أنت بحاجة إلى بطل: مدير المشروع

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

لماذا تحتاج إلى مدير مشروع في المقام الأول

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

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

• المشروع لديه ضغط الوقت.
• الميزانية أصغر مما أريد.
• أنا أغلى مما يرغب العميل.
• أنا لا أستمع بشكل مثالي كما يود العميل.
• لا يشرح العميل الأشياء تمامًا كما أريد.

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

هذا الشخص ، هذا البطل ، هو مدير المشروع.

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

لماذا لا يكون المبرمج مدير مشروع جيد

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

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

حسنًا ، بالنسبة للمبتدئين ، أنت تدفع لنا مقابل الكود.

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

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

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

لماذا لا يكون العميل مدير مشروع جيد

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

ومع ذلك ، لديك أيضًا الكثير على طبقك.

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

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

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

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

قائمة غير كاملة بأساليب إدارة مشروع تقني

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

معالم

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

تقديرات الوقت

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

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

قصص المستخدم

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

للحصول على بعض المعلومات السريعة حول قصص المستخدمين ، وجدت أن هذه البرامج التعليمية من Mountain Goat Software و Roman Pichler عالية الجودة وموجزة. لمزيد من المعلومات حول الفلسفة الكاملة لإدارة المشاريع الرشيقة ، جرب منشور مدونة Toptal هذا The Ultimate Introduction to Agile Project Management بقلم بول بارنز.

التراكيب (نماذج بالأحجام الطبيعية)

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

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

اجتماعات الوقوف

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

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

نظام التذاكر

بينما يمكن لأي شخص الاحتفاظ بنظام الملاحظات اللاصقة ومُحرر مستندات Google (مع تمييز مهام الجميع بألوان مختلفة) ، فهذا ليس ضروريًا حقًا ؛ حاول الكثير من الناس حل هذه المشكلة نيابة عنك. تشتهر Basecamp و Trello بسهولة الاستخدام ، بينما تحاول Pivotal تغليف الفلسفة "الرشيقة" بأكملها في حزمة رائعة جدًا. مهما كان اختيارك ، فإن نظام التذاكر الجيد سيسمح لك ، على الأقل ، بما يلي:

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

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

التحكم في المصدر

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

تستخدم معظم المشاريع الحديثة Git ، على الرغم من أنك ستواجه أحيانًا Subversion (SVN) عند العمل في مشاريع موجودة منذ فترة. يسمح لك Github باستضافة مستودعات عامة غير محدودة مجانًا (بالإضافة إلى أنه يحتوي على معظم المشاريع مفتوحة المصدر في العالم) ، بينما يسمح لك Bitbucket باستضافة مستودعات خاصة غير محدودة وبالتالي فهو الخيار المفضل للمشاريع التجارية.

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

التحكم في المصدر هو الأعظم.

تطوير يحركها الاختبار

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

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

يتم إحتوائه

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