كيفية تسعير المشاريع وإدارة زحف النطاق

أنا متأكد من أنك قرأت مقالات غير واقعية تشير إلى وجود نهج علمي للتسعير يتيح لك بطريقة سحرية إنشاء عرض أسعار دقيق. ربما تكون قد دفعت أيضًا إلى الاعتقاد بأنه يجب تجنب زحف النطاق بأي ثمن ، ولكن في العالم الحقيقي ، سيحدث دائمًا.

لقد حان الوقت بالنسبة لنا للتوقف عن لعب هذه اللعبة السخيفة والبدء في تشغيل المشاريع بطريقة لا تشبه المقامرة وتشبه إلى حد بعيد اتباع عملية قوية وموثوقة.

هل أنا أبالغ؟ ربما ، ولكن دعونا نلقي نظرة على المواضع التي تسوء فيها الأمور في كثير من الأحيان في المشاريع الرقمية.

المشاكل مع عملية مشروعنا

من واقع خبرتي ، فإن معظم المؤسسات في أي صناعة تدير مشاريع بنفس الطريقة تقريبًا:

1. شخص ما في الإدارة يطلب استكمال المشروع. لسوء الحظ ، غالبًا ما يفتقر هذا الطلب إلى التفاصيل من حيث النواتج ويميل فقط إلى أن يكون له أهداف غامضة.
2. يتم تشكيل لجنة من أصحاب المصلحة لتحديد المشروع بالتفصيل واتخاذ قرار بشأن النطاق.
3. ثم يتم نقل النطاق التفصيلي إلى الفريق الذي سيبنيه ، ويطلب منهم تقدير المدة التي سيستغرقها ومقدار التكلفة.
4. يتم تسليم المشروع حسب المواصفات ، مع التأكيد على التسليم في الوقت المحدد وفي حدود الميزانية. نتيجة لذلك ، يصبح زحف النطاق هو العدو.
5. يتم تسليم المشروع ، وينتقل الجميع إلى المشروع التالي في قائمة المهام الخاصة بهم.

هذا النهج بعيد كل البعد عن المثالية ، خاصة بالنسبة للمشروعات الرقمية. تزودنا الرقمية بتعليقات غير مسبوقة على سلوك المستخدم وتجعل من السهل نسبيًا تنفيذ التغييرات (مقارنة بالمنتجات المادية). ومع ذلك ، بمجرد تحديد النطاق وتقديم عرض أسعار ، يصبح المشروع مغلقًا ، مع تردد الجميع في إجراء تغييرات مع تقدم المشروع.

ومع ذلك ، لا مفر من أن يتغير النطاق ، ويرجع ذلك أساسًا إلى أن أصحاب المصلحة لديهم تفسيرات مختلفة لما سيتم بناؤه أو لأنهم يدركون منتصف المشروع أن العناصر الحاسمة خاطئة.

في الحقيقة ، لا حرج في زحف النطاق . يعد الحفاظ على المرونة والتكيف مع تعلم المزيد أمرًا أساسيًا لإنشاء خدمات رقمية ممتازة. لا تكمن المشكلة في زحف النطاق ولكن في الطريقة التي ندير بها المشاريع.

لسوء الحظ ، نظرًا لأنه تم الاتفاق على المواعيد النهائية والتكاليف ، نحاول تقديم هذه التغييرات ضمن تلك القيود ، مما يؤدي إلى قطع الزوايا.

لا يعني ذلك أن الجداول الزمنية والتكاليف كانت دقيقة في المقام الأول. المشاريع الرقمية معقدة ، وغالبًا ما تتضمن عمل المتخصصين وأصحاب المصلحة معًا. نتيجة لذلك ، من الصعب تقديرها بدقة.

لقد قرأت العديد من المقالات التي تقترح منهجيات للتقدير بدقة. ومع ذلك ، فهي غير عملية في العالم الحقيقي في جميع الحالات تقريبًا ، ويرجع ذلك أساسًا إلى أنها تستغرق وقتًا طويلاً في التقديم. يعتمد تقدير المشروع على الحدس والخبرة والتخمين المتعلم!

كما سيخبرك أي شخص عمل في هذا المجال لأي وقت ، فإن معظم التقديرات هي عمل خيالي . عادة لا نعرف ما يكفي مقدمًا حتى لتحديد الحل الصحيح أو كيفية استجابة المستخدمين له. لذلك من المستحيل إجراء تقدير دقيق لمشروع كامل مقدمًا.

