تجربتي مع احدي شركات التطوير البرمجي

ساتحدث معك اليوم عن تجربة عملت فيها مديرا لمشروع برمجي داخل احدي شركات التطوير .. لن اذكر اسم الشركة ولا اسم العميل, فالقصة ليست عنهما, وانما عن نمط اراه يتكرر في اماكن كثيرة اكثر مما نتصور.

دخلت الشركة مطورا, وبعد فترة قصيرة طلب مني ان اكون مسؤولا عن احد المشاريع البرمجية .. ثم حدث ما لم يكن بالحسبان.

الاجتماع الاول

بدات باجتماع مطول مع صاحب المشروع لاطلع علي تفاصيله كاملة. كان المشروع قد بدا بمرحلة التصميم مباشرة, فراجعت ما هو متاح من تصميم اثناء الاجتماع نفسه.

وكانت اسئلتي هي الاسئلة المملة المعتادة: اين تحليل المشروع ؟ اين خطة العمل ؟ ما هي ال "Standards" المتبعة هنا ؟

"ال Standard عندنا هو ما يريده العميل"

هذه كانت الاجابة تقريبا بنصها. ال "Standard" المتبع في الشركة هو "ما يريده العميل", ولم يتم تنفيذ اي ملف تحليل للمشروع, والسبب المعلن ان ال "PM" الخاص بالعميل لم يطلب ذلك !

توقف عند هذه الجملة قليلا يا صديقي. التحليل ليس خدمة اضافية تقدمها عند الطلب, هو الارضية التي تقف عليها انت قبل ان تقف عليها العميل. وغيابه لا يوفر وقتا, انما يؤجل الفوضي الي وقت يكون ثمنها فيه اغلي بكثير.

والاهم ان تسليم القرار الفني بالكامل لطرف لم يطلب شيئا ليس مرونة, هو تخل عن الدور. العميل لا يعرف انه يحتاج تحليلا, وهذه ليست وظيفته اصلا.

من يدير المشروع فعلا ؟

كنت اتحدث مع ال "PM" الخاص بالشركة, فكان السؤال الذي فرض نفسه: ما دورك هنا اذن ؟

الصورة التي تكونت لدي ان خطة العمل لم تكن واضحة من الاساس, فصار "PM" العميل هو من يقود التفاصيل بالنيابة عن "PM" الشركة .. اي ان الشركة استلمت المشروع وتركت دفة القيادة عند الطرف الاخر, وبقي دورها تنفيذيا فقط.

بالنسبة لي هذه ليست مشكلة تنظيمية صغيرة. حين لا يكون واضحا من يملك القرار, فان كل تاخير لاحق سيكون بلا صاحب, وكل خطا سيكون خطا مشتركا, والمشترك في هذه الحالات لا يصلحه احد.

ماذا حدث بعد اسبوع من العمل ؟

اسبوع واحد كان كافيا لتظهر ثلاث علامات, كل واحدة منها تكفي وحدها للتوقف والمراجعة.

• تسليم يحمل نفس الملاحظات القديمة. تم تسليم اربع صفحات ال "login" وال "registration" وبها نفس الاخطاء التي سبق التعليق عليها, ثم سلمت كما هي. الملاحظة التي لا تغير شيئا في التسليم التالي ليست ملاحظة, هي مجرد ورق.
• صلاحيات اوسع من اللازم بكثير. تمت اضافتي علي ال "Jira" باطلاع علي كافة مشاريع الشركة, ووصول كامل لبيانات العملاء والمشاريع. كتبت وقتها في ورقتي كلمة واحدة: "مصيبة". انا لا احتاج بيانات عملاء لا اعمل معهم, ووجودها في يدي مخاطرة علي الشركة قبل ان تكون راحة لي.
• توثيق اقل من العرض نفسه. تم تزويدي باربع صفحات "PDF" تشرح سير المشروع بشكل ابسط مما يحويه ال "Proposal" الخاص به. حين يكون المستند الداخلي اضعف من المستند الذي ذهب للعميل, فانت تعمل بمعلومات اقل من التي بعتها.

اضف الي ذلك ان الكود لم يكن موثقا باي شكل.

ما الذي تعلمته من هذه التجربة

لاكون صادقا, لم تكن المشكلة في مطور كسول ولا في عميل صعب. كل ما رايته كان نتيجة طبيعية لغياب اتفاق مكتوب علي طريقة العمل.

• اذا سالت عن ال "Standards" وكانت الاجابة "ما يريده العميل", فاعلم انه لا توجد "Standards" .. وان ما ستسمعه لاحقا عند اول خلاف هو "احنا مقلناش كده".
• التحليل يسبق التصميم, والتصميم يسبق الكود. مشروع يبدا من مرحلة التصميم مباشرة يكون قد قفز فوق الخطوة التي كانت ستحدد معني كلمة "تم" فيه.
• اسال دائما: من صاحب القرار الفني ؟ اذا كانت الاجابة غير واضحة في الاجتماع الاول, فلن تصبح اوضح بعد شهر.
• الصلاحية الزائدة ليست ثقة, هي غياب سياسة. من وجهة نظري هي اخطر ما مر علي في هذه التجربة كلها, لان اثرها لا يظهر الا حين يقع الضرر.
• الملاحظة التي تتكرر مرتين علي نفس الشاشة ليست مشكلة في الشاشة, هي مشكلة في دورة المراجعة نفسها.

ربما اكون قد بالغت قليلا في وصف اسبوع واحد, لكن الاسبوع الاول في اي مشروع هو اصدق ما فيه .. كل ما ستراه لاحقا يكون قد ظهر فيه بشكل مصغر, ونحن غالبا من يختار الا يراه.

لهذا صرت لا ابدا اي عمل قبل ورقة واحدة يتفق عليها الطرفان: ما هو المطلوب, من يقرر, وما معني ان العمل انتهي. ورقة واحدة توفر عليك شهورا من النقاش.

وفقت يا صديقي العزيز ❤