تؤثر البنى الأساسية للخوادم بشكل أساسي على العوامل التي تحد من تطوير المنتج.يعمل مديرو المنتجات في المؤسسة في مجموعة متنوعة من الأدوار. في بعض الأحيان يطلق عليهم "صوت العميل" ، وأحيانًا يلعبون دور
"خطر القط للشركات" . إنهم أشقاء ذوو البشرة السميكة ، أناس يقودونك بلا رحمة لتسليم المنتج ، على الرغم من أي أخلاقيات أو أعذار. نادراً ما يصبح مدير المنتج الجيد المعبود الخاص بشخص آخر ، ولكن بفضل عمل هؤلاء الأشخاص تتجسد معظم الحلول التكنولوجية التي استخدمتها في أي وقت مضى.
تبحث PM دائمًا عن أدوات عالية الجودة لحل المشكلة. نحن نعلم أن المنافسين يواصلون نشاطهم باستمرار ، لقد سئم العملاء من الانتظار ، لذلك علينا دائمًا التصرف بشكل أكثر ذكاءً وأسرع وأكثر كفاءة. مع ظهور التقنيات الخالية من الخوادم ، لم يكن من الواضح على الفور كيف ستندرج في قائمة أمنيات إدارة المنتج. ومع ذلك ، بعد العمل مع هذه التقنيات لمدة عام ، أرى أنها تحل بعض مشكلات تطوير البرامج التي بدت لنا إلى الأبد.
مفارقة: حجم الفريق والأداء
تقول القاعدة الأولى لإدارة المنتج: إن حجم العمل الذي يتعين القيام به يتزايد باستمرار. يستمر تراكم الأعمال المتراكمة ، وينهار إلى الصفر في حالة واحدة فقط: عندما يتم التخلص من المنتج. أصعب شيء هو تحويل أهم عناصر تراكمك إلى منتج جاهز للتسليم. الأشياء الأخرى على قدم المساواة ، ويعتقد أن العلاقة التالية ينبغي مراعاتها:
إذا تمكن حفار واحد من إعادة تدوير 1 طن من التربة يوميًا - من المفترض أن 10 حفارات يمكنهم إعادة تدوير 10 طن. كقاعدة عامة ، تعتمد إدارة الموارد في الشركات على هذا المبدأ: إذا كنت ترغب في زيادة المبيعات - يمكنك توظيف المزيد من موظفي المبيعات. عند تطوير البرامج ، وعندما ينمو العمل المتراكم ، يكون الإغراء هو زيادة الفريق ببساطة. ومع ذلك ، في حالات المنتجات والخدمات المعقدة ، يلوح في الأفق الجدول الزمني التالي تقريبًا بمرور الوقت:
من النادر أن نرى كيف يعمل فريق ضخم بسرعة Stakhanov ؛ لكن غالبًا ما يحدث أن يتقدم فريق صغير ذو ثبات يحسد عليه على قدم وساق.
لدى العديد من الشركات الناشئة هذا الخطأ: بمجرد أن يصبح المنتج ناجحًا ، تتم إضافة المزيد من المطورين والمديرين الجدد إلى الموظفين. سرعان ما اتضح فجأة أن السرعة تبدأ في الانخفاض. ما هو الموضوع؟ أن المطورين الأوائل كانوا أكثر موهبة ، وأن البيروقراطية نمت في الشركة ، وكيف تم التخطيط للهندسة المعمارية؟
أعتقد أن كل هذه مجرد أعراض وليست جذر المشكلة. تكمن المشكلة في حد ذاتها في تفاعل ثلاثة عوامل حاسمة ، يمكن التحكم في اثنين فقط منها:
- الهشاشة هو تأثير التغييرات الجديدة. إذا أثرت ميزة جديدة على جزء فقط من الماكينة ، فمن السهل اختبارها وتنفيذها. إذا كان يؤثر على جميع عناصر الجهاز ، يصبح الاختبار أكثر صعوبة وفي الوقت نفسه أكثر أهمية ، ويتطلب التنفيذ ترتيبًا أكبر من الوقت.
- حجم العمل هو أصغر جزء من العمل يمكن أن يؤديه فريق ويعطي ميزة إنتاجية في المخرجات. على سبيل المثال ، تكون النتيجة "الدفع مع Alexa" بدلاً من "الاجتماع معًا ومناقشة كيفية إجراء المدفوعات باستخدام Alexa".
- التعقيد - مقدار المعرفة المطلوبة لتنفيذ ميزة. هل المطور هو الذي يعرف كيفية كتابة ميزة قادرة على فعل الشيء نفسه داخل المؤسسة؟ ما هي التغييرات الإضافية التي يجب أن تحدث لكي يتباطأ التقدم تدريجياً ، ويتوقف نمو المنتج عن طريق ميزات ذات قيمة من وجهة نظر العميل؟
أنا مهتم بشكل خاص لماذا ، في فجر الوجود ، كل هذه العوامل متوازنة على النحو الأمثل: لا يوجد شيء هش ، وكمية العمل ليست كبيرة بشكل خاص (ويمكنك عادة الاتفاق مع العميل) ، والتعقيد غائب عمليًا. لذلك ، إذا احتاج فريق ما إلى إنشاء موقع متوافق مع إجمالي الناتج المحلي ، فسيكون لديهم وقت لدراسة هذه المشكلة ، وسيتم اتخاذ قرار سريعًا ، وسيكون الفريق متأكدًا من أن الموقع يعمل تمامًا كما هو مخطط له.
في الشركات الكبيرة ، يتم الجمع بين هذه العوامل ، مما يؤدي إلى زيادة حجم الفريق ، ويتم تقليل حجم العمل المنجز. لإنشاء موقع متوافق مع الناتج المحلي الإجمالي في مثل هذه الشركة ، ستحتاج إلى توقيع المحامي وموافقة المسوقين والموافقة على المشروع على مستوى مجلس الإدارة واختبار A / B للتنفيذ الأقل تعطلاً وتنسيق انقطاع التطوير مع فريق المسؤولين والتنسيق مع خطط النشر المعتمدة من الفرق الأخرى - القائمة تطول. حتى مع هذا القدر من التحكم وعدد العمليات ، فإن الفريق أقل ثقة في نجاحه ، بسبب هشاشة النظام بأكمله والعديد من العناصر المجهولة في النظام البيئي.
توسيع هذا المثال إلى حجم مشروع حقيقي ، حيث قد يكون هناك العديد من الميزات ومئات التغييرات ، من السهل أن نفهم كيف ، بسبب تأثير هذه العوامل ، يتحول الرسم البياني لنسبة "حجم / حجم فريق العمل" من الأول إلى الثاني. مع نمو الفريق ، يُحتمل عليك القيام بعمل أقل لكل وحدة زمنية ، بغض النظر عن كيفية التغلب على العملاق التنظيمي. أو يبدو الأمر كذلك - لكن ما العمل إذن؟
كيفية اختراق جميع العوامل الثلاثة
هذه المشكلة كانت تطاردني لسنوات عديدة ، مما دفعني إلى دراسة أسبابها المحتملة. هل يمكن للشركات الناشئة إحراز تقدم سريع؟ لفترة من الوقت ، أعتقد ذلك ، واجهت صعوبات إدارة المنتج في المؤسسات الكبيرة. ومع ذلك ، ثم نظرت إلى العوامل الثلاثة عن كثب.
الهشاشة دائمًا ما يلحق الضرر بك - فهو يثير الديون الفنية المتزايدة في أي مشروع من أي حجم. يشبه الموقف "عمر النصف على العكس": أي عنصر من عناصر البرنامج ينمو بمرور الوقت وبسبب هذا (أثناء التطوير) يصبح أكثر هشاشة ، ويتضاعف كل هذا مع كل سطر جديد من التعليمات البرمجية.
لا يرتبط مقدار العمل بميزة محددة للمنتج ("الدفع باستخدام Alexa") ، بل يرتبط بالاختلافات في الخطوط العريضة للبنية التحتية إذا قارنا الحالات "قبل" و "بعد". كلما زادت صعوبة "بعد" ، كلما قل حجم العمل المنجز. لهذا السبب في العديد من الشركات ، عند التخطيط للعمل ، يتم تحويل التركيز من احتياجات العميل ("الدفع مع Alexa") إلى احتياجات المنظمة ("تعرف على من يناقش من يجب أن يشارك في تنفيذ ميزة" الدفع مع Alexa ").
التعقيد هو مزيج من العوامل الاجتماعية والتنظيمية والتقنية التي تؤثر بشكل مباشر على مدة البحث عن مطور مناسب ، والقدرة على التعامل مع المبرمجين كأشخاص متعددي المهام الذين يمكن تكليفهم بأي وظيفة. علاوة على ذلك ، إنه أمر معقد - الجانب ذاته الذي من المرجح أن يظل غير مرئي وغير موثق وسوء فهم. يمكن للمطور كتابة تطبيق React في المنزل وإصداره بنفسه ، لكن في المؤسسة سيتعين عليه اتخاذ عشر خطوات إضافية ستستغرق وقته ، ولن تتغير الميزات المثيرة للاهتمام للمستخدم على الإطلاق. سيقضي المبرمج معظم اليوم عليهم.
تشكل هذه العوامل الثلاثة معًا حلقة مفرغة ، بحيث يتناقص مقدار العمل المنجز ، ويزيد الهشاشة ، ويتمكن المطور من إكمال ميزات أقل وأقل ، ويغمر منتجك بالتعقيد كطين غير مرئي. وبالتالي ، لا يساعد نمو الفريق ، ولا يمكن زيادة السرعة إلا بوعي من خلال الماكرة بالأرقام والمؤشرات. أعراض كلاسيكية: يظهر موقف "الاجتماع الذي عقد" في تقارير الركض.
في الشركات الكبيرة ، اضطررت إلى ملاحظة بعض الأساليب المعيبة المصممة لكسر هذه الدورة. الأول هو "على نطاق واسع رشيقة" ، مما أسفر عن اجتماعات ضخمة فيها تماما جميع المشاركين في تطوير ميزة معينة المشاركة ومحاولات لتنسيق العمل. لذا حاول تنسيق العمل وفهم التعقيد. يعد هذا النهج مفيدًا لشركات توزيع الأغذية التي تقدم وجبات غداء ساحرة ، ولكن في حالتنا ، فإنها لا تعمل. والحقيقة هي أنه مع زيادة حجم مجموعة المشروعات ذات الأولوية ، يزداد عددهم ، وينخفض عددهم. لذلك ، لا يمكن حل مشاكل الهشاشة والتعقيد بشكل أساسي. بمرور الوقت ، تقدم Agile الواسعة النطاق قائمة تكتيكية من المهام التي تشبه قائمة التسوق ، وتشبه إلى حد ما مسارًا كليًا من ميزة مدروسة إلى أخرى.
ثانياً ، غالبًا ما تحاول "مجموعات الابتكار" داخل الشركات دفع التغييرات المحيطية ، على أمل أن يتأصل هذا العمل في جهاز هش ، وسوف يتغير الهيكل بأكمله للأفضل. هذا النهج له تأثير جانبي غريب: يتم توحيد الاعتقاد بأن فقط "مجموعات من المبدعين" لديهم الحق في إجراء تغييرات على العملية. لذلك ، طريقة مماثلة أيضا لا تحل مشاكل التعقيد التنظيمي.
بعد أن رأيت سنوات عديدة من الإخفاقات المختلفة ، توصلت إلى استنتاج مفاده أنه من الضروري اختراق العوامل الثلاثة لمنع تأثيرها المشترك على العمل المنجز والتغلب على القصور الذاتي:
- يجب ألا تزيد الهشاشة في الإصدارات المستقبلية أو مع تقدم عمر المنتج.
- يجب ألا يقل حجم العمل عن المطلوب لإنشاء ميزة مهمة من وجهة نظر المستخدم.
- يجب ألا يؤثر التعقيد على عمل مطور واحد.
إذا نجحت في تبني هذه الأفكار ، فستتم حمايتك من موسيقى الروك ، التي تتبع جميع منتجات البرمجيات في تاريخ البشرية. يبدو رائعا ، ولكن كيف يمكن تحقيق ذلك؟
إذا نجحت في تبني هذه الأفكار ، فستتم حمايتك من موسيقى الروك ، التي تتبع جميع منتجات البرمجيات في تاريخ البشرية. يبدو رائعا ، ولكن كيف يمكن تحقيق ذلك؟
Serverless تقنيات كسر القيود
بفضل ظهور التكنولوجيا السحابية ، كان من الممكن تمهيد مسارات مهمة لحالة "اختراق" جديدة. بشكل عام ، مع ظهور السحب ، أصبحت عملية تقديم منتج برمجي أكثر إحكاما ، حيث بدأ المزود في القيام بالكثير من الأشياء الروتينية نيابة عنك. قبل ظهور السحب ، إذا كنت بحاجة إلى تنفيذ ميزة مستخدم جديدة ، فيجب عليك طلب خادم ، وتثبيت المعدات على الرفوف ، والاتفاق على وضع الشبكات في مركز البيانات ، ثم صيانة هذا الجهاز ، الذي يتلاشى مع مرور الوقت. في السحابة ، يمكن استئجار كل هذا ، وبالتالي التخلص من العشرات من العناصر التنظيمية وتوفير أشهر كاملة.
بالإضافة إلى ذلك ، من خلال القضاء على الحاجة إلى ترقية المعدات في مركز البيانات وتوفير الوصول إلى الأجهزة عند الطلب ، فإننا نحد من الهشاشة والتعقيد. إن استخدام البرامج أسهل بكثير مما كان عليه في الأيام القديمة. ومع ذلك ، مع مرور الوقت ، زاد عبء إدارة البنية التحتية الافتراضية الواسعة بشكل كبير ، وبقيت العديد من طرق التسليم القديمة على حالها. باستخدام السحب ، يمكن زيادة الفريق بشكل كبير قبل بدء العمل في التباطؤ - ومع ذلك ، يبدأ في التباطؤ ، بطريقة أو بأخرى.
تقنيات Serverless تغيير جذري هذه الديناميكي. يتكون التطبيق بدون خادم من أجزاء صغيرة من التعليمات البرمجية يكتبها فريقك (ما يسمى "الغراء") و "الصناديق السوداء" الوظيفية التي يديرها مزود السحابة. الصندوق الأسود يقبل ببساطة التكوين ويتفاعل مع التغييرات. في تطبيق له بنية عالية الجودة ، يقع جزء قياسي من العمل التشغيلي المرتبط بتشغيل التطبيق على المربعات السوداء القياسية. لم يعد التطبيق نفسه وظيفة متجانسة ، بل بنية اتحادية للوظائف والمربعات السوداء.
في الممارسة العملية ، يؤثر هذا بشكل كبير على العوامل الثلاثة التي ذكرتها أعلاه:
- يتم تقليل الهشاشة بسبب تكاليف إدارة البنية التحتية الصفرية وضعف الارتباط. في مشاريعنا الخاصة ، لوحظ أن قاعدة الشفرة نتيجة لهذه التغييرات يمكن في بعض الأحيان تخفيضها بعشرة أضعاف.
- عادةً ما يكون حجم "قطعة العمل" مشابهًا لتكلفة إنشاء ميزة جديدة ، حيث يصبح إنشاء نسخ جديدة من الوظائف أو وظائف جديدة تمامًا لم تكن مطلوبة من قبل.
- لا يؤثر التعقيد على المطور - إذا كان بإمكانه كتابة وظيفة تعالج مدفوعات بطاقات الائتمان ، فليس هناك عملياً شيء يمكن فعله بالإضافة إلى هذا الرمز في التطبيق بدون خادم ، ولا توجد أي أغلفة تنظيمية ولا يوجد أي اعتبار للنظام الإيكولوجي ، لأن العمل قد يتباطأ.
عند إدارة التطبيقات الخالية من الخوادم الكبيرة جدًا ، يكون من السهل على مدير المنتج إلقاء نظرة فاحصة على العناصر القليلة جدًا التي تأثرت بالتغييرات التي تم إجراؤها. بالإضافة إلى ذلك ، من السهل إطلاق نسختين على نحو تنافسي عن طريق وضع أعلام الميزات. علاوة على ذلك ، عادة ما يكون من غير الضروري هدم الإصدارات القديمة من الكود.
في التطبيقات الخالية من الخوادم ، يتم بناء البنية الأساسية دائمًا على الهامش ، وتكتب فقط الحد الأدنى الضروري من الكود الذي يجمع بين الخدمات المدارة بالكامل. لست مضطرًا أبدًا للتفكير فيها من وجهة نظر عملياتية. نحن لا نحاول السيطرة على المتراصة ، أو تنظيف الكود القديم ، أو عرض النظام بأكمله من وجهة نظر عين الطير.
لماذا هو مهم للغاية
مع زيادة وتيرة التغيير ، يصبح من الصعب بشكل متزايد التنبؤ بكيفية ظهور البرنامج في المستقبل أو ما يريده المستخدمون منك. لذلك ، فإن محاولات كتابة الكود "لعدة قرون" ، بحيث يجب أن تعمل في المستقبل ، على الرغم من أي تغييرات ، تصبح أكثر جدوى. لقد رأينا مدى سوء استخدام التعليمات البرمجية في معظم الشركات ، وكيف يؤدي التقيد بالمنصات القديمة إلى إبطاء التقدم.
الآن يتم ترتيب كل شيء حتى يتم تطوير النظام القديم وصيانته لأطول فترة ممكنة ، حتى يبدأ دعمه في الاستغناء عن المبرمج تقريبًا طوال الوقت. بعد ذلك ، تبدأ الشركة من جديد بالنظام الجديد ، وتعهد رسميًا بعدم تكرار الأخطاء التي ارتكبت في النظام القديم. عندما تخنق النظام الجديد ثلاثة عوامل عاجلاً أم آجلاً ، فهناك "حرائق غابات" تكنولوجية ، وبعد ذلك يجب أن تبدأ من جديد.
لقد انطلقنا في الكفاح ضد أعراض التعقيد ، وهذا هو السبب في أن العديد من النماذج تأتي وتذهب ، دون ترك أي أثر كبير في تاريخ إدارة المنتج. يسمح التطوير بدون خادم ، بدوره ، للفريق بتقليل الزيادة في التعقيد والاستمرار في تقديم منتج ذي قيمة بوتيرة متساوية إلى حد ما ، دون الوقوع في الفخاخ الكلاسيكية التي ظلت لعقود من الزمن من ويلات أي تطوير للبرامج.
لقد بدأ تطوير النموذج بدون خادم ، لكنه يبدو بالفعل واعداً للغاية. في الوقت الذي يطلب منك فيه العميل أن يكون لديك ميزات جديدة لم يسبق لها مثيل ، يمكن لمديري المنتجات أخيرًا الحصول على منصة تتيح لك التفكير بدقة بناءً على إعداد ميزات جديدة. لا يتم إعاقة هذه العملية عن طريق زيادة التعقيد التنظيمي ، كما أنها لا تتوقف بسبب الهشاشة المفرطة.