Продуктовый подход в 1С разработке: 80% – развитие 20% – операционка

Меня зовут Елена Веренич, я руководитель группы финансовых продуктов компании CDEK. Мой соавтор Денис Еганов – технический лидер нашей команды. Мы хотим рассказать о продуктовом подходе в разработке на платформе 1С: как мы его внедрили у себя и как используем в работе.

Про фокус

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

Когда руководитель доносит эту информацию с бизнес-функцией – это одна речевая архитектура. Когда же обсуждаешь это с командой, которая не так глубоко понимает бизнес-цели, – это другая архитектура. Нужно на доступном языке объяснить ценности продукта. Все должны понимать, зачем мы это делаем и что мы принесем бизнесу.

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

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

Участники продуктового борта – это:

1. ТОП-менеджмент. Мы вовлекаем его, чтобы подтвердить наши цели.

2. Бизнес-функции, причем не только целевые, но и смежные – те, которые будут пользоваться продуктом. Например, если у меня работает управленческая функция, это бюджетирование, казначейство, управленческий учет, МСФО – все функции, которые формируют, контролируют бюджеты, инициируют заявки на потребность или расходование денежных средств. В продуктовый борт мы включаем все эти функции. Важно, чтобы они понимали, как будут работать с продуктом.

3. Команда продукта.

Сделать продукт сразу «под ключ» и качественно – задача крайне сложная. На продуктовом борте мы открыто обсуждаем, как будем его реализовывать: с какой этапностью, какие трудности возникнут на первом этапе, какие проблемы возможны, заранее проговариваем все риски. Разработать весь продукт сразу и идеально – практически невозможно, поэтому мы разбиваем его на этапы развития.

Если речь идет о минимально жизнеспособном продукте (MVP), мы честно заявляем: «Вот MVP. Полгода вам придется работать с нагрузкой 120%, потому что данные придется вводить вручную, дублировать некоторые операции, не все будет удобно». Это нормальная жизнь продукта на начальном этапе. В дальнейшем мы будем его развивать, улучшать и автоматизировать. Мы оговариваем сроки, обсуждаем этапы и фиксируем все договоренности.

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

В итоге, когда мы проговорили все ценности продукта, у нас проходит голосование. Если оно проходит успешно, мы берем продукт в работу.

Измеримый результат. Работая над продуктом, нам необходимо измерять результаты. Если это продукты с выручкой, все понятно: выручка, метрики объема продаж – по ним можно оценить успех. Но как быть, если выручки нет, например, в учетных системах?

У нас есть несколько метрик, которые мы используем в управленческом учете:

• Срок сдачи отчетности в днях. Для бизнеса критически важно, чтобы отчетность сдавалась как можно раньше. Если это происходит позже начала месяца, отчет уже считается «посмертным» и теряет актуальность.

• Рейтинг продукта. Его оценивают все пользователи, независимо от роли. Важно, насколько комфортно работать с продуктом: интерфейс, удобство нажатия кнопок, подсказки – все это влияет на удобство использования и общее восприятие.

• Количество автоматизированных процессов. Здесь речь идет об уровне автоматизации: мы разбиваем процессы, оцениваем их и выводим процент автоматизации тех процессов, которые планировали автоматизировать.

• Количество багов – эта метрика напрямую говорит о качестве продукта.

Мы собираем метрики раз в квартал: фиксируем их текущие значения и анализируем динамику.

Про процесс разработки

Чтобы достигать поставленных целей, нам необходимо адаптировать процесс разработки.

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

80% развития. В нашей команде принято распределять ресурсы следующим образом: около 80% времени уходит на развитие. Из них 60% – на новую функциональность и фичи для бизнеса, а оставшиеся 20% – на техническое развитие продукта. Эти 20% посвящены тем решениям, которые не всегда очевидны для бизнеса, но позволяют в будущем работать эффективнее и быстрее.

UI/UX. Немаловажным аспектом является создание удобных и продуманных интерфейсов. Продукт должен быть не просто инструментом для ввода информации, а помощником бизнеса в решении его задач. Множество мелких деталей могут значительно упростить работу пользователя.

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

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

В идеальном сценарии пользователь просто открывает форму, использует представленные данные (возможно, даже ничего не изменяет), и процесс завершен. В результате пользователь доволен, и мы тоже.

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

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

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

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

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

У нас сложный конвейер данных: они поступают из бухгалтерского учета, затем транслируются в международный учет, управленческий учет, казначейство и другие системы. На любом этапе может возникнуть проблема – например, не заполнены аналитики или нет правил трансляции. Мы не останавливаем процессы, фиксируем ошибки в реестре, ответственные лица их устраняют, и только небольшая порция данных проходит повторную обработку. Таким образом, очередей не образуется, и во всех учетах остаются корректные данные.

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

• железные метрики (аппаратные показатели),

• данные из журнала регистрации,

• данные из технологического журнала.

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

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

Про навыки

Эффективно выстроенный процесс разработки влияет на развитие навыков разработчиков.

1. Планирование. Каждый разработчик участвует в оценке задач. Оценка должна быть точной, чтобы попадать в планы – нельзя оценивать «абы как». Навык планирования помогает разработчикам эффективнее распределять свое рабочее время.

2. Ответственность. Мы все знаем цели, которые перед нами стоят. Каждый разработчик участвовал в планировании, «подписался» под этими целями, поэтому нет шанса сказать: «Я не успел», «Я забыл» или «У меня не получилось». Вся команда заинтересована в результате, и отлынивать нельзя.

3. Мы проводим перекрестное код-ревью. Этим занимается не наставник или техлид, а каждый разработчик. Читая чужой код, разработчики узнают что-то новое – приемы, методики. Даже опытные специалисты, изучая код молодых коллег, могут открыть для себя что-то новое или переосмыслить давно забытое.

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

5. Кругозор. В процессе разработки приходится сталкиваться с вспомогательными инструментами, такими как GitHub, ClickHouse, Sonar, Vanessa и другими. Это расширяет кругозор разработчиков, позволяет не зацикливаться только на возможностях платформы 1С, а смотреть шире. Так они находят более эффективные пути решения проблем.

Все эти навыки помогают находить оптимальные решения и в конечном счете создавать по-настоящему эффективный и ценный продукт.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.