في هذه المقالة ، سأتحدث عن بناء مهام سير العمل في قسم صغير لتطوير الشبكة. تم تشكيل القسم من البداية وبدأ على الفور العمل المستقل ، لذلك كان علينا أن نبني عمليات الإنتاج لوحدنا ، ونخطو على جميع أنواع المكابس ونستخلص النتائج اللازمة من هذا. على أمل أن يساعد ذلك شخص ما على توفير الوقت والمال والأعصاب ، سأصف المشكلات التي نواجهها وخياراتنا لحلها.
من المهم ملاحظة أن هذه ليست منهجية عالمية يمكن تنفيذها في أي فريق تطوير ، وسيكون كل شيء رائعًا على الفور. هذا مجرد مزيج من التقنيات المعروفة والخبرة العملية ، والتي تمكنا من التكيف بفعالية مع ميزاتنا التطويرية. لا يوجد حل واحد بسيط لهذه المشكلة. تحتاج دائمًا إلى الاعتماد على حجم وخبرة الفريق نفسه ، وخصائص العمل ، وخصائص المشاريع ، إلخ.
البيانات الأولية لقسمنا: فريق منتج صغير (5-10 أشخاص) ، موزع جزئيًا (يعمل بعض الموظفين عن بُعد ، بعضهم في المكتب) مع عملاء داخل الشركة. مشاريع الويب. لا يوجد أخصائيون في إدارة النظام داخل القسم ، ولكن هناك إدارات تشارك في الشركة.
فريق التواصل
لنبدأ ببناء تواصل فعال داخل القسم. في أي فريق ، من المهم بناء قنوات وطرق اتصال فعالة ، ولكن عندما يصبح الفريق موزعًا ، تزداد هذه الحاجة. وصلت إلى أقصى حد لها هنا لأن الفريق تم توزيعه جزئيًا فقط. كان علينا أن نتعلم دمج عوالم المكاتب والموظفين عن بعد.
القضية الأكثر أهمية التي واجهناها هي المناقشات اللفظية. يتمتع موظفو المكتب دائمًا بالإغراء للتعبئة السريعة لفنجان من القهوة ومناقشة حالة المشروع. ومع ذلك ، في هذه الحالة ، لن يكون العاملون عن بُعد قادرين على المشاركة في هذه المناقشة ، وبالتالي ، لن يكونوا قادرين على المساهمة بأفكارهم ، ولن يعرفوا حقيقة أن هناك شيئًا ما يحدث. وكقاعدة عامة ، ينتج عن هذا عدم التزامن في تصرفات الفريق ومناقشات متكررة بسبب ظهور أفكار ومقترحات جديدة من الجزء الموزع من الفريق وطعم غير سارة.
أصبح من الواضح أنه ينبغي مناقشة بعض الأشياء الشائعة المهمة كتابةً في الدردشات العامة أو في بعض المكالمات الجماعية.
يؤدي هذا إلى مشكلة أخرى شائعة جدًا تظهر في فرق تحتاج إلى كتابتها كثيرًا - مشكلة ثقافة الكتابة. لا يمكنك فقط الذهاب إلى زميل ، وسحب كمك ، ورسم شيء على منديل وإضافة إيماءات إلى قصتك. من ناحية ، يؤدي هذا إلى تعقيد العمل ، ومن ناحية أخرى ، يطور الناس مهارة كتابة أفكارهم بطريقة منظمة ومفهومة. كنتيجة لهذا النهج ، بدأت الوثائق تصبح رسمية بشكل أفضل ، وبدأت صياغة المهام بشكل أكثر وضوحًا ، وبدأ الجميع في التفكير في كيفية تقديم أفكارهم بطريقة كانت مفهومة للآخرين من القراءة الأولى.
كل ما سبق لا يعني أننا تخلينا تمامًا عن الاتصالات الشخصية والمكالمات الصوتية والمرئية. ومع ذلك ، فقد جعلنا من هذه القاعدة تسجيل نتائج هذه المناقشات كتابةً ، كنوع من المعرفة الفنية ، متاحة دائمًا للجميع.
انظر بإيجاز إلى قائمة الأدوات الشائعة التي حللنا بها مهام الاتصال الخاصة بنا داخل الفريق.
أولاً ، بدأنا الدردشة على Telegram. ولكن بعد ذلك ، فيما يتعلق بنمو الفريق ، أدركنا أننا في دردشة واحدة كنا قريبين بالفعل ، وانتقلنا إلى سلاك. هناك قمنا بتقسيم التدفق العام إلى قنوات مواضيعية ووضع قواعد واضحة - لأي أسباب تكتب إلى أي قناة. هذا ساعد على تجنب خلط المعلومات المفيدة والفيضانات.
بالإضافة إلى ذلك ، أتاح لنا التحول إلى Slack بعض الفرص الرائعة للتشغيل الآلي والتكامل مع الخدمات الأخرى ، مثل نظام إدارة المستودعات أو متعقب الأخطاء.
- مكالمات الصوت والفيديو - Skype for Business.
- نقوم بتنفيذ المهام في جيرا.
- يتم تخزين قاعدة المعرفة في التقاء.
تخطيط المهمة والتنفيذ والسيطرة
عندما أنشأنا اتصالات ، أصبحت مشكلة إعداد المهام والتحكم فيها وإكمالها داخل الفريق مهمة (سأتحدث عن العمل مع العميل في هذا الصدد بعد ذلك بقليل).
لم يكن لدينا قائمة واحدة من المهام ، وأولوياتها ، وحالة الاستعداد ، وما إلى ذلك. وبدلاً من وجود خطة واضحة وشفافة ويمكن تتبعها ، كان التخطيط والتنفيذ التلقائي على المدى القصير حاضرين.
للتعامل مع هذا الموقف ، بدأنا في استخدام bugtracker (في الواقع ، حاولنا خمسة منهم). بدأت تظهر الخطوط العريضة للتوجه العام للمشروع ، وفهم للحالة التي ظهرت فيها مهام معينة والصورة الكلية ككل. ومع ذلك ، واجهنا مشكلة عدم الانضباط عند استخدام bugtracker ، والتي بدأت تقلل من قيمة الكثير من مساعينا. لم يتم بدء جميع المهام في bugtracker ، ولم يتم تحديث المهام الحالية دائمًا ، إلخ. ببساطة ، لم تعد صورة حالة المشروع وثيقة الصلة وموثوقة.
لمكافحة هذا ، قمنا بتطوير وتنفيذ ثقافة إدارة المهام الخاصة بنا:
- يجب عدم تنفيذ العمل حتى تبدأ المهمة المقابلة. هذا يساعد على مواكبة تاريخ المشروع وعمل الفريق.
- عند العمل مع مهمة ، من الضروري تغيير حالتها في الوقت المناسب. في حالتنا ، هناك أربع حالات تكفي: "المهمة" - حالة بدء المهمة ، "قيد التقدم" - المهمة قيد التنفيذ ، "قيد الانتظار" - المهمة التي بدأوا في أدائها ، ولكن تم تعليق العمل (نحن في انتظار بعض المعلومات الإضافية ) ، "تم" - المهمة جاهزة. يجب تأكيد استعداد المهمة بطريقة أو بأخرى من قبل العميل أو المدير داخل الفريق.
- بمرور الوقت ، زاد عدد المهام والمشاريع بشكل كبير ، لذلك قمنا بتقسيم القائمة العامة للأعمال إلى مشاريع فرعية منفصلة ، ويجب أن تبدأ المهمة وفقًا لقائمة المشاريع الفرعية هذه.
- المهمة يجب أن تعطى الأولوية. يساعد هذا في فهم المهام في أي ترتيب مطلوب من أجل تحقيق أقصى فائدة للمشروع.
- مراجعة المهام بشكل دوري وأولوياتها. نظرًا لأن المشاريع تعيش وتتطور ، وخطط العمل تتغير أحيانًا ، بمرور الوقت ، تصبح بعض المهام أقل أو أكثر أهمية أو حتى تتطلب إزالتها.
- تتطلب بعض المناقشات الرئيسية حول المهام التي تم تنفيذها شفهياً أو كتابيًا في الدردشة إصلاح الحل النهائي في المهمة نفسها ، بحيث عندما نكملها نرى دائمًا المعلومات الأكثر صلة بها وتاريخها. يحدث غالبًا أن يتحول البيان الأولي للمشكلة بعد سلسلة من المناقشات إلى شيء مختلف تمامًا ، ونحن بحاجة إلى مراقبة ذلك.
- إذا تم نقل المهمة من مجموعة من المتخصصين إلى مجموعة أخرى داخل الفريق ، فيجب أن تقوم المجموعة المنقولة بإصلاح جميع الأدوات الفنية اللازمة للمعرفة والتي يجب نقلها إلى المجموعة التالية. على سبيل المثال ، يجب على فريق التصميم إرفاق النماذج وجميع الوثائق اللازمة للتطوير قبل نقل المهمة إلى فريق التطوير. هذا يتجنب الأسئلة غير الضرورية والتشتيت ومفاتيح السياق.
- ربط تلتزم المهام. باستخدام بعض القواعد الخاصة بتسمية الأسماء ، نعلق تلقائيًا روابط إلى مهام GitLab. يساعد هذا بشكل كبير في التطوير لفهم من وماذا وكيف ومتى هذه المهمة. وفي الاتجاه المعاكس ، من خلال التعيينات المسماة بشكل صحيح ، يمكنك دائمًا العثور على مهمة تحتوي على سبب التغييرات التي تم إجراؤها.
اتصالات العملاء
الفئة التالية من الصعوبات التي نحتاج إلى حلها كانت العمل مع العملاء. أول شيء كان علينا القضاء عليه هو وضع الكلمات بالكلمات. إذا قدمنا ثقافة الكتابة داخل القسم ، فقد حان الوقت لتوسيع نطاقها ليشمل جهات الاتصال الخارجية.
ليس سراً أن مديرًا آخر يحب الاقتراب من المطور ، وبكلمات أخبره بما يجب القيام به ، لكز الأصابع على الشاشة للإقناع والمغادرة ، على أمل أن يتم كل شيء بشكل جيد وفي الوقت المحدد. في هذه الحالة ، يمكن استبدال المدير والمطور بمالك منتج ومدير معين لفريق التطوير الذي يقود كل هذه المهام. نتيجة هذا لن تتغير.
هناك العديد من المشاكل مع هذا النهج:
- سيتم نسيان ما يقال بالكلمات والإيماءات (جزئيًا على الأقل) عن الغد ، في أحسن الأحوال ، بعد غد. لا يتعلق الأمر ببعض الأشياء الصغيرة ، بل يتعلق بخطر النسيان التام للمهمة. في الوقت نفسه ، من المستحيل التأكيد بأي طريقة على وضعه لشخص ما أو أن شخصًا ما وعدك بعمل شيء على الأقل.
- عادة ، يكون مثل هذا البيان للمشكلة فوضويًا إلى حد ما ، ولا توجد تفاصيل عميقة فيه. نتيجة لذلك ، من الصعب للغاية توضيح المعلومات المفقودة.
- كما نوقش سابقًا ، فإن بيان المشكلة بالكلمات ينغمس في إحجام الفساد عن تعلم صياغة أفكارهم في الكتابة بحيث يفهمها الآخرون.
عندما يكون لديك العديد من العملاء ، ولكل منهم خصائصه الخاصة ، يكون من الصعب بناء ترتيب واحد للعمل مع الجميع. من الناحية المثالية ، نود أن نجلب جميع العملاء إلى متعقب الأخطاء ، حيث يمكنهم تعيين المهام وتحديد الأولويات ومناقشة التفاصيل وقبول العمل. لكن هذه تبقى مهمة مستحيلة. ومع ذلك ، تمكنا من إيجاد حل وسط تتدفق فيه المهام معًا في تدفق مكتوب بدقة إلى قسم بريد الشركة ، ومن جانبنا يبدأ المدير ويقودهم بشكل أكبر في تعقب الأخطاء وفقًا للقواعد التي تم وضعها بالفعل في بلدنا. توقفت المهام عن الضياع أو نسيانها أو تخزينها في عقول أشخاص محددين ، تمت مناقشتها من خلال التكوين غير الكامل للمتخصصين المطلوبين ، إلخ.
بعد ذلك ، واجهنا مشكلة واحدة أكثر أهمية: من الصعب على العميل صياغة مهمة. لا يكون العميل دائمًا مؤهلًا بما يكفي (أو بالأحرى ، غير مؤهل دائمًا بشكل كافٍ) في صياغة المواصفات الفنية للفريق الفني. وهذا طبيعي. لا يمكن تجاهل العامل البشري: قد يكون من المألوف أن يشعر العميل بالحرج والراحة عند طلب الفريق عندما يكون هو نفسه غير قادر على صياغة الأمر بالكامل. يتمثل أحد معايير الفريق المهني الناضج في القدرة على مساعدة العميل في تحديد مشاكله ومتطلباته وحلوله.
يحدث غالبًا أن العميل ، بدلاً من مواجهة مشكلة ، يأتي مع طلب لتنفيذ الحل الذي اخترعه بالفعل. من أجل عدم مفاجأة أنفسنا أو الزبون بنتائج العمل على ToR الموضوعة على "منديل" ، أنشأنا قائمة مرجعية أساسية من الأسئلة للعميل. بالفعل على أساس هذه الإجابات ، من الأسهل على كل من العملاء فهم ما يريده حقًا وفريق التطوير ما هو مطلوب منه. ثم جاء دور بعض الأسئلة الموضحة لتوضيح المتطلبات أو تحديدها.
لذا ، قبل الاجتماع الأول مع العميل ، نطلب منك أن تملأ مسبقًا (قدر الإمكان) وترسل لنا قائمة المراجعة هذه حتى لا تضطر بعد ذلك إلى إضاعة الوقت في الأسئلة نفسها ، ولكن البدء فورًا في حوار مثمر. تجدر الإشارة إلى أنه عند التفاعل مع العميل ، من المهم ليس فقط توضيح الإجابات التي قدمها ، ولكن أيضًا على أساس مشكلته المعلنة لمساعدته في تحديد تلك المتطلبات التي ربما لم يفكر بها.
قائمة الأسئلة للعميل:
- ما هو الغرض من المشروع؟ ما المشكلة هل هذا حل؟ ما قيمة الأعمال التجارية التي تحملها؟
- هل هذا هو الحل الوحيد الممكن لهذه المشكلة؟ إذا لم يكن كذلك ، فما هي الخيارات الأخرى المتاحة؟
- هل هناك أي متطلبات عامة تمر بالمشروع بأكمله؟ على سبيل المثال ، إذا كان متجرًا عبر الإنترنت ، فيجب عليه الامتثال التام للتشريعات التي تحكم التداول عبر الإنترنت.
- هل هناك أي متطلبات وظيفية؟ ماذا يجب أن يفعل القسم (الصفحة ، المشروع)؟ على سبيل المثال ، يجب أن يقدم القسم معلومات حول منتجات الشركة ، ومن خلال النموذج الموجود على الصفحة ، جمع أولئك الذين يرغبون في طرح أسئلة حول هذا المنتج أو الحصول عليه.
- هل هناك متطلبات غير وظيفية؟ كيف جيدا يجب أن يفعل هذا؟ على سبيل المثال ، يجب ألا يزيد وقت فتح الصفحة عن 5 ثوانٍ.
- متطلبات إضافية. تنسيق مجاني يمكنك من خلاله إسقاط الروح.
مشكلة أخرى كان علينا مواجهتها: المهام القادمة من جميع الأطراف في وقت واحد. عندما يكون هناك العديد من العملاء في مشاريع مختلفة ، عندها يريد الجميع إعطاء مهمته الأولوية القصوى. في الحالة المثالية العامة ، على الأرجح ، لا يمكن حل هذه المشكلة بنسبة 100٪. كيف نعيش مع هذا؟ مع إدخال الانضباط في صياغة وإدارة المهام ، وكذلك بعض عناصر منهجيات Agile ، أصبح مجمع المهام الخاص بنا أكثر انسيابية وشفافية للمراقب الخارجي ، والأهم من ذلك أنه يمكن التنبؤ به. لقد أنشأنا النظام والخطط ضمن فريقنا ، ونحن بحاجة فقط إلى تعزيز التعليقات مع العملاء. عند مناقشة الأولويات والمواعيد النهائية والخطط ، تعلمنا كيفية بناء حوار جدلي ، بدلاً من رمي أنفسنا بشكل أعمى في المهام وإطفاء الحرائق المشتعلة باستمرار (وهي في الواقع ليست ذات صلة دائمًا وليست دائمًا حرائق).
حاولنا أيضًا القضاء على "إدارة طيور النورس" التقليدية في إطار هذه الفقرة ، عندما سافر عميل أو مدير إلى "وضع" المهام - وحلقت بثقة تامة أنه بمجرد تعيينه للمهمة ، سيحصل بالتأكيد على نتيجة ممتازة. كما أظهرت الممارسة ، فإن النتيجة مع هذا النهج لم تكن الأكثر إثارة للإعجاب. كيف تتعامل معها؟ هنا ، أيضًا ، لا توجد نصيحة عالمية ، ولا عبارة سحرية تغير سلوك الناس. للقيام بذلك ، تحتاج إلى التحدث ، تثقيف ، شرح ، إظهار ، يمكنك القول تثقيف. فقط العمل التربوي وإما الأمثلة المرئية للغاية أو القابلة للقياس (والأفضل على حد سواء) الإيجابية والسلبية سوف تساعد على التغلب على "إدارة طيور النورس" بما فيه الكفاية.
ديف مقابل العمليات
والقضية المهمة الأخيرة لدينا هي مشكلة التواصل بين إدارتي Dev و Ops.
إننا نواجه موقفًا كلاسيكيًا حيث لا يفهم المطورون جيدًا كيفية عمل الخادم ، ولا يفهم فريق المشرف التابع لجهة خارجية كيفية عمل التطبيق. أعطيت لنا كل صعوبة في تقاطع هذين المجالين مع الألم والكثير من الوقت. كان من الصعب حتى تشخيص أي جانب من المشكلة:
- لقد برمجته هناك!
- لا ، هناك لديك شيء مع الخادم هناك!
في هذه الحالة ، ساعدنا ظهور مطور في الفريق الذي كان على دراية جيدة بالإدارة. كان قادرا على التحدث مع كل مجموعة بلغتها وتشخيص كل مشكلة من كلا الجانبين. بدأت التناقضات في الانخفاض ، لكن بقينا مرتبطين بهذا الرجل. لإلغاء ربط كل هذه المشكلات بنفسه ، بدأ في مساعدة المسؤولين على فهم كيفية عمل التطبيق والمبرمجين - ما يحدث على الخادم. نضيف إلى شرح وثائق الكتابة الصوتية ، ولا نحصل فقط على معرفة الفريق بأكمله ، ولكن أيضًا على العمل الأكثر تنسيقًا لإدارات Dev and Ops. نعم ، يوجد في أقسام كبيرة من المشروع الدموي فرق خاصة وأشخاص مؤهلون يقومون بإعداد كل شيء حتى لا يعرف المطورون كيف وأين يعمل عملهم على الخادم. ومع ذلك ، سيكون من الجيد تطوير هذا المستوى من الكفاءة لدى الأفراد في فرق صغيرة ، بالإضافة إلى وجود موظف واحد على الأقل متطور بالفعل في هذا الصدد.
تصميم
بالتوازي مع كل هذه ، أخذنا تطوير ثقافة التنمية.
لن أركز على الجزء الفني ، والآن أصبح بالفعل معيارًا بحكم الواقع ويفتقر الجميع تقريبًا إلى مدى الحاجة إلى نظام تحكم في الإصدار و CI / CD وأدوات تطوير وتجميع ونشر أخرى. سوف أتطرق فقط لحظات لينة من التنمية.
- Codestyle. من المهم جدًا تطوير قواعد تصميم الأكواد والموافقة عليها صراحةً. أولاً ، من الجميل من الناحية الجمالية رؤية نظرة واحدة متجانسة في المشروع ، بدلاً من حديقة للحيوانات ذات الأساليب والمعايير المختلفة. ثانياً ، إنه يزيد من قراءة الكود ، وكما نعلم ، في معظم الأوقات لا يكتب المبرمج شفرته ، لكنه يقرأ شخصًا آخر.
- تسمية يرتكب . قدمنا قواعد معينة لالتزامات التسمية ، بحيث كان من الواضح باسم التغييرات ما هي التغييرات التي تم إجراؤها ومن قام بذلك وضمن أي مهمة.
- مراجعة الكود . تفاصيل مشاريعنا والفريق هو أننا لا نملك بعضًا من مراجعة الكود الإلزامي ، والتي بدونها من المستحيل ضخ كودنا في الإنتاج. ومع ذلك ، فقد جعلنا من القواعد أن ينظر شخص واحد على الأقل إلى الكود الذي يدفعه زميل. يساعد هذا كلاهما على ملاحظة أي قصور ، وتقديم أفكار بديلة ، ومواكبة جميع أجزاء النظام. أصبحت مراجعة الكود ذات صلة خاصة بزيادة عدد المشاريع وتعقيدها ، ولهذا السبب لم يعد لدى كل مطور الوقت الكافي للعمل على جميع المشاريع بما يكفي لفهم جميع تفاصيلها.
- محاذاة الهندسة المعمارية داخل الفريق في وقت مبكر . يحدث غالبًا أنه في محاولة لإنشاء ميزة بشكل أسرع ، تبدأ الواجهة الأمامية في القيام بشيء خاص بها ، حيث تبدأ الواجهة الخلفية بسرعة خاصة بها ، ثم يتضح أنها تتكامل بصعوبة كبيرة أو لا تتكامل على الإطلاق. في تطوير الميزات الكبيرة ، نناقش بشكل مشترك في الهندسة المتقدمة ، تنسيقات تبادل البيانات ، وما إلى ذلك. ونتيجة لذلك ، لم يعد التكامل طويلًا ومؤلماً.
- السيرة الذاتية التنمية مدفوعة . هذه مشكلة يقوم فيها المطورون بسحب تقنيات جديدة (حديثة وعصرية وذات رواتب عالية) إلى المشروع ليس من أجل المشروع ، ولكن من أجل وضع علامة في السيرة الذاتية. نحن منفتحون على التقنيات الجديدة ونحاول تطوير مشاريعنا من الناحية التكنولوجية ، ومع ذلك ، من المهم الحفاظ على التوازن الذي سيحدث فيه تقدم تكنولوجي ومشاريع مكتملة بنجاح في إطار زمني معقول. هناك شيئان مهمان في هذا الموضوع الزلق: ألا يدفع العميل المواعيد النهائية حتى لا يكون لدى المطورين استراحة ، وأن فريق التطوير (أو ، على الأقل ، قائد الفريق المختص أو الفريق الفني) لا يهتم فقط بتطوير ملف تعريف LinkedIn الخاص بهم ، ولكن أيضًا بشأن رفاهية المشروع بشكل عام.
إعادة بيع الديون ، الدين التقني ومبدأ التحسين المستمر
بدأ قسمنا بالتشكيل حول أسطول من المشاريع التي قام بها متعهدون خارجيون. بطبيعة الحال ، لم تكن هناك وثائق هناك ، ولم يتبع أي شخص أهمية وجودة الشفرة. نظرًا لأننا أدركنا أنه لا يزال يتعين علينا العمل والحفاظ عليه وتطويره لفترة طويلة ، فقد تقرر تخصيص جزء من الوقت لترتيب الأمور في المشروع - إعادة البناء ، وحذف الكود غير ذي الصلة ، إلخ.
منذ أن كان المشروع كبيرًا ، كان مستوى الانتروبيا مرتفعًا أيضًا. لقد أدركنا أنه في إحدى الجلسات ، من المستحيل التغلب على كل شيء ماديًا ، والتخلي معنوياً عن احتمال هذه الوظيفة الضخمة. قررنا تطبيق المبدأ الياباني للتحسين المستمر "كايزن". نقوم بتقسيم الدين الفني إلى العديد من الأجزاء الصغيرة شيئًا فشيئًا ، لكننا أغلقت هذه الأجزاء الصغيرة بانتظام ، ونعدل باستمرار كل من المشروعات وعمل الفريق نفسه وتحسينه.
أخلاقيا ، هذا لم يسبب أي إزعاج ، ولكن في الوقت نفسه لم يكن له تأثير كبير على تطوير وظائف جديدة وتغطية متطلبات العمل. بعد عام ونصف ، وجدنا أن الدين التقني القديم قد تم تسديده بالكامل ، مما أتاح لنا فرصًا لتطوير وظائف مستوى جديد من التعقيد والأهمية.بالطبع ، هذا لا يعني أنه ليس لدينا الآن ديون فنية. بينما تعيش المشاريع وتتطور وتنمو وتتطور ، فمن المؤكد أنها تتراكم. ومع ذلك ، فإننا نراقبها بعناية ، ونضعها في مجموعة خاصة من المهام ، ونخصص بعض الوقت بانتظام لسدادها. يسمح لنا هذا العمل المستمر بالديون الفنية بإيجاد توازن بين تطوير وظائف جديدة ودعم عالي الجودة للمسنين.في حالتنا ، تمكنا نحن ، المطورين ، من توضيح وإظهار أهمية تسديد الديون الفنية للشركات. كيف فعلنا هذا؟ في الممارسة العملية ، لقد أظهرنا مواقف ، إذا لم تقم بإعادة تشكيل أو إجراء بعض التغييرات الهيكلية الأخرى على المشروع الحالي ، فسيكون تطوير وظائف جديدة أو تغيير الوظيفة القديمة مستحيلًا من حيث المبدأ (أو ممكن ، ولكن عدة مرات أبطأ).تنفيذ منهجيات رشيقة
سمح لنا تنفيذ بعض أفكار منهجيات Agile بزيادة شفافية عملنا داخل الفريق وللأعمال ، لجعل التطوير أكثر قابلية للتنبؤ ومرونة ، والنتيجة أكثر استقرارًا.أول شيء فعلناه هو تنظيم المواقف اليومية داخل الفريق. نظرًا لتوزيع الفريق ، خصص سلاك قناة منفصلة لهذا ، حيث يكتب كل موظف ثلاث نقاط كل صباح: ما هي المهام التي عمل عليها أمس ، وما يخطط للعمل عليه اليوم ، هل هناك أي مشاكل تعرقل عمله. يحظر حدوث فيضان في هذه القناة ومناقشة مهام أو مشكلات شخص ما. هذه القناة مخصصة حصريًا لتجميع المعلومات حول الحالة. يجب إجراء المناقشات المتبقية في القنوات المواضيعية المناسبة. سمح هذا لكل شخص في الفريق بفهم ما يفعله زملاؤه ، وما يحدث في المشروع بشكل عام ، ومن يمكنه وينبغي مساعدته. إذا تم إيقاف المشكلات دون توقف ، وبعد فترة طويلة تبين فجأة أن المهمة لم تكن جاهزة بعد ، فمن الواضح الآن من يحتاج إلى المساعدة ،ما يجب القيام به لجعل فريق العمل أكثر فعالية.بعد ذلك ، قررنا تطوير سرعات. كل يوم جمعة في نهاية اليوم ، نجري بأثر رجعي بأثر رجعي ، وننظر في المهام التي تم التخطيط لها ، وما هو جاهز ، وما هو غير جاهز ، وإذا كان هناك شيء غير جاهز ، فلماذا حدث ذلك. نفكر في المشكلات التي لدينا وما الذي يمكننا فعله لتجنب الصعوبات المماثلة في المستقبل. ثم نخطط لسباق سريع للأسبوع المقبل بناءً على عبء العمل في المجالات المختلفة داخل الفريق وأولويات العمل. نتيجةً لذلك ، في بداية الأسبوع ، يعرف جميع المطورين ما يجب القيام به وبأي ترتيب ، ويعرف رجال الأعمال ما ستتم تغطية احتياجاته في المستقبل القريب ، ويمكنهم بالفعل تشكيل "قائمة الأمنيات" الخاصة به للسباقات المقبلة. تجدر الإشارة إلى أننا لسنا بمنأى عن المهام المفاجئة التي قد تعطل خطط العدو.في هذه الحالة ، تحتاج إلى التصرف على أساس الطبيعة المحددة للعمل: كم مرة تنشأ مثل هذه المهام؟ كم؟ هل يمكن التنبؤ بهذا؟ في حالتنا المحددة في التطوير ، قمنا بحساب التجربة كم من الوقت في المتوسط يقع على المهام غير المخطط لها ومحاولة وضع هذا الهامش في سباق السرعة. بشكل منفصل ، تجدر الإشارة إلى أنه بعد بدء العمل في سباق السرعة ، تمكنا من معرفة بالتحديد مقدار العمل الذي تم تسليمه إلينا على مدخل غير مجدول ، وتحليل هذا المبلغ وتقليله ، ومناقشة الأولويات بعناية مع العميل وإظهار بوضوح كيف تؤثر الرغبة الفورية في الحصول على الميزة الأكثر أهمية في الوقت الحالي على الإنتاجية الإجمالية للفريق بأكمله.ما هو متوسط الوقت للمهام غير المخطط لها ومحاولة وضع هذا الهامش في العدو. بشكل منفصل ، تجدر الإشارة إلى أنه بعد بدء العمل في سباق السرعة ، تمكنا من معرفة بالتحديد مقدار العمل الذي تم تسليمه إلينا على مدخل غير مجدول ، وتحليل هذا المبلغ وتقليله ، ومناقشة الأولويات بعناية مع العميل وإظهار بوضوح كيف تؤثر الرغبة الفورية في الحصول على الميزة الأكثر أهمية في الوقت الحالي على الإنتاجية الإجمالية للفريق بأكمله.ما هو متوسط الوقت للمهام غير المخطط لها ومحاولة وضع هذا الهامش في العدو. بشكل منفصل ، تجدر الإشارة إلى أنه بعد بدء العمل في السباقات ، تمكنا من معرفة بالتحديد مقدار العمل الذي يتم تسليمه إلينا على مدخل غير مجدول ، وتحليل هذا المبلغ وتقليله ، ومناقشة الأولويات بعناية مع العميل وإظهار بوضوح كيف تؤثر الرغبة الفورية في الحصول على الميزة الأكثر أهمية في الوقت الحالي. على الإنتاجية الإجمالية للفريق بأكمله.كيف تؤثر الرغبة الفورية في الحصول على ميزة غير ضرورية في الوقت الحالي على الإنتاجية الإجمالية للفريق بأكمله.كيف تؤثر الرغبة الفورية في الحصول على ميزة غير ضرورية في الوقت الحالي على الإنتاجية الإجمالية للفريق بأكمله.انتقلنا أيضًا من الإصدارات الطويلة إلى الإصدارات القصيرة. في السابق ، تلقينا مجموعة المعارف التقليدية أو الأسابيع أو الأشهر التي قدمت حزمة كاملة من الميزات ، وعندها فقط أظهرها للعميل. كنتيجة لذلك ، غالبًا ما تبين أن العميل إما غير رأيه أو لم يتوقع ذلك تمامًا ، وبدأنا في إعادة كل أو جزء مما فعلناه بالفعل. ولإجراء تغييرات على مجموعة كبيرة من الميزات الجاهزة يعد أمرًا مريبًا. نعرض الآن كل ميزة في أقرب وقت ممكن حتى يتخذ العميل قرارًا - ما إذا كان هذا هو ما يريده حقًا ، أو يجب تغيير شيء ما. كلما وافق أو أرسلها للمراجعة بشكل أسرع ، قل حجم العمل الذي سنستثمره ، وبالتالي ، كلما أصبحت الميزة أسرع في الإنتاج. ونتيجة لذلك ، بدأت الميزات تصل إلى الإنتاج بشكل أسرع ، وتم اختبار الفرضيات بشكل أسرع ، وتم تنفيذ المشروع بشكل أسرع.عامل الحافلة
نظرًا لأن فريقنا صغير ، فقد بدأنا على الفور في التفكير في المشكلات التي قد نواجهها أثناء تناوب الموظفين. أصبح أشخاص معينون هم الوصاية الوحيدة على بعض المعرفة ، وقد توسعت المشاريع بشكل كاف ، وبالتالي بدأنا في تطوير ثقافة تخزين المعرفة وإدارتها.وقد ساعد القضاء على هذه المشكلة من خلال تراكم المصنوعات المعرفية التي انتقلت من رؤوس أشخاص محددين إلى العالم المادي المكتوب. وهي:- يتم تنفيذ جميع الأعمال فقط إذا كانت هناك مهمة في bugtracker. هذا يسمح لك بعمل سجل كامل للتغييرات في المشروع.
- إذا ناقشنا التغييرات في المهمة في مكان ما في الدردشة أو في التجمع ، فيجب علينا أن نعكس في هذه المهمة في هذه المهمة نفسها نتيجة هذه المناقشة.
- . , Gitlab. , .
- Confluence , - , .
- - postmortem « — — — ».
لا تزال هناك ممارسة جيدة ، والتي ، بطبيعة الحال ، تحتاج إلى معرفة التدبير وليس رفعه إلى المطلق: إذا سئل عن جزء من النظام الذي تعرفه فقط ، فمن المستحسن أن تكتب وثائق حول ذلك والرد مع وصلة لذلك. لذلك لن تضطر أبدًا إلى الإجابة عن هذا السؤال مرة أخرى ، وطرح أسئلة على أشخاص آخرين.ساعدتنا طريقة الحفاظ على الآثار الفنية بشكل متكرر في العثور على معلومات حول تلك الأجزاء من المشروع التي قد تضيع بالضرورة. كما قلل بشكل كبير من مخاطر المشروع والفريق أثناء تناوب الموظفين. المثال الأخير: استردنا بسرعة وسهولة المعلومات المتعلقة بمنطق العمل ، ومبدأ التشغيل وطريقة نشر الأداة ، التي قام بها الموظف الذي ترك عمله منذ عامين.إذا قمنا بتطبيق العمل باستخدام المواقف الاحتكاكية والسباقات على هذه التقنية ، فسيتم تقليل عامل الناقل بدرجة أكبر. منذ وقت ليس ببعيد ، أجرينا تجربة: كان هناك مطور في إجازة ، وعمل مطور آخر. في تلك اللحظة ، عندما ذهبت الأولى في إجازة ، ذهبت الثانية في إجازة. لم يكن جوهر التجربة هو كتابة أي رسائل ورسائل توضيحية توضيحية ، وليس تسليم القضية ومعرفة مدى صعوبة الشخص بعد إجازة طويلة لفهم ما كان يحدث في غيابه ، وما الذي تغير ، وكيف بالضبط ، وما هي خطط المستقبل. كما أوضحت الممارسة ، فإن عرض bugtracker ، والتعهدات ، والتوثيق ، والمواقف ، والإسراع في العمل سمحت للموظف بالدخول إلى مسار العمل بسهولة تامة ومواصلة عمله بشكل مستقل.استنتاج
في الختام ، أود أن أشير إلى أنه لم يتم حل أي من المشكلات المذكورة أعلاه على الفور وبدون أخطاء. التغيير التنظيمي هو دائما عمل طويل ومنهجي. لا يمكنك قول "نحن الآن نفعل هذا" ونأمل أن يكون كل شيء مختلفًا الآن. أي قرارات تتخذها ، وأي أحداث تنظمها ، تتطلب تحكمًا وتدريبًا وتنويرًا للأشخاص ، ووقتًا لتكييف الفريق مع الأساليب الجديدة ، والأساليب نفسها مع موقف معين. وألاحظ أيضًا أن فرض منهجية على الناس هو عملية شاقة للغاية وغير فعالة. سوف يستريح الناس ، ينسون ، ربما تخريب.لكي تبدأ التغييرات المطلوبة في الفريق ، يجب أن يرغب الفريق نفسه في إجراء هذه التغييرات. من الضروري مراقبة كيفية عملها وتحديد مجالات المشكلات ، وإدراك هذه المشكلات ، وإيجاد الحلول ، ثم تنفيذها. بالطبع ، ليس كل عضو في الفريق يجب أن يفعل ذلك ويريد القيام بذلك ، ولكن إذا كان هناك شخص رأى هذه المشكلات وتوصل إلى حلولها ، فسيقوم أولاً بتنوير الفريق.شارك معلوماتك وملاحظاتك وتجربتك وجادل وأظهر وأثبت أين توجد المشاكل الآن وما هي الخطوات التي يمكن اتخاذها لحلها. وبهذه الطريقة فقط يمكن إجراء التحولات التنظيمية الرئيسية بأكبر قدر ممكن من الكفاءة. حتى لو كنت قائدا وتريد دفع موقفك وقرارك - حاول أن تفعل ذلك بشكل مقنع ومقنع قدر الإمكان ، وبالتالي توفير الوقت في التنفيذ وإنقاذ الفريق من السلبية غير المرغوب فيها.بقلم إيفجيني أنتونوف ، رئيس مجموعة تطوير التقنيات الإيجابية