التخطيط بسرور. كيف أنشأنا عمليات بدون مديرين

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

الفريق

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



يمكن تمثيل مجموعة المهام القادمة إلى الفريق على النحو التالي:

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

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

مثال: المهمة التي يجب أن يكون لها هو إطلاق beta.2gis.ru ، والمهمة من العميل هي إضافة حقل جديد إلى استجابة التطبيق.

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

كما كان من قبل

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

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

المشكلة 1. ليس من الواضح للعملاء ما يحدث مع مهامهم.

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

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

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

مشكلة 2. لا يعكس مجلس Kanban الواقع

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

المشكلة 3. الفريق ليس واضحا ما يحدث مع المهام

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


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

اجعل العميل شفافا

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

اجعل الفريق شفافا

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

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

كيف فعلت

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

ما أريد القيام به بعد ذلك:

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

هل حللت أي من هذه المشاكل؟ تبادل الأفكار في التعليقات.

هل تريد المتابعة؟ انضم إلى DevDay Manage IT البث المباشر غدًا.