ما هو الفريق الأفضل لبناء المنتج الرقمي؟

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

المقدمة:

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

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

هل توفير المال في توظيف عدد أقل سيؤدي لمنتج سيئ, أم الإسراف في التوظيف سيؤدي لصرف المال الزائد دون حاجة, أم هل ربما يوجد خيار ثالث لإستأجار خدمات خارجية من شركات تطوير وبرمجة؟

في ما يلي سنوفي بإجابات مناسبة وعملية لهذه التساؤلات بحيث نأخذ جميع الإعتبارات المالية والتقنية والإدارية بعين الإعتبار.

أرضية مشتركة:

دعنا نبني أرضية مشتركة بيننا قبل المضي قدماً في هذه الورقة ولنتفق على النقاط التالية:

1. سوف تكون طريقة الطرح بعرض الحالة المثالية العامة للفريق ومهامه ومن ثم مناقشة حالات أخرى تدور في فلك ذلك.
2. لن يتم التطرق إلى الرواتب التي تدفع للموظفين لأن ذلك يختلف بحسب البلد.
3. فهم طبيعة فريق المنتج ومهامه ووظائفه يأتي قبل القرار بعدد الموظفين فيه.

طبيعة فريق المنتج:

وراء كل منتج رائع وعظيم, يقبع فريق تطويره العظيم.

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

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

الهدف النهائي هو تقديم قيمة للعملاء ودعم الشركة لتحقيق أهدافها.

هذا النص السابق تقريباً وبتصرّف, ما بدأت به مقالة وجدتها على موقع Aha والرابط من هنا.

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

1. فهم الإحتياج في السوق.
2. خلق شيئ جديد يسد الإحتياج.
3. تقديم الشيئ الجديد للسوق.
4. وضع الأولويات.
5. تحليل رحلة العميل وقياس الأداء.
6. تقديم قيمة للعملاء.
7. ودعم الشركة لتحقيق أهدافها.

هل لازلت تعتقد حتى اللحظة أن فريق المنتج هو مجموعة من المبرمجين بشاشات سوداء؟؟

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

مهام الفريق:

المهام الرئيسية لفريق المنتج الواحد:

1. الإدارة Management.
2. التحليل Analyzing.
3. البناء Building.

ثلاث مهام رئيسية ينطوي تحتها مهام فرعية عديدة كما سنأتي عليهم تباعاً.

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

1- الإدارة Management:

وهنا نقصد إدارة المنتج وإدارة المشروع.

1. إدارة المنتج Product management: وتأخذ هذه المهمة نطاق العمل على إدارة المنتج من النواحي التقنية والتسويقية والمالية ورضى العملاء, يسعى مدير المنتج لضمان بناء منتج يحتاجه العميل ويرغب بشراءه بسعر مفيد للشركة وطريقة عمل مرضية للعميل.

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

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

2- التحليل Analyzing:

ونعمم المفهوم هنا إلى:

1. تحليل العمل التجاري ومتطلباته وفهمها قبل البدء ببناء حلول رقمية ويقوم بذلك الـ Business analyst.
2. جمع وتنظيف وتشذيب وتوصيف المعطيات واستخراج التوصيات منها عندما يكون المنتج قيد الإستخدام ويقوم بذلك Data analyst.

3- البناء Building:

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

أدوار الفريق:

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

لكن عموماً يجب عليك المرور على القائمة الطويلة أولاً لتكون الصورة الكبيرة مكتملة عندك.

وعليه فإن أدوار الفريق, ونقول أدوار وليس أشخاص لأن كل دور قد يقوم به أكثر من شخص أو ربما شخص واحد يقوم بأكثر من دور:

