استخدام جداول البيانات الرشيقة لتقدير الاكتشاف

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

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

أدخل جدول البيانات Agile.

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

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

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

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

تعامل مع رؤية المنتج وخارطة الطريق أولاً

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

يعجبني تنسيق رؤية منتج Scrum.org لأسلوبه السردي البديهي. هذا ما يبدو عليه:

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

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

لاستخدام Microsoft كمثال: كان Windows 8 على الأرجح إصدارًا لخريطة طريق. كان Windows 10 إصدارًا آخر لخريطة الطريق يتميز بالعديد من الميزات الجديدة والمرغوبة.

بمجرد اكتمال رؤية المنتج وخارطة الطريق ، حان الوقت لمطالبة العميل بالالتزام بـ MVP.

تفاوض على ميزات MVP باستخدام مخطط القيد الثلاثي

هذه هي اللحظة لتشكيل توقعات العميل حول الوقت والنفقات باستخدام مخطط القيد الثلاثي:

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

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

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

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

ابدأ بمقاسات القمصان

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

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

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

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

اضبط معلماتك

أنت الآن جاهز لوضع جدول البيانات الخاص بك في العمل وحساب التقدير الخاص بك. ابدأ بإنشاء علامة تبويب المعلمات. سيعمل هذا كمفتاح لعملياتك الحسابية ، والقيم التي تدخلها هنا ستغذي الصيغ المستخدمة في Backlog / User Stories وتقدير الملخص من خلال علامات التبويب Release.

إليك كل ما تحتاجه في علامة التبويب "المعلمات":

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

تاريخ البدء. سيتم استخدام تاريخ بدء التطوير المتوقع لإنشاء مخطط زمني للمشروع. في كل مثال ، تاريخ البدء لدينا هو 25 أكتوبر.

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

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

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

معدلات لكل ساعة. استخدم هذا الجدول لتوثيق معدلات الأجور لكل دور. إذا كان لدى مطوري الواجهة الخلفية معدلات مختلفة ، فاستخدم متوسط ​​الاثنين.

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

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

حجم كل إصدار مع الملاحم

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

أولاً ، حدد العمود "EPIC؟" وتأكد من تحديد "Epic" فقط.

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

لاحظ أنه في معظم الحالات ، تعرض الخلايا الموجودة في عمود "النقطة" الرقم "34 *". إذا عدت إلى علامة التبويب المعلمات ، فسترى أن 34 نقطة تتوافق مع نطاق كل ساعة بين 33 و 48 ساعة. هذا العدد من الساعات كبير جدًا إذا كانت مدة الركض أسبوعًا واحدًا فقط.

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

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

نظرًا لعدم وجود قصص مستخدمين لعرضها حتى الآن ، تحقق من زر "وضع Epic".

يمكنك الآن رؤية التكلفة التقريبية والجداول الزمنية لـ MVP والميزات والتحديثات الأقل إلحاحًا في الإصدارات المستقبلية (R3 و R4). في هذا المثال ، يكون الإصدار الثاني (R2) فارغًا لأن العميل قد طلب إطلاق جميع ملاحم MVP في الإصدار الأول.

يمكنك الآن رؤية التكلفة الإجمالية الأكثر تفاؤلاً: 28،810 دولارًا. هذا الرقم هو مجموع تكلفة كل إصدار من MVP حتى R4.

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

في هذه الحالة ، يكون المسار الحرج هو تطوير الواجهة الأمامية ، مع تاريخ الانتهاء في 31 يناير.

حان الوقت الآن لضبط المعلمات لمحاكاة الميزانية الأسوأ وأطول جدول زمني.

ضبط الطوارئ إلى 50٪

ما زلنا نعرف القليل نسبيًا عن متطلبات الجهد والخبرة للمنتج ، لذلك سنضيف طوارئ ROM بنسبة 50 ٪ في علامة التبويب المعلمات. سينخفض ​​الاحتياج كلما عرفنا المزيد من التفاصيل حول المشروع.

مرة أخرى ، ها هو إجمالي تقدير المشروع عند 0٪ للطوارئ.

وهنا بنسبة 50٪ للطوارئ.

وهذا يعني أن تقدير ROM للمشروع بأكمله يتراوح بين 28810 دولارًا و 41860 دولارًا. في أفضل الحالات وأسوأها ، لن تكون ميزانية العميل البالغة 20000 دولار كافية لتضمين جميع الميزات في قائمة رغباته.

تاريخ الانتهاء الكامل للمشروع بنسبة 50 ٪ للطوارئ يقع الآن في 14 مارس ، أي بعد ستة أسابيع من تاريخ الانتهاء للطوارئ بنسبة 0 ٪.

في غضون ذلك ، سيكون MVP جاهزًا في 10 يناير.

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

أعد ترتيب الأولويات للوفاء بالمواعيد النهائية

لنفترض أن العميل حدد تاريخًا مستهدفًا في 25 ديسمبر لـ MVP ، بعد شهرين من بداية 25 أكتوبر.

للانتقال إلى تاريخ الانتهاء الحالي لـ MVP 10 يناير ، وافق العميل على تأخير ملحمتين MVP حتى الإصدار التالي (R2).

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

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

تنتهي الآن مجموعات التطوير الأمامية والخلفية في نوفمبر ، وأصبحت ضمان الجودة المسار الحرج الجديد (مع تاريخ الانتهاء في 20 ديسمبر). لاحظ أن التكلفة لا تتغير. ذلك لأن إجمالي ساعات العمل في كل مجموعة تظل كما هي. بدلاً من مطور واحد يعمل لمدة أسبوعين (80 ساعة) ، يعمل مطوران لمدة أسبوع واحد (80 ساعة).

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

وفقًا لجدول بدوام كامل ، ستكتمل UX / UI في 29 نوفمبر.

وفقًا لجدول بدوام جزئي ، ستكتمل UX / UI في 27 ديسمبر.

مرة أخرى ، لا تتغير التكلفة ، لكن UX / UI تصبح المسار الحرج الجديد ، لتمديد الجدول الزمني لـ MVP حتى 27 ديسمبر.

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

صقل تقديراتك مع قصص المستخدمين

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

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

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

لنلقِ نظرة على كيفية تقسيم الملاحم إلى قصص مستخدمين أصغر وأكثر تفصيلاً:

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

ضمن "T-shirt Sizing" في علامة التبويب Backlog / User Stories ، أدخل مجموعة الحجم المخصصة للمطورين والشركات الصغيرة والمتوسطة لأكوامهم لكل قصة. من هناك ، ستعمل صيغة جدول البيانات تلقائيًا على ملء الساعات المقابلة من علامة التبويب المعلمات. تذكر أن الحجم الأكبر ، LL ، يجب أن يظل أقل من 34 نقطة للتأكد من أنه يمكن إكماله خلال مدة العدو المتفق عليها. أي قصص لا يزال معدل 34 نقطة أو أعلى يجب تقسيمها.

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

الآن سترى مجموعة جديدة من الأرقام:

بعد تفصيل جميع المهام والالتزام بميزات MVP فقط ، يتطابق الجدول الزمني والتكلفة الآن مع متطلبات العميل. نظرًا لأن الرصيد في حدود ميزانيته ، يقرر العميل المضي قدمًا في MVP واختباره قبل الالتزام بإصدارات إضافية.

جعله لك

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

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

هل تفضل جداول البيانات المخصصة على أدوات إدارة المشاريع الجاهزة؟ أخبرنا لماذا أو لماذا لا في التعليقات.