لسوء الحظ ، غالبًا ما يؤدي هذا الغموض إلى توزيع اللوم بشكل غير عادل عندما يفوت المشروع حتماً الموعد النهائي ويتجاوز الميزانية.

لحسن الحظ ، هناك طريقة لتقديم تقديرات دقيقة وإدارة زحف النطاق الذي يتضمن تغيير المشاريع قيد التشغيل. يكمن السر في تقسيم المشاريع إلى أجزاء أصغر. هذا النهج يتجنب اتخاذ مشاريع كبيرة ومعقدة.

قسم المشاريع إلى سلسلة من المشاركات الأصغر

أريد أن أكون واضحًا في هذه المرحلة. أنا لا أقترح أن برامج العمل الطموحة خاطئة. أعمل لدى عملاء كبار على مواقع ويب كبيرة وبرامج عمل مترامية الأطراف. ومع ذلك ، نادرًا ما أتعامل مع هذه الارتباطات كمشروع واحد كبير. بدلاً من ذلك ، أقوم بتقسيمها إلى مشاريع أكثر قابلية للإدارة والتي أضعها في نطاق واحد في كل مرة.

عندما يقترب مني أحد العملاء راغبًا في تنفيذ مشروع رقمي (سواء كان كبيرًا أو صغيرًا) ، أقوم عادةً بتقسيمه إلى أربع مراحل تحدث بالترتيب التالي:

1. اكتشاف،
2. ألفا،
3. الحد الأدنى من المنتج القابل للتطبيق ،
4. التكرار والتحسين المستمر.

كل مرحلة هي مشاركة منفصلة مع نتائج واضحة. لذلك أنا لا ألتزم بالمشروع بأكمله ولكن بالمرحلة الأولى فقط. هذا يجعل تقدير وإدارة زحف النطاق أسهل كثيرًا.

على سبيل المثال ، ما عليك سوى تحديد نطاق المرحلة التالية. يتيح لك ذلك إدارة زحف النطاق بشكل أفضل لأنه يمكنك مواءمته أثناء تحديد المرحلة التالية ، بمجرد اكتمال المرحلة السابقة.

بدلاً من تقدير برنامج عمل كامل ، فأنت تقوم بتقدير المشروع التالي في هذا البرنامج. أيضًا ، يمكنك استخدام المرحلة السابقة لمساعدتك في التقدير بشكل أكثر دقة.

تساعد كل مرحلة على تحديد وتقدير المرحلة التالية ، بدءًا من الاكتشاف.

1. الاكتشاف

في مرحلة الاكتشاف ، أعمل مع أصحاب المصلحة للتحقق من صحة المشروع. اعتمادًا على الحجم الإجمالي للمشروع ، يمكن أن يكون هذا بسيطًا مثل اجتماعين أو يمكن أن يكون برنامج عمل كامل.

عادةً ما تتضمن عناصر مثل:

• إجراء بحث المستخدم ؛
• تحليل المنافسة.
• تحديد مؤشرات الأداء الرئيسية ؛
• تحديد شكل النجاح ؛
• فهم القيود؛
• تجميع آراء أصحاب المصلحة.

الفكرة هي أن مرحلة الاكتشاف ستقدم تعريفًا أكثر استنارة للمشروع ، بما في ذلك احتياجات المستخدم وأهداف العمل وما يجب إنشاؤه.

الأهم من ذلك ، أنه سيتم التحقق من أن المشروع سيقدم القيمة المطلوبة.

يمكننا بعد ذلك استخدام هذا الناتج لتحديد وتقدير العمل المطلوب في مرحلة ألفا. يؤدي القيام بذلك إلى زيادة دقة تقديراتنا وكذلك تعديل النطاق بناءً على ما تعلمناه.

2. ألفا

مرحلة ألفا هي المكان الذي نحدد فيه كيفية عمل الخدمة الرقمية (سواء كان ذلك تطبيق ويب أو موقعًا) ونضمن حصول المستخدمين على تجربة إيجابية في استخدامها.

يتم ذلك عادةً من خلال إنشاء نموذج أولي. في المشاريع الصغيرة ، قد لا يكون هذا أكثر من بعض نماذج بالحجم الطبيعي للتصميم. في المشاريع الكبيرة ، يمكن أن يكون نموذجًا أوليًا وظيفيًا يمكن للناس تجربته.

