Привет, Хабр! Меня зовут Александр, я уже около 15 лет в IT. Долгие годы занимался разработкой, но в последнее время перешел в менеджмент.
Сейчас я работаю в крупной компании, которая занимается юридическими услугами. За несколько лет компания выросла, и сейчас IT-отдел насчитывает уже 70 человек. Помимо разработчиков у нас появились аналитики, тестировщики, саппорт. При этом для бизнеса оставались непонятны сроки, стоимость и прибыль от разработки фич.
Мне предложили заняться менеджментом разработки, так как помимо написания самого кода я еще был глубоко погружен в бизнес-процессы. Предложение мне показалось интересным, и я с энтузиазмом взялся за непочатый объем работы, возглавив разработку нескольких сервисов.
В этой статье читателям Хабра и вАЙТИ — нового DIY-медиа для айтишников я расскажу о принципах, которые помогли наладить процессы в разработке и сделать их прозрачнее.
Фиксация запросов бизнеса
Для того чтобы понять, какой объем работ поступает в команду и сколько мы можем переварить, необходимо начать фиксировать все запросы, которые поступают от бизнеса. Это можно делать хоть в блокноте, хоть на школьной доске, но все мы отлично знаем, что для этого существуют таск-трекеры.
Хочется добавить, что бизнес готов вам накидывать идеи хоть несколько раз в день. Тут важно быть рядом с заказчиком и заставить его задуматься о пользе его предложений. Часто удается на цифрах доказать, что очередная идея не такая уж классная.
Приведу пример из собственного опыта. У нас есть бот, который напоминает холодным клиентам, что неплохо бы с нами пообщаться в чате ВК или ТГ. Приходит заказчик и выдает отличную идею: «А давайте будем ботом писать еще в WhatsApp. Там даже можно первым инициировать диалог, а телефон клиента у нас есть».
Отличная идея, только WhatsApp позволяет отправлять первым только платные сообщения, либо если с момента последнего сообщения прошло более 24 часов. После анализа выяснилось, что просто для запуска такой фичи нам надо потратить 6000 $, а потом ежемесячно еще 2000 $.
Еще раз подумав, заказчик решил, что идея не такая уж и классная, ведь конверсия в договор не позволит окупить такие затраты.
Принцип единой ответственности
Что делать со срочной фичей, которая кажется заказчику очень важной и должна быть сделана еще вчера?
Такую фичу мы фиксируем и передаем аналитику. Вместе с ним мы разбиваем запрос на стори, ответственным за которые становится он. То есть если возникнет несоответствие между тем, что просил сделать заказчик и что получилось по факту, я точно знаю, с кого спросить.
При этом в глазах заказчика реализация доработки или сервиса ложится на мои плечи, то есть бизнес точно знает, с кого спрашивать в случае возникновения каких-либо проблем.
Далее идет стандартный процесс, при котором мы узнаем действительные проблемы заказчика и пытаемся решить их, не трогая разработчиков. Часто оказывается, что есть несколько путей, как минимум следуя правилам «быстро и дешево» или «долго и качественно».
Также выясняем реальный объем работ. Маленькое изменение бизнес-процессов может потащить за собой большие изменения в коде. Например, заказчик хочет изменить в сервисе одно поле: текстовый инпут «Город клиента» переделать в выпадающий список. Но значениями этого поля пользуются другие сервисы, а значит, нам грозят масштабные переделки.
Благодаря анализу мы можем достаточно точно спрогнозировать сроки работы. Или можем даже зарубить разработку, если аналитик на цифрах покажет несостоятельность идеи заказчика или если функциональность уже реализована в рамках другой фичи.
И так мы поняли, что без разработчиков проблему заказчика не решить и нужна доработка. Согласовываем вариант реализации с заказчиком, предупреждаем о сроках, рисках и стоимости. Если все условия устраивают, аналитик создает технические таски, ответственными за которые становятся конкретные разработчики.
В этот момент мы можем начать процесс планирования разработки исходя из приоритета той или иной таски. Способов приоритизации великое множество, информацию о них можно найти в интернете. Например, у нас в компании действует простое правило: чем ближе к деньгам, тем быстрее надо сделать.
У каждой конкретной таски ответственным ставится только один разработчик. Если возникают риски, связанные с качеством кода или багами, мы точно знаем, к кому идти, чтобы всё исправить.
Что делать со всем остальным?
Бесконечными разработками только фич мы, конечно же, не занимаемся. У нас еще есть пользователи наших сервисов, у которых возникают вопросы по работе сервиса, а мы собираем от них обратную связь.
Саппорт фиксирует обращение пользователя, вопрос по работе сервиса или обратную связь. Сотрудники пытаются решить проблему пользователя в рамках своих компетенций. Если у вас хорошо описанная документация и вы поддерживаете ее в актуальном состоянии, то чаще всего саппорт справляется самостоятельно, без помощи разработчиков.
В ином случае сотрудники саппорта заводят реквест и передают его разработчикам либо аналитикам. В дальнейшем реквест может переродиться в баг или фичу. Тут круг замыкается, и фича, пройдя этапы согласования, ложится на меня.
P. S.
Я сознательно избегал описания таких вещей, как планирование, приоритизация, и терминов Scrum, Kanban. В этой статье я хотел описать только подход, в котором все задачи, попадающие в разработку, имеют четкую иерархию и ответственного. Тогда разработка становится прозрачной для заказчика и всех, кто отвечает за поставку.
вАЙТИ — DIY-медиа для ИТ-специалистов. Делитесь личными историями про решение самых разных ИТ-задач и получайте вознаграждение. |
Комментарии (23)
vnbelyaev
11.04.2024 19:43>> менеджментом разработки
что это за новояз?
Бизнес действительно готов накидывать хоть десятки ИДЕЙ в день. Но - КТО будет определять что вот именно эту идею надо запускать в работу?
rukhi7
11.04.2024 19:43какой-нибудь завалявшийся Стив Джобс просто нужен, который точно знает в каком порядке эти идеи реализовывать, а какие просто игнорировать.
vnbelyaev
11.04.2024 19:43все же просто - подкидываем кубик и определяем что важное и срочное и т.д. )))))
Ivan22
11.04.2024 19:43вы текст то читали?
у нас в компании действует простое правило: чем ближе к деньгам, тем быстрее надо сделать.
rukhi7
11.04.2024 19:43У нас в прошлом тысячилетии было такой интересное слово: "показуха".
Так вот если вы спросите пять разных людей, скажем разработчика, тестера, начальника разработчиков, начальника тестеров, начальника над начальниками, вы всегда рискуете получить пять разных мнений по поводу того, какое решение текущей проблемы
ближе к деньгам
Поэтому ваше простое правило вряд ли является вполне эффективным, к сожалению. А есть еще ситуации когда вы теряете деньги и надо минимизировать потери, тут явно надо придумывать еще одно правило.
Ivan22
11.04.2024 19:43во-первых оно не мое, а во-вторых даже я понимаю что как-то тупо спрашивать тестера о ценности новой фичи для продукта, когда для этого есть специальная целая роль, продукт оунер называется. Это его прямая работа деньги от фич считать, а не девелоперов, вы бы еще баристу из корпоративного бара спросили
rukhi7
11.04.2024 19:43вы бы еще баристу из корпоративного бара спросили
ну если ваш продукт оунер для нового проекта запланирует что бариста начнет выделять из себя некую волшебную субстанцию и будет добавлять ее в популярный у разработчиков напиток и поетому разработчики начнут работать в 10 разэффективнее, то к баристе тоже придется обращаться в связи с проектом как это не странно звучит.
Как видите нет ничего невозможного в этом мире, особенно когда дело касается близости к деньгам :).
Ivan22
11.04.2024 19:43только баристу спросят не о ЦЕННОСТИ этой фичи, а просто о ее реализуемости и сроках. Не подменяйте понятия, ценность снова же будет оценивать продукт оунер
rukhi7
11.04.2024 19:43только баристу спросят не о ЦЕННОСТИ этой фичи, а просто о ее реализуемости и сроках.
то есть сколько бариста хочет денег за такое свое ВОЛШЕБНОЕ участие в проекте никто спрашивать не будет? прикольно :)!
Так и получается проблеммы
индейцевподчиненных,шерифаначальство не интересуют :) .vnbelyaev
11.04.2024 19:43Вообщето ни проблемы негров, ни шерифа - бариста не волнуют. Деньги есть? Вот тебе кофе.. Денег нет - что тут забыл?
Ivan22
11.04.2024 19:43будет описание: фича1 - "10 трудодней работы от баристы и расход 10г порошка на порцию. Выход +20 к морали" А уж продукт оунер реашет сколько пользы из этого можно выжать и какая у нее ценность и в итоге приоритезирует. Так это и работает.
p.s. Бариста вообще свою ЗП получает фиксированную, на его деньгах это не скажется никак.
з.з.ы да вы просто себестоимость с ценностью попутали, все ясно
rukhi7
11.04.2024 19:43Бариста вообще свою ЗП получает фиксированную, на его деньгах это не скажется никак.
бариста получает свою зарплату как бориста, а если какой-то овнер открыл в нем способности к волшебству и собирается использовать эти способности то бариста как бы обретает новое качество, качество волшебника в данном случае.
Мне кажется это все таки вы упустили что за такое дополнительное качество не плохо бы доплачивать. А за качество волшебника, я боюсь, что придется волшебно доплачивать, при чем возможно с волшебными отрицательными последствиями в случае не уплаты.
vnbelyaev
11.04.2024 19:43Тут есть другое правило - чем ближе ЛПР к деньгам, тем менее его волнуют все остальные проблемы. Цитата :"проблемы негров шерифа не волнуют"
rukhi7
То есть фичу которую надо было сделать вчера подвергается глубокому анализу чтобы, наверно, сделать ее завтра... или послезавтра..., ну, в общем, если получится. Классное решение!
То есть анализ это супер технология! Никто больше не догадывается применять Анализ!
Супер статья! Чувствуется подход перспективного менеджера.
Ivan22
я уверен это правильное и вообще единственно верное решение в долгосрочной перспективе. Все остальное это просто накопление костылей и мантры самоуспокоения про то что "ну тех.долг обязательно закроем... когда-нибудь... потом"
Ivan22
Не, ну на первый взгляд кажется что это очевидный и логичный шаг любой задачи. Но внезапно оказывается, что полно мест где это не очевидно и там делают так как вы сами описали выше "если фичу надо было сделать вчера - некогда анализировать, вперед быстрее копать..." И в итоге на анализ кладут болт, а ведь это супер технология :)
Aizz
Регулярно подбешивают менеджеры/архитекторы/РП, которые говорят "Да, там срочная фича, я сказал делай, чего думать", а потом начинается "Ой, а вы чего не уточнили у отдела продаж, это ж на них повлияет", "Ой, у нас интерфейс не умеет с этим работать", "Ой, у нас еженедельная выгрузка в BI поломалась"
vnbelyaev
Обычно такое лечится вопросами - "что делать если будет такое?", "а если такое"
Ivan22
ну не так-то просто и лечится. Ответ всегда в стиле "когда будут проблемы тогда и будем разбираться".
vnbelyaev
и еще - тебе дали задание, ты и разбирайся ))))))
rukhi7
Так я не против что это супер технология, но выдавать это за, как бы, свое открытие я бы постеснялся :). Не быть мне перспективным менеджером :) !
Ivan22
ну супер технология по факту здесь это возможность и желание говорить "НЕТ" тем кто пытается пропихнуть "если фичу надо было сделать вчера - некогда анализировать, вперед быстрее копать..." Вот это действительно супер сила
IvanG
Хм если вы автор или имеет схожий опыт, то я удивлен, за 15 лет в АйТи и долгое время разработки дев тоже должен научится говорить "НЕТ".