Коригування політик

Ви можете задатися питанням: яким чином розставлялися пріоритети, якщо підрахунок ROI більше не здійснювався? Виявилося, що він взагалі не потрібний. Якщо елемент був важливий і цінний, то його вибирали з беклогу до вхідної черги, а якщо ні, то не вибирали. Пізніше Драгош зрозумів, що необхідна ще одна політика: вичищати з беклогу будь-який елемент, старший за шість місяців. Якщо за півроку після надходження його так і не вибрали, то напевне він не має жодного значення. А якщо кінець кінцем з’ясується, що даний елемент таки важливий, то його можна додати знов.

Примітка. Це поширена тема в методі Канбан. Поєднання явних політик, прозорості та візуалізації надає членам команди можливість приймати власні рішення і самостійно керувати ризиками. Врешті-решт керівництво починає довіряти системі, оскільки розуміє, що робочий процес складається з політик. Політики розробляються для управління ризиками та задоволення користувацьких очікувань. Політики є явними, робота відстежується прозоро, а всі члени команди розуміють політики й принципи їх застосування.

А як щодо керуючої політики про перешкоджання надходженню великих запитів до техпідтримки замість спрямування їх до великого проєкту? Зрештою було вирішено, що деякі з них таки можуть туди спрямовуватися. Історичні дані свідчили, що таких запитів зазвичай менше 2 %. Розробників просили бути уважними, і якщо новий запит, за їхніми оцінками, вимагає на обробку понад 15 днів, попереджати свого менеджера. Ризики і витрати в даному випадку становили менше 0,5 % наявної потужності. Це був чудовий компроміс: відмовившись від оцінювання, команда отримала понад 33 % додаткової потужності за рахунок витрати менше 1 % тієї самої потужності. Ця нова політика дала розробникам повноваження самим керувати ризиками і за необхідності висловлювати свою думку!

На перші дві зміни було відведено пів року. Протягом цього періоду були запроваджені ще деякі дрібні поліпшення. Як уже зазначалося, з’явилась політика очищення беклогу, а щотижневі зустрічі з власниками продукту були скасовані. Процес рухався так гладко, що Драгош налаштував Product Studio так, щоб отримувати електронне повідомлення щоразу, коли виникало вільне місце для нового завдання. Після цього Драгош попереджав електронною поштою власників продукту, які між собою вирішували, хто з них має вибрати наступне завдання. Здійснювався вибір, і запит переводився з беклогу в чергу протягом двох годин по тому, як з’являлося вільне місце.