كقاعدة عامة ، في مجال تطوير الويب المخصص ، تحلم جميع الوكالات فقط بالعملاء الذين ستنمو مشاريعهم مرتين في معدل دوران سنوي ، وتقدم بانتظام حالات يمكن التباهي بها ، وتحصل على جوائز تصنيفات الملف الشخصي للوكالة. هؤلاء العملاء هم قادة الصناعة. هذه إما شركات تم بناء أعمالها على الويب ، أو شبكات كبيرة غير متصلة بالإنترنت ، بفضل الاستثمارات الرائعة ، تنتقل إلى المناصب الرائدة في قناة الويب.
يبدو أنه بعد الحصول على اثنين من هؤلاء العملاء ، يمكنك أن ترتاح على أمجادك - توقف عن البيع وتحكم فقط في التدفق المتزايد للمهام. ولكن في الواقع ، مع نمو المشروع ، سيمنحك تحديات جديدة وجديدة للتعامل مع العميل وإنقاذه ، أثناء العمل بفاعلية التكلفة ، ستكون مهمة صعبة للغاية.
نمو المشروع والتحديات ذات الصلة
من المهم اتخاذ تدابير استباقية في الوقت المناسب وتحمل التكاليف الإضافية المرتبطة بالقياس. في البداية ، قد يؤثر هذا سلبًا على الربحية ، ولكن عند الوصول إلى أحجام معينة ، سيتضح أن الاستثمار الأولي كان له ما يبرره.
فيما يلي التحديات الرئيسية التي قد تواجهها الوكالة في مثل هذا المشروع:
- مشكلة التوسع هي إعادة هيكلة هيكل الفريق مع نمو الأحجام.
- الحاجة إلى فهم مهام المنتج والأعمال - بدون تحليلات قوية للمنتج ، من المستحيل العمل بفعالية في مشروع كبير.
- برامج متطورة وهندسة الخوادم - جنبًا إلى جنب مع نمو أحجام الإنتاج في إطار المشروع ، هناك أيضًا زيادة في حركة المرور ، مما يؤدي إلى بنية أكثر تعقيدًا والحاجة إلى استخدام حلول الحمل العالي.
- متطلبات عالية الجودة.
- الحاجة إلى ضمان تشغيل متواصل 24 × 7 وسرعة عالية في الاستجابة للحوادث بما في ذلك خارج ساعات العمل.
- درجة عالية من المسؤولية عن وقف المبيعات.
- مراقبة ومراقبة مؤشرات الأعمال.
ليست كل الوكالات في السوق لديها الكفاءات اللازمة للتعامل مع كل هذه التحديات. سنتحدث اليوم عن مشكلة توسيع نطاق الفريق - وهو الجانب الأكثر صعوبة ، في رأيي ، في العمل مع مشروع متزايد.
أتيحت لي الفرصة للعمل في العديد من المشاريع ذات النمو الهائل ، بما في ذلك أكبر متجر على الإنترنت لسلع الأطفال وشركة التأمين الرائدة.
لقد شاركت في هذه المشاريع أولاً كمدير ، ثم كرئيس لفريق إداري ، وأريد مشاركة الخبرة المكتسبة.
أدوار في مشروع صغير ولماذا تحتاج إلى التوسع
يبدو مخطط الدور هذا في الحالة العامة:
في AGIMA ، نستخدم إدارة من ثلاث مراحل ، عندما يتم تحديد جميع القضايا التكتيكية في إطار التفاعل داخل فريق المشروع ، ويتم عرض القضايا الاستراتيجية على مستوى مدير الحساب ورئيس قسم خدمة العملاء. يتم إنشاء تسلسل هرمي داخل فريق المشروع ، اعتمادًا على حجم المشروع ، سأتحدث عنه أدناه.
هذا ما يبدو عليه مخطط الدور النموذجي داخل فريق مشروع في مشروع صغير:
للمشروع دوران رئيسيان: مدير المشروع (RP) وقائد الفريق.
تتواصل الشركة مع العميل ، وتضفي الطابع الرسمي على المهام ، وتضع المتأخرات المتراكمة ، وتحدد الأولويات ، وتضع الخطط وتمارس التحكم في المهام للامتثال لمنطق الأعمال. كما تتواصل RP في جميع مراحل العمل مع أقسام التصميم والتصميم والتحليلات وإدارة النظام.
يقوم Timlid بإجراء إضفاء الطابع الرسمي على المهام ، وتحديد التقنيات / الأدوات المستخدمة ، وإجراء مراجعة التعليمات البرمجية ، وتنفيذ الإصدارات ، ومراقبة السلامة المعمارية للمشروع ، وتنسيق فرق التطوير.
يمكن توصيل الموارد المتبقية بالمشروع حسب الحاجة وهي قابلة للتبادل للغاية.
إن حدثًا هامًا في نمو المشروع وتغيير نموذجي غريب يحدث في وقت يكون فيه من المستحيل الاحتفاظ بجميع المعلومات في رأس واحد. لا يمكن لقائد فريق واحد التحكم فعليًا في بنية المشروع بالكامل ، لأنه ينمو بسرعة كبيرة. مدير واحد ليس لديه الوقت للانخراط في جميع المهام والتحكم في كل العمل.
هناك حاجة للفصل والازدواجية في واجبات الموظفين ، ويتوسع مخطط الدور القياسي ويصبح أكثر تعقيدًا.
هيكل فريق الإدارة
واحدة من أكثر الوحدات صعوبة في القياس هي RP.
مع نمو المشروع ، من المنطقي تنفيذ مدير الحساب الزوجي الكلاسيكي - مخطط مدير المشروع ، عندما يتولى أحد الممثلين المحترفين خدمة العملاء ، بما في ذلك مشكلات المنتج ، وينظم الثاني عملية الإنتاج داخل الشركة.
ومع ذلك ، يصبح مثل هذا المخطط طريق مسدود مع النمو اللاحق. في إطار مشروع واحد يمكن أن يكون هناك ما يصل إلى عشرات المنتجات ، كل منها يتطلب اهتماما وثيقا من وجهة نظر العمليات التجارية. في هذه الحالة ، تنشأ المواقف بشكل دوري عندما يؤدي التطوير الموازي للمنتجات المختلفة إلى تضارب منطقي في إطار بنية تطبيق الويب أو منطق الأعمال ، مما ينطوي على مخاطر عالية للغاية.
لذلك ، فإن المخطط المثالي من وجهة نظر المزيد من قابلية التوسع هو كما يلي:
يدير رئيس المجموعة (GH) الموظفين الإداريين للمشروع وهو مسؤول عن التحكم في الميزانيات ، والربحية ، وتشكيل الفريق (المديرين التنفيذيين والمديرين على حد سواء) وتخصيص الموارد ، ويحل القضايا الاستراتيجية لإدارة المشروع. كما يدير مراقبة المنتج ويراقب غياب النزاعات في العمليات المتوازية. لا يقضي الوقت في الأنشطة التنفيذية ويراقب تنفيذ كل مهمة محددة.
بفضل تقديم هذا الدور ، يتم التخلص من الحالات عندما يتم تنفيذ العديد من المهام الكبيرة بالتوازي ويتم الكشف عن التناقضات والتعارضات المنطقية في المرحلة النهائية ، والتي تؤدي في الحالة الأقل نجاحًا إلى إعادة الهيكلة الكاملة.
إذا لزم الأمر ، يتم توصيل دور إضافي لمالك المنتج ، حيث يفوض GH جزءًا من مسؤوليات المنتج. في معظم الأحيان ، يعتمد هذا الموظف على جانب العميل وينقل جميع رغبات العمل في شكل مهام رسمية للتنفيذ.
كل RP في الفريق مسؤول عن "جزء" من المشروع ، مع التحكم في جميع المهام الحالية لعدد من المنتجات (من الناحية المثالية ، يجب أن تكون هذه المجالات ذات الصلة). تشمل مسؤولياته توقيت ونوعية جميع المهام في إطار تطوير المنتجات الخاضعة للمساءلة.
المخطط قابل للتوسع بسهولة وله حد دخول منخفض نسبيًا ، لأنه عند توصيل RP جديد ، لا يحتاج إلى تغطية قاعدة المعرفة الكاملة للمشروع في وقت واحد ، يكفي لفهم مبدأ تشغيل المنتجات "الخاصة بك".
من المهم أن يكون كل RP مسؤولاً ليس فقط عن عملية الإنتاج ، ولكن أيضًا على دراية جيدة بمنطق الأعمال لمنتجاته. وبفضل هذا ، فإن جميع قرارات الإدارة ليست صحيحة فقط من وجهة نظر إدارة المشروع ، ولكنها مفيدة أيضًا للأعمال والتحقق منها هندسيًا.
في بعض الحالات ، يجب تحديد دور مدير المشروع بشكل منفصل - لا يغمس هذا الموظف نفسه في مكون المنتج أو عملية الإنتاج ، ولكنه يشارك في إعداد التقارير ، وهو مسؤول عن إدارة المستندات ويلعب أيضًا دور "السطر الأول" ، مما يضمن استمرارية الاتصال والإجابات السريعة لجميع طلبات العملاء والشركاء .
في الوقت نفسه ، شمل فريق الإدارة بأكمله الدافع الجماعي ، المرتبط بإدارة توقعات العملاء ، في المقام الأول - الدخول في توقيتات المشروع.
- قبل 10 أيام عمل من بداية الشهر ، يخصص كل RP نفسه من ثلاثة إلى خمسة من مهامه الرئيسية للشهر التالي.
- قبل 5 أيام عمل من بداية الشهر ، يختار GH اثنين أو أربعة منهم لكل مدير ويحدد المواعيد النهائية: 1 - مصطلح العميل (50٪) ، 2 - الفصل الداخلي (100٪) وإدخاله في الجدول.
شروط المكافأة (حسب نتائج الشهر):
- يحصل المدير على مكافآت بنسبة 100٪ إذا تم الانتهاء من جميع مهامه خلال الموعد النهائي الداخلي.
- يحصل المدير على 50٪ من المكافآت إذا تركت واحدة على الأقل من مهامه المدة الداخلية ، ولكن تم إكمالها في فترة العميل.
- لا يحصل أي من المديرين على مكافآت إذا لم تكتمل مهمة واحدة على الأقل من القائمة العامة في وقت العميل.
يسمح هذا المخطط لفريق الإدارة بأكمله بالعمل بفعالية وإدارة توقعات العملاء بشكل صحيح.
اختبار الرمز النهائي ليس فقط - أمر QA
مع نمو المشروع ، تتراكم قاعدة معرفية قوية ، يزداد عدد الفروق الدقيقة والميزات ، وتصبح العلاقات المنطقية أكثر تعقيدًا وتنوعًا. في مرحلة ما ، تبدأ هذه العوامل في ممارسة مثل هذا التأثير القوي لدرجة أن تصحيح الأخطاء قبل الإصدار يستغرق وقتًا يتناسب مع التطور ويستغرق نفس مقدار الموارد.
لتجنب هذا الموقف ، توصلنا إلى فكرة إنشاء فريق ضمان جودة كامل بناءً على فريق الاختبار. والفرق الرئيسي هو أن الاختبار لا يتم فقط في مرحلة تطوير التصحيح وتصحيحه ، ولكن في جميع مراحل المشروع:
- إن ضمان الجودة مسؤول عن جودة المنتج وامتثاله الأسلوبي والمنطقي للمنتجات الأخرى والمقبول بشكل عام في قواعد المشروع.
- ينظر QA إلى جميع القطع الأثرية التي تظهر في المشروع: إضفاء الطابع الرسمي على المهمة ، والنماذج الأولية ، والمواصفات ، والتصميم ، وبالطبع اختبار الكود والتخطيط ، وكتابة حالات الاختبار ، وتغطية الوظائف الحالية والجديدة بشبكة من الاختبارات التلقائية.
- بدون التحقق من صحة المواد من قبل فريق ضمان الجودة ، لا يملك RP الحق في إطلاق المرحلة التالية أو إرسال المواد لقبولها إلى العميل.
يمكن لمثل هذا النهج أن يقلل بشكل كبير من مخاطر التصحيح المطول وتأخير تواريخ الإصدار.
Timlids - الكفاءة أو التبادلية؟
بمجرد تقديم قائد الفريق الثاني للمشروع ، يطرح السؤال على الفور - ما هو مخطط توزيع المسؤوليات الذي يجب تطبيقه؟
هناك العديد من الخيارات: إما تقسيم المشروع حسب نوع النشاط ، أي ، على سبيل المثال ، يركز الفريق أ على الهندسة المعمارية ومراجعة التعليمات البرمجية وإضفاء الطابع الرسمي على المهام ، بينما يدير الفريق ب فرق التطوير وإصدارات الإصدارات ، وهو المسؤول عن الاستمرارية والأمن. الخيار الثاني هو تقسيم المنتج ، حيث يتحمل كل قائد فريق المسؤولية الكاملة عن مجموعة منتجاته داخل المشروع.
كلا الخيارين جيدان من حيث استخدام الموارد ، لكنهما يحملان مخاطر كبيرة من حيث التبادلية.
على سبيل المثال ، ماذا علي أن أفعل إذا مرض أحد قادة الفريق ، أو ذهب في إجازة أو استقال؟ سيكون من الصعب تضمين قائد فريق جديد في العملية ، لأن فترة الانغماس في هذا الدور طويلة للغاية.
لذلك ، من المفيد استخدام مخطط هجين في المشروع ، حيث يشارك كل قائد فريق في مهامه الخاصة ، ولكن هناك عدد من الأنشطة التي يكرس فيها كل أو على الأقل اثنين من قادة الفريق.
تشمل هذه الأنشطة الأنشطة الأكثر خطورة ، على سبيل المثال: بنية المشروع ، والاستمرارية ، والأمن ، والمنتجات الرئيسية التي تمثل المبيعات الأكثر نشاطًا ، والتي تم تحديد أدائها في اتفاقية مستوى الخدمة.
هذا المخطط ، بالطبع ، يقلل من إنتاجية العمل ، ولكنه يزيل معظم المخاطر. من الضروري إيجاد توازن بين الكفاءة وقابلية التبادل ، وتحديد قائمة بأهم اللحظات أهمية.
بشكل منفصل ، من المنطقي ربط قادة الفريق بالأنشطة المعزولة: منتج منفصل هندسيًا عن الجزء الرئيسي من المشروع ، أو نشاط يمكن مشاركته بالتوازي. على سبيل المثال ، من الممكن تمامًا تحديد تخطيط قائد الفريق الذي سيتحكم بالكامل في جميع عمليات الخط الأمامي ؛ تتميز بشكل منفصل أدوار قائد فريق ضمان الجودة والتصميم والتحليلات.
تبادل أعضاء الفريق
كلما زاد عدد الأشخاص المشاركين في المشروع ، كلما زادت الحاجة إلى استخدام الأدوات لخفض حد الدخول للموظفين الجدد ، قاموا أيضًا بتبسيط إمكانية تبادل أعضاء الفريق الحاليين وتقليل عامل الناقل.
فيما يلي عدد من الأدوات التي تحقق أداءً جيدًا في جميع المشروعات تقريبًا.
نظام التصميمنظام التصميم عبارة عن مجموعة تصميم شاملة وحديثة ومكتبة المكونات في المستودع. يعكس المجموعة الكاملة من العناصر القياسية في المشروع ويسمح لك بجمع صفحات جديدة من هذه الكتل. لا يحتوي نظام التصميم على مجموعة من العناصر فحسب ، بل يصف أيضًا تفاعلها ، كما يحتوي على أمثلة التعليمات البرمجية.
يمكن أن يؤدي استخدام نظام التصميم إلى تبسيط فهم الموظف الجديد ، سواء كان مديرًا أو مصممًا أو مبرمجًا ، للقواعد المرئية للمشروع ، وتطبيق الحلول الحالية بدلاً من اختراع حلول جديدة باستمرار.
يتطلب استخدام مثل هذه الأدوات إنفاقًا كبيرًا على الموارد للتنمية والدعم. أيضًا ، غالبًا ما يتطلب الأمر الكثير من الجهد الأخلاقي لتوضيح للعميل لماذا من الضروري الالتزام بهذا النظام ولأي سبب سيتم رفض مقترحات مثل "إضافة زر أخضر جديد على هذه الصفحة ، مثل الموقع N ، الذي يبدو جميلًا جدًا".
التوثيقكلما كبر المشروع ، كلما تم توثيق كل منتج وكل ميزة بعناية أكثر ، وإلا ، سيقضي الخبراء المزيد والمزيد من الوقت في تصحيح الأخطاء ومعرفة كيفية عمل وظيفة أو أخرى.
من المنطقي تقسيم وثائق المشروع إلى 4 أنواع:
- مواصفات الواجهة - وصف لسلوك الوظيفة المنفذة (منطق العمل ، التحقق من صحة الحقل ، مجموعة الشاشات).
- حالات الاختبار (وصف سيناريوهات المستخدم ونتائج مرورها) ، بناءً عليها ، إذا لزم الأمر ، يتم تطوير اختبارات ذاتية.
- مواصفات الخدمة (وصف التفاعل مع خدمات الويب ، وبيانات الاختبار ، وأمثلة على الاستجابة للطلب).
- توثيق الكود (وصف المكونات والفئات وتسلسلها الهرمي والقوالب).
يجب تجميع جميع الوثائق في قاعدة معرفية على الإنترنت (Wiki) وتحديثها باستمرار.
جيتلتسريع اتصال المطورين الجدد من المشاريع الأخرى للشركة ، يتم تقديم نهج قياسي لـ GitFlow. نستخدم في AGIMA نهج "العمل مع فرعين رئيسيين".
بدلاً من استخدام الفرع الرئيسي ، يتم استخدام فرعين رئيسيين لتاريخ المشروع: رئيسي للإصدارات والتطوير لدمج الوظائف المطورة من الفروع المميزة.
سير العملالأداة الأخرى التي تنظم وتوحد عمل جميع أعضاء الفريق هي سير العمل حسب اليوم من الأسبوع.
كل أسبوع هو دورة إنتاج قياسية: يتم إصدار الإصدارات بدقة يومي الثلاثاء والخميس ؛ الأربعاء - يوم التقييمات ؛ يتم إجراء التخطيط بأثر رجعي وتخطيط للشحنات الجديدة في نهاية الأسبوع - يومي الخميس والجمعة. هذا مثال على سير العمل من أحد المشاريع ، لكل حالة محددة ، يجب تطوير نهج.
يجب أن يشارك العميل أيضًا في سير العمل - لا يمكن لهذا النظام أن يعمل من جانب واحد.
ليس أقل أهمية هو سير العمل في حالات المهمة ، مما يبسط انتقال الموظفين بين المشاريع. يجب أن تكون متطابقة في جميع مشاريع الشركة. في AGIMA ، يبدو كما يلي:
إبقاء أعضاء الفريق على اطلاع
حتى لو تم تنظيم الوثائق بشكل مثالي في المشروع وعمل جميع العمليات مثل العمل على مدار الساعة ، فمن المستحيل توقع جميع المخاطر المرتبطة بنقص الوعي لكل فنان معين. لهذا ، يتم تنظيم الأحداث العادية بأشكال مختلفة.
1. اجتماعات المنتجفي مثل هذه الاجتماعات ، يخبر الموظفون الأكثر خبرة الفريق عن منتجات محددة. يتم تسليط الضوء على جوانب منطق الأعمال والتنفيذ التقني والهندسة المعمارية. يساعد وعي كل موظف حول الفروق الدقيقة في المنتجات على طرح أفكار مفيدة واتخاذ القرارات الصحيحة في جميع مراحل التنفيذ.
2. أقسام البنية التحتيةينمو المشروع بشكل ديناميكي ، وهذا يستلزم التطوير المستمر والتوسع في البنية التحتية. في الأقسام العادية ، تتم مناقشة المشاكل والمهام الحالية لتطوير البنية التحتية ، ويتم مناقشة التقدم المحرز في تنفيذ كل منها.
3. بأثر رجعي وتخطيط العملمن الضروري عقد اجتماعات أسبوعية لمناقشة المهام التي تم تنفيذها خلال الأسبوع الماضي ، وتسليط الضوء على الأخطاء وتخطيط العمل للفترة المحاسبية التالية.
الاستنتاجات
سيساعد التطبيق المدروس لجميع الأدوات والنهج المذكورة أعلاه في بناء فريق متماسك ومرن يتوسع بسهولة مع زيادة نمو المشروع.
مما لا شك فيه أن تنظيم مثل هذا النظام ينطوي على عدد من الصعوبات ويتطلب كلا من الكفاءات العميقة داخل الوكالة واستعداد العميل للاستثمار في مثل هذه القرارات ، والتي قد تكون صعبة في سوقنا النامية ، ولكن هذه الجهود تؤتي ثمارها وتؤدي إلى تعاون طويل الأمد ومثمر وتسمح بإصدار السوق منتجات ذات جودة عالية.