أسامة محمد3

نعمل باستمرار في إدارة المنتجات على بناء منتجات تحل مشاكل مستخدمينا. ومع ذلك، لا يرغب العملاء في أن تكتفي الشركات بتوفير المنتجات؛ بل يريدون أيضًا أن يكون لديهم اتصال شخصي بالمنظمة التي يدفعون لها المال! إن الطلب على التعامل المستمر بين البائع والمشتري حتى بعد توقيع العقد آخذ في الارتفاع، فكل من الشركات والعملاء يرغبون بذلك. وتنعكس فائدة تبادل الملاحظات على الميزات جلية لكلا الطرفين، فأنت تعطي وتتلقى؛ ومع ذلك، نظرًا لأن هذا المستوى من التركيز على العملاء يبدو ظاهرةً جديدةً إلى حد ما بالنسبة للعديد من الشركات، فلا توجد قواعد واضحة للعملية حتى الآن، خاصةً عندما يتعلق الأمر بإهمال ملاحظات معينة أو اقتراحات بخصوص الميزات. ليس من بالضروري أن يكون هذا حال جميع الشركات فقط لمجرد كونها ظاهرة جديدة لبعض الشركات. لقد صادفت العديد من الشركات التي تتقن تمامًا إدارة الملاحظات، ولكن مقابل كل شركة تزدهر في هذا المجال، هناك خمس شركات تعاني، على الرغم من أن بعضهم يبذلون قصارى جهدهم ليكونوا متمركزين حول العملاء ويبحثون عن رضا العميل، إلا أنهم ما زالوا غير قادرين على بناء المنتج الناجح الذي يهدفون إليه، لكن لماذا؟ ما الصعوبات الشائعة بخصوص تقديم الملاحظات على المنتج؟ من المؤكد أنه سبق لأي مدير منتج ولو مرةً في حياته المهنية تلقي ملاحظات من العملاء على المنتجات بطريقة ما. وربما واجهنا جميعًا المشكلة التالية الشائعة: وهي جودة التعليقات. قد يعاني العملاء أحيانًا من ذكر أسماء الأشياء بأسمائها الحقيقية المتعارف عليها. ومع ذلك، فإن مهمتنا كمديرين للمنتجات هي فهم ما يحاولون التعبير عنه، لذا فليس ذنب عملائنا أنهم لا يستطيعون شرح منتجنا لنا. بل هذه مشكلتنا لأننا لم نوضح لهم المنتج بطريقة جيدة. للتغلب على صراع "التعليقات منخفضة الجودة"، من الضروري عليك التعامل مع عملائك. يمكن أن يحدث هذا على وسائل متعددة، بينما تتحقق بعض الشركات من رضا العميل من خلال إجراء مقابلات مع العملاء، فقد يستخدم البعض الآخر استطلاعات البريد الإلكتروني. عادةً ما تصبح إيجابيات وسلبيات كل وسيلة تواصل واضحةً بعد إعداد العملية، والتي غالبًا ما تكون متأخرة جدًا إذا فاقت العيوب الإيجابيات. ومن واقع خبرتي، فإن الطريقة الأكثر فائدةً للتفاعل مع عملائك مع توفير مساحة مركزية واحدة لهم لمشاركة أفكارهم أو مشكلاتهم، هي استخدام أداة إدارة ملاحظات المنتج، وهي متوفرة عبر الويب. إذا تلقيت تعليقات لا تخدم عمق الرؤية التي تبحث عنها، فسيتعين عليك ببساطة التعمق أكثر بطرح الأسئلة. ويمكن تحقيق ذلك على أفضل وجه من خلال الأسئلة الخمسة: من؟ ولماذا؟ وماذا؟ ومتى؟ وأين؟ متى عليك أن تصغي جيدا للعملاء؟ تكمن الفكرة في أنه عليك دائمًا الاستماع إلى عملائك. زودهم بطريقة لتوصيل أفكارهم والمشكلات المتعلقة بمنتجك. ومع ذلك، فإن استماعك إليهم لا يلزمك بالتصرف وفقًا لجميع التعليقات التي تتلقاها منهم. وللتأكيد، هناك الكثير من التعليقات التي يجب أن تُهمل، إما في الوقت الحالي على الأقل أو للأبد، لكن لا تدعونا نستبق الأمور، ففي البداية، دعونا نلقي نظرةً فاحصةً على التعليقات التي تستحق الكثير من الاهتمام وأيضًا كيفية إمكان إشراك عملائك لتزويدك بمثل هذه التعليقات الجيدة. التحقق من صحة خارطة طريق منتجك الفكرة أن عملاءك ليسوا مسؤولين عن إيجاد حلول لمشاكلهم، بل أنت المسؤؤل. والحلول التي تريد بناءها تشكل خارطة طريق منتجك. قد يكون تبرير أفكارك وقراراتك لأعضاء الفريق أو أصحاب الأسهم الآخرين أمرًا صعبًا ومحبطًا، ولكن يمكن أن تساعدك بيانات الملاحظات القابلة للتطبيق في التغلب على هذه العقبة. هذا هو الموضع الذي يجب أن تستمع فيه إلى عملائك. تحقق من صحة خارطة طريق منتجك عن طريق مواءمة أفكارك مع ملاحظات عملائك. وإذا كانت لديك معلومات حية تُظهر أن عملاءك يريدون هذه التحديثات ويحتاجون إليها، فيمكنك تبرير أهمية خارطة طريقك لهم دون تكلف. ومع ذلك، يجب أن يكون لديك خطة أو رؤية تتبعها؛ إذ قد تتسبب إضافة ميزات بدون خطة عمل واضحة لمجرد أن عملاءك يظنون أنهم بحاجة إليها في انهيار لمنتجك. الميزات المصممة تنفيذًا لرغبة العميل، بغض النظر عن مدى قوة أثرها، ستواجه صعوبةً في الترقي والتطور، وفجأةً ستجد نفسك مديرًا لمنتج بدون خطة وتوجيه واضحين. ارتفاع وتيرة الطلبات على المزايا قد يكون من الصعب أحيانًا ربط النقاط الصغيرة ببعضها. فعلى الرغم من أنك تلقيت غالبًا نفس التعليقات أو طلبات الميزات عدة مرات، إلا أن الأمر قد لا يكون دائمًا بهذا الوضوح. قد تكون لدى عملائك حالات استخدام مختلفة تؤدي إلى نفس المشكلة، أو قد يختلف وصف الطلبات. وفي نهاية المطاف، يكون حلها بميزة واحدة، وبالطبع قد يكون واضحًا وضوح الشمس أحيانًا أن العديد من العملاء يريدون الشيء نفسه. في كلتا الحالتين، يكون الوقت قد حان للنظر عن كثب والاستماع إلى عملائك. وحتى إذا كانت خارطة الطريق لا تحتوي على معلم رئيسي مخصص للموضوع، إلا أنك قد تضعه ضمن حساباتك لإضافته لاحقًا إلى الخارطة. ومن أجل تكامل هذه الطلبات بنجاح، يجب أن يكون لديك عملية مستمرة لجمع الملاحظات والعمل على أساسها. وإذا كنت قد بدأت للتو بجمع الملاحظات حول المنتج، فيمكنك هنا العثور على مدخل جيد لحلقة إدارة الملاحظات. متى لا ينبغي عليك الاستماع للعملاء؟ من باب التوضيح، فإن عدم الاستماع لا يعني أنه يجب ألا تقدّم لعملائك فرصةً للتعبير عن اهتماماتهم أو أفكارهم، فالمقصود هنا أنه أحيانًا قد توجد ملاحظات لا فائدة فعلية منها. خلال عملي لدى شركة تقدم أنظمة تتبع لمقدمي الطلبات، طلب أحد أكبر عملائنا و أطولهم أمدًا وهو أحد البنوك، أن يكون المرشحون قادرون على تقديم ملاحظات حول عملية تقديم الطلبات إلى الشركة. كان هذا في الأيام الأولى لمنتجنا، وكان من المهم بالنسبة لنا أن نحافظ على هذا العميل الضخم وأن نجعله سعيدًا. وبالنظر إلى أن الفكرة نفسها تتوافق مع رؤيتنا للمنتج، فقد قررنا المضي قدمًا وبناء الميزة لعميلنا. كانت المشكلة الوحيدة لدينا هي أننا صممنا الحل خصيصًا لذلك العميل، لذا لم يتمكن العملاء الآخرون من الاستفادة منه لأنه كان محددًا جدًا لهذا البنك، وأدركوا أن مرشحيهم لن يتمكنوا من استخدام هذه الميزة. من ناحية أخرى، كان لدينا الكثير من العملاء الصغار، مثل أحد الأشخاص الذي يرغب بالتوظيف. وبعد فترة، أصبح من الواضح أن الأمر لا يتعلق باستخدام أنظمة تتبع لمقدمي الطلبات فحسب، بل أصبح أيضًا يتطلب مبدأ إدارة علاقات العملاء. ونظرًا لكونه طلبًا وصلنا الكثير منه وواجهناه أيضًا في عروض المبيعات، كان علينا التفكير فيما إذا كنا نريد تنفيذه أم لا. نحن كشركة نفخر بأنفسنا لأننا نركز على العملاء ومنفتحون دائمًا على ملاحظات المستخدمين، لكننا الآن وجدنا أنفسنا في مأزق؛ ففي حين أننا نقدّر الملاحظات ونريد أن يكون عملاؤنا سعداء، إلا أن الميزات المقترحة لا تتماشى مع رؤية منتجاتنا. ولكننا في النهاية، قررنا أن نتمسك برؤيتنا ولم ننفذ الطلب. وهذا بالطبع كان له عواقبه أيضًا؛ ولكن بالنسبة لنا، ما زال أسلوبنا يؤتي ثماره وهذا ما يهم. أنا متأكد من أن كل مدير منتج لديه قصص من هذا القبيل، إذ في بعض الأحيان تأخذ بملاحظات العملاء وأحيانًا أخرى ترفضها. إذاً متى يكون من غير المفيد الاستماع إلى ملاحظات عملائك؟ عندما تريد أن ينمو ويكبر منتجك الحالي. عندما لا تتوافق الطلبات مع رؤيتك. عندما تتطلع إلى الابتكار بمفهوم جديد. عندما تريد مفاجأة عملائك بشيء غير متوقع. عندما تريد كسر القاعدة. إذا كنت في شركة صغيرة على وشك النمو الهائل. عندما يكون هناك عدد قليل من الآراء المتماثلة، فلا تدعها تشوشك. نظم ملاحظاتك آخر نصيحة أريد أن أقدمها لك بخصوص عملك هي تنظيم ملاحظاتك. فعلى الرغم من أن الأمر قد يبدو واضحًا، إلا أنني أعلم من التجربة أن العديد من الشركات قد تظن أن تعليقاتهم منظمة؛ ولكن صدقوني، قد لا تكون كذلك. هناك العديد من القنوات التي يمكن أن تصل إليك التعليقات منها، مثل الأقسام الأخرى في العمل ووسائل التواصل الاجتماعي ومنصات التقييم وما إلى ذلك. إذا كنت تريد حقًا أن تكون شركة تركز على العملاء وتعتمد على ملاحظات العملاء في عملية اتخاذ القرار، فعليك أن ترتقي بأسلوب عملك وتجمع كل التعليقات في مكان مركزي واحد. وإذا لم يكن لديك الوقت الكافي لتحقيق ذلك، فهناك الكثير من الأدوات لمساعدتك في إدارة تعليقات المنتج. فطالما أنك تتبع هذا النهج باستمرار، سيساعدك ذلك أنت وشركتك على توفير الموارد على المدى الطويل. ترجمة -وبتصرف- للمقال When Product Managers Should Listen to Their Users لصاحبته Elisabeth. اقرأ أيضًا مفهوم مدير المنتجات ودوره في عملية تطوير المنتج محاسن ومساوئ مدير المنتجات الجديد وكيفية ضبط التوقعات التحضير لمقابلة العمل بهدف الحصول على وظيفة مدير المنتج مقارنة بين مدير المنتج ومدير المشروع كيف تحلل ملاحظات العملاء وتجعلها قابلة للتنفيذ

تعاني فرق المنتج المثابرة طوال الوقت، حتى في ظل أفضل الظروف. وفي كثير من الأحيان، لا يرجع ذلك إلى العجز أو نقص في المهارات داخل الفريق، وإنما بسبب وقوع الفريق في واحد -أو أكثر- من الاختلالات الوظيفية الأكثر شيوعًا في إدارة المنتج. هذه الاختلالات الوظيفية منتشرة للغاية لدرجة أن كل من عمل في إدارة المنتج تقريبًا قد واجهها أكثر من مرة؛ لذا من المهم إذًا فهم ماهية هذه الاختلالات، حتى تتمكن من تجنبها. إليك في ما يلي أكثر 10 اختلالات وظيفية شيوعًا. 1. مبدأ عجلة الهامستر: التركيز على كمية المخرجات أكثر من التركيز على نوعيتها في عجلة حيوان الهامستر، كل ما يهم هو الاستمرار في الركض، على الرغم من عدم الوصول إلى أي مكان. وبالمثل، تركز فرق المنتجات في بعض الأحيان، بصورة شبه كاملة على الإنتاج و الوفاء بالمواعيد النهائية للتسليم، مع القليل من الاهتمام بالنوعية. وازن بين السؤالين التاليين، وسترى الفرق في الرؤية تجاه الأمر. هل أنهيت إصدار تلك الميزة في الوقت المحدد؟ (وجهة النظر التي تركز على المنتج بحد ذاته). هل قدمت هذه الميزة قيمةً فعليةً للعملاء وزادت الإيرادات؟ (وجهة النظر التي تركز على نوعية المنتج). على هذا الأساس، تستطيع الإجابة على تساؤل ما فائدة تأمين المنتج في الوقت المحدد إذا لم يرغب أي عميل بشرائه أو كان على استعداد لدفع ثمنه؟ وللابتعاد عن العمل كمبدأ عجلة الهامستر، ركز على نوعية المنتج وقيمته وليس على المنتج بحد ذاته. 2. مبدأ مكتب المحاسبة: الهوس بالمقاييس الداخلية في مكتب المحاسبة، ينصب التركيز بالكامل على المقاييس الداخلية دون أي اعتبار لرضا العميل. وكما هو ملاحظ، أصبحت العديد من فرق المنتجات مهووسةً بالمقاييس الداخلية مثل ازدياد الإيرادات، وعدد المستخدمين النشطين شهريًا، والاحتفاظ بالعملاء. الحقيقة هي أن معظم المقاييس الداخلية مؤشرات لاحقة لنجاح المنتج، وبالتالي لا ينبغي أن تكون موضع الاهتمام الأساسي لإدارة المنتج. من المفيد جدًا الإجابة هنا على السؤال التالي: "كيف يمكننا تقديم قيمة أكبر لعملائنا بطريقة فعالة؟"، إذا تمكنت من الإجابة عن هذا السؤال وأنشأت نموذج عمل جيد حول تلك الإجابة، فستحذو المقاييس الداخلية حذوك دائمًا. 3. مبدأ البرج العاجي: قلة الاطلاع على رغبات العملاء في مبدأ البرج العاجي، أصبحت فرق المنتجات بعيدةً جدًا عن العملاء لدرجة أنهم بدأوا يظنون أنهم يعرفون عن عملائهم أكثر مما يعرفه العملاء عن أنفسهم، وأصبحوا لا يتحدثون أبدًا مع عملائهم، مما يعني أنهم يخاطرون ببناء منتج قد لا يريده أو يحتاجه أحد. يمكن أن يؤدي هذا أيضًا إلى انعدام الثقة بين إدارة المنتج والإدارات الأخرى، فقد تظن إدارة المنتج أنهم يقدمون المنتج المناسب (على الرغم من أنهم قد لا يكونون كذلك)، وهنا عندما لا يعمل المنتج جيدًا، يفترضون أن الخطأ يكمن في مكان آخر. تجدر الإشارة هنا إلى أن البرج العاجي فخ، فالعيش فيه بمثابة كناية عن الانغلاق على النفس والعزلة بعيدًا عن الآخرين، لذا حاول البقاء على احتكاك مع عملائك. 4. مبدأ مختبر العلوم: الاعتماد فقط على التحسين واستبعاد كل الحلول الأخرى في مبدأ مختبر العلوم، تميل فرق المنتج إلى تركيز كل جهودها على إجراء تحسينات قابلة للقياس للغاية ولكنها سطحية لنوعية منتجهم، بحيث أنه حتى في حال كانت التحسينات الصغيرة مجتمعةً معًا إلا أنها لا تزيد المنتج ابتكارًا أو تضيف قيمةً للعملاء. بالنسبة للكثير من الشركات، أصبح التحسين هو العنصر الأكثر أهميةً في العمل، بدلًا من أن يكون جزءًا من عملية تطوير منتج متوازنة، والاعتقاد الدارج هو أن إجراء تحسينات على الحلول الحالية هو الشيء الوحيد الذي سيؤدي إلى تحقيق النتائج، ولكن حتى التحسينات الفعالة لا يمكنها أن تحل محل الابتكار الحقيقي، إذ تحتاج أحيانًا إلى حلول جديدة، وليس تحسينات. 5. مبدأ مصنع الميزات: وجود خط تراكمي من الميزات ماذا ينتج مصنع الميزات؟ ميزات! متى ينتهي مصنع الميزات من إنتاج الميزات؟ لن ينتهي إطلاقًا. هذه هي مشكلة كونك مصنعًا للميزات، وهي أن هناك دائمًا ميزة تالية عليك إنشاؤها. تقع فرق المنتج في هذا الفخ لأن العملاء أو أصحاب المصلحة الداخليين يقودونهم إلى الاعتقاد بأنهم لو تمكنوا من تأمين هذه الميزة التالية فقط، فسيضمنون مزيدًا من الصفقات أو على الأقل يحتفظون بالعملاء الذين قد يغادرون بطريقة أخرى. تجدر الإشارة إلى أنه في بعض الأحيان، قد تعمل هذه الطريقة كما يجب، ولكن في الغالب سيجد الفريق أن هناك حاجةً إلى ميزة أخرى، ففي مرحلة ما، عليك كسر هذه الحلقة. 6. مبدأ كلية إدارة الأعمال: الإفراط في استخدام العلوم والبيانات في الواقع، كلية إدارة الأعمال هي المكان الذي تذهب إليه لتحليل الأعمال وليس للقيام بالأعمال التجارية. وبالمثل، يمكن لفرق المنتج الانخراط في التحليل المفرط لكل شيء، بحيث يتجنبون إصدار قرارات صعبة ولكنها ضرورية بنفس الوقت. سيحسب بعض مديري المنتجات بدقة تحليلات عائد الاستثمار لتحديد الميزات التي يجب متابعتها. مع هذا النهج، لن يُتخذ أي قرار بخصوص المنتج على الإطلاق، ومن البديهي أن التحسينات الأقل جهدًا هي التي ستكون في الواجهة. ولاتخاذ قرارات إستراتيجية، يجب أن تضع في حسبانك العملاء واستراتيجية العمل الأكبر، وليس فقط عائد الاستثمار المحسوب رياضيًا. 7. مبدأ اﻷفعوانية: التقلبات والمنعطفات السريعة تُعَبر اﻷفعوانية عن تجربة جامحة مليئة بالانعطافات السريعة والاصطدامات الفجائية. وفي إدارة المنتجات، يحب المستثمرون والمسؤولون التنفيذيون رؤية نتائج فورية، وعندما لا تتحقق هذه النتائج على الفور، يمكن أن يميلوا إلى الانعطاف فجأة؛ مما يؤدي إلى حدوث صدمة مفاجئة. يجب أن تتحلى بالصبر وتترك فرصةً كافية للنجاح، لأنك بخلاف ذلك ستحصل على نتائج سلبية خاطئة، فحتى الميزة التي تُعَد فكرةً جيدةً بالأساس ستفشل، وذلك لأنه لم يكن هناك وقت كافٍ لتنفيذها بأسلوب صحيح. تؤدي هذه السلبيات الكاذبة، والمتسلسلة معًا، إلى ركوب اﻷفعوانية المثيرة للصداع في تطوير المنتج، الذي ينتهي في نفس المكان الذي بدأ فيه تمامًا. 8. الجسر نحو الفراغ: الإفراط في الهندسة بخصوص مستقبل مجهول تخيل لو صمم وبنى فريق من المهندسين جسرًا فوق نهر لربط مدينة بمنطقة برية حيث قد تتواجد مدينة أخرى هناك في يوم من الأيام. بطبيعة الحال، هم يستثمرون قدرًا هائلًا من الوقت والمال والموارد، وبعد ذلك كله، لا تُبنى تلك المدينة أبدًا. هذا ما يحدث مع العديد من فرق المنتجات، فنتيجةً لحماسهم لتطوير البنية التحتية للحصول على المنتج بالطريقة اﻷنسب، يفرّطون بهندسة ذلك المنتج، محاولين مراعاة الاحتياجات المستقبلية التي لا تمد للمنتج بصلة. ركز على الاحتياجات الحالية، ففي المستقبل يمكنك دائمًا التكيف مع المستجدات. 9. طاولة المفاوضات: محاولة إبقاء الجميع سعداء في بعض الأحيان، يمكن أن تتحول اجتماعات المنتج إلى طاولة مفاوضات، حيث يحاول مدير المنتج إعطاء كل شخص ما يريد. غالبًا ما يعتقد مديرو المنتجات أن النجاح يعني إبقاء جميع أصحاب المصلحة سعداء، أو على الأقل التقليل من تعاستهم، ولكن عندما تريد الفرق والأفراد في المنظمة جماعيًا أكثر مما يمكن للهندسة تأمينه، يصبح الأمر مستحيلًا عندها من الناحية العملية. ليس من وظيفتك أن تعطي كل شخص ما يريد، فمهمتك هي إعطاء العملاء ما يريدون؛ وعندما تعطي الأولوية للأشياء المناسبة للعميل، فإنك تساعد كل فريق، سواءً أدركت تلك الفرق ذلك أم لا. 10. قاعة العرش: اتخاذ قرار مزدوج المعايير من قبل الشخص المسؤول في بعض الأحيان، يفقد المؤسس أو الرئيس التنفيذي السيطرة، ويتحول من رئيس تنفيذي إلى ملك أو ملكة في قاعة العرش، إذ يصدرون القرارات وهم بنفسهم يتجاوزونها بشأن أي شيء وكل شيء، وأحيانًا دون تقديم مبرر منطقي. وبسبب ذلك يفشل الرئيس التنفيذي عادةً في توجيه التناسق حول اتجاه المنتج، لأن لا أحد يفهم ما يفعله أو حتى لماذا يفعله. بطبيعة الحال، تُعَد هذه الحالة مستعصيةً بالنسبة لفريق المنتج، فهي تمنع توسيع نطاق الشركة إلى ما هو أبعد من شركة يديرها صانع قرار واحد؛ ففي إدارة المنتج الأكثر فاعلية، يحتاج فريق المنتج إلى صلاحيات تخوله لاتخاذ القرارات الخاصة بهم. ترجمة -وبتصرف- للمقال ‎10 Common Product Management Mistakes that Could be Slowing Your Progress‎‎ لصاحبيه Rajesh Nerlikar و Ben Foster. اقرأ أيضًا ما هي إدارة المنتجات؟ كيف تدخل إلى مجال إدارة المنتجات وتنجح فيه؟ مقارنة بين مدير المنتج ومدير المشروع كيف تتعامل مع دراسات الحالة في مقابلات إدارة المنتجات ست تحديات شائعة للقيادة في إدارة المنتجات كل ما يجب أن تعرفه عن أنواع المنتجات وإدارة تطويرها

