بعد النسخة الأولى: ما يكلفه فعلًا تطوير برنامج مفصَّل

الجزء الظاهر من مشروع برمجي هو بناؤه: تسعيرة، وأسابيع عمل، ووضع في الخدمة. أما الجزء الذي يدوم فهو ما بعد ذلك، وله عملة مختلفة. لم تعد تشتري برنامجًا بل تشتري تغييرات، واحدًا واحدًا، لسنوات.

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

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

لا تستشهد بأي رقم، والقسم الأول يشرح السبب: السؤال الطبيعي «كم يكلف تطوير» ليس له جواب قابل للمقارنة بين تسعيرة وأخرى، والسبب أطرف من الغياب نفسه.

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

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

اكتب الطلب انطلاقًا من حالة ملموسة ومؤرخة لا بعبارات عامة: طلبية ذلك الزبون، تلك التي سببت مشكلة الثلاثاء. الحالة الحقيقية تحوي التفاصيل التي تمحوها الصياغة العامة، وهي بالضبط ما يجعل السعر يتفاوت بخمسة أضعاف.

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

البرنامج ليس جمعًا لوظائف مستقلة. كل إضافة تمس قواعد قائمة، وجزء من كلفة التغيير هو التحقق من أن الباقي ما يزال يعمل. هذا الجزء غير مرئي في الطلب وحقيقي جدًا في التسعيرة.

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

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

ويعطي هذا أيضًا سؤالًا جيدًا يُطرح لحظة التسعير: أي جزء من هذا السعر هو التعديل نفسه، وأي جزء هو التحقق من الباقي. المزود الذي يعرف الجواب فهم نظامه؛ والمزود الذي لا معنى للسؤال عنده يقول لك شيئًا.

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

قائمة ما تغيّر، بلغة عادية، بما في ذلك ما تغيّر دون أن يُطلب. وقائمة القواعد المقررة في الطريق، وهي قواعد القسم الرابع. وتأكيد أن الكود المسلَّم في المستودع الذي تملكه. وما تبقى معلومًا، بما فيه العيوب المقبولة مؤقتًا.

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

وهذه العناصر الأربعة تسع رسالة واحدة. لا تطلب أداة ولا منهجًا ولا مفردات: تطلب عادة، وهي عادة تُؤخذ عند أول تسليم أو لا تُؤخذ أبدًا.

نصيبنا اشتغال هذه الفترة: الطابور المرئي وتحكيمه، والطلب المكتوب في ثلاث فقرات، ومحضر القواعد المقررة عند كل تسليم، والبيئتان، ومستودع الكود الذي تملكه من أول سطر. هذه عادات أكثر منها أدوات، وتُؤخذ في البداية أو لا تُؤخذ.

ونرفض إعطاء سعر متوسط لتطوير، والسبب ليس الحذر: لا توجد وحدة مشتركة. تسعيرتان لـ«الطلب نفسه» تتناولان شيئين مختلفين، وتعريفة معلنة لن تفعل إلا نقل الغموض من التسعيرة إلى الفاتورة. ما نسعّره طلب مكتوب، ونفضّل قضاء ساعة في كتابته معك على الدفاع عن رقم بعد ذلك.

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

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