بناء المعيار الجديد في تتبع الوقت

Written by Muneeb Sahaf
بقلم Muneeb Sahaf، مهندس ضمان الجودة

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

قصة جِبل

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

وهذا ما شاهدته في جِبل.

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

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

ومع ذلك، فإن جِبل تفتخر بكونها “المعيار الجديد في تتبع الوقت”، وهو ادعاء جريء، ولكنه ادعاء وجدته متجذرًا في الواقع. وهذا نتيجة للجهود الشاقة لجعل شيء عادي ولكنه مهم مثيرًا للاهتمام.

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

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

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

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

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

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

عملية التطوير لدينا

يقضي فريقنا ساعات لا تحصى في تحسين كل بوصة من عملية التطوير الخاصة بهم، وهي كما يلي:

التفكير: العثور على النقطة الهامة

يقضي فريقنا وقتًا طويلاً للغاية قبل كتابة السطر الأول من التعليمات البرمجية، للتأكد من أننا لا ننفق ضعف هذا الوقت بمجرد أن نبدأ في البناء. وكما قال ابراهام لنكولن:

“أعطني ست ساعات لأقطع شجرة وسأقضي الأربع ساعات الأولى في شحذ فأسي.”

البحوث الخارجية

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

البحث الداخلي: المناقشات مع الفريق

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

اتخاذ القرار: افعل ذلك الآن أو لاحقًا، كيف سيؤثر ذلك على العمل؟

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

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

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

أبحاث التصميم

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

المواصفات

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

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

  • المسودة الأولية
  • يقوم قادة الفريق بمراجعة المواصفات الأولية وترك التعليقات المتعلقة بالجدوى الفنية أو الاقتراحات البديلة
  • التعديلات
  • مناقشة أخرى (يمكن تكرار الخطوات 2-3 عدة مرات حسب مدى تعقيد المشروع).

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

تصميم المنتج

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

كل شاشة يمكن تصورها — الهاتف المحمول، والويب، والكمبيوتر اللوحي — ومجموعة واسعة من أحجام الشاشات، يتم أخذ كل شيء في الاعتبار في هذه المرحلة.

التنفيذ الخلفي واختبارات الوحدة

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

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

تطبيق طلبات العميل واختبارات الوحدة

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

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

اختبار قبول ضمان الجودة

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

اختبار الانحدار لضمان الجودة

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

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

في الوقت الحالي، نقوم بتنفيذ ذلك يدويًا قبل أن تصبح البرامج النصية للأتمتة جاهزة تمامًا.

الاختبارات الاستكشافية

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

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

الإصدار

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

الخاتمة

لإنشاء منتج رائع، يجب أن تكون لديك رؤية رائعة، وعدم الانحراف عنها عندما تتغير الرياح. يفهم فريق تتبع الوقت في جِبل الحكمة وراء عدم الاستسلام للاتجاهات بسرعة كبيرة؛ فهي هادفة ولكنها تتكرر باستمرار من أجل التحسين. وفي الوقت نفسه، يقومون بتنفيذ استراتيجيات في محاولة للبقاء ملتزمين برؤيتهم لما ينبغي أن يكون “المعيار الجديد في تتبع الوقت”. أعتقد أن هذا يلعب دورًا كبيرًا في نجاحهم الأخير.

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