Рассказываю, как наша компания адаптируется к изменениям требований при планировании проектов. Материал поможет руководителям веб-студий всегда делать проекты прибыльными. Клиенты digital-компаний смогут лучше ориентироваться на рынке услуг и понимать, в каких случаях можно все починить «по гарантии», и где лучше не экономить на незаменимом.
Как бы тщательно мы ни планировали, неизбежно наступает момент, когда приходится вносить корректировки. Меняются условия, задачи, расходы и затраченное время. А вместе с этим бюджет проекта, что может привести к сокращению прибыли и в более тяжелых случаях — к убыткам.
Итак, что нам нужно, чтобы изменения требований на проектах не застали нас врасплох, а работа получила четкий и действенный алгоритм на все случаи жизни?
Если вы занимаетесь заказной разработкой, перед вами всегда будут стоять три вопроса:
Как правильно распределить денежные и временные ресурсы?
Как оценить загрузку специалистов?
Как не создать убытки и сохранить запланированную себестоимость?
Если поначалу кажется, что с первым вопросом все ясно — нужно только правильно планировать бюджет, — то второй вносит свои коррективы. Дело в том, что общие затраты на проект составляются в том числе из зарплат сотрудников. Оценка трудозатрат специалистом — субъективна, при этом зарплата, которую он получает, никак вам не гарантирует рентабельность на отработанных им объёмах. Поэтому чем большую зарплату человек получает, тем эффективнее он должен отрабатывать условные 160 часов в месяц.
Так как же объективно оценить загрузку каждого конкретного специалиста с учетом рентабельности отработанных часов?
Тут на помощь приходит расчёт загрузки на производстве. Если сможете преодолеть субъективность, рассчитаете количество необходимых ресурсов для выполнения задачи, обоснуете их клиенту, тогда избежите убытков и получите прибыль.
Как именно это лучше сделать, расскажу ниже.
Расчет загрузки специалистов
Ставки специалистов считаются по следующим параметрам:
Зарплаты сотрудников + НДФЛ + ЕСН.
Средние косвенные затраты — аренда офиса, тех.оснащение, работа бухгалтерии и другие затраты, не относящиеся к производству напрямую.
Ваша планируемая маржа.
Маржинальность заказной разработки невелика и обычно не превышает 20%. С зарплатами сотрудников выше более-менее разобрались. Косвенные затраты мы рекомендуем считать на каждого специалиста, а не на «весь офис». Так вы будете понимать, сколько вам стоит один специалист (эти данные будут полезны когда вы будете считать нагрузку при резком повышении требований, например за месяц разработать MVP пяти новых сервисов, в течение двух недель перенести все данные на российские сервера и так далее). Помните, что иногда дешевле нанять ещё одного сотрудника, чем требовать сверхурочных от уставшего коллектива.
Если речь идет о руководителях (не производственный персонал), то плюсуем сюда уже зарплаты, налоги и косвенные затраты на всех сотрудников его отдела (дизайна, фронтенда или бэкенда). Так мы понимаем, как работает весь отдел, и сколько стоит эта работа.
Что будет если не работать с изменениями требований на проектах
Последствия можно поделить на две категории: административные последствия и влияние на качество.
Административные последствия
Некорректный расчёт загрузки специалистов: вроде как изначально загрузка была оптимальной, однако произошли изменения в требованиях и появились дополнительные работы. Все графики (например, сроки сдачи проекта) отныне не соответствуют действительности, опираться на них нельзя.
Переработка специалистов: ваши сотрудники работают сверхурочно, без обеда и тому подобное. Это ведет к выгоранию, снижению мотивации и ошибкам.
Потеря прибыли: вы тратите на проект больше, чем планировали изначально, а значит рискуете не окупить проект. Доходы ограничены договором, а себестоимость производства в виде ФОТ стабильна.
Сокращение команды: люди, которые постоянно перерабатывают, быстрее выгорают. Предприятия, которое не умеет планировать с учетом изменений, рискуют столкнуться с высокой ротацией кадров. А это — допрасходы на обучение, трата времени на введение в курс дела и т.д.
Убытки и стагнация бизнеса: конечный пункт, к которому приведет все вышеперечисленное, если вы не сумеете создать адекватный ответ на возникающие изменения.
Влияние на качество
Страдает не только коллектив, неверная политика реагирования на изменения требований затрагивает и сам продукт:
Упрощение функциональности: к примеру, разработчиков просят добавить новые для изначальных требований функции. Если это не отследить, часов для работы станет больше, а денег — столько же. Это повлечет экономию на качестве: сократятся объёмы проектирования архитектуры и многое другое. При этом клиент, внесший изменения в требования, не предполагает, что новое будет добавлено в ущерб тому, что было включено в изначальную смету.
Экономия на тестировании: самая соблазнительная часть для урезания расходов, когда проект не вписался в бюджет и временные рамки. Не успели, поэтому не протестировали. Продукт сдан, и кажется качество уже не так важнó . Кто знает, как все будет работать у покупателя?
Сокращение этапов методик испытаний: отказ от проверки инфраструктуры или pen-тестирований. Как и экономия на функциональном тестировании, может фатально сказаться на итоговом качестве.
Экономия на измерении продуктовых и бизнесовых метрик: ваш продукт работает, однако генерирует ли он заказчику прибыль? Если нет, то это может оказаться фатальным для ваших отношений с заказчиком: продукт не помогает бизнесу заказчика, а деньги на его поддержку и развитие (которым занимаетесь вы) он тратит. Логично предположить, что от таких трат скорее всего откажутся.
Важно помнить, что в заказной разработке вы фактически приобретаете вечного клиента при одном-единственном условии: ваш продукт работает эффективно. Заказчику нет смысла переходить к другому разработчику, искать «более модное» или даже более дешевое решение, так как ваше приносит ему прибыль.
Установка требований
Чтобы неприятностей не происходило, а любой ветер перемен не воспринимался как катастрофа, нужно изначально создать эффективный алгоритм фиксации требований на проекте.
Иногда думают, что чем лучше прописываешь требования, тем меньше вероятности грядущих изменений. Это мнение ошибочно.
Чем больше и конкретней вы пропишете требования, тем легче вам будет реагировать на изменения. Изменения — это хорошо: вы актуализируете продукт под внешние факторы во время разработки.
Настоящее развитие продукта никогда не заканчивается, поскольку вы постоянно улучшаете продукт под требования пользователей. Поэтому важно замерять количественные бизнес-показатели у продукта и проводить качественные исследований для формирования гипотез по улучшению бизнес-показателей, учитывая опыт пользователей. В конце концов, что плохого в том, что клиент просит вас сделать еще три дополнительных экрана?
Что важно учитывать при установке изначальных требований:
Точность изначальной оценки. Например, если вы на какую-то работу планируете 8 часов, а делаете ее за 6 — это плохо. Если наоборот 10 часов, то еще хуже. Производительность команды, или Velocity, должна быть равна 1, допустимая погрешность — 0,5 часа. Там, где можно было бы дать более выгодную ставку за 6 часов и сделать больший объема работ, вы даете оценку 8 часов, и часть работ «отваливается».
Коэффициент риска: это те самые два часа. Чтобы избежать такого несоответствия, старайтесь создавать готовые алгоритмы, просчитывать типовые задачи: например, на разработку одного экрана мы тратим 10 часов.
Жесткая фиксация требований. Не бойтесь все фиксировать с заказчиком. Чем четче вы обозначаете задачи, чем легче вам будет не только соответствовать плану, но и менять его (доказывая увеличение себестоимости). Клиентам это тоже полезно: они могут попросить изменить функциональность, а спустя некоторое время вернуться к изначальным требованиям. Если изменения вовремя не отследить, можно столкнуться с дополнительными рисками, при этом сам продукт останется таким же, каким его изначально задумывали.
Оценка рисков при изменении требований к конечному продукту
И вот, вы все просчитали, однако при этом все равно настал момент, когда потребовалось вносить изменения. И снова — без паники!
Оцениваем предстоящие изменения и корректируем стратегию.
Для этого:
Определяем влияние изменений*.
Оцениваем изменения в трудозатратах.
Обновляем таймплан.
Согласовываем с заказчиком новые даты и новые деньги.
Перераспределяем ресурсы, если необходимо.
*Влияние изменений — это когда заказчик говорит «мне нужна еще одна функция», и мы выясняем, что именно ему нужно и как долго это делать. К примеру, клиент просит добавить ещё одну страницу. Мы оцениваем, сколько часов на нужно на это доработку. Влияние изменений может быть незначительным, допустимым и критичным.
Иногда бывает так, что компания копит изменения в проекте, молча принимая новые и новые требования, а потом, ближе к дедлайну шокирует клиента новой ценой и сроком. Так делать не нужно. Чем больше вы информируете заказчика, тем больше вам доверяют. В общем случае заказчик готов платить больше, если вносит новые требования. Если нет, то именно ваша задача еще на берегу проинформировать его, что изменения будут стоить денег.
Доп. cost: ты просишь больше денег, но просишь их без уважения
Как же обосновать дополнительную стоимость с учетом изменений для клиента?
Во-первых, чем лучше информирован заказчик, тем лучше для вас. Информированный заказчик платит или заранее отказывается от того, что ведет к перерасходу. А значит, вы гарантированно не попадете на допрасходы и убытки.
Чтобы грамотно презентовать доп. cost клиенту, нужно показать, что именно вы будете делать за эти дополнительные деньги. Согласуйте с клиентом заранее и дайте объяснения, что за оговоренные рамки вы не выходите до внесения новых изменений в требования. Договоритесь «на берегу», что к трем дополнительным экранам, которые попросил клиент, не придется рисовать дополнительные шесть. Объясните, что такое количество экранов несимметрично располагается в верстке, но если они все-таки нужны, работы тоже придется оплатить.
Обычно доп.cost не пугает клиентов, если те изначально находятся в курсе всего тайминга проекта.
Инструменты минимизации рисков от изменений требований
Застраховаться от изменений можно и даже необходимо. Для этого мы используем три основных инструмента: анализ задачи, фиксация и тайминг.
1. Анализ задачи. Инструмент, способный перекрыть все риски от неожиданных изменений — предпроектное обследование (ППО). Одно дело, когда клиент хочет что-то сверх, другое — когда оказывается, что имеющаяся база недостаточна и приходится все переделывать. Поэтому изначально пристальное внимание нужно уделить возможным ограничениям системы, и тут без обследования никак.
Клиенты не всегда хотят проводить эту процедуру, и она стоит денег, однако это тот случай, когда имеет смысл уговаривать, потому что в конечном итоге в этом заинтересованы обе стороны. Бывают ситуации когда после ППО мы снижаем оценку проекта, и выигрываем тендер… помните 6 и 10 плохо, а 8 часов идеально?
2. Фиксация. Чем больше вы фиксируете в ваших отношениях с заказчиком (требования, договоры, предоплаты, тестирования), тем лучше. Сдвинули предоплату, а без нее вы не начинаете? Ничего страшного, просто вы тут же выдаете обоснование нового дедлайна, который отодвинулся на такое-то количество дней.
После любого вашего обсуждения с заказчиком должен появиться митинг-репорт. Все вехи проекта обозначайте в письменном виде. Каждое ТЗ по задачам должно быть согласовано всеми заинтересованными членами команды и отправляться к заказчику на одобрение. Чем более компетентен в происходящем клиент, тем меньше разногласий, неожиданных требований, недоразумений по поводу итоговой стоимости.
3. Тайминг. Должен быть реалистичным! Для этого я не рекомендую делать задачи более 8 часов на исполнение, — их будет сложно отслеживать. Таймплан должен хотя бы еженедельно актуализироваться (наши руководители проектов делают это ежедневно).
В автоматизации проектных задач вам поможет и ведение базы знаний. Это также хорошо скажется на вашем стиле работы с постоянными клиентами. Так, в нашу компанию порой компании-клиенты обращаются с просьбой поднять что-то по нашей документации. В такой ситуации мы выступаем еще и своего рода архиваторами и с таким партнером совершенно невозможно расстаться!
Продуктовый надзор
Последний, но самый важный пункт, который вам нужно учесть и о котором я уже не раз говорил в статье — качество итогового продукта.
Никогда не экономьте на ваших собственных знаниях о нем.
Если клиент с вами надолго, имеет смысл дать ему добавочную ценность в виде базы знаний проекта. Внутренней базой знаний пользуются разработчики и менеджеры при передаче проекта друг другу. Ведение такой базы – это расходы компании, и клиент за них не всегда готов платить. Решение о ведении базы знаний должно быть принято из нескольких факторов: рентабельности, перспективности заказчика и многих других. Но чаще всего мы ведем базу знаний даже если это снижает рентабельность.
Как работает итоговая разработка? Генерирует искомую клиентом прибыль? Оправдана ли стоимость и функциональность? Что действительно имеет смысл добавить, а от чего — отказаться, даже если клиент настаивает? Влияет ли функциональность на прибыль клиента или мы делаем работу ради работы? Внимательный и критичный анализ позволит вам научиться правильно оценивать потребности ваших клиентов. Заказчики, как правило, очень дорожат партнерством с теми, кто не пытается их уговорить на все подряд, а предлагает только действительно необходимое и работоспособное.
Удовлетворив такую потребность, вы сможете сохранять надежного и платежеспособного и преданного клиента на неограниченный срок.
[Хэштеги с ссылками удалены модератором]
