تجادلت ذات مرة مع أحد المبرمجين الذي اعتقد أننا لسنا بحاجة إلى كتابة المواصفات. وتوجهت إلى مكتبه حاملاً القالب الذي أخبرني رئيسي أن استعمله، فسخر منه المبرمج (ومني أيضاً للأسف). فقد كان رأيه أنه إذا كان ما أرغب القيام به معقداً إلى درجة أنني بحاجة إلى 50 صفحة لأشرحه للمبرمجين، فإنه لا يستحق أن ينفذ على أية حال. وقد رأي أن الحاجة إلى كل هذه العملية والعمل الورقي، كإشارة إلى الاتصالات والتنسيقات مع الفريق، فاشلة. وأننا لسنا محل ثقة لاتخذا القرارات بشأن الأمور الخاصة، وأننا لسنا بحاجة إلى التكاليف الزائدة والبيروقراطية ، مما يعني أن إغناء التخطيط بالتفاصيل لم يكن ضرورياً أبداً.
قد ابتسمت، باعتباري ناقشت هذا الموضوع من قبل، وسألته إذا كان قد صرح بالشيء ذاته عن الخطط الهندسية للمبنى الذي يضم الشقة التي يعيش فيها ، أو الطرق الرئيسية التي تمر بها أثناء قدومه إلى العمل. ولكن كان من الواضح أنه سمع هذا السؤال من قبل، فابتسم مرة أخرى، وقال: على الرغم من سروره لأنه قد تم تخطيط هذه الأشياء بتفصيل ممتاز، فإنه لا يعتقد أن العمل مع البرمجيات يشبه العمل مع القوانين الفيزيائية ومواد البناء. وقد اتفقنا سريعاً على نقطتين: الأولى أنه بالمقارنة مع الهندسة التقليدية فإن البرمجيات تعتبر أكثر مرونة وأسهل للتغيير ونادراً ما تشكل خطراً على حياة الناس. ولكننا نعلم أنه بسبب مواجهة التحديات الهندسية المعقدة وأن فريق العمل يعتمد على قراراتنا وأنه توجد ميزانيات محددة ومواعيد تسليم يجب تحقيقها، فإننا بحاجة إلى أكثر من ذاكرتنا عن النقاشات السريعة، لنتأكد من أن الأمور تتم بالشكل الصحيح. كذلك اتفقنا أن ما احتجناه لمشروعنا كان مناسباً لنوع العمل الذي كنا نقوم به ونوعيتنا كأشخاص. إن التوثيق المكتوب سيكون مفيداً إذا كان يحل مشكلات حقيقية لفريقنا ويسرع إنجاز الأمور ويرفع من احتمالية جودة النتائج ( ومن الضروري أن يتم تحديثه مع الزمن دون إزعاج أحد). لقد قال إننا إذا تمكنا من إنشاء شيء ما يحقق هذه الأمور فإنه سيستخدمه بسرور، بغض النظر عما نسميه، أو عن صيغته. وهكذا فقد عدلنا مفهوم عملية المواصفات إلى شيء اتفقنا أنه مفيد لفريقنا الصغير. بعدها عدت إلى رئيسي ، وأعدنا مناقشة حوارنا، ووصلنا إلى تسوية واستغنينا عن القالب الكبير.
إن العبرة الأساسية من هذه القصة هي أنه كأي شيء آخر يقوم به الناس، لا توجد طريقة واحدة صحيحة لكتابة المواصفات أو توثيق العمل. والمواصفات، شأنها شأن باقي الأشياء التي عليهم إنشاؤها وقراءتها. وبنفس الطريق حيث يجب أن تمر المنتجات البرمجية ومواقع الوب بعملية التصميم من أجل إيجاد أفضل الطرق، فإن المواصفات بحاجة إلى بعض الأفكار والتكرارات لإنجازها بالشكل الصحيح. إلا أن العديد من الخبراء الذين أعرفهم قد وقعوا في فخ الاعتقاد أن هناك طريقة واحدة لإنجاز المواصفات (أو مهما كانت تسميتها بالنسبة لهم). وهي تميل لأن تكون نفس الطريقة التي اعتمدوها في المرة الماضية. تعود هذه السلسلة من الاسترجاع أحياناً الى المشاريع الأولى التي عملوا عليها. لأنهم يفترضون أنه باعتبار أن تلك المشاريع لم تكن كوارث كاملة، فإن الطريقة التي كتبوا المواصفات باستخدامها قد ساهمت إيجابيا في الوصول إلى النتائج. وهذا ادعاء من دون بحث أو تحقيق، وقد يكون صحيحاً أو لا (يعني أنه من الممكن أن يكون المشروع قد نجح على الرغم من أن عملية المواصفات، فإن أحداً من الفريق لن يفهم حقاً مدى سوء أو جودة كتابة المواصفات، أو مدى مساهمتها أو عدمها في أداء الفريق ( إن هذا مشابه تماماً لمدى تأثير غياب الأسئلة الجيدة عن كتابة شيفرة ذات جودة عالية في منع إمكانية معرفة مدى جودة أو سوء الشيفرة).
إن هدفي في هذا الفصل هو شرح مجموعة من الأفكار التالية، أولاً يجب أن تفيد المواصفات المشروع في أمور ثلاثة: التأكد من تنفيذ الأشياء الصحيحة، وتأمين جدولة بالأركان الأساسية التي تلخص مرحلة التصميم للمشروع، وتسمح بالمراجعة العميقة والتغذية الراجعة من أفراد مختلفين طوال فترة المشروع. إن هذه الأمور الثلاثة ضرورة جداً. وليس واردا أن تؤمنها على التوازي عملية أخرى غير كتابة المواصفات. ولهذا السبب فقط ، فإنني معجب بالمواصفات. ثانياً أن معظم شكاوي الناس من المواصفات يمكن تجاوزها بسهولة ، باعتبار أن كاتبي المواصفات يدركون أفخاخ عملية الكتابة، ويدركون الفوائد التي يجب أن تجني من هذه العملية.
ماذا تستطيع المواصفات تحقيقه
إن المواصفات مثلها مثل وثيقة الرؤية، هي شكل من أشكال التواصل، وعندما تستخدم بكفاءة، فإنها تنقل معلومات هامة بطريقة سهلة وبسيطة. وعندما تستخدم بالشكل غير الصحيح فإنها تكون صعبة القراءة. وإنشاؤها ممل وبطيء. وهي مقلقة لكل من له علاقة بها. وغالبا فإن فرق العمل التي تكتب مواصفات خاصة بها تبدو بحاجة إلى المزيد منها.
غالباً تأتي المواصفات الضعيفة أو الفاشلة من سوء فهم إمكانياتها، وما الذي لا يمكنها تحقيقه. فيما يلي قائمة بالأشياء الأكثر أهمية التي يمكن للمواصفات تحقيقها للمشروع:
- تصف بكفاءة وظيفية ما سنقوم به.
- تساعد المصممين على توضيح القرارات بأن تفرض عليهم أن يكونوا محددين.
- تسمح بالمراجعة وطرح الأسئلة ومناقشة الخطط المفصلة قبل أن يبدأ التنفيذ الكامل.
- توصل المعلومات من شخص إلى العديد من الأشخاص.
- تشكل نقطة مرجعية للفريق من أجل خطط محددة ( وإذا تم تشكيل مسودة في مرحلة التصميم، تستخدمها كوثيقة حيوية لما يحدث).
- تؤمن جدولة نقاط علام المراحل الأساسية لتركيز الفريق.
- تعتبر تأميناً في حالة إصابة كاتبها بحادث.
- تسرع، وتحسن وتزيد من تواتر القرارات الصحيحة.
- تقدم فرصة للقادة لإعطاء التغذية الراجعة ووضع معيار الجودة.
- تضفي المنطقية والثقة على الفريق (والكاتب).
الأشياء التي لا يمكن أو لا ينبغي أن تحققها المواصفات:
- تلغي كل النقاشات بين أعضاء الفريق.
- تثبت للفريق مدى ذكاء كاتبها.
- تثبت أهمية إحدى الميزات ( أو لم لا ينبغي الاستغناء عنها).
- تحول آراء الأشخاص إلى وجهات نظر فلسفية.
- تشكل مساحة لعرض مهارات الكاتب في استخدامVisio أو UML
يجب أن يتعاون قادة الفريق على وضع قائمة مثل هذه لكي يستخدمها الفريق. وعلى كل من يجب عليه قراءة أو كتابة المواصفات أن يراجع هذه القائمة ويعطي رأيه بها قبل كتابة أي مواصفات. وقد تكون هناك أشياء مسرودة في القائمة لا يحتاج الفريق إلى مواصفات من أجلها، أو أن هناك شيئاً ما غير موجود في القائمة ويجب أن يضاف. وهذا عبارة عن نقاش سريع يستغرق نصف ساعة على أعظم التقدير، وحتى يمكن أن تحدد محاورة سريعة التوقعات لما تساهم به المواصفات ، وتمنح الفريق فرصة لتقديم الاقتراحات عن الطرق الأفضل لتشكيلها. وإذا توفر قالب للمواصفات على مستوى الفريق فإنه يجب أن يسجل مع تذكر هذا المعيار.
اتخاذ القرار بشأن ما يلزم توصيفه
تعرف كل المنهجيات التي رأيتها بالتطور البرمجي أو إدارة المشاريع ، التوصيفات بطريقة مختلفة. ألا أنني لم أقلق كثيراً لهذا الشأن، حيث توجد أربعة أنواع أساسية من المعلومات التي تنتهي على شكل مواصفات، وأسهل طريقة لمناقشتها هي افتراض أنها تنتهي على شكل أربع وثائق مختلفة. ولكن كيفية تقسيم هذه الأشياء ليست مهمة بالضرورة (رغم أن بعض الأشخاص يعيرونها الكثير من الأهمية). إلا أن المهم حقاً هو أن تحدد المعلومات الصحيحة من قبل الأشخاص المناسبين، وأن تنتج بطريقة مفيدة للأشخاص الذين يحتاجونها. وبالتالي، فإنه في حال فرق العمل الصغيرة، يتم غالباً دمج هذه الأنواع المختلفة، أما في حال الفرق الأكبر، فقد تكون هناك حاجة إلى فصلها ( ولكن مع المحافظة على ارتباطها). وحتى إنه يجب أن تتم كتابتها من قبل أشخاص مختلفين.
- المتطلبات: من الجل توثيق الأشياء العديدة المتوقعة من المشروع، فإن توصيف المتطلبات يحدد الإطار العام لكل الطلبات والفروض التي يجب أن يتآلف معها العمل. فهي تدمج جميع متطلبات العمل الأخرى ضمن نظام، وتشكل نقطة مرجعية للمشروع. بأحسن الأحوال، هي عبارة عن قائمة من شروط النجاح، وتصف ما ستكون عليه النتائج النهائية، دون الكثير من الشرح عن كيفية تحقيقها. وبجميع الأحوال، يجب أن تعرف المتطلبات قبل أن تبدأ عملية التصميم (رغم أنها يمكن أن تتحسن وتحدث لاحقاً). كما يجب أن تشتق من وثيقة الرؤية، وأن تكون ضمن مواصفات المزايا من أجل الوضوح والمساعدة على المراجعة (هل ستحقق هذه الخطة المتطلبات؟).
- السمة: إن توصيف السمة يصف سلوك ووظيفة سيناريو محدد أو مجموعة سيناريوهات من وجهة نظر الزبون. وهي الناتج الأساسي لعملية التصميم، فهي تصف وظيفة البرمجة من عبر واجهة المستخدم ( إذا وجدت)، وتفصل كيفية عمل الأشياء انطلاقا من وجهة النظر الأبعد عن التقنية. كما أنها يجب أن تصف كيف ستتغير خبرة الزبون عندما ينتهي العمل، ويجب أن تحوي تصنيفاً بسيطاً لبنود العمل المعرفة هندسياً التي يجب تحقيقها. إن هذا يختلف عن قائمة المتطلبات في أنها تعرف تصميما محددة يحقق المتطلبات، ويتضمن واجهة التفاعل مع المستخدم أو عناصر تصميمية مهمة.
- المواصفات التقنية: تفصل الطرق الهندسية اللازمة لتحقيق توصيف السمة. ويجب تفصيلها فقط بما يكفي لوصف الأجزاء الأكثر تعقيداً أو التي يعاد استخدامها من قبل مبرمجين آخرين، ولتأمين الدليل الداعم لبنود العمل اللازمة لتوصيف السمة. أحياناً يلغي عمق الطبيعة التقنية لتوصيف السمة الحاجة إلى مواصفات تقنية مستقلة
- قوائم بنود العمل: هي مماثلة تقريبا لبنى تقسيم العمل WBS. إن قائمة بنود العمل هي الوصف لكل واجب برمجي لازم لتحقيق توصيف السمة، ويجب أن تقسم إلى مستوى من التفصيل تفصل البنود ذات المستويات المختلفة من الأهمية بوجود تقديرات مقيسة بالأيام (يجب وضع بعض الحدود على حجم بند العمل، ربما يوم أو نصف يوم، ويبقى الموضوع عائدا للمبرمج) أو القائد أو مدير المشروع (تقنيا لا تعتبر قائمة بنود العمل مواصفات، وإنما هي خطة لكيفية تحقيق المهندسين للمواصفات. على كل، إنها هامة جداً ومتعلقة بالمواصفات حتى إنني لم أجد مكاناً أفضل لتقديمها).
- معيار الاختبار ومعيار انتهاء نقاط العلام: مع تشكيل مواصفات السمة كاملة، يجب تشكيل معيار الاختبار. ويجب أن يتضمن هذا حالات اختبار مرتبة بالأوليات للوظيفة الجديدة، على توافق مع الأهداف عن مدى جودة الشيفرة اللازمة لتعمل على هذه الحالات لكي تحقق أهداف الجودة لنقطة العلام الأساسية ( أو كما يقال عنه معيار الخروج، راجع الفصل 15). دعني أقدم لك مثالاً عن كيفية دمج هذه الأنواع المختلفة من معلومات المواصفات: كلما عملت مع فريق عمل كبير وكان هناك العديد من المهام التخصصية، فمن الشائع أن ندون كلاً من مواصفات السمة والمواصفات التقنية. كما كنا نشتق المتطلبات من الرؤية، ونراجعها مع الفريق أو الزبون ومن ثم نضعها في بداية مواصفات السمة لقد ولدت قوائم بنود العمل من قبل المبرمجين (غالبا، باستخدام ورقة عمل بسيطة على مستوى الفريق)، وتم نسخها أو ربطها مع مواصفات السمة، وبهذا انتهينا بمواصفات أساسية واحدة تتضمن العديد من أنواع معلومات المواصفات التي وضعناها للتو. إن أسهل طريقة للتفكير بهذه الأنواع الأربعة للمواصفات هي بترتيب زمني تقريبي: المتطلبات، والسمة، والتقنية ، وبنود العمل. يؤمن كل من هذه الأنواع الأربعة للمعلومات، شأنها في ذلك شأن العديد من مهام المشروع الأخرى، الأساس لما سيلي ذلك. وكلما ازداد حجم الفريق وتعقيد المشروع ، ازدادت احتمالية الحاجة إلى رفع صياغة التقسيم بين هذه الأنواع من المواصفات.
من المسؤول عن المواصفات؟
في فرق العمل الكبيرة، يجب أن يكون مدراء المشروع أو المصممون هم المسؤولين عن تحديد السمة والمبرمجون هم المسؤولين عن المواصفات التقنية . ويجب عليهم كتابة هذه الأشياء بطريقة توحي لمن يقرأ كلا الوثيقتين أن كاتبيها يعرف أحدهما الآخر حق المعرفة، ويتحاوران باستمرار. غالباً، تكون المواصفات التقنية أقصر(أو أقل عطاء للقارئ) لأن جمهورها أصغر، كما أن المبرمجين لا يهتمون بكتابة أشياء لن تتحول إلى برامج تنفيذية ومع هذا، فإن المواصفات التقنية التي تدعم التصاميم في مواصفات السمة يجب أن تتطابق. غالباً يقوم محللو الأعمال أو العملاء أو مدراء المشاريع بكتابة وثائق المتطلبات،ويعتمد هذا على من لديه سلطة المتطلبات، وعلى طبيعة عمل فريق المشروع (فريق مستأجر صغير ، أو فريق كبير من موظفي المنظمة). إن قوائم بنود العمل هي مسؤولية كل من يدير فريق المبرمجين، ويكون عادة في المنظمات الكبيرة هو قائد المبرمجين. أما في الفرق الصغيرة فإن هذا كالعادة يعتبر أمراً أقل هيكلية. فقد لا توجد سياسات صارمة تحدد من الذي سيقوم بماذا. أو ما الوثائق اللازم كتابتها. وقد ينتهي الأمر بمدير المشروع أو قائد المبرمجين بكتابة وثيقة واحدة هي مزيج غير متكافئ من هذه الأنواع الأربعة للمعلومات. والتنقل بينها لملائمة الاحتياجات الفعلية لفريقه. وقد يكون هذا جيداً باعتبار أن الناس يحصلون على ما يحتاجونه عندما يحتاجونه.
التوصيف ليس تصميماً
لقد عرف الفصلان السابقان عملية التصميم على أنها كيفية العمل مع الأفكار وتطويرها إلى خطط. وتكمن أهمية عملية التصميم المعرفة في فصل إجراء التصميم والعمل التخطيطي عن إجراء كتابة المواصفات من أجلها. كما يجب أن يركز تشكيل المواصفات، قدر المستطاع، على التعبير عن خطة موجودة أو مجموعة قرارات بأفضل طريقة ممكنة، أكثر من تصميم تلك الخطة بنفس الوقت. وكلما قل الفصل بين هذين الأمرين، صعب إنجاز كل منهما. كما أن تنفيذ هاتين العمليتين بشكل مستقل يعتبر صعباً، وكلما حاول الشخص أن يقوم بهما معاً في نفس الوقت، انخفضت احتمالات إنجاز كل مهمة بالشكل المناسب.
يجب أن يدرك كاتبو المواصفات طرق التفكير المختلفة هذه بين التصميم والتوصيف. وعندما يقررون كتابة المواصفات، عليهم أن يتوقفوا عن الاستكشاف والإنشاء، والتركيز على التعبير والتفسير. أو على الأقل يجب أن يخططوا للعودة أو المراجعة المحكمة للوثيقة لتعكس رأي المفسر أكثر من المنشئ. وفي أي وقت تكتب فيه المواصفات ( أو أي شيء آخر)، من المهم تذكر أن الطريقة التي اكتشفنا فيها شيئا ما ، ليست دائما أفضل طريقة لشرح هذا الشيء للآخرين.
وصف التصميم النهائي مقابل كيفية تنفيذه
رغم أنه من الممكن دمج توصيفات السمة مع المواصفات التقنية ضمن وثيقة واحدة، فإنها يجب أن تكون على الغالب مقاطع منفصلة بوضوح.
إن واحدة من أسوأ المواصفات التي قرأتها، وقعت في فخ تنفيذ هذين الأمرين مرة واحدة. وعلى قدر ذكاء وإمكانيات الكاتب، فقد حاول وصف التصميم وبنفس الوقت شرح كيفية بنائه. وقد كان واضحاً، بمجرد فتحي للوثيقة، كم الوقت الذي قضاه في كتابتها. فقد أنشأ مخططات احترافية غاية في الدقة لتظهر العلاقات بين العناصر والمكونات، وفي نفس الوقت وضعها في مخططات وفقاً لمصطلحات كيفية استخدامها من قبل الزبائن. كانت النتيجة عبارة عن كارثة شديدة التنقيح والجمال. فقد بدت المواصفات جذابة، ولكن بعد خمسة دقائق من قراءة هذا الشيء والمحاولة الشديدة لتقبله، لم يكن بوسعي سوى أن أؤنبه ( وبالطبع فقد استجاب فريقه بنفس الشكل) لقد حاول مرات عديدة أن يجعل الناس يتفهمونها، لكن هذا للأسف لم يزد إلا في استجاباتهم السلبية ( والعنيفة داخليا).
في محاولة لمساعدته، تكلمت مع كاتب المواصفات وحاولت أن أعرض عليه النصح، واعترف أنه فقد التركيز، وأن المواصفات بحد ذاتها لم تكن بتلك الأهمية، إلا أنه لا يزال يؤمن أن طريقته كانت جيدة. وقد صرح أنه بسبب معرفته بحاجة المبرمجين إلى مرجع لكل من السلوكيات المتوقعة والتفاصيل عالية المستوى للعلاقات بين العناصر، فقد كان من المنطقي دمجها جميعا. بينما كان رأي أنه ولو احتاج الشخص إلى كلا النوعين من المعلومات، فلا يوجد سبب لافتراض أنه بحاجتها في نفس الوقت أو على نفس الصفحة. ومن الأسهل غالباً، أن تقرأ وتكتب بمستوي تفكير واحد، وأن تتعامل مع الموضوع بنفس السوية في كل مرة، من أن تدمجها جميعا. إن المواصفات الجيدة تصف التصميم غالباً ضمن طبقات: الأولى: ما تشرحه تجربة الزبون، بلغته. والثانية: نظرة عامة عالية المستوى إلى العناصر الأساسية والبنية، والثالثة: تغطية لأمور التصميم الهندسية المفصلة والمعقدة.
تبسيط المواصفات الجيدة
إن أصعب شيء على التقنيين هو الاختيار الفعال لأي التفاصيل التي يجب تركها، وفي أي وقت. لقد تعلمت من العديد من الدروس المعقدة والفظيعة في المنطق والحساب أن أفضل المدرسين يعرفون متى يتجاوزون المواضع غير الأساسية، رغم أهميتها، وكيف يعودون إليها عندما يكون الطالب أو القارئ جاهزاً لها. عندما تكون المواصفات مكتوبة بعناية ، فإنها تستخدم نفس النوع من المهارة وتأتي الأساسية خلال ذلك. حيث يكسب الأشخاص فهماً للعمل، ويمكنهم حينها المتابعة مع وجود الوضوح. تكون القوالب الفكرية لديهم والخاصة ببناء الأشياء أكثر تنقيحاً بعد قراءة المواصفات، كما تتحسن نوعية الأسئلة التي يمكنهم طرحها على مدير المشروع أو الآخرين من أعضاء الفريق. ابحث عن هذا الأثر. لن تستطيع إشراك الجميع، ولكن ناضل لتصل إلى أكثر المساهمين أهمية في المشروع. بالطبع، لا يمكن تجنب التعقيد في حالة النماذج الغرضية المعقدة أو الواجهات كثيرة التفاصيل، وقد تتطلب بعض الأشياء بعض الوقت والتفسير حتى يتم استيعابها، ولكن تأكد أن هذه هي الحالة حقاً. وغالباً يكون التعقيد هو لإخفاء الكتابة الضعيفة أو التفكير العادي الخالي من الإبداع. إن الهدف العام من كتابة المواصفات هو وصف الأشياء بطريقة تخفض مقدار العمل الذي يجب على الآخرين القيام به لاستيعابها. وفي أسوأ حالة ممكنة، قد يتطلب استيعاب المواصفات من احد الأشخاص وقتا أكثر من الذي كان سيلزمه ليقوم بالتصميم بنفسه. ولكن باعتبار أهم أمور الكتابة، فإن هذه المعايير تكون تابعة للموضوع لدرجة كبيرة. إن ضبط المستوى الصحيح للوضوح والتعقيدية المناسبة هو أمر حكمي، ومن الأفضل ترك القرار لقادة الفريق. لكن كمحاولة لوصف الأشياء جيداً، إليك بعض ملاحظات الكتابة والأشياء التي يجب تجنبها في المواصفات:
- استعر من المواصفات الأخرى تفسيرات جيدة للأمور ( ولو كانت مكتوبة من قبل أشخاص آخرين): استخدم النصوص ووجهات النظر المفيدة في مواقع الوب، إذا دعت الحاجة. كما يجب أن يشجع القادة الفريق على ذلك. حيث لا يجب عليك أن تخترع أو تصف كل شيء.
- تجنب المفردات الخاصة بمجال معين واللغات المبهمة: لا تستخدمها إلا إذا كنت واثقاً أنها تساعد المستخدم، رغم أنها نادراً ما تكون كذلك.
- عد إلي المواصفات القديمة: فهي تعتبر مرجعاً جيداً عندما تعجز عن معرفة أفضل تمثيل لمفهوم ما أو عند تخطيط شيء ما. عندما ترى مواصفات جيدة كتبها شخص آخر، تمسك بها، أيضاً.
- تذكر وجود قراء محددين عندما تكتب: ولو كان الفريق مؤلفاً من عشرة أشخاص، من المحتمل أن يعتمد 4 أو 5 منهم بشدة على المواصفات. أضف إلى هذه المجموعة شخصا لامعاً تعرفه، لا ينتمي إلى الفريق، وليس متآلفاً مع تقنية محددة تستخدمها أنت، كيف كنت ستصف له مفهوما صعباً.
- لا تتعلق كثيراً بالمرئيات أو المخططات التدفقية: اجعل علاقتك مثلي بكل الأدوات. حيث أن المخططات تكون مثيرة عادة فقط للشخص الذي صنعها. وغالباً لا تكون فعالة في مساعدة المشروع كما يعتقد الشخص الذي أنشأها ، أحيانا، تكون فقرة جيدة أو مخطط غير متقن أفضل من مخطط UML ذي 500 عنصر. (إن مجرد كون المخطط هو الطريقة الوحيدة ليفهم الكاتب شيئاً ما، لا يضمن أنه أفضل طريقة لتفسير الأشياء لشخص آخر). فالأدوات والمخططات يمكن أن تكون أشياء رائعة، ولكن حافظ على كونها غرضية.
- أهي مرجع أم مواصفة؟: لا تحتاج المواصفات عامة أن تكون مراجع API كاملة، أو أن تصف كل حالة فردية أو تصرف محتمل. ومن المنطقي أن تركز على شرح 10 أو 15 أهم حالة وأن توفر وثيقة منفصلة لكل منها، وهي تعدد ما تبقى على سبيل الحصر (بأقل التفاصيل).
- قبل المتابعة، استخدم شيفرة وهمية أو اللغة العربية لوصف الخوارزميات المعقدة على أعلى مستوى: كما ذكرنا سابقاً خذ بالاعتبار كيف يمكن لطريقة الشرح المتعدد المستويات أن تكون أسرع طريقة للتعلم – حتى للأشخاص اللامعين، فإن الخلاصات العامة على الأقل سوف تستمر.
- إليك حيلة إضافية اعتبرتها دائماً مساعدة، إذا كان أحد الأمور على مسودة مواصفاتك مربكاً لأي شخص ( وهو ما ستكتشفه فقط عندما ترشو أحدهم ليقرأها أصلاً)، اشرحه له في خمس دقائق، وعندما يفهمه، اسأله إذا كان هناك طريقة أفضل يمكنك بها تفسير المواصفة. أحياناً تحصل على النصيحة وأحياناً لا ، ولكن استيعابك سيتحسن دائما. وذلك ببساطة لأنك تجبر نفسك على توسيع أفقك. لأنك في كل مرة تسأل فيها شخصاً آخر، ستفكر بالموضوع المحدد بطريقة مختلفة قليلاً، مما يزيد احتمالات إيجاد طريقة أفضل: وباعتبارك كاتب المواصفات، تذكر دائماً أن الآراء المرجعية الجيدة تأتي عندما تطلبها بسهولة أكثر من انتظارها.
تأكد من حصول الشيء الصحيح
تعرف المواصفات مجموعة من الأهداف، وهي تقدم الادعاء التالي: "إذا سارت الأمور كما نتوقع، فإننا سنحصل على ما هو موصوف في هذه الوثيقة، عندما ننهي هذا العمل". مما يعني أن كل ( أو نسبة مئوية كبيرة) السلوكيات والوظائف المعلنة في مواصفات السمة يجب أن تظهر في شيفرة العمل النهائي عندما ينتهي كل شيء. ورغم أنه من الممكن أن يتغير العالم في اليوم التالي لاكتمال المواصفات، فإن الأهداف تبقى نفسها يوم كتابتها. وعندما يتغير العالم، يجب أن تحدث المواصفات لتعكس هذا العالم الجديد والأهداف الجديدة – مهما تكن.
على المستوى الهندسي، فإن الهدف من المواصفات هو إعلان الأهداف لكل من يحتاج إلى استخدامها وبالنسبة للمسؤولين عن الاختبارات وضمان الجودة، فإن هذا يعني وجود الدقة الكافية للسلوك المتوقع من المشروع لكتابة مسودة تقديرات وحالات الاختبار. كما سيكون لدى مسؤولي التسويق والتوثيق واي اختصاصيين آخرين في المشروع أسئلة أخرى تحتاج إلى إجابة عن شكل النتيجة النهائية قبل أن يتمكنوا من القيام بأعمالهم. وسيحتاج مدراء الدعم الفني أو مدراء الحسابات إلى فهم كيفية عمل الأشياء ليمكنهم دعم العمل أو التخطيط لذلك.
إن أحد أفضل الأسئلة لطرحها على الناس بعد قراءتهم للمواصفات هو "هل حصلت على ما تحتاجه لتقديم أفضل عمل عندك؟" بنقل التركيز إلى القراء فإن اهتمامتهم بها سيتغير، وسيطرحون أسئلة أفضل، ويضعون المواصفات في الاستخدام، في أذهانهم، باتجاه العمل الحقيقي الذي سيلي.
من ، ومتى وكيف
تماماً مثل وثائق الرؤية فإنه من الضروري جداً للمواصفات أن تكتب من قبل شخص واحد. كما يجب أن يساهم كل من يقوم بالعمل بالتعليقات والإضافة إلى المحتويات، ولكن يجب أن يختار شخص واحد من ذلك، ويقوم بتشكيلها ويجعلها متلائمة مع بعضها البعض. وسبب هذا بسيط: إذا أردت أن تقرأ المواصفات كما كتبها شخص صافي التفكير، وسبب هذا بسيط: إذا أردت أن تقرأ المواصفات كما كتبها شخص صافي التفكير، لا يمكن أن يملك أشخاص مختلفون أجزاء مختلفون من الوثيقة، وطالما أدرك ذلك الكاتب الواحد أن عمله هو دمج المساهمات والاقتراحات الجيدة المقدمة من قبل أي شخص، فإن الأمور يجب أن تسير على ما يرام. وبافتراض أنه يوجد كاتب أساسي واحد، فإن المتقدمين المحتملين لهذا العمل هم مدير المشروع، أو المصمم، أو قائد المبرمجين. وبما أن المواصفات تمثل اتخاذ قرار متعدد الوظائف، فإنها يجب أن تكتب من قبل أكثر الأشخاص مسؤولية عن القرارات في ذلك المستوى. كما تجبر مواصفات السمة والمواصفات التقنية على المطابقة والاتصال مع قوائم بنود العمل التي ترجمها فريق المبرمجين. إذا عمل المصممون والمهندسون معاً في مرحلة التصميم، فإن جعل هذه الأشياء تتطابق يعتبر شيئاً مباشراً. وسوف تبدو تعاونا جيداً لتخطيط العمل ، بدلاً من ابتداء العملية بالمناقشات والقلق.
من أجل ذلك، ولأسباب أخرى، يجب أن يبدأ العمل بالمواصفات في مرحلة التصميم ريثما يتم تشكيل النماذج الأولية واستكشاف الأفكار، تبدأ القرارات الصغيرة بالتناثر من العمل ويمكن أن يبدأ العمل بوثائق المواصفات كمسودات تقريبية ( ويجب وصفها بمسودات أولية). يمكن الاحتفاظ بها لفترة إلى أن يتوفر الوصف الكافي فيها، حتى تكون ذات قيمة لأكثر من شخص ويتطور بالحوارات بين إدارة المشروع والتصميم وفريق التسويق وفريق المبرمجين، إدراك بسيط ومستمر في نفس الوقت عما هو القرار الصحيح، كما يجب أن تقلل المواصفات من تلك النقاشات. وعندما تأتي مرحلة التصميم في الوقت الذي يتوفر فيه بديلان أساسيان، فإنه يمكن أن تتضمن المواصفات على الأقل كل العناصر العامة والعمل الهندسي المطلوب في كلا البديلين (مثل محرك البحث اللازم لكلا التصميم بالإضافة إلى سرد عالي المستوى للقرارات الأساسية المتبقية وآثارها المحتمل.
الكتابة من أجل شخص واحد مقابل الكتابة الموجهة لعدة أشخاص
يمكن أن تمثل المواصفات، لمدراء المشاريع مكاناً مناسباً لوضع المعلومات، حتى يمكنهم هم فقط استخدامها. وهناك دائماً العديد من الأسئلة أو الأمور التي يطرحها أشخاص مختلفون فتصبح وثيقة المواصفات الوحيدة، أسهل مكان لمتابعة هذه الأمور.
لكن لسوء الحظ، فإن هذا المستوى من التفصيل يصبح مزعجاً للجميع، عدا مدير المشروع. إن قراءة المواصفات يجب ألا توحي لك أنك تقرأ مذكرة عمل الكاتب (رغم أنه مثل العديد من العلماء والمهندسين الذين يحتفظون بمذكرة عمل منفصلة يمكنها أن تساعدهم على اكتشاف الأفكار الجيدة). كلما كان الفريق أكبر، والمهام أكثر تخصصاًـ ستكون هذه المشكلة أكبر.
من جهة أخرى، فإن أحد أهم وظائف المواصفات هي مساعدة مدير المشروع بشكل مباشر، باعتبار أنه يجب عليه تنظيم وقيادة الجهود، فإنه من المحتمل أن يقوم بتعديل وقراءة الوثيقة أكثر من أي شخص آخر. إن الصيغة المشابهة للمفكرة التي ستظهر في المواصفات لها وظيفة هامة. يمكن أن تجني الفائدة من ملاحقة المواصفات والأجزاء التفصيلية لمعلومات المشروع. والحيلة تكمن في أن تقوم بذلك بطريقة لا تشوش على السرد الأساسي والقرارات التي تحاول المواصفات وصفها. بالتالي يجب أخذ الحذر عند كتابة المواصفات لفصل أي التفاصيل تخدم فقط مدير المشروع وأيها ذات قيمة عند باقي الفريق، وأبسط طريقة للقيام بهذا هي فصل التفسيرات عن السلوك والوظيفية في المواصفات عن الأمور والأسئلة الخاصة بالوصف الحالي. قد توجد قائمة واحدة من الأمور المفتوحة في نهاية المواصفات، وهي أبسط حل.
متى تكتمل المواصفات؟
إن كتابة ومراجعة المواصفات هي النتيجة الطبيعية لأي جدولة تطويرية فيها مرحلة تخطيطاً نظريا، يجب أن يعرف الفريق معظم التفاصيل عما سيتم بناؤه وكيف، مع نهاية المواصفات، ويكون المشروع جاهزاً للانطلاق، وينتقل توازن العمل من المخططين والمصممين إلى المبرمجين ومسؤولي الاختبار.
ما القدر الكافي؟
إن الإقرار باكتمال المواصفات موضوع حكمي. وهناك دائما بنود متأخرة وأسئلة أو اعتمادات على شركات أو مشاريع أخرى لم تنجز أمورها بعد. إن الإقرار بـ (اكتمال المواصفات) يمكن أن يعني مستويات مختلفة جداً من الاكتمال والجودة، وذلك تبعاً للفريق والمشروع. وفي هذا الأمر لا يوجد صحيح أو خاطئ. أحياناً يتم موازنة مخاطرة المواصفات الأضعف مع ضغوطات الجدولة أو اعتبارات أخرى. تماماً مثل أي ناحية اخرى عالية المستوى في المشروع. (جودة الشيفرة، والتوازن والأداء)، إن حكم قائد الفريق فقط، بإمكانه تقرير المستوى الصحيح من الاستثمار. وبالطبع كلما كانت الاستراتيجية الهندسية العامة أكثر تكراراً، سيزيد احتمال كتابة المواصفات، بمرونة أكبر.
لكن كقاعدة عامة، كلما كانت المواصفات أقوى، سيكون الاحتمال أكبر في تحقيق النتائج في الوقت المناسب، ويكون السؤال عندها ما مقدار الاحتمالية التي تحتاجها؟ هل تستحق الزمن الذي سيستغرقه جعل المواصفات أفضل بنسبة 5%؟ أو هل اكتشف المبرمجون أو مدير المشروع تلك التفاصيل أثناء الفترة الطبيعية للقيام بالعمل؟ لا يوجد جواب سهل. بالنظر إلى أي مواصفات معطاة، كان علي أن أستخدم حكمي الخاص. وأعتقد أن هذا بحاجة إلى خبرة في المشاريع أكثر من مهارات الكتابة أو البرمجة. على كل، فإن النقطة الهامة هي أنه بغض النظر عن مستوى الاكتمال المتوقع قبل أن تعتبر المواصفات مكتملة، فإن الطريقة الوحيدة لانجاز ذلك هي بعملية المراجعة، وبما أنها شديدة الموضوعية والنسبة، فإن الطريقة الوحيدة للحصول على مواصفات بجودة معينة هي بجعل قادة الفريق (وهم من سيستخدم المواصفات)، يراجعونها ويعطون آراءهم بها (سوف اشرح هذه العملية في المقطع التالي).
كيف تتدبر قائمة الأمور المفتوحة (المعلقة)
بغض النظر عن كيفية تدبر الفريق لعملية التصميم، ستبقى دائماً أمور غير محلولة أثناء كتابة المواصفات. وإذا لم تدر هذه الأمور بالشكل المناسب، توقع الكوارث. فالعديد منها التي تحدث في منتصف المشروع هي نتيجة لبنود المواصفات التي أسيئت معالجتها أو تم تجاهلها. وإنه لأمر صعب أن يتخذ مدير المشروع المبادرة لجمع ومراجعة هذه البنود، دافعاً الفريق لمعرفتها باكراً.
وهو تحد صعب لمدراء المشاريع الأقل خبرة، حيث إنهم سيكونون مشغولين جداً بالمهام الأخرى الخاصة بكتابة المواصفات، حتى إنهم لن يخصصوا الوقت المناسب لإدارة الأمور المعلقة. أحيانا يتطلب الأمر حصول مشكلة بسبب بند ما في مرحلة متأخرة في المشروع لكي تدرك قيمة متابعة الأمور من البداية.
إن الإدارة الفعالة للأمور المعلقة هي أمر اجتهادي بحت. وعلى أحد الأشخاص الاستقصاء عن المشكلات المحتملة، وكذلك إمضاء الوقت في تدوينها. وليس هناك أي نوع من السحر في هذا.
حالما يتم تدوينها يمكن ترتيبها بحسب الأولويات، وتكليفها، وحلها. ولكن إذا لم يمض أحدهم هذا الوقت، فإن منع المشكلات الأساسية يصبح أمراً يعتمد على الحظ لا على المهارة. هب أنك قمت فعلياً بمتابعة الأمور نوعاً ما ، ولو كانت مجرد قائمة موجودة على اللوح الأبيض في مكتبك، إليك بعض الأسئلة الأساسية لتساعدك على إعطاء الأولويات لهذه الأمور وتنقيحها:
- متى يجب حل هذا الموضوع؟ من أفضل شخص لاتخاذ القرارات اللازمة لحله؟
- هل يمكن عزل هذا الموضوع بطريقة ما ، ربما إلى سيناريو أو عنصر محدد؟ أو هل يؤثر على السمة الكلية أو المشروع؟
- ما الحلول الممكنة للمشكلة التي ما زالت قيد الاعتبار؟ (على سبيل المثال، سوف نستخدم JSPوليسPHP,ASP كيف سيؤثر كل من هذه البدائل على المواصفات؟
- هل يمكننا التخلص من هذا الأمر؟ وكيف سيؤثر ذلك فعليا على الزبون في سيناريو المستخدم ذي الأفضلية الأولى؟
- هل يمكن تقسيم الموضوع إلى أمور أصغر، ليمكن (يجب) توكيلها لأشخاص آخرين؟
- من أول ما الذي يمنع حصول هذا الأمر، وهل تم بذل الجهود للتخلص من هذا الحجب؟ (قد يكون الحل تقنياً أو سياسياً).
إذا وجد العديد من الأمور الكبيرة وكان من الصعب تقسيمها، فإن شيئاً ما سيكون قد اتجه في الاتجاه الخاطئ وعملية التصميم أو قيادة الفريق قد فشلت. إن الطريق إلى الخروج من المشكلة خارج مجال إدارة الأمور المعلقة.
إغلاق فجوة المواصفات
إذا قمت بإدارة الأمور المعلقة بشكل جيد فإنه من الممكن أن تغلق فجوات الجدولة بإعطاء تقديرات عن كيفية حل هذه الأمور. والفكرة الأساسية التي يشار إليها بتطرف (التصويب) . إذا نفذ هذا الأمر بالشكل المناسب، يمكن عندها مراجعة المواصفات واعتبارها مكتملة في الوقت المحدد. وإن بقيت أمور خاصة بالتصميم غير محلولة. إن (التصويب) هو تمهيد للمخاطرة، حيث إنك تقدر قدرة الفريق الجيدة على حل باقي المشكلات، بدلاً من انتظار الفريق ليحلها فعلياً. من جهة أخرى، فهي ليست بالضرورة حركة شديدة الخطورة، وتعتمد على مدى حسن فهمنا للأمور، ومدى جودة الاقتراحات المعطاة عنهم. افترض وجود فريقين، الفريق A لديه قائمة طويلة من البنود ولكنها مستوعبة بشكل جيد. أما الفريقB قائمة صغيرة ولكن استيعابها ضعيف. أي الفريقين برأيك أكثر احتمالاً لانجاز العمل بالوقت المحدد؟ أنا أراهن على الفريق A. إن الشكوك، إن لم يكن سواها، تملي أن القائمة الصغيرة للفريقB تعني أنهم لم يجدوا كل الأمور المتعلقة بالمواصفات بعد. بينما قضى الفريق Aالمزيد من الوقت على الأمور المعلقة، وأنه مجهز بشكل أفضل لأي نوع من التحديات التي قد يقوده المشروع إليها.
من المهم إبداء ملاحظة أن إغلاق الفجوة لا يعني التوقف عن العمل التصميمي اللازم لإنهاء هذه القرارات. إنها تعني أن يحاول مدير المشروع التراجع خطوة إلى الوراء للحظة وإصدار أحكام لصالح الحفاظ المحتمل على الجدولة. خذ بالاعتبار الأسئلة التالية الخاصة بكل أمر معلق، للمساعدة في إغلاق الفجوة:
- هل توجد بنود عمل يجب إنجازها بغض النظر عن إي البدائل سيتم اختبارها؟ إذا وجدت فإنها يجب أن تقدر وتضاف إلى المواصفات. وإذا لزم الأمر يمكن أن يتم البدء بهذه البنود قبل أن تنتهي المواصفات.
- هل يمكن لمدير المشروع أو المصمم أن يحل هذا الموضوع؟ وهل سيؤدي إنهاء هذا الموضوع إلى بنود عمل جديدة؟ (على سبيل المثال، قد يكون العمل بشكل تفرعي مع المبرمج ممكناً بدءاً من إدراك بنود العمل، بينما يقود مدير المشروع الأمور المعلقة باتجاه الحل).
- ما البدائل الممكنة لحل هذا الموضوع الذي ما زال قيد الاعتبار؟
- أي البدائل الممكنة أكثر كلفة؟ اعتبر أن تقدير بنود العمل يعتمد على هذه الطريقة، وقم بتشكيل قائمة بنود العمل والمواصفات في خطة تصميم تفترض أسوأ الحالات.
- هل هذا مكون رئيسي أو مركزي؟ من سيحتاج المبرمج لتنفيذ هذا؟ هل يمكن تصميمه فيما بعد في مرحلة التنفيذ؟ هل هو شيء ما نعرف أن بعض العناصر الاخرى تعتمد عليه؟
- هل يمكن لهذا الأمر أن يحتوي أو يتقلص أو يتجزأ أو يلغي؟ إذا لم يكن ذلك ممكناً، ضعه في أعلى قائمة الأولويات.
لا يمكن دائما إغلاق الفجوة بنجاح. وتستطيع أن تقوم بدفعة متينة وتجعل الأمور تتقدم إلى الأمام ومع ذلك تجد نفسك لا تزال بعيداً جداً. مع ذلك، فإن إعطاء دفعة باتجاه الإنهاء يعتبر خطوة جيدة. غالباً تحتاج الفرق قليلة الخبرة إلى هذا النوع من الضغط لإجبارها على مواجهة جميع هذه الأمور (التقنية وسواها)، وقد لا يتفهم المدراء بشكل كامل مدى تعقيد ما تبقى، حتى يحصل هذا. يمكن إجراء حوار جيد من أجل إغلاق الفجوة بشكل سباق بدلاً من الانتظار حتى تصبح الجدول في مرحلة المخاطرة.
أهمية الوصول إلى انجاز المواصفات
يجب أن يوجد موعد ضمن الجدولة للوصول إلى اكتمال المواصفات. وربما يكون هو الموعد الأهم لمدير المشروع كمشارك مستقل في المشروع. وغالباً تكون كتابة المواصفات هي التقرير الأساسي أو ربما الوحيد، المهم للمشروع. وحالما تكتمل المواصفات، ينتقل تركيز مدير المشروع إلى إرشاد وقيادة المشروع، بما في ذلك مساعدة تحول الفريق إلى التطوير الكامل.
يجب أن يحصل تغيير في نفسية وسلوك الفريق بعد انتهاء المواصفات. وهذه المشاعر يجب إن تتلاءم مع المرحلة الأساسية الحالية. حيث أن الأساسات قد انتهت، وأن العديد من القرارات الصعبة قد اتخذت. وقد مر الفريق ببعض التحديات الكبيرة من أجل اكتشاف ما القرارات الصحيحة والتعامل مع الاحتمالات العديدة لتحقيق الرؤية بهدف الوصول إلى خطة واضحة ومدروسة جيداً. ويعود موضوع التأكد من أن كل من له علاقة بهذا المجهود حتى الآن لديه تصور عن وجهة النظر هذه، وقد تعرف مدير المشروع إلى عمله.
ملاحظة
إن المواجهة هي أفضل طريقة لإخبار الناس أنك تقدر عملهم. لا تعتمد على البريد الالكتروني المرسل إلى كل أعضاء الفريق من أجل إيصال رسالة معينة لأي كا. بل اذهب إلى مكاتبهم أو اتصل بهم هاتفياً حيث إن مكالمة قصيرة تحمل رسالة ذات وزن معنوي أكثر من البريد الالكتروني.
على الرغم من صعوبة إلقاء الخطابات المشجعة وإجراء الأحداث الباعثة على الثقة بالشكل الجيد، فإنه يجب أن يتوفر نوع من المعرفة العامة عند الفريق عن العمل الذي قد تم إنجازه حتى اليوم. وعادة تكون الأشياء البسيطة أفضل ما يحقق ذلك: استراحة مسائية، أو غداء لفترة طويلة تحت أشعة الشمس أو أسبوع تقدم فيه الأطعمة الخفيفة مجاناً في مطعم الشركة. إن الكسر الإيجابي نوعاً ما للرتابة ( كالخروج من مكان العمل) هو أفضل طريقة لمساعدة الفريق على الانتقال من مرحلة لأخرى وشحنه بالطاقة كتحضير للضغوطات المختلفة التي سيواجهها في الأسابيع أو الأشهر القادمة.
المراجعات والتغذية الراجعة
إن الخطأ الأكبر الذي يقع به الناس بالنسبة للمواصفات هو انتظار المراجعة الرسمية للحصول على تغذية راجعة عن محتوياتها. يجب أن تستخدم المراجعات للتأكيد والتنقيح، وليس من أجل المرور الأول والقرار الأخير في نفس الوقت. وهو سبب آخر لاعتبار عملية التصميم شديدة الأهمية. إنها تعني أن قرارات التصميم قد مرت بتكرارات عديدة وأن كاتبيها قد حصلوا على العديد من الفرص لضم الاقتراحات الجيدة. وعلى القادة تحقيق ذلك بإجراء المراجعات غير الرسمية المبكرة وتوفير مسودة المواصفات على الشبكة الداخلية للشركة. إلا أن هذا لا يعني أن تكون اجتماعات مراجعة المواصفات عبارة عن لقاءات احتفالية، حيث يجب أن يتدخل الجميع في العملية بفكرة واضحة عما هو متوقع منهم إنجازه. توجد طرق مختلفة لمراجعة المواصفات، إلا أن معظمها يتضمن إجراء اجتماع تتم فيه قراءة أو مناقشة الوثيقة لإرضاء أحد الأشخاص. إن مدى رسمية أو عدم رسمية هذا الاجتماع تتعلق كثيرا بثقافة الفريق وسلوك قادته وطبيعة المشروع. ولكن بغض النظر عن كيفية إجرائه، فإن الهدف هو الإجابة عن السؤالين المتماثلين "هل تم تفصيل المواصفات بشكل كاف لإرشادنا أثناء التطوير؟ "و" هل تحقق النتائج ، والمتطلبات والأهداف لهذا الجزء من المشروع؟ "بالطبع، فإن هناك العديد من الأسئلة عن المواصفات التي يجب طرحها ، إلا أنها جميعاً مشتقة من هذين السؤالين الأساسيين. إن عملية المراجعة يجب أن توجه إلى الإجابة عن هذه الأسئلة بثقة.
كيف تراجع المواصفات
إن مراجعة المواصفات يجب أن تكون عملية خاصة بالفريق. وعلى الرغم من كون التركيز الأساسي على الوثيقة والأشخاص الذين كتبوها، فإن الهدف يجب أن يكون للتأكيد على أن كل من يجب عليه القيام بالعمل موافق على ما هو موجود في الوثيقة. وأسهل وأسرع طريقة للقيام بذلك هي تجميع أولئك الأشخاص في غرفة ليعرفوا الإجابات عن أي أسئلة مطروحة. لقد رأيت مراجعات للمواصفات تجري بواسطة البريد الالكتروني أو المكالمات متعددة الأطراف، ولا يمكنني القول إنني كنت سعيداً بالنتائج. لأنني تمنيت فور ظهور موضوع جدلي لو كنت معهم بنفس الغرفة حيث يمكنني استخدام اللوح الأبيض أو الإيماءات بالأيدي لشرح الأشياء في الزمن الحقيقي. كلما كانت المواصفات أكثر تعقيداً، ازدادت رغبتي في جمع الأشخاص في الغرفة (إذا كنت مجبراً على العمل بشكل تخيلي، وتؤمن بضرورة وجود الجميع من أجل المراجعة، قم بذلك على شكل مجموعات صغيرة مؤلفة من 3-5 أشخاص). وفي حال المهام المعقدة مثل مراجعة المواصفات، فإن المكالمات متعددة الأطراف والمؤتمرات الفديوية مع مجموعات كبيرة تتحول مباشرة إلى ملهاة ومأساة.
يجب حجز غرفة اجتماعات متوسطة الحجم لمدة ساعة أو ساعتين قبل عدة أيام إذا كانت المواصفات جاهزة للمراجعة (حسب ما يحدد كاتبها، بالإرشاد من المعيار المعرف من قبل قادة الفريق)، ويجب أن تكون جزءاً من الدعوة إلى الاجتماع. وعلى ما أذكر، فقد تمكنت من القيام بذلك لمرات قليلة فقط. فقد كنت غالبا، أحجز للاجتماع قبل أسبوع أو ما يقارب واخبر الجميع أنهم حصلوا على الوثيقة بالبريد الالكتروني قبل 24 ساعة من موعد الاجتماع لمراجعة المواصفات. لقد كره بعض الأشخاص ذلك، لكنني تعلمت أنها الطريقة الأكثر نجاحاً لتامين وثيقة محدثة وإجبار الأشخاص على قراءتها. وبهذا التحذير المبكر يمكن للأشخاص تخطيط أوقاتهم في فترة 24 ساعة لقراءة ذلك الشيء. وباعتبار نفس المنطق، أظن أنه من العدل الطلب أن يقوم أولئك الذين يحضرون مراجعة المواصفات بقراءتها قبل القدوم إلى الاجتماع. وبسبب كونه خيارا طبيعيا، فإن الأشخاص الذين هم فعلا بحاجة إلى قراءتها سيجدون الوقت لذلك، لأنها ستكون إحدى أكثر الأمور التي يقومون بها أهمية . وبغض النظر عما يقولونه، فإذا لم يتمكنوا فعلياً من إيجاد الوقت ليقلبوها سريعا ًعلى الأقل لمعرفة المشكلات الجلية، فإن العمل ليس في قمة أولوياتهم، وبالتالي فهم لا ينتمون إلى الاجتماع. في كل مرة كانت لدى فيها السلطة للقيام بذلك، كنت أطبق قاعدة قراءة المواصفات قبل الاجتماع على كل أعضاء الفريق، وقد أكد هذا على أمرين: الأول أنه يخفض عدد الأشخاص القادمين إلى الاجتماع إلى العدد من الأشخاص الذين يحتاجون إلى الحضور حقاً، وعندها تنخفض احتمالات ازدحام الغرفة بالناقدين. ثانياً، أن اجتماع المراجعة سيمضي بسرعة أكبر لأن الجميع ينطلق من نفس العمق في المفهوم، كما سيميل الأشخاص الذين لم يقرؤوا المواصفات لأن يعيقوا الأمر نظراً للأسئلة التي يطرحونها. وإذا كانت أسئلتهم صالحة، عندها يجب أخذها بالاعتبار، ولكنها إذا كانت مغطاة جيداً ضمن المواصفات فمن العدل الطلب منهم أن يقرؤوا ذلك المقطع، ومن ثم يتابعوا الموضوع مع كاتب المواصفات بعد الاجتماع.
من الذين يجب أن يكونوا موجودين في الاجتماع وكيف؟
يجب أن يحضر الاجتماع شخص واحد على الأقل يمثل إحدى المهام الأساسية (البرمجة، الاختبار، الخ) بالإضافة إلى أي مهام أساسية مساهمة أخرى ( العمل، التصميم، التوثيق). كما يجب أن تكون المراجعات مفتوحة لكل أعضاء الفريق، فإذا اهتم المبرمجون أو مسؤولو الاختبارات بالمواصفات، وأمضوا وقتاً في قراءتها، يجب عندئذ الترحيب بحضورهم، ولو لم يعملوا بمواصفات السمة. إن دعوة قيادة الفريق اختيارية، وهم الذين يقررون إذا كانوا بحاجة إلى المشاركة في الاجتماع. فإذا كانوا يقومون بعملهم بشكل جيد، فهم ربما يعرفون ما يكفي من التفاصيل، فيحضرون فقط المراجعات الأكثر جدلية للمواصفات. من ناحية أخرى، إذا كان الفريق عديم الخبرة، عندها قد يحتاجون إلى حضور كل الاجتماعات. يجب أن يدار الاجتماع الفعلي من قبل مدير المشروع (أو كاتب المواصفات)، والعملية بسيطة: إجابة الأسئلة. وإذا لم يكن هناك أسئلة (وهي حالة خيالية)، ووجد في الغرفة الأشخاص المناسبون، وكانوا سعداء بالمواصفات، عندها تنتهي المراجعة. يميل بعض مدراء المشاريع لإجراء مراجعة تفصيلية للنموذج الأولي النهائي، وهو أمر جيد. بينما يفضل الأخرون مراجعة الوثيقة مقطعاً مقطعاً. أما أنا فأعتبر شخصياً أن هذا مضيعة للوقت (إذا كتبت مواصفات جيدة، وقرأها الجميع، عندها ما السبب في إجراء مراجعة للموضوع كاملاً؟) إلا أن بعض فرق العمل يحبون هذا، لذا استخدم أي شيء يحقق المطلوب. إن الأمر الوحيد المهم هنا هو أن يشترك الأشخاص في نقاشات صحية، ويطرحوا أسئلة جيدة، ويعملوا معأ من اجل انجاز المطلوب. بالنسبة لأي سؤال يطرح ، فإن أمر مناقشة الإجابة لإرضاء من طرح السؤال أو لإضافة بند جديد إلى قائمة الأمور المفتوحة في المواصفات، يعود إلى الموجودين في الغرفة. وعندما تنتهي الأسئلة يقوم مدير المشروع بمراجعة قائمة البنود المفتوحة (إن اللوح الأبيض في غرفة المؤتمرات مناسب لتعداد البنود الجديدة). ويقرر إذا كان هناك شيء ما يستحق إجراء اجتماع مراجعة آخر. وإذا لم يصل أي شيء إلى هذا الحد، عندها نعتبر أنه قد تمت مراجعة المواصفات، مما يؤدي إلى البحث وإيجاد الحلول لتلك الأمور المفتوحة الجديدة. بعد أن تكتمل مراجعة المواصفات، يجب أن يكون لدى مدير المشروع خط زمني للاستجابة إلى الأسئلة أو الأمور المطروحة في الاجتماع. كما يجب (مباشرة بعد الاجتماع) أن يحصل كل من دعي للحضور على بريد الكتروني فيه خلاصة قصيرة عن الأمور المفتوحة وموعد للمراجعة التالية (إذا كانت قد تمت جدولتها) وخط زمني لتحديد موعد وجوب حل الأمور المعلقة. ويعتبر هذا هاماً خاصة إذا كان أحد الأمور المفتوحة يعيق أحد أعضاء الفريق عن القيام بعمله. في الحقيقة يجب أن تستحضر الأمور المعيقة أثناء مراجعة المواصفات، وإيلاؤها اهتماماً خاصاً.
قائمة الأسئلة
هناك بعض الأسئلة التي يجب أن تطرح في كل اجتماع مراجعة لمراجعة المواصفات بناء على الأمور العامة التي وجد الأعضاء أنها غير صحيحة. رغم أن طرح الأسئلة الصعبة لا يجد حلولاً محددة، فإنها تجبر الفريق على التفكير بحساسية أعلى بما يفعلونه. تذكر، أن هذا ليس امتحاناً نهائياً. من الجيد أن يعلم الجميع ما الأسئلة قبل قدومهم، وهذا في صالحك، حيث يأتي الجميع مجهزين إلى اجتماع المراجعة. باعتبار أن التصميم وكتابة المواصفات هما عمليتان تفاؤليتان، فإن الأمر يعود إلى الأشخاص الذين يقومون بالمراجعة، أن يشكوا ويستكشفوا الأشياء التي ربما أهملت ( احذر أن تكون لئيماً، فكونك ناقداً لا يتطلب الخروج عن المألوف وأن تكون قاسياً أو تجعل الناس يشعرون بالسوء. وإذا كان الفريق لسوء الحظ غير جاهز لمراجعة المواصفات، فإن المسؤولية تقع غالبا على عاتق قادة الفريق بنفس الدرجة التي تقع فيها على عاتق الأفراد). وإن كان الفريق يعرف الأسئلة الصحيحة، يجب أن يقوم أحد الأشخاص بالتحريض و إجراء البحث، للتأكد من الحصول على الإجابات الصحيحة.
فيا يلي قائمتي من الأسئلة، وأنني أشجعك على مراجعة هذه الأسئلة وإضافة خاصتك إليها:
- هل تطابق قائمة بنود العمل عند المبرمج، المواصفات؟ وكيف يتعلق كل مكون أساسي في المواصفات بكل بند من بنود العمل؟ في أي نواحي التصميم يكون احتمال إيجاد بنود عمل قد تم تجاهلها، أكبر؟
- كيف يمكن أن يفشل هذا التصميم؟ ما المكونات أو الواجهات الأضعف؟ لم لا يمكن تحسينها؟
- ما الناحية الأقوى في هذا التصميم؟ وما الناحية الأضعف؟ ما النواحي التي ثقتنا تجاهها أكبر أو أقل؟ هل تتركز قوانا وطاقاتنا حول المكونات الأكثر أهمية؟
- هل نحن في المستوى الصحيح من الجودة؟ وهل يكون هذا موثوقاً، ومنجزاً وقابلاً للاستعمال كما تتطلب الرؤية الخاصة بمشروعنا؟ هل تقديرات الاختبار واقعية؟
- لم يكون التصميم الأبسط أفضل؟ وهل نحتاج حقاً إلى هذا القدر من التعقيد أو الوظيفية؟ وما الأدلة التي لدينا، أو ما النقاشات التي يمكن أن تتم حتى لا يكون هذا أبسط؟
- ما الاعتماديات التي يحتويها هذا التصميم؟ هل هناك تقنيات، أو شركات أو مشاريع أو مواصفات قد تفشل بشكل يؤذي أو يمنع هذا العمل؟ هل تتوفر لدينا خطط إسعافية مستقبلية؟
- أي عناصر التصميم أكثر احتمالاً للتغيير؟ ولماذا؟
- هل لدى الاختبارات، أو التوثيق أو كل المهام الاختصاصية الموكلة إلى هذا المشروع، كل المعلومات اللازمة لتؤدي عملها بأفضل شكل ممكن؟ ما اهتماماتها، وكيف سيتم تحديدها؟ أو هناك أسباب واضحة ليمكننا تجاهلها؟
- ما اهتمامات مدراء المشروع والمبرمجين ومسؤولي الاختبارات الأساسيين لهذه المواصفات؟ أو لهذه السمة؟
- هل هناك احتمالات للمشارك أو استعادة الشيفرة من سمات أخرى يتم بناؤها في هذا المشروع؟
- هل حققنا سمات إمكانيات الوصول وتحديد الموقع لواجهات المستخدم؟
- ما مخاطر السرية في هذا التصميم؟ لم لا يعتبر إلغاؤها منطقياً؟ وهل تم توثيقها في المواصفات بما في ذلك الاصطلاحات المحتملة (مثل نماذج اختبار السرية التي يتم إدخالها مع الشيفرة أثناء كتابتها)؟
- هل يوجد لدينا دليل معتمد يشير إلى أنه يمكن لمستخدمين محددين أن يستخدموا تصميم واجهات المستخدم هذه لينجزوا بنجاح ما يرغبون بإنجازه؟
خلاصة
- يجب أن تحقق المواصفات ثلاثة أشياء: التأكد من بناء المنتج الصحيح، وتامين جدولة خاصة بكل مرحلة أساسية تلخص مرحلة التخطيط للمشروع وتسمح بمراجعة عميقة، وتغذية راجعة من أفراد مختلفين أثناء فترة المشروع.
- تحل المواصفات مشكلات محددة فقط، يجب أن يوضح قادة الفريق ما المشكلات التي يحاولون حلها باستخدام المواصفات، وما المشكلات التي يجب حلها بوسائل أخرى.
- المواصفات الجيدة تؤدي إلى التبسيط، فهي بشكل أساسي وسيلة للتواصل.
- إن المواصفات مختلفة جداً عن التصميم.
- يجب أن تكون السلطات واضحة لمن سيكتب ويتحكم بالمواصفات.
- إن إغلاق الفجوة هو إحدى طرق إدارة الأمور المعلقة وتسريع إنهاء عملية المواصفات.
- إن عملية المراجعة هي أفضل طريقة لتعريف المواصفات والتحكم بجودتها.
المرجع
كتاب : فن إدارة المشروعات، تأليف : سكوت بيركان، ترجمة حلا قش قش، دار شعاع للطباعة والنشر والتوزيع.