سنوضح في هذا المقال من هم أصحاب المصلحة ونقدم أسلوبًا لتصنيفهم، كما سنذكر طرائق اتصال مختلفة لكل نوع منهم، والتي من شأنها أن تجنبك الكثير من الصداع حيال فهمهم. إذا كنت تبحث عن دور في إدارة المنتج، فلابد أنك لاحظت أن مواصفات الوظيفة تدرج دائمًا إدارة أصحاب المصلحة كمهارة إلزامية. يعود ذلك إلى أنه عند العمل كمدير منتج، سيعتمد تأثيرك على قدرتك على التفاوض مع أصحاب المهام الرئيسة في العمل، وتحفيز منظومة التطوير، وإقناع الفرق الإضافية، لكن الخطأ الذي يقع فيه غالبًا مديرو المنتج هو معاملة جميع أصحاب المصلحة بالطريقة نفسها. سوف نشرح كيفية تصنيف أصحاب المصلحة والتعامل معهم وفقًا لذلك التصنيف لتوفير الوقت والجهد. هذه الطريقة ليست مفيدةً فقط لمديري المنتجات بل أيضًا لمديري المشاريع وأي دور يشمل التفاعل مع أصحاب المصلحة. من يكون صاحب المصلحة؟ تتمثل الخطوة الأولى في إدارة أصحاب المصلحة في فهم من هم أصلًا، لذا سنشرح فيما يلي مفهوم أصحاب المصلحة. في دورة إعداد مالك منتج الفريق التآزري (فريق سكرام) ذات المستوى الثاني التي خضع لها ادواردو ميجنوت Eduardo Mignot (كاتب المقال بنسخته الأصلية)، قدم المدرب التعريف الذي أطلقه Paul Stamsnijder. بمعنى آخر، صاحب المصلحة هو أي أحد لديه مصلحة في أعمالك. أصحاب المصلحة هم منظمات أو أفراد يمكن أن تتأثر بمشروعك. صاحب المصلحة هو أي أحد لديه غرض راسخ في مشروعك. حدد أصحاب المصلحة في مؤسستك بمجرد أن تعرف من هو صاحب المصلحة، فقد حان الوقت لتحديد الشخص المناسب لمؤسستك ومشروعك. ابدأ بعصف ذهني لكل الأشخاص المتأثرين بعملك، وابحث عن الأفراد الذين لديهم سلطة على مشروعك. وفي الأخير، ضع قائمةً بالأشخاص الذين تلمسهم نتائج مشروعك، حتى تفهم تحديدهم، وإليك هذا الجدول لتسهيل الأمر. ما يجب البحث عنه في أصحاب المصلحة لديك الآن قائمة بالأشخاص والأدوار، والخطوة التالية الآن هي تقييمهم وفقًا لمجموعة من المعايير. السلطة: ما مدى تأثيرهم داخل مؤسستك؟ العزيمة: هل هم مهتمون حقًا بنجاح مشروعك؟ هل يمكنهم إيقاف مبادرتك؟ الأهداف الشخصية: ما هي أهدافهم الشخصية؟ ما الذي يهمهم فعلًا؟ الاحتياجات: ما هي احتياجاتهم؟ ماذا يريدون وكيف يمكنهم تحقيقه؟ الشخصية: أي نوع من الأشخاص هم؟ المؤثر: من الذي يعجبهم؟ لمن يستمعون؟ من الذي يلهمهم؟ مبدأ التأثير / السلطة بعد أن عددنا أصحاب المصلحة يمكن الآن تصنيفهم وفقًا لمتغيرين: السلطة التي يتمتعون بها في عملك (محور السينات). التأثير الذي يمكنهم ممارسته (محور العينات). ستحصل الآن على أربعة أرباع يمكنك من خلالها تصنيف الأشخاص الذين ذكرتهم في قائمتك: منخفضو التأثير ومنخفضو السلطة: راقبهم بأقل جهد. منخفضو التأثير وذوو سلطة عالية: حافظ على رضاهم. ذوو تأثير كبير وذوو سلطة منخفضة: أبقهم على اطلاع. ذوو تأثير كبير وذوو سلطة العالية: تعامل معهم عن كثب. ذوو الفائدة المنخفضة والسلطة المنخفضة (راقبهم فقط): لست بحاجة إلى تضييع الكثير من الوقت أو الموارد على أصحاب المصلحة هؤلاء. حاول أن تجعل الأمور واضحةً قدر الإمكان من خلال إتاحة لائحة الأعمال المطلوب إنجازها بخصوص المنتج والوثائق للجميع. تأكد من تضمينها في تقاريرك الأسبوعية أو الشهرية ليطلعوا عليها. أعد توجيههم إلى الوثائق قدر الإمكان، فأنت غير مضطر لبذل جهد إضافي لإرضائهم. ذوو الفائدة المنخفضة والسلطة العالية (أبقهم راضين): أبقهم ضمن حساباتك. عليك تقييم رغباتهم وكيف يمكنهم مساعدتك أو تثبيطك في المستقبل. أطمح لجعلهم سعداء بأقل جهد، مع إظهار اهتمامك لآرائهم، كما يمكن أن يكون لهم كلمة في مشروعك. كن حذرًا لأن لديهم سلطةً عالية، وقد يتحولون إلى ذوي فائدة عالية، لذا اجعلهم يشعرون أنهم في موضع تحكم (حتى لو لم يكونوا كذلك حاليًا). ذوو فائدة كبيرة وسلطة منخفضة (أبقهم على اطلاع): أبلغ أصحاب المصلحة هؤلاء باستمرار بمستجدات العمل واستمع إلى اقتراحاتهم، فقد يكونون داعمين لمشروعك ومفيدين للغاية؛ لذا تأكد من أنهم يعلمون بأن آرائهم ونصائحهم مرحب بها، ولكن عليهم أن يعلموا أيضًا أنك أنت المسؤول، وأنت الذي يتخذ القرار النهائي. بالطبع أنت لا تريد تضييع الوقت في شرح جميع خياراتك أو أن تضطر إلى رفض توصياتهم بأسلوب لبق. يمكن تشبيه ذلك بعمل مالك المنتج أثناء عمل فريق سكرام Scrum اليومي، حيث يمكنه الحضور، لكن لا يمكنه المشاركة. راقبهم وهم يكتسبون السلطة حتى يتمكنوا من التأثير في مشروعك. ذوو الفائدة العالية والسلطة العالية (عاملهم عن كثب): أنت بحاجة لتكريس معظم وقتك لهذا النوع من أصحاب المصلحة. نجاح مشاريعك يعتمد كثيرًا عليهم، فهم على الأرجح سيكونون رعاة المشروع أو صناع القرار، بالتالي لديهم أكبر تأثير على منتجك، لذلك عليك التأكد من أنك تتواصل معهم بوضوح وباستمرار وبأسلوب فريد. لن تفيد التقارير النظرية أو العروض التقديمية العامة معهم، فأنت بحاجة إلى مقابلتهم وجهًا لوجه، وأن تجعلهم يحددون وتيرةً واضحةً لاجتماعاتك معهم. وفي بعض الحالات، من الضروري أيضًا تثقيفهم حول دورك كمالك منتج وكيف تحتاج إلى التمكين لاتخاذ القرارات وقول كلمة "لا" عند الضرورة. يحثك مبدأ عمل الطاقة / الفائدة على تقسيم وقتك بدقة في التعامل مع كل نوع من أصحاب المصلحة واستخدام منهجيات اتصال مختلفة. وفي ما يلي، سنرى كيفية تخصيص محتوى رسائلك بحيث يُرسل كل جزء منها للفئة التي يهمها هذا الجزء، وكذلك سبل إيصال تلك الرسائل. كيفية إنشاء خطة تواصل في إدارة أصحاب المصلحة في هذه المرحلة، عليك إنشاء جدول يضم جميع أصحاب المصلحة مع اهتماماتهم وأهدافهم والطريقة التي تتواصل بها مع كل منهم. مضمون الأعمدة ومستوى التفاصيل متروك لك. سنذكر أدناه معايير تصنيف مفيدة بالإضافة إلى أمثلة رائعة مقدمة من سمارت شيت Smartsheet و تيم غانت TeamGantt. إليك في ما يلي بعض المتغيرات لإنشاء خطة الاتصال. التعريف بصاحب المصلحة من يكون: اسم الشخص. الدور: المسمى الوظيفي له/ لها. مستوى الاهتمام: مدى اهتمامهم بمنتجك وفق مقياس تضعه أنت. على سبيل المثال، "صاحب اهتمام منخفض مقابل صاحب اهتمام مرتفع" أو ترتيبهم وفق "1، 2، 3" من منخفض إلى مرتفع الاهتمام. مستوى التأثير: مقدار السلطة التي يمتلكونها في منتجك. حاول استخدام نفس المقياس الذي استخدمته لمستوى الاهتمام. الهدف: ما الهدف الأكثر أهمية لأصحاب المصلحة؟ ما الذي يريدون تحقيقه فعلًا؟ التعريف بطريقة التواصل الكيفية: ما الوسائل التي تستخدمها للتواصل مع صاحب المصلحة. هل يجب أن تكون شخصية وجهًا لوجه؟ هل يمكن أن تكون باستخدام أدوات عبر الإنترنت ومتاحة للجميع؟ هل يتطلب ذلك عقد اجتماع أم يكفي اطلاعه على تقرير إخباري؟ الرسالة: ما نوع المحتوى الذي يجب تضمينه في رسالتك؟ هل يجب تكون حول مؤشرات الأداء الرئيسة في العمل والمقاييس المهمة للإنجاز أم معلومات حول التقدم في المشروع؟ التكرار: عليك أن تقرر عدد مرات إجراء ذلك الاتصال، حيث تُرسل الإشعارات الأكثر فعالية على فترات منتظمة. اعتمادًا على محتوى الرسالة وطولها، يمكن أن يكون ذلك يوميًا، أو أسبوعيًا، أو نصف شهري، أو شهريًا، أو ربع سنوي، أو سنويًا، أو مخصصًا (أي فقط عندما يحدث مستجد). وهنا بمجرد أن يكون لديك تكرار منتظم، عندها يمكنك تأجيل طلبات اللقاءات التخصصية لمواكبة الوضع الراهن. الغرض: تأكد من وجود سبب وجيه لكل لقاء، فبطبيعة الحال أنت لا تريد إرهاق الأشخاص بالتعامل مع الكثير من الإشعارات. التأثير المطلوب: ما الذي تريد تحقيقه بفضل وسيلة الاتصال هذه؟ استخدم هنا الفئات الأربع من مبدأ عمل الفائدة / السلطة. أمثلة ونماذج من TeamGantt و Smartsheet يمكنك أن تنشئ خطة الاتصال الخاصة بك من الصفر، ولكن العديد من مواقع الويب تقدم نماذج قيمة لبناء طريقتك في التواصل. سنقدم مثالين عن ذلك. القوالب نموذج خطة اتصالات TeamGantt (جدول بيانات جوجل Google). نموذج خطة اتصالات SmartSheet (ملف Excel). القوالب اﻷصلية من أصحابها باللغة اﻹنجليزية، لذلك يمكنك اﻻستعانة بمترجم ليعمل على ترجمتها لك. نأمل أن تساعدك هذه المقالة في إدارة أصحاب المصلحة في دورك كمدير للمنتج. ترجمة -وبتصرف- للمقال The Product Manager's Guide To Identifying and Managing Project Stakeholders لصاحبه Eduardo Mignot. اقرأ أيضًا ما هي إدارة المنتجات؟ كيف تدخل إلى مجال إدارة المنتجات وتنجح فيه؟ دليل المبتدئين لمنهجية أجايل Agile تعرف على إطار عمل سكرام scrum أشهر أطر منهجية أجايل من هو مسؤول سكرام Scrum Master وما هي وظيفته؟