مهما كان الأمر ، فإن الفكرة هي تصور الخدمة الرقمية التي تقوم ببنائها.

نفعل هذا لثلاثة أسباب.

• أولاً ، سيضمن التصور أن يكون لدى جميع أصحاب المصلحة رؤية مشتركة لما تقوم بإنشائه. يمكن تفسير المستند بعدة طرق مختلفة ، ولكن القيام بذلك يكون أصعب بكثير مع النموذج الأولي.
• ثانيًا ، سيجعل النموذج الأولي من الأسهل كثيرًا تحديد أي شيء ربما تم تجاهله ، لذا تجنب تسلل النطاق إلى أسفل الخط عندما يكون معالجته أكثر تكلفة.
• أخيرًا ، إذا كان لدينا شيء ملموس ، فيمكننا اختباره مع المستخدمين للتأكد من أنه سيكون مناسبًا للغرض قبل أن نذهب إلى حساب بناء الشيء الحقيقي.

إذا كان الاختبار سيئًا ، فلا يزال لدينا متسع قبل المرحلة التالية للتكيف دون كسر الميزانية أو إفساد الجدول الزمني.

كما هو الحال مع مرحلة الاكتشاف ، يمكننا استخدام ألفا لتقدير العمل المطلوب في المرحلة التالية. إن وجود تصور لما يحتاج إلى بناء يجعل تقدير العمل المطلوب أسهل كثيرًا لجميع أصحاب المصلحة المعنيين. يمكنهم رؤية ما يُطلب منهم بناءه.

بالإضافة إلى ذلك ، يمكننا استخدام الدروس المستفادة من اختبار ألفا لتكييف ما سننشئه ، مرة أخرى لخلق مساحة للتغييرات في النطاق دون عرقلة المشروع.

بمجرد أن نحصل على ألفا ، يمكننا بعد ذلك الانتقال بثقة إلى البناء ، مع العلم أننا سننشئ الشيء الصحيح وأن المستخدمين سيستجيبون له بشكل إيجابي.

3. الحد الأدنى من المنتج القابل للتطبيق

اعتدت أن أشير إلى هذه المرحلة باسم "البناء". ومع ذلك ، وجدت أن أصحاب المصلحة قد ربطوا إنهاء البناء باستكمال المشروع. في الواقع ، لا يتم تنفيذ الخدمات الرقمية أبدًا ، حيث يلزم تكرارها باستمرار لضمان فعاليتها قدر الإمكان.

لتجنب هذه المشكلة ، بدأت في الإشارة إلى هذه المرحلة على أنها الحد الأدنى من المنتج القابل للتطبيق (MVP). في هذه المرحلة ، نبني ونطلق النسخة الأولية من الخدمة الرقمية.

بالإشارة إليه على أنه الحد الأدنى من المنتجات القابلة للتطبيق ، نؤكد أنه سيكون هناك تكرار بعد الإطلاق. يوفر لنا ذلك طريقة للتعامل مع زحف النطاق والتعقيد غير المتوقع عن طريق دفعه للوراء حتى مرحلة ما بعد الإطلاق. وهذا يضمن بقاء المشروع على المسار الصحيح ويحافظ على زخمه.

حتمًا أثناء الإنشاء ، سنضع بعض الأشياء على الرف حتى مرحلة ما بعد الإطلاق. تصبح هذه العناصر بعد ذلك الأساس لتحديد مرحلتنا النهائية ، مما يمكننا من إجراء تقدير أولي لتحسين ما بعد الإطلاق.

4. استمرار التكرار والتحسين

تتعامل مرحلة ما بعد الإطلاق مع الوظائف والتعقيد والمشكلات الأخرى التي لم نعالجها في MVP. من السهل نسبيًا تحديد نطاق قائمة التحسينات هذه في هذه المرحلة ويمكن تقديرها بدقة معقولة.

ومع ذلك ، بالإضافة إلى هذا العمل ، يجب أن تكون هناك عملية مستمرة للمراقبة والتكرار والاختبار التي تزيد من تحسين فعالية الخدمات الرقمية.

يجب أن يعتمد تقدير مقدار هذا العمل الذي تقوم به على حجم وتعقيد الخدمة الرقمية. يجب أن يكون تقديرك أيضًا متناسبًا مع الاستثمار في باقي المشروع.

