Как работать с бэклогом проекта, чтобы не было больно после релиза

Захватывающая история о задачах-убийцах: тех, что таятся во тьме, всплывают в последний момент и рушат проект до основания.

Представим типичный IT-стартап. На очередном этапе развития он генерирует идею золотоносного продукта, собирает нужную инфу и готовит MVP.

Он, конечно, не без дыр. UI предстоит подрихтовать, аналитик не учёл часть данных, как реализовать отдельные задачи — неясно.

Команда воодушевлена и пока не думает о деталях. Менеджер бережно хранит их на стикерах, приклеенных к монитору, или на странице личного блокнота.

Аудитория встречает MVP продукта, как Виндзоры — сына Гарри и Меган. Команда увлечённо пришивает «младенчику» дополнительные ноги, руки, хвосты и усы, а потом приводит в приличный вид и учит пользоваться пришитым.

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

Спойлер: этих ребят серьёзно недооценивают. Они, тем временем, обретают важность и растут в числе.

Команда допиливает и продаёт продукт, радуется успеху. Для неё работа выглядит оконченной. Но для покупателя она только начинается: тест продукта на реальных пользователях формирует список дополнительных тасков, в котором новые идеи и улучшения чередуются со старыми знакомыми менеджера со стикеров.

В этот момент задачи становятся убийцами: обойдутся дорого по деньгам и времени, наверняка испортят отношения в команде, потребуют серьёзной переделки продукта.

Талантливый менеджер в таких обстоятельствах забирает плюшки и рисует сквозняк: увольняется, меняет проект или хотя бы уходит в отпуск. Команда не ждёт плохих новостей: у ребят дофамин, они разработали нужный рынку продукт и отправили его в жизнь. А недочёты в дизайне и костыли в коде так и остались за скобками.

На этом этапе герои сначала страдают. Клиент — от сыроватого продукта, который не спешат дорабатывать; команда — от лавины правок вместо похвал; менеджер, если не убежал, — от неизбежности работы над тем, что всю дорогу не нравилось. Сам продукт тоже под угрозой: неизвестно, хватит ли бюджета и других ресурсов, чтобы довести его до ума.

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

Даже если всё пройдёт по лучшему сценарию (менеджер не сбежал, бюджет не в минусе, кризис все пережили), команда закономерно демотивируется, кто-то может уйти. Это болезненный опыт, который приводит к сомнениям в руководстве и целесообразности дальнейшей работы.

Ни один человек не захочет это повторять, и вопрос о продолжении работы с командой решается из опоры на два фактора: морали и лояльности. От морали зависит, согласится ли исполнитель исправлять косяки после релиза, ещё и, с некоторой вероятностью, за пониженную ставку. От лояльности — поверит ли он, что этот случай — ошибка и исключение, решится ли дать компании ещё один шанс.

В итоге, конечно, никто не умрёт: клиент найдёт способ выкрутиться, исполнителей можно нанять, менеджера — заменить. Но осадочек останется. У всех.

Нам страховаться от задач-убийц помогает Штаб, в котором менеджерятся задачи, и небольшой регламент:

Чит посложнее — устойчивая команда. Если постараться и сплотить её вокруг продукта, вероятность того, что кто-то захочет его бросить после релиза, упадёт. Делать это можно через личную ответственность (система KPI и бенефитов за успехи), через регулярные неформальные митапы по продукту (у нас они с пиццей и другими прелестями жизни), через сильный HR в компании.

Студия «Сибирикс» предлагает ещё несколько хороших фишечек.

Стратегические:

1. Уделять больше внимания сложному, чем простому. Когда появляется непонятная задача, лучше немедленно пойти об неё учиться, а не складывать в папку «потом». Такая расстановка приоритетов сокращает число задач-убийц, а то и вовсе избавляет от них.

2. Задавать вопрос «зачем я это делаю». Как можно чаще. Особенно — по поводу мелочей, которые должны поддерживать крупные куски продукта.

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

Тактические:

1. Открыть доступы. Хранить задачи категории «когда-нибудь потом» не на стикерах, а на доске проекта в таск-менеджере, например. Сделать так, чтобы они с самого начала были у команды на виду и не превратились в убийственно неприятный сюрприз.

2. Начинать со сложного. В начале команда обычно работает энергичнее, поэтому шансов безболезненно решить нерешаемое тоже больше. Чем ближе конец спринта, тем меньше сил и мотивации браться за что-то мудрёное.

3. Проверять результаты вручную. Звучит как отрицание автоматизации, но нет. На то, чтобы несколько раз проверить работу каждого исполнителя и переспросить его, всё ли он сделал по брифу и стандартам, уйдёт время. На то, чтобы найти такие мелкие ошибки и исправить их, когда продукт из MVP превратится в вундервафлю, уйдёт гораздо больше времени. И денег. И нервов.

С неожиданно всплывшими старыми задачами тоже можно справиться. Шансы преуспеть значительно вырастут, если следовать двум правилам.

1. Рассказать всё команде ASAP. И обсудить решение, чтобы сложилась понятная общая картина. Важно, чтобы каждый понимал, что делать.

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

Задачи-убийцы могут выскочить на вашу тропу к благополучию, даже если вы сделали всё, чтобы этого не допустить. Так в принципе работают риски. А если такое уже было и вы справились — напишите в комментариях, как: проблема ещё долго не устареет, хорошие решения пригодятся.