تلميح: من الواضح أن ليس لديك مستخدمين.
ارفع يدك إلى أولئك الذين أعلنت شركتهم "توجيه العملاء" كواحدة من قيمها المؤسسية. بالنسبة لأولئك منكم الذين قرأوا هذا النص على حبري ولم يروا الحضور: كانت الغرفة كلها تقريبًا ترفع يدها ، باستثناء زوجين من الخلف.
انهم يعملون في أوراكل.
رضا العملاء هو أحد قيم شركة أوراكل. لكن قيم الشركات - فهي تشبه عضوية الصالة الرياضية - لا يكفي مجرد امتلاكها.
هاجس العملاء شيء مفيد ، ولكن هناك شيء آخر تهتم به العديد من الشركات هو التوقيت. المواعيد النهائية جيدة.
"ستكون جاهزة عند الانتهاء" يمكن أن تكون استراتيجية رائعة (أو حتى مستحسنة) لشخصين يعملان على نفس التطبيق. ولكن عندما تعمل في شركة تضم أكثر من مائتي موظف ، فإنك تحتاج إلى فهم ما يحدث ؛ فكرة تقريبية عن متى سيتمكن المستخدمون من استخدام صفاراتك وفرتس الجديدة.
أجرؤ على القول إن المواعيد النهائية الثابتة هي مواعيد نهائية سيئة ، وإذا كانت شركتك لديها ، فيجب أن تذهب أبعد من ذلك وتزيل عنصر "التركيز على العملاء" من قائمة قيم الشركات. لأن ، صدقوا أو لا تصدقوا ، المستخدمون لا يهتمون بسباق الخيول المتناثر.
المواعيد النهائية مطلوبة في المقام الأول ليس من قبل العملاء ، ولكن من قبل الإدارة.
الهدف الرئيسي هو الهدف
أو لماذا تجميد متطلبات العدو هو ممارسة فظيعة
التوقيت جيد ، فهو يخلق إحساسًا بالإلحاح ، ويضمن إمكانية التنبؤ بعملياتك ، وبالتالي يجب أن يكون لديك.
ولكن هناك شروط جيدة وسيئة. وهناك الشركات التي يتم فيها تحديد المواعيد النهائية في الحجر ، وأولئك الذين يملؤون المواعيد النهائية في خطوة واحدة من الفصل. ثم تبدأ المشاكل.
أنا أتحدث عن ثقافة تنمية يكون من المعتاد فيها تجميد الأهداف أثناء سباق السرعة: عندما يجتمع الجميع في البداية ، يقومون بتقييم المهام ، وبالتأكيد باستخدام أرقام فيبوناتشي فقط ، وأي شيء يتم تحديده في هذه الاجتماعات ، كل هذا يجب القيام به قبل الانتهاء سباق - لا شيء يتغير وليس التسامح. من الناحية النظرية ، يبدو هذا رائعًا ، لكنني أعتقد أن مثل هذا التكتيك يخسر في أي سيناريو:
الموقف أ. لنفترض أن مطورًا يتغلب على قانون باركنسون ويغلق المهام مسبقًا. في هذه الحالة ، إما أن المطور لا يبلغ عن هذا الأمر في صباح اليوم التالي ، لأنه لا يستطيع أن يقول أنه ليس لديه ما يفعله. أو مديره يكلفه بمزيد من المهام من خلال تجميد العدو ، لأنه لا يمكن أن يكون لديه مطور لا يفعل
شيئًا .
الموقف ب. المطور ، كونه مطورًا ، متأخرًا عن الجدول. استغرقت مشاكل إعداد البيئة وقتًا أطول مما كان متوقعًا ، ولم يعد متأكدًا من أنه سيكون لديه وقت للقيام بكل شيء قبل نهاية الأسبوع.
ما يقدمه في الاجتماع التالي ، والذي يرد عليه مدير المشروع:
"حسنًا ، لقد سمعت. لكن التزمنا ، فهل يمكنك محاولة إكمال كل شيء في الوقت المحدد؟ " في الوقت نفسه ، يقوم رئيس المدير بمسح صورة لكيفية شرح التأخير في الإصدار في المزامنة الأسبوعية لنائب رئيس شركة التطوير ، والذي بدوره يعطيه المشورة المفيدة
"فقط قم بذلك" ، لذلك من الأفضل فقط سلالة ومحاولة القيام به.
لذا المطور ، كونه مطورًا ، يغادر لبضع ليالٍ ، أو ربما عطلة نهاية أسبوع ، ويكمل العمل في الوقت المحدد. ومديره
يقدر جهوده في التجمع القادم. عمل شيء.
أم أنها ليست على نحو سلس؟ تم الوفاء بالمواعيد النهائية ، وتم إنجاز العمل بنجاح ، ولكن تم إنشاء سابقة خاطئة. تلقى طالب تم استئجاره مؤخرًا وله عيون منتفخة إشارة إلى أن المعالجة في عطلات نهاية الأسبوع
صحيحة .
ولن نناقش السيناريو الحزين عندما لا يتم الوفاء بالموعد النهائي ، وتنتقل المهمة إلى السباق التالي ، ويتعين على المدير تبرير التأخير في مزامنته الأسبوعية المقبلة قبل نائب رئيس التطوير والاستماع إلى النصائح الأخلاقية.
هل ترى مشكلة؟ في أي وقت من الأوقات ، لم يسأل أي شخص السؤال التالي:
"اسمع ، ماذا يحدث إذا انتقلنا إلى العدو التالي ولم نقدم أعذارًا لأحد؟ كيف سيؤثر هذا على المستخدمين؟ "في كثير من الأحيان أكثر مما ينبغي ، المواعيد النهائية هي التنويم المغناطيسي الذاتي. وكيفية التعامل معهم - أيضا.
إن الحل المثالي هو
مجرد التحدث إلى الأطراف المعنية - فريق المنتج أو فريق المبيعات ، ومعرفة ما إذا كان التأخير قد يؤدي إلى فقدان العميل. وإذا كان الأمر كذلك ، فعليك بالتأكيد تخصيص ساعات إضافية ، وربما العمل في عطلة نهاية الأسبوع. في هذه الحالة ، سيتلقى الطالب الشاب إشارة إلى أن الشركة تهتم حقًا بعملائها ، وليس بسباقها.
هناك مشكلة أخرى مع تجميد السرعات. لنفترض أنك تلقيت طلبًا من عميل - لإصلاح خلل تافه ومنخفض الأولوية. المطور سوف تتعامل معها في يوم واحد. لكنك تتابع عملية
TM ، مما يعني إضافة المهمة إلى تراكم فريقك وربما يتم تذكرها بعد بضعة أشهر. لكنك فقدت الفرصة لإرضاء المستخدم! يمكنك التعامل مع هذا في غضون يومين ، وإبلاغ المستخدم عبر البريد الإلكتروني أنه قد تم حل مشكلته. يتذكر الناس مثل هذه اللحظات ، وهذه الأشياء هي التي تجعلهم يوصون المنتج الخاص بك لأصدقائهم.
لا تبالغ في العمليات - بسببها يمكنك تفويت هدفك. 1
أعتقد أيضًا أن تجميد السرعات أو أي ممارسات تقييدية أخرى هي علامة على انعدام الثقة المتبادل المتأصل في الشركة ، كنتيجة لمشاكل أكثر جوهرية على مستوى ثقافة الاتصال ، ولكن أكثر حول ذلك في المرة القادمة.
لماذا هي المواعيد النهائية فظيعة
- إنها تخلق توقعات خاطئة ، على عكس ما هو مكتوب في قيم شركتك. لأن قيم شركتك ليست هي قيمك ، فإن قيمك الحقيقية هي توقعات وتحيزات غير مكتوبة (جيدة وأخرى سيئة).
- سيقطع الناس الزوايا إذا وضعتهم في ظروف قاسية. سوف يسجل شخص ما للاختبار ، ولن يقوم شخص ما بتحديث الوثائق. يمكنك شحن الإصدار في الوقت المحدد ، ولكن بأي ثمن؟
- لا أحد يوافق على قضاء بعض الوقت في البحث عن حلول جديدة بينما يصلي المديرون من أجل المهام المنجزة في الوقت المحدد. سيكتب الجميع الواجهة الأمامية على أطر عمل MVC حتى يمر شخص ما على Facebook خلال الموعد النهائي.
لذا ، اعمل بدون مواعيد نهائية؟
بالطبع لا. تحديد المواعيد النهائية ، ولكن جعلها مرنة. مدى مرونة المواعيد النهائية الخاصة بك يمكن أن يكون هدفك. إذا كان الفشل في الوفاء بالموعد النهائي قد يؤدي إلى خسارة مليون دولار ، يجب أن تكون مرونتك صفرية. ولكن إذا كانت هذه ميزة أخرى ، فهناك دائمًا مجال للمناورة. يمكنك أيضًا تجربة طرق احتمالية أكثر تعقيدًا لتقدير التواريخ ، بدلاً من لعب أرقام فيبوناتشي بإصبعك في السماء.
2لكن تجميد السرعات هو قرار صعب.
1. تحدث جيف بيزوس جيدًا حول هذا الموضوع في رسالة إلى المساهمين في عام 2016 . ونصح "مقاومة الوكلاء بين الناس داخل الشركة."2. يتحدث جويل سبولسكي عن الأساليب المتقدمة لتقدير المواعيد النهائية في مقاله "الجدولة المبنية على الأدلة" ( الترجمة في حبري ).