Как провести первые 30 дней с Fractional CTO

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

Месяц достаточно короток, чтобы заставить сосредоточиться, и в то же время достаточен, чтобы увидеть настоящий рабочий цикл. За это время нужно связать обещания по продукту, путь клиента, архитектуру, выпуск изменений, надёжность, безопасность, данные, расходы, людей и поставщиков. Не обещайте перестроить компанию за четыре недели. Пообещайте достоверную исходную картину, неотложные защитные меры, более ясный выбор и последовательность действий, которую внутренняя команда способна выполнить. Подробнее о смежных подходах читайте в материалах «Как составить технический план развития» и «Как оценить существующую команду разработки».

До первого дня: определите вопросы, полномочия и правила безопасности

Ещё до открытия доступа составьте одностраничный мандат. Укажите событие в бизнесе, три-пять вопросов, на которые нужно ответить в течение месяца, решения с установленными сроками, связанные с ними пути пользователей, конечную дату, ответственного руководителя, заинтересованных лиц, ожидаемую доступность и чёткие исключения. Например: можно ли выполнить обещанный запуск, почему выпуск изменений стал нестабильным, какой риск безопасности требует немедленного ограничения, какая архитектура выдержит следующий этап роста или какого инженерного руководителя стоит нанять. Вместо требования «проверить всё» установите границы конкретных решений.

Определите полномочия и правила конфиденциальности. Зафиксируйте, что Fractional CTO может просматривать, рекомендовать, решать, утверждать, блокировать или передавать на более высокий уровень; кто отвечает за продукт, инженерию, безопасность, финансы, сотрудников и поставщиков; как будут разрешаться споры. Предоставьте именной доступ с минимально необходимыми правами, ограниченным сроком и журналированием действий. Согласуйте правила работы с данными, конфиденциальность бесед, запрещённые действия в рабочей среде, границы активных проверок, уведомление об инцидентах, сроки хранения и отзыв доступа. Расширяйте права лишь на основании подтверждённой потребности, а не ради удобства.

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

Первая неделя: составьте надёжную исходную картину

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

Наблюдайте за реальным поведением системы, а не только слушайте её описания. Проследите путь одной недавно созданной функции продукта от решения до рабочей среды, одного дефекта или инцидента — до восстановления, одного сложного обращения клиента и одного рабочего действия, например предоставления доступа или восстановления данных. Сопоставьте правила с журналами событий, задачами, кодом, показателями и демонстрациями. Изучите и обычный, и сложный период, ведь средние значения часто скрывают выпуск, сбой, сезонный пик или запрос крупного клиента, которые в действительности определяют систему. Разделяйте проверенный факт, обоснованный вывод, неподтверждённое утверждение и неизвестное.

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

Вторая неделя: ограничьте неотложные риски и распределите решения

Ко второй неделе отделите неотложное ограничение вреда от основательного улучшения системы. Если данные требуют немедленных действий, защитите раскрытые учётные данные, назначьте ответственных за критические оповещения, исправьте резервные копии, из которых нельзя восстановиться, закройте опасный доступ, остановите неконтролируемые расходы, обезопасьте неподдерживаемые системы с внешним доступом или исправьте процесс выпуска, который раз за разом причиняет вред. Для каждой временной меры определите ответственного, критерий приёмки, путь восстановления, срок действия и следующий шаг. Не начинайте необратимую модернизацию под предлогом срочности, если ожидание не создаёт большего и документально подтверждённого вреда.

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

Превратите выводы в небольшое число вариантов. Для каждой существенной проблемы опишите наблюдаемое состояние, результат, которого она касается, возможные последствия, степень уверенности, немедленную защитную меру и два-три осуществимых пути с оценкой стоимости, срока, зависимостей, обратимости и нагрузки на эксплуатацию. Выбирайте лишь то, что подтверждают данные. Записывайте отклонённые альтернативы и условия, при которых решение следует пересмотреть. Цель состоит не в полном перечне технических пожеланий, а в достаточной ясности, чтобы ответственно распределить ограниченное внимание.

Третья неделя: введите простую систему повседневной работы

На третьей неделе введите самый простой полезный ритм принятия решений. Еженедельный пересмотр приоритетов и рисков продукта и инженерии поможет согласовать обещания с возможностями команды; архитектурный совет будет рассматривать значимые решения, затрагивающие несколько систем; обзор хода работ охватит их движение, выпуски, качество и восстановление; отдельный порядок для безопасности и надёжности позволит распределять действительно серьёзные риски. Для каждой такой встречи определите исходные данные, участников, права на решения, ожидаемый результат, ответственного и ограничение по времени. Уберите отчётные совещания, после которых нет ни решения, ни новых сведений.

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

Сделайте работу видимой с помощью краткого перечня текущих задач. Каждый пункт должен содержать ожидаемый результат, подтверждающие данные, ответственного, зависимости, критерий приёмки, способ восстановления и дату пересмотра. Используйте небольшую сбалансированную систему измерения: для каждого приоритета — один опережающий показатель, один показатель результата и одна контрольная граница. Рост скорости выпусков ничего не доказывает без данных о неудачных изменениях и опыте клиентов; сокращение расходов на облачные ресурсы — без оценки надёжности и труда инженеров. Публикуйте короткие записи решений и храните все материалы в системах под контролем компании.

Не превращайте первые 30 дней в показательную перестройку

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

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

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

Четвёртая неделя: утвердите конкретный план на 90 дней

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

Постройте план на 90 дней из завершённых, полезных частей. Перед широкой модернизацией выполните необходимые предварительные условия и ограничьте риски с самыми тяжёлыми последствиями. Каждая часть должна давать пригодное к использованию изменение: проверенное восстановление, прослеживаемый выпуск, закреплённый за ответственным целевой уровень сервиса, закрытый пробел в доступе, обоснованное решение о найме или проверенную границу архитектуры — вместе с критерием приёмки и способом возврата к прежнему состоянию. Назначьте внутренних ответственных и определите роль Fractional CTO. Согласуйте план с реальными возможностями команды, бюджетом, обещаниями клиентам и способностью организации внедрять и закреплять изменения.

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

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