وحده في الميدان ليس محاربًا. الطريق إلى العمل الجماعي الفعال

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

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



فقط حول هذا فك تشفير تقرير Evgeny Fedoreev على TeamLead Conf . في التقرير ، وصف يوجين على مراحل عملية تنظيم فريق تطوير فعال في Banki.ru: التوظيف والتواصل وتبادل المعرفة وتطوير المطورين والمختبرين داخل الفريق والقسم.


حول المتحدث : شارك Evgeny Fedoreev ( hardj ) في تطوير الويب لمدة 15 عامًا ، 6 منهم في منصب قائد الفريق ، وهو الآن يقود تطوير مشاريع جديدة في Banki.ru.

ما هو Banki.ru؟

سياق الشركة هو معرفة التجربة التي سيتم مناقشتها. Banki.ru هو أكبر بوابة مالية مستقلة لـ Runet مع جمهور شهري بأكثر من 8 ملايين مستخدم فريد.

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

المهمة الرئيسية لفريق التطوير

عند التحضير للتقرير ، سألت الناس سؤالًا:

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

الكفاءة التنموية

مفهوم الكفاءة شيء للمدير ، وآخر للمطور.

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

بالنسبة للمطور ، يعمل هذا مع دين تقني . هذا هو أحد الآلام منذ العمل مع هؤلاء. الدين ، لإعادة الهيكلة ، للتصحيحات والتحسينات تعطى القليل من الوقت.

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

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

أي معايير أخرى لكل فريق.

عملية التنمية

بدأنا في بناء عمليات التطوير في Banki.ru بعد أن بدأت الشركة في التطور والنمو. ظهر شركاء ومشاريع جديدة ، ولم يكن 6-9 مطورين خلفية كافيين. لقد وصلنا إلى استنتاج أننا بحاجة إلى بناء عملية التنمية وإضفاء الطابع الرسمي عليها للعمل الفعال.

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



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

في عالم مثالي ، يجب أن تبدو عملية التطوير على هذا النحو.

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

اقترحنا أن العالم ليس مثاليًا ، وأن QA سيعيد المهام ، نظرًا لأن الأخطاء موجودة في أي تطور ، وأضفنا سهمين آخرين.



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

لقد تغير مخططنا. تقفز المهام مثل الكرة في كرة الطاولة: من ضمان الجودة إلى الأمام والخلف للمطورين ، وحتى الوصول إلى المديرين.



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

كيف تقلل من وقت التسليم؟

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

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

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

لقد جربنا كل الحلول. ونتيجة لذلك ، تم تقليل الوقت ، ولكننا لم نكن سعداء.

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

فريق الميزة

هذا عندما يكون لدى الفريق مجموعة كاملة من الأشخاص لإكمال المهمة:

• المطورين الخلفية.
• المطورين الأماميين.
• مطورو ضمان الجودة.

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

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

مشكلات فريق الميزة

في ذلك الوقت ، كان لدينا 6 مشاكل.

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

هناك مشاكل ، سنقوم بحلها.

عامل الناقل

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

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

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

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

التخطيط الطويل

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

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

لقد قمنا بدعوة المديرين لوصف المهام بمزيد من التفصيل ، ولكن ليس كثيرًا حتى لا نتعمق في الكثير من الوثائق.

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

سباقات السرعة المغلقة

هذا ألم. ربما قام أحدهم بإغلاقهم ، ولكن معنا في ذلك الوقت - لا.

قررنا تقليل سعة العدو من 10 أيام عمل إلى 8 . كنا نظن أننا نخطط لمدة 8 أيام ، ونترك المختبرين لمدة يومين.

في الواقع ، اتضح أنه عندما يرى المطور مهامًا أقل ، فإنه يؤديها ببطء. 20 ٪ أقل من المهام في العدو لم تقدم أي شيء.

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

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

الدرجة! ذهبنا إلى المديرين لبيع هذه الفكرة:

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

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

اتضح أن المطورين يمكنهم القيام بالكثير من الأشياء عندما يكونون أحرارًا.

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

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

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

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

طبيعة المهام المختلفة للفرق

لدينا فرق منتجات تقوم بشيء جديد. لديهم تخطيط لمدة أسبوعين ، وسباقات سريعة ، ومشاريع طويلة ويأتون للإفراج عنها في 1-2 شهر أو أكثر.

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

قررنا التحدث مع رئيس الوزراء والأعمال:

- يا رفاق ، لدينا Agile ، Scrum ، العدو السريع ، العمليات - دعنا لا نلقي مهام جديدة ، لكننا سنتطور بشكل متوقع.
- انظر ، نبيع الهبوط ، يجب القيام به في 3 أيام. لقد دفعنا مليون لهذا. ما العمليات؟ يجب أيضا كسب المال!

مليون أقنعنا. بدأنا في التفكير أكثر.

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

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

ظهور فرق جديدة

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

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

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

تبادل الخبرات بين الفرق

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

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

وكانت الاجتماعات الأولى على النحو التالي:

- مرحبًا ، اسمي يوجين ، نحن الآن نقطع الأخبار.
- رائع!

الاجتماع القادم:

- مرحبًا ، اسمي لا يزال يوجين ، نواصل قطع الأخبار.
- حسنا.

لا يحدث شيء غير عادي.

اللقاء الثالث: مرحبا ... وكل نفس.

أدركنا أننا بحاجة إلى تغيير التنسيق. قراءة كتب عن الاجتماعات و
قدم جدول أعمال ثابت.

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

مزايا هذا القرار

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

لقد أحببنا شكل الاجتماعات وبدأنا في عقدها بانتظام.

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

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

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

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

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

ثم تذكرنا حول KPI ! دعونا نعلم كل مطور أن يتكلم وأن يدرج في تقارير KPI 2 الخاصة به لمدة ستة أشهر في تجمعات الجمعة. اعتقدنا أن الفكرة كانت رائعة وسيتقدم الجميع.

اتضح أنه بعد تقديم KPI ، توقف المطورون عن إعداد التقارير. نشأت المظاهر السلبية للأداء الإلزامي. قرر المبرمجون التضحية بتنفيذ 100 ٪ من مؤشرات الأداء الرئيسية ، فقط لعدم تقديم تقارير طوعية إلزامية.

الاستنتاجات

بينما كنا نحل مشاكل الكفاءة ، كانت الشركة تتطور وظهرت مشاريع جديدة وكان علينا التكيف. هذا ما فهمناه من هذا.

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

— .

. , , , : , PM, .

— , .

, :
— . — , PM.
PM .
— , ? — PM , .

, , .

. .

, . Jira Slack, , , . Scrum-, .

, .

.

. , . , . , - , — , — - . , . :

— ?
— !
— !
— , iMessage!

, - : , .

, : , , , 2 , .

« » .

— , , .

. , «», — , , . , , , . , , .
تكون مرشحات بين البيئة والفريق. يجب تحديد جميع المعلومات حتى لا تحبط المطورين.

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