У програмуванні є старий жарт, який приписують Тому Каргіллу з Bell Labs: перші девʼяносто відсотків коду займають перші девʼяносто відсотків часу розробки, а решта десять відсотків коду займають ще девʼяносто відсотків часу. Смішно рівно доти, доки це не Ваш проєкт. Бо в житті це виглядає так: на кожній зустрічі Вам кажуть «майже готово, відсотків девʼяносто», і так три тижні поспіль. А потім ще три.
Я багато разів спостерігав цю картину, іноді, зізнаюся, зсередини власних проєктів. І дійшов висновку, що проблема майже ніколи не в лінивих розробниках. Проблема в тому, як ми вимірюємо поступ. Якщо вимірювати неправильно, чесні люди чесно називатимуть неправильні цифри.
Відсотки брешуть, віхи ні
«Готово на девʼяносто відсотків» це оцінка відчуття, а не факту. Розробник зробив основну частину роботи, бачить, що лишилося трохи, і називає цифру. Він не бреше. Він просто ще не знає, що в решті «трохи» сховані інтеграція, яка не запрацює з першого разу, крайні випадки, про які ніхто не подумав, і правки після показу клієнтові.
Тому перше правило контролю термінів: замінити відсотки на віхи. Віха це не «робота над модулем оплати триває», а «оплата карткою працює на тестовому сервері, і її можна спробувати». Віха має два стани: досягнута чи ні. Жодних «майже». Її можна показати, помацати, перевірити. Це як станції на залізниці: потяг або пройшов станцію, або ні. Ніхто не каже, що потяг на девʼяносто відсотків у Харкові.
Поступ, який не можна показати, це не поступ, а надія. Вимірюйте те, що можна відкрити й помацати.
Ритм контрольних точок
Друге правило: віхи мають бути частими. Якщо перша точка перевірки проєкту через три місяці, Ви три місяці летите наосліп. Коли нарешті зʼясується, що щось пішло не так, виправляти буде пізно й дорого.
Я віддаю перевагу ритму в один-два тижні. Кожні один-два тижні має бути показ працюючого результату, хай маленького. Це дисциплінує всіх. Команда не може місяць робити щось у шухляду. Клієнт бачить, куди рухається проєкт, і може скоригувати курс, поки це дешево. Менеджер отримує реальні дані про швидкість, а не враження.
Зручно, коли віхи виростають із декомпозиції проєкту. Якщо Ви читали мою статтю про WBS, то знаєте, що проєкт розкладається на пакети робіт. Віхи ставлять там, де закривається логічно завершена група пакетів, яку можна показати як результат.
Діаграма Ганта і критичний шлях
Діаграму Ганта багато хто не любить за те, що вона виглядає як бюрократія з минулого століття. Смужки на часовій шкалі, стрілочки, залежності. Але вона має одну незамінну властивість: показує, що від чого залежить. І з цього випливає поняття критичного шляху, ланцюжка задач, затримка в будь-якій з яких зсуває весь проєкт.
Знати критичний шлях важливо, бо не всі затримки однакові. Якщо на тиждень запізнилася задача, яка має запас, проєкт цього навіть не помітить. Якщо на день запізнилася задача на критичному шляху, на день запізниться все. Менеджер, який це розуміє, правильно розподіляє увагу: стежить за критичними задачами, як яструб, і не смикає людей щодо решти.
Де тримати запас
Будь-який досвідчений менеджер закладає в план запас часу. Питання в тому, де його тримати. Інтуїтивно хочеться додати трохи до кожної задачі: тут пару днів, там пару днів. Проблема в тому, що робота має властивість заповнювати весь відведений час, це давно помічено й називається законом Паркінсона. Якщо на задачу дали пʼять днів замість трьох, вона займе пʼять. До того ж люди схильні починати по-справжньому працювати ближче до дедлайну, так званий синдром студента.
Тому запас краще тримати окремо, спільним буфером наприкінці етапу чи проєкту. Задачі оцінюються чесно, без подушок, а буфер витрачається лише тоді, коли щось справді пішло не так. І швидкість витрачання буфера сама по собі стає чудовим індикатором здоровʼя проєкту: якщо половина буфера пішла в першій третині шляху, час бити на сполох.
Найважливіше: ранні сигнали
Усе перелічене це інструменти. Але головне в контролі термінів не інструменти, а культура, в якій про проблеми кажуть рано. Зірваний термін майже ніколи не буває несподіванкою для того, хто безпосередньо робить роботу. Він знає про ризик за тижні. Питання лише в тому, чи скаже він про це вголос.
Люди скажуть, якщо знають, що за погану новину їх не покарають, а допоможуть. Якщо ж гінця з поганими вістями традиційно страчують, Ви дізнаватиметеся про проблеми в останній день, коли вже нічого не можна зробити. Тому я завжди дякую за ранні попередження, навіть якщо новина неприємна. Це найдешевша інформація в проєкті.
Що зробити завтра
Подивіться на поточний проєкт і замініть усі відсоткові статуси на віхи з двома станами. Для кожної найближчої віхи дайте відповідь: що саме можна буде відкрити й перевірити, коли її буде досягнуто, і коли це станеться. Якщо найближча віха далі ніж за два тижні, розбийте шлях до неї на дрібніші. І на найближчій зустрічі з командою спитайте не «на скільки відсотків готово», а «що заважає дійти до наступної віхи вчасно». Відповідь на це запитання варта більше за будь-який звіт.
