رشيق الجانب المظلم

القارئ اليقظ يتدحرج عبر الشريط ويسأل السؤال: "ماذا ، مرة أخرى ، النص عن رشيقة؟". أجل.

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

تحت قطة حول مقاعد الاختبار ، حبس الناس في غرف الاجتماعات وكيفية إدارة القسم ، عندما يتناثر الجميع حول الفرق ويتمتعون بالحياة.

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

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

يبدأ كل شيء بمحاولة إدخال عمليات تطوير جديدة.

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

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

جافا - يسار ، جافا سكريبت - يمين

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

يبدو صحيحًا ، ولكن في الحياة الواقعية ، كل شيء خاطئ قليلاً.

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

في بعض الأحيان يكون المونوليث أمرًا طبيعيًا

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

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

اختبار الإصلاح

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

إذا كنت قد سافرت بالفعل إلى Edgile Moon ، فإن منصة الاختبار هي شيء سيبطئ العملية برمتها ، وهذا هو السبب.

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

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

حول مواقف الاختبار

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

يوجد الآن 70 منهم ، لكننا نهدف إلى 200 - حتى يتمكن الجميع ، مجانًا ، ولا يسيء أحد.

من الحوار مع المسؤول:
- قل لي ، أين هو أتمتة النشر؟
- الحساب مرة كل أسبوعين يستغرق ساعة ، ماذا علي أن أتمتة هنا؟

في الواقع ، هذا: (200 منصة + إنتاج) * (50+ مكون) = الكثير من الجهد للنشر.
الآن لدينا أكثر من 50 مكونًا يطرحها الروبوت. إذا لم يكن له ، فسيكون الجميع سيئين.

في هذه المرحلة ، سيكون لدى الشركة ، التي تتجه نحو رشيقة ، أنظمة آلية لتجميع وتسليم الإنتاج ، وسيتحسن العمل تدريجيًا في الفرق وسيزيد الأداء أيضًا - ما يصل إلى 60-80 إصدارًا في الأسبوع ، وسيتم إصدار كل مكون 2-3 مرات في اليوم .

عند هذه النقطة ، يدرك الجميع أن النظام أصبح كبيرًا جدًا بحيث لا يستطيع أي شخص استيعابه

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

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

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

مراقبة أخرى

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

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

مثل محطة الطاقة النووية

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

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

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

إذا تم التغلب على ذلك ، فسيعمل النظام بشكل جيد في جميع الحالات ، باستثناء المشاريع "الشاملة".

مشاريع المظلة

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

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

قصة حياة: Spotify هي واحدة من الشركات المرنة المثالية. في مرحلة ما ، توصلوا إلى اشتراك عائلي ، لكنهم لم يتمكنوا من إدراك ذلك بسبب صعوبة المزامنة والتخطيط بين الفرق التي لديها خريطة طريق وخطط خاصة بها. بعد عام ، طرحت Google و Apple اشتراك العائلة.

تعارضات المزامنة والجدولة

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

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


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

بشكل عام ، هناك حاجة إلى المزامنة وبدونها لا يمكنك المضي قدمًا. إنه يعقد الحياة في مشاريع ذات موعد نهائي واضح وحرجة عالية - المواعيد النهائية تتراوح من 10 ٪ إلى 50 ٪ ، وهذا غير مقبول في كثير من الأحيان.

كيف تدير هذا؟

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



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

بشكل عام ، عندما يبدو هذا السؤال ، يحتاج الزعيم إما إلى التغيير أو التدريس.

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

الثقافة في تكنولوجيا المعلومات

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



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

رشيقة - غيض من فيض

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

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

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

ثلاثة استنتاجات

1. لا تلمس إدارات التنمية "الكلاسيكية" دون الحاجة. يعمل نظام هجين في Yandex.Money - هناك فريق منتج ، ولكن هناك أقسام يمكنها العمل بفعالية بدون رشيقة.
   
2. إذا لم تكن لديك مهمة لإعادة بناء الشركة بأكملها ، ولكن لديك رغبة أو حاجة إلى جعل منتج جديد أسرع باستخدام أساليب جديدة ، فمن الأسهل أحيانًا الاستعانة بمتعاقدين خارجيين يعملون على رشيقة وإعطاء المنتج موردًا خارجيًا.
   
3. إذا كان تحويل تكنولوجيا المعلومات أمرًا لا مفر منه ، فمن الأفضل الاتفاق على كل شيء "على الشاطئ". يجدر إبرام نوع من "اتفاق الرجل" مع القيادة - أنه ستكون هناك ميزانية للحديد والناس (للمناصب الجديدة لمسؤولي النظام والمختبرين والمطورين). في هذه الحالة ، من الممكن العودة بشكل دوري إلى هذه الاتفاقية ومناقشة ما تم القيام به وكيف.
   

كل ما سبق لديه مشكلة واحدة. اذهب على طول الطريق! = تعال إلى النجاح. لا تمرره = مضمون للفشل.

ولكن إذا كنت في الطريق - حظًا سعيدًا!