يِعَد مصطلح النمذجة الأولية للبرمجيات مشهورًا، ويرتبط بعدد من الخرافات والمفاهيم الخاطئة. ولتصحيحها سيكون الوصف المذكور في هذا المقال للنمذجة الأولية للبرمجيات واضحًا بحيث يزيل أي لبس حول ماهية النمذجة الأولية للبرمجيات. قبل الوصول إلى المنتج النهائي، لا بد من توفير نماذج أولية عالية الدقة يمكنها أن تصور بدقة كيف سيبدو المنتج في النهاية، فبعد إجرائها لبعض التعديلات الصغيرة، تُظهر النماذج الأولية عالية الدقة المشروع بطريقة واضحة ومفيدة للمستخدمين المستقبليين. هناك عيب واحد فقط بخصوص النماذج الأولية عالية الدقة، وهو دورات التطوير الطويلة، والذي يعني نفقات تطوير أكبر. في الخطوة التالية، يجب أن تصنع نماذج أولية منخفضة الدقة والتي تكون مجرد عناصر ثنائية الأبعاد أو مخططات. تبذل النماذج الأولية منخفضة الدقة أفضل ما عندها لوصف الميزات طباعةً على الورق بدلًا من إعادة إنشاء وظيفة البرمجيات، وتهدف هذه النماذج الأولية إلى إظهار كيفية استفادة أصحاب العمل الآخرين من ميزة معينة في التطبيق، وبالتالي مساعدتهم على المشاركة في أهداف المشروع. ومع ذلك، قد يتبع المنتج النهائي أو لا يتبع نفس منطق النموذج الأولي المستند إلى الأسلوب الذي طور به البرنامج. وبصفتك رائد أعمال يدير منتجًا أو نشاطًا تجاريًا جديدًا، يجب أن يكون النموذج الأولي لبرمجياتك ناضجًا بما فيه الكفاية حتى تتمكن من إظهاره للعملاء والمستثمرين المستقبليين. الهدف من استخدام النمذجة الأولية للبرمجيات يمكن أن تستخدم النمذجة الأولية للبرمجيات لطيف واسع من الأهداف، متضمنة: تقييم صنع التطبيقات الجديدة يمكنك استخدام النماذج الأولية للبرمجيات لتقييم تقدم واتجاه التطبيقات التي لا تزال في المراحل الأولى من التطوير. فبدون الحاجة إلى موارد إضافية كبيرة، تستطيع أن تمثل لنا المزايا الإضافية التي سيكتسبها المنتج والاتجاه الذي سيسلكه منتج البرنامج النهائي. عليك استخدام النماذج الأولية في كل خطوة من خطوات تطوير البرامج لمراقبة تقدم مشروعك واتجاهه (مثل مرحلة منتج الحد الأدنى، ومرحلة أول نسخة من المنتج، وما إلى ذلك). مشاركة الطرف الثالث مثل أصحاب المصلحة أو المستثمرين أو العملاء يُطلب من العديد من أصحاب المصلحة والمستثمرين والعملاء المشاركة في بعض مبادرات تطوير البرمجيات، إذ أن الطرف الثالث مفيد، خصوصًا عند استخدام نموذج أولي لطلب الاهتمام حول البرمجيات قيد التقدم. يمكن تعزيز قدرة الشركة على تأمين التمويل الخارجي من خلال مدخلات العملاء وأصحاب المصلحة الآخرين. القدرة على إضافة بعض التعديلات قبل انتهاء المواعيد النهائية للتسليم أو نفاد الموارد أي تعديل يُجرى في اللحظة الأخيرة على مواصفات متطلبات البرمجيات يمكن تقييمه باستخدام النماذج الأولية للبرمجيات أيضًا، فقد أصبح التحقق مما إذا كان من الممكن تلبية الاحتياجات الجديدة قبل المواعيد النهائية أو إنفاق الموارد أسهل باستخدام النماذج. يمكن أيضًا استخدام النماذج الأولية للبرمجيات للتحقق من حالة البرمجيات عند استنفاد جميع الموارد. الأشكال المختلفة للنمذجة الأولية للبرمجيات يمكن تصنيف أشكال النمذجة الأولية للبرمجيات إلى أربعة أنواع: النمذجة الأولية السريعة غالبًا ما يكون النموذج الأولي ضروريًا لدورة حياة تطوير البرمجيات SDLC لمجموعة متنوعة من الأسباب، بغض النظر عن مدى ضآلة تبدلات الشيفرة المصدرية، إذ تُعَد النمذجة الأولية السريعة هي الخيار الأفضل لتلبية احتياجات الاختبار وإظهار التعديلات الصغيرة. إن أكثر ما يشيع استخدام النماذج الأولية السريعة فيه هي تقنية التطوير المرنة Agile، حيث يتم إجراء تعديلات صغيرة وتنفيذها بسرعة خلال كل فترة من عملية التطوير. على نحو متزايد، يصبح من الصعب استخدام النماذج الأولية التي سبق استخدامها من قبل مع تقدم عملية تطوير البرمجيات. تُعرف النماذج الأولية السريعة أيضًا باسم النماذج الأولية المستبعِدة، لأن كل نموذج أولي سابق يصبح غير قابل للتطبيق في موضع التطوير الحالي عند استخدامه بأسلوب مغاير. النمذجة الأولية التطورية في بداية المشروع، قد تكون متطلبات البرمجيات غامضة، وفي نفس قد تتطلب تغييرات متواضعة إلى جوهرية مع تقدم المشروع. تتطلب مثل هذه المواقف إنشاء نماذج أولية تطورية، والتي تضم فقط خصائص معروفة مسبقًا. سيتمكن أصحاب المصلحة من المساعدة في تعريف معايير غير محددة مسبقًا وصقلها بمجرد عرض النموذج الأولي التطوري، فبمجرد دخول متطلبات جديدة، تستخدم النماذج الأولية التطورية نهجًا تفاعليًا لتطبيق الملاحظات الخارجية عليها، وتحدد المتطلبات الجديدة، وتتحقق من توافقها. يمكن مقارنة هذا النهج مع الحد الأدنى من المنتج القابل للاستخدام، ولكن بدلًا من البدء بالوظائف الأساسية فى الحد الأدنى من المنتج، تبدأ عملية التطوير في النماذج التطورية بعناصر محددة بوضوح. النمذجة الأولية المتراكبة نظرًا لأن أنظمة المؤسسة غالبًا ما تكون متحدة وتتطلب عمليات تكامل أساسية، فإن النماذج الأولية المتراكبة هي الأسلوب الوحيد القابل للتطبيق على برمجيات المؤسسة. في هذا النوع من النمذجة الأولية، تُنشأ نماذج أولية صغيرة متعددة لكل ميزة من ميزات الحل الكامل مشاكل البرمجيات التي يواجهها العملاء، ثم تُجمع النماذج الأولية في نموذج أولي كبير واحد يرمز إلى البرنامج الفعلي عندما يتم تطويرها جميعًا. تُعَد حقيقة وجوب مزامنة جميع المطورين والتطوير عامل تمييز مهم في النماذج الأولية المتراكبة، وإن لم يحدث ذلك، فسيبدو كل نموذج أولي أصغر جزءًا من منتج لبرمجيات حاسوب آخر تمامًا، وقد تكون النتيجة النهائية غير متصلة. النمذجة الأولية القصوى في التطوير على شبكة الإنترنت، هناك ثلاث خطوات للنمذجة الأولية القصوى، وأهمها على الإطلاق هي المرحلة الثانية. تُعد طبقة العرض أو واجهة المستخدم وطبقات الخدمة بما فيها الاتصالات ومنطق العمل والترخيص ضروريةً لهذه المستويات. وتتكون النمذجة الأولية المتطرفة من ثلاث مراحل: ابدأ بتجميع بنيان لغة HTML والتي تمثل طبقة العرض. سيؤدي النموذج الأولي وظيفته على أكمل وجه بمجرد ربطه بطبقات الخدمة. يجب أن تُفعّل طبقات الخدمة في هذه المرحلة لإكمال الإنتاج. اختيار النمط المناسب من النمذجة الأولية للبرمجيات على الرغم من المعلومات التي نملكها حول أنماط النماذج الأولية، إلا أنك قد تواجه صعوبةً في تحديد النموذج الأفضل لاحتياجاتك. يمكن أن يستخدم موقع الإنترنت البسيط ذي الأفكار الواضحة نماذج أولية قصوى؛ أما تطبيق برمجيات الأعمال الكبيرة، فيجب أن يستخدم نماذج أولية متراكبة؛ كما يمكن أيضًا استخدام النماذج الأولية السريعة أو التطورية أو القصوى لإنشاء حلول مكتملة بخصوص المشروع، فحتى لو كان مشروع تطوير البرمجيات واسعًا ومعقدًا، يمكن للنماذج الأولية المتراكبة جعل الأمور قابلة للإدارة. هناك نهج مختلف يتمثل في استخدام النمذجة الأولية الذكية وذلك عند العمل بمنهجية مرنة Agile، والتي تقسم عملية تطوير البرمجيات إلى عدة فترات زمنية. يكون استخدام النمذجة الأولية التطورية مفيدًا فقط عندما تكون متطلبات البرمجيات غير واضحة أو على الأقل غير واضحة بما فيه الكفاية. هل يجب إجراء بعض الاختبارات بعد الانتهاء من تكوين الواجهة؟ أنشئ مجموعةً متنوعةً من طرائق العرض للواجهة عند إعدادها، إذ يجب إطلاع جميع أصحاب المصلحة على الميزات والوظائف الجديدة لضمان أن المشروع يسير على المسار الصحيح، فلا بد من فحص نموذجك الأولي من قبل المستخدمين الفعليين الذين قد يشيرون إلى الميزات الناقصة ويساعدونك في تحسينها. وللعلم، قد تكون تكلفة ووقت جمع آراء العملاء الذين استخدموا المنتجات في بداية إطلاقها أمرًا باهظًا في حالة النماذج الأولية المتراكبة، لذلك قد تميل لتخطي جمعها كليًا. التعديلات التي أُجريت بناء على ملاحظات أصحاب المصلحة والمختبرين يجب إنشاء النماذج الأولية التي تعرض بدقة وظيفة التطبيق المستهدفة من خلال تطبيق ما تعلمته من أصحاب المصلحة والمختبرين. ولتلبية مطالب العامة وتطوير المنتج، يجب أن يكون النموذج الأولي النهائي سليمًا فعالًا أيضًا. الخلاصة يمكن لرائد الأعمال في أي مستوى أن يصنع نموذجًا أوليًا للبرمجيات لإظهار أو اختبار كيفية عمل النسخة المثالية للمنتج في الحياة الواقعية. لإرضاء المستثمرين وتسريع وقت التسويق، يمكن للنماذج الأولية أيضًا توضيح الوظيفة الفعلية للبرمجيات، والتي يمكن أن تساعد في تسريع عملية التطوير. يُعَد العثور على النموذج الأولي الصحيح لمشروعك أمرًا بالغ الأهمية. وتشمل الخيارات الأخرى لرواد الأعمال وأصحاب الأعمال الحد الأدنى من المنتجات القابلة للتطبيق وإثبات المفهوم (وهو إدراك فكرة ما لمعرفة الجدوى منها لتقدير إمكانية تطبيقها وتنفيذها). قد يُعد اللجوء لشركات تطوير النمذجة الأولية للبرمجيات التي تنشئ أيضًا حدودًا دنيا من المنتج وإثباتات مفاهيم خيارًا لتوفير التكاليف الإجمالية. ترجمة -وبتصرف- للمقال How to Test Product-market Fit Using Software Prototypes لصاحبه Aelius Venture. اقرأ أيضًا الفوائد العملية لبناء النماذج الأولية مدخل إلى تطوير البرمجيات Software Development تطوير منتج جديد خطوة بخطوة كل ما يجب أن تعرفه عن أنواع المنتجات وإدارة تطويرها دليلك الشامل إلى دورة حياة المنتج

