Продуктовый подход, Agile и Scrum в разработке Legal Tech решений. Наш опыт внедрения и обратная связь сотрудников

В в этом году мы начали внедрять в работу продуктовый подход, философию Agile и фреймворк Scrum. Что поменялось, легко или трудно было все это внедрить, и какие наши планы на будущее? Рассказываем в этой статье. 

Что было до?

Начнем с того, что мы IT-стартап, который сам по себе является очень гибким и быстро меняющимся. Мы пробуем разные подходы и меняем стратегию, тестируя разные гипотезы. До 2024 года в нашей работе преобладал проектный подход. Мы делали акцент на процесс, были четкие цели разработать конкретные продукты, которые можно будет выводить на рынок.

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

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

Переход

Решение по переходу на продуктовый подход было принято в конце января. Плавно началась перестройка команд и оргструктуры. Раньше у нас была одна общая команда разработки - Resource Pool, она была разделена на 3 команды, за каждой из которых закрепили свои продукты. То есть разработчики больше не распылялись, они занимались конкретным продуктом. При этом внедрение продуктового подхода началось только в одной команде, две другие оставались на проектном. Это было сделано как для тестирования в условиях нашей разработки, так и потому, что у продуктов, которые разрабатывает данная команда, появился первый пул клиентов.

Ожидаемые результаты этого изменения:

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

Первая команда начала работу в формате продуктового подхода и фреймворка Scrum в марте. Была полностью перестроена работа. Теперь ведущим лицом становился Владелец Продукта. Он делает следующее:

• владеет бэклогом продукта и приоритизирует его;
• получает и анализирует обратную связь от клиентов;
• формирует цели продукта и максимизирует его ценности;
• управляет бюджетом.

Это позволило нам гибко вносить изменения в продукт и улучшить коммуникацию.

Таким образом мы следили за изменениями и улучшениями работы в течение двух месяцев. Далее, в мае, работу по продуктовому подходу начала вторая команда, а в конце июня третья. Одновременно с этим, было принято решение сформировать четвертую команду, чтобы все продукты были в фокусе и каждому из них уделялось больше внимания.

Участники процесса

В первую очередь продуктовый подход коснулся разработки. Мы полностью пересобрали команды, распределили разработчиков по конкретным продуктам и сменили ответственных. После распределения было выявлено, что работников не хватает, поэтому мы начали активный найм. Всего за 4 месяца было нанято 17 человек и найм продолжается в связи с увеличением количества команд. Объемы растут, новые люди появляются.Мы собрали обратную связь от сотрудников из первой команды, чтобы оценить изменения, которые произошли.

С внедрением продуктового подхода, Agile и Scrum улучшилось то, что теперь мы больше участвуем в продукте, высказываем свое мнение и влияем на итог. Ранее мы такого не делали, только выполняли ТЗ. Благодаря дейликам все участники процесса задействованы и заинтересованы, что важно. Из минусов в целом ничего критичного, но увеличилось количество встреч, это заметно и это отмечают все, кто начал работать по продуктовому подходу. Они, разумеется, очень важны и улучшают работу, но отнимают время.

Отмечу, что для меня, как для разработчика, ничего не меняется, я так же пишу код, но теперь я смотрю на перспективу и планирую на будущее, думаю как сделать лучше, а не пишу по методичке.

Алексей, Разработчик Python

Для меня продуктовый подход, Agile и Scrum в первую очередь повлияли на моральное состояние команды. Я заметил, что нам намного легче работать, когда мы можем спокойно обсудить наши решения, выразить и услышать мнение всех членов команды. Раньше с этим были проблемы, поскольку люди отвечали за результат перед руководителем проектов, которого, ввиду своих обязанностей, интересовал конечный результат, выполненный в положенный срок, поэтому у специалиста могло просто не быть достаточно времени для обсуждения на тему “А как можно сделать лучше?”, люди просто старались выполнить то, что заложено в ТЗ.

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

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

Александр, Бизнес-аналитик

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

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

На мой взгляд продуктовый подход показывает себя эффективнее и лучше процесса, выстроенного ранее.

Улукбек, Разработчик Python

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

Начали проводиться регулярные встречи Владельцев продуктов и Клиентского отдела для постоянного обмена информацией и улучшения продуктов.

О каких-то изменениях для клиентов пока говорить рано, продуктовый подход был внедрен совсем недавно, и если сотрудники заметили ощутимые изменения, клиенты пока нет.

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

Общие впечатления

Подытожим небольшим выводом для нас на данном этапе. Разумеется, мы понимаем, что продуктовый подход, Agile и Scrum внедрены совсем недавно и мы только начинаем активно по ним работать, но четкие плюсы после опроса мы уже видим: Сотрудники стали больше погружены в продукт, они осознают его ценность и при разработке продукта смотрят не только на текущее тз, но и на перспективу.

Плюсы продуктового подхода:

• Улучшилась коммуникация среди сотрудников. Теперь она происходит напрямую, а не через Руководителя отдела, что значительно облегчило работу.
• Качество разработки стало выше. Сотрудники не боятся высказывать свое мнение, озвучивать риски и предлагать идеи.

Минусы продуктового подхода:

• Увеличилось количество встреч, хотя они необходимы.
  Незаменимость членов команды в случае болезни или отсутствия, однако этот минус мы регулируем наймом новых людей.

На данном этапе мы уверенно движемся вперёд и к концу 2024 года надеемся существенно продвинуться во внедрении продуктового подхода и сопутствующих моментов, таких как философия Agile и фреймворк Scrum, а в перспективе и внедрение практик из Kanban.

По плану на конец года достигнуть от 9 до 10 (из 10 возможных) баллов эффективного внедрения продуктового подхода и вышеописанных моментов обратной связи, а также увеличить скорость работы команд (тут, к примеру, нам поможет введение в будущем системы Story Point, планирование по ним и оценки эффективности), а также улучшить обратную связь от клиентов (тут помогут лучшие практики по приоритезации и декомпозиции задач, а также более тесные и продуктивные сессии взаимодействия с клиентами).

Мы обязательно будем делиться опытом внедрения различных инструментов в нашу работу.

#продукты