Прогноз загрузки разработчиков при массе краткосрочных проектов

На конференции Outsource People 2014 Максим Ицкович, СЕО Mobindustry Corp. рассказал о том, почему возникают проблемы с организацией и планированием загрузки на краткосрочных проектах и что с этим делать? Знакомим вас с докладом Максима.

Ситуация в компании Mobindustry Corp.:

5 ключевых финансовых показателей IT компании

Узнайте 5 главных показателей, которые должна отслеживать каждая IT-компания для роста с пояснениями и рекомендациями к каждому.

имеем 100% разработчиков
разработчики заняты на 120% — ежедневные овертаймы, постоянные опоздания сдачи проектов
60% коммерческая прибыль
200% головной боли ПМов — они были постоянно загружены коммуникацией с клиентами
Головная боль у руководителя
Текучка кадров

Надо что-то с этим делать! Но что?

В начале Максим посмотрел на график загрузки по проектам. Начал анализировать откуда растут ноги и почему происходит такая ситуация с краткосрочными проектами. Так что такое краткосрочный проект?

Краткосрочный проект состоит из трех этапов:

1. Подготовка — это когда мы к проекту готовимся, эстимейтим его, рассказываем клиенту, почему именно мы. К этому процессу привлекается около 20% программистов и их времени на техническую экспертизу, оценки и другие задачи.

2. Разработка — программист просто «пилит», а менеджер за этим присматривает.

3. Доработки — Это когда клиент выходит на связь в четыре часа ночи и говорит: «рочно, у меня завтра конференция, мне нужно бегом, на полтора часа сделать фикс». А у нас есть план, его никто не отменял.

В реальности получается, что этапы накладываются друг на друга. В чем причины?

бесконечный поток оценок
бесконечный поток ASAP доработок
текущие коммерческие проекты
внутренние проекты
низкая квалификация заказчика
низкая самоорганизация менеджеров проектов

Максим понял, что нужно вводить некие правила, которым будут следовать все: начиная с СЕО и заканчивая клиентом.

Вот эти правила:

1. Планировать за разработчика:

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

2. Планировать за ПМа:

вести карту проекта и карту клиента — индексировать сложность и нагруженность на менеджера проекта
планировать загрузку по каждому проекту и итеративно сверять план/факт
заставить менеджера принять экспертную позицию перед заказчиком

3. Дрессировать клиента:

разработка системы управления ценой (систему дискретного рейта)
управлять ожиданиями клиента. Когда клиент говорит, что мне нужно сделать эту задачу сегодня, откажите ему и обозначьте реальные сроки её выполнения.
АСАП — за дополнительную плату. Если у вас рейт – 10 долларов в час, то АСАП — это 20 долларов в час, и клиент — это должен понимать.
минимальный биллинг – 4 часа разработки
штрафы за простой. Вероятно вам знакомо, когда клиент говорит: «Я делаю дизайн, вес будет за две недели до того как вы начнете разработку». Некоторые из вас с этим сталкивались. Проходит две недели, вы начинаете разработку, и дизайн появляется. Он появляется совсем не соответствуя тому, что было предъявлено в спецификации, начинаются доработки, программисты сидят. Нужно говорить клиенту, что если вы виноваты, и это независимый от нас риск, то эта табличка «независимый от нас риск» уходит вместе с эстимейтом к клиенту.

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

Вывод:

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

Полную версию доклада Максима Ицковича вы можете посмотреть в видео: