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

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

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



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

وأريد منهم أن يعملوا بسلاسة مثل هؤلاء الأشخاص في GIF:



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

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

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



لدينا العديد من الخدمات. لا تناسب الشريحة. آمل أن أقنعكم أن ياندكس كبير جدًا. الأشياء الكبيرة يصعب إدارتها.

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

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



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



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



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



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

ويقول: "لدي مصمّم رئيس الرفيق ، لدي فكرة رائعة. أحتاج إلى مصمم ". سوف يجيب: "حسنًا ، أولاً ، فكرتك غريبة ، وثانيًا ، جميع المصممين مشغولون بي. تعال إلى Q5. "

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

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



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



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



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

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

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



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

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



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

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



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

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

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

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



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



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

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

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

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



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



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



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

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

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

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

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

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



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



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

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



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

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

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

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



, : « , , ?». , . , , . , - , , .

, . , , . ? , , , , .

, . , - , , . , . , , — , , , : «, , . ».

, — . , , , , , ? . . , , , . , , . . , — , , , . -, , .

: — , , , , . — . .