1. مدير المشروع Project manager: مهمته إدارة المشروع كتكلفة وتخطيط ومصادر وخط زمني ومخاطر وهلم جر.
2. مدير المنتج Product manager: يقوم بإدارة المنتج كمنتج فقط, بنائه وميزاته وشكله وأدائه وإدخاله السوق والخارطة الزمنية لمراحله وملائمته للإحتياجات وهلم جر.
3. صاحب المنتج Product owner: يشرف ويحّسن ويسهّل عمليات بناء المنتج الرقمي كاملة داخل الفريق ويتعامل مع أعضاء الفريق المسؤولين مباشرة عن عملية البناء من جهة ومع مدير المنتج ومحلل الأعمال (والعميل لو وجد) من جهة أخرى.
4. محلل الأعمال Business analyst: يحلل العمل التجاري ومتطلباته وفهمها.
5. محلل البيانات Data analyst: يوجد أدوات مناسبة لجمع وترتيب وتشذيب ومن ثم تحليل البيانات حول المنتج واستخدامه وأسواقه بما يخدم مصالح أي طرف يهمه الأمر.
6. سيد السكرم Scrum master: يشرف على الأداء اليومي للفريق ويذلل التحديات أمامهم.
7. مطور الواجهة الخلفية Backend developer: يقوم بكاتبة الكود البرمجي الأساسي للمنتج الرقمي.
8. مطور الواجهة الأمامية Frontend developer: يكتب الكود البرمجي وما يلحق به من أدوات ومكتبات للواجهات الأمامية التي يراها المستخدم.
9. مطور تطبيقات الموبايل Mobile app developer: وله تخصصات من حيث نظام التشغيل Android or IOS ويمكن أن يكون تخصصه بحسب لغة البرمجة التي قد تلائم كلا نظامي التشغيل.
10. محلل تجربة المستخدم User Experience UX.: يقوم بدراسة أنواع المستخدمين وسلوكهم ويضع مخطط لرحلتهم ضمن المنتج الرقمي.
11. مصمم الواجهات User Interface: يأخذ المخرجات من محلل تجربة المستخدم ويتعاون معه لخلق واجهات مناسبة.
12. مهندس إختبار البرمجيات Software testing engineer: يجري الاختبارات على البرامج أو التطبيقات للتأكد من أنها تعمل بشكل صحيح.
    ويقوم بتصميم حالات الإختبار Test cases وسيناريوهات الإختبار Test scenarios . ويجهز أدوات الإختبار الضرورية لذلك ويدرب الأعضاء المعنيين عليها.
13. مهندس ضمان الجودة للبرمجيات Software quality assurance engineer: يراقب عملية بناء المنتج من الألف إلى الياء مع أدق التفاصيل من وصف الميزات ومن ثم بناءها وكتابة الكود البرمجي لها وطريقة عمل الكود وتعقيده ووضوحه وإستقراره وقابلية التوسع فيه وآليات الإطلاق والتصحيح وهلم جر ويعطي التوصيات اللازمة بما يضمن الجودة للمنتج الرقمي.
14. مهندس العمليات والتطوير DevOps: بناء العمود الفقري الأساسي البرمجي والتقني الذي يضمن سلاسة وإستقرار مرحلة إصدار النسخ المتتابعة للمنتج من مرحلة البناء والإختبار ووصولاً لمرحة الإطلاق الرسمي للعملاء والسوق وعوداً إلى جمع الملاحظات والتصحيح.
15. مسؤول الخادم Server administrator: تجهيز الخوادم وصيانتها والتأكد من أن البنية التحتية التقنية تعمل بسلاسة.

كل الأدوار تم ذكر وصفها باختصار ولكي تتوسع أكثر بمهامهم وتخصصاتهم تحتاج بحثاً مخصصاً لكل دور على حدى.

ولكن أريد أن أنوّه لنقطة مهمة جداً كي لا تقع في لبس ولخبطة, كوني عاينت بعض المعاناة التي يقع فيها رواد الأعمال عند محاولتهم لفهم مهام ومسؤوليات كل دور من الأدوار أعلاه وإليك الملاحظة المهمة.

تقريباً فإن 70% من الوصف الوظيفي لكل دور هو نفسه لدى كل الشركات ولكنهم يختلفون بما يقارب 30% من الوصف الوظيفي بسبب تخصيصهم لقوالب وظيفية تناسب حجم الشركة وحجم الدور والمشاريع وطبيعتها وهلم جر.

مثال:

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

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

في مايلي العلاقة بين الأدوار في مخطط بسيط:

تحليل سريع للمخطط أعلاه:

1. كما نرى من المخطط أن هنالك اختلاف واضح بين شركة برمجة تريد بناء منتج رقمي لعميلها, وبين شركة ناشئة تريد بناء منتجها الرقمي لنفسها.
2. نريد التركيز على الحالة الثانية فقط وهي شركة ناشئة تريد بناء منتجها الرقمي الخاص بها وتدخله للسوق.
3. كما أنني لم أركز على الهرمية في الفريق ومن سوف يقوم بإدارة من أو يقدم تقاريره لمن, هل تعرف لماذا؟ لأنني لا أؤمن بالهرمية في البنية الإدارية وأنا مؤمن بالبنية المفتوحة flat وأن كل فرد يجب عليه القيام بعمله من تلقاء نفسه.
4. ولا ننسى أنه في هذه الحالة يجب توظيف فقط الناس الثقاة ويجب وضع مقاييس واضحة للأداء وهذا موضوع شيق وطويل لا يسعنا طرحه هنا.
5. يعمل الفريق وفقط خطط داخلية له ولكنها متلائمة مع خطة العمل التي تم تحضيرها مسبقاً.
6. يمثل مدير المنتج صلة الوصل بين الفريق وبين العالم الخارجي من سوق وإدارة وباقي أقسام الشركة.
7. تحليل الأعمال وإدارة المشروع هي أدوار مهمة في كل الأحوال ويجب تغطيتها بشكل جيد.
8. دور محلل البيانات هو دور محوري ومفيد للعديد من أقسام الشركة.