من خلال تقسيم مشاريعك إلى هذه المراحل الأربع وإكمال كل منها على حدة ، ستزيل العديد من التحديات التي نواجهها عند استخدام مناهج إدارة المشاريع التقليدية.

لماذا يعمل تفكيك المشاريع

تأتي أربع فوائد مهمة من تجزئة المشاريع بهذه الطريقة:

• يتم تحديد كل مرحلة بشكل أفضل .
  لأن مخرجات المرحلة السابقة تحدد كل مرحلة ، فهذا يعني أن هناك رؤية واضحة للاتجاه. يساعد ذلك أصحاب المصلحة على فهم إلى أين تسير الأمور وتجنب المفاجآت السيئة لاحقًا.
• يتم تقدير المشاريع بدقة أكبر .
  على سبيل المثال ، بدلاً من الاضطرار إلى تخمين المدة التي سيستغرقها تقديم مشروع مهم وغامض مع عدد كبير من الأشياء المجهولة ، فأنت تقوم فقط بتقدير المرحلة التالية والقيام بذلك بناءً على مخرجات المرحلة السابقة.
• ينتج عنه خدمات رقمية أفضل .
  نظرًا لأنه يتم التحقق من صحة أفكار المشروع واختبارها مع المستخدمين ، يمكنك أن تكون أكثر ثقة في أن المنتج النهائي سيتناسب مع الغرض. كما أنه يتيح مساحة لتكييف النطاق والوظائف بين المراحل لضمان تقديم أفضل نتيجة ممكنة.
• إنه نهج أقل خطورة .
  لا تحتاج الشركة التي تقوم بتشغيل الخدمة الرقمية إلى الالتزام بالمشروع بأكمله مقدمًا. إذا فشلت مرحلة الاكتشاف في التحقق من صلاحية المشروع ، فيمكن إسقاطه مع خسارة طفيفة. وبالمثل ، إذا لم يتم اختبار نموذج ألفا الأولي جيدًا مع المستخدمين ، فيمكن تكييفه قبل أن تصبح الأشياء باهظة الثمن.

هذه النقطة الأخيرة مطمئنة إذا تم استخدام مورد خارجي لأول مرة. بدلاً من الاشتراك في وكالة لمشروع كبير دون معرفة ما إذا كان بإمكانهم التسليم ، يمكن للعميل إشراكهم في مرحلة الاكتشاف لمعرفة ما هم عليه. إذا كانوا جيدين ، يمكنهم مواصلة العمل معهم. إذا لم يكن الأمر كذلك ، فيمكنهم نقل النتائج إلى وكالة أخرى دون فقدان أي شيء.

إذا كنت تدير وكالة أو تعمل لحسابهم الخاص ، فقد تعتقد أن هذا يبدو وكأنه فكرة سيئة. من المفهوم أنك تفضل تسجيل عميل للمشروع بأكمله. ومع ذلك ، فقد تجنبت العديد من المناقصات التنافسية مع هذا النهج لأن العميل لم يشعر أنه يخاطر بمثل هذا الاستثمار الأولي الصغير. بالإضافة إلى ذلك ، لم يشعروا بالحاجة إلى التحدث إلى العديد من الموردين لأنهم إذا لم يحبوني ، فيمكنهم التبديل بسهولة.

بالإضافة إلى ذلك ، فإن استخدام هذا النهج التدريجي سيجعل تحديد النطاق والتسعير لمشروعك التالي ذي السعر الثابت أسهل كثيرًا. بالتأكيد ، لن يقدم تقديرًا بطريقة سحرية أو يمنع زحف النطاق. ومع ذلك ، فإنه سيجعل التقدير أكثر قابلية للإدارة لأنك تقوم فقط بتحديد نطاق جزء واحد في كل مرة. سيسمح لك أيضًا بالعمل مع زحف النطاق ، بدلاً من محاولة قمعه.

لذا فإن نصيحتي ، سواء كنت تعمل داخليًا أو خارجيًا ، في مواقع كبيرة أو صغيرة ، هي التوقف عن محاولة تقدير المشروعات ونطاقها دون تقسيمها إلى مراحل. بدلاً من ذلك ، تعامل مع مرحلة واحدة في كل مرة واستخدم ما تتعلمه لإبلاغ المرحلة التالية . إذا قمت بذلك ، فستقدر بشكل أكثر دقة ، وستتاح لك مساحة للتكيف بناءً على ما تعلمته ، وستجد أن إدارة المشروع أكثر وضوحًا.