# NUPP

قواعد عامة تقريبًا

[image]

هذه نسخة قابلة للتنزيل من الدليل المتاح عبر الإنترنت (https://omimo.org/ar/modules/nupp/) ، وقد تم إنشاؤها بتاريخ 2026‑07‑02. يُرجى مراجعة الموقع الإلكتروني للحصول على أحدث الإصدارات.

يأتي NUPP من مشروع OMIMO (https://omimo.org/ar/) ، وهو مجموعة من الوحدات المفتوحة والبسيطة.

يمكن استخدام هذا الدليل وتوزيعه بحرية بموجب ترخيص المشاع الإبداعي: النسبة (Creative Commons Attribution 4.0 International).

يتم تمويل OMIMO بشكل مشترك من قبل الاتحاد الأوروبي. ومع ذلك، فإن الآراء ووجهات النظر المعبر عنها هي آراء OMIMO فقط ولا تعكس بالضرورة آراء الاتحاد الأوروبي أو EPOS VZW. ولا يمكن تحميل الاتحاد الأوروبي أو الجهة المانحة المسؤولية عنها.

تمت الترجمة بواسطة: Afef Mezzi


## مقدّمة

NUPP هو مجموعة من القواعد العامة تقريبا للمشاريع: تلك التي من المحبذ اتباعها في جميع المشاريع بغض النظر عن المنهجيات و الأساليب التي نعتمدها لزيادة نجاحنا.

ينتبه كل مورد وطريقة لإدارة المشاريع إلى بعض من هاته NUPs (قواعد عامة تقريبًا)، ومع ذلك:

  - عادة ليس جميعهم، وسيكون من الجيد للممارسين استعمال جميع NUPs بدلاً من مجموعة فرعية، و
  - عادة ما تكون المبادئ الأساسية غير واضحة بما فيه الكفاية في الموارد، ويهتم معظم الممارسين في التفاصيل العملية التي تنسى المبادئ وتفعل أشياء لا تتوافق معها.

NUPP متوافق مع جميع الطرق والأنظمة والموارد والأطر الرئيسية مثل PRINCE2^(®) و PMBOK^(®) Guide و P3.express و PM² و DSDM^(®) و XP و Scrum. على الرغم من أنه قد لا يكون متوافقًا مع تفسيرات معينة لتلك الأنظمة، وهنا يحاول NUPP تشجيع الممارسين على إعادة النظر في تفسيراتهم. NUPs هم:

  - NUP1 — تفضيل النتائج والحقيقة على الانتماءات
  - NUP2 — الحفاظ على الطاقة والموارد وتحسينها
  - NUP3 — يجب ان تكون دائما استباقيا
  - NUP4 — تذكر أن السلسلة قوية فقط مثل أضعف حلقاتها
  - NUP5 — لا تقم باي شيء بدون هدف واضح
  - NUP6 — استخدام العناصر القابلة للتكرار


## NUP1 تفضيل النتائج والحقيقة على الانتماءات

[image]

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


### مثال: Agile vs Waterfall

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

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

هذا يسبب مشاكل بطرق متعددة، بما في ذلك ما يلي:

  - لا يستطيعون التعلم من أي شخص خارج المجموعة
  - لا يشجع الاخرين على التعلم منهم
  - يجعل الانتماء الى المجموعة اهم بكثير من الهدف الحقيقي والذي بدوره يمنع العديد من أعضائها من تعلم المعنى الحقيقي ل Agility

يمكن تقليل هذه المشكلة بشكل كبير، إن لم تتم إزالتها بشكل كامل، عن طريق استخدام “Agile” فقط كتسمية تشير إلى اسلوب تطوير بدلاً من مجموعة أعضاء؛ وعن طريق ايجاد أشخاص يعتبرون أنفسهم مبدعين، ويمكنهم حل المشكلات، وقادة، يرون أن Agile ببساطة هو من أحد العوامل التمكينية تحت نطاقهم بدلاً من هويتهم.

ليست هناك حرب Agile-waterfall للمحترفين الحقيقيين.


### مثال: PRINCE2^(®) vs PMBOK^(®) Guide

هناك العديد من المهنيين في المجتمع الذين يربطون أنفسهم إما بالدليل PRINCE2^(®) أو PMBOK^(®) (عادة بسبب موقعهم الجغرافي) وليسوا على دراية ببقية الأساليب.

يمكن أن يكون لدينا جميعًا تفضيلات تجاه موارد معينة، ولكن ليس باعتبارها هويتنا، والأهم من ذلك، يجب أن نتعرف عليهم جميعًا لتوسيع منظورنا وخياراتنا.

المحترف الحقيقي هو منفتح على كل الأفكار، يبحث عنها، يتعلم عنها ويستخدمها عند الحاجة بدون انتماءات.


### مثال: تعليم مستمر

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

ما نؤمن به اليوم ليس هو الحقيقة. إنه مجرد فهمنا الأفضل حتى الآن، والذي يجب تحسينه مع تقدمنا. عندما تكون أفكار الشخص هي نفسها تمامًا كما كانت عليه قبل بضع سنوات فيوجد حتما خطأ ما. هذا هو الحال بالنسبة لـ NUPP: إذا عدت بعد بضع سنوات وشاهدت نفس الشيء بالضبط، فيجب أن تشك.


### مثال: الانفتاح

عند الاعتراض على شخص ما، تأكد ان اعتراضك هو على الفكرة وليس الشخص. هذا يساعد على منع الكثير من التوترات.

في سياق مشابه، عندما يعترض شخص ما عليك، لا تحاول أن تفسرها على أنها حرب ضدك، بل هي مناقشة لأفكارك، ويجب ان تكون منفتح عليها. لا تستمع للرد، ولكن استمع إلى الفهم؛ واعمل مع الشخص الآخر لتحسين الفكرة.

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


## NUP2 الحفاظ على الطاقة والموارد وتحسينها

[image]

الموارد محدودة. الموارد المتاحة للمشروع محدودة، وكذلك الطاقة العقلية التي لديك لاتخاذ قرارات جيدة. يجب عليك الحفاظ على هذه الموارد وتحسينها لنفسك وللمشروع، ومساعدة أعضاء الفريق الآخرين على القيام بنفس الشيء.


### مثال: القاعدة 80/20

يمكن تحقيق جزء كبير من الفوائد المحتملة لإدارة المشروع عن طريق بذل قليل من المجهود. في معظم الحالات، يكون استهداف 100٪ من الفوائد المحتملة باهظ التكلفة وغير مبرر. يجب تطبيق هذه القاعدة في كل ما نقوم به وحث البقية على القيام بنفس الشيء.


### مثال: القرار عند التعب

نحن نستخدم مصدرًا وحيدًا للطاقة العقلية لاتخاذ جميع أنواع القرارات، وأيضًا للتعبير عن قوة الإرادة. إذا كنت تستهلك الكثير من هذا المصدر في اتخاذ قرارات غير ضرورية أو غير مهمة، فستكون لديك طاقة أقل لاتخاذ القرارات المهمة، مما قد يؤدي إلى نتائج سيئة. هذا أحد الأسباب التي تجعلك تتجنب الإدارة الصغرى (مبدأ “manage by exception” في PRINCE2^(®)).

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


### مثال: اهتم بنفسك

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

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


### مثال: توازن الحياة مع العمل

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


### مثال: التحفيز

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

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


### مثال: التعاون والعمل الجماعي

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

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


### مثال: ثقافة الفريق الواحد

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


### حكمة الحشد

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

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


### قائد المشروع الرائد

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


## NUP3 يجب ان تكون دائما استباقيا

[image]

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


### مثال: تخطيط

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

على عكس ما يعتقد البعض بشأن مشاريع Agile، فإن التخطيط ضروري دائمًا؛ يختلف نوع ومستوى تفاصيل الخطط فقط من منهجية إلى أخرى. التخطيط قبل التنفيذ هو نهج استباقي.

تذكر المثل: “أعطني ست ساعات لقطع الشجرة وسأمضي الأربع ساعات الأولى في شحذ الفأس.”

إذا كان هذا مشروعًا تنبؤيًا ، فيمكنك قضاء 4 ساعات في شحذ الفأس لأنك متأكد من أنك تريد قطع شجرة. في مشروع Agile، لا تعرف ما إذا كنت ستقطع شجرة أو تقوم باستعادة الفروع المكسورة أو حصاد العشب أو استخراج الفحم أو أي شيء آخر. ومع ذلك، يجب أن تكون مستعدا دائمًا بشكل عام (اكتشف أين يقع أقرب متجر ادوات) وبشكل أكثر تحديدًا (شحذ الفأس) عندما تركز على حل معين. هذا هو التخطيط.


### مثال: تخطيط المخطط

التخطيط لكيفية تنفيذ المشروع هو نهج استباقي. يمكن تمديد هذا النشاط الاستباقي من خلال تخطيط كيفية تخطيطنا للتنفيذ؛ إنه مفهوم خطة إدارة دليل PMBOK^(®) واستراتيجيات إدارة PRINCE2^(®) ونهج DSDM^(®).


### مثال: تخطيط مستمر

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


### مثال: إدارة المخاطر

تستند الفكرة الكاملة لإدارة المخاطر على نهج استباقي: في مواجهة الأحداث الغير مؤكدة، فبدلاً من الانتظار لمعرفة ما يحدث والرد عليها، فإننا نفكر في الاحتمالات والآثار، ونفحص الإجابات، ومن الممكن التصرف قبل وقوع الحدث.

لاحظ أن ما نقوم به في المشاريع جدي؛ في بعض الأحيان حياة البشر هي على المحك.


### مثال: تحديد الادوار والمسؤوليات

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

يعتمد عدد الأدوار وتنوعها على نوع وحجم المشروع. يمكن أن يكون تعريفًا بسيطًا مثل Scrum، وهو شيء معتدل مثل P3.express أو كامل، مثل تعريف DSDM^(®) وPRINCE2^(®). ومع ذلك، ضع في اعتبارك أن تعريف الدور في هذه الأساليب ينطبق فقط على أنشطة الإدارة، ولا تزال بحاجة إلى إضافة تعريف الدور للجوانب التقنية.


### مثال: الخيارات المتاحة

هل يجب عليك اغلاق المشروع قبل الأوان او الاستمرار فيه؟

لا يوجد نادرا الا خياران، حتى لو كان هذا هو ما يشير إليه السؤال. يجب عليك اتباع نهج استباقي وتحليل جميع خياراتك قبل اتخاذ القرار. ربما يمكنك تغيير مواصفات المشروع؛ ربما يمكنك التوقف حتى يصبح هناك شيء واضح للتطور؛ قد تتمكن من تغيير نهج المشروع (على سبيل المثال، اختيار جهة خارجية لمتابعة المشروع)، إلخ.


### مثال: التفكير النقدي

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

للإشارة، يمكن استخدام قائمة التحيز المعرفي في ويكيبيديا .

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


### مثال: الشفافية

نود أن نتجنب التأخر أو وجود أي مشكلة في المشروع، ولكن هذا لا يعني أننا يجب أن نخفي هذه الحالات إذا حدثت. كن شفافاً وأبلغ أصحاب المصلحة، حيث قد يتمكن بعضهم من مساعدتك. على أي حال، سوف يكتشفون في النهاية المشاكل ونتائجها عاجلاً أم آجلاً، وسيتعين على بعضهم التصرف بسرعة (على سبيل المثال، قبول النتيجة السلبية).


### مثال: التواصل بنجاعة

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


### مثال: تحمل المسؤولية

من السهل إلقاء اللوم على الآخرين بسبب النتائج السيئة. على سبيل المثال، قد ترغب في ان تمنحك مؤسستك السلطة الكاملة لتغيير كل شيء في المشروع والقيام بذلك بشكل مثالي، لكنهم لا يفعلون، ونتيجة لذلك، يفشل المشروع. هذا ليس نهج استباقي.

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


## NUP4 تذكر أن السلسلة قوية فقط مثل أضعف حلقاتها

[image]

هناك مجالات مختلفة في المشاريع وكلها تتطلب عناية خاصة. يجب أن يكون لدينا منظور شامل للمشروع. لا يكفي الانتباه إلى مجال يبدو مهمًا (على سبيل المثال، الوقت)، حيث أن جميع المجالات تتفاعل وتعمل بشكل صحيح فقط إذا كانت جميعها تتلقى ما يكفي من الاهتمام.


### مثال: كل شيء يعتمد على الموعد النهائي!

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

هل سمعت بهذه القصة الشهيرة التي التقى فيها الرئيس كينيدي بواب وكالة ناسا وسأله عما كان يفعله، فأجاب: “أنا أساعد في وضع رجل على سطح القمر”؟ هل تساعد مشاركة هذا النوع من الأشخاص في احترام المواعيد النهائية؟

مع تقدمك، ستجد أن كل مجال من مجالات المشروع يساهم في إدارة الوقت، ولا يمكنك احترام الموعد النهائي مع اليقين المقبول إذا لم تهتم بجميع المجالات.


### مثال: قطف الكرز

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

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

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


### مثال: Anti-Processus

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

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


### مثال: هذه هي جميع المجالات التي تحتاج إليها

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

تعد محاور PRINCE2^(®) مجالات، لكن هذه فقط المجالات التي تلعب دورًا رئيسيًا في المنهجية. المجالات الأخرى هي ضمنية فقط.

دليل PMBOK^(®) ليس منهجية ويمكن صياغته بشكل أفضل مع مجالات المعرفة العشرة. ومع ذلك، فهذه تفسيرات لجميع المجالات استنادًا إلى منظور PMBOK^(®) Guide في المشروع، بدلاً من منظور محايد (وليس بالضرورة أن يكون هناك منظور محايد). على سبيل المثال، لا تحظى الجوانب البشرية باهتمام كبير في دليل PMBOK^(®).

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

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


## NUP5 لا تقم باي شيء بدون هدف واضح

[image]

يجب ألا تفعل أي شيء ما لم يكن له هدف واضح. تخيل عالمين متوازيين حيث كل شيء هو نفسه باستثناء الشيء الذي تفكر في القيام به: ما مدى اختلاف هذه العوالم؟ هل الفرق يستحق الجهد للقيام بهذا الشيء؟

إذا لم يكن لديك هدف واضح وفعلت شيئًا فقط لأن أي شخص آخر يقوم بذلك، أو يقول الجميع إنه من المهم القيام بذلك، فعندئذ:

  - قضيتك قد لا يكون لها فائدة حقيقية، ولايمكنك الحصول على أي شيء منها، او
  - قد تظل لها فوائد محتملة في قضيتك، ولكن نظرا لأنك لا تضع الهدف في الاعتبار، فقد لا تساعد طريقتك في تحقيق الأهداف.


### مثال: الملفات والبرامج

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

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


### مثال: المشروع ككل

تختلف مرونة المنتج حسب المشروع. في بعض مشاريع تطوير تكنولوجيا المعلومات، يكون المنتج مرنًا تمامًا ويعتمد شكله النهائي على الملاحظات الناتجة عن الزيادات في المنتج أثناء المشروع، مما يتطلب اتباع نهج تكيفي (Agile). إنه عملياً مزيج من طبقات الملفات، البرنامج والمشاريع، وينبغي إيلاء أقصى درجات الاهتمام للهدف النهائي. من المستحسن توثيق الهدف وجعله في متناول اليد؛ هذا هو أحد أهداف “رؤية المنتج” المستخدمة في بعض أنواع المشاريع مثل مشاريع Scrum. الانتباه إلى القيمة التجارية في مشاريع Agile هي وسائل مواكبة لهدفهم.

في أنواع المشاريع الأخرى، حيث يكون المنتج ثابتًا نسبيًا وهناك آليات أخرى لضمان أن المنتج المحدد يفي بالهدف المرغوب فيه، يمكن لأعضاء فريق المشروع تحويل الكثير من تركيزهم من الهدف إلى المنتج (ومن هنا المبدأ “التركيز على المنتج” في PRINCE2^(®))، ولكن يلزم الحد الأدنى من الاهتمام للمنتج لتحقيق هذا الهدف، والذي يمكن أن يتحقق بالقيام بمقارنة بين الفوائد المحتملة والفوائد المتوقعة (وبالتالي مبدأ “التبرير المستمر للأعمال” وموضوع “حالة العمل” في PRINCE2^(®)).

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


### مثال: مراقبة المشروع

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

عندما يتعلق الأمر بالمتابعة، سيتم إجراء مراقبة منخفضة المستوى للمشروع باستخدام أدنى مستوى للمتغيرات، لأنه قد لا يكون من الممكن تتبع الهدف النهائي. في هذه الحالة، يجب أن تظل لديك الأغراض في الاعتبار: ما هو الغرض من المراقبة؟

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

جميع القياسات الأخرى، مثل القيم المخططة والفعلية حتى الآن، هي مجرد قيم مؤقتة نحتاجها من أجل حساب التوقعات، وليست القيم النهائية التي نستخدمها لأغراض إدارية.


### مثال: الوثائق

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

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

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

البحث عن “نسخة” هو عكس فعل شيء بناءً على الغرض.


### مثال: تقرير عن وضعية المشروع

من الشائع أن يكون لديك تقارير وضعية طويلة جدًا في العديد من المشاريع. استنادًا إلى هذه القواعد العامة تقريبا (NUP)، يجب أن نسأل أنفسنا ما هو الغرض من التقرير وكيف يمكننا تحقيق هذا الهدف، بغض النظر عما يمكن لمعظم الناس فعله.

يمكن أن يقودنا هذا في العديد من الحالات إلى إعداد تقارير بسيطة للغاية من صفحة واحدة يقرأها أصحاب المصلحة ويفهمونها حقًا بدلاً من التقارير الطويلة. يساعد هذا أيضا على الانتباه الى الهدف.

ومع ذلك، إذا كنت تعد تقارير من صفحة واحدة، فقد يعترض بعض الأشخاص ويعتقدون أنه ليس لديك نظام متابعة “مناسب”. يؤدي هذا في الأساس إلى إنشاء هدف ثانٍ لك (بالإضافة إلى الهدف الأول، وهو مساعدة أصحاب المصلحة على فهم حالة المشروع) ولتحقيق ذلك، يمكنك ببساطة إنشاء نوع ثانٍ من التقارير الطويلة جدًا. ومع ذلك، فلن تجمع هذا مع التقرير الأول لأن هذين الهدفين ليسا متماثلين.


### مثال: دراسات العمل وميثاق المشروع

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

عند التفكير في كيفية إعداد المستندات لتحقيق أهدافها، لا يمكنك التفكير في جميع السيناريوهات وقد تفوتك بعض التفاصيل. لتجنب ذلك، يمكنك التحقق مما يقترحه PRINCE2^(®) وPMBOK^(®) Guide وP3.express وDSDM^(®)، ثم تقييم هذه الاقتراحات بناءً على أهدافك.


### مثال: ما بعد المشروع

على الرغم من أن المشروع له هدف محدد ويمكن أن نأخذه في الاعتبار في جميع مراحل المشروع، إلا أن تحقيقه يتم تقييمه بشكل أساسي على أساس التوقعات التي تم إجراؤها أثناء المشروع، ويجب ألا ننسى ذلك بمجرد الانتهاء من المشروع. من المهم التحقق من تحقيق الأهداف بمجرد اكتمال المشروع للأسباب التالية:

  - يمكننا أن نرى كيف يتم تحقيق الأهداف النهائية والتعلم منها لمشاريع المستقبل، و

  - في بعض الأحيان لا تتحقق الأهداف إلا إذا قمنا ببعض الأعمال الإضافية بعد الانتهاء من المشروع، وفهم الحاجة إلى هذه المهام الإضافية يتطلب المتابعة.

تعتبر مراقبة ما بعد المشروع خطوة ضرورية إذا كنت موجهة نحو الهدف. هذه هي مسؤولية أنظمة إدارة البرامج بشكل أساسي، وبما أن معظم الشركات لا تملك هذه المستويات الإدارية، يتم تجاهل هذه الخطوة عادة. لهذا السبب تضيف P3.express وDSDM^(®) هذه الخطوة إلى منهجيات إدارة المشاريع.


### مثال: البساطة

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

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


### مثال: الملائمة

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

بمجرد وضع الأهداف في الاعتبار، ستفهم بشكل أفضل كيفية ملائمة الانظمة والوثائق مع مشاريع مختلفة.


## NUP6 استخدام العناصر القابلة للتكرار

[image]

يتطلب النهج المخصص للمشروع الكثير من الطاقة والموارد، ويواجه دائمًا خطر فقدان بعض العناصر الضرورية. أفضل طريقة لتبسيط ما يجب القيام به هي استخدام العناصر القابلة للتكرار، ويفضل أخذها في دورات قابلة للتكرار.


### مثال: قوائم مراجعة الجودة

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

  - أولاً، يمكنك إنشاء قائمة بجميع المعايير، وهي شكل من أشكال التخطيط.
  - يوصي المبدأ NUP6 بتوحيد القائمة: هل هناك تسليمات مماثلة في المشروع؟ في هذه الحالة، قم بإعداد قائمة تحقق الجودة العامة لهذه الفئة من التسليمات واستخدامها لكل منها. إذا كانت المتغيرات موجودة، احتفظ بهذه القائمة وأضف بعض العناصر الإضافية للنواتج الفردية. الآن لديك قوائم مرجعية قابلة للتكرار.
  - عندما تقوم بإعداد قوائم تدقيق عامة لأنواع مختلفة من التسليمات، يمكنك العثور على عناصر مكررة، مما يشير إلى إمكانية إنشاء فئة رئيسية افتراضية لها. في هذه الحالة، بدلاً من تكرار عناصر كل هذه القوائم العامة، قم باستخراجها ووضعها في قائمة أم. أخيرًا، سيكون لديك على الأرجح قائمة عامة للمشروع بأكمله. تعتبر معايير القبول Scrum مثالاً على قائمة مراجعة الجودة (من بين أمور أخرى) على مستوى المشروع. عند القيام بذلك، سينتمي كل ناتج إلى تسلسل هرمي للفئات وسيتعين عليه إرضاء العناصر التي تظهر في قوائم جميع فئات سلسلتهم.

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


### مثال: العمليات وسير العمل

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

تحتوي المشروعات Agiles على عناصر قابلة للتكرار في نهج التطوير التكراري الخاص بها، حيث يتم تكرار نوع معين من أنشطة التطوير لكل وظيفة؛ مثلا الروتين اليومي الشائع في XP (eXtreme Programming): الإقران، واختيار عنصر، تصميمه على لوحة بيضاء، وإنشاء نصوص برمجية للاختبار، ودمج الرمز، إلخ.

بجانب مهام سير العمل القابلة للتكرار التي يمكن استخدامها في الأنشطة الفنية، يمكنك أيضًا إنشاء عناصر قابلة للتكرار لأنشطة إدارة المشروع. تعتبر العمليات في PMBOK^(®) Guide وPRINCE2^(®) وDSDM^(®) والأنشطة في P3.express والأحداث في Scrum هي أمثلة على هذا المفهوم.


### مثال: الدورات

وجود عناصر قابلة للتكرار لإدارة المشروع أمر مفيد. يمكن جعل هذا أسهل عن طريق وضعها في دورات قابلة للتكرار. تعمل هذه الدورات على تبسيط الأنشطة اليومية للمشاركين في إدارة المشروع وتوجيهه. دورات مجموعة العملية في دليل PMBOK^(®) المستخدم في مشروع متعدد المراحل، خطوات في PRINCE2^(®)، دورات يومية وأسبوعية وشهرية في P3.express، التكرارات وTimeboxes في DSDM^(®) وSprints في Scrum هي أمثلة على هذا المفهوم.

الدورات القصيرة هي أسهل في الفهم والاستخدام من الدورات الطويلة؛ على سبيل المثال، تختلف Sprints in Scrum عن المراحل وفقًا لدليل PMBOK^(®). ومع ذلك، قد لا تكون الدورات القصيرة جدًا كافية لدعم أنواع معينة من المشاريع. قد يكون الحل هو استخدام عدة دورات، مثل استخدام DSDM^(®) لدورات timebox القصيرة ذات دورات التكرار الأطول، أو استخدام P3.express في الدورات اليومية والأسبوعية والشهرية.


### مثال: الأساليب

يعد استخدام منهجية أو إطار عمل لتنفيذ مشروع مثالًا آخر على استخدام العناصر القابلة للتكرار. قد تكون منهجية حالية مثل PRINCE2^(®) أو P3.express أو DSDM^(®) أو Scrum أو نظام قمت بتخصيصه أو بنائه بنفسك. ومع ذلك، من الأفضل عادة البدء بإحدى المنهجيات الحالية وتكييفها حسب احتياجاتك بدلاً من بناء طريقة جديدة.

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