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

مراجعة سريعة للمصطلحات

*بإمكانك تجاوز هذا القسم من المقالة إذا كنت ملما بالمشاريع والمنتجات.

حسب الدليل المعرفي لإدارة المشاريع (PMBOK Guide)، الصادر من معهد إدارة المشاريع (PMI) "المشروع هو مسعى مؤقت يُتخذ من أجل الوصول لمنتج أو خدمة أو نتيجة متفردة". يقصد بكلمة "متفردة" كون المشروع جديدا أو لديه عناصر أساسية مختلفة عن المشاريع السابقة، مثلا مشروع عمارة طبق الأصل من عمارة قام الفريق ببنائها سابقا لكن ستبنى في موقع مختلف. أم كلمة "مؤقت" فيقصد بها وجود توقيت لبداية المشروع ونهايته، وليس سلسلة من المهام المستمرة بدون نهاية واضحة، مثل مهام صيانة السيرفرات أو خدمة العملاء [2].

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

أما بالنسبة للمنتج، سأستخدم التعريف التالي البسيط من موقع !Aha "المنتج هو أي شيء أو خدمة يمكن بيعها لخدمة إحتياج زبون أو رغباته". وإدارة المنتجات حسب موقع ProductPlan هي "التخطيط الإستراتيجي لبناء وإطلاق ودعم وتطوير منتجات شركة". تحدثت في مقال سابق عن مهام مدير المنتجات وأمثلة المنتجات وبالتالي لن أطيل عليك الشرح هنا.

عمل المشاريع وعمل المنتجات

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

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

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

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

عقلية المشروع وعقلية المنتج

المشكلة التي لاحظتها وعليها قررت كتابة المقالة، هي محاولة شركات وأفراد صُنع منتج تقني، لكن يتم التفكير فيه وإدارته كمشروع تقني، مما يرفع من احتمالية فشله وضياع الوقت والجهد والمبالغ المصروفة عليه. فلنتحدث عن الفروقات في التفكير والإدارة (وأشير إليهما بالعقلية) بين المشاريع والمنتجات.

نجاح المشروع في تسليمه حسب المتطلبات ضمن الميزانية والوقت، أما نجاح المنتج فهو في حل مشكلة أو توليد أرباح

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

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

المسألة السابقة تقع فيها أيضا الشركات التى تعتمد على التعهيد (الاوت سورسينج) في بناء منتجها. شركة التعهيد تتعامل مع المنتج كمشروع، وتتوقع متطلبات واضحة في بداية المشروع لكي تبني عليها الميزانية والوقت. اي تعديلات بعد الانتهاء من المشروع ستتطلب مشروعا جديدا وقد لا يكون الفريق التقني متوفر لانشغاله بمشاريع اخرى [4].

فريق المشروع مؤقت، فريق المنتج حتى الموت!

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

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

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

متطلبات المشروع معروفة، متطلبات المنتج غامضة

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

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

تركيز المشروع على الانتاجية، تركيز المنتج على النتائج

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

يسعى المشروع إلى التسليم، ويسعى المنتج إلى الاستدامة

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

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

يتفادي المشروع التغيير، ويتبناه المنتج

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

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

هل يعني هذا أن إدارة المشاريع غير مناسبة للمنتجات؟

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

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

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

الملاحظات

[1] خصصت الكلام عن المنتجات التقنية لأن هذا مجالي. لا أفتي في أنواع  المنتجات الأخرى فغيري أعلم بذلك.

[2] توجد تفاصيل وإستثناءات عديدة هنا، لكن ليس هذا مجال المقالة فاضطررت للاختصار.

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

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

المصادر

https://productcoalition.com/product-thinking-vs-project-thinking-380692a2d4e

https://www.koombea.com/blog/the-difference-between-product-and-project-management

https://martinfowler.com/articles/products-over-projects.html