الوظائف الرئيسة الثلاثة في فريق تطوير البرمجيات هي التطوير والاختبار والتشغيل، بحيث يُعاد ابتكار المهام المطلوبة بين هذه الوظائف باستمرار. لتسريع عملية التطوير، دُمج التطوير مع التشغيل، والذي يُشار إليه الآن باسم التطوير والتشغيل DevOps؛ ولكن لسوء الحظ، أُهمل أمر مهم يقع بين كل من التطوير والتشغيل، وهو إجراء الاختبار الدائم. لضمان التنقل السريع وتحسين الكفاءة العامة للعمل والحفاظ على الحالة المستمرة للاختبار في دورة التطوير والتشغيل DevOps، طورت منهجية جديدة وهي: التطوير والاختبار والتشغيل DevTestOps وهي ما سنركز عليه في مقالنا هذا. ما المقصود بالتطوير والاختبار والتشغيل DevTestOps؟ إن مضمون التطوير والاختبار والتشغيل DevTestOps هو مزيج من التطوير والتشغيل DevOps والاختبار المستمر. يُعَد كل من الاختبار المبكر والاختبار المنتظم والاختبار عبر خطوط العمل Pipelines طرائق مستخدمة خلال عملية اختبار البرنامج. ووفقًا لمبدأ التطوير والاختبار والتشغيل DevTestOps، يجب تضمين خطوط العمل التكامل المستمر والنشر المستمر في بنية الاختبار المستمر. يقدم هذا الإجراء نتائج اختبار مستمرة للمطورين خلال مراحل تطوير المنتج، ويجنب الخوض بمجازفات في العمل واكتشاف العيوب بوقت متأخر؛ وبالتالي يساعد استخدام مبدأ التطوير والاختبار والتشغيل DevTestOps عبر مراحل تطوير المنتج في التخفيف من مخاطر الأعمال وتقليل فرصة ظهور الأخطاء في مراحل لاحقة. التطوير والاختبار والتشغيل DevTestOps كرؤية جديدة لمنهجية أجايل Agile أدت تقنية التطوير والاختبار والتشغيل DevTestOps رسميًا إلى حقبة جديدة من التطوير، مما أدى إلى تغيير طريقة إجراء الاختبار، والذي كان لا يُجرى إلا بعد اكتمال التشفير بصورة نهائية. التنسيق بين التطوير والاختبار والتشغيل DevTestOps أحدَث الاختبار المستمر ثورةً في السوق لأنه يساعد على تقديم تقييم مبكر للمنتج ويسمح بالكشف المبكر عن المشاكل، مما يساعد في النهاية على تقليل التكاليف المرتبطة بإصلاح المشكلات بعد وقوعها. وفي دورة حياة تطوير البرمجيات SDLC النموذجية، يُجرى الاختبار في نهاية دورة التطوير عند اكتمال المنتج بأكمله، فيحدث بسبب ذلك تأخير زمني نتيجة اكتشاف الأخطاء وإصلاحها. وللتأكيد، يُعَد الكشف عن ثغرات أمنية جديدة أصعب بكثير من الثغرات العادية ويستغرق وقتًا أطول وتكلفة أكثر، خصوصًا إذا أضفنا للحساب التشفير الجديد الذي أُدخل ضمن العمل مسبقًا. ومع ذلك، بدأت العديد من الشركات مؤخرًا فيما يعرف بالتحول لليسار shift-left (وهو أسلوب تتبعه الشركات بإجراء بعض العمليات في مراحل مبكرة والتي كانت تُجرى في مراحل متأخرة تقليديًا)، واختبرت تطوير البرمجيات في وقت مبكر جدًا من العملية. يؤكد خبراء الاختبار وضمان الجودة أنه يجب تضمين الاختبار في كل نقاش ومناظرة، بدءًا من تطوير فهم مشترك للمزايا الجديدة، مرورًا بتخطيط خط عمل التسليم pipeline delivery، وصولًا إلى مراقبة استخدام المنتج. يُعد إجراء الاختبار في أقرب وقت ممكن في الفرق المرنة Agile أمرًا بالغ الأهمية للانتقال إلى مسار العمل السريع، ويتطلب إنجاز ذلك نهج التطوير والاختبار والتشغيل DevTestOps. الانتقال من نهج تطوير واختبار وتشغيل متلكئ إلى نهج سريع - سرع مرونتك Agility في العمل تقدم Spotify مثالًا واقعيًا يعرض ما يشبه تنفيذ نهج التطوير والاختبار والتشغيل DevTestOps الفعال كمحاولة لتوسيع نطاق عمل فريق أجايل Agile. ومع ما يقدر بنحو 286 مليار مستخدم، فإن Spotify هي أكبر وأشهر خدمة بث صوتي في العالم؛ وأحد العوامل المساهمة في نجاح Spotify هو نهجها الفريد في زيادة سرعة الفريق، وبالتحديد نهج التطوير والاختبار والتشغيل DevTestOps. يؤكد نموذج Spotify الحالي والذي يقدم الخدمات للناس فعلًا على أهمية وجود شبكة داخلية واتصالات ضمن العمل، والأهم من ذلك، أن مسؤولية الجودة تتحملها جميع الفرق بمن فيهم فرق التطوير والاختبار والتشغيل. ومع وجود الاختبار في جميع مراحل دورة التطوير والاختبار والتشغيل DevTestOps كعملية لا بد منها في جميع الأقسام، فإن أعضاء فريق Spotify مسؤولون بتساوٍ عن كفاءة المنتج النهائي. في نموذج Spotify، يضيف المطورون ميزات جديدة للمنتج باستمرار، مثل إضافة قوائم تشغيل جديدة يُعتقد أن العملاء سيحبونها، أو إدخال أسلوب جديد للتنقل بين الأغاني مثلًا. يساعد دمج أدوات التكامل المستمر خلال سير العمل على اختبار الإضافات الجديدة بسهولة ويقلل من الإضافات الخاطئة. ونتيجةً لذلك، إذا فشل الاختبار، عندها يمكن للمطورين تغيير العناصر الموجودة في طور الإنشاء مباشرةً قبل أن ينتقلوا إلى طور النشر. يعزز هذا الإجراء ثقة المطورين من خلال تقليل احتمالات إعادة إجراء الاختبار بأكمله، حيث تُصلح العيوب بمرحلة أبكر. علاوةً على ذلك، يُجري خبراء ضمان الجودة والمختبرون اختبارات، ويصممون سيناريوهات اختبار لاكتشاف أي خطأ يجب معالجته، مثل زر غير قابل للنقر على موقع الويب، أو إذا توقفت الموسيقى عن العمل فجأة. ومع إصلاح أخطاء التشفير الرئيسة في المرحلة السابقة، يمكن الآن لخبراء ضمان الجودة التركيز على أجزاء أخرى من التشفير والمعزولة بطبعها وذات تعقيد داخلي خاص بها. بالإضافة إلى ذلك، من خلال الاختبار المستمر، يمكن لعمليات ضمان الجودة مراقبة حجم أكبر من البيانات والتعامل معها، وذلك بفضل استخراج البيانات آليًا من السجلات، حيث تُحلل ملفات سجل إنشاء التكامل المستمر تلقائيًا لتقديم ملاحظات سريعة ودقيقة، بما فيها طلبات التطبيق ورسائل الخطأ. فكر في الاختبار المستمر كعادة جيدة في روتينك اليومي. فكما أن شرب كمية كافية من الماء يوميًا تجعل صحتك أفضل، فإن الاختبار المستمر يجعل سير عملك أكثر مرونة، وذلك لأنه يعمل على اكتشاف الأخطاء روتينيًا، وبالتالي يؤدي إلى تطوير أسرع للمنتج وتزويد المطورين والمشغلين بالبيانات المحدثة. تضمن إضافة الاختبار المستمر في دورة التطوير والتشغيل DevOps (أو التطوير والاختبار والتشغيل DevTestOps) أن البنية التحتية والمنصات وأطر العمل المناسبة للاختبار متوفرة ومجهزة قبل بدء الاختبار. فوائد الاختبار المستمر سنذكر فيما يلي بعض فوائد الاختبار المستمر، والتي تتمثل في: اكتشاف العيوب بوقت مبكر، وبالتالي يمكن تصحيحها وتسليمها بسهولة. تقصير دورة الانحدار تلقائيًا من أسابيع إلى ساعات (والمقصود بالانحدار هو التأكد من أن التغيير الذي أُضيف بعد إجراء الاختبار قد تمكن فعلًا من إحداث الفارق، فإن لم يفعل فتسمى الحالة انحدارًا). يعمل المطورون والمختبرون معًا بأسلوب أكثر انتظامًا لتحسين جودة المنتج. يُجنب البناء والنشر التلقائيان الاعتماد على البشر وأخطائهم. ومع ذلك، فإن تبني مبدأ التطوير والاختبار والتشغيل DevTestOps على أكمل وجه ليس بالمهمة السهلة. يحتاج المطورون إلى التكيف مع طريقة عمل جديدة، والتي يكون فيها اختبار الشيفرة البرمجية من مسؤوليتهم أيضًا، كما يكون خبراء ضمان الجودة والمختبرون أكثر انخراطًا في العمل لتقديم خبرتهم، مما يساعد الفرق على إنشاء الاختبارات المناسبة ويجعل العملية أكثر كفاءة. يجب أن يتأكد فريق العمليات الآن من عدم وجود حالات عدم تطابق بين عملية التطوير وبيئات باقي مراحل العمل. لبدء التطوير والاختبار والتشغيل DevTestOps، كما يجب أن يكون كل أفراد الفريق في حالة من التفاهم وأن يستوعبوا أن الاختبار يجري خلال سير العمل بأكمله وليس فقط في مراحل معينة، وأن يدركوا لماذا عليهم الاستثمار أصلًا في تنسيق التطوير والتشغيل DevOps، وذلك عبر أدوات مثل Katalon. مع ذلك، من المهم الأخذ بالحسبان أنه على الرغم من أنه قد يوجد حل رائع لشركة ما، إلا أن هذا لا يعني أن يكون مناسبًا لمؤسستك. ترجمة -وبتصرف- للمقال How to Make DevTestOps Orchestration for Agile Teams Work. اقرأ أيضًا ما هي إدارة المنتجات؟ دليل المبتدئين لمنهجية أجايل Agile دليلك إلى أشهر أطر عمل منهجية أجايل أهمية التخطيط لدورات التطوير في منهجية أجايل المراسم الأربعة لمنهجية أجايل Agile ceremonies

