من مطور iOS إلى رئيس قسم الهندسة: ٧ دروس من ١٠ سنوات
ما الذي تغيّر في الطريق من كتابة تطبيقات iOS إلى قيادة فريق هندسي من ٢٠ مهندسًا: الملكية، والمعايير، والتوظيف، والعادات التي أبقت الفرق قادرة على التسليم.
بقلم محمد طارق الزقرد · · قراءة في ٤ دقائق
بدأت مطورًا لتطبيقات iOS عام ٢٠١٦، حين بنيت النسخ الأولى من تطبيقات المرضى لاثنتين من أكبر سلاسل المعامل الطبية في مصر. وبعد عشر سنوات أتولى رئاسة قسم الهندسة في Spomotion، وأدير كريبتون، شركة البرمجيات التي أسستها. وبين البداية واليوم بنيت وأطلقت بنفسي أكثر من ٥٠ تطبيق iOS لعملاء في الخليج، ثم قدت فريق الموبايل، ثم فريقًا هندسيًا من ٢٠ شخصًا مقسّمًا إلى فرق.
تغيّرت طبيعة العمل أكثر مما تغيّر المسمى الوظيفي. وهذه هي الدروس التي صنعت الفرق، أكتبها للمطورين الذين يفكرون في الانتقال إلى القيادة، ولأصحاب الشركات الذين يقررون من يقود فريقهم الهندسي.
١. إنتاجك يصبح إنتاج الفريق
حين تكون مطورًا، يُقاس يومك الجيد بما أطلقته. وحين تصبح قائدًا، يُقاس بما أطلقه الفريق، ويشمل ذلك العمل الذي أزلت عوائقه أو راجعته أو علّمته. والأشهر الأولى صعبة، لأن العمل الذي تتقنه أكثر من غيره لم يعد العمل الأهم.
والحل ليس أن تتوقف عن البرمجة، بل أن تختار البرمجة التي تضاعف أثر الآخرين: قرارات المعمارية، والمراجعات الصعبة، والنموذج الأولي الذي يحسم نقاشًا. وحين قدت فريق الموبايل احتفظت بالملكية التقنية الكاملة للمعمارية والتقديرات ومراجعة الكود وإصدارات App Store، وتركت تطوير المميزات للفريق.
٢. اكتب المعايير
البطولات الفردية لا تكبر مع الفريق. فريق من المطورين الأقوياء بعادات مختلفة ينتج كودًا لا يستطيع صيانته إلا كاتبه. لذلك كتبنا في فريق الموبايل معاييرنا، وبنيناها على MVVM وClean Architecture، حتى يستطيع أي مطور أن يفتح أي مشروع ويعرف مكان كل شيء.
المعايير ليست مسألة ذوق. إنها تجعل المراجعة أسرع، والتأهيل أقصر، والتقديرات أصدق، لأن الفريق يتوقف عن حل المشكلة الهيكلية نفسها بطريقة جديدة في كل مشروع.
٣. أعطِ كل فريق شيئًا يملكه
حين كبر الفريق إلى ٢٠ مهندسًا، لم يعد مجديًا أن يعمل فريق واحد على كل شيء. فقسّمناه إلى فرق أصغر، يملك كل منها مجموعة من مشاريع العملاء من المتطلبات حتى الدعم بعد الإطلاق.
الملكية تغيّر السلوك. الفريق الذي سيرد بنفسه على طلبات الدعم يكتب الكود بطريقة مختلفة، ويسأل أسئلة أفضل عند جمع المتطلبات، ويهتم بالإصدار حتى بعد إطلاقه بوقت طويل.
٤. التوظيف هو القرار الأطول أثرًا
كل مهندس توظفه يشكّل الفريق لسنوات: الكود الذي يكتبه، والمراجعات التي يقدمها، والأشخاص الذين يساعد في توظيفهم بعده. لذلك أعدت بناء عملية التوظيف حول هدف واحد: رفع المستوى مع كل مهندس جديد، لا ملء المقاعد بسرعة.
وعمليًا يعني ذلك صورة واضحة للدور قبل أول مقابلة، وأسئلة منظمة واحدة لكل المرشحين، وتمرينًا تقنيًا يشبه العمل اليومي الحقيقي. فالموافقة البطيئة أرخص من الخطأ السريع.
٥. وجّه المشكلات بدل أن تحملها
القائد الذي يتولى بنفسه كل مشكلة يرسلها العملاء يصبح عنق الزجاجة، ولا يتعلم الفريق حقًا الأنظمة التي يملكها. لذلك بنينا نظامًا يوجّه مشكلات العملاء مباشرة إلى الفريق المسؤول عن المشروع.
مهمة القائد أن يتأكد من أن هذا الطريق موجود ويعمل، لا أن يكون هو الطريق.
٦. خصّص وقتًا للحديث والتعليم
عادتان أفادتا الفريق أكثر من أي أداة: اللقاءات الفردية المنتظمة، وجلسة أسبوعية لتبادل المعرفة الهندسية. اللقاءات الفردية تكشف المشكلات وهي ما زالت صغيرة، والجلسة الأسبوعية تنقل ما تعلّمه فريق واحد إلى الجميع، فلا يُدفع ثمن الدرس إلا مرة واحدة.
٧. رئاسة قسم الهندسة تعني امتلاك الطريق كله
في Spomotion اتسع النطاق مرة أخرى: معمارية التطبيق، وهيكلة الفريق، والتسليم، والطريق إلى الإصدار النهائي للمنتج. لم يعد السؤال هل الكود جيد، بل هل يصل المنتج إلى الناس، وهل يستطيع الفريق الذي يبنيه أن يستمر في ذلك.
وهذا هو الفرق الحقيقي بين الأدوار: المطور يملك ميزة، وقائد الفريق يملك طريقة عمل الفريق، ورئيس قسم الهندسة يملك قدرة الهندسة كلها على دفع المنتج إلى الأمام.
إن كنت تستعد لهذه الخطوة
- اختر العمل الذي يضاعف أثر الفريق، واترك ما سواه.
- اكتب المعايير قبل أن تحتاج إليها.
- امنح الناس الملكية، بما في ذلك كل ما بعد الإطلاق.
- تعامل مع كل توظيف على أنه قرار طويل الأمد.
- ابنِ طرقًا واضحة للمشكلات، واحمِ وقت اللقاءات الفردية والتعليم.
إن كنت تمر بانتقال مشابه، أو تبني فريقًا هندسيًا لمنتجك، فيسعدني دائمًا الحديث معك.