مشروعك الإلكتروني يفشل لأنك لم تكتب المتطلبات جيداً

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

والناحية الثانية: شركات السوفت وير نفسها محتاجة أن تمرّ بهذه الخطوات حتى تقدر تأخذ كل الـ Requirements من العميل.

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

دورة حياة أي مشروع سوفت وير

قبل أي حاجة، السوفت وير هذا يُعمل إزاي أصلاً؟

بدايته خالص فكرة: عندي فكرة أريد أن أنفّذها. الخطوة التي بعدها أن تبدأ تعمل Requirements أو متطلبات: أنا أريد أن أعمل واحد واثنين وثلاثة وأربعة.

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

وحتى صفحة الهبوط البسيطة هذه ممكن يكون فيها كذا متطلب. هل تريد أن تضع الفيديو فقط، أم تضع معه سابقة أعمالك؟ والفورم نفسها: أنت محتاج فيها ثلاث خانات — الإيميل ورقم التليفون والاسم — وبعدها يدوس ويُرسل؟ أم أنه سيكتب رسالة كمان؟ أنا أضرب مثالاً وأحاول أخلّيه أبسط ما يكون، ومع ذلك القرارات فيه ليست واحدة.

فأذهب لشركة السوفت وير وأقول له: عندي فكرة، ومتطلباتي واحد واثنان وثلاثة. يأخذ منك الـ Requirements، ثم:

1. الديزاين. يبدأ يعمل لك ديزاين السوفت وير — وهذا ليس ديزاين الفوتوشوب. هذا الرسم الإنشائي: تماماً كما تبني عمارة فترسم رسمها الإنشائي — أين الأوض، وأين الأعمدة. فيقول لك: هذه هيكلة الصفحة، وهذا شكلها، والفيديو سيكون هنا. توافق على الـ Wireframe أو على شكل الصفحة.
2. الـ UI. بعدها يعمل التصميم الخارجي: الـ User Interface، أو واجهات المستخدم.
3. الـ Backend. بعد ما يخلص، يبدأ يعمل الباك إند لو فيه باك إند — لو فيه Database وسيربطها بها.
4. الـ Testing. يبدأ يعمل Test: هل هذه الفورم شغّالة فعلاً وتأخذ الأرقام أم لا؟
5. ما بعد الـ Test. ستظهر مشاكل: أدوس على الفورم فيبعث لي المستخدم مرتين، ومرة لا يبعث أصلاً، ومرة يدوس فتقعد الصفحة تحمّل ولا توصله لحاجة. فيبدأ يأخذ هذه المشاكل ويحلّها.

ثم تقول: لا، أنا أريد الفورم بعد ما يسجّل يذهب ليدفع Online. والدفع الأونلاين هذا لم يكن موجوداً — إذن هناك مرحلة سنزوّد فيها الجديد، فنرجع للـ Cycle من الأول: نأخذ الـ Requirement، ونفصّصه ديزاين، ثم Development، ثم Testing، ثم الصيانة.

هذه هي دورتك في السوفت وير: سواء صفحة هبوط بسيطة، أو سيستم ERP وأنظمة كبيرة للشركات. أي سوفت وير في الحياة سيُعمل بهذه الطريقة.

أين ينتهي دورك أنت

الآن، الديزاين ليس شغلك، ولا الـ Development، ولا الـ Testing. هذه كلها حاجات شركة السوفت وير.

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

الـ Requirements. هذا هو الجزء الخاص بك.

ولما تذهب لشركة وتأخذ منك الـ Requirements بالطريقة التي سنقولها، اطمئن.

نرجع لمثال صفحة الهبوط. الفيديو الذي أريد أن أضعه: أذهب للشركة وأقول لهم إنني أريد صفحة هبوط أقدر أن أرفع فيها الفيديو بتاعي. جميل. بالنسبة له، سيأتي ويقول لك: هذا الفيديو يُفترض أن يُرفع بثلاث صيغ مثلاً — MOV و MP4 وصيغة ثالثة. والفيديو حين يُرفع سيُعمل له Compress، ثم يذهب في الداتابيز في المكان الفلاني. ولما آتي أعمل Recall للفيديو سيكون بالطريقة الفلانية، وسيكون Lazy Load — يعني لا يفتح معك الفيديو على طول أو يفتح.

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