لفريق سكرام Scrum Team المقدرة على إنجاز أي مهمة خلال أسبوع إلى شهر إذا ما أُخذت المدة التي من المقرر إنجاز العمل بها والأسس المشتملة به بالحسبان؛ ولكن في الواقع ليس هذا أفضل ما يمكن أن يفعله الفريق سكرام، فالهدف من عمل الفريق (الفريق سكرام) هو تقديم خدمة سريعة ومتزايدة للمستخدمين النهائيين، وبالتالي من الخطأ وضع خطة ذات أمد طويل لينجز بها الفريق ذلك العمل، إذ بمجرد التركيز على ما هو مهم فعلًا ومعرفة كيفية التعامل مع المستجدات يمكن النهوض بالفريق إلى حد يمكنه من إنجاز عمله خلال 48 ساعة فقط. إليك في ما يلي كيفية تحقيق ذلك: اليوم الأول مهام اليوم الأول: ضع رؤية للعمل. حضر أدوات العمل. ضع قائمةً بالأعمال المطلوب إنجازها. تطوير قائمة الأعمال وإدخال تعديلات عليها. الجلسة الأولى: وضع رؤية للعمل أهم نقطة بالنسبة للفريق هي تحديد سبب وجوده أولًا، ولتحقيق ذلك لا بد من فهم مشكلة العمل التي تحاول الشركة حلها. فلماذا أُنشئ الفريق أساسًا؟ وما هي معايير النجاح لنقول بأن الفريق قام بعمل جيد أصلًا؟ تأكد من مشاركة الفريق بأكمله في مهمة هذه الجلسة ليكون الفهم مشتركًا. باختصار: ستحتاج إلى بيان يلخص سبب وجود الفريق، مع معايير لقياس نجاحه. الجلسة الثانية: تحضير أدوات العمل إن العمل كفريق يعني وجود فهم مشترك لما يفعله كل شخص. تُعد البرمجيات المشتملة بإدارة المشروع السبيل لذلك، حيث يمكن اﻻعتماد على تطبيقات وبرمجيات مثل منصة أنا وجيرا JIRA وآزوري Azure board وجيت هب Github. تأكد من أن تلك الأدوات تحت تصرف الجميع في المشروع، كما يمكن استخدام اللوحات التمثيلية كانبان Kanban boards التي تمثل بصريًا وترتب مهام العمل أمام الأشخاص، بحيث تسهل فهم سير العمل للجميع. خذ وقتًا كافيًا لإجراء بعض التدريبات الذي لا بد منها حتى يتمكن الجميع من التنقل بين مهام المشروع وفهم كيفية سير العمل. باختصار: يجب وضع عمل مشترك لمراقبة إنجاز المهام وتنظيمها، مع أعمدة لوحات كانبان Kanban متفق عليها مسبقًا تؤمن فهمًا شموليًا للعمل، والتأكد بأن الجميع مخول للمشاركة في المشروع. الجلسة الثالثة: وضع قائمة بالأعمال المطلوب إنجازها حان الوقت الآن لتدوين كل المهام التي يعتقد الفريق أنه بحاجة لإنجازها ضمن لائحة تحوي خانات تُكتب عليها المهام. في بادئ الأمر، لا تكترث للتفاصيل. اكتب كل ما يعتقد الأشخاص أن فعله ضروري، أو ما يعمل عليه الفريق الآن إذا كان الفريق قيد العمل أساسًا. المبدأ الأساسي هنا هو الشفافية بين جميع الأفراد بشأن الوضع الحالي للعمل. تجنب ملء الخانات بالتفاصيل، فسيحدث ذلك بمرور الوقت. سيتم العمل عليها بالتدريج، لذلك لا تضيع الوقت بالخوض فيها بالبداية. حاول أن تصف المشكلة بأسلوب جيد، وأنشئ خانة تعريفية تحوي سطرين من الوصف بحيث تكون مرشدة لفهم باقي الخانات. باختصار: لا بد من امتلاك قائمة تضم كل الأعمال المطلوب إنجازها كأداة من أدواتك في مراقبة سير العمل. الجلسة الرابعة: تعديل قائمة الأعمال المطلوب إنجازها بعد أن حددتم جميعًا عناصر قائمة المهام المطلوبة، عليكم الآن مناقشة أولوية إنجازها، ويكون ذلك إما من حيث أولوية العمل، أو الترتيب المنطقي للإنجاز. مر مجددًا على الخانات الأكثر أهمية، واحرص على وضعها أعلى القائمة، ثم ابدأ بتفصيلها. ركز على جمع معايير قبول العمل من باقي الأفراد، وكذلك وصف المعلومات المطلوبة حتى تتمكن من بدء العمل في المهمة. احرص على جمع الأسئلة بدلًا من محاولة الإجابة عليها في الجلسة. وللتذكير مجددًا، عليك التعامل مع الأمور الغامضة بهدوء، إذ من المحتمل أن تكون هناك الكثير من الأشياء المجهولة في هذه المرحلة. باختصار: يجب تحديد أولوية إنجاز المهام في القائمة، مع معايير القبول و والحصول على معلومات إضافية. اليوم الثاني مهام اليوم الثاني: إنشاء ورشة لتوزيع مهام العمل. *وضع خطة عمل لفترة زمنية معينة. تبيان متى يمكن القول أن المهمة قد أُنجزت. الجلسة الخامسة: إنشاء ورشة لتوزيع مهام العمل بعد قضاء ليلة من النوم الهنيء واحتساء فنجان مركز من القهوة، فإن هدف ورشة العمل الأولى لليوم الثاني هو: كيفية تحويل الفكرة إلى إنتاج؟ قد يكون هذا بديهيًا جدًا بالنسبة الفريق، ولكن غالبًا ما تكون هناك ثغرات في فهم العملية وتقبلها. وضّح ذلك مبكرًا لتجنب تلكّؤ عمل الفريق لاحقًا. وإذا كانت هناك إجراءات يلزم اتخاذها لإعداد التكامل المستمر أو عملية توزيع الأفراد على العمل، فأضفها إلى قائمة المهام. باختصار: يجب التوصل إلى مخطط بياني لسير عملية تحويل الأفكار إلى إنتاج، مع لفت الانتباه للفجوات الحالية. الجلسة السادسة: وضع خطة عمل لفترة زمنية معينة حان الوقت لوضع أول خطة زمنية لعملك. تُعد إجراءات تخطيط فترات العمل الزمنية أمرًا بالغ الأهمية، لذا ضع هدفًا لتحقيقه خلال هذه الفترة؛ يعني ما الذي نريد تحقيقه فعلًا بنهاية الفترة الأولى بما يخص قيمة العمل؟ بمجرد الإجماع على ذلك الهدف، راجع بنود لائحة المهام بما يسهم في تحقيق الهدف، وانتقِ المهام بناء عليه. سيساعدك ترتيب الأولويات الذي قمت به البارحة في المجموعة الأولى من المهام في ذلك حتمًا، لذا حدد مع الفريق مقدار ما يمكنك إنجازه في الفترة الأولى، ثم اتفق مع الفريق على خطة أولية حول ما سيقوم به كل عنصر في الفريق. باختصار: ستحتاج إلى تحديد الهدف المراد تحقيقه خلال فترة من الزمن واستخدام لائحة المهام بما يوافق تلك الفترة، وإحداث انسجام بين ما سيعمل عليه الجميع في البداية. الجلسة السابعة: تبيان متى يمكن القول بأن المهمة قد أُنجزت بعد أن وضعت خطةً زمنيةً للعمل، قد تظن الآن أنك جاهز للمضي قدمًا في إكمال العمل، ولكن في الواقع الأمر لم ينته بعد! إذ ستفشل خطتك بسرعة ما لم يكن هناك تعريف مشترك لمفهوم الإنجاز في العمل. يشمل مفهوم الإنجاز عمومًا ما نعنيه عند نقل المهمة من خانتها كمهمة مطلوب إنجازها إلى خانة الإنجاز ضمن اللائحة وفقًا لمعايير الإنجاز المتفق عليها مسبقًا، وبالتالي بدلًا من الاهتمام المبالغ به بملء خانة المهام المنجزة، يجب التركيز على امتلاك أسلوب قوي لفحص جودة المهام قبل نقلها إلى خانة الإنجاز، وتكوين فهم مشترك حيالها. باختصار: من الضروري جدًا امتلاك قائمة بالمعايير التي يجب أن تفي بها كل مهمة لنقول أنها قد أُنجزت. بعد هذين اليومين الشاقين، يجب أن يكون الفريق مستعدًا لامتلاك رؤية في العمل، وهدفٍ عليهم تحقيقه خلال فترة زمنية، ولائحة مهام عليهم إنجازها؛ مع فهم لكيفية توزيع تلك المهام على الأفراد، وتحديد مفهوم مشترك للإنجاز. والآن، يمكن للخطط الزمنية أن تنطلق وتتقدم، مع مراعاة مراقبتها وتقييمها يوميًا. إن أحد نقاط القوة الرئيسة في الفريق سكرام هو الفحص المستمر لسير العمل والتكيف مع المستجدات، فهذا أمر بالغ الأهمية، نظرًا لمبدأ عمل الفريق سكرام ذي الطابع السريع. تأكد بأن العملية تسير بكفاءة في بدايتها، ثم دعِ الفريق يتحسن بمرور الوقت، ولا بأس بالتكرار وإعادة المحاولة بعد اكتشاف الأخطاء أفضل من محاولة وضع خطة مثالية تبدأ بها المشروع. ترجمة -وبتصرف- للمقال Hacking the Set Up of Your Scrum Team to Start Delivering Within 48 hours لصاحبه Edward Lowe. اقرأ أيضًا تعرف على إطار عمل سكرام scrum أشهر أطر منهجية أجايل من هو مسؤول سكرام Scrum Master وما هي وظيفته؟ دليلك إلى أشهر أطر عمل منهجية أجايل المراسم الأربعة لمنهجية أجايل Agile ceremonies

