Комментарии 11
Другое дело – когда каждый член команды действительно отвечает за свой участок. В том числе и своими деньгами.
Прелестно. Каждый член команды, который будет отвечать деньгами за предпринимательские риски директора и фаундера, будет мазать лыжи на выход.
Все не совсем так.! Во первых программист получающий фиксированную ЗП не просто ни заинтересован в результате- он заинтересован гадить компании.
Я сам 30 лет проработал в IT руководителем. Всегда мой доход зависил от результата. Но был тут момент когда был перебой в работе и пригласили в проект и настаивали на фиксированной ЗП. Изначально я по привычке "тянул проект"- спорил с руководителями, программистам. Пытался навязать проекту выбор правильных технологий, подобрать квалифицированных людей, организовать правильную последовательность работ. В результате наниматель был мною сильно не доволн))) И тут я сообразил - я же наемный работник, получаю просто ЗП. Зачем я спорю с начальством? Скажут мне писать ИИ с нуля на ассемблере что бы сложить два плюс два- не буду спорить! Правда толку от моей работы при этом ноль, но ЗП то все равно идет! А чем больше времени они проект делают тем больше больше денег мне заплатят. В результате все в компании стали мной резко довольны, ЗП еще повысили))) Правда проект они не сделали, через год разорились и я ушел)))) Т.е получилось что стратегия поддакивать начальству и гадить проекту гораздо более выгодная чем делать работу хорошо для наемного программиста с фиксированной ЗП.
Во вторых у программиста в зависимости от квалификации срок выполнения задачи может отличаться в десятки раз. Поэтому гораздо выгоднее иметь грамотного, дорогого специалиста чем хуже но дешевле. Сам я неоднократно сталкиваюсь с тем что то что я могу сделать за день работник может делать месяц.
Поэтому первое правило -только лучшие, пусть дорогие специалисы. Второе правило - только сдельная работа. И тогда ваш бизнес пойдет...
У нас маленькая компания, я сам отвечаю за оценку, но в любом случае дляоценки используем PERT метод и делаем регулярно ретро с анализом утечек времени.
Причин невыполненной работы всего 2 в природе: тот, кто отвечает за неё, сделал недостаточное количество действий либо у него недостаточная квалификация.
Либо мало работал, либо дурак? Серьезно?
FIX-price проекты - вероятно худшее что можно придумать. Смотрите - когда мы работаем по T&M, то рисков у нас немного, но и прибыль невелика (и она очень плохо масштабируется, потому что это по-сути наценка на человеко-часы). Другой конец спектра - это когда мы развиваем собственый продукт. Тут у нас куча рисков, но вся созданная интеллектуальная собственность - наша, и мы можем в случае удачи продавать продукт (возможно, с кастомизацией) много раз подряд. А это - масштабирование и прибыль.
Занимаясь же фикс-прайсом, вы берете себе рисков почти как в собственном продукте - но отдаете заказчику интеллектуальный результат, и не можете его продать более одного раза. Как бы собраны в одном месте все недостатки без значимых достоинств...
Прикольная статья
это оценка сроков проекта. На старте он кажется равным 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 часов в неделю в обмен на деньги. Ты же береш на себя риски и получаеш прибиль. Либо я компаньон, либо "вот мои часы, пока ты даешь мне деньги". Но еще дело даже не в этом. После первой попытки наказать меня рублем, следующая оценка будет точно гарантированно выполнимая :) Только ни одного заказчика ты не найдешь, потому что она будет с огромным запасом :) А попытка продавить оценку сотрудника окончится пониманием, что помимо воды есть еще "несжимаемые" субстанции :) потому что боль от предыдущего штрафа ...
Дальше, ну если у вас непонятно, кто за что отвечает, а вы рассуждаете о том, увеличивать или нет - ну а как вы хотите? Вы ж не ныряете вглубь, в команды и процессы внутри нее :) Но рецепт прост:
надо быть более эффективным
для этого надо "нырять" внутрь и искать причину всего
найденную причину исправлять
результаты мониторить
А вы, у меня так сложилось, хотите пройтись по верхах и рыбку выловить :)
Масло масляное в названии
По фиксированной цене можно продавать только готовый продукт, а любой кастдев - это всегда субъективная оценка. И так не только в нашей с вами айтишечке. Стадион/завод/дом/мост также строят по примерной оценке плюс риски. А в рисках может быть и x2 и больше.
Да, смысл статьи уловить очень сложно, есть ощущение что было задание на заголовок и какой-то текст, и не было требований по качеству текста.
Поддержу остальных комментаторов. Искать корень зла в том, что программист неверно оценивает сроки это дикость.
Проработав 20 лет в ИТ я тоже всегда называю усредненный срок, за который я должен сделать. Но в реальности он может быть как больше так и меньше. Если пытаться давить рублем и заставлять указывать "точные" сроки, то программист автоматически должен давать оценку по максимально возможной планке.
При этом если брать не разработку с нуля, где хотя бы плюс-минус понятно, а доработку и правки неизвестной системы, то тут, периодически, даже минимальные проблемы, которые, казалось бы, должны решаться за пару минут занимают часы. Из последних: клиент попросил в табличке в CRM слово "Отказ" заменить на "Отказано". С виду вроде 5 минут в шаблоне поменять, но потом оказывается, что оно тянется из бд , туда попадает из 1С, так ещё используется в 200 SQL запросах внутри системы. И вот тут уже или программисту делать костыль в форме быстренько, или согласовывать дальше, что точно нужно.
Опять же зачастую требования заказчика меняются постоянно и программист не должен за это нести ответственность.
По итогу получаем, что тут просто попытка переложить ответственность руководства на исполнителя
Почему Тime and Materials и почасовая оплата не спасёт вашу компанию, если вы ошибаетесь в сроках разработки