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