حجم الفريق:

من الواضح جداً أن خطة العمل للشركة سوف تحدد التالي:

1. التمويل المخصص للتطوير.
2. المدة الزمنية لإطلاق النسخة الأولى للمنتج.
3. التعقيد التقني للنسخة الأولى للمنتج.
4. المواهب والخبرات المطلوبة لبناء البرمجيات.

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

أو ربما يوجد تمويل جيد جداً ولكن النسخة الأولى من المنتج ليست معقدة لدرجة بناء فريق من 14 شخص أو أكثر.

وهنا سوف نقوم بدمج الأدوار تحت أشخاص محددين, والبعض يسميها تعدد القبعات.

وإليكم توصياتي حول الموضوع:

1. دور مدير المنتج وصاحب المنتج ومحلل الأعمال ومحلل البيانات وسيد السكرم في شخص واحد, رغم أن العديد من الخبراء لا يوصي بدمج صاحب المنتج مع سيد السكرم, إلا أنني قمت بتجربة الأمر في العديد من المرّات ووجدته ناجح إلى حد ما.
2. دور محلل تجربة المستخدم ومصمم الواجهات يكونون نفس الشخص UX/UI.
3. مبرمج الواجهات الأمامية ومبرمج الواجهات الخلفية يمكن أن يكون مبرمج محترف يجيد الأمرين, ولكنني لا أوصي بدمجهم إلا للضرورة القصوى.
4. مهندس الإختبار ومهندس ضمان الجودة يمكن دمجهما بشخص واحد بشرط توفر شخص خبير في ذلك لأنه في الحالة العامة فإن مهندس الإختبار لا يتوفر عنده الكفائة في ضبط الجودة والعكس بالعكس.
5. مهندس العمليات والتطوير ومسؤول الخادم عموماً ممكن أن يكونو نفس الشخص ونرى هذه الحالة كثيراً في الشركات الصغيرة.
6. قد نحتاج حس إداري لإدارة المشروع ويمكن إسناد هذه المهمة لمدير المنتج عموماً في الشركات الصغيرة.

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

سؤال مهم:

هل هنالك حجم مثالي لفريق المنتج عند بدء الشركة من يومها الأول؟

الإجابة:

من وجهة نظري أفضّل أن يكون الفريق عند البداية على الشكل التالي:

1. شخص محنّك إدارياً ليكون مدير المنتج وصاحب المنتج و محلل الأعمال ومحلل البيانات وسيد السكرم بدوام كامل.
2. مبرمج واحد محترف للواجهات الخلفية بدوام كامل ويكون مسؤول عن ضبط الجودة أيضاً.
3. مبرمج واحد متوسط المستوى للواجهات الخلفية.
4. مبرمج واحد للواجهات الأمامية بدوام جزئي او كامل بحسب طبيعة المنتج.
5. مبرمج واحد للموبايل لو لزم الامر بدوام جزئي او كامل بحسب طبيعة المنتج.
6. شخص تقني محترف لإدارة الخادم والعمليات والتطوير بدوام جزئي.
7. شخص مختص بالإختبار ويكون بدوام جزئي.

ولكن هذه الإجابة لا تتعدى أن تكون مجرد وجهة نظر عامة جداً, لأن هنالك الكثير من العوامل التي قد تجعل منها وجهة نظر خاطئة أو قاصرة نوعاً ما.

شركة تطوير خارجية:

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

لن أقوم بمفاضلة خيار على آخر لأن المفاضلة تختلف وليست مطلقة وهي متعلقة بعوامل عديدة, لذلك سأكتفي بذكر هذه العوامل وأطلب من القارئ العزيز دراسة حالته طبقاً لهذه العوامل وأخذ القرار بعد ذلك:

1- القدرة:

هل أنت قادر على القيام بكلا الخيارين أصلاً, لأنك لو لم تكن كذلك فلا داعي للتفكير بينهما!

