10.2к
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Как спланировать разработку без хаоса?

Время чтения 1 минута
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
10.2к
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Здравствуйте, меня зовут Александр. Я уже около 15 лет в IT. Долгие годы занимался разработкой, но в последнее время перешел в менеджмент.

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

За несколько лет компания выросла, и сейчас IT-отдел насчитывает уже 70 человек. У нас, помимо разработчиков, появились аналитики, тестировщики, саппорт. При этом для бизнеса оставались непонятны сроки, стоимость и прибыль от разработки фич.

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

Как спланировать разработку без хаоса?

Фиксация запросов бизнеса

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

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

Приведу пример из собственного опыта. У нас есть бот, который напоминает холодным клиентам, что неплохо бы с нами пообщаться в чате ВК или ТГ. Приходит заказчик и выдает отличную идею: «А давайте будем ботом писать еще в WhatsApp. Там даже можно первым инициировать диалог, а телефон клиента у нас есть».

Отличная идея, только WhatsApp позволяет отправлять первым только платные сообщения, либо если с момента последнего сообщения прошло более 24 часов. После анализа выяснилось, что просто для запуска такой фичи нам надо потратить 6000 $, а потом ежемесячно еще 2000 $. 

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

Принцип единой ответственности

Что делать со срочной фичей, которая кажется заказчику очень важной и должна быть сделана еще вчера?

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

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

Далее идет стандартный процесс, при котором мы узнаем действительные проблемы заказчика и пытаемся решить их, не трогая разработчиков. Часто оказывается, что есть несколько путей, как минимум следуя правилам «быстро и дешево» или «долго и качественно». 

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

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

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

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

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

Что делать со всем остальным?

Бесконечными разработками только фич мы, конечно же, не занимаемся. У нас еще есть пользователи наших сервисов, у которых возникают вопросы по работе сервиса, а мы собираем от них обратную связь.

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

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

P. S.

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

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники