Что такое, как бороться и какие симптомы
Хвостовые риски в digital-проектах
Сибирикс
Хвостовые риски
в digital-проектах
Что такое, как бороться и какие симптомы
Владимир Завертайлов
CEO & Founder
Приходит мужик в баню, забыл полотенце, и шарит глазами по бане: чем бы вытереться. Видит, висит табличка: «Занавесками не вытираться!». Думает: «О, блин, идея!».


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

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

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

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

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

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

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

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


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


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


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

  1. в начале проекта всегда больше энтузиазма (энергии, драйва — как угодно), и сложности решать проще;
  2. чем раньше вылезут сложности и вопросы, тем больше времени будет принять по ним решение (можно будет увидеть прогресс потери времени, если используете Burn Down Chart или метод освоенного объема).
Это не всегда возможно, но стоит попробовать.


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

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


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


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

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


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

  • Попросить физический артефакт проверки (фото, документ, таблица), а не просто слова.

  • Задавать конкретные вопросы, о которых нет мнения (вместо «оплатил ли клиент?» спрашивать номер платежного поручения).

  • Повторять свой вопрос — это порождает сомнение. Например, «Ты положил макеты в нужную папку? Точно положил? В ту самую папку, где остальные хранятся?».
Экстренные меры, если могильник вскрылся посреди проекта
1. Проинформировать всех заинтересованных лиц о сложностях и согласовать решения
Например, включить описание проблем в еженедельный статус-репорт.


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

Екатерина
Исполнительный директор
Симптоматика хвостовых рисков

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

  • «потом», «в следующем спринте…», «когда получим доступы…» — либо сам менеджер так говорит, либо слышит это от исполнителей;

  • туман, отсутствие конкретики, байки;

  • «если бы…» — перекладывание ответственности с себя на других («если бы дизайнер нарисовал по-другому, клиент бы…»);

  • усреднение: как только начинается разговор про какие-то средние величины, про то, что в целом все хорошо — в целом, в среднем, в общем — это уже очень тревожный сигнал о том, что человек «зарывает хвост». Внешне у него всё хорошо, но никто не знает, какой у него могильник и сколько в нём спрятано. А если долго складывать в могильник проблемы, рано или поздно это всё вскроется и погребёт менеджера под собой.
Пример усреднения
Русская рулетка: каждому выжившему даётся по 1000 долларов. Эксперимент проводится на 1000 испытуемых. В среднем выигрыш составит 860 баксов. Если же испытуемый один, а выстрелов 1000? Проигрыш (и место в гробу) гарантирован.
Итого: даже простая легализация могильника делает проект управляемым. Шкура на кону, высокая квалификация, и акцент на сложных вещах работают еще лучше. Успехов!