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