В начале текущего года наша команда начала работать над новым продуктом компании. Новый продукт- это всегда вдохновляет: новые роли в команде, новые технологии, новые подходы. Возможность не совершать ошибок, с которыми уже сталкивались раньше. Новый проект- это отличная возможность проявить себя, улучшить процесс создания его создания и выпустить на рынок действительно ожидаемое решение. В этом после я хотела бы поделиться теми трудностями и проблемами, которые у нас возникли в первые полгода работы.
Новый продукт. Цель и начальные условия
Наша цель была создать продукт для уже поделенного рынка (работа с отчетностью). Продукт- это современное веб-приложение, выдерживающее высокую (сотни тысяч клиентов) пиковую нагрузку, обладающее множеством киллер-фич и идеальным UX. Амбициозно, не правда ли?
Особенности:
- У компании уже есть аналогичное решение, которое достаточно давно на рынке, по которому ведется разработка. Новый продукт должен его заменить.
- Достаточно специфическая предметная область. Значительное кол-во отчетов, из которых только часть требуется регулярно, а другая часть тоже нужна, но реже.
- Нет ТЗ в классическом виде, есть только начальный road map готовности продукта к основным датам. В качестве источника требований может выступать законодательсво и ресурсы, его трактующие.
- Да, есть жесткие сроки.
- Как оказалось позже, исторически сложившийся неверный портрет пользователя.
Команда:
- Распределенная географически команда (около 30 человек),
- Разные сроки старта работы команд с продуктом,
- Команды состоят из аналитиков, разработчиков, тестировщиков и дизайнеров. У всех сотрудников различная квалификация.
- Нет PO.
Возможности:
- Отсутствие ресурсных ограничений,
- Прямое подчинение Топ-менеджерам компании,
- Получение поощрений за выполнимую работу (материальную и нет).
Обязанности:
- Каждые две недели проводить демо реализованного функционала,
- Выполнять работу в соответствии с указанными сроками,
- Реализовать возможность максимального быстрого создания новых отчетов не членами продуктовой команды, а лучше- не разработчиками.
Поехали…
Конечно, начало проекта окрыляет любого, тем более у текущей команды был опыт создания и выпуск продуктов релиз. Естественно никто не думал, что на новом продукте наш любимый масштабированный Scrum на 2 команды с наличием PO не сработает, если все масштабирование апроксимировать на 4 команды без РО. Не сработало. С какими же проблемами мы столкнулись через несколько месяцев работы.
Проблемы и как мы их решали:
- Команде не нравится трекер (ТФС), это регулярно обсуждается. Одна проблема заключается в том, что никто не хочет с эти трекером работать. Создавать таски- это не продуктовый код писать. Остались в ТФС, доработав карточки ЮС, одна команда работает с трекером в виде скрам-доски. На стабилизационные недели перед важными датами создавали доску в трелло, где фиксировали только важные проблемы к релизу.
- У команды не было понимания цели проекта, цели итераций, цели реализации конкретной ЮС. Было потрачено время на грумминги функционала, который (как выяснилось позже) не входит не в MVP, не в MVP10. Создали RoadMap совместно с менеджерами проекта.
- Много груммингов, планирований, различных мероприятий, на которых некоторые участники скучали. Что сделали: поделились на команды первый раз, однако такое деление оказалось нежизнеспособным, как мы поймем через несколько месяцев.
- У нас нет PO. Сформировали команду интеграции, которая взяла на себя эту роль.
- А что еще у нас нет: стратегического планирования, бизнес модели, портретов пользователей, CJM … Постарались эти проблемы решить ().
- А что есть? А есть классические проблемы: нехватка кадров, нехватка времени на рациональное покрытие кода автотестами, непродуманная сразу архитектура. И конечно же непонимание масштабирования команд.
- Самое главное у многих сотрудников началось выгорание (об этом я напишу в следующей статье).
Продолжение следует….
Немного о работе над проектом: