Як CTO робить створення й випуск програм передбачуваними

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

Роль CTO — побудувати таку систему роботи для продукту, інженерії, проєктування продукту, безпеки, експлуатації та комерційних зобов’язань. Вона поєднує менші частини роботи, видиме проходження через систему, зменшення технічних ризиків, надійні шляхи випуску, явні повноваження на рішення та прогнози, уточнені за фактичними даними минулих періодів. Засоби й показники підтримують модель, але не виправлять неоднозначних пріоритетів або повноважень.

Цей посібник призначений засновникам і керівникам, чиї розмови про план розвитку перетворилися на торг між оптимізмом і недовірою. Для суміжних рішень дивіться матеріали про масштабування після MVP, стратегію перевірок і створення плану технічного розвитку, придатного для рішень.

Визначте, що саме організація обіцяє завдяки передбачуваності

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

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

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

Побудуйте вихідну картину за даними про перебіг роботи та збої

Відтворіть, як робота насправді проходила через систему. Візьміть завершені, покинуті, термінові й затримані завдання у звичайні та складні періоди. За наявності даних запишіть надходження, взяття зобов’язання, початок, фаховий перегляд, випробування, випуск і підтвердження результату. Додайте час блокування, очікування залежностей, передавання між учасниками, повторну роботу, аварії, дефекти, виявлені вже користувачами, і незапланований попит. Мета — виявити черги та мінливість, а не оцінювати людей.

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

Розділяйте дані на порівнювані групи, перш ніж робити висновки. Невелику зміну налаштувань, зміну регульованого платіжного процесу й перенесення платформи не можна оцінювати за одним спільним розподілом. Відокремлюйте класи обслуговування, частини продукту, зовнішні залежності, планову й незаплановану роботу. Використовуйте медіани та процентилі замість одного середнього, зберігайте нетипові випадки для дослідження й документуйте зміни у вимірюванні. Показники вводять в оману, коли визначення змінюються непомітно.

Ухвалюйте явні рішення про обсяг, пріоритет і залежності

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

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

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

Установіть ритм рішень, що змінює систему роботи

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

Визначайте готовність випуску за явними критеріями: підтвердженою поведінкою продукту, перенесенням даних і сумісністю, засобами безпеки та захисту персональних даних, показовими перевірками, доказами швидкодії, діагностикою, готовністю підтримки, порядком розгортання й повернення до попередньої версії та визначеними відповідальними з правом ухвалити рішення. Суворість критеріїв має відповідати наслідкам, а не створювати одну важку перепону для кожної зміни. Автоматизація виконує повторювані перевірки; люди приймають залишковий ризик.

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

Проєктуйте з урахуванням відмов, не приховуючи невизначеності

Інженерні засоби контролю роблять невеликі зобов’язання безпечнішими. Підтримуйте відтворюване складання, швидкий зворотний зв’язок для звичайних змін, захищену головну гілку, готові до розгортання пакети, зворотно сумісні зміни бази даних, кероване ввімкнення функцій за потреби, типові автоматичні перевірки, діагностичні дані з робочого середовища та відпрацьований шлях повернення або виправлення. Поліпшуйте найповільнішу й найменш надійну частину цього шляху, перш ніж купувати новий набір інструментів.

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

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

Уточнюйте прогнози й перевіряйте дієвість моделі

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

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

Для сукупності ініціатив використовуйте сценарії, а не додавайте оцінки одним числом. Покажіть імовірний наслідок збереження поточного обсягу незавершеної роботи, призупинення однієї ініціативи, додавання залежності, резервування ресурсу для супроводу або зміни строку. Історичні дані про завершення можуть підказати ймовірнісні діапазони, коли робота порівнювана, а дані сталі, але модель має чітко називати групу аналогічних робіт і винятки. Моделювання підтримує рішення, але не робить передбачуваною роботу, яка не має аналогів. Перераховуйте прогноз після істотної зміни самої системи або попиту.

CTO досягає успіху, коли організація може давати й переглядати достовірні обіцянки без особистих подвигів. Продуктова команда може відкрито змінювати обсяг, інженери — показувати невизначеність без покарання, комерційні керівники — відрізняти прагнення від зобов’язання, а керівництво — діяти до провалу прогнозу. Передайте команді визначення показників, повноваження на рішення, ведення зустрічей і знання про прогнозування. Передбачуваність — це здатність організації, яку треба постійно підтримувати, а не інформаційна панель у власності одного керівника.

• Визначте обіцянку: укажіть результат, діапазон прогнозу, рівень упевненості, незмінні обмеження, гнучкий обсяг, відповідального й докази, що змінять зобов’язання.
• Вимірюйте перебіг роботи: використовуйте вік завдань, розподіл тривалості, кількість завершень, час блокування й залежностей, незапланований попит, показники випуску та результати продукту.
• Керуйте системою: зменшуйте розмір завдань, обмежуйте незавершені завдання, робіть видимою ціну терміновості, усувайте залежності й захищайте безпечний шлях випуску.
• Підтримуйте ритм рішень: щотижня переглядайте перебіг роботи, дозволяйте випуск за доказами, достатніми для його ризику й щомісяця уточнюйте прогнози з представниками продукту та бізнесу.
• Захищайте чесність: показуйте невизначеність і заблоковану роботу; відмовляйтеся від понаднормової праці, завищення оцінок, скорочення якості та звітних правил, що створюють видимість певності.
• Навчайтеся й передавайте модель: переглядайте помилки прогнозів, відновлення, якість, безпеку, результати й стан команди; усувайте головне обмеження та розподіляйте відповідальність.