Хвостовые риски в digital-проектах

Что такое, как бороться и какие симптомы

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

Допустим, вы выпускаете какой-то MVP вашего продукта/сайта/приложения, который готовы отдавать на растерзание пользователям. Вы уже построили гипотезы, согласовали примерный объем работ, примерно понимаете продукт, который вам нужно выпустить, — разобрали его на спринты и стартовали разработку. Сделали первый спринт, второй, третий: MVP готов.

Вы запустились, и все счастливы: пользователи приходят, вы смотрите, тестируете какие-то гипотезы — все хорошо и правильно.

Но на каждом проекте перед спринтами есть какая-то предыстория: аналитика, дизайн и всё прочее. И вот там бывают какие-то ошибки, недоделки — может быть, где-то аналитик что-то недодумал и просто оставил какие-то непонятные «дырки» или неконкретные требования (в ТЗ, в бэклоге).

Эти «дыры» всплывают, например, когда идёт планинг — кто-то может сказать: «ребята, ваши требования — г-но» и потребовать уточнений. А вместо уточнений менеджер заводит своего рода «могильник», куда отправляет все задачи из разряда:

Могильником пованивает. Лезть в него и разбираться ну, очень не хочется. Но рано или поздно с ним придется что-то делать.

Допустим, у нас заказная разработка. Вы говорите клиенту «Ура, все готово!». Подразумевая, что готово все интересное, большое, героическое и понятное. Только там кое-что нужно будет сделать при деплое... (настроить платежи на боевом сервере, например, или родить на страницу «о нас» текст, получше чем «мы молодая динамично развивающаяся компания»). В итоге к концу трёх спринтов вылезает дополнительный скоуп работ, которые неравномерно размазываются по времени, и конца ему не видно. А к изначально «успешному» по времени и бюджету проекту (студия заработала денег, клиент доволен сроками, менеджер — красавчик) прилетает еще пачка гадких задач, сжигающих весь бюджет, сроки и отношения.

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

Что в этот момент делает умный, но хитрожопый менеджер? Сваливает в отпуск, на больничный или насовсем. Главное — получить свои бонусы до того, как могильник раскопали. И быть вне зоны досягаемости в этот момент.

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

Потенциально «бабайка» может возникнуть на любом проекте. Но даже если она там появится, хороший менеджер не позволит ей превратиться в бомбу замедленного действия. Что для этого можно сделать?

1. Повышать квалификацию

Чаще всего «бабайки» выползают, когда не хватает знаний и навыков. Мы откладываем что-то в сторону, если не знаем, что с этим делать. Более зрелое поведение — действовать с точностью до наоборот. Я чего-то не знаю — значит это повод разобраться. Обязательно стоит прокачивать и себя, и других.

2. Легализовать могильник

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

3. Сложные задачи — в начало

Рекомендуем в первые спринты разработки брать самые сложные задачи. Мотивация:

Это не всегда возможно, но стоит попробовать.

4. Шкура на кону (по Н. Талебу)

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

Когда менеджер сам отвечает за проект, сам горит за него и нацелен довести его до конца, а не просто получить медальку — вот тогда шансы на успех проекта значительно выше. Очень хорошо это ложится на scrum, когда вся команда участвует в демке спринтов, рассказывая, что и как было сделано. И получает прямую обратную связь.

5. «А не херню ли я делаю?»

Вопрос, который надо задавать себе почаще. Если поймали себя на этом — значит, скорее всего, «бабайка» уже рядом.

6. Метод «Приблизиться к оленю» (по В. К. Тарасову)

Представим ситуацию: охотник хочет убить оленя — прицеливается, но стреляет мимо. Какие последствия? Во-первых, падает его репутация среди других охотников. Во-вторых, страдают материальные ресурсы (одну стрелу уже потерял). В-третьих, он останется голодным. А всё потому, что он был от этого оленя далеко. Чтобы гарантированно убить оленя, нужно приблизиться к нему на такое расстояние, где ты точно не ошибешься.

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

Как побудить другого человека проверять выполнение задачи так же тщательно, как ты сам?

1. Проинформировать всех заинтересованных лиц о сложностях и согласовать решения

Например, включить описание проблем в еженедельный статус-репорт.

2. Спланировать очередность решения проблем

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

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

Итого: даже простая легализация могильника делает проект управляемым. Шкура на кону, высокая квалификация и акцент на сложных вещах работают еще лучше. Успехов!