Проектный и продуктовый подход в разработке, Agile и Scrum. Внедрение и обратная связь сотрудников
На связи команда Legal Resources. Мы надеемся, что сможем дать нечто полезное, рассказав о своем опыте. Несколько слов о нашей команде: мы занимаемся разработкой сервисов Legal Tech для профессиональных взыскателей и сотрудников юридической сферы, сейчас у нас 9 продуктов, которые мы развиваем и улучшаем. В этом блоге мы планируем делиться нашим опытом, ошибками и успехами. В этой статье мы хотим рассказать о нашем пути внедрения в работу нового для нас подхода - продуктового, а также философии Agile и фреймворка Scrum. Что поменялось, легко или трудно было все это внедрить, и какие наши планы на будущее?
Что было до?
Начнем с того, что мы IT-стартап, который сам по себе является очень гибким и быстро меняющимся. Мы пробуем разные подходы и меняем стратегию, тестируя разные гипотезы. До 2024 года в нашей работе преобладал проектный подход. Мы делали акцент на процесс, были четкие цели разработать конкретные продукты, которые можно будет выводить на рынок.
В январе 2024 года в нашей компании прошла важная стратегическая сессия, которая способствовала смене вектора развития, так как наши продукты начали активно выходить на рынок. Разработка начала отталкиваться от потребностей клиентов, поэтому было принято решение о переходе на продуктовый подход.
Одной из предпосылок стало то, что нам было необходимо соответствовать быстро меняющимся условиям рынка, а именно - сфере Legal, которая не только является высокорегламентированной, но еще и регулярно дополняется новыми законами, а также конкурировать с выходящими на рынок гигантами за счет улучшения сервиса. Следовательно, как мы написали выше, мы начали делать упор на потребности наших потенциальных и действующих клиентов, а также тренды и нужды рынка.
Переход
Решение по переходу на продуктовый подход было принято в конце января. Плавно началась перестройка команд и оргструктуры. Раньше у нас была одна общая команда разработки - Resource Pool, она была разделена на 3 команды, за каждой из которых закрепили свои продукты. То есть разработчики больше не распылялись, они занимались конкретным продуктом. При этом внедрение продуктового подхода началось только в одной команде, две другие оставались на проектном. Это было сделано как для тестирования в условиях нашей разработки, так и потому, что у продуктов, которые разрабатывает данная команда, появился первый пул клиентов.
Ожидаемые результаты этого изменения:
- Снижение времязатрат на переключение контекста при работе с разными продуктами
- Повышение компетенций разработчиков внутри конкретных продуктов
- Включение разработчиков в продукт с точки зрения долгосрочной ценности всего сервиса для пользователя
Первая команда начала работу в формате продуктового подхода и фреймворка Scrum в марте. Была полностью перестроена работа. Теперь ведущим лицом становился Владелец Продукта. Его задачи:
- Владеет бэклогом продукта и приоритизирует его
- Получает и анализирует обратную связь от клиентов
- Формирует цели продукта и максимизирует его ценности
- Управляет бюджетом
Это позволило нам гибко вносить изменения в продукт и улучшить коммуникацию среди сотрудников.
Таким образом мы следили за изменениями и улучшениями работы в течение двух месяцев. Далее, в мае, работу по продуктовому подходу начала вторая команда, а в конце июня третья. Также было принято решение сформировать четвертую команду, чтобы все продукты были в фокусе и каждому из них уделялось больше внимания.
Участники процесса
В первую очередь продуктовый подход коснулся разработки. Мы полностью пересобрали команды, распределили разработчиков по конкретным продуктам и сменили ответственных. После распределения было выявлено, что сотрудников не хватает, поэтому мы начали активный найм. Всего за 4 месяца было нанято 17 человек и найм продолжается в связи с увеличением количества команд. Объемы растут, новые люди появляются.
Мы собрали обратную связь от сотрудников из первой команды, чтобы оценить изменения, которые произошли.
С внедрением продуктового подхода, Agile и Scrum улучшилось то, что теперь мы больше участвуем в продукте, высказываем свое мнение и влияем на итог. Ранее мы такого не делали, только выполняли ТЗ. Благодаря дейликам все участники процесса задействованы и заинтересованы, что важно. Из минусов в целом ничего критичного, но увеличилось количество встреч, это заметно и это отмечают все, кто начал работать по продуктовому подходу. Они, разумеется, очень важны и улучшают работу, но отнимают очень много времени.
Отмечу, что для меня, как для разработчика, ничего не меняется, я также пишу код, но теперь я смотрю на перспективу и планирую на будущее, думаю как сделать лучше, а не пишу по методичке
Для меня продуктовый подход, Agile и Scrum в первую очередь повлияли на моральное состояние команды. Я заметил, что нам намного легче работать, когда мы можем спокойно обсудить наши решения, выразить и услышать мнение всех членов команды. Раньше с этим были проблемы, поскольку люди отвечали за результат перед руководителем проектов, которого, ввиду своих обязанностей, интересовал конечный результат, выполненный в положенный срок, поэтому у специалиста могло просто не быть достаточно времени для обсуждения на тему “А как можно сделать лучше?”, люди просто старались выполнить то, что заложено в ТЗ.
Второе - в разработке стало меньше неопределенности благодаря постоянной обратной связи от пользователей. Раньше нам приходилось строить теории о том, в каком виде то или иное решение лучше подойдет нашим клиентам, иногда приходилось внедрять множество вариантов решений, давая таким образом, как нам казалось, больше свободы для них, однако на деле мы просто тратили время на никому ненужные вещи. Теперь мы лучше понимаем потребности пользователей и не распыляемся на ненужные фичи, а наши решения выглядят именно так, как хотят клиенты.
Третье - процесс разработки стал более гибким. Нам приходится чаще менять свои решения прямо во время разработки, что, несмотря на постоянное перестраивание планов, позволило нам выдавать именно тот результат, который находит своего потребителя
Для меня плюсы продуктового подхода, Agile и Scrum таковы: - Разработка проходит быстрее, тк команда закреплена за определенными сервисами и внимание не распыляется на все сервисы сразу. К каждой команде прикреплены Бизнес-аналитики, дизайнеры и прочие нужные для разработки люди, если к ним есть вопросы или нужен созвон - это происходит напрямую и быстрее. Пул работ планируется заранее на каждый спринт, все риски сразу обсуждаются. Погруженность в процессы закрепленных за тобой сервисов теперь гораздо выше и можно предлагать свои решения проблем.
Минусы такого подхода: Тк сервисы теперь закреплены за определенной командой, стоит 1-2 разработчикам заболеть или уйти - разработка встанет. То есть теперь разработка и релиз новых версий продукта сильно зависят от пары разработчиков. Второе - тк мы, разработчики, теперь сильнее погружены в бизнес процессы, созвонов и обсуждений по задачам стало гораздо больше
На мой взгляд продуктовый подход показывает себя эффективнее и лучше процесса, выстроенного ранее
Помимо разработчиков изменения затронули клиентский отдел и отдел маркетинга, т.к. они в своих мероприятиях и коммуникации с клиентами в первую очередь придерживаются парадигмы, что мы готовы меняться для клиентов и гибко подстраиваться под их потребности.
Начали проводиться регулярные встречи Владельцев продуктов и Клиентского отдела для постоянного обмена информацией и улучшения продуктов.
О каких-то изменениях для клиентов пока говорить рано, продуктовый подход был внедрен совсем недавно, и если сотрудники заметили ощутимые изменения, клиенты пока нет.
Продуктовый подход для всей компании
В июне в нашу компанию вышел SCRUM-мастер, который сразу начал организовывать обучения для всех сотрудников (о том, что именно он изменил и какие у него планы мы расскажем в отдельных статьях). Первым обучением стал как раз таки продуктовый подход. Перед собранием было проведено анкетирование, чтобы узнать, насколько сотрудники погружены и понимают что такое продуктовый подход, AGILE и SCRUM.
Общие впечатления
Подытожим небольшим выводом для нас на данном этапе. Разумеется, мы понимаем, что продуктовый подход, Agile и Scrum внедрены совсем недавно и мы только начинаем активно по ним работать, но четкие плюсы после опроса сотрудников мы уже видим: Сотрудники стали больше погружены в продукт, они осознают его ценность и при разработке продукта смотрят не только на текущее тз, но и на перспективу
- Улучшилась коммуникация среди сотрудников. Теперь она происходит напрямую, а не через Руководителя отдела, что значительно облегчило работу
- Качество разработки стало выше. Сотрудники не боятся высказывать свое мнение, озвучивать риски и предлагать идеи
Минусы такого подхода:
- Увеличилось количество встреч, хотя они необходимы.
- Незаменимость членов команды в случае болезни или др. Однако этот минус мы регулируем наймом новых сотрудников
Подводя итог всему вышесказанному. На данном этапе мы уверенно движемся вперёд и к концу 2024 года надеемся существенно продвинуться во внедрении продуктового подхода и сопутствующих моментов, таких как философия Agile и фреймоворк Scrum, а также в перспективе внедрение практик из Kanban.
По плану на конец года достигнуть от 9 до 10 (из 10 возможных) баллов эффективного внедрения продуктового подхода и вышеописанных моментов обратной связи, а также увеличить скорость работы команд (тут, к примеру, нам поможет введение в будущем системы Story Point, планирование по ним и оценки эффективности), а также улучшить обратную связь от клиентов (тут помогут лучшие практики по приоритезации и декомпозиции задач, а также более тесные и продуктивные сессии взаимодействия с клиентами).
Мы обязательно будем делиться опытом внедрения различных инструментов в нашу работу.
Подписывайтесь на наш телеграм-канал! Там мы будем рассказывать о наших новостях и давать советы, учитывая наш опыт