Value Driven решения в разработке.

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

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

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

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

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

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

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

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

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

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

Не ошибается лишь тот, кто ничего не делает. А так как продукт - это результат деятельности, в нем будут ошибки. Но ошибка ошибке рознь. С некоторыми продукты могут существовать достаточно долго, а другие должны быть устранены как можно скорее. Фича-флаг или kill-switch поможет быстро отключить решение от остальной системы, тем самым даст врем для устранения возникшей проблемы.

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

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

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