🎴 ⏺️ 🙆🏼 مشاريع العجيل المتزامنة (تحت السجن) والشلال 👆 🏇🏿 💍

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

كانت

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

أصبح

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

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

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

الإدخالات في النظام تبدو كما يلي:

مشاكل

نهج الصيانة منطقي للغاية ، ولكن تنشأ المشاكل التالية:

عدم وجود اتصال مرئي بين
مهام العميل والمجموعة . عادةً ما توجد مهام العمل في الجدول ، ويتم فك تجميعها في Jira. عندما يكتب المطور طريقة API أخرى ، لفهم من سيستخدمها ، تحتاج إلى الذهاب إلى المدير والتوضيح مرة أخرى.
يشير
مصمم تحديد الأولويات غير الصحيح إلى الانتهاء المبكر من التخطيط (نعم ، هذا يحدث أيضًا). يسأل: ماذا تفعل بعد ذلك؟ النائب يحدد مهمة المشروع الرابع ، الأول على القائمة. في نهاية المطاف ، أدرك أن المهمة الرابعة من المشروع الأول كانت أكثر أهمية.
لا يوجد تمثيل مرئي لنطاق العمل
المهام في المشاريع المختلفة. لا أحد يريد إبقائها في الرأس أو البحث في الكتالوجات. من الأسهل ، عندما انتهيت ، أن أسأل: ماذا أفعل بعد ذلك؟
توزيع غير متساوٍ للحمل حسب الوقت والموظفين من
الواضح ما يفعله Vasya و Petya في الوقت الحالي ، فمن الصعب القول من سيكون مشغولًا بعد أسبوعين وما إذا كانت مهامهم ستكون متكافئة.
عند التخطيط لوقت الانتهاء ، لا تؤخذ المهام من المشاريع الأخرى بعين الاعتبار. لقد
طُلب منا تغيير الرابط على الموقع. إنه سهل ، لنفعل ذلك اليوم. ثم يتذكر المدير أن هناك أخطاء حرجة للغاية على موقع آخر. ونتيجة لذلك ، امتد التغيير في الرابط ، وفقًا للعميل ، إلى أن امتد الفريق لمدة أسبوع.

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

تحويل البطيخ

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

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

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

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

والحقيقة هي أنه من أجل تنفيذ الهيكل الصحيح ، من الضروري أن يكون لديك 3 مستويات من التعشيش ، Jira في وقت كتابة المقال لديه 2 + 1 (التاريخ والمهمة موجودة على نفس المستوى). +1 هي مهمة فرعية ، أنا لا آخذها في الاعتبار ، لأنها تحمل وظيفة المكمل بدلاً من التعشيش بسبب الافتقار إلى المرونة والالتزام القوي بالوالد.

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

التاريخ (الملحمي) في هذا الهيكل هو مهمة العمل (رغبة العميل). مهمة- إجراءات مفهومة لحل مشاكل العمل.

أيضا ، تم إضافة بعض العدادات والحقول إلى الكيانات. وأهمها مقياس لتقييم مدى تعقيد المهمة من 1 إلى 10 في الوحدات التعسفية (نقطة القصة).

إنشاء النظام

هناك بيانات ، فأنت بحاجة إلى تحديد الشكل وكيفية عرضها. لقد أنشأت مشروعًا مشتركًا للفريق وكتبت استعلام JQL لسحب المهام من جميع مشاريعنا إليه (يسهل إنشاء الاستعلام في قسم المشكلات). تمت إضافة لوحات Kanban والحالات التي تتوافق مع عمليتنا الفنية: Backlog → To Do → Doing → Review → Testing → Matching → Done.

تحولت الصورة التالية:

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

باستخدام نفس استعلام JQL مع المكون الإضافي BigGantt (أو أي برنامج آخر) لـ Jira ، يمكن عرض المهام في شكل مخطط Gantt. قم بتغيير المهلة الزمنية ، المواعيد النهائية ، تسجيل التبعيات ، انظر الحمل على فناني الأداء. طي المهام في التاريخ ، التاريخ في الملاحم ، أي تصور خريطة طريق أو خطة عمل مفصلة.

الجزء الإداري

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

بعد الاجتماع ، يتم تحديد أولويات المهام في الأعمال المتأخرة ، ويتم تعيين المنفذ ، ونقله إلى المهام. يقوم المطور بإنشاء فرع في BitBucket ، وتنتقل المهمة تلقائيًا إلى Doing. عند الانتهاء ، ينتقل "المطور" إلى المراجعة ، ينتقل الفنان إلى مطور آخر. إذا كان كل شيء على ما يرام ، يقوم "المراجع" بدمج والرمز موجود على خادم الاختبار. يرسل Jira المهمة إلى المختبر. بعد التحقق ، تقوم QA بنقله إلى المدير. هذا يظهر للعميل. العميل راضٍ - يتم إرسال الرمز إلى خادم المعركة تحت إشراف دقيق من اختبارات السيارات اليومية.

شكرا لمثل هذه الأتمتة ، وذلك بفضل مهندسينا devops. لقد قمت للتو بتكوين تغيير الحالات والمنفذين للأحداث من git. يتم ذلك في إعدادات العمليات التجارية ، إذا كنت تعمل ضمن النظام البيئي في Atlas. وعند استخدام GitLab و Bitrix ، سيتعين على Redmine العبث.

حلول

دعونا نرى ما تمكنا من تحقيقه:

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

الخطط

تم تخفيض بعض العمليات أو تشغيلها تلقائيًا ، ولكن بقيت الخطط في الكثير:

إعداد تقديرات لوقت ووقت المشاريع

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

التسويات التلقائية بين المديرين

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

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

مشاريع العجيل المتزامنة (تحت السجن) والشلال