يعلم الجميع أن على المشاريع العمل بسرعة، وهذا جزء مما يميزها غالبًا عن الشركات الأكثر تقليدًا والأكبر حجمًا؛ ولكن ما معنى أن تعمل المشاريع بسرعة أساسًا؟ ولِمَ يُعد أمرًا بتلك الأهمية؟ للإجابة عن هذا السؤال علينا تفصيل مفهوم السرعة إلى معانيه المتنوعة والتعامل مع كل معنى بصورة مختلفة، وكذلك دراستها بصورة شمولية حيث تتلاقى جميع المعاني مع بعضها. إليك في ما يلي التحليل المفصل لأنواع السرعة المطلوبة، بالإضافة لنصائح حول كيفية تنمية كل نوع. كجزء من العمل الذي قُمت به في كتابي "قيادة المنتج Product Leadership"، أجريت مقابلات مع مديري منتجات يعملون ضمن شركات ناجحة، ولا سيما أولئك الذين كانوا متواجدين في المشروع منذ انطلاقه، بحيث يمكنهم سرد القصة الكاملة بخصوص المنتج والشركة (نظرًا لعدم إمكانية نجاح منتج منذ يومه الأول). ذكر عدد من الأشخاص في تلك المقابلات مدى أهمية السرعة في نجاحهم، فقد سمعت أقوالًا مثل "بعد أن عرفنا ما يجب علينا فعله، كنا بحاجة لفعله بسرعة"، أو "كانت السرعة أحد قيمنا الجوهرية". من جهة، قد يبدو الأمر بسيطًا وسطحيًا، فالكل يعلم أن على المشروع العمل بسرعة، إلا أنني أردت التعمق أكثر بذلك المعنى وطرحت السؤال التالي: لماذا تُعد السرعة بتلك الأهمية أساسًا؟ وللإجابة عن هذا السؤال علينا أولًا أن نفهم ما يعنيه الناس حقًا بقولهم كلمة "سرعة Speed" فأنواع السرعة ليست كلها متشابهة. سنذكر في ما يلي 4 أنواع من السرعة تُعد كل منها بحد ذاتها ضروريةً لعمل المشروع. سرعة إدراك الأمور تكمن فكرة المرونة والرشاقة Lean and Agile بأنه من غير الممكن أن تعرف كل شيء نظريًا من الورق فقط، بل يجب عليك الاحتكاك مع السوق لفهم ما يجري فعليًا. وبصراحة، لم يسبق لي أن آمنت بهذه الفكرة إلى هذا الحد من قبل، فقد صادفت ذلك مرات عديدة. هناك الكثير من الأشياء التي تكتشفها عند وضع الأفكار النظرية قيد التطبيق والتنفيذ، فهنا مربط الفرس. فقد تكون افتراضاتك خاطئة، أو على الأقل ليست دقيقة %100. قد تظهر عقبات جديدة لم تتوقعها عليك مواجهتها، والتعامل مع تقلبات السوق والمنافسة من نواحٍ لم تفكر بها. كل ذلك موجود في السوق والعمل مع عملائك الحاليين أو المستقبليين، فلم يسبق لك التفكير ببعض الأفكار الطارئة من الخارج أو التي تجول بذهن باقي الأشخاص وفهمها من قبل. ولتعمل بسرعة كبيرة، عليك توقع تلك الأفكار بأسرع وقت ممكن، وليس بعد أن تُعرض عليك. وللقيام بذلك، تأكد من فهم الافتراضات والعودة إليها بانتظام (شهريًا على الأقل للافتراضات التخطيطية) لمعرفة ما إذا كانت لا تزال قائمة. لاحظ أنها في كثير من الأحيان لا تكون على خطأ، ولكنهم ليسوا دقيقين كليًا أيضًا، فالدقة مهمة هنا، خاصةً عندما تكون في نواحٍ أساسية، مثل عرض قيمة المنتج وكيفية فهم العملاء وتعاملهم مع المشكلات الواجب حلها. سرعة اتخاذ القرار عند تعرضك لمستجد من السوق، عليك أن تقرر ما ستفعل حياله، وهذا يستغرق وقتًا أيضًا. تتخذ بعض الشركات القرارات أسرع من غيرها، فضمن عالم مليء بالأمور الغامضة (وهذه تقريبًا طبيعة كل قرار تحتاج إلى اتخاذه بخصوص المنتج) يمكن أن يستغرق التخلص من الغموض وقتًا طويلًا، وعادةً لا يختفي هذا الغموض كليًا، وإنما يمكن تقليله فقط. يجب عليك الموازنة بين اتخاذ القرار الصحيح، ودعمه بالبيانات، والعمل بسرعة كافية، بحيث لا تدفعك السرعة بالعمل لاتخاذ قرارات خاطئة. المفتاح لاتخاذ قرارات أسرع هو أن تتذكر أن عدم اتخاذ القرار له تكلفته أيضًا. غالبًا ما يبدو أن التأخر في اتخاذ القرار ليس له تبعات، إلا أنه نادرًا ما يكون كذلك. لاحظ بأن هذا لا يعني اتخاذ القرار دون انتظار أي شيء وأي شخص، ففي كثير من الحالات هناك حاجة فعلية للبحث المركز والتحليل العميق. الفكرة هنا هي أن تفهم أنك تدير المخاطر باستمرار، وأن المخاطرة تكمن في جانبي المعادلة: هناك مخاطرة في اتخاذ القرار بسرعة كبيرة، وهناك مخاطرة في اتخاذ القرار ببطء شديد. عندما ترى الأمر على هذا النحو، سيكون من الأسهل بكثير العثور على ما هو مهم فعلًا بعيدًا عن المعلومات الهامشية التي لا تستحق أن تتأخر من أجلها في اتخاذ القرار، والتي ستُكتسَب من خلال البحث الإضافي. تقرر بعض الشركات أن يُتخذ القرار بالإجماع فقط. يُعد هذا الإجراء سيئًا عمومًا، ولكن لا يوجد الكثير مما يمكنك فعله حيال ذلك كفرد. ستكون بدايةً جيدةً لو اعتمد تداول القرارات على لغة إدارة المخاطر، فإذا أُنجز هذا على نحو صحيح، فستتمكن من إشراك الجميع في القرار، ولكن عليك إقناع الناس أنه ليس من الصواب تأخير اتخاذ القرار حتى لو لم يقتنعوا بالقرار بحد ذاته؛ إذ عادةً ما يكون هناك من لا يوافق على تفصيل معين من ذلك القرار، وفي حال تمكنت من إنشاء الآليات المناسبة للتعامل مع المخاطر في حال كان القرار خاطئًا، فسيكون من السهل جدًا على الأشخاص الموافقة على المضي قدمًا في القرار. السرعة بتأمين المنتج هذا غالبًا التفسير الأكثر شيوعًا للسرعة لأنه ببساطة الأسهل من حيث الرؤية والقياس، فهو النمط الأكثر واقعيةً للسرعة وعادةً أثقل جزء من العملية، لذا فالتركيز على تحسينه سيؤدي إلى نتائج رائعة. عندما تفكر بمعنى سرعة تأمين المنتج، أحثك لتخطي مفهوم السرعة السطحي الذي يعمل وفقه قسم البحث والتطوير لتأمين برمجيات عالية النوعية. فبالرغم من أنها تعمل جيدًا، إلا أنني أريد أخذك إلى مستوى أعلى: كم السرعة التي يمكنك تأمين المنتج خلالها؟ طبعًا حتى تفعل ذلك عليك أن تبرع بأنواع السرعة الأخرى التي سبق ذكرها. عليك تأمين منتجك بسرعة في السوق، بحيث تتلقى الآراء حوله بسرعة ومن ثمة اتخاذ القرارات بسرعة وتأمين النسخة التالية من المنتج تباعًا بأسرع وقت ممكن لتقييمها مجددًا وإعادة ضبطها. يمكنك تحسين كل نوع من أنواع السرعة تلك بصورة منفصلة، ولكن إذا ركزت على سرعة تأمين المنتج المناسب، فهناك أشياء أخرى يمكنك فعلها أيضًا: فالمفاضلات بين نطاق العمل والسرعة يمكن أن تنجز بصورة مختلفة إذا فهمت أن هدفك الآن هو التعلم، وليس البيع، على سبيل المثال، كلما فهمت ما هو الهدف من كل ما تفعله، زادت الطرق التي يجب أن تتأكد من خلالها بأن هدفك سليم بينما يجري التعامل مع القيود الأخرى أيضًا. هذا أحد المواضيع التي سيخضع لها المشاركون في برنامج تدريب رؤساء أقسام المشتريات القادم، لأنه أساسي لقيادة منتج رائعة وناجحة. سرعة التأثير هذا هو النوع الأكثر تعقيدًا للسرعة، لكنه ربما الأكثر أهمية. تركز جميع أنواع السرعة المذكورة أعلاه على مدى السرعة التي تعمل بها وعلى الجهد الذي تبذله، بينما يركز هذا النوع على تأثيرك، أو مدى السرعة التي يمكنك بها تحقيق النتائج. وأعني بالنتائج هنا الأعمال أولًا وقبل كل شيء، على الرغم من أن وجهة النظر هذه يمكن تطبيقها على أنواع أخرى من النتائج أيضًا. يمكن رؤية سرعة التأثير في طول دورة المبيعات (وهي متوسط عدد الأيام التي تحتاجها الشركة لجمع الإيرادات بعد إجراء عملية البيع)، ومدى ضخامة مسار التحويل الخاص بك وصحته، ومدى سرعة نمو الأعمال بنهاية المطاف. إذا فكرت في كيفية تقييم سوق الأوراق المالية للشركات، فدائمًا ما يرجع ذلك إلى النمو المستدام. الأمر نفسه ينطبق على دورات التمويل، فالمستثمرون الرأسماليون ينظرون إلى عائداتك، وكذلك الوقت الذي استغرقته للحصول عليها. وبقدر أهمية نمو الإيرادات، لاحظ أنه من الخطير جدًا البدء في التركيز على سرعة التأثير في وقت قريب جدًا. إذا كنت لا تزال في مرحلة الاكتشاف لمعرفة المنتج المناسب الذي يريده عملاؤك فعلًا وعلى استعداد لدفع ثمنه (قبل أن يكون لديك منتج مناسب للسوق)، فيجب أن تمكّن نفسك من أنواع السرعة للتماشي مع السوق بسرعة وتعلم كل ما أمكن تعلمه. وفيما يتعلق بالتأثير في هذه المرحلة، يجب أن تعمل عن كثب مع عملائك وتتأكد من تحقيق التأثير الأولي (عدد من العملاء الراضين، وإيجاد حلول مناسبة للمشكلات). وبمجرد أن تحصل على عملاء سعداء يدفعون ثمن المنتج، وإثبات أنه يمكنك فعل ذلك باستمرار وبصورة متكررة، فقد حان الوقت لزيادة سرعة التأثير. وهنا تجدر الإشارة إلى أن القيام بذلك مبكرًا سيضر في الواقع قدرتك على إحداث تأثير أكبر لأنك ستعمل في العديد من الاتجاهات في وقت واحد. لزيادة سرعة التأثير، هناك شيئان يمكنك فعلهما: الأول هو أن يكون لديك خطة واضحة للمنتج تبين بصورة جلية القيمة الفريدة لمنتجك وجدوى الأعمال. يُعد هذا مهمًا ليس فقط لتطوير المنتجات بل أيضًا للتسويق، ولتكون المبيعات قادرةً على جذب العديد من العملاء، وهذا أحد الأشياء التي سيتعلمها المشاركون في برنامج تدريب رؤساء أقسام المشتريات القادم. الشيء الثاني الذي يمكنك فعله لزيادة سرعة التأثير هو البدء بالتفكير في تأمين أعداد أكبر من المنتج والذي بدوره سيقودك لاكتشاف سبل أخرى لتسيير العملية. على سبيل المثال، لنفترض أنك قادر على البيع المتكرر للجمهور المستهدف ولكن كل عملية بيع تستغرق بضعة أشهر. بوضع ذلك في الحسبان، قد توسع هدفك ليشمل 50 عميلًا جديدًا لهذا العام. ولتحدي نفسك، اسأل نفسك عما يتطلبه الأمر للوصول إلى 500 عميل جديد بدلًا من ذلك. قد تكتشف أن هناك طرائق للوصول إليها لم تفكر فيها من قبل. وبالنسبة لشركات B2B (وهي الشركات التي تبيع منتجاتها لشركات أخرى Business-to-business)، غالبًا ما يعني ذلك الانتقال إلى النمو الذي يقوده المنتج وهو طريقة مختلفة تمامًا لإدارة الأعمال. ترجمة -وبتصرف- للمقال 4 Startup Speeds You Need to Succeed لصاحبته Noa Ganot. اقرأ أيضًا أنواع موارد المشروع واحتياجاته الخطوات الموالية للخروج من المشروع وتوثيق الرحلة الريادية الأخطاء الشائعة لرواد الأعمال عند بداية مشاريعهم

