Ситуация

Я принимаю существующую систему. Что мне нужно в первый месяц?

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

Короткий ответ

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

#Для чего на самом деле нужен первый месяц

Не для дорожной карты и не для реорганизации. Для установления того, что верно.

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

Поэтому у первого месяца один результат: описание системы, которое не зависит от того, как её опишет один конкретный человек. Всё остальное — план, приоритеты, найм, обоснование инвестиций — идёт следом и без этого является гаданием.

#Форма тридцати дней

  1. Первая неделя — что существует

    Опись: компоненты, что от чего зависит, внешние сервисы, что работает по расписанию, какие есть окружения. Выведено из системы, а не из сессии у доски.

    Заодно: получите доступ ко всему сами и выясните, на чьё имя оформлен каждый аккаунт. Проблемы владения дешевле поднять на первой неделе, чем на шестом месяце.

  2. Первая неделя — что действительно горит

    Что ломалось за последние девяносто дней, что поднимает людей ночью, чего команда просит и не получает. Просите историю инцидентов, а не мнения.

  3. Вторая неделя — края

    Внешние зависимости, входящие интерфейсы, кто вне компании полагается на эту систему. Здесь живут риски, которых никто не считал, и здесь новый руководитель приносит пользу сразу.

  4. Вторая неделя — картина по людям

    Кто единственный разбирается в каждой области. Не чтобы судить, а чтобы посчитать. Найденная единственная точка отказа — управляемый риск; ненайденная — то, что портит квартал.

  5. Третья неделя — открытые вопросы

    Что установить не удалось, по приоритету. Принесите этот список команде как вопросы, а не как выводы, и смотрите, на какие из них не может ответить никто.

    Вопросы, на которые не может ответить никто, и есть ваша настоящая повестка на два квартала вперёд.

  6. Четвёртая неделя — самое маленькое настоящее изменение

    Выпустите что-то небольшое сами, от начала до конца, через реальный процесс. Это скажет о состоянии инженерной системы больше, чем четыре недели встреч.

  7. Конец месяца — записать и показать

    Картина, риски, открытые вопросы и то, что вы предлагаете делать с первыми тремя. Это и есть документ, который объясняет, зачем вы здесь.

#О чём спросить команду

Вопросы, которые дают сведения, а не успокоение.

О риске

  • Какую часть системы вам было бы тревожно отдать кому-то на изменение и почему? Самый урожайный вопрос, доступный новому техническому руководителю.
  • Что ломается регулярно и что вы делаете, когда это происходит?
  • Что случится, если [каждый названный человек] будет недоступен месяц?
  • Чего вы просите и что никто не согласовывает?

О краях

  • Что работает такого, чего нет в репозитории?
  • Кто вне компании зависит от этой системы?
  • Какие внешние сервисы остановили бы продукт, если бы легли?
  • Что приходится делать руками и как часто?

Об истории

  • Что здесь стоит из-за ограничения, которого больше нет?
  • Что пробовали и бросили?
  • Какие решения вы бы сейчас приняли иначе?

#Чего у неё не просить

Не просите команду написать вам документацию. Три причины, все практические:

  • Это отнимает у них недели и даёт то, что они помнят, а не то, что есть.
  • В ваш первый месяц это читается как проверка — людьми, которые и так насторожены новым руководителем.
  • Почти всё это выводится из самой системы ценой одной инструкции.

Структурную картину выведите. Их внимание потратьте на три набора вопросов выше, которые вывести нельзя ничем.

#Ловушки

Объявить технологическое решение в первый месяц.

Вместо этого Объявите вопрос в первый месяц и решение на третий. Разница в доверии огромна, а стоит это ничего.

Принять рассказ самого громкого инженера за саму систему.

Вместо этого Получите независимую картину и сравните. Там, где они сходятся, у вас факт. Там, где расходятся, вы нашли кое-что интересное.

Спутать «команда компетентна» с «знание в безопасности».

Вместо этого Явно посчитайте единственные точки отказа. Сильная команда всё равно может держать всё понимание в трёх головах.

Пропустить опись владения, потому что это кажется бумажной работой.

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

Написать стратегический документ, о котором никто не просил.

Вместо этого Сделайте картину и открытые вопросы. Это полезнее, с этим труднее спорить, и стратегия после этого становится очевидной.

#Где 1ADK помогает, а где нет

Где помогает

  • Структурная картина за дни, а не недели, и без занятия команды.
  • Описание, которого не писал никто в комнате, — это политически полезно.
  • Открытые вопросы явным приоритизированным списком.
  • Доказательства: утверждение можно проверить, а не обсуждать.
  • Запись того, что меняется за ваш первый год.

Где не помогает

  • Ничего о людях, динамике команды и способностях.
  • Рассуждение за прошлыми решениями.
  • Суждение о качестве кода или архитектуры.
  • Сказать, что приоритизировать. Это и есть ваша работа.
  • История инцидентов и эксплуатационные привычки.

Вопросы, которые задают на самом деле

Чините то, что горит прямо сейчас, и ничего больше. Любое структурное изменение, сделанное до понимания системы, обходится дважды: один раз, когда выяснится, что оно неверное, и второй — в том доверии, которое было нужно для изменений, действительно важных.

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

Сделайте то, чего нет ни у кого другого. Полная проверяемая картина системы с явным списком того, на что никто не может ответить, убеждает на третьей неделе сильнее любого решения, которое вы могли бы принять, и почти ничего не стоит команде.

Это необычно удачное и недолгое положение. Потратьте его на рассуждение, а не на структуру: чего он опасался, что пробовал и не вышло, что стоит так из-за ограничения, которого больше нет.

Получите план на тридцать дней под вашу ситуацию.

Размер команды, сервисы, состояние документации, подрядчики, горит ли что-то — и на выходе план, с которым можно работать. Без аккаунта и без почты.

Открыть конструктор плана Или сначала построить карту системы