Короткий ответ
#Звонок в пятницу
Пятница, около шести. Звонит крупный клиент, тот самый, переговоры с которым шли четыре месяца. У них новый юрист, и юрист спрашивает одну вещь: где физически лежат персональные данные их сотрудников и кто ещё их видит.
Вы знаете ответ на уровне лозунга. «У нас всё в Европе, всё шифруется.» Юристу нужно другое: список мест, где эти данные оказываются, включая резервные копии, логи, сервис рассылки и ту аналитику, которую подключили полтора года назад. Точный ответ есть у одного человека в команде. Человек в отпуске до среды.
Дальше происходит самое дорогое. Не срыв сделки, сделка обычно не срывается. Происходит пауза: пять рабочих дней, в которые вы не можете сказать ничего определённого о собственном продукте. И в эти пять дней вы впервые понимаете, что вопрос был не техническим. Вопрос был про то, кому вы принадлежите.
Про что эта статья
Не про то, что разработчики плохие или что документацию надо писать аккуратнее. Про то, что у бизнес-вопроса к системе нет источника ответа, кроме человека, и что это перестало быть нормальным именно сейчас.
#Дефицит переехал
Последние два года мысль о том, что программный бизнес строится не кодом, стала общим местом. Её повторяют основатели, которые продали компанию, и основатели, которые ничего не продали. Смысл простой: победил не тот, кто написал лучший продукт, а тот, кто первым добрался до людей с проблемой. Код оказался не преимуществом.
С этим я согласен. Но дальше из верной мысли делают неверный вывод: если код не преимущество, значит, в код можно не смотреть. Владелец слышит «бизнес это отношения» и облегчённо решает, что техническая часть его больше не касается.
Код перестал быть преимуществом, потому что стал доступен всем. Он не перестал быть ограничением, потому что бизнес упирается в него в самый неудобный момент, и этот момент выбирает не владелец. Три вещи изменились одновременно, и все три работают против вас.
-
Кода стало больше на человека
Один разработчик с агентом производит за неделю то, что раньше занимало месяц. Строк, сервисов, интеграций и фоновых задач в системе становится больше, а людей, которые держат её в голове, столько же.
Объём растёт быстрее, чем способность его объяснить.
-
Понимание перестало появляться само
Раньше, чтобы написать модуль, человек был вынужден его понять, и понимание оставалось побочным продуктом работы. Теперь код пишется сессиями. Сессия закончилась, и понимание закончилось вместе с ней.
Это не про качество кода. Проверка на качество здесь бессильна: код может быть хорошим, а объяснения не быть.
-
Люди меняются чаще, чем система
Продукт живёт пять и десять лет. Разработчик, подрядчик, технический директор сменяются за это время несколько раз. Каждый уход забирает часть картины, и никто не считает, какую именно.
Система остаётся, знание о ней уходит по частям.
Получается неприятная симметрия. Производство подешевело, понимание нет. Чем быстрее вы выпускаете, тем быстрее растёт та часть продукта, о которой никто в компании не может ответить ни на один вопрос.
#Разрыв растёт сам
Нарисуйте две линии от одной точки. Первая, сколько в системе всего есть: компонентов, интеграций, мест, где хранятся данные, задач по расписанию. Вторая, сколько из этого кто-то в компании может объяснить с указанием, где это видно. Первая линия разогналась. Вторая идёт со скоростью человека, который читает, спрашивает и запоминает, и эта скорость не изменилась.
Между линиями и живут все неприятные разговоры: due diligence, смена подрядчика, вопрос про персональные данные, оценка сроков.
У этого разрыва есть свойство, из-за которого его почти никогда не замечают вовремя: он не мешает работать. Продукт работает, команда на месте, задачи закрываются. Разрыв даёт о себе знать только в момент, когда кто-то снаружи задаёт конкретный вопрос. Поэтому его обнаруживают в худших возможных обстоятельствах: на переговорах, при передаче, во время инцидента.
Я вижу это на собственной разработке. 1ADK проверяется больше чем тысячей автоматических тестов, у него есть своя документация, и я написал его сам. И всё равно, когда я первый раз прогнал по нему собственный анализ, картина содержала вещи, которые я не смог бы назвать по памяти: зависимости между частями, которые я помнил иначе, и места, про которые честный ответ был «неизвестно». Если так у автора системы, у владельца, который её не писал, разрыв шире на порядок.
#Что расходуется, пока вы ждёте
Разрыв не берёт с вас денег напрямую, поэтому его нет ни в одной строке бюджета. Он расходует четыре других ресурса, и все четыре ограниченные.
- Время до решения. Любой вопрос, требующий знания системы, превращается в ожидание человека. Не в час работы, а в срок: до среды, до конца спринта, до возвращения из отпуска.
- Деньги за повторное выяснение. Каждый новый участник восстанавливает картину с нуля и делает это по полной ставке. Новый подрядчик, новый технический директор, новый аудитор, каждый раз заново.
- Свобода менять команду. Чем меньше вы понимаете, тем дороже смена исполнителя, и тем хуже ваша позиция в разговоре о цене. Зависимость редко выглядит как конфликт. Обычно она выглядит как согласие на условия, которые вы не стали бы обсуждать, будь у вас выбор.
- Доверие покупателя. Корпоративный клиент, инвестор и покупатель компании задают одни и те же вопросы и делают одинаковые выводы из ответа «нужно уточнить у разработчика».
Дальше полезно посмотреть на два сценария. Не в терминах катастрофы, а в терминах того, что реально произойдёт. Первый: ничего не делать, продолжать отвечать через людей. Второй: один раз получить проверяемую картину и поддерживать её.
| Момент | Оставить как есть | Разобраться сейчас |
|---|---|---|
| Через три месяца | Прибавилось несколько интеграций и фоновых задач. Список того, что работает по расписанию, существует только в чьей-то памяти. | Список есть, и видно, что в нём изменилось за квартал. Новые вопросы закрываются за минуты. |
| Через год | Сменился кто-то из ключевых людей. Часть решений теперь объясняется словами «так исторически сложилось». | Уход человека стоит времени на замену, а не стоимости восстановления картины продукта. |
| Крупный клиент с требованиями | Опросник по безопасности превращается в неделю переписки внутри команды и в осторожные формулировки. | На большинство пунктов отвечаете вы, с указанием, откуда это известно. |
| Смена подрядчика | Передача занимает месяцы и оплачивается дважды: уходящей команде за объяснения и новой за изучение. | Передаётся не только доступ, но и описание системы, которое новая команда может проверить. |
| Продажа или раунд | Технический due diligence находит то, о чём вы не знали. Цена обсуждается заново. | Вы показываете картину сами, вместе со списком известных слабых мест. Это другой разговор. |
Правая колонка не обещает, что проблем не будет. Она обещает, что вы узнаете о них первым и от себя, а не последним и от покупателя.
#Что с этим делать
Хорошая новость в том, что задача конечная. Вам не нужно понимать код. Вам нужно уметь получать ответы на вопросы бизнеса без единственного человека. Это измеримо, и к этому есть последовательность.
-
Выпишите решения, а не темы
Три или четыре решения следующего квартала, которые требуют знания системы. Поднять цену тарифа. Подключить корпоративного клиента с его требованиями. Поменять подрядчика. Вынести часть функциональности.
Тема звучит как «архитектура». Решение звучит как «можем ли мы пообещать хранение в ЕС к марту».
-
Превратите каждое решение в вопрос к системе
Не «расскажи про архитектуру», а «через какие сервисы проходят персональные данные клиента», «что сломается, если отключить старый платёжный провайдер», «что работает по расписанию и что заметит, если это остановится».
Вопрос, на который нельзя ответить одним предложением, обычно означает, что его ещё никто не задавал.
-
Проверьте, кто отвечает
Задайте эти вопросы так, чтобы ответ не приходил от одного человека. Найдите ответ в документации, в описании системы, в инструменте. Отметьте, сколько вопросов закрылось без звонка разработчику.
Это ваша текущая цифра зависимости. Её достаточно, чтобы понять, есть ли проблема.
-
Получите первую проверяемую картину
Описание системы, где у каждого утверждения видно, откуда оно взято, а у каждого пробела есть имя. Неизвестное должно оставаться неизвестным, а не превращаться в уверенный абзац.
Картина без ссылок на источник читается как документация и работает как слух.
-
Обновляйте её вместе с системой
Один разбор устаревает так же, как устаревала документация. Ценность появляется на втором и третьем, когда видно разницу: что добавилось, что исчезло, где стало хуже.
Повторный анализ отвечает на вопрос, который нельзя задать однократному: что изменилось, пока я не смотрел.
-
Измеряйте зависимость, а не объём документации
Плохая метрика: сколько страниц описания. Хорошая: какую долю вопросов о продукте вы закрываете без конкретного человека и за какое время.
Первая растёт сама и ничего не значит. Вторая двигается только когда что-то реально изменилось.
#Проверка на двадцать минут
Прежде чем что-то менять, полезно измерить, где вы находитесь. Возьмите лист и ответьте сами, не спрашивая команду. Важен не результат, а то, сколько раз вы поймаете себя на фразе «надо уточнить».
Шесть вопросов владельцу
Три «надо уточнить» из шести означают, что эта статья про вашу систему.
- Назовите все места, где оказываются персональные данные ваших клиентов, включая копии и внешние сервисы. Это первый вопрос корпоративного клиента и первый вопрос регулятора.
- Перечислите всё, что работает по расписанию, и скажите, кто узнает, если это остановится. Тихо остановившаяся задача обнаруживается снаружи и через несколько месяцев.
- Назовите внешние сервисы, от которых вы зависите, и что произойдёт при отключении каждого. Здесь находятся самые дорогие сюрпризы при смене поставщика или цены.
- Скажите, что изменилось в устройстве системы за последний квартал. Не в задачах и релизах, а в самой системе. Обычно этого не знает никто.
- Скажите, кто, кроме одного человека, может ответить на предыдущие четыре вопроса. Это и есть ваша зависимость, выраженная числом людей.
- Скажите, где написан ответ, если этого человека завтра не будет. Если ответ только в голове, у вас нет ответа. У вас есть человек.
#Что делают вместо этого
Заказывают большой технический аудит раз в год.
Вместо этого Аудит отвечает на вопросы того дня, когда его делали. Через квартал система другая, а отчёт тот же. Нужна картина, которую можно обновить и сравнить с прошлой версией.
Просят агента сгенерировать документацию и убирают её в общую папку.
Вместо этого Сгенерированный текст гладкий и неотличим от проверенного. Требуйте у каждого утверждения ссылку на то, где это видно, и отдельный список того, что установить не удалось.
Назначают ответственного за документацию.
Вместо этого Ответственный уходит вместе с документацией, и вы возвращаетесь в ту же точку. Ответственным должен быть механизм: описание обновляется от той же работы, которая меняет систему.
Решают разобраться перед следующим крупным событием.
Вместо этого Крупное событие это худший момент: на нём нет времени, зато есть чужие сроки. Разбирайтесь на спокойной неделе, когда цена ошибки равна нулю.
Считают, что достаточно спросить у ИИ-помощника, когда понадобится.
Вместо этого Спросить можно, и ответ будет разумным. Но второй раз ответ будет другим, сравнить их нельзя, и запись о том, какой из них был верен и когда, не остаётся.
#Чего это не решает
Понимание системы это условие хороших решений, а не сами решения. Стоит сказать прямо, чего оно не даёт.
Чего это не делает
- Оно не заменяет команду. Знать, как устроена система, и уметь её менять, это разные умения.
- Оно не делает решение правильным. Точный ответ про хранение данных не подскажет, стоит ли брать этого клиента.
- Оно не оценивает качество кода. Картина системы говорит, что есть и как связано, а не насколько это хорошо написано.
- Оно не отменяет доверие к людям. Цель не в контроле над разработчиком, а в том, чтобы разговор с ним был разговором двух сторон, у каждой из которых есть картина.
- Оно не бывает полным. Часть вещей останется неизвестной, и в честной картине они так и названы.
И последнее, самое важное. Вопрос не в том, хороший у вас код или плохой. Вопрос в том, сколько людей должно быть доступно, чтобы вы могли принять решение о собственном продукте. Если ответ «один», это и есть ваше ограничение, и оно не имеет отношения к тому, кто написал этот код: человек, подрядчик или агент.
Кто в вашей компании может сегодня ответить на все шесть вопросов из проверки выше, и что случится с этими ответами, если этот человек уйдёт в следующем месяце?