كيف أقوم بتطوير مشروع تقني بشكل صحيح؟
هذه السلسلة هي نتاج تجارب عديدة في تطوير المشاريع التقنية بالتالي قد تحتمل الصواب والخطأ.
سأفترض أولاً أنني قمت بجمع المتطلبات الرئيسية والتي استطعت عن طريقها بناء الفريق المناسب ورصد الميزانية الخاصة بالمشروع وقمت أيضاً بتحديد التقنيات التي سأستخدمها، طبعاً كل نقطه مما سبق يعتبر موضوع مستقل تماماً.
اذاً، من أين أبدأ الآن؟
سأقوم بتجاوز بعض التفاصيل المتشعبة والتركيز على الأساسيات التي أراها أكثر أهمية و سأحاول الاختصار قدر الامكان في هذا الجانب حتى لايتشتت القارئ.
سأقوم بتجاوز بعض التفاصيل المتشعبة والتركيز على الأساسيات التي أراها أكثر أهمية و سأحاول الاختصار قدر الامكان في هذا الجانب حتى لايتشتت القارئ.
يجب علينا قبل كل شي تحليل المتطلبات التي قمنا بجمعها من صاحب المشروع وفهم الفكرة الأساسية ثم كتابتها على هيئة نقاط من خلالها تتضح صلاحيات كل مستخدم يملك صلاحية الدخول للمشروع " سواءً كان تطبيق أو موقع الكتروني".
سأبدأ بإفتراض أن صاحب المشروع طلب مني بناء تطبيق اقتصاد تشاركي بحيث تقوم الفكرة على أساس أن المستخدم يستطيع طلب خدمة توصيل غرض معين من نقطة الى نقطه أخرى.
ثم سيقوم مزود الخدمة باستقبال الطلب والبدء في عملية التوصيل ثم استلام المبلغ من العميل بعد الانتهاء من التوصيل.
أول خطوه بعد فهم التصور العام للفكرة هي تحديد المستخدمين وأنواعهم، ثم صلاحياتهم وبالمثال السابق لدينا:
أول خطوه بعد فهم التصور العام للفكرة هي تحديد المستخدمين وأنواعهم، ثم صلاحياتهم وبالمثال السابق لدينا:
١- مدير النظام (المسؤول عن مراقبه العمليات ومتابعه جميع المستخدمين من خلال لوحة تحكم شاملة).
٢- العميل وهو من سيقوم بطلب الخدمة.
٣- مزود الخدمة وهو من سيقوم بتنفيذ الخدمة.
٢- العميل وهو من سيقوم بطلب الخدمة.
٣- مزود الخدمة وهو من سيقوم بتنفيذ الخدمة.
من الممكن أيضاً رسم حالة الاستخدام لكل مستخدم وما هي صلاحياته بالنظام ، ولنأخذ مثال بسيط على ذلك:
يمكن تطبيق المثال السابق على جميع المستخدمين لمعرفه حالات الاستخدام (Use case) وأكيد سبق ومرت على طلاب وطالبات الحاسب.
كما يمكن لبعض المتخصصين في هذا المجال تفصيلها بشكل كبير لتوضيح إطار عمل النظام بشكل كامل ورصد الوظائف الأساسية والثانوية ورسم جميع السيناريوهات المحتملة.
الخطوة التالية وهي تحليل خصائص النظام ومعرفه أدوار وصلاحيات كل المستخدمين، وقد تستند على حالات الاستخدام السابقة ، ويوجد بعض الاشخاص الذين قد يتجاوزون الخطوة السابقة (Use case) دون الاضرار بالصلاحيات ويأتي ذلك حسب الخبرة والممارسة.
يجب تطبيق تحليل خصائص النظام على جميع المستخدمين داخل إطار المشروع ويوجد عدة أنواع من الطرق للتحليل ولكن سأبسطها قدر الامكان من خلال شرح المثال التالي:
لنأخذ المستخدم "مزود الخدمة" ونقوم بتحليل خصائصه:
١- يستطيع مزود الخدمة التسجيل بالتطبيق.
٢- يسمح النظام لمزود الخدمة بالتسجيل في حال أكمل الخانات المطلوبة.
٣- يستطيع مزود الخدمة الدخول للتطبيق.
٤- يسمح النظام لمزود الخدمة الدخول للتطبيق وعرض الصفحة الرئيسية.
١- يستطيع مزود الخدمة التسجيل بالتطبيق.
٢- يسمح النظام لمزود الخدمة بالتسجيل في حال أكمل الخانات المطلوبة.
٣- يستطيع مزود الخدمة الدخول للتطبيق.
٤- يسمح النظام لمزود الخدمة الدخول للتطبيق وعرض الصفحة الرئيسية.
٥- يستطيع مزود الخدمة استعراض الطلبات المرسله من المستخدم "العميل".
٦- يسمح النظام لمزود الخدمة من استعراض الطلبات ضمن محيطه بالخريطة.
٧- يستطيع مزود الخدمة قبول طلب خدمة توصيل.
٨- يقوم النظام بحجز الطلب لمزود الخدمة بحيث لا يستطيع اي مزود آخر الاطلاع على هذا الطلب او قبوله.
٦- يسمح النظام لمزود الخدمة من استعراض الطلبات ضمن محيطه بالخريطة.
٧- يستطيع مزود الخدمة قبول طلب خدمة توصيل.
٨- يقوم النظام بحجز الطلب لمزود الخدمة بحيث لا يستطيع اي مزود آخر الاطلاع على هذا الطلب او قبوله.
٩- يقوم مزود الخدمة بالاطلاع على تفاصيل الطلب.
١٠- يسمح النظام لمزود الخدمة استعراض تفاصيل الطلب.
هذا مثال مبسط لآلية تحليل خصائص وصلاحيات المستخدمين.
١٠- يسمح النظام لمزود الخدمة استعراض تفاصيل الطلب.
هذا مثال مبسط لآلية تحليل خصائص وصلاحيات المستخدمين.
يمكن وضع كل نقطه مما سبق بسيناريو منفصل يوضح جميع محتويات الشاشات واشتراطاتها والخانات المطلوبه من المستخدم (User story).
بالاضافة لحصر جميع رسائل الخطأ والسيناريوهات البديله للمستخدم، كما يجب ترقيم الوظائف لتكون مرجع لأي طرف يعمل بالمشروع سواءً المصمم ، المبرمج أو المختبر.
بالاضافة لحصر جميع رسائل الخطأ والسيناريوهات البديله للمستخدم، كما يجب ترقيم الوظائف لتكون مرجع لأي طرف يعمل بالمشروع سواءً المصمم ، المبرمج أو المختبر.
أصحاب التجارب في هذا العالم يقومون أحياناً بتجاوز هذه الخطوة أيضاً وهنا الموضوع قد يكون له تبعات سيئه في حال نقص الخبرة، كما أن ذلك القرار يعتمد على حجم المشروع وإطار العمل وظروف المشروع.
طبعاً تجاوز هذه الخطوة ليس بمعنى الانتقال للعمل البرمجي او التصميم، فأحيانا يكون اختصار بعض الأمور يضاعف عليك الوقت في مرحلة ما (مرحلة الاختبار على سبيل المثال).
الخطوة التي قد يتم الانتقال لها هو البدء في رسم Sketch للتطبيق او الموقع وحصر ما ذكرناه سابقاً في الرسم التوضيحي بحيث يتم التعامل معها دون قراءة أي مستندات وفهم ومعرفه آلية ترابط الشاشات...يتبع
...ومن المهم جداً في هذه الخطوة هو عرض هذه المرحلة أول بأول على صاحب المشروع وأخذ الموافقات منه ، لأن أي تعديل لاحق قد يؤثر بشكل كبير على جميع الشاشات او ترابطها وهيكلتها.
والبعض لا يكتشف مثل هذه الاخطاء الا بعد البدء في مرحلة البرمجة وهذا له تبعات سيئة كون الوقت الذي سيتم استغراقه لحل المشكلة قد يؤثر على جميع مراحل المشروع.
ما هي مزايا مرحلة الـsketch؟
١- المرحلة مناسبة لتكوين الفكرة من خلال العصف الذهني ورسم ملامح التطبيق الأساسية مع صاحب المشروع.
٢- بناء أساس قوي من خلال وضع العناصر الأساسية وتهيئتها للمرحلة القادمة.
٣- تقوم بتسريع الخطوات القادمة.
٤- تقوم بتهيئة مرحلة الـWireframe.
١- المرحلة مناسبة لتكوين الفكرة من خلال العصف الذهني ورسم ملامح التطبيق الأساسية مع صاحب المشروع.
٢- بناء أساس قوي من خلال وضع العناصر الأساسية وتهيئتها للمرحلة القادمة.
٣- تقوم بتسريع الخطوات القادمة.
٤- تقوم بتهيئة مرحلة الـWireframe.
هذه المرحلة تقوم أيضاً بعكس أفكارك بحيث تصبح شفافة لفريق العمل وصاحب المشروع أيضاً مما يسهل الوصول لأفضل فكرة.
مثال:
مثال:
الأن سأنتقل للخطوة التالية وهي مرحلة الـWireframe.
قبل كل شيء (Wireframe is not a sketch).
قبل كل شيء (Wireframe is not a sketch).
عندما نقوم بالعمل في مرحلة الـ Wireframe فإن الهدف ليس نفسه في مرحلة الـsketching، لانه و في هذه المرحلة سنقوم بتوضيح آلية العمل بشكل أدق عن طريق العناصر الرماديه والتي ستقوم برسمها من خلال استخدام برامج مخصصة لذلك.
كما أن هذه المرحلة من خلالها ستقوم بتفصيل أكثر للشاشات لاستعراض الجوانب التي لا يمكن استعراضها بالمرحلة السابقة مثل حجم الخط او ارتفاع الصورة او ترتيب العناصر في الشاشة.
كما أنك مع الفريق ستقومون بدراسه ترتيب وتركيب العناصر وتوزيعها بالشاشة وليس فقط وضعها بشكل عشوائي.
من خلال هذه المرحلة سيتمكن المصمم من فهم (كيف سيكون شكل الشاشة).
في نهاية هذه المرحلة يجب أن تكون الفكرة مصقولة وواضحة.
في نهاية هذه المرحلة يجب أن تكون الفكرة مصقولة وواضحة.
من المراحل السابقة ستكون قد اكملت الجزء المهم وحان الوقت للدخول للعمل الرئيسي.
سيكون أمامنا الآن أربع مراحل رئيسية:
سيكون أمامنا الآن أربع مراحل رئيسية:
١- مرحلة التصميم، لن تقوم بتصميم جميع الشاشات دفعة واحدة ، ستقوم فقط بتصميم شاشتين او ثلاث لعرضها على صاحب المشروع وفي حال حصلت على الموافقة فأبدأ بتصميم بقية الشاشات وعرضها أول بأول وإياك وقبول التعديلات التي قد تؤثر على أساسات عمل المشروع كإضافة مستخدمين جدد او تعديل الصلاحيات
او تغيير هيكلة الشاشات التي تم الاتفاق عليها في مرحلة الـ Wireframe.
طبعاً فائدة تصميم شاشتين او ثلاث شاشات وعرضها على صاحب المشروع لايضاح شكل التصميم العام للتطبيق.
من التهور تصميم جميع الشاشات ثم عرضها دفعة واحدة ، فقد يقوم برفض التصميم وطلب مقترح آخر!
طبعاً فائدة تصميم شاشتين او ثلاث شاشات وعرضها على صاحب المشروع لايضاح شكل التصميم العام للتطبيق.
من التهور تصميم جميع الشاشات ثم عرضها دفعة واحدة ، فقد يقوم برفض التصميم وطلب مقترح آخر!
من المهم معرفة أن لكل تطبيق تجربة مختلفة بشكل نسبي عن الآخر وهذا يعتمد بشكل أساسي على (User experience) الخاصة بكل منصة ولحفظ الوقت والمال يجب على المصمم الاطلاع على القواعد الارشادية الخاصة بـ Apple أو Google.
Android material design:
material.io
material.io
iOS Human Interface Guidelines:
developer.apple.com
developer.apple.com
٢- مرحلة بناء الـBack-End، والتي سيسبقها اجتماعات مكثفة بين فريق مبرمجي الـFrontend و الـBackend ، والهدف من هذه الاجتماعات هو الخرورج باتفاق يخص شكل البيانات التي سيقوم الـBackend بإرسالها للـFrontend ولا علاقة لصاحب المشروع الاطلاع على هذا الجانب.
الا في حال كان يملك فريق تقني ويرغب باستلام المشروع من بعدك للعمل عليه بالتالي آرائه او آراء فريقه سيكون لها اعتبار.
وتعتبر مهمه لانها ستحد بشكل كبير من المفاجأت التي قد تحصل لاحقاً في مرحلة تطوير التطبيقات.
وتعتبر مهمه لانها ستحد بشكل كبير من المفاجأت التي قد تحصل لاحقاً في مرحلة تطوير التطبيقات.
من المهم أيضاً وضع بيئة تطوير خاصة بمرحلة ما قبل الاطلاق (Development) ومرحلة ما بعد الاطلاق (Production) بعض المطورين يقومون بوضع أكثر من ذلك وهذا يختلف حسب خطة عمل الفريق والفرق التي ستعمل معه، ولكن أنصح بالابتعاد عن تطوير المشروع على بيئة واحدة فقط.
لا تقلق ان لم تفهم هذه المرحلة فهي موجه بشكل رئيسي للمبرمجين.
لتفاصيل أكثر عن بيئة التطوير: deploybot.com
لتفاصيل أكثر عن بيئة التطوير: deploybot.com
٣- مرحلة بناء وتصميم الـFront-End وهي تستند بشكل مباشر على المرحلتين السابقتين.
٤- مرحلة الاختبار، يوجد عدة طرق للاختبار ولكن سأقوم بسرد طريقة بسيطة، وهي الاعتماد على ( Test cases ) بالاستناد على التصميم والتحليل الذي سيعتبر كمرجع لمن سيقوم بالاختبار ، هذا الفيديو لتوضيح فكرة وطريقة الاختبار:
youtube.com
youtube.com
طبعاً يوجد أكثر من منهجية للعمل على المراحل أعلاه أشهرها باستخدام الـAgile methodology Or Waterfall methodology من خلالها ستختلف المخرجات لكل مرحلة حسب المنهجية المتبعة والذي سينعكس على إطار العمل الذي سيتم انجازه واختباره
هذا الموضوع يحتاج لسلسة أخرى نتحدث فيها عن منهجيات العمل في هذا النوع من المشاريع.
هل بالإمكان إطلاق المشروع مع وجود اخطاء برمجيه؟ وما هي الأخطاء التي يمكن او لا يمكن الإطلاق بها؟ من سيقرر ذلك اصلاً؟ سيكون لنا أيضاً ان شاء الله سلسلة تجيب عن هذا التساؤل.
أخيراً وبعد الانتهاء من العمل والحصول على موافقة العميل للبدء باجراءات إطلاق المشروع بشكل رسمي سنقوم برفع التطبيقات على متجر ابل وجوجل، وهذا أيضاً موضوع مستقل بحد ذاته.
ملاحظات لابد أن تنتبه لها:
١- مدة العمل على المشروع هي مدة العمل على (التحليل، التصميم، البرمجة، الاختبار) فلا تدخل ضمن مدة العمل الاجتماعات مع العميل أو انتظار موافقة العميل على جزئية معينه لذلك الأفضل إرسال بريد إلكتروني للعميل تبين له أن العمل سيتم استكماله بعد الرد من طرفه.
١- مدة العمل على المشروع هي مدة العمل على (التحليل، التصميم، البرمجة، الاختبار) فلا تدخل ضمن مدة العمل الاجتماعات مع العميل أو انتظار موافقة العميل على جزئية معينه لذلك الأفضل إرسال بريد إلكتروني للعميل تبين له أن العمل سيتم استكماله بعد الرد من طرفه.
٢- لا تبدأ في مرحلة حتى تحصل على موافقة رسمية من العميل عبر البريد الإلكتروني.
٣- أي مشاكل خارج صلاحياتك أو ليست ضمن نطاق عملك لست مسوؤلاً عنها مثل (مشكلة في عميلة الدفع الإلكتروني) أو (تأخر اعتماد احد التطبيقات في المتجر) فالأمر هنا ليس بيدك وليس للعميل الحق في لومك.
٤- عليك احتساب تكلفة مخاطر للمشروع فلا تظن أن كل سيناريوهات العمل ستكون سعيدة وسلسلة.
٥- أعط نفسك وقت معقول للتفكير في تقييم العمل بشكل كامل وإياك الرد الفوري على العميل بالمدة أو التكلفة.
أعتذر ان سقطت مني نقطة مهمة فهذا الموضوع ضخم جداً وحاولت أن أوجز فيه قدر الامكان لإيضاح الفكرة الرئيسية، وفي حال وجود أي سؤال أو استفسار فأنا جاهز للإجابة عنها ان شاء الله.
جاري تحميل الاقتراحات...