{"id":13582,"url":"\/distributions\/13582\/click?bit=1&hash=08f63613201fa572e9d042f45442e065ac99a64011290465240c71f90fc00f1a","title":"\u0418\u043d\u043a\u0443\u0431\u0430\u0442\u043e\u0440 \u0438 \u0430\u043a\u0441\u0435\u043b\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u044b \u0432\u0438\u0434\u0435\u043b\u0438, \u0430 \u0441\u0442\u0430\u0440\u0442\u0430\u043f-\u0441\u0442\u0443\u0434\u0438\u044f \u2014 \u044d\u0442\u043e \u0447\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"acb6f58f-ce2f-51d0-96cb-c256b9565a70","isPaidAndBannersEnabled":false}
Карьера
Aleksandr Stikharev

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

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

Анастасия Алдохина

Экспозиция

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

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

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

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

Завязка

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

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

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

Анастасия Алдохина

Кульминация

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

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

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

Анастасия Алдохина

Развязка

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

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

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

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

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

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

Анастасия Алдохина

Эпилог

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

  • Не сваливать всё на проджекта. Он мониторит общий процесс работы, но решение задач лежит на исполнителях. Найти пруфы для гипотезы — задача маркетолога, дополнить очтёт — аналитика, подлатать интерфейс — дизайнера. Отвечают за это они, а не менеджер: так мы его разгружаем, чтобы освободить ресурс на своевременные чекапы.
  • Держать задачи на виду. Мы пользуемся классической эджайл-доской, и для таких задач есть своя метка. Команда знает, что задачи с этой меткой откладывать нельзя. Штаб позволяет задать карточке приоритет — здесь пригождаются «критический» и «срочно». Самые важные задачи отправляем в верх списка, чтобы о них точно не забыли.
  • Ставить жёсткие сроки. Сложные задачи не откладываются. Если их не получается закончить к дедлайну, в следующем спринте они прорабатываются в первую очередь.

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

Анастасия Алдохина

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

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

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

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

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

То, что создают люди, не ставя свою шкуру на кон, будет усложняться (пока в конце концов не рухнет).

Нассим Талеб

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

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

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

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

Анастасия Алдохина

Мораль

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

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

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

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

0
3 комментария
Veta Rime

Было, справились. Самым ретроградным способом: понесли убытки и переделали как надо за дополнительное время. Проект был акцией в магазине, и мы тупо неправильно просчитали количество товаров и логистику. Обнаружили прямо перед запуском, перенесли, чтобы нормально подготовиться. 

Ясное дело, что так можно не всегда, но после прочтения статьи хочется на всякий случай выбросить стикеры 

Ответить
Развернуть ветку
Mercator

Вы тупо неправильно посчитали. Это совсем не про задачи-убийцы, которые откладывают на «когда-нибудь потом», потому что их непонятно как или долго делать.

Ответить
Развернуть ветку
Mercator

Статья хорошая, но очень не хватает конкретных примеров.

Ответить
Развернуть ветку
Читать все 3 комментария
null