العودة إلى الوراء
يعد سوء الفهم وعدم وجود رؤية للمنتج الذي يتم بناؤه ضمن مشروع تطوير البرمجيات من المشاكل الشائعة جداً في التعاون بين العميل والفريق المسؤول عن العملية. هذه الأخطار لها تأثير مباشر على النتائج المحققة وغالباً ما ترتبط بفقدان المواعيد النهائية وخسائر الميزانية. انظر أين يمكن أن تظهر هذه المخاطر وكيفية محاربتها.
مصدر الصورة: perfectdigital.com
أعتقد أنه يظهر بشكل جيد للغاية أن التناقضات الكبيرة وانعدام الرؤية قد تظهر في مشاريع تطوير البرمجيات بين جميع المشاركين والأشخاص المعنيين. غالبًا ما تنشأ المشاكل منذ البداية، عندما يأتي العميل بمقترح نهائي (نظريًا) المنتج الرؤية ويعرضها على الفريق. ثم يأتي المزيد من سوء الفهم، وسوء التفسير، وفي النهاية المشروع يسير بسرعة في المسار الخاطئ للتطور.
أثناء تحليل الرسم البياني أعلاه، سأعرض خطوة بخطوة جميع التهديدات المحتملة وأقترح كيفية محاربتها. دعونا ندخل في صلب الموضوع!
سيكون هناك تناقضات في رؤية المنتج منذ البداية. لماذا؟ السبب بسيط للغاية - كل شخص يفسر الواقع بطريقته الخاصة، ولديه فكرة عن شيء ما في ذهنه وقد لا يقدم هذه الرؤية بدقة للطرف الآخر. إذا قمت بوصف المنتج الذي ترغب في بنائه بالكلمات، فهناك احتمال كبير أن يفهم فريق التطوير رؤيتك بطريقة مختلفة عما كنت تقصده.
بالطبع، من الممكن تجنب ذلك. يجب عليك البدء في وضع التصور في أقرب وقت ممكن ومناقشة العناصر الفردية لوظائف المنتج بناءً على الرسومات التخطيطية. ومن المثير للاهتمام أن الرسومات التخطيطية الأولى عادةً لا تشترك في شيء مع المنتج النهائي. ومع ذلك، فإن أهم شيء في هذه المرحلة هو جعل الرؤية متماسكة.
هل تتساءل عن سبب اختلاف الصورة الأولى عن الثانية؟ سيلقي قائد المشروع دائمًا نظرة فاحصة على رؤية المنتج. ومع ذلك من المهم أن يكون مثل هذا الشخص، المسؤول بشكل أساسي عن تطوير البرمجيات العملية, الفهم الكامل للمشكلة والاحتياجات المتعلقة بالمنتج. يجب أن يكون لدى قائد المشروع "صورة أكبر" واضحة. كما ترى، لا تختلف الصورتان من حيث الوظيفة. إنهما فقط يبدوان مختلفتين. لفهم هذه النقطة بشكل أفضل، دعنا نعود إلى الصورة رقم واحد. في بداية المشروع، لم تكن هناك رسومات تخطيطية وأدى ذلك بالفعل إلى سوء فهم. وظيفة المنتج صحيحة، ولكن التصميم مختلف تمامًا.
في بعض الأحيان، لا يعرف المحللون والمطورون احتياجات المستخدمين أو أهداف العمل المحددة. فهم يرون فقط الجزء الصغير من المشروع بأكمله، والذي يستحوذ على تركيزهم الرئيسي. فهم غير قادرين على النظر من منظور أوسع، وهذا هو الحال بشكل خاص بالنسبة للمشاريع الكبيرة، حيث يعمل الكثير من المطورين في نفس الوقت.
يمكننا أيضًا استخدام مثال آخر. قد يحدث أن يتم وصف المشكلة المراد حلها بشكل غير صحيح، على سبيل المثال، من قبل مالك المنتج. يتضمن ذلك تقديم معلومات غير مكتملة يقوم المطور أو المصمم على أساسها بإنشاء تفسيراته الخاصة، وينحرف المنتج عن مسار التطوير المقصود أكثر فأكثر.
كيف يمكن تغيير ذلك؟ أعتقد أن الحل الجيد هو التأكد من أن الأشخاص الذين يعتبرون أساسيين في المشروع لديهم معرفة مفصلة عنه - ما يسمى بـ "الصورة الأكبر". في حالة حدوث سوء فهم، سيكون من الأسهل عليهم أن يجلبوا عملية تطوير البرمجيات على المسار الصحيح. لذا، تذكر - إذا كان كل شخص يرى فقط الجزء الضئيل من الوظائف المتطورة، فإن سوء الفهم في الرؤية يصبح تهديدًا محتملاً.
الأمر هنا بسيط. يجب أن يبيع المنتج. عليك أن تبرز بطريقة ما، لذا، على سبيل المثال، أرجوحة بسيطة لحديقتك تحقق عناصر غير عادية. الفكرة هي إقناع المشتري المحتمل. من المؤكد أن قسم التسويق والمبيعات سيفعل كل شيء لإظهار أن المنتج فريد من نوعه.
التوثيق المفقود مشكلة شائعة جدًا. في بعض الأحيان، يكون إنشاء الوثائق أثناء تطوير المنتجات يبدو مضيعة للوقت لا داعي لها. هذا خطأ. أقول في كثير من الأحيان أن التغييرات تتم بشكل أسرع على الورق من الكود، وهناك شيء ما في ذلك. بالإضافة إلى ذلك، من الأسهل الرجوع إلى الوثائق لتتبع أي تغييرات. صدقني، المشروع الذي لا يحتوي على وثائق يكون معرضًا لخطر كبير جدًا لفقدان الرؤية.
تشير هذه المرحلة إلى وضع البيئة على الخادم. وكما هو الحال في النقطة المتعلقة بالمبرمجين والمحللين، فبدون بيانات كاملة ومع وجود ثغرات في الاتصالات، قد يتبين أنه لم يتم إنشاء سوى جزء من البيئة اللازمة.
إنه نتيجة لضعف التواصل ونقص تجربة المستخدم وما إلى ذلك. ظهور الأخطاء يزيد من وقت التطوير. والوقت هو المال، أليس كذلك؟ تلميحاتي هي إدارة المشروع وفقًا لـ Agileوالحفاظ على أعلى معايير التواصل والحفاظ على إرشادات واضحة بشأن الميزانية. ولا يساورني شك في أنكم بذلك ستتجنبون مثل هذه المشاكل.
كثيرًا ما يركز العملاء في كثير من الأحيان على بناء المنتج والانتهاء منه فقط. ومع ذلك، نحن نعيش في زمن يشهد العديد من التغييرات والابتكارات التكنولوجية، ولهذا السبب من الضروري الحفاظ على الدعم التقني المستمر. والفكرة هي تجنب حدوث موقف يتوقف فيه شيء ما عن العمل فجأة حيث يصبح قديمًا ويفقد المنتج قيمته. لا ينبغي نسيان هذا الجانب أيضاً.
لقد وصلنا إلى النقطة الأخيرة. انظر إلى التناقض بين الرسمين البيانيين الأول والأخير. ففي النهاية، كلاهما يتعلق بوجهة نظر العميل. لماذا يحدث هذا؟ الجميع يكذبون بهذه البساطة 🙂 نتائج الاستبيان تختلف دائمًا عن الاحتياجات الفعلية للمستجيبين. أثناء الإجابة على سؤال الباحث، يرغب المستخدمون في إظهار أفضل ما لديهم. لذلك, غالبًا ما لا يستجيبون بصدقبل بطريقة يعتقدون أن عليهم الإجابة عنها. في الأساس، لا يريدون أن يتعرضوا للتقييم السلبي للآخرين. إليك تلميحًا صغيرًا لك - اذكر في التعليمات أنه لا توجد إجابات جيدة أو سيئة.
أين تظهر الاختلافات الأخرى؟ غالبًا ما لا يعرف الناس ما يريدونه حقًا. في كثير من الأحيان، يقول المستخدمون في البداية إنهم يحتاجون إلى 10 وظائف في المنتج، ثم يستخدمون في الواقع 3 وظائف فقط في وقت لاحق.
إذن كيف يمكنك حل هذه المشكلة؟ بالإضافة إلى سؤال المستخدمين عما يريدونه ويحتاجونه، اسمح لهم باختبار المنتج، ويفضل أن يكون ذلك على عناصر أصلية للحفاظ على المصداقية. كلما زادت الاختبارات أثناء إنشاء المنتجات، زادت فرصة أن تكون النتيجة دقيقة.
إذا أصبحت عضوًا في تطوير البرمجيات مشروع، تذكر أمثلتي واستخلاص الاستنتاجات حتى لا تنسخ الأخطاء المذكورة أعلاه. وتذكر أن هذه المفاهيم مهمة جداً في بناء منتج (تطبيق) من الصفر:
- تجربة مستخدم جيدة واختبارات جيدة، حتى تتمكن من معرفة ما يحتاجه المستخدمون حقًا,
- التواصل داخل المشروع، بحيث يتوفر فهم عميق للمشكلة والاحتياجات للأشخاص الرئيسيين في المشروع,
- تطوير المنتج بما يتوافق مع المرونة,
- لا تنسى الدعم الفني
اقرأ المزيد:
– كيفية إدارة المطورين عن بُعد بفعالية؟ دليل CTOs CTO
– Python مقابل روبي؟ ما التقنية التي يجب أن تستخدمها لتطوير المنتج؟
– دليل سريع لبناء وتطوير السوق الخاص بك. ما الذي يستحق أن تعرفه؟
Arabic 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Italian 
Japanese 
Korean 
Polish