Причина не в том, что разработка – непредсказуемый процесс. И даже не в том, что ваши проекты какие-то особые. Дело в другом, и вы легко можете это исправить.
Довольно частая проблема фаундеров и СЕО компаний аутсорс-разработки – это оценка сроков проекта. На старте он кажется равным 1, в реальности оказывается 1+1, а с учётом отклонений в ходе проекта – 1+1+1.
В результате проект выходит даже за сроки, установленные с запасом. Эту проблему фаундеры и СЕО часто стараются решить с помощью изменения подхода к ценообразованию: невозможно прогнозировать срок и стоимость заранее, на компании большие риски, перейдём на почасовую оплату. Поделим, в общем, риски срыва срока и увеличения стоимости проекта с клиентом.
С лозунгом “Нет фикспрайсу” фаундер идёт к РОПу, РОП – к сейлзам, сейлзы – к клиентам
И в момент переговоров обнаруживают, что клиент риски делить не хочет, он хочет решение своей задачи. И занимает позицию “Я хочу понимать, сколько времени и денег займёт проект, если вы не можете мне этих данных предоставить – обращусь в другое агентство”. Сейлз и сам не понимает, чем клиенту может быть удобен T&M, идёт обратно к РОПу, РОП – к СЕО, круг замкнулся.
Любое ценообразование имеет место быть, если позволяет компании быть на рынке конкурентоспособной. Но если вы теряете львиную долю клиентов, имеет смысл подумать о том, что можно сделать с вашим предложением, чтобы оно стало более привлекательным для рынка и целесообразным для вас.
Давайте посмотрим, что можно сделать, чтобы оценка сроков перестала быть настолько проблемным фактором. Тем более, что при любой модели ценообразовании делать это придётся. Для этого хорошо бы разобраться в причинах, почему эта ситуация происходит.
Сотрудникам невыгодно правильно оценивать срок
Давайте вспомним, как мы оцениваем длительность проекта. Узнаём примерное ТЗ, спрашиваем у отдела разработки, сколько времени у них это займет, чуть увеличиваем и говорим клиенту, что сделаем проект за N часов и за такую-то фиксу. Клиент доволен, бьем по рукам, начинаем.
Проект идет, N часов подходят к концу и разработчики говорят, что им нужно еще два-три N. Как же так? За чей счёт? Что с репутацией и ожиданиями клиента? Чья теперь ответственность за то, чтобы это разрулить?
Размер потенциальных убытков не выходит у фаундера из головы. А еще в ней же в очередной раз появляются мысли, что это последний проект, который вы берете по фикс-прайсу. И вообще, разработка это непредсказуемый процесс, надо было выбирать другую нишу.
Но давайте копнем глубже. Кто вообще делает проект? Как их зарплата зависит от прибыльности этого проекта? Не в вашей голове, где очевидно, что из прибыли от каждого проекта создаётся весь фонд зарплат, а в их головах. И вот тут многие аутсорс-агентства не замечают проблемы, которая кроется в собственных же сотрудниках. Вернее – в системе их мотивации.
СЕО приходит и спрашивает у РМ, почему разработчики не успевают, и в ответ слышит что-то про сложность функционала, особенности реализации, “всё оказалось сложнее, чем выглядело на старте” и тд. Как будто в этот момент ничего и не остается, кроме как принять это и идти регулировать отношения с разъяренным заказчиком.
Но дело не в том, что оценить сроки совершенно невозможно. Дело в том, что людям, которые оценивают их в вашей компании, это на самом деле не нужно. Вам – да, а им – нет.
Любой сотрудник может назвать примерный, более-менее адекватный срок на реализацию своей части работы в проекте. И если этот прогноз по сроку не реализуется, для сотрудника ничего не произойдет. Зарплата у него та же, работа у него та же, делать нужно то же.
Другое дело – когда каждый член команды действительно отвечает за свой участок. В том числе и своими деньгами. Вы сразу заметите, как повышается точность оценки сроков. А проектов, где летят сроки, становится меньше. Прибыльность проектов растет. Хороший повод снова влюбиться в свой бизнес.
Ответственность в команде распределена неверно
Следующая частая проблема – это то, что у нас в команде появляется огромное количество ролей и мы сами, по-честному, не знаем, что делают все эти люди и кто за что отвечает. Кто отвечает за сроки? Кто отвечает за реализацию в срок? Кто – за то, чтобы реализация была качественной?
Чаще всего мы думаем, что дело в людях: они безответственные, забывчивые, не проактивны, не включены в вашу компанию, не играют за вас. Но обычно это – следствие организационного хаоса.
Как правило, такие ситуации возникают, когда в момент роста компании мы натыкаемся на участок, где ответственный не справляется со своей работой. И мы, вместо того, чтобы точно выявить причину отсутствия результата, начинаем потихоньку “отщипывать” кусочки его функционала и думать, кому ещё это можно поручить. Так у нас в компании возникает излишне большое количество людей.
Каждый из этих людей ещё больше множит хаос, и вот уже нам непонятно, за что отвечает тимлид, за что – техлид, за что – СТО, за что – продакт, а за что – проджект. В теории понятно за что, а внутри вашей конкретной организации – нет. И метрик у них нет очевидных, и вводить их – непонятно, с чего начинать.
На самом деле, принимать решения о расширении команды стоит инвестиционно. То есть, сначала – сделать условия, в которых будет видно, какая точка действительно нуждается в усилении, а в какой точке – просто неквалифицированный исполнитель. Ответить себе на вопрос о том, как новый человек на конкретной роли отразится на экономике, как конкретно он повлияет на прибыль, как вы это оцените быстро. И какая нужна квалификация, чтобы он это сделал. После этого – нанимать.
В общем, запутанность процессов увеличением людей не всегда лечится. Увеличение команды – инструмент, чтобы пропускную способность этих процессов вырастить. И если вы растите хаос, получаете хаос, помноженный на количество людей.
Даже правильно оцененный проект едет из-за неверного управления
Нам кажется, что мы неверно оцениваем сроки на старте. Но часто он увеличивается по мере реализации и это не связано с техническими аспектами решения. Это связано именно с тем самым организационным хаосом, о котором мы говорили.
Если руководитель проекта не умеет внутри каждой итерации правильно выявлять причину, по которой срок съезжает, и работать с ней, ему не удастся выпустить проект вовремя.
Для того, чтобы это делать, нужно хорошо утвердиться в том, какие причины существуют. Причин невыполненной работы всего 2 в природе: тот, кто отвечает за неё, сделал недостаточное количество действий либо у него недостаточная квалификация.
И работать нужно через них. Иначе мы сами допускаем в компании культуру невыполнения задач, а потом удивляемся, что она становится массовой.
Если у нас верно организованы процессы, каждый участник команды находится на своём месте – симптомов типа “срок сгорел, а мы ничего не сделали” у нас не возникает. Решается это, как вы понимаете, не ценообразованием, а работой с корпоративным управлением и командой.
В нашем ТГ-канале мы делимся своим опытом о том, как организовывать процессы и команду вокруг них.
Довольно частая проблема фаундеров и СЕО компаний аутсорс-разработки – это оценка сроков проекта. На старте он кажется равным 1, в реальности оказывается 1+1, а с учётом отклонений в ходе проекта – 1+1+1. В результате проект выходит даже за сроки, установленные с запасом. Эту проблему фаундеры и СЕО часто стараются решить с помощью изменения подхода к ценообразованию: невозможно прогнозировать срок и стоимость заранее, на компании большие риски, перейдём на почасовую оплату. Поделим, в общем, риски срыва срока и увеличения стоимости проекта с клиентом. А здесь предлагаем поделиться, как вы обычно решаете проблемы со сроками внутри своих проектов.