5 грехов проджект-менеджмента, которые мы пофиксили у нас в команде
Chibbis - агрегатор доставки готовой еды, и за последние пару лет мы выросли в заказах, людях и проектах. У нас работает 22 человека в IT, ведь агрегатор - это сложный, многогранный и нагруженный продукт. Поэтому крайне важно выстроить процессы в IT. За это время мы “набили много шишек” и исправили немало ошибок.
В этой статье мы выделили 5 моментов проджект-менеджмента, которые были терпимы, когда мы были небольшим стартапом, и которые стали недопустимы при масштабировании.
1. «Ну там делов на 2-3 часа, давай запилим сейчас быстро!»
В Chibbis мы отказались от абстрактной и поверхностной оценки объема работ.
Мы не просим разработчика сразу оценить и взять в работу задачу, пока пьем кофе на кухне, подсовывая ему описание на салфетке.
Перед тем, как задачу возьмут в работу, она проходит несколько этапов согласования:
- Продакт-менеджер определяет приоритет и ценность работы для бизнеса
- Проджект-менеджер создает техническое задание для крупных задач и детальное описание для небольших
- Проходит оценка техническими руководителями поставленной задачи на доступность, понятность и выполнимость
- Проходит оценка трудозатрат тимлидом проекта и командой
- Устанавливается планируемый релиз исходя из приоритета относительно других задач
- Разработчик приступает к задаче, когда до нее доходит очередь
Тут нет бюрократии. Во-первых, у нас простая горизонтальная структура: все этапы проходят быстро и открыто. Во-вторых, мы тратим время на подготовку задачи, зато существенно экономим на ее реализации и доработках, поэтому по итогу работаем меньше.
Тщательный подход к оценке ведет к лучшему планированию. У нас нет авралов, у нас ничего не горит. Мы знаем, над чем и как будем работать. Мы уделяем планированию достаточно времени, но зато это позволяет разгрузить разработчиков от переделок и доработок.
2. «Если сразу делать без багов, то и фиксить баги не придется!»
Нам важно выпускать отличный продукт. Баг в итоге превращается в недовольного пользователя, а своих пользователей мы любим и не хотим терять.
Можно ли что-то написать без багов? Можно, но потом баги все равно появятся. Поэтому мы пришли к модели, и в каждом релизе мы оставляем от 30 до 40% от мощности релиза на правки.
Мы не хотим нагружать техническую команду на 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