أداة جاهزة أم تطوير مخصص؟

ابدأ من الحاجة لا من المنتج

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

دوّن أيضًا ما يكلفك العمل اليوم من ساعات أو أخطاء. وبدون ذلك يبدو أي سعر مرتفعًا جدًا أو منخفضًا جدًا.

متى تكفي الأداة الجاهزة عادةً

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

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

متى يبدأ العمل المخصص بأن يكون منطقيًا

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

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

أجرِ تجربة بمهمة واحدة

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

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

مثال افتراضي

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

قرّر ودوّن القرار

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