Причина не в том, что разработка – непредсказуемый процесс. И даже не в том, что ваши проекты какие-то особые. Дело в другом, и вы легко можете это исправить.
Довольно частая проблема фаундеров и СЕО компаний аутсорс-разработки – это оценка сроков проекта. На старте он кажется равным 1, в реальности оказывается 1+1, а с учётом отклонений в ходе проекта – 1+1+1.
В результате проект выходит даже за сроки, установленные с запасом. Эту проблему фаундеры и СЕО часто стараются решить с помощью изменения подхода к ценообразованию: невозможно прогнозировать срок и стоимость заранее, на компании большие риски, перейдём на почасовую оплату. Поделим, в общем, риски срыва срока и увеличения стоимости проекта с клиентом.
С лозунгом “Нет фикспрайсу” фаундер идёт к РОПу, РОП – к сейлзам, сейлзы – к клиентам
И в момент переговоров обнаруживают, что клиент риски делить не хочет, он хочет решение своей задачи. И занимает позицию “Я хочу понимать, сколько времени и денег займёт проект, если вы не можете мне этих данных предоставить – обращусь в другое агентство”. Сейлз и сам не понимает, чем клиенту может быть удобен T&M, идёт обратно к РОПу, РОП – к СЕО, круг замкнулся.
Любое ценообразование имеет место быть, если позволяет компании быть на рынке конкурентоспособной. Но если вы теряете львиную долю клиентов, имеет смысл подумать о том, что можно сделать с вашим предложением, чтобы оно стало более привлекательным для рынка и целесообразным для вас.
Давайте посмотрим, что можно сделать, чтобы оценка сроков перестала быть настолько проблемным фактором. Тем более, что при любой модели ценообразовании делать это придётся. Для этого хорошо бы разобраться в причинах, почему эта ситуация происходит.
Сотрудникам невыгодно правильно оценивать срок
Давайте вспомним, как мы оцениваем длительность проекта. Узнаём примерное ТЗ, спрашиваем у отдела разработки, сколько времени у них это займет, чуть увеличиваем и говорим клиенту, что сделаем проект за N часов и за такую-то фиксу. Клиент доволен, бьем по рукам, начинаем.
Проект идет, N часов подходят к концу и разработчики говорят, что им нужно еще два-три N. Как же так? За чей счёт? Что с репутацией и ожиданиями клиента? Чья теперь ответственность за то, чтобы это разрулить?
Размер потенциальных убытков не выходит у фаундера из головы. А еще в ней же в очередной раз появляются мысли, что это последний проект, который вы берете по фикс-прайсу. И вообще, разработка это непредсказуемый процесс, надо было выбирать другую нишу.
Но давайте копнем глубже. Кто вообще делает проект? Как их зарплата зависит от прибыльности этого проекта? Не в вашей голове, где очевидно, что из прибыли от каждого проекта создаётся весь фонд зарплат, а в их головах. И вот тут многие аутсорс-агентства не замечают проблемы, которая кроется в собственных же сотрудниках. Вернее – в системе их мотивации.
СЕО приходит и спрашивает у РМ, почему разработчики не успевают, и в ответ слышит что-то про сложность функционала, особенности реализации, “всё оказалось сложнее, чем выглядело на старте” и тд. Как будто в этот момент ничего и не остается, кроме как принять это и идти регулировать отношения с разъяренным заказчиком.
Но дело не в том, что оценить сроки совершенно невозможно. Дело в том, что людям, которые оценивают их в вашей компании, это на самом деле не нужно. Вам – да, а им – нет.
Любой сотрудник может назвать примерный, более-менее адекватный срок на реализацию своей части работы в проекте. И если этот прогноз по сроку не реализуется, для сотрудника ничего не произойдет. Зарплата у него та же, работа у него та же, делать нужно то же.
Другое дело – когда каждый член команды действительно отвечает за свой участок. В том числе и своими деньгами. Вы сразу заметите, как повышается точность оценки сроков. А проектов, где летят сроки, становится меньше. Прибыльность проектов растет. Хороший повод снова влюбиться в свой бизнес.
Ответственность в команде распределена неверно
Следующая частая проблема – это то, что у нас в команде появляется огромное количество ролей и мы сами, по-честному, не знаем, что делают все эти люди и кто за что отвечает. Кто отвечает за сроки? Кто отвечает за реализацию в срок? Кто – за то, чтобы реализация была качественной?
Чаще всего мы думаем, что дело в людях: они безответственные, забывчивые, не проактивны, не включены в вашу компанию, не играют за вас. Но обычно это – следствие организационного хаоса.
Как правило, такие ситуации возникают, когда в момент роста компании мы натыкаемся на участок, где ответственный не справляется со своей работой. И мы, вместо того, чтобы точно выявить причину отсутствия результата, начинаем потихоньку “отщипывать” кусочки его функционала и думать, кому ещё это можно поручить. Так у нас в компании возникает излишне большое количество людей.
Каждый из этих людей ещё больше множит хаос, и вот уже нам непонятно, за что отвечает тимлид, за что – техлид, за что – СТО, за что – продакт, а за что – проджект. В теории понятно за что, а внутри вашей конкретной организации – нет. И метрик у них нет очевидных, и вводить их – непонятно, с чего начинать.
На самом деле, принимать решения о расширении команды стоит инвестиционно. То есть, сначала – сделать условия, в которых будет видно, какая точка действительно нуждается в усилении, а в какой точке – просто неквалифицированный исполнитель. Ответить себе на вопрос о том, как новый человек на конкретной роли отразится на экономике, как конкретно он повлияет на прибыль, как вы это оцените быстро. И какая нужна квалификация, чтобы он это сделал. После этого – нанимать.
В общем, запутанность процессов увеличением людей не всегда лечится. Увеличение команды – инструмент, чтобы пропускную способность этих процессов вырастить. И если вы растите хаос, получаете хаос, помноженный на количество людей.
Даже правильно оцененный проект едет из-за неверного управления
Нам кажется, что мы неверно оцениваем сроки на старте. Но часто он увеличивается по мере реализации и это не связано с техническими аспектами решения. Это связано именно с тем самым организационным хаосом, о котором мы говорили.
Если руководитель проекта не умеет внутри каждой итерации правильно выявлять причину, по которой срок съезжает, и работать с ней, ему не удастся выпустить проект вовремя.
Для того, чтобы это делать, нужно хорошо утвердиться в том, какие причины существуют. Причин невыполненной работы всего 2 в природе: тот, кто отвечает за неё, сделал недостаточное количество действий либо у него недостаточная квалификация.
И работать нужно через них. Иначе мы сами допускаем в компании культуру невыполнения задач, а потом удивляемся, что она становится массовой.
Если у нас верно организованы процессы, каждый участник команды находится на своём месте – симптомов типа “срок сгорел, а мы ничего не сделали” у нас не возникает. Решается это, как вы понимаете, не ценообразованием, а работой с корпоративным управлением и командой.
В нашем ТГ-канале мы делимся своим опытом о том, как организовывать процессы и команду вокруг них.
Довольно частая проблема фаундеров и СЕО компаний аутсорс-разработки – это оценка сроков проекта. На старте он кажется равным 1, в реальности оказывается 1+1, а с учётом отклонений в ходе проекта – 1+1+1. В результате проект выходит даже за сроки, установленные с запасом. Эту проблему фаундеры и СЕО часто стараются решить с помощью изменения подхода к ценообразованию: невозможно прогнозировать срок и стоимость заранее, на компании большие риски, перейдём на почасовую оплату. Поделим, в общем, риски срыва срока и увеличения стоимости проекта с клиентом. А здесь предлагаем поделиться, как вы обычно решаете проблемы со сроками внутри своих проектов.
Комментарии (9)
HEXFFFFFFFF
30.12.2023 15:42+2Все не совсем так.! Во первых программист получающий фиксированную ЗП не просто ни заинтересован в результате- он заинтересован гадить компании.
Я сам 30 лет проработал в IT руководителем. Всегда мой доход зависил от результата. Но был тут момент когда был перебой в работе и пригласили в проект и настаивали на фиксированной ЗП. Изначально я по привычке "тянул проект"- спорил с руководителями, программистам. Пытался навязать проекту выбор правильных технологий, подобрать квалифицированных людей, организовать правильную последовательность работ. В результате наниматель был мною сильно не доволн))) И тут я сообразил - я же наемный работник, получаю просто ЗП. Зачем я спорю с начальством? Скажут мне писать ИИ с нуля на ассемблере что бы сложить два плюс два- не буду спорить! Правда толку от моей работы при этом ноль, но ЗП то все равно идет! А чем больше времени они проект делают тем больше больше денег мне заплатят. В результате все в компании стали мной резко довольны, ЗП еще повысили))) Правда проект они не сделали, через год разорились и я ушел)))) Т.е получилось что стратегия поддакивать начальству и гадить проекту гораздо более выгодная чем делать работу хорошо для наемного программиста с фиксированной ЗП.
Во вторых у программиста в зависимости от квалификации срок выполнения задачи может отличаться в десятки раз. Поэтому гораздо выгоднее иметь грамотного, дорогого специалиста чем хуже но дешевле. Сам я неоднократно сталкиваюсь с тем что то что я могу сделать за день работник может делать месяц.
Поэтому первое правило -только лучшие, пусть дорогие специалисы. Второе правило - только сдельная работа. И тогда ваш бизнес пойдет...
serguey_issakov
30.12.2023 15:42У нас маленькая компания, я сам отвечаю за оценку, но в любом случае дляоценки используем PERT метод и делаем регулярно ретро с анализом утечек времени.
Shotgun12G
30.12.2023 15:42+5Причин невыполненной работы всего 2 в природе: тот, кто отвечает за неё, сделал недостаточное количество действий либо у него недостаточная квалификация.
Либо мало работал, либо дурак? Серьезно?
ruomserg
30.12.2023 15:42+2FIX-price проекты - вероятно худшее что можно придумать. Смотрите - когда мы работаем по T&M, то рисков у нас немного, но и прибыль невелика (и она очень плохо масштабируется, потому что это по-сути наценка на человеко-часы). Другой конец спектра - это когда мы развиваем собственый продукт. Тут у нас куча рисков, но вся созданная интеллектуальная собственность - наша, и мы можем в случае удачи продавать продукт (возможно, с кастомизацией) много раз подряд. А это - масштабирование и прибыль.
Занимаясь же фикс-прайсом, вы берете себе рисков почти как в собственном продукте - но отдаете заказчику интеллектуальный результат, и не можете его продать более одного раза. Как бы собраны в одном месте все недостатки без значимых достоинств...
Batalmv
30.12.2023 15:42+5Прикольная статья
это оценка сроков проекта. На старте он кажется равным 1, в реальности оказывается 1+1, а с учётом отклонений в ходе проекта – 1+1+1.
Чуда нет, если вы не попадаете с оценкой и/или что-то делаете неэффективно, то вы неконкурентно способны. Вам нужно меняться изнутри, схема контрактинга вас не спасет, так как у вас то может быть и T&M, но у заказчика то точно есть бюджет, и если он за него не получил то что надо - проект failed. Да, юридически и финансово на этом проекте вашей компании можно "отпетлять", но репутация потерена. Много фэйлов и лавочку можно будет закрывать.
невозможно прогнозировать срок и стоимость заранее, на компании большие риски, перейдём на почасовую оплату.
На всякий случай, схем все таки минимум три:
fixed
dedicated team
T&M
Все таки это важно, так как схема dedicated team существенно отличается.
Но давайте копнем глубже. Кто вообще делает проект? Как их зарплата зависит от прибыльности этого проекта? Не в вашей голове, где очевидно, что из прибыли от каждого проекта создаётся весь фонд зарплат, а в их головах. И вот тут многие аутсорс-агентства не замечают проблемы, которая кроется в собственных же сотрудниках. Вернее – в системе их мотивации.
Нет, проблема не там. Мы можете меня люто замотивировать, вот прям так как не мотивировал никто от сотверения мира, но я не пробегу 100ку за 10 секунд. Никак! Вообще, даже теоретически. Проблема только в том, что вы что-то делаете нет так. Когда вы поймете root cause - вы его можете попробовать исправить.
Но дело не в том, что оценить сроки совершенно невозможно. Дело в том, что людям, которые оценивают их в вашей компании, это на самом деле не нужно. Вам – да, а им – нет.
Дело в том, что ... вы не можете это сделать. Смотрите, чисто математически всегда будут те, кто оценил верно, и те - кто нет. Кто-то в большую сторону, кто-то в меньшую. Просто по закону больших чисел. И часто в этом може не быть чьей-то заслуги. Просто кого-то дельфины вытолкали на берег, а кого-то - в море.
Любой сотрудник может назвать примерный, более-менее адекватный срок на реализацию своей части работы в проекте.
Вот это самая жесткая ошибка. Смотрите, начнем сначала.
Аналитик - он же не знает, насколько заказчик вообще знает, что он хочет. Может он из породы тех, кто меняет направление "хотелки" каждую неделю. Или окажется, что внутри заказчика есть три подразделения, которые вообще не могут дать согласованных требований. Что он может оценить
Разработчик - он уже условно дает оценку второго порядка, так как ему надо оценить время реализации еще не написанных требований (в которых уже большая погрешность). И тут снова - он же не знает, насколько эти требования будут стабильные, качественные. В большой компании может оказаться, что он этого аналитика вообще первый раз видит :)
Тестировщик вообще уже вторая производная и проще его оценку получить методом умножения оценки разработчика на 0.3, чем о чем-то спрашивать :)
В реале оценивается проект в целом. Тут возможны варианты:
яблоки подобны во всем. Условно если среди прошлых проектов были на 10-20-30-50, а этот похож на 23,5 - то берем среднее между 20 и 30. Офигенный метод, советую
можно применить коэфициенты к разным участникам, например "заказчик путался в показаниях еще до подписания контратка" - +20%, "заказчик приводил с собой 100500 неизвестных людей, которые спорили меджу собой" - +50%, у нас в команде "два джуна, вместо трех миддлов" - +100% и т.д.
Так реально работает и такую оценку можно получить относителдьно быстро (а часто ее надо быстро давать). Можно бить по задачам, но в целом - все это писано вилами по воде. Но тоже может быть полезным, чтобы получить оценки "снизу" и "сверху", и если они сильно разошлись - подумать почему? Есть еще техники попарного сравнения, условно есть одна задача 5, а вторая 7 - задать вопрос "почему". Пройдя выбранное некоторое количество пар можно сильно повысить качество оценки по частям
Другое дело – когда каждый член команды действительно отвечает за свой участок. В том числе и своими деньгами
Щассс, а прибылью поделитесть? Камрад, ты тут сильно промазал. Сотрудники отвечает за то, что дарит тебе свое время 40 часов в неделю в обмен на деньги. Ты же береш на себя риски и получаеш прибиль. Либо я компаньон, либо "вот мои часы, пока ты даешь мне деньги". Но еще дело даже не в этом. После первой попытки наказать меня рублем, следующая оценка будет точно гарантированно выполнимая :) Только ни одного заказчика ты не найдешь, потому что она будет с огромным запасом :) А попытка продавить оценку сотрудника окончится пониманием, что помимо воды есть еще "несжимаемые" субстанции :) потому что боль от предыдущего штрафа ...
Дальше, ну если у вас непонятно, кто за что отвечает, а вы рассуждаете о том, увеличивать или нет - ну а как вы хотите? Вы ж не ныряете вглубь, в команды и процессы внутри нее :) Но рецепт прост:
надо быть более эффективным
для этого надо "нырять" внутрь и искать причину всего
найденную причину исправлять
результаты мониторить
А вы, у меня так сложилось, хотите пройтись по верхах и рыбку выловить :)
Dekmabot
30.12.2023 15:42+1По фиксированной цене можно продавать только готовый продукт, а любой кастдев - это всегда субъективная оценка. И так не только в нашей с вами айтишечке. Стадион/завод/дом/мост также строят по примерной оценке плюс риски. А в рисках может быть и x2 и больше.
newintellimouse
Прелестно. Каждый член команды, который будет отвечать деньгами за предпринимательские риски директора и фаундера, будет мазать лыжи на выход.
Inocs
В добавок если человек отвечает за риски, то с ним должны делиться прибылью, а не зарплатой.