إدارة المشاريع التقنية عن بُعد… كيف تبدأ؟

تنبّهت مجموعة كبيرة من الشركات حول العالم إلى أهمّية العمل عن بُعد في الآونة الأخيرة ليس حُبًّا بمواكبة أحدث الصيحات، بل بسبب “كورونا” (Corona) الذي جعل العمل عن بُعد بنكهة “مُكره أخاك لا بطل”. ولأنني بدأت قبل أسابيع قليلة بالعمل على مشروع تقني جديد كمُطوّر ومسؤول عن المشروع بشكل كامل، قرّرت إفراد تدوينة لهذا الأمر من وحي تجربتي الخاصّة.

يُمكنك أيضًا القراءة عن كيفية إدارة فريق العمل عن بُعد.

اختيار الأدوات المُناسبة

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

أداة إدارة المشروع ومهامه هي الأكثر أهمّية في المشاريع التقنية، فأنت تحتاج لإنشاء مهمّة (Task)، بطاقة (Ticket)، تشرح فيها الوظيفة المطلوبة بحيث تكون مرجعًا للمُبرمج في أي وقت.

“جيت لاب” (Gitlab)، “جيت هاب” (Github)، “بت باكت” (bitbucket) من الأدوات التي تُتيح تطوير البرمجيات بسهولة تامّة، وهي توفّر في ذات الوقت قسم خاص لإنشاء المهام وإسنادها للمُبرمجين، والأفضل من هذا كُلّه هو إمكانية ربط المهمّة بفرع برمجي (Branch) في أداة “جيت” (Git).

هناك محاسن ومساوئ لكل أداة، قد يكون السعر أكثرها مرارة. ولهذا السبب في المشروع الجديد قرّرنا استخدام أداة “يوتراك” (Youtrack) الرائعة جدًا، المتوفّرة بنسخة مفتوحة المصدر يُمكن تركيبها على خادمك الخاص -أو يُمكننا تركيبها نحن لك (إعلان رخيص 😂)- وإنشاء مشروع جديد.

وقبل الانتقال للنقطة التالية، ارغب في شكر “دانيل” (Danyel AlKeddah) لأنه هو من دلّني على هذه الأداة.

هيكلة المشاريع

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

في هذه الحال قُم بإنشاء أكثر من مشروع، واحد لتطبيق الهاتف MobileApp، وآخر للواجهات البرمجية APIs، وفي حالة وجود لوحة تحكّم للإدارة، قُم بإنشاء مشروع ثالث لها Dashboard، وبهذه الحالة تفصل مهام كل مشروع في مكان خاص لتجنّب أي تداخل وفوضى.

وتبدأ الآن مهمّتك كمُدير للمشروع لإدخال المهام تحت كل مشروع ووضع شرح مُناسب لها مع تحديد الفترة الزمنيّة التي قد تحتاجها هذه المهمّة.

خارطة الطريق

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

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

جدول المهام

بصورة أساسيّة، تمرّ المهمّة بمجموعة من المراحل حتى تُصبح جاهزة تمامًا لدمجها مع التطبيق الرئيسي، وهذا يتم عبر جدول المهام الذي يُعتبر “تريلو” (Trello) أبسط مثال عليه. في أداة “يوتراك” الجداول موجودة، وكل “سبرينت” مؤلّف من تلك الجداول بالأساس، بحيث يحتوي الأول على جميع المهام ليتم نقلها فيما بعد إلى قيد التطوير (In Progress)، ثم إلى “الاختبار” (To Test)، ثم إلى قيد الاختبار (Test in Progress)، وأخيرًا إلى تم (Done) للإشارة إلى أنها انتهت وتم دمجها مع التطبيق.

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

الاختبار

فصل كل مهمّة في فرع برمجي خاص بها يسمح للمُطوّر، ولمُدير المشروع، بالخروج إلى ذلك الفرع وتجربة الميّزة على حدة دون تداخلها مع أي شيء يتم تطويره في ذات الوقت، وبهذه الحالة يُمكن عزل أي تضارب أو مشاكل مع الشيفرة البرمجية، في فرع Dev، التي سبق وأن قُمنا باختبارها وتأكّدنا من أنها تعمل بشكل سليم 100٪.

في حالة عدم وجود مشاكل، يُمكن دمج (Merge) فرع المهمّة مع الفرع الرئيسي للـ “سبرينت”، أو مع فرع التطوير Dev، ومن ثم نقل المهمّة في جدول المهام إلى Done.

عوائق لا بُدّ مها

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