ليست هناك حاجة مديري المشاريع

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

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

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

ملاحظة المحرر: هذا النص هو نتيجة لتقرير أعده ديمتري كروغلوف من وصوله إلى رالي بيمنايا.

أم أنك لا تزال بحاجة

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

إدارة المشاريع ليست من اختصاص تكنولوجيا المعلومات. هذا علم يتجاوز عمره 50 عامًا. علم له كتابه المقدس . بالطبع ، PMBoK ليس فريدًا من نوعه ، فهناك PRINCE وربما على الأرجح العديد من الكتب التي تدعي أكثر أو أقل عددًا من الكتب. لكن PMBK هو أساس المعايير الدولية وهذا يدل على مستوى عالٍ من التقدير. لذلك سوف نبني عليه.

هيا نلعب اللعبة: إذا كنت تعمل كمدير للمشروع ، فحاول ، دون النظر إلى المستقبل ، أن تتذكر مجالات نشاطك الرئيسية من وجهة نظر المعايير الدولية ومعهد عمره أكثر من 50 عامًا؟

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

قارن ما تذكرته بالقائمة من PMBoK:

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

مخطط جانت

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

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

يتم حل معظم المهام في هذه المناطق من خلال إدارة كيان واحد - مخطط جانت.

يتم تأكيد شعبيته وتعدد استخداماته من خلال عدد الأدوات والخدمات التي تتيح لك إنشاء المخططات الخاصة بك. حاول البحث عن "Gantt عبر الإنترنت" وانظر كم من الوقت قائمة الروابط لكل ذوق ولون تحصل عليه.

ما اتضح: لدينا مهنة ، لدينا نشاط ولدينا قطعة أثرية جيدة ، كنتيجة لذلك. إذن ما هي الفائدة؟

كل شيء عن الفروق الدقيقة. على سبيل المثال ، مع Gantt ، ليس كل شيء جيدًا.

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

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

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

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

إذا حاولت google موضوع فائدة مديري المشاريع في تقنية المعلومات ، يصبح من الواضح أن هذه المناقشة مستمرة منذ فترة طويلة. تمكنت من أن تصبح holivar آخر ، مثل المواجهة بين عشاق iOS و Android أو Windows أو OS X. فقط علامات الاقتباس في نتائج البحث أكثر عاطفية: "هل نحن بحاجة إلى PM؟" ، "لماذا قررنا التخلص من PM" ، "هل هل عمل رئيس الوزراء لا قيمة له؟ "

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

منهجيات رشيقة

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

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

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

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

دور

أصبحت منهجيات Agile هي المعيار الفعلي وجلبت أدوارًا جديدة لعملية تطوير البرمجيات. وبدأت هذه الأدوار الجديدة في الاستغناء عن الأنشطة والتحف الفنية من مديري المشاريع.

مالك المنتج (PO)

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

لذلك ، فإن المنهجيات المرنة تفعل ذلك تمامًا - يقولون لشخص واحد من الشركة شيئًا ما بروح: "أنت متطرف من أجل المال وحركة المرور والتحويل. ولكي نكون صادقين ، نحن لا نهتم بما ومع الأولوية التي تقوم بها في المنتج. الشيء الرئيسي هو أنه بحلول نهاية العام ، سيزداد التحويل من 1 ٪ إلى 1.1 ٪ ، وإلا فإن المشروع لن يكون مربحا. " ويحصل PO على الحق في اتخاذ القرارات بشكل فردي ، فهو يحدد الأولوية ، ويقوم بإنشاء الأعمال الفنية المقابلة (الخطط ، خرائط الطريق ، المتطلبات) ويستغرق جزءًا من العمل من PM.

Techlide (TL)

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

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

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

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

محلل نظم (SA)

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

سكروم ماستر (SM)

سكروم ماستر تقلص إلى حد كبير دور مدير المشروع. إنه لأمر مؤسف الآن أن SMs أنفسهم أصبحوا مرشحين للانقراض.

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

- ما هو التقييم؟
- نقاط القصة.
- ما هي السرعة؟
- 68.
- كيف تخطط للمشاريع؟
- في تقييمات "تي شيرت" S ، M ، L.

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

بالطبع ، هذا ليس هو الحال في كل مكان. بالتأكيد هناك العديد من الشركات التي تحتاج إلى الوصول إلى معايير السوق وهذه ليست عملية سريعة. في روسيا ، بعد 10 سنوات ، سيكون من الممكن العثور على وظيفة كـ Scrum Master في نوع من "Lenoblkhozpromlespoval" عندما تقرر المنظمة نقل مبرمجيها الثلاثة إلى Agile.

خلال شعبيتها ، تمكن Scrum Master من استبعاد جميع الأسئلة من فريق المشروع تمامًا من PM. لقد أخذوها ليس لأنفسهم ، ولكن لأعضاء الفريق ، لتسهيل مشاركتهم في أعمال التصميم. هذا ، بالمناسبة ، رفع مستوى نضج تكنولوجيا المعلومات بشكل كبير في نظر الأعمال.

أو لا تزال غير مطلوبة

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

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

لا تزال بحاجة

هناك فئات من مشاريع تكنولوجيا المعلومات التي يكون الفشل فيها بدون مدير مخصص مضمونًا عمليًا.

مشاريع العالم الحقيقي

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

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

المشاريع المتعلقة بالمعدات تعيدنا من العوالم الرقمية إلى واقعنا ، حيث لا يزال تحكم PMBoK الكلاسيكي ذا صلة.

مشاريع مظلة

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

مشاريع مع ارتفاع تكلفة الخطأ

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

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

مشاريع بدون جزء من الأدوار

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

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

نص أعده:
المؤلف - ديمتري كروغلوف
المحررين - يوجين شكليار ، دينيس فونساروفسكي
قد لا يتزامن رأي المؤلف في بعض القضايا مع رأي هيئة تحرير المدونة وشركة Yandex.Money.