Фиксация запросов бизнеса
Для того чтобы понять, какой объем работ поступает в команду и сколько мы можем переварить, необходимо начать фиксировать все запросы, которые поступают от бизнеса. Это можно делать хоть в блокноте, хоть на школьной доске, но все мы отлично знаем, что для этого существуют таск-трекеры.
Хочется добавить, что бизнес готов вам накидывать идеи хоть несколько раз в день. Тут важно быть рядом с заказчиком и заставить его задуматься о пользе его предложений. Часто удается на цифрах доказать, что очередная идея не такая уж классная.
Приведу пример из собственного опыта. У нас есть бот, который напоминает холодным клиентам, что неплохо бы с нами пообщаться в чате ВК или ТГ. Приходит заказчик и выдает отличную идею: «А давайте будем ботом писать еще в WhatsApp. Там даже можно первым инициировать диалог, а телефон клиента у нас есть».
Отличная идея, только WhatsApp позволяет отправлять первым только платные сообщения, либо если с момента последнего сообщения прошло более 24 часов. После анализа выяснилось, что просто для запуска такой фичи нам надо потратить 6000 $, а потом ежемесячно еще 2000 $.
Еще раз подумав, заказчик решил, что идея не такая уж и классная, ведь конверсия в договор не позволит окупить такие затраты.
Принцип единой ответственности
Что делать со срочной фичей, которая кажется заказчику очень важной и должна быть сделана еще вчера?
Такую фичу мы фиксируем и передаем аналитику. Вместе с ним мы разбиваем запрос на стори, ответственным за которые становится он. То есть если возникнет несоответствие между тем, что просил сделать заказчик и что получилось по факту, я точно знаю, с кого спросить.
При этом в глазах заказчика реализация доработки или сервиса ложится на мои плечи, то есть бизнес точно знает, с кого спрашивать в случае возникновения каких-либо проблем.
Далее идет стандартный процесс, при котором мы узнаем действительные проблемы заказчика и пытаемся решить их, не трогая разработчиков. Часто оказывается, что есть несколько путей, как минимум следуя правилам «быстро и дешево» или «долго и качественно».
Также выясняем реальный объем работ. Маленькое изменение бизнес-процессов может потащить за собой большие изменения в коде. Например, заказчик хочет изменить в сервисе одно поле: текстовый инпут «Город клиента» переделать в выпадающий список. Но значениями этого поля пользуются другие сервисы, а значит, нам грозят масштабные переделки.
Благодаря анализу мы можем достаточно точно спрогнозировать сроки работы. Или можем даже зарубить разработку, если аналитик на цифрах покажет несостоятельность идеи заказчика или если функциональность уже реализована в рамках другой фичи.
И так мы поняли, что без разработчиков проблему заказчика не решить и нужна доработка. Согласовываем вариант реализации с заказчиком, предупреждаем о сроках, рисках и стоимости. Если все условия устраивают, аналитик создает технические таски, ответственными за которые становятся конкретные разработчики.
В этот момент мы можем начать процесс планирования разработки исходя из приоритета той или иной таски. Способов приоритизации великое множество, информацию о них можно найти в интернете. Например, у нас в компании действует простое правило: чем ближе к деньгам, тем быстрее надо сделать.
У каждой конкретной таски ответственным ставится только один разработчик. Если возникают риски, связанные с качеством кода или багами, мы точно знаем, к кому идти, чтобы всё исправить.
Что делать со всем остальным?
Бесконечными разработками только фич мы, конечно же, не занимаемся. У нас еще есть пользователи наших сервисов, у которых возникают вопросы по работе сервиса, а мы собираем от них обратную связь.
Саппорт фиксирует обращение пользователя, вопрос по работе сервиса или обратную связь. Сотрудники пытаются решить проблему пользователя в рамках своих компетенций. Если у вас хорошо описанная документация и вы поддерживаете ее в актуальном состоянии, то чаще всего саппорт справляется самостоятельно, без помощи разработчиков.
В ином случае сотрудники саппорта заводят реквест и передают его разработчикам либо аналитикам. В дальнейшем реквест может переродиться в баг или фичу. Тут круг замыкается, и фича, пройдя этапы согласования, ложится на меня.
P. S.
Я сознательно избегал описания таких вещей, как планирование, приоритизация, и терминов Scrum, Kanban. В этой статье я хотел описать только подход, в котором все задачи, попадающие в разработку, имеют четкую иерархию и ответственного. Тогда разработка становится прозрачной для заказчика и всех, кто отвечает за поставку.
