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







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

الأعراض

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



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



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

مشاكل

بعد أن تعمقنا في عمليات الفريق ، وجدنا مجموعة متشابكة من المشكلات التي لا يمكن حلها بشكل منفصل ، فهي تتطلب نهجًا متكاملًا:

• كومة التكنولوجيا القديمة
• عملية كانبان الطويلة والمعوجة ؛
• صعدت الأعمال إلى الشؤون الداخلية للتنمية ؛
• كان فريق التطوير يفقد الاهتمام بالمشروع ؛
• سمية عامة.

سأخبرك بمزيد من التفصيل كيف تم التعبير عن هذا.



كومة التكنولوجيا القديمة. تمت كتابة عمليتنا في IBM ODM ، وهو نظام يحتوي على عدد من الميزات التي أعاقت طريق الفريق. تم وصفها بالتفصيل من قبل المهندس المعماري لدينا دينيس كوتسكينفي حالة مشروع مجاور (على الرغم من وجود IBM BPM ، ولكن بشكل عام كل شيء عادل). بشكل منفصل ، ألاحظ أنه لا يوجد متخصصون في السوق لديهم خبرة في هذا النظام.



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



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



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



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



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



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

ماذا فعلنا

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

• إعادة بناء عملية كانبان. بفضل مركز تسليم الأعمال Tinkoff ، الذي تعمق سريعًا في قضايانا وساعد في تكييف Jira.
• مزامنة الأعمال وتكنولوجيا المعلومات. نحن هنا مدفوعون بالاعتقاد بأن الفريق يجب أن يفهم المنتج جيدًا ، وليس فقط أداء المهام التي ستجلبه.

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

الجزء 1. إعادة كتابة العملية

لذلك بدأنا في إعادة كتابة العملية من IBM ODM إلى Camunda. تم وصف أسباب اختيار Camunda في مقالة Nikolay nshipyakov...



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



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

الجزء 2. تغيير ترتيب المهام

عند تغيير عملية التطوير ، اعتمدنا على الإرشادات التالية:

• يجب ألا تكون هناك خطوات لا تنعكس على السبورة.
• يجب إعطاء الخبرة الفنية للفريق.
• يجب أن يفهم الفريق كيف تؤثر المهمة على العمل.

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



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



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



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



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

الجزء 3. مزامنة تكنولوجيا المعلومات وفرق العمل

نستخدم العديد من التنسيقات لمزامنة الأعمال والمطورين.



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



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



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



نجري محاضرات حول المنتجات في شكل برنامج تعليمي ومناقشة لاحقة. هدفهم هو غمر رجال تكنولوجيا المعلومات في سياق الأعمال. وفقًا للتعليقات التي تم جمعها في شكل استطلاع مع الصياغة الأكثر عمومية "قيم محاضرة اليوم" ، فإن متوسط ​​التقييم هو 8.5 من 10.

النتيجة

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



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



تضاعف الأداء (عدد المهام في اليوم) خلال هذا الوقت. بطبيعة الحال ، ليس على حساب التحلل: لقد اتفقنا مسبقًا على معايير معينة نلتزم بها.



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

ماذا تعلمنا

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

• , . — . , — , . — .
• , , , , , . , .
• — , , . , , discovery .
• . one-one-, , . Shoom3301, .
• : — , IT — . , .