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

У 2002 році Аgile-спільнота сприймала сталий темп просто як «сорокагодинний робочий тиждень»[2]. Agile-маніфест, зі свого боку, зазначав: «Аgile-процеси сприяють оптимальному розвитку. Спонсори, розробники і користувачі мають бути готові підтримувати постійний ритм протягом необмеженого часу»[3]. За два роки до цього моя команда в Sprint PCS повсякчасно чула від мене, що «розробка великих за обсягом програмних продуктів – це марафон, а не спринт». Якщо членам команди потрібно підтримувати сталий темп під час здійснення півторарічного проєкту, то дуже важливо завадити їхньому вигоранню за місяць-другий від початку роботи. Проєкт потрібно розпланувати, бюджетувати, розписати за часом і оцінити так, аби члени команди щодня витрачали на роботу розумну кількість часу і не надто втомлювалися. Переді мною як менеджером постало завдання досягти цієї мети і задовольнити всі вимоги бізнесу.

У 1991 році, коли я працював на своїй першій менеджерській посаді в стартапі зі створення плат відеозахоплення для ПК та більш дрібних комп’ютерів, СЕО повідомив мені, що в керівництва склалося про мене «вкрай негативне враження». Причина? Я завжди відповідав «ні», коли від моєї команди вимагали все більше продуктів або функцій, а наші потужності як розробників уже були майже вичерпані. До 2002 року це стало моєю звичкою: понад десять років поспіль я відмовлявся виконувати незліченні примхи власників бізнесу.

Загалом команди розробників ПЗ і IT-відділи компаній неабияк залежали від інших груп, що повсякчас торгувалися, просили, погрожували і вимагали переробити навіть найбільш обґрунтовані та об’єктивно розроблені плани. До переліку вразливих потрапляли навіть ті плани, що ґрунтувалися на ретельному аналізі та багаторічному досвіді. Більшість же команд, які не володіли переконливими методами аналізу й певним досвідом, були безсилі перед тими, хто намагався примусити їх узяти на себе невідомі (і переважно нездійсненні) зобов’язання.

Отже, співробітники поступово змирилися з шаленим навантаженням, і надмірні обсяги роботи перетворилися на норму. Скидалося на те, що інженери-програмісти взагалі не потребують спілкування з друзями або сімейного життя. Звучить несправедливо, бо так воно і є! Мені відомі численні приклади, коли надмірне виробниче навантаження руйнувало сімейні стосунки.

Водночас неможливо було співчувати типовому розробнику ПЗ тих часів. У моєму рідному штаті Вашингтон інженери-програмісти посідали друге місце за рівнем річного прибутку після стоматологів. Як і за часів Генрі Форда, тобто в 1920-х роках, коли люди на його автомобільних заводах заробляли уп’ятеро більше, ніж у середньому по країні, нікому навіть на думку не спадало поскаржитися на монотонність роботи або відсутність дозвілля, оскільки їхня праця щедро оплачувалася. Важко уявити собі діяльність профспілок у таких інтелектуальних галузях, як розробка ПЗ, тому ніхто й не намагався всерйоз дослідити причини фізичних і психологічних недуг, від яких потерпають розробники. Більш відповідальні роботодавці згодні сплачувати додаткові медичні послуги на кшталт масажу або психотерапії, або надавати працівникам «дні психічного здоров’я» замість того, аби приділити увагу виявленню основних причин проблеми. Технічний письменник, співробітник відомої фірми-розробника ПЗ, якось сказав мені: «Немає нічого страшного в тому, що я вживаю антидепресанти, адже так роблять усі!» Стикаючись із такими зловживаннями, інженери-програмісти зазвичай погоджуються з усіма вимогами, отримують непогану зарплату й страждають від наслідків психологічного вигорання.

Я прагнув змінити такий стан справ, знайти взаємовигідний підхід, що дозволив би мені казати «так» керівництву й при цьому захищати свою команду, забезпечуючи досягнення сталого темпу. Я хотів повернути членам своєї команди нормальне життя і поліпшити умови, що викликали стреси та проблеми зі здоров’ям розробників, які не досягли навіть тридцяти років. Ось чому я вирішив розпочати боротьбу із цими проблемами.