Тимлиды и команды в больших компаниях постоянно сталкиваются с одной и той же проблемой: бизнес хочет знать сроки, а разработка не может их назвать. Оценки «пальцем в потолок», спринты без delivery, злые заказчики и выгоревшие разработчики — знакомо?
«Три карандаша» — это метод инженерного груминга, который я разработал в боевых условиях и который сейчас стал частью стандарта разработки в Газпромбанке. Суть простая: вы берете доску, три цветных маркера и за два часа превращаете размытые бизнес-требования в понятный план работ с реалистичными сроками. Он подходит для любых задач: фронтенд, бэкенд, data science, интеграции. Если вы можете разложить работу на логические шаги — вы можете использовать три карандаша.
Всем привет. Меня зовут Рустам Файзулин. 30 лет BE- и data-science-разработчик, последние семь лет работаю коучем в Газпромбанке. Моя задача — сделать так, чтобы разработчики понимали, что надо сделать, а бизнес понимал, когда он это получит. Дальше расскажу, как родился мой метод, как он устроен и как внедрить его у себя.
Почему классический груминг ломается в большом бизнесе
Если вы — маленькая команда энтузиастов в папином гараже, у вас десять технологий, пять человек, и все уже побывали в коде друг у друга. Вы прекрасно понимаете бизнес-идею, потому что сами же ее и придумали. Ситуация меняется, когда вы попадаете в энтерпрайз.
В крупном банке может насчитываться свыше 600 автоматизированных систем, используется больше сотни технологий. Людей, способных охватить такую картину целиком, вообще не бывает. А еще очень непростая бизнес-логика, которая может кардинально поменяться с выходом одной-единственной инструкции ЦБ, — и вот вам надо срочно менять двигатель у летящего самолета.
На это накладывается то, что называется «законом Вавилонской башни в IT». Разработчиков уже бомбит от слова «созвониться», и мы общаемся через артефакты. Кто-то что-то написал, добавил пару слов в комментарий и отправил дальше. На каждом этапе теряется информация. В результате система получается не совсем такой, как задумывалось. А если разработка еще и параллелится на разные автоматизированные системы — добро пожаловать в ад под названием «интеграция».
Как это было: рождение метода
Далекий январь 2018 года. Меня попросили помочь разобраться с проектом, который уже год как горел. Атмосфера соответствующая.
Как изначально считали сроки? Стандартным способом: берешь бизнес-требования, распечатываешь, разбираешь на главы, раздаешь разработчикам, получаешь от них оценки. Дальше наступает классическая магия, которую использует любой грамотный техлид: выстраиваешь работы по порядку, находишь критический путь. Получившийся срок умножаешь на два и добавляешь корень из пи (ибо какой же ты инженер, если не добавил корень из пи)?
Получился август 2018-го. Люди от заказчика подходили и говорили: «Назови любые сроки. Любые. Ты уверен, что август?» Я думал: на два умножил, корень из пи добавил, чего вы еще хотите? В августе пойдем в отпуск (до сих пор мем на некоторых проектах).
Ладно, надо запускать проект по уму. Повесили огромную доску, разлиновали, налепили стикеры, запустили ламповый скрам. Народ подходит, стикеры передвигает. Проходит две недели — поставки нет. Смотрим на схему — вроде должна быть поставка. Смотрим на результат — поставки нет. Запускаем следующий спринт. Проходит еще две недели. Дейлики, стикеры — поставки снова нет.
Понятно, что так продолжать нельзя. Сношу все с доски. Такой Скрам народу не нужен. Говорю команде: отойти от компьютеров, увижу кого-нибудь клацающего — уволю сразу! Собираю всех у доски и начинаем разбираться с самого начала.
Черные маркеры для белой доски к тому моменту закончились. Остались только синий, зеленый и красный (отсюда и название — «Три карандаша»). Начинаем рисовать клиентский путь.
Рисую первый пользовательский экран. Что с ним? Написали, протестировали, сдали. Отлично! Рисую синим.
Второй экран — то же самое, рисую синим.
Третий — это экран, разводящий на разные сценарии. Поехали по первому сценарию. Сдали? Отлично, синий.
Второй сценарий только начинаем делать. Спрашиваю: первый экран — вы знаете, как его делать, не знаете, как его делать, или он уже сделан? Три состояния, больше быть не может. Говорят: знаем. Рисую зеленым. Что дальше? Тоже знаем. Мамой клянутся.
Третий сценарий. Первый экран — знаем, рисую зеленым, остальные — не знаем. Рисую красным.
Начинаем второй проход по экранам. К каждому экрану задаю три вопроса:
Что нужно, чтобы все заработало?
Что будет происходить, когда пользователь что-то делает?
Что произойдет, когда пользователь уйдет с экрана влево или вправо?
Работы на фронте рисую посередине, рядом с экранами. Работы на бэке, которые нужны для этого, — внизу. То, что надо получить от внешних систем, — наверху. Никаких типов и длин полей, никаких наименований переменных. Просто: вызов метода существует или не существует. А сам метод существует или надо писать с нуля? Ну, и цвета для методов по той же схеме: существует — синий, делаем и знаем как — зеленый, ничего не понимаем — красный.
Вот эту первую дорожку — то, что ребята уже сделали, — мы разбирали до обеда. И, что неудивительно, у разработчиков оказались совершенно разные представления о том, как первый сценарий был реализован. После обеда перешли ко второму сценарию. Клятвы на маме не помогли: выяснилось, что знают не всё. Всплыла куча подробностей реализации, вызовы внешних сервисов, много того, о чем, может, даже и было написано в системном анализе, но либо не прочитали, либо забыли, либо анализ поменялся, когда уже разработка шла. В общем, много любопытного всплыло. Красного было существенно больше, чем я скромненько тут на презентации нарисовал. На проработку третьего сценария ушел весь второй день — мы прогрызали этот клиентский путь, отвечали на вопросы, звали «соседей», уточняли с ними реализацию. Перекрашивали красное в зеленое.
Дальше была очень простая магия. У нас есть полностью реализованный первый сценарий. Мы его разобрали на экраны, оценили каждый по сложности и добавили наши знания по срокам выпуска каждого экрана и сервиса. Брали данные из Git. В результате получили линейку и точку отсчета. Потом проделали то же самое со вторым и третьим сценариями и каждый экран приложили к линейке и оценили. Посчитали новую дату. Оказалось — январь 2019 года. Получили двоякий результат. В моменте, когда мы озвучили новую дату, заказчик счастлив не был, — ему уже пообещали август, он на это заложился. Но зато мы попали в третью неделю января. Сдали, как пообещали. И более того, мы запустили Скрам заново и стали поставлять строго по расписанию. Спринт — поставка! Т. е. Скрам обрел смысл!
Анатомия метода: шаблон и три цвета
После того проекта я стал применять подход на других проектах — и постепенно сформировалась технология. Все, что вам нужно для старта, — это клиентский путь, доска и три маркера.
Шаблон
Доска шаблона делится на три горизонтальные зоны.
Наверху — внешние зависимости. Все, к чему нужно привлечь смежные команды. Держи друзей близко, врагов еще ближе: чем выше, тем заметнее. Красный стикер тут должен сиять, как звезда на елке. Если вы не договоритесь со смежными командами — никуда не поедете.
Посередине — клиентский путь. Экраны, с которыми взаимодействует пользователь, или шаги бизнес-логики.
Замечание специально для тех, кто скажет «а вот у нас нет пользовательских интерфейсов, мы, например, дата-сайентисты, или ETL-щики»: так вот, специально для вас новость года! — у бэка тоже есть клиентский путь. Все, что от вас требуется, это записать по-русски: «вытащить данные», «рассчитать средние остатки», «посчитать рейтинг» и так далее — эти шаги точно так же ложатся на шаблон, только не в виде экранов, а в виде карточек соответствующего цвета.
Внизу — ваш бэк. То, где у вашей команды есть руки и вы можете делать что хотите.
Три цвета
Синий — для того, что уже существует. Написано, протестировано, работает. Мы используем это «как есть».
Зеленый — обозначает, что мы знаем, как сделать. Команда здесь и сейчас договорилась: бэк с фронтом согласовали, тестировщик уже задал вопрос: «А что будет, если эта штука сломается?» Кстати, если тестировщик молчит на груминге, — это проблема. Учите его говорить! Это называется тестирование требований. Шаг номер один на вашем пути в shift left.
Красный — мы этого не знаем, надо исследовать. И вот тут критически важное правило: никогда не оставляйте красные карточки просто с вопросом. Всегда назначайте ответственного и дату. Иначе вся схема зарастет красным, и вы никуда не сдвинетесь.
Принцип необходимости и достаточности
На этом этапе вам не нужен атрибутивный состав. Не нужны названия переменных и длины полей. Нужно понять суть работы: это физически существует или не существует? Нам надо дописать, перегрузить метод, сделать новый интерфейс? Вы сравниваете сложность работ между собой, а детали — потом.
Три вопроса и трехзвенка
Метод опирается на два фундаментальных принципа, которым уже почти семьдесят лет.
Трехзвенная архитектура. Состоит из трех слоев: слой представления данных, слой обработки данных, слой хранения данных. Все. Для груминга этого достаточно.
Жизненный цикл интерфейса. Нас интересуют три состояния: инициализация интерфейса, работа пользователя на интерфейсе, выход из интерфейса по логике вперед (вправо) или назад (влево).
Отсюда — три вопрос�� к каждому элементу схемы:
Что нужно, чтобы интерфейс поднялся? Какие данные и откуда подтянуть? Как они должны отобразиться в интерфейсе?
Что происходит, пока пользователь работает? Какие контролы и как должны отрабатывать? Где должны сохраняться соответствующие данные?
Что должно произойти с данными при переходе пользователя (сценария) дальше, влево или вправо?
Проходите слева направо по интерфейсам, задаете последовательно эти вопросы к каждому, рисуете вызовы в бэк. Вверх — к внешним системам, вниз — к собственным. Рядом с каждым сервисом обычным русским языком пишете суть работы: «пробросить дополнительную переменную», «добавить новый эндпойнт» и т. д. Для команды разработки, для оценки сложности на этом этапе проработки задачи такого уровня погружения более чем достаточно. Точный атрибутивный состав возникнет потом, на этапе разработки. Когда аналитик вместе с фронтом, бэком и тестировщиком составят контракт. А сейчас достаточно понимания, что у вас есть (или нет) набор сервисов, который обеспечит всеми необходимыми данными ваш клиентский путь. Причем если вы в этом не уверены, то смело клейте на сервис красную карточку. И пока не вызовите его, например, в Postman и не убедитесь, что он именно такой, как вы про него думаете, вы не красите его ни в зеленый, ни в синий цвет. Тут тоже надо соблюдать меру. Не стоит превращать быструю диагностику в полноценное исследование.
И если сервис внешний, то ОБЯЗАТЕЛЬНО позовите смежников! Они должны быть в курсе, что скоро вы придете к ним с запросом на доработку. Они должны быть к этому готовы и только они могут дать вам ответ по сложности и срокам доработки с их стороны.
Правила проведения
Время — до двух часов на одну встречу. Когда вы начнете регулярно грумить, декомпозировать и оценивать ваши эпики, как и положено в гибких технологиях, и будете закладываете на это до 10% рабочего времени команды, то два часа — это даже слишком. В Газпромбанке мы устанавливаем расписание по схеме «три раза в неделю по часу». Если команде не хватает этого времени, она может добавить еще две встречи по часу. До тех самых 10% времени. Этого хватает для поддержания бэклога на уровне «мы точно знаем, что сделаем в квартал», «мы точно знаем, что сделаем в следующие два спринта». Время на планирование двухнедельного спринта сокращается с четырех часов до тридцати минут. Еще один практический совет — ставьте эту встречу на утро, сразу после дейли. Утро очень хорошо подходит для творческой работы. Это особенность человеческой физиологии.
Кого звать: владельца продукта или бизнес-аналитика (готовит канвас с клиентским путем), представителей бэка и фронта, тестировщика и — если есть внешние зависимости — кого-то толкового и договоропригодного из смежной команды, способного рассказать, как у них устроено на самом деле и с кем можно договориться о доработках внешнего сервиса.
Результат — это не просто схема, а blueprint. Готовый план работ, который можно нарезать на задачи и оценить.
Главное: сначала рисуем сх��му командой, а потом пишем необходимые документы, бизнес-требования, системные требования, архитектурное решение и т. д. А не наоборот. Раньше мы брали аналитика и вкидывали его в задачу: «Вернешься с требованиями — мы напишем по бумажке». Теперь наоборот. Нет такого аналитика, который знает 600+ систем. А так знания собираются со всей команды сразу.
Про оценки: почему это работает
Отдельная история — как самокалибруются оценки сложности — на данных команд Газпромбанка.
Когда мы только начинали внедрять Три карандаша в стримах Газпромбанка, график «сторипойнты vs время выполнения» выглядел как облако. (см. график). По сути — палец, пол, потолок. Постепенно, со временем, стал образовываться коридор — оценки начали попадать в какой-то диапазон. А когда технология созрела, появился предсказуемый спред: чем дальше горизонт, тем шире, но в понятных пределах. Сторипойнты заработали и стали ценными с точки зрения прогноза. Команды сами созрели до того, что истории по одной, две, три и, так и быть, пять — это хорошие, а вот восемь уже напрягает, а 13+ — это уже русская рулетка, ну на фиг, декомпозируем!
Кроме того, проявился еще один интересный феномен, о котором в свое время писал и говорил «дядя Боб» Мартин, а именно понятие «инженерной бесконечности». Вот как это выглядит. Среднестатистический разработчик уровня middle или middle plus способен адекватно спрогнозировать свою работу максимум на два рабочих дня, все, что больше, — «инженерная бесконечность». Если он говорит «мне нужно два дня» — можно верить. Если говорит «пять дней» или, не дай бог, «две недели», и он объяснил, как нарезал эту работу на куски не больше двух дней и как он их сшил, — все это значит только то, что ему страшно, он не понимает, как делать задачу, и потому заложил весь спринт на «авось пойму». Помогите ему разобраться и декомпозировать.
За всю свою 30-летнюю историю разработки я встретил только трех инженеров, которые могли спрогнозировать работу на две недели. Они декомпозировали на автомате в уме!
Что мы получили
Time to market в стриме упал с девяти месяцев до полутора. Будем честны, далеко не только из-за Трех карандашей — мы параллельно прокачивали инженерные практики, поднимали девопс, развивали практику квартального планирования. Но благодаря каскадному грумингу и декомпозиции команды научились оценивать, выделять главное. Брать в спринт то, что реально могут сделать, и попадать в сроки.
Предсказуемость выросла с 30% до 90%. Когда вы попадаете в оценки на 90%, бизнес перестает закладывать буферы «на всякий случай» и начинает вам доверять. А доверие — это совсем другой разговор про бюджеты и приоритеты.
Качество архитектуры — отдельный бонус. Когда вы договариваетесь о реализации в самом начале, всей командой, — становится практически невозможно накостылить.
Разгруженный техлид. Команда сама видит сложности, сама погружается в контекст. Уходит «детский сад» разработчиков-кодировщиков: «Пока мне аналитик не написал, каким пальцем какую клавишу давить, я ничего делать не буду».
Удовлетворенность — по результатам CSI бизнес стал довольнее на 43%, команды — на 25%.
Частые вопросы и воз��ажения
Это же waterfall?
Нет. На этапе Трех карандашей мы даем высокоуровневую оценку сложности. Создание детальных артефактов, договоренности, разработка — все это стартует, когда задача взята в работу. До этого момента это еще гипотеза. Владелец продукта смотрит на оценку и может сказать: «Сколько-сколько? Давайте переделаем». Это все еще проработка гипотезы, а не обязательство команды.
Кворум большой, много человеко-часов
Давайте начнем с того, что для получения хорошо проработанного бэклога команде требуется до 10% всего рабочего времени команды. Таковы правила игры в гибкие технологии. Так вы управляете неопределенностью.
На старте внедрения Трех карандашей собирайте всех. Когда команда обучится, можно работать подгруппами. Если нет совместных зависимостей, не надо тащить всех на каждый груминг. На дейлике говорите: «Мне нужны вот эти четверо», остальные пусть работают. Но и тут есть нюанс! Раньше, когда мы все сидели в одном офисе и четверо что-то обсуждали у доски, остальные это слышали. По-научному это называется osmotic communication. В результате все были плюс-минус в курсе всего происходящего в комнате. Сейчас мы сидим по домам, и если не подключился к встрече, то ничего и не узнаешь. Наверное, это единственный случай, когда я приветствую мультитаскинг на встрече. Приходи, работай, слушай вполуха. Если это не мешает работать, то тут скорее польза, чем вред.
А если на пятом экране выясняется, что надо переделать первый?
Если мы на этапе груминга, то мы все еще на этапе проработки гипотезы и ничего не теряем. Если мы пошли в реализацию, уже выпустили четыре экрана и понимаем, что для пятого надо переделать первый, — ну что ж, подобное бывает, но редко. Такие ошибки уходят в ту самую погрешность 5–20% — мы целимся в 80%+ предсказуемости, а не в 100%. Если вы мыслите потоком ценности, где любая задача — это гипотеза, то 80% точности вас более чем устроят.
Как это дружит с User Story Mapping, CJM, INVEST?
Прекрасно дружит. CJM и User Story Mapping — это то, что приносит владелец продукта на вход. Это бизнес-путь. А Три карандаша — инженерный перевод этого пути на язык реализации. INVEST применяется, когда вы нарезаете blueprint на конкретные истории.
Как начать
Есть такая концепция SHU-HA-RI. SHU — точно повторяете, HA — добавляете свое, RI — создаете полностью свое. Я настоятельно рекомендую начать с SHU.
Выберите фичу следующего квартала или ближайшего спринта.
Соберите состав: владелец продукта, бэк, фронт, тестировщик. Если есть внешние зависимости — позовите кого-то из соседней команды.
Возьмите доску и три маркера. Физические или в Holst — неважно.
Забронируйте два часа. Не больше.
Идите слева направо по клиентскому пути, задавайте три вопроса к каждому шагу, рисуйте вызовы вверх и вниз.
Красное — с ответственным и датой. Без исключений.
Команды, которые уже освоили метод, проводят такие сессии за час-полтора. У нас в банке забито время: вторник, среда, четверг — по часу на PBR. Понедельник и пятница заняты церемониями спринта. Да и поработать тоже надо.
Еще один момент, к которому мы пришли, это деление PBR на две части — бизне�� и инженерную.
В командах, которые только начинают адаптировать у себя Три карандаша, владелец продукта, бизнес-аналитик, дизайнер, а также часто системный аналитик и техлид могут собираться «узким кругом» для проработки клиентского пути, подготовки экранов, декомпозиции большой идеи на эпики на уровне бизнес-ценности. Вот тут очень хорошо работают такие инструменты, как CJM — клиентский путь, USM — карта пользовательских историй, INVEST — критерии хорошей пользовательской истории. Их задача — уже на этом уровне выделить минимальную клиентскую ценность, оформить ее в виде шаблона инженерного груминга, описать формулу (я как <роль> совершаю <действие>, чтобы <что>), описать критерии приемки и ограничения эпика (он же бизнес-контекст). После такой подготовки эпика владелец продукта или бизнес-аналитик готовы идти в команду и стартовать Три карандаша. Часто уровень проработки эпика на бизнес-груминге регулируется командным Definition of Ready.
Команды, которые уже освоили и адаптировали под себя Три карандаша, могут не ограничиваться инженерной частью груминга, они начинают постепенно вовлекаться и в бизнес-груминг. А совсем продуктово развитые команды начинают ходить в Гембу — смотреть, как в реальной жизни пользуются продуктом, который они пишут, и на основе этого предлагать очень толковые улучшения продукта. Вот такие команды для любой организации уже на вес золота!
Главное — не бойтесь красного цвета на схеме. Это те проблемы, которые вы увидите и урегулируете уже сейчас, а не встретите внезапно в середине спринта. Лучше знать о них заранее. Помните, что красная карточка — это всегда: Вопрос, Ответственный, Дата — когда посмотрим на результат поиска ответа. Обычно это следующий груминг.