Разработка
Chibbis

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 часа работы, но должно быть полезно?»

Но вовлеченность тоже никто не отменял. Когда в понедельник ты сделал кнопку красной, а в следующий понедельник узнаешь, что благодаря твоей красной кнопке мы получили Х новых заказов – это приятно.

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

Присоединиться к нашей команде можно тут.

0
2 комментария
Кустарный коммент

Да забавно, а ведь есть конторы где 2 itшника тусуются с кучей подрядчиков из вне, итог всегда просто - хотелки требуют кровавой расправы или второй должен улыбаться и плакать

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Читать все 2 комментария
null