Як провести перші 30 днів із Fractional CTO

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

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

До першого дня: визначте питання, повноваження й правила безпеки

Ще до відкриття доступу складіть односторінковий мандат. Укажіть подію в бізнесі, три-п’ять питань, на які треба відповісти протягом місяця, рішення з визначеними строками, пов’язані з ними шляхи користувачів, кінцеву дату, відповідального керівника, зацікавлених осіб, очікувану доступність і чіткі винятки. Наприклад: чи можна виконати обіцяний запуск, чому випуск змін став нестабільним, який ризик безпеки потребує негайного обмеження, яка архітектура витримає наступний етап зростання або якого інженерного керівника варто найняти. Замість вимоги «перевірити все» встановіть межі конкретних рішень.

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

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

Перший тиждень: складіть надійну вихідну картину

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

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

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

Другий тиждень: обмежте нагальні ризики й розподіліть рішення

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

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

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

Третій тиждень: запровадьте просту систему щоденної роботи

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

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

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

Не перетворюйте перші 30 днів на показову перебудову

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

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

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

Четвертий тиждень: затвердьте цільовий план на 90 днів

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

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

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

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