Антихрупкость в IT: гипотезы вместо ТЗ

Знакомство ведущего и гостя случилось на конференции в Берлине, где большой круглый стол делился на сторонников монорепозитория и сторонников мелких репозиториев; гость до сих пор помнит, что стол оказался наполовину русскоязычным, и называет это кадром из прошлой жизни, когда до сообщества можно было доехать. О себе он рассказывает крупными мазками: двенадцать лет у него своя IT-компания на шесть-семь человек, которая ведёт продукт от слов «у нас проблема» до релиза на страну, плюс консалтинг, преподавание в университетах и бесплатное менторство на одной платформе. Вторую книгу, про карту гипотез, он только что забрал из типографии. Александр сразу выкладывает претензии: местами изложение слишком тезисно, в тизерной части ссылок на внешние ресурсы по три-четыре на страницу, а классификация заказчиков в первой главе явно неполная.

Ответ гостя прямой: книга написана не для Александра и не для таких, как он. Тимлиды и техлиды всё это прошли, а писал он для тех, кто ещё учится в университете, для новичков, которым нужно охватить широту профессии, и для слоя над IT — руководителей, владельцев бизнеса и инвесторов, которые смотрят на разработку издалека. Отсюда и глава о том, из-за чего проваливаются проекты: к нему приходят с «у нас готово на 95 процентов, деньги закончились», он открывает код и находит куски статичного HTML и что-то крутящееся внизу — систему даже не начинали. Из той же боли выросло кнопочное мышление: заказчик приносит решение, «добавьте вот здесь кнопку», вместо бизнес-цели, и команду используют как руки, а не как голову. Александр вспоминает своего заказчика, который, послушав про MVC, попросил сделать ему универсальный контроллер.

Impact mapping гость начал применять лет десять-двенадцать назад, через пару лет после книги Гойко, чью фамилию в эфире так и не выговорили; инструмент связывал цель со списком задач, и это было прекрасно. За годы работы к нему накопились уточнения: цель стоит описывать хотя бы по SMART, акторы — это не исполнители, а импакты лучше записывать как гипотезы в определённом формате. Объяснять одно и то же гость устал и решил дать переработанной идее новое имя — так появилась карта гипотез. Шаблон в Miro у него есть, но в каталог расширений он его так и не выложил и прямо в эфире зовёт слушателей сделать это за него, обещая похлопать в ладоши; база знаний по карте лежит на GitHub. Инструмент прост на вид и труден в заполнении, хотя двенадцатилетний сын знакомого составил по черновику карту для школьного проекта и защитился по ней.

Александр примеряет карту к своей работе: он отвечает за платформу продуктовой аналитики и часто видит эксперименты, к которым потом невозможно вернуться и понять, на что вообще надеялись. Гость уточняет, что его гипотезы — уровень стратегии, а не статистически значимых A/B-тестов. Из большой нефтянки ему говорят обратное: цели понятны, задачи расписаны на десять лет вперёд, а связки между ними нет, потому что мыслить гипотезами — это задом наперёд и трудно. Дальше участники проходят по функциональным местам процесса: OKR закрывают только целеполагание и игнорируют стратегию с тактикой, поэтому карта гипотез ложится сверху; CJM гость заменил на карту процесса опыта — гибрид CJM и service blueprint, подробно расписанный Андреем; user story mapping решили не трогать. Для системы управления складами международного ритейла простые инструменты не тянут.

Про антихрупкость первым вспоминает гость: она лежит в основе главы о ТЗ. Написать техзадание — значит попытаться законсервировать случайность, пообещав, что всё будет как написано, хотя оба собеседника знают, что это неправда. Снижение рисков идёт асимптотически: за одно и то же время риски падают на 75, потом на 83, потом на 85 процентов — как каждая следующая девятка надёжности. Владелец крупной ювелирной компании принёс гостю ТЗ страниц на семьсот-восемьсот, которое писали год и ещё год реализовывали, а бизнес-пользователи не смогли им пользоваться. Александр добавляет математику: полноту доказать нельзя, и вспоминает теорему о неполноте и попытку начала XX века вывести полную и непротиворечивую арифметику. Гость смеётся, что теперь будет отвечать ссылкой на теорему тем, кто просит оценку по ТЗ, — и ему просто перестанут писать. Но иногда ТЗ всё же нужно: между заказчиком и командой стоит прокси-менеджер, а то и два, от исполнителя не ждут ничего сверх задачи, или так велит регламент.

Смысл антихрупкости гость формулирует так: если бы изменений не было, не нужны были бы ни практики, ни архитектура — шлёпай новые функции; всё начинается с первой надстройки, и вопрос в том, становятся ли после изменений сильнее бизнес, люди, команды, процессы и архитектура. Он вспоминает, как после его доклада к нему подошёл человек из очень большой компании: если люди разом исчезнут, системы проживут около часа — считали по частоте инцидентов. К трём F гость добавил четвёртое: качество фиксируем всегда, иначе смена вектора стоит трёх-четырёх итераций и звучит как «скрам не работает», хотя дело во внутреннем качестве. Александр рекомендует книгу стэнфордского преподавателя, придумавшего алгоритм raft, гость — статью Фаулера о стоимости внутреннего качества. Ещё одна схема из книги — матрица осознанности и компетентности: людей нужно целенаправленно держать в осознанной компетентности, иначе проклятие знаний мешает передавать контекст. Заканчивают матрицей доверия и прозрачности: гибкий объём работ возможен только при высоком доверии, а растёт оно через стендапы, демо и привычку приходить с проблемой первым.