Как мы трансформируем процессы и культуру в МоемСкладе

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

Что мешает российским компаниям трансформировать процессы и культуру и как это удается делать в МоемСкладе — рассказывает Head of Scrum облачного сервиса МойСклад Владислав Могильников.

Scrum очень дорогой во внедрении, и компаниям, которые хотят на всем экономить, он не подойдет.

Scrum не любит ленивых. Внедряются новые процессы, направленные на повышение прозрачности работы в команде. Например, регулярные встречи, где проявляется активность всех членов команды (Daily Scrum, Sprint Review, Retrospective).

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

В компаниях с жесткой иерархией и токсичной атмосферой в коллективе тоже не стоит внедрять Scrum. Сначала нужно менять культуру компании и только потом рассматривать Scrum как способ работы.

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

МойСклад — гибкая компания с матричной структурой управления: есть вертикальные полосы — продуктовые команды, и горизонтальные — гильдии специалистов: разработчиков, дизайнеров, тестировщиков, Product-менеджеров и Scrum-мастеров.

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

Мы улучшили процессы в командах: добавили прозрачности в ход разработки и удалили неактуальные задачи из бэклога (общего списка работ, упорядоченных по приоритету). Обучаем сотрудников давать конструктивную обратную связь, поддерживать друг друга, задавать себе вопрос, зачем мы делаем ту или иную задачу.

В одних командах результаты лучше, другие менее успешны — это нормально. Каждая движется в своем темпе.

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

Многие команды учатся выполнять взятые в спринт задачи и релизить их на prod за время спринта (2 недели). То есть делать так, чтобы пользователи как можно раньше получали фичи и могли дать по ним обратную связь.

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

Выстроили несколько гильдий специалистов и продолжаем развиваться в этом направлении. Команда разработки у нас самая большая, пока удалось выделить только гильдию front-end, но будем выделять еще.

Проводим внутренние митапы гильдии методологии — встречи в формате Lean Coffee для поддержки сотрудников. Любой может прийти и задать свой вопрос.

Сейчас в процессе изменение формата онбординга новых сотрудников. Пока он единый для всей компании, но мы планируем разделить обучение для ИТ-специалистов и сотрудников других подразделений (продаж, маркетинга, HR).

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

Метрики помогают нам принимать решения на основании данных, а не субъективных ощущений и экспертных мнений. Например, точно ли нам нужен новый разработчик, если у нас задачи на разработке вообще не «зависают»?

Метрики мы вводили в 2 этапа. Сначала появились метрики из Kanban-практики:

Flow In — количество задач, которое команда берет в спринт

Flow Out — сколько полезных задач за спринт команда закрывает

Unfinished — количество незавершенных задач (перенесенные из прошлого спринта)

Waste — закрытые задачи, где не было ценности (дубликаты, ошибочные, недоделанные)

Все метрики выводятся на диаграмме Netflow. Она помогает определить равномерность работы команды.

Чтобы измерить скорость работы команды, мы внедрили Lead time и Cycle time.

Lead time — время, которое задача проходит от момента взятия в работу до момента вывода на продакшн. Lead time показывает скорость работы, бывает минимальным, максимальным и медианной. Мы специально взяли медиану, а не среднее значение, так как все мы знаем, что средняя температура по больнице 36,6.

Cycle time — сколько времени задача пребывала в разных статусах: в разработке, на тестировании, ревью и т.д.

Долгое время мы пользовались только этими метриками, было сопротивление.

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

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

Потом мы ввели метрику Back, отражающую количество возвратов назад. Пока мы считаем возвраты только с тестирования, сейчас это для нас приоритетно. Если Lead time большое, то можем проверить, сколько было возвратов с тестирования и задаться вопросом, почему так много багов: плохо кодим или плохо ставим задачи?

Мы по-прежнему работаем на прозрачность. Последняя метрика, которую мы ввели — это план-факт. Смотрим, какая оценка была по задаче изначально и за какое время ее фактически сделали.

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

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

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

Нужно переосмыслить процесс Work Flow продуктовых команд: создать Cook Book с общими правилами по процессу разработки, а затем каждая команда адаптирует его под свои особенности. Гибкость будет, но общие правила нарушать нельзя.

И, конечно, доведем до конца обновление процесса онбординга и зайдем в команды, где еще не работали (таких в МоемСкладе осталось немного, но они есть).

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

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

Часто начальникам не хватает качеств лидера, а лидерам — качеств начальника. Самый эффективный руководитель, по моему мнению, — это «персьютор», в переводе с английского “pursuit” — стремиться. У него пограничная роль — еще не лидер, но уже не начальник, он готов меняться сам и вести за собой компанию на новый уровень. За такими специалистами будущее.

Смотря какой:) Психоаналитики никуда не исчезнут, а функции аналитиков в ИТ постепенно поглощаются новыми профессиями.

Например, есть Product Owner. Он совмещает в себе роль аналитика и менеджера. Финансовых аналитиков заменит искусственный интеллект, а системным анализом не против заниматься сами разработчики.

Признаюсь честно — меня не радует ситуация с внешними митапами: банальные темы, очевидные ответы. Поэтому сейчас я выстраиваю комьюнити вокруг себя: у меня закрытый профессиональный клуб «Несекретарь» в Telegram, который вырос в 6 раз с октября прошлого года.

Каждую неделю я поднимаю новые темы, участники поддерживают друг друга. Людям нравится моя позиция и честность. По вопросам вступления в клуб пишите мне в Telegram @time_t0_it

Во внешних мероприятиях я участвую редко (выступление на прошедшем 24-25 сентября Flow Days, скорее, исключение), но мы с командой проводим собственные — хочется делиться опытом и рассказывать, как у нас в компании проходит трансформация.

В июле 2022 года мы провели первый митап — «Не Agile трансформация».

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