سعياً منها لتحسين قدرتها على التكيف، سارعت عدة شركات إلى تطبيق منهج أجايل (Agile) لتطوير البرمجيات. لكن الكثير من هذه الشركات فعل ذلك بطريقة جعلتها أقل مرونة. لقد أصبحت هذه الشركات مرنة بالاسم فقط، لأن العملية التي اعتمدتها تؤدي في كثير من الأحيان إلى التأثير سلباً على حافز المهندسين وحتى إنتاجيتهم.
منهجية أجايل لتطوير البرمجيات
تتوفر أطر تطوير البرمجيات عالية التكيف مثل أجايل منذ فترة طويلة وتتجلى في أشكال عديدة. ولكن في صميم معظم هذه النماذج، هناك أمران: وضع فرضيات (على سبيل المثال، ما هي الميزة التي يفترض تحقيقها؟) والتعاون بين مجالات الخبرة المتعددة في تجربة المنتج، كل ذلك بروح التعلم بالقيادة وليس الترنح على مسار يثبت لاحقاً أنه ليس بالمسار الصحيح.
عندما بدأ تطوير البرمجيات وفق منهج أجايل في عام 2001، صاغ هذا المنهج أربعة مبادئ حاسمة للارتقاء بحرفة تطوير البرمجيات وتحسين الحوافز لدى المهندسين ومديري المنتجات من خلال:
- جعل الأفراد والتفاعل فيما بينهم أوْلى من العمليات والأدوات.
- اعتبار البرمجية الناجحة أهم من التوثيق الشامل.
- اعتبار التعاون مع الزبائن أهم من التفاوض على العقود.
- جعل الاستجابة للتغيير أوْلى من اتباع خطة ما.
على مدى السنوات الأربع الماضية، وخلال بحثنا حول ما الذي يحرك الحافز البشري، حللنا ممارسات المهندسين عبر أكثر من 500 شركة مختلفة باستخدام مزيج من المناهج التجريبية وتلك القائمة على الاستبانات ووجدنا أن ما يحدث في الواقع بعيد تماماً عن هذه المبادئ المعلنة.
على سبيل المثال، من الممارسات الشائعة أن العمليات والأدوات أصبحت هي المحرك للعمل، وليس الأفراد والتفاعلات. في إحدى شركات "فورتشن 100" الكبرى، قال لنا رئيس المنتجات الرقمية: "لا يُسمح لنا بالتشكيك في أي عملية وفق منهج أجايل". وفي مؤسسة أخرى ضمن قائمة "فورتشن 500″، يتواصل مدراء ومهندسو المنتجات حصرياً من خلال أدواتهم التي يلجأ إليها المدراء في المقام الأول لإصدار الأوامر إلى المهندسين.
وبالمثل، يحظى التوثيق غالباً بالأولوية على حساب البرمجية الناجحة. في إحدى شركات التكنولوجيا الكبيرة، كرّس فريق أحد المنتجات قسماً كبيراً من الوقت في البداية لكتابة متطلبات صغيرة (تسمى "قصص المستخدمين"). ووضعت هذه المتطلبات في قائمة بطاقات انتظار كمهام يؤديها المهندس المتاح التالي لبدء العمل عليها. لقد ازداد حجم الوثائق المطلوبة لاستمرارية تحريك قائمة الانتظار. وفي نهاية المطاف، أصبحت هذه العملية تتدفق وتتعدد كأنها "شلالات" صغيرة، حيث يتم تمرير العمل من قسم المنتجات إلى المصممين إلى المهندسين. هذه العملية هي بالضبط ما كان يقصد منهج أجايل التخلص منه. لذلك فإنه من غير المستغرب أن يقول مدير تكنولوجيا المعلومات في هذه الشركة إن "المهندسين لديه يشعرون بأنهم طهاة ينفذون طلبات صغيرة في مطبخ خلفي في أحد المطاعم".
في الحالات التي يطلق عليها "الاستجابة للتغيير خلال تنفيذ إحدى الخطط، قد يسيء البعض فهم تلك المرونة في تغيير الخطط على أنها بمثابة "العمل من دون خطة". وهذا ما نجده – على سبيل المثال – في إحدى شركات التكنولوجيا سريعة النمو، حيث لم تحاول فرق أجايل فهم الاستراتيجية الأوسع للشركة. ونتيجة لذلك، ركزت محاولاتهم المتكررة للتطوير على نواح منخفضة القيمة أو غير مهمة من الناحية الاستراتيجية. في غياب الخطة، لن تعرف فرق العمل كيف تحدد أولويات الإجراءات وكيفية الاستثمار في تلك الإجراءات بشكل مسؤول. وقد ساد تطبيق هذا المبدأ إلى حد جعل المهندسين يعتقدون أنه من غير المناسب أن يكون هناك قيد زمني لتنفيذ خطط العمل الأساسية.
لو كان سوء تطبيق منهج "أجايل" الذي ذكرناه آنفاً أدى إلى تحسن الحافز لدى المهندسين وإلى تحسين الأداء لكان الأمر مفهوماً، ولكن الواقع أن العكس هو ما حدث. إن منهج أجايل عندما يمارس بالطريقة الموضحة أعلاه، يقلل من الدافع العام لدى المهندسين. ونظراً لأنه لا يُسمح لهم بالتجريب وإدارة عملهم والتواصل مع الزبائن، فإنهم لا يشعرون أنهم معنيون بالأمر ولا بالإمكانيات الواعدة أو الغاية من المنتج؛ وبدلاً من ذلك يشعرون بضغط نفسي واقتصادي لتحقيق النجاح، أو بحالة من الفتور في الأداء. إنهم يتوقفون عن التكيف والتعلم وبذل قصارى جهدهم في عملهم.
على سبيل المثال، روى لنا أحد الشركاء في شركة ذات رأس مال مغامر (أو ما تسمى بشركات رأس مال جريء) قصة عن كيفية استمرار شركة لتطوير ألعاب الفيديو في بناء منتج لمدة عام على الرغم من أن كل مهندس لديها كان يشعر أن اللعبة لا تستحق اللعب. لقد أدركت الشركة لاحقاً أنها أهدرت الكثير من الوقت والمال.
تخرج عمليات أجايل عن مسارها لأن الشركات، وهي تسعى جاهدة للارتقاء بأدائها، إما إنها تصبح تكتيكية للغاية (تركز أكثر من اللازم على العمليات وإدارة الأمور التفصيلية) أو تكيفية للغاية (تتجنب الأهداف طويلة الأجل والجداول الزمنية أو التعاون بين الأقسام متعددة الاختصاصات).
إن مفتاح الحل هو تحقيق التوازن بين كل من الأداء التكتيكي والتكيفي. سواء كنت مهندساً أو مدير منتج، إليك بعض التغييرات التي يجب وضعها في الاعتبار لتحقيق هذا التوازن، بحيث يمكنك تحسين الحافز والأداء لدى فريقك الهندسي (أو أي فريق آخر).
1- يجب أن تكون عملية تطوير البرمجيات عملية تعاونية وليس عملية استلام وتسليم.
فبدلاً من عملية يقوم فيها شخص واحد بكتابة المتطلبات (حتى الصغيرة منها) ويقوم آخر بتنفيذها، وكل ذلك دون بوصلة استراتيجية يستهديان بها، يجب على الفريق الذي يسعى لاكتساب مرونة حقيقية في العمل أن يتبع عملية بعيدة عن الاستلام والتسليم مقابل عملية يقوم فيها شخص واحد بكتابة المتطلبات في حين يقوم الآخر بتنفيذها. في العملية التي لا تجري على أساس الاستلام والتسليم، يكون مدير المنتج والمهندسون (وأي أعضاء معنيين آخرين) شركاء متعاونين من البداية إلى النهاية في تصميم إحدى مزايا المنتج.
أولاً، يجب على الفريق، بما في ذلك المدراء التنفيذيين، توضيح "تحديات" الفريق الاستراتيجية، حيث تتخذ التحديات شكل السؤال وتركز دائماً على تحسين النتيجة أو التأثير بالنسبة للزبائن. فكر بها على أنها مهمة مفصلة للفريق في شكل سؤال لتحفيز التفكير بعيد النظر. التحديات نفسها يضعها ويكيفها الفريق بأكمله، بما في ذلك الرعاة من المدراء التنفيذيين (والزبائن). ويُطلب من كل فرد في الفريق (أو أي فريق لهذه الغاية) المساهمة بأفكار لحل كل تحد وقتما يشاء.
في أحد البنوك، على سبيل المثال، كان التحدي هو "كيف يمكننا أن نساعد الزبائن على الاستعداد بشكل أفضل للصدمات المالية المحتملة؟"، وتمثل تحد آخر في طرح السؤال التالي: "كيف يمكننا أن نجعل الزبائن يرون في اتباع عادات مالية سليمة مسألة تحقق لهم الرضا وليست عملاً روتينياً؟". أنتجت هذه التحديات عشرات الأفكار من العديد من الأشخاص المختلفين.
بعد ذلك، بدلاً من أن يتولى شخص ما كتابة المتطلبات في حين ينفذها آخر، تقوم هذه الفرق بتطوير فكرة وإنضاجها بشكل تعاوني، بدءاً من المسودة الأولى إلى أن تصبح فرضية قابلة للاختبار.
2 – تجربة الفريق في إنجاز المشروعات يجب أن تكون واضحة.
غالباً ما تجد الفرق أنها تضيع الوقت عن طريق السعي المستمر للتكيّف مع الأفكار والمشاريع المتنوعة. ولتجنّب ذلك، لا ينبغي فقط تطوير الأفكار في مجال التحديات الاستراتيجية، بل أيضاً من أجل ضمان السرعة في الإنجاز، وما يسمى "السرعة في الوصول إلى الحقيقة"، بل من أجل تقليل الجهد الضائع وزيادة حقوق اتخاذ القرار لدى الفريق، يجب أن تكون التجارب قصيرة في طبيعتها. وإذا أمكن، يجب ألا تزيد مدة التجربة عن أسبوع.
يتطلب ذلك في بعض الأحيان من الفريق تقليل ميزة معينة إلى حدها الأدنى لاختبار أضعف افتراض لدى الفريق. هذا يعني في بعض الأحيان ألا يعمل الفريق على كتابة الشيفرة ولكن بدلاً من ذلك يُكمل تجربة "عدم الاتصال" (بالإنترنت) من خلال البحث.
3- ينبغي أن يركز نهج الفريق على الزبائن.
يجب أن تكون عملية بناء البرمجيات (حتى برمجيات الاستخدام الداخلي) متمحورة حول الزبائن.
وينبغي في الحد الأدنى تطبيق المبادئ التالية:
- تأطير "التحديات" حول تأثيرها على العميل دوماً.
- تبدأ اجتماعات حل المشكلات دائماً مع عرض أحدث ملاحظات الزبائن، وتضم الاجتماعات ممثلين من الخطوط الأمامية بشكل متكرر.
- كل تجربة تُبنى على فرضية تتمحور حول العميل. بهذه الطريقة، يمكن للفريق تحمل المسؤولية عن النتيجة المتوقعة من التجربة.
لكن الأهم من ذلك هو أن يرى المهندسون بأعينهم كيف يستخدم الزبائن منتجاتهم. هذا يتطلب من موظفي البيع والمهندسين العمل معاً لمعرفة ما إذا كان المنتج يخلق تأثيراً لدى الزبائن.
4 – استخدم القيد الزمني لتركيز التجربة وتجنب الهدر.
من المثير للاهتمام أن تطوير البرمجيات التكيفية يشجع على استخدام القيد الزمني كطريقة لضمان الاستثمار بصورة مبررة في تجربة ما والإشارة إلى مستوى الجودة المقبولة لميزة معينة. من ناحية أخرى، يتجنب الممارسون النموذجيون لمنهجية أجايل القيد الزمني أو المهل النهائية خشية استخدام الموعد النهائي لممارسة ضغط نفسي عليهم. إن أحد أسوأ مشاعر مطور البرامج هو قضاء بضعة أشهر في العمل على شيء يتبين في النهاية أنه غير مفيد. هذا يشعرك بضغط عاطفي ("لقد خذلت الجميع") وفتور في الهمة ("لماذا أفعل هذا؟").
لتجنب هذه النتيجة، يجب أن تكون واضحاً بشأن المدى الذي يجب أن يذهب إليه المهندس قبل أن يتحقق لمعرفة ما إذا كان لا يزال يسير في الاتجاه الصحيح. كلما زاد عدم اليقين بشأن فرضية الفريق وزاد الخطر، وجب تقصير المسار. مع أخذ ذلك في الاعتبار، فإن القيد الزمني ليس مهلة نهائية. إنه قيد يجب أن يوجه مستوى عمق وجودة التجربة قبل الاختبار الحقيقي. بهذه الطريقة، يمكن أن يزيد القيد الزمني الحافز الكلي.
5- ينبغي تنظيم الفريق للتشديد على التعاون.
للتأكد من أن الأمر لن يؤدي إلى عملية استلام وتسليم، ينبغي على مختلف المعنيين أن يعملوا كفريق واحد متعدد الوظائف، فيما يُعرف أيضاً باسم "الكبسولة". الهدف من الكبسولة هو الدفع بالتعاون قدماً. يجب أن تحتوي كل كبسولة على مجموعة كاملة من الخبراء اللازمين لتسليم منتج رائع. وهذا قد يشمل كبار المسؤولين التنفيذيين. في إحدى الشركات على سبيل المثال، تشتمل كبسولة المنتج على مدير منتج ومطور برامج أمامي ومطور برامج خلفي ومصمم ومهندس جودة وممثل عن خدمة الزبائن بوقت جزئي ومدير تنفيذي من قسم الإشراف.
في العديد من المؤسسات، هناك علامات دالة على "الكبسولات المزيفة"، وهي فرق تطلق على نفسها اسم "كبسولة" لكنها لا تعمل في الواقع على هذا النحو. ومن علامات الكبسولات المزيفة:
- يكون الخبراء في فرق "متناغمة" منفصلة وليس في الفريق نفسه. على سبيل المثال، يكون لدى فريق العمل المسؤول عن أحد المنتجات "فرق سبرنت" (sprint) أي فرق الإنجاز السريع، مهمتها إعداد فرق محددة سريعة الإنجاز وهذه الفرق تختلف عما تحدثنا عنه من "كبسولات" الفرق.
- يستخدم الفريق أدوات تحول دون تعاون حقيقي. على سبيل المثال، لدى سؤال فريق هندسي لماذا اختاروا أدوات برمجيات أجايل التي يستخدمونها، قالوا: إن "هذه الأدوات ستمنع المدراء التنفيذيين من المشاركة في عملنا". كل ما يفعله هذا هو إدامة دورة عدم الثقة.
- تحدد الإدارة العليا في الواقع أهدافاً مختلفة لأقسام الهندسة والمنتجات. ويستخدم المسؤولون التنفيذيون في كلا القسمين سلطتهم الهرمية التراتبية لجعل أعضاء فريقهم يعطون الأولوية لأهداف القسم فوق أية أهداف أخرى، بما في ذلك أهداف كبسولاتهم. تؤدي هذه النزاعات في نهاية المطاف إلى صدامات داخل فرق العمل تحول دون العمل الجماعي الحقيقي.
- ﺗقوض ﻋﻣﻟﯾﺎت إدارة اﻟﻣواھب اﻟتراتبية الصارمة، ﻣﺛل ﺗﺻﻧﯾﻔﺎت اﻷداء واﻟمناصب اﻟﮭرﻣﯾﺔ وتحمل اﻟﺿﻐوط للحصول على ﺗرقية وظيفية وأﻧظﻣﺔ اﻟترقية أو ترك الشركة، اﻟﻌﻣل اﻟﺟﻣﺎﻋﻲ اﻟﻣطﻟوب ﻟضمان عمل الكبسولات على أحسن وجه. فإما أن تجعل هذه الأنظمة أعضاء الفريق أكثر انصياعاً لرئيسهم من عميل فريقهم أو أن تضع أعضاء الفريق في منافسة مع بعضهم البعض. وفي كلتا الحالتين لن يعملوا كفريق واحد.
بعبارة أخرى، كلما كانت صوامع المؤسسة أقوى، عمل عدد أكبر من الناس على إيجاد حلول لاحتياجات قسمهم داخل الشركة، في مقابل احتياجات فريقهم. يجعل هذا التعاون والتوافق صعبا للغاية دون تصعيد مستمر.
6 – على الفريق أن يتساءل باستمرار عن صحة العملية.
هناك مبدأ هندسي شهير يعرف باسم "قانون كونواي" ينص على ما يلي: إن أي شركة تعمل على تصميم الأنظمة ستنتج تصميماً تكون هيكليته نسخة من بنية (أي عملية) الاتصال في المؤسسة. بعبارة أخرى، إذا كنت شركة متجانسة، فستصنع تصاميم أحادية متجانسة. وإذا كنت شركة منظّمة حسب شرائح المستخدمين، سيخدم منتجك تلك البنية على أمثل وجه.
إذا رغبت في التغلب على "قانون كونواي"، فإن الممارسة الأمثل هي تعديل الهيكلية والعمليات باستمرار لتتناسب مع متطلبات مواجهة المشكلة التي بين يديك. وهذا يتطلب فرقاً لديها عمليات بسيطة وذات هيكليات بسيطة وخفيفة تعمل باستمرار على مراجعتها وتعديلها.
وبالتالي، بدلاً من بناء منهجية أجايل كصرح لا يمكن المساس به، يجب أن تعتاد فرق الهندسة على الدوام على تشخيص نموذج عملها الخاص وتحسينه. في أفضل الأمثلة التي رأيناها، وعلى أساس شهري، تقوم الفرق بتشخيص نموذجها التشغيلي وتحديد ما إذا كان يحتاج إلى تغيير لتحسين المنتج.
أصبحت القدرة على جذب مواهب للعمل على تطوير المنتجات الرقمية وإلهامها والاحتفاظ بها مهمة أساسية للشركات. لقد وقعت معظم الشركات فريسة لرسالة بسيطة تتمثل في تطبيق أجايل وكأنه سلسلة من الاحتفالات وكل شيء سيتحسن. لسوء الحظ، ليس هذا ما يحدث في كثير من الأحيان عندما يُفتقد الجانب الإنساني من المعادلة. لكن، يمكنك بناء مؤسسة مرنة حقاً، من خلال العودة إلى أساسيات الحافز والأداء التكيفي.
تمت عملية الاشتراك بنجاح
عذراً، أنت مشترك مسبقاً بالنشرة البريدية
وصول رقمي للمحتوى عبر
التطبيق
والموقع 
اترك تعليق