شهر الرجل الأسطوري الأسطوري

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

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

نشره فريدريك بروكس في عام 1975 (هل تتذكر عام 1975 ، أليس كذلك؟ عندما كان تطوير البرمجيات يشبه تطوير البرمجيات بنسبة 100٪ في عام 2020؟) ، هذا الكتاب مشهور إلى حد ما بين مهندسي البرمجيات. على وجه التحديد ، هناك نقطة واحدة مشهورة في الكتاب بأكمله (لست مقتنعًا أن الناس يقرؤون أي شيء سوى هذه النقطة إذا كانوا قد قرأوا الكتاب على الإطلاق):

"... إضافة المزيد من الرجال يطيل الجدول وليس يقصره."

سهل الإصلاح. سأقوم فقط بتوظيف النساء في المشاريع من الآن فصاعدًا (انظر عودة الملك والكفاح ضد Witch King of Angmar).

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

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

هذا الرسم البياني من الكتاب يوضح هذه النقطة:

هذه بالتأكيد نقطة عادلة. لهذا السبب أسمعه كثيرًا في العمل. إن المساهمين الفرديين المنهكين والقادة المنهكين على حدٍ سواء سوف يتخلصون منها - لا يمكننا أن نذهب أسرع ، لا يمكننا فعل المزيد ، ووقف التوظيف ، واقرأ The Mythical Man-Month واليأس! يبدو أن الحل الوحيد هو التوقف عن النمو وقتل بعض المشاريع.

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

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

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

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

والمثير للدهشة أن الإجابة على هذا السؤال تأتي من نفس كتاب بروكس. هذا رسم بياني آخر في نفس الفصل:

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

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

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

يمكن إدارة الصراع بين المدير التنفيذي للمنتج بين التوسع وتحديد الأولويات القاسية.

1. أنت تعطي الأولوية بلا رحمة في الأماكن ذات الخيوط الفردية (لنفترض تراكم فريق المنتج).
2. يمكنك القياس عن طريق إضافة المزيد من النوى للتعامل مع العمل المستقل.

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

كل شيء عن إدارة التبعية

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

يتمثل أحد الحلول في تجميع اتجاه استراتيجي للشركة يقلل أو يحد من التبعية من خلال مجموعة مبادرات منتقاة بعناية. الشيء المضحك هنا هو أن العديد من الناس سوف يتراجعون عن هذا الأمر. لنفترض أن لدي خيارين ، أحدهما يمكنني من خلاله تنفيذ المشاريع أ ، ب ، ج التي لها قدر ضئيل من التنسيق (لنفترض أنها تؤثر على منتجات مختلفة ) ، وخيار آخر مع المشاريع D1 و D2 و D3 التي تحتوي على الكثير من الترابطات ( لنفترض أنها تؤثر جميعها على نفس المنتج). غالبًا ما يتم استدعاء شهر الرجل الأسطوري ضد الخطة السابقة بدلاً من الأخيرة. لأنه على الورق يبدو أكثر .

في الواقع ، إنها أقل "تركيزًا". لكنها في الواقع أقل صعوبة من منظور التبعية وبالتالي تتناسب بشكل أفضل مع الموظفين الإضافيين.

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

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

الخلاف في Mythical Man-Month هو أنه عندما تضيف أشخاصًا إلى مشروع برمجي ، يحتاج الاتصال إلى زيادة هندسية. على سبيل المثال ، إذا كان لديك 3 أشخاص في المشروع ، فهذا يعني 3 خطوط اتصال. ولكن إذا كان لديك 4 ، فهذه 6 خطوط اتصال. شخص واحد إضافي ، في هذه الحالة ، يؤدي إلى مضاعفة الاتصال! هزار. (هذا ، بالطبع ، تبسيط مفرط للتواصل في مشاريع تطوير البرمجيات.)

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

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

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

مخاطر تجربة العملاء: التكلفة المخفية (ولكن مقبولة؟) لجدار الحماية

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

كمنتج استهلاكي (فكر في Instagram أو Nintendo Switch أو Roomba) ، يجب أن نكون قابلين للاستخدام خارج الصندوق. بالنسبة لمنصة تسويق شاملة تهدف إلى تعزيز عملك ، فهذا صعب! وهذا يعني أن كل شيء يبنيه Mailchimp يجب أن يكون متصلاً بسلاسة من منظور التجربة.

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

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

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

يمكنك دائمًا تقصير قانون بروكس باختيار جهود جدار الحماية ، بما في ذلك الجهود التي لا ينبغي أن تكون بجدار حماية في عالم مثالي!

"

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

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

لا تنس الجانب الأكثر ليونة من التحجيم

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

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

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

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