إدارة المشاريع التقنية… ما الذي تعلّمته من تجربتي

كُنت من المحظوظين خلال الأشهر القليلة الماضيّة وتم اختياري لإدارة فريق من المُبرمجين (Technical Team Leader) في واحدة من الشركات الناشئة. ولكونها أول تجربة لي، وضعت بعض الاستراتيجيّات التي قد يستفيد منها البعض، وسأشاركها هنا رفقة بعض الدروس المُستفادة.

جسّ نبض

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

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

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

عدم تقديم الوعود كان لحماية الصورة الشخصيّة وعدم رفع سقف التوقّعات، فلو دخلت منذ اليوم الأول بروح التغيير الإيجابي وتأخّر هذا التغيّر، سيفقد الجميع إيمانهم بقائد الفريق وستُصبح المهمّة أصعب وأصعب.

القانون قانون!

عندما تُقرّر وضع شروط مُحدّدة للعمل تحتاج للالتزام بها أنت أولًا قبل أي شخص آخر؛ الدوام يبدأ 9 صباحًا؟ يجب أن تأتي يوميًا قبل الموعد المُحدّد. إن لم تكن أول شخص يلتزم بالقانون فلا تتوقّع من أحد الالتزام به أيًا كانت الحجّة.

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

“الأجايل (Agile)، أو المرونة، هو مفهوم لا يُمكن قبول أية استثناءات فيه، ولا يُمكن البدء باستخدامه بناءً على قرارات ليست سليمة كأن توافق على طلب العميل في تنفيذ المشروع خلال فترة شهر في وقت يستغرق فيه المشروع ثلاثة أشهر على أرض الواقع. لا “أجايل” ولا حتى أي مفهوم تطوير برمجيات آخر سيفي بالغرض.

بناءً على ما سبق، وبعد الاستماع لطلبات العميل، تحتاج لوضع فترة زمنية منطقيّة، وفي حالة موافقة جميع الأطراف عليها، يُمكنك البدء في الاعتماد على “الأجايل” لتقسيم المهام ومواعيد تسليمها.

إدارة الفريق

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

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

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

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

عقد قران

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

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