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