المعهد يعلم الخوارزميات ، هياكل البيانات ، OOP. في حالة جيدة ، يمكنهم التحدث عن أنماط التصميم أو البرمجة متعددة الخيوط. لكنني لم أسمع عن كيفية تقييم تكاليف العمالة بشكل صحيح.

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

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

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

أنماط التقييم المضادة

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

تافه ، ولكن غير سارة

افترض أنك تقوم بتطوير نظام إدخال أوامر ، لكنك لم تتمكن بعد من تطوير متطلبات لإدخال أرقام الهواتف. من بين حالات عدم اليقين التي يمكن أن تؤثر على تقييم البرنامج ، يمكننا تسليط الضوء على ما يلي على الفور:

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

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

مثال آخر ممتاز على "التورم" قد يبدو مطلبًا أوليًا ، اقرأ في مقال " كيف يكون أسبوعان ؟!

مخروط من عدم اليقين

تطوير البرمجيات - والعديد من المشاريع الأخرى - يتكون من آلاف الحلول. وجد الباحثون أن تقديرات المشروع في مراحل مختلفة متأصلة في مستويات عدم اليقين المتوقعة. مخروط عدم اليقين يدل على أن التقديرات تصبح أكثر دقة مع تقدم المشروع. يرجى ملاحظة أنه في مرحلة المفهوم الأولي (حيث يتم إجراء التقديرات والالتزامات في كثير من الأحيان) ، يمكن أن يكون الخطأ 400 ٪ (أربعمائة في المئة ، كارل!). من الأفضل تقديم التزامات بعد الانتهاء من التصميم التفصيلي.

رجل الأسطوري الشهر

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

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


يحاول فريق المشروع التغلب على الصدمات // إيفان إيفازوفسكي ، 1850

إذا كان بإمكان 8 أشخاص كتابة برنامج خلال 10 أشهر ، هل يمكن لـ 80 شخصًا كتابة البرنامج نفسه في شهر واحد؟ يصبح عدم كفاءة المواعيد النهائية القصوى للتشديد واضحًا بشكل خاص في الحالات القصوى - مثل 1600 شخص يحتاجون إلى كتابة برنامج في يوم واحد. اقرأ المزيد حول هذا الموضوع في كتاب يحمل نفس الاسم لفريدريك بروكس .

أنماط التقييم

لذلك ، مع المشاكل كل شيء واضح. ما الذي يمكن عمله؟

التحلل

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

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

الميزات والمهام

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

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

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

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

التقييم في مجموعات ، وتخطيط لعبة البوكر

المبرمجون متفائلون جدًا بشأن حجم العمل. وفقًا لمصادر مختلفة ، غالباً ما يختلف التقليل من قيمة العملة في حدود 20-30٪. ومع ذلك ، في مجموعات يتم تقليل الخطأ. ويرجع ذلك إلى تحليل أفضل بسبب وجهات نظر مختلفة وتقييم مزاجه.
الممارسة الأكثر شيوعًا مع تزايد شعبية Agile هي ممارسة " تخطيط لعبة البوكر " ، ومع ذلك ، ترتبط مشكلتان بتقييم المجموعة:

1. الضغط الاجتماعي
2. تكاليف الوقت

الضغط الاجتماعي

في أي مجموعة تقريبًا ، ستختلف تجربة المشاركين وفعاليتهم الشخصية. إذا كان لدى الفريق فريق / تقنية قوية - مبرمج الرصاص / الرصاص ، فقد يشعر الأعضاء الآخرون بعدم الارتياح ويقللون من شأن الدرجات: "حسنًا ، كيف يمكن لفاسيا أن تفعل ذلك ، لكن هل أنا أسوأ؟ يمكنني أن أفعل ذلك أيضًا! " قد تكون الأسباب مختلفة: الرغبة في أن تبدو أفضل مما هي عليه بالفعل ، منافسة أو مجرد توافق. والنتيجة هي واحدة: تقييم مجموعة يفقد كل مزاياه ويصبح الفردية. يعطي Timlid علامات ، والباقي يوافق عليه ببساطة.

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

هناك العديد من التوصيات الرئيسية:

1. يتم تقدير معظم التقييمات. لا يمكنك الاختيار بين تصنيفين؟ خذ واحدة أكبر.
2. لست متأكدا من التقييم - طرد البطاقة "؟" أو تصنيف كبير. ربما لا يحمل أبدا تقريبا.
3. دائما مقارنة الخطة والحقيقة. إذا كنت تعرف أنك غير لائق مرتين ، فقم بتقديم تقدير أعلى مرتين مما تعتقد. بدأت في المبالغة؟ اضرب في عقلك بمقدار واحد ونصف. بعد تكرار قليل ، يجب تحسين جودة الدرجات الخاصة بك بشكل كبير.

تكاليف الوقت

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

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

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

تخطيط التبعية ، مخططات جانت

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

1. الجدول ديسيبل
2. رمز الخلفية
3. رمز الواجهة الأمامية

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

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

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

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

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

قفل المهمة

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

المسار الحرج ، والمخاطر المقبلة

. , ( ), , , , . , , , , , , . , .

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

لذلك ، عليك أن تبدأ بالمهام الأكثر موحلة ومعقدة وغير سارة ، ووضعها في وضع "محظور" وتوضيح وإعادة تقييم وإزالة التبعيات كلما كان ذلك ممكنًا.

معايير القبول ، وحالات الاختبار

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

إدارة المشاريع

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

تتبع الوقت ويعرف أيضا باسم تتبع الوقت

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

الخاتمة

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

هل تريد معرفة المزيد عن تقييم المشروع؟

اقرأ كتاب ستيف ماكونيل " كم يكلف مشروع برمجيات " ومقالات أخرى حول هذا الموضوع عن حبري:

1. habr.com/en/company/infopulse/blog/170777
2. habr.com/en/post/308494
3. habr.com/en/company/ruswizards/blog/151029
4. habr.com/en/company/mindbox/blog/321270
5. habr.com/en/post/307820