إنَّ دور مالك المنتج معروف على نطاق واسع في حقل تطوير البرمجيات وفق المنهجية المرنة Agile. في هذا المقال، سنوضح من يكون "مالك المنتج" أساسًا، وسنذكر أيضًا السبل التي يُمكِنها جعلك مالك منتج ناجح، حيث سنستعرض مجموعةً من النصائح والخطوات العملية في سبيل ذلك. قد يحدث أحيانًا خلط بين وظيفة كلٍّ من مالك المنتج و وظيفة القائد الأساسي للفريق التآزري Scrum Team، إلا أنَّ مالك المنتج بصورة عامة، لاتقع على عاتقه مسؤوليات كثيرة كما هو الحال بالنسبة لقائد الفريق الأساسي فيما يخص الإشراف على أعضاء الفريق. قد لا تنطبق أفكار هذا المقال بالمطلق على جميع أنواع المشاريع، ولكنها بلا شك ستلهمك وتعلمك الكثير حول المسؤوليات العامة لوظيفة مالك المنتج ضمن حقل خدمات تطوير البرمجيات. جمعت هذه الأفكار المتعلقة بمالك المنتج بهدف نقلها لزملائي الجدد في هذا المجال أو حتى الذين هم بقيد العمل حاليًا، فأنا واثق من أن الجميع يمكنهم الاستفادة منها، بمن فيهم الأشخاص في عالم الإنترنت Online. لقد مارست شخصيًا هذا الدور عدة مرات و اكتسبت الكثير من الخبرة ضمن هذا المجال وأظن أن الوقت قد حان لمشاركة تجربتي مع الآخرين. دعونا نبدأ إذًا ببعض التعاريف. لقد أجمعت معظم النشرات على العبارة التالية بما يخص وظيفة مالك المنتج: ولكن لتحقيق ذلك يجب على مالك المنتج المرن أجايل Agile ممارسة أدوار عدة بصفته من يضع خطة العمل ويصمم المنتج ويحلل طبيعة السوق بما أنه على اتصال مع العملاء ومدير للمشروع. باختصار، فإن مالك المنتج جزء أساسي من أي فريق سكرام Scrum Team. غالبًا ما يقود تنوع المسؤوليات هذا الكثير من مالكي المنتج الجدد للضياع، فالكفاح من أجل تحقيق التوازن بين كل من اهتمامات العملاء ومصلحة الإدارة والفرق المطورة أمر واقع لا بد منه، إذ يجب عليهم توفير كميات متزايدة من المنتج وفقًا لجدول أعمال مُحكَم. وفي ظل تعاملهم مع الجميع، يجب عليهم البقاء حازمين في تعاملهم رغم السلطة المحدودة الممنوحة لهم باتخاذ القرار. استنادًا لما ذُكر أعلاه، يُتوقع من المرشحين لوظيفة مالك المنتج أن يكونوا أصحاب خبرة في المجال ويمتلكون معرفة قوية مصحوبة بنضج في التواصل مع الآخرين واستعداد لتحمل مسؤوليات جديدة. من يكون مالك المنتج؟ أجريت العديد من المحادثات مع مالكي المنتج، وطرحت عليهم السؤال التالي: "من هو مالك المنتج؟ ما المهمة التي يقوم بها؟"، عندها فحصلت على عدد كبير من الأجوبة بهدف الحصول على مفهوم مترابط منهم. تضمنت إجاباتهم ما يلي: شخص يتحمل المسؤولية. شخص يمكنه التواصل مع الآخرين. قائد للفريق. محلل لعمل الفريق. عالِم نفس. مدرب. عضو ضمن فريق التطوير. وكيل عن غيره. مطوّر / عالِم. شخص يأخذ رؤية المستخدم بالحسبان. شخص قادر على تحويل رغبات العملاء إلى أفكار قابلة للتطبيق. شخص يرفع مستوى العمل إلى الحد الأقصى. شخص يحصي احتياجات العمل. شخص مقدم للتضحيات. يضع معايير الاختبار، إلا أنه لا يقوم بالاختبار بحد ذاته. الأفكار السابقة كثيرة كما هو ظاهر، لذا دعنا نحاول إذًا أن نأخذ فكرةً حول من يكون مالك المنتج من خلال أربع وجهات نظر مختلفة وهي: الشركة، والفريق، والعميل، ووجهة النظر الفنية. بالنسبة لوجهة نظر الشركة، فمالك المنتج هو الشخص المسؤول عن إبرام العقد، فهو مسؤول عن ترتيب أولويات إنجاز العمل ويراقب عملية الإنجاز. في الشركة التي استخدمتها كدراسة حالة ضمن المقال، وفي حالة المشاريع الصغيرة، اتضح أن الفرد عليه قضاء ما لا يقل عن %20 إذا كان عليه إنجاز عمل فني كبير. وكحالة مثالية، الشخص الواحد عليه أن "يملك" منتجًا واحد. وبالنسبة لوجهة نظر الفريق فإن مالك المنتج هو دليلهم للسير قدمًا. يُعَد هذا من قبل الكثيرين أصعب جزء في الوظيفة، إذ يجب عليه أن يكون خدومًا ويلبي احتياجات الفريق وينسجم مع توليفة الفريق، بحيث يقرر من هو الشخص المناسب لتأمين المنتج بنجاح. ترى الفرق أن على مالك المنتج الانتباه للملاحظات التي ترِد خلال اجتماعات الفريق وتدوينها. عليه الإلمام بدقائق الأمور وصغائرها بطبيعة الحال، إلا أن عليه تحديد قائمة أعمال فعالة بالمهام الواجب إنجازها، فليس مطلوب منه إذًا الإلمام بكل تفصيل. يجب على مالك المنتج امتلاك رؤية حول المنتج الذي يعمل عليه الفريق وليس المشروع بحد ذاته، وعليه أيضًا أن يكون وكيلًا عن باقي الأعضاء لتخفيف أعباء العمل عنهم إلى الحد الأدنى؛ أما بالنسبة لوجهة نظر العملاء، فمالك المنتج هو الشخص الذي يتواصل معهم، وهو بالطبع حامل للمسؤولية، فهو وكيلهم الذي يفهَمهم ويكون جل همه نجاح مشروعهم. وإضافة إلى ذلك، يتفاوض معهم عندما تكون الميزانية محدودة (وهو الشيء الذي يحدث غالبًا)، كما يجب عليه إرشاد العملاء عديمي الخبرة في مجال منهجية تطوير البرمجيات لتوعيتهم بتبعات خيارات تصميم معينة. وبالنسبة لصاحب العمل الذي عملت معه على وجه التحديد، فإن المرشحين للدور القيادي يُختارون من بين أفراد على مستويات عالية من التنافس. وكما قيل، فإن الشخصية القيادية لا تأتي من مجرد الاطلاع الواسع فحسب بل تتطلب معرفةً وتجربةً إضافيتين. بالنسبة لوجهة النظر الفنية، فعلى مالك المنتج اتّباع "دورة حياة تطوير البرمجيات" SDLC الخاصة بالشركة أو أي مجموعة أنظمة تتبناها الشركة في حال كانت مفتقدة لنظام مشابه. يُنصَح مالكو المنتج بوضع العمل تحت الاختبار باستمرار، فنحن نعتقد أن المشروع يسير على ما يرام بسبب أننا لا نختبره، ونحن لا نختبره لأننا في الواقع لا نريد معرفة أنه سيء. أخيرًا، على مالك المنتج تيسير الطلبيات البسيطة والمطلوبة باستمرار. من ضمن مسؤوليات مالك المنتج أيضًا: التعامل مع المخاطر. تحويل الأقوال إلى أفعال. تحمل المسؤولية عندما تصبح. الأمور غامضة ومبهمة. التأكد من أن عدد المهام على قائمة الإنجاز أقل من س (أُجمِع بأن 100 مهمة عدد مقبول). مالكو المنتج ضمن دورة حياة المشروع يجب أن يكون مالك المنتج متواجدًا ضمن عملية تطوير المشروع منذ البداية، فالعملية النموذجية للمشروع تتضمن غالبًا: إجراءات ما قبل البيع. المبيعات. انتقاء الفريق. تطوير المشروع بحيث توضع الخطط وتحدد المصادر. الدعم. إن وجود مالك المنتج في المراحل المختلفة أمر قابل للنقاش ويعتمد على طبيعة الشركة بدرجة كبيرة. هناك إجماع بأن جميع الموظفين يقومون بعملية البيع فعليًا بطريقة غير مباشرة، وذلك من خلال إنجازهم لعملهم والحفاظ على تواصلهم مع العملاء. وفي كل المراحل السابقة، على المرء تذكر فكرة تكررت كثيرًا في المقابلات التي أجريتها، وهي أن ترتيب الأعمال الواجب إنجازها Backlog هو أداة مالكي المنتج في عملهم. بصفتك مالكًا للمنتج، يجب أن تكون على دراية بنقاط الاهتمام الرئيسة في دورة حياة تطوير البرامج والعمليات المرنة Agile Processes ودورك فيها. سأعرض الآن نصائح حول بعض أنواع الاجتماعات التي ستكون جزءًا منها. الاجتماع الافتتاحي وهو أول اجتماع مع أعضاء الفريق: أرسل جدول أعمال إلى أعضاء الفريق قبل الاجتماع. وضح الغرض من الاجتماع. عرف أعضاء الفريق ببعضهم البعض. ناقش محور العمل. استخدم وسائل تنظيمية مثل اجتماعات الحالة Status Meetings وأنشئ قنوات اتصال بين الأعضاء وناقش نتائج العمل وإدارة المهام وطرائق الوصول إلى الموارد. امنحهم فرصة التعبير عن أفكارهم وآرائهم. اقترح مواعيد لعقد اجتماعات لاحقة. التخطيط الهدف هنا هو تحديد الكمية المتزايدة من المنتج المراد إنتاجه في الفترة القصيرة المقبلة. التذكير بأهداف الفريق قريبة و بعيدة الأمد والأولويات بالنسبة للفريق. قسم المهام، بحيث يمكن إنجازها خلال الفترة المحددة. لا تدخل بالتفاصيل. دعِ الجميع يشارك في الاجتماع. راعِ الوقت، حيث تنخفض الإنتاجية بحدة بعد مرور ساعة من بدء الاجتماع. اجتماعات الحالة Status Meetings أقصد باجتماعات الحالة تلك التي تجتمع فيها مع العميل. ابدأ بموضوع خفيف. الهيئة والمظهر ليست بتلك الأهمية. لا حاجة لإعداد شرائح مثالية في كل مرة. تمسك بجداول أعمال ثابتة. أرسل ملخصات. تواجد الفريق بأكمله ليس ضروريًا. نصائح عامة حول الاجتماعات كن مستعدًا للاجتماع. كن أول شخص يحضر الاجتماع . تمسك بالفترات الزمنية المحددة . لا بأس بالقليل من الأحاديث الجانبية. لا تطلب من الأشخاص غير المستعدين إنجاز مهام تعتقد أنهم غير مستعدين لها، خصوصًا أمام الأشخاص الآخرين. كن على طبيعتك كإنسان. الاختلافات الثقافية ضع الاختلافات الثقافية دومًا في حسبانك. بالنسبة للجلسات التي تتضمن أشخاصًا من مختلف دول العالم، يُلقن الأشخاص طرق التواصل مع الثقافات الآخرى أو على الأقل يعتادون عليها، لذا فهم سيضبطون تصرفاتهم الاجتماعية معك. ولكن على كلا الطرفين مراعاة ذلك، فلو كنت تعمل على مشروع مع عميل أصله من منطقة لا تعرف عنها الكثير، عليك قراءة القليل عنها. خاتمة قد تكون تجربتك الأولى كمالك منتج صعبةً بعض الشيء، ولكن كل شيء سيكون على ما يرام طالما أنك مدرك لموقعك وقادر على نقل ما تعنيه حقًا للآخرين، فكلنا بشر بالنهاية. لا تخف من طلب المساعدة من الآخرين، فمن المؤكد أن مديرك ومطوري العمل سيقدمون لك العون بخصوص أي أمر يتعلق بتواصلك مع العملاء؛ كما أن المدراء الفنيون متواجدون أصلًا لمساعدتك باتخاذ القرارات المتعلقة بالناحية الفنية للعمل، فما عليك سوى اغتنام من حولك بما يخدم مصلحتك. ترجمة -وبتصرّف- للمقال ?Agile Development: What Is a Product Owner لصاحبه Karol Horosin. اقرأ أيضًا ما هي إدارة المنتجات؟ دليل المبتدئين لمنهجية أجايل Agile دليلك إلى أشهر أطر عمل منهجية أجايل أهمية التخطيط لدورات التطوير في منهجية أجايل المراسم الأربعة لمنهجية أجايل Agile ceremonies