أي هل لديك قدرة على التوظيف الجيد لموظفين جيدين, وهل لديك القدرة أيضاً على إيجاد شركة برمجيات ممتازة وموثوقة.

إذا لم تكن قادر على أخذ أحد الخيارين فقم بالخيار المتبقي دون التفكير والعناء.

2- الميزانية:

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

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

3- الجودة:

هل تهمك الجودة إلى أقصى حد, وفكرة مشروعك مستقرة ومجرّبة وأنت فقط تحتاج البرمجية لتشغيلها فوراً (نظام لأتمتت عملية التسجيل ضمن الجامعة عندك) أم ترى أن الجودة يجب فقط أن تكون مقبولة إلى حين إستقرار نموذج العمل, ومن ثم يمكنك تحسينها؟

وعليه ستقوم بتقدير الخيارات المتاحة طبقاً لجودتها.

4- الإدارة:

هل لديك تجربة إدارية وحنكة للعمل مع فريق داخلي؟ أم لديك تجربة لإدارة مشروع مع شركة عن بعد نوعاً ما مع إختلاف التوقيت ربما؟ أم لديك تجارب عمل مشترك ناجحة مع شركات محلية؟ أم لديك تجارب ناجحة مع موظفين أصدقاء سابقين؟

5- الزمن:

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

6- المرونة:

هل فكرتك جديدة وربما ستتغير كثيراً أثناء البناء, أم مشروعك واضح للغاية ولا مجال للتغيير, وهنا هل الشركة البرمجية التي ستعمل معها معتادة على مشاريع تتغير كثيراً أم لا؟ وبالمثل, هل لديك فريق مرن وتديره بمرونة أم لا؟

7- الخبرة:

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

وشركائك مصدر الخبرة والتخصص.

8- الإستمرارية:

إلى أي مدى تثق بمشروعك واستمراريته على مدى السنوات القادمة, هل أنت تجرّب حظك فقط؟ ام أنت تبني حلّاً مستقراً ومتأكد تماماً من ديمومته واستمراره.

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

ملاحظة أخيرة:

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

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

من وجهة نظري أراه خيار رائع ولكن فقط لمن يحترف توظيف وإدارة المستقلين فهو أمر ليس بالسهل بتاتاً

التعاقد بطريقة Build–operate–transfer (BOT):

ثبت بالتجربة وفي أغلب الحالات لدى العديد من الشركات النقاط التالية:

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

لذلك ظهر نموذج آخر مريح يسمى Build–operate–transfer (BOT) كنت أستخدمه سابقاً مع عملائي ولم أكن أعلم بالضبط التسمية العلمية له إلى أن سمعت صديقي عبد الله السباعي يتحدث عنه في إحدى مؤتمرات ديجيتال إسطنبول.

عبد الله هو المدير التنفيذي لشركة NBS Venture ويقدمون ذات الحلول التي أتكلم عنها هنا.

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

يرتكز هذا النموذج على طرفين متعاقدين:

1. طالب الخدمة.
2. ومقدم الخدمة.

والمراحل في التعاقد هي:

1. بناء الفريق المناسب وتجهيزه للبدأ ونسميها مرحلة Build (B).
2. بناء وإداخل المنتج للسوق والتصحيح ونسميها Operate (O).
3. نقل المنتج والفريق وكل ما يتعلق بهما إلى جانب طالب الخدمة ونسميها Transfer(T).

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

لكنه يوفر عناء الأخطاء التقنية, والأخطاء الإدارية والوقت المستغرق في التوظيف ويحقق إستقرار عالي للمنتج والخدمة والشركة كلهم مجتمعين.

وأهم ميزة هي: سهل البدء عند ورود الفرصة, وسهل الخروج في حال الفشل في السوق.

العمل عن بعد:

توظيف الفريق والعمل معه عن بعد له العديد من الإيجابيات والسلبيات ويوجد آلاف المقالات تتحدث عن ذلك, وعليه لن أورد هنا تكرار لذلك بل سأعطي نقاط مهمة لن تقرأها في مكان آخر بسهولة لأنها وليدة تجربتي مباشرة وهي:

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

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

ومنه يجب توفر الأدوات الإدارية والتطبيقات التي تسهّل تطبيق هذه المنهجيات, وبالتالي فإن الإنتقال من المكتب للعمل عن بعد سيكون أمراً سلساً جداً بدون تحديات كبيرة.

ملاحظة مهمة لمن يعمل من المكتب:

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

الخاتمة:

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

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

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