لكن الطرف المقابل من هذا: لو ذهبت وقلت “أنا أريد موقعاً”، فقال لك “هذا بـ 5000 جنيه” من غير ما يعرف متطلباتك — كده اهرب.

المتطلبات التي لا علاقة لها بالسوفت وير أصلاً

هنا الجزء الذي يسقط من الجميع تقريباً. جزء من متطلباتك ليس له علاقة بالسوفت وير نفسه بقدر ما له علاقة بالقانون أو بالمؤسسة أو بطبيعة منتجك.

• القانوني. في دولة معيّنة غير مسموح بحاجة معيّنة. فيصير المتطلب: النظام يشتغل على الموبايل في كل مكان ما عدا هذه الدولة. هذا متطلب لا علاقة له بالسيستم، له علاقة بالقانون الموجود في البلد.
• الخاص بالمؤسسة. أنت بنك مثلاً، فمن Policies البنك أن يكون السيرفر بالشكل الفلاني. هذا ليس مطلوباً حتى يشتغل السوفت وير — هو مطلوب لأن المؤسسة نفسها تشترطه.
• الخاص بالمنتج. أنت اليوم تبيع منتجاً له خصائص معيّنة، فلازم السوفت وير يخدمه بهذا الشكل. هل تبيع كورساً؟ أم كتاباً إلكترونياً؟ أم استشارة؟ وداخل الكورس نفسه: هل ستعمل كورساً مسجّلاً — Recorded — أم كورساً لأطفال في المدرسة زي الدروس الخصوصية؟ الاثنان مختلفان تماماً في المتطلبات.

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

والحاجة الثانية بعدها: المتطلبات داخل السوفت وير نفسه. أنا أريد الطالب أن يقدر يدخل يأخذ الـ Quiz، والمدرّس يقدر يدخل يضع الفيديو. فتبدأ تحطّ ما تريده من النظام. ثم نقطة أخيرة: لو فيه أي Acquire من بره — أي شيء تحتاجه من طرف ثالث — لازم تكون حاطّه ومفكّراً فيه من الأول.

الـ Specifications: من يكتبها ومن يدفع ثمنها

الجزء الخاص بخصائص الأبلكيشن أو الويب سايت — الـ Specifications — هو ما يُفترض أن تقدّمه لك شركة السوفت وير، أو تقول لك: نحن سنشتغل على واحد واثنين وثلاثة وأربعة.

فيه شركات تقدّمها مجاناً — نحن نقدّمها مجاناً. وفيه شركات تأخذ عليها Fees، وهذا طبيعي وعادي. ممكن نقول إن 60 أو 70% من الشركات تأخذ Fees على الجزء الخاص بـ “أنا سأعمل لك الـ Specifications بتاعتك”.

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

نموذج يجمع ذلك كله: من العالم إلى الآلة

فيه نموذج تقدر تشتغل به، فكرته أنه أخذ حرفاً من أول كل مرحلة، ومراحله خمس:

1. العالم (World). ما الموجود حولك؟ خذ صفحة الهبوط التي تكلمنا عنها، وسنضيف لها خاصية الدفع الإلكتروني: العميل بعد ما يختار الخدمة يدفع إلكترونياً. أول حاجة خالص: أن تكون هناك موبايلات تقبل الدفع، وأن يكون الموضوع قانونياً في البلد التي نحن موجودون فيها، وأن يكون الناس عندهم استعداد ومعرفة بأن يدفعوا أونلاين ولا مشكلة عندهم في ذلك. هذه حاجات حواليك، ليست فيك ولا في السيستم.

وهنا نقطة الوقت. أنت تتكلم على الدفع الإلكتروني اليوم، لكن تخيّل نفس الفكرة في 2002 أو 2003 — بداية الأونلاين. الناس ليست مستخدمة كريدت كاردز، ولا الإمكانيات الموجودة هي نفسها. وضع مختلف تماماً وكلام مختلف تماماً. وفيه أفكار اليوم هي نفسها فكرة الدفع الإلكتروني في 2000: الحاجات التي لها علاقة بالذكاء الاصطناعي ستجد فيها اعتراضات. وفيه أوبر وكريم في 2010 والدنيا حولها في 2023 ليست هي الدنيا في 2010. فستجد أفكاراً عندك تريد أن تنفّذها في 2023 وربما لا تكون مناسبة إلا في 2040.

2. المتطلبات (Requirements). وهي التي شرحناها: الحاجات التي أريدها، من غير أن أتكلم في أي شيء تقني. لن أقول سأستخدم Java، ولن أحدّد فورمات معيّناً للفيديو. لا أتكلم في أي حاجة من هذا خالص.

3. المواصفات (Specifications). هنا يأتي: سأستخدم لغة إيه، وسأعمل إيه، وأي داتابيز.

4. البرنامج (Program). الكود نفسه، الـ Development.

5. الآلة (Machine). وليكن أنا سأعمل موبايل أبليكيشن — فالموبايل الموجود معي هو الآلة. أو سأعمل ويب سايت — فالبراوزر والجهاز الذي سيشغّل الموقع. ولما تأتي تعمل الموقع ستعمله على براوزرات مختلفة وفيرجنز مختلفة، وعلى الموبايل بفيرجن معيّن؛ والموبايل أبليكيشن تقدر تعمله على موبايلات مختلفة.

والمرحلة هذه بالذات من السهل أن تُعتبر بديهية فلا تُكتب — ثم تتحوّل إلى خلاف. لأن “الموقع شغال” ليست جملة كاملة: شغال على أي براوزر، وأي فيرجن، وأي موبايل؟ الإجابة على هذا في الورق أرخص كثيراً جداً من الإجابة عليها بعد التسليم.

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

والجهة الثانية: أنت كشركة سوفت وير

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

فالعميل لن يأتيك ومعه الحاجات هذه مرتّبة. هو عنده فكرة في دماغه، وهو متخيّل أنه قالها لك كاملة. دورك أنت أن تسأله في العالم الذي حوله: هل الموضوع قانوني في بلدك؟ هل عملاؤك أصلاً يدفعون أونلاين؟ وأن تسأله في مؤسسته: عندك Policies تفرض شيئاً على السيرفر أو على الداتا؟ وأن تسأله في منتجه: أنت تبيع ماذا بالضبط، وبأي شكل؟

وحين تسأل هذه الأسئلة أنت لا تعطّل البيعة — أنت تمنع الخلاف الذي كان سيحصل لاحقاً، والذي يكلّفك أضعاف الوقت الذي كنت ستوفّره لو سعّرت بسرعة.

من أين يأتي سوء التفاهم أصلاً

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

وغالباً تكون كلمة واحدة بديهية بالنسبة لك هي التي بوّظت الدنيا. بديهية بالنسبة لك، وليست موجودة عنده في أي ورقة.

فالحل: من الأول نضع كل البدايات في الـ World — بدايات العالم، وبداياتي أنا، وبدايات الشركة عندي. ثم أضع كل حاجة خاصة بي في المتطلبات. ثم يذهب هو ويقول: هذه الخصائص التي سأعملها في السيستم، وهذه لغة البرمجة التي سأشتغل بها، وهذه الداتابيز التي سأتعامل على أساسها. ويضع لك كل التفاصيل هذه. وبعد ما يضع لك الـ Document، يعطيك سعراً.

خلاص، أنت الآن ماشٍ. لكن انتبه: أنت تستلم منه هذه المواصفات، والمفروض أنها تحقق ما وضعتَه أنت في الأول. كلمة زيادة أو كلمة أقل، يبقى عنده مشكلة.

ولو جئت بعد فترة واكتشفت أنك محتاج تعمل حاجة جديدة غير موجودة في هذه الـ Specifications — فالراجل معه حق بالكامل. زي ما تكلمنا في دورة حياة السوفت وير: تأخذ الـ Cycle من الأول من جديد. وهذا ليس تعنّتاً منه؛ هذا هو الشكل الوحيد الذي يجعل السعر يعني شيئاً والتسليم يعني شيئاً.