كيف بدأنا في إصدار الميزات بسرعة مضاعفة (دراسة حالة)

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

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

مزيد من القراءة على SmashingMag:

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

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

نداء إيقاظ

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

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

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

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

من الاقتراح إلى الميزة

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

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

بناءً على التعليقات ، تقوم فرقنا بتحديث نموذج يبدو كالتالي:

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

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

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

• ما الفوائد التي ستجلبها هذه الميزة للمستخدمين؟
• هل تناسب فلسفة منتجاتنا؟
• هل ستضيف تعقيدات لا داعي لها؟
• هل تنسجم بشكل جيد مع الواجهة والوظائف الموجودة؟
• هل لدينا الموارد اللازمة لتقديمه في إطار زمني معقول؟

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

التصميم للمستخدم

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

نبقي الأمور في نصابها من خلال السؤال ، أين يتوقع المستخدم أن يكون هذا الخيار؟

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

خذ اختصارات لوحة المفاتيح. يمكنك إنشاء مجموعة الاختصارات الخاصة بك وتتوقع أن يتعلمها المستخدمون (ربما لن يتعلموها). أو يمكنك إضافة تلك التي يستخدمها الأشخاص بالفعل. يستخدم الكثير من مستخدمينا Slack بالفعل ، على سبيل المثال ، لذلك أضفنا اختصارًا مألوفًا لهم بالفعل (يعمل Command + K للقفزات السريعة في Active Collab أيضًا).

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

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

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

حان الوقت لبدء الأمور

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

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

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

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

بعد الاجتماعات ، سيكون لدى الفريق جميع المعلومات اللازمة:

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

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

ننتقل إلى قائمة التحقق هذه قبل بدء العمل:

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

هذه هي اللحظة التي تنتقل فيها مهمة إلى عمود "قيد التقدم".

حان وقت الترميز!

العمل الجماعي على الشاشة

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

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

اعرض وتكلم

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

اجتماعات أسبوعية

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

وضعه على المحك

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

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

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

إليك تعريفنا لكلمة "تم":

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

وصلت المهمة إلى المرحلة النهائية ، المسماة "Release Q."

الافراج اليوم

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

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

يوم نشاط مجاني

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

يوم مطاردة الحشرات

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

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

ما هي النتيجة؟

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

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