5 грехов проджект-менеджмента, которые мы пофиксили у нас в команде
Chibbis - агрегатор доставки готовой еды, и за последние пару лет мы выросли в заказах, людях и проектах. У нас работает 22 человека в IT, ведь агрегатор - это сложный, многогранный и нагруженный продукт. Поэтому крайне важно выстроить процессы в IT. За это время мы “набили много шишек” и исправили немало ошибок.
В этой статье мы выделили 5 моментов проджект-менеджмента, которые были терпимы, когда мы были небольшим стартапом, и которые стали недопустимы при масштабировании.
1. «Ну там делов на 2-3 часа, давай запилим сейчас быстро!»
В Chibbis мы отказались от абстрактной и поверхностной оценки объема работ.
Перед тем, как задачу возьмут в работу, она проходит несколько этапов согласования:
- Продакт-менеджер определяет приоритет и ценность работы для бизнеса
- Проджект-менеджер создает техническое задание для крупных задач и детальное описание для небольших
- Проходит оценка техническими руководителями поставленной задачи на доступность, понятность и выполнимость
- Проходит оценка трудозатрат тимлидом проекта и командой
- Устанавливается планируемый релиз исходя из приоритета относительно других задач
- Разработчик приступает к задаче, когда до нее доходит очередь
Тут нет бюрократии. Во-первых, у нас простая горизонтальная структура: все этапы проходят быстро и открыто. Во-вторых, мы тратим время на подготовку задачи, зато существенно экономим на ее реализации и доработках, поэтому по итогу работаем меньше.
2. «Если сразу делать без багов, то и фиксить баги не придется!»
Нам важно выпускать отличный продукт. Баг в итоге превращается в недовольного пользователя, а своих пользователей мы любим и не хотим терять.
Мы не хотим нагружать техническую команду на 100% человеческих возможностей. Мы даем время для спокойного исправления недочетов. Чтобы и с задачами справились без переносов, и ошибки поправили. Таким образом, довольны и проджекты, и разработчики.
Конечно, бывает так, что за весь релиз упало два бага на два часа работы, а заложено у нас целых 40% мощности. Тогда это повод спокойно заняться самообразованием, либо отрефакторить что-нибудь и заняться техническим долгом.
3. «Если ты не успел запилить фичу в рамках своей же оценки по трудозатратам – поработай ночью, чтобы успеть»
Если по какой-то причине задачу не получается выполнить в срок, то мы всегда идем навстречу команде. В Чиббис, если у сотрудника случается личный форс-мажор, то доверяем и помогаем.
Назначаем другого инженера, если фичу надо срочно релизить, либо сдвигаем сроки.
Так наши разработчики знают, что они не подводят нас и мы их ценим. С их стороны ни разу не было злоупотреблений. Мы думаем, что у нас изначально собираются такие люди, которые разделяют нашу культуру доверия и открытости.
4. «А вот на прошлой встрече один разработчик сказал, что эту задачу можно сделать за 1,5 сторипоинта. Поэтому я тут 3 не поставлю»
В Чиббисе для оценки задач мы используем фреймворк RICE, скорректированный под наши практики. Как частный независимый игрок ИТ-рынка, в своих решениях мы держим в голове ROI.
Мы используем систему RICE:
- Reach - на какое количество юзеров влияет фича,
- Impact - насколько сильно она на них влияет,
- Confidence - насколько мы уверены, что правильно оценили прошлые параметры,
- Estimate - сколько мы потратим на реализацию этой фичи.
Первые три показателя оценивают продакт-менеджеры. Казалось бы, этого хватает, чтобы сделать всю оценку. Но появляется много проектов, они становятся сложнее, появляются специалисты, которых надо делить между командами. Крайне важно максимально точно подходить к оценке. Кстати, для этого мы начали оцениваем фичи по часам, а не по дням.
Мы - независимый игрок, и для нас ключевая метрика - это ROI. Правильно понять, попадаем ли мы в цель по ROI, можно только посчитав все составляющие.
Мы закладываем время для разработчиков на то, чтобы понять задачу. Они применяют разные методы: от плэнинг покера до ведерок. Но результат один: потратив час времени, мы получаем комплексную оценку задач на две недели вперед. Это позволяет лучше планировать релизы, а разработчикам не гнаться за выдуманными сроками.
5. «Ты делай задачу, а зачем это нужно продактам, им виднее»
Нет такой задачи, смысл которой не может понять разработчик. Ему необходимо понимать, зачем он делает что-то.
Мы взяли за правило для каждой задачи описывать проблему, которую она будет решать, как именно она будет это делать и какой эффект она принесет для бизнеса. Раз в месяц мы подводим итоги реализованных задач. Смотрим, как они повлияли на наши показатели.
Зная цель задачи, разработчики предлагают дополнительные решения: «Если мы добавляем поле вот тут, чтобы юзеры Х получали информацию, то может сделаем так, что у юзеров Y будет свое вот такое поле? Усложним задачу на 2-3 часа работы, но должно быть полезно?»
Но вовлеченность тоже никто не отменял. Когда в понедельник ты сделал кнопку красной, а в следующий понедельник узнаешь, что благодаря твоей красной кнопке мы получили Х новых заказов – это приятно.
Мы на себе испытали все проблемы, которые могут возникнуть в рамках проджект-менеджмента. И пришли к выводу, что четкая оценка объема работ, погоня за качеством (а не количеством), взаимовыручка и понимание, что и зачем мы делаем - это основа качественной работы разработчиков. Используя эти способы, можно уменьшить текучку кадров и повысить качество продукта.
Присоединиться к нашей команде можно тут.
Да забавно, а ведь есть конторы где 2 itшника тусуются с кучей подрядчиков из вне, итог всегда просто - хотелки требуют кровавой расправы или второй должен улыбаться и плакать
Комментарий недоступен
Как-то у вас все смешалось в пункте про планирование.
Баги - это ошибки приложения, которые команда пропустила.
Рефакторинг - это технологический кредит, который растет с ростом числа зависимостей.
а есть еще бизнесовый рефакторинг, это когда вы дорабатываете пропущенные кейсы в уже выпущенных фичах
в среднем по индустрии разбивка по типам задач выглядит так: https://t.me/pm_god/187
Если продакт-оунер где-то загулял, а спринт пора начинать, берите инициативу в свои руки и планируйте загрузку команды примерно так:
40% - новые фичи;
15% - технический рефакторинг: удаление и переделка старого кода, долги по тестам, CI;
15% - бизнесовый ...
Если продакт-оунер где-то загулял, а спринт пора начинать, берите инициативу в свои руки и планируйте загрузку команды примерно так:
40% - новые фичи;
15% - технический рефакторинг: удаление и переделка старого кода, долги по тестам, CI;
15% - бизнесовый рефакторинг: доработка и улучшение уже выпущенных фич;
10% - багфиксинг: ошибки приложения, которые не вошли в предыдущие два пункта. Ошибки новых фич рекомендуется закладывать в первые 40%;
10% - разработка, а-ля RnD: проверка гипотез, прототипы фич, всякие пруф оф концепт для клиентов, попробовать новые библиотеки и фреймворки;
10% - запас на случай непредвиденных задач (а они будут);
------------------------------
Если этот рецепт вам не подходит, держите упрощенный, работающий во все времена:
❗Делать надо те задачи, которые приносят деньги. А те, что не приносят - не делать.