Читать книгу Канбан. Успішні еволюційні зміни для вашого технологічного бізнесу - Дэвид Дж. Андерсон - Страница 6

Друга проблема, якою я переймався, – це прагнення кинути виклик великим організаціям для здійснення змін в управлінні. Я був менеджером із розробки в Sprint PCS і згодом у Motorola. У цих компаніях існувала нагальна потреба в переході на більш гнучкі методи роботи. Але в обох випадках було складно застосовувати Аgile-методи більш як до однієї-двох команд.

Обидва рази я не мав достатньо повноважень, щоби просто наказати впровадити зміни до роботи численних команд. Я намагався ввести зміни на прохання вищого керівництва, але не володів належними повноваженнями. Мене просили вплинути на колег, аби ті запроваджували в своїх командах такі ж зміни, як і я у власній команді. Однак інші команди опиралися впровадженню методів, які, на мій погляд, якнайкраще зарекомендували себе в моєму випадку. Ця протидія, імовірно, мала кілька причин, але найчастіше я чув, що в кожної команди власна ситуація, і мої методи слід ретельно підганяти під конкретні потреби інших. У середині 2002 року я зрозумів, що примусове виконання наказів стосовно будь-якого процесу розробки ПЗ не має сенсу – це просто не спрацює.

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

Я спробував висвітлити цю проблему в книжці Agile Management for Software Engineering, над створенням якої працював саме тоді. Я ставив питання: «Чому гнучка розробка дає кращі економічні результати, ніж традиційні підходи?» і прагнув застосувати в пошуках відповіді структуру теорії обмежень[4].

Під час досліджень і створення тексту я зрозумів, що кожна ситуація певною мірою унікальна. Хіба ж може той чи інший стримуючий фактор або вузьке місце виявитися однаковим для будь-якої команди і проєкту в будь-який час? Кожна команда унікальна: різні навички, можливості, досвід. Кожен проєкт відрізняється від інших бюджетом, обсягом і ступенем ризиків. Не схожі одна на одну й організації: у них різні ланцюжки створення цінності, вони працюють на різних ринках (рис. 1.1). Мені здалося, що це може пояснити причини виникнення опору змінам. Якщо запропоновані зміни методів роботи і моделей поведінки не дають, на думку членів команди, очевидної переваги, то вони не сприймають їх. Якщо ці зміни не впливають на те, що сприймається командою як обмеження або стримуючий фактор, то команда намагається чинити опір. Інакше кажучи, зміни, запропоновані без урахування контексту, будуть відкинуті людьми, які краще за всіх знають контекст проєкту.

Рис. 1.1. Чому універсальна методологія розробки не працює

Здавалося б, буде краще, якщо новий процес почне розвиватися, усуваючи одне обмеження за іншим. Це основна теза теорії обмежень Ґолдратта. Розуміючи, що мені ще багато чому треба навчитися, я, однак, усвідомлюючи цінність зібраного матеріалу, поринув у роботу над попередньо розпланованим рукописом. Я чудово розумів, що книжка не допоможе впровадити ці ідеї у більшому маштабі, оскільки майже зовсім не дає порад з управління змінами.

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

Нарешті я зрозумів, що можна поєднати цей підхід із деякими прийомами зі сфери ощадливого виробництва. Змоделювавши робочий процес розробки ПЗ у вигляді потоку створення цінності, а потім створивши систему відстеження і візуалізації стану робіт відповідно до того, як вони «протікають» крізь систему, я зміг побачити її вузькі місця. Здатність ідентифікувати обмеження є першим кроком у моделі, яка є підґрунтям теорії обмежень. Ґолдратт уже розробив метод застосування цієї теорії для проблем потоку – він носить незграбну назву «барабан – буфер – канат»[6]. Незважаючи на незручність назви, я відчув, що спрощений варіант цієї системи можна запровадити у сфері розробки ПЗ.

Загалом «барабан – буфер – канат» є прикладом класу рішень, відомих як «системи витягування». Як ми побачимо в Розділі 2, канбан теж є одним із прикладів такого штибу систем. Цікавий побічний ефект систем витягування полягає в тому, що вони обмежують обсяг незавершеної роботи (WIP) до заздалегідь встановленого обсягу, запобігаючи перевантаженню працівників. Цілковито завантаженими залишаються лише працівники, які безпосередньо працюють у вузькому місці; у всіх інших має залишатися вільний час. Я зрозумів, що системи витягування здатні вирішити обидві проблеми, якими я переймався. Система витягування дозволить мені робити покрокові зміни, що (як я сподівався) істотно зменшить опір, а також полегшить досягнення сталого темпу. Я вирішив перейти на систему «барабан – буфер – канат» за першої-ліпшої нагоди. Мені хотілося поекспериментувати з покроковою еволюцією процесу й подивитися, наскільки вона забезпечує сталий темп і зменшує опір змінам.

Така можливість з’явилася восени 2004 року в корпорації Microsoft, що докладно описано в Розділі 4 цієї книжки.