Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:
Снижая риски добавлением этапов, мы снижаем рентабельность* всего проекта.
Свою рентабельность, в смысле. Когда я обнаружил это с помощью простой excel-таблицы, и посчитал, во что обходится добавление еще одного этапа — я присвистнул.
Итак, у нас есть абсолютно типовые этапы:
- Пресейл [0.10];
- Продажа [0.50];
- Аналитика [0.8];
- Дизайн [0.9];
- Верстка [0.9];
- Кодинг [0.9];
- Поддержка [0.8];
Цифры в скобках — это вероятность того, что проект у вас перейдет из одной фазы в другую с успехом и прибылью. Вымышленные, но довольно близкие к реалиям. Например, если у вас заказали только дизайн — то циферка в скобках уменьшается. Вы можете сами посчитать это для своей компании. Делайте это хотя бы раз в год. Просто проанализируйте все продажи и проекты. Будет где-то
* У нас была довольно бурная полемика по поводу того, корректно ли использовать слово «рентабельность», ведь мы же получаем деньги за каждый этап. То есть рентабельность этапов не снижается. Однако проект, отвалившийся на середине цепочки, означает, что разработчики на последних этапах внезапно могут оказаться недогруженными и проедят прибыль с предыдущих этапов, вместо того, чтобы ее генерировать. Кроме того, именно на заключительных этапах проект обретает ту форму, в которой его хочется положить в портфолио, поставить на нем копирайт и гордиться им. А это — привлечение новых проектов и +100 к боевому духу. Так что пусть будет «рентабельность».
Это упражнение сразу отбивает желание добавлять новые этапы в рабочий процесс.
Просто откройте калькулятор, введите туда 0.9, нажмите [X] и тыкайте кнопку [=] столько раз, сколько у вас этапов.
Каждый из этих этапов можно разбить на более мелкие стадии или делать много итераций по коду и дизайну. Так обычно и происходит на крупных проектах. В основном, именно такими мы и занимаемся. Это важно, потому что на крупном проекте — продажа, ухаживание за клиентом, обретение взаимного доверия и уважения — одна из очень затратных операций. Причем очень долгая и непредсказуемая. А теперь самое интересное:
Дорогая и непредсказуемая операция есть в начале и в конце каждого этапа рабочего процесса.
Фактически мы должны продать результат текущего этапа и разработку следующего каждый раз, когда у нас на руках появилось что-то, что можно показывать нашему клиенту и использовать это. Обычно это идет как по маслу. Но вся правда в том, что ваша хорошая работа не всегда влияет на то, продастся ли следующая фаза.
Иногда даже наоборот: хорошо сделанный прототип четко даст понять клиенту, что проект делать не надо.
Получается, что чем больше этапов и итераций проходит проект в agile-процессе, тем больше демонстраций, а каждая демонстрация — это риск того, что клиент тормознет проект. Или устроит ТЯГОМОТИНУ!
Тут нет никакого противоречия с маркетингом. У маркетоидов вообще для этого придуман инструмент: воронка продаж. Как-то вечером мне стало скучно, и я решил посчитать, сколько обращений мне нужно иметь «на входе», чтобы обеспечить:
- Оптимальную загруженность команд на проектах.
- Желаемый уровень дохода моей компании.
Я исходил из того, что у меня 8 команд, и мне нужны примерно 4-6 проектов на стадии РЕЛИЗА за месяц.
Итогом стала примерно такая табличка:
В столбце «вероятность перехода дальше» — вероятность, с которой проект перейдет из текущей фазы в последующую. В строках — этапы, через которые проходит проект.
Например, минимально у нас должен быть 137 проектов на фазе лида за месяц. С вероятностью 0,1 каждый из них переходит в фазу сделки (т.е. остается 14 проектов). И так далее — из всех входящих только 4 проекта будут доведены до фазы релиза.
Мне удобно использовать канбан-доску для хранения всего списка проектов. Минимальное и максимальное количество проектов я использую как индикаторы для каждой из колонок (доска подсветит их нужным цветом, если что-то пошло не так, и если на какой-то фазе слишком мало или слишком много проектов). Кроме того, я могу прикинуть, сколько всего карточек (суммарный work in porgress) допустимо у меня на канбан-доске. В нашем случае это 39 и 59 проектов. Еще удобно считать, сколько денег у меня «застряло» на каждой фазе.
Наверное, если бы я был не такой ленивый, я бы постоянно мониторил, насколько перегружены или недогружены мои менеджеры проектов. Я бы даже сделал такую табличку:
Но обычно это и так понятно по их внешнему виду, зачем такие заморочки? 😉
Все просто. Теперь я рискую и иногда делаю бесплатную работу осознанно!
Почему? Я знаю, что разбиение проекта на более мелкие этапы:
- Снижает риски «не уложиться в оценку» (хорошо).
- Повышает риск «невыпуска» проекта в полном объеме от изначально задуманного (плохо) и добавляет тяяягомоооотины (очень-очень плохо).
Кроме того, я знаю (и прогнозирую) вероятную загрузку менеджеров и их команд на пару месяцев вперед.
И иногда мне выгоднее, чтобы менеджер и команда взяли на себя больше рисков по неопределенности. НЕ разбивали проект на дополнительные этапы. Или даже проделать какой-то из этапов как будто бы за свой счёт. Например, аналитику. Лишь бы быстрее и без потерь пропихнуть проект на следующий этап. Который уже окупит все. Ибо бесплатно работать — грех 😉
Так что отслеживайте количество проектов в работе, рискуйте и иногда играйте с вашим калькулятором. Всем аджайл, пацаны!
ссылка на оригинал статьи http://habrahabr.ru/post/179745/
Добавить комментарий