Fixed Cost vs. Time and Material

Jun 19, 2011 15:48

Это про то, что всем интересно, но про что стесняются спрашивать.

Есть два основных формата ведения проектов:

Fixed Cost (FC)  - есть бюджет, сроки, критерий выполненности. Твори что хочешь, получишь результат - получишь деньги. Ошибся с оценками - сам дурак, будешь работать себе в убыток. Изменения требований/критериев (change request, CR) ( Read more... )

it business, time and material, fixed cost

Leave a comment

Comments 26

(The comment has been removed)

d_zh June 19 2011, 12:25:23 UTC
Просто спросить о преобладающем типе проектов. Из этого секрета не делают, но никто никогда не спрашивает почему-то. Я больше тысячи собеседований провел - ни разу мне не задавали этот вопрос.

Reply


artamonov June 19 2011, 12:32:58 UTC
А если такая сторона монеты: при FC - нужно сделать быстро, очень быстро, только на этом можно заработать. А самый простой способ - сделать некачественно (все равно это неизмеримо). Т.е. на словах все хорошо, но система устроена так что изначально мотивирует лишь на плохое качество. Конечно с этим все борятся, но разве можно полностью побороть основной принцип системы, изнутри нее самой?

Ну знакомая же ситуация, когда все понимают что какая часть проекта это кусок говна, который получился даже случайно, но его нельзя трогать? Да даже за рефакторинг в таком проекте по головке не похвалят. Обычно весь проект идет в режиме самообмана, вслух все говорят что "мы профессионалы", оно так и есть наверное, но на практике "ну здесь чуть сэкономим", "да и так пойдет, а че". Двоемыслие.

Reply

d_zh June 19 2011, 12:55:46 UTC
Вопрос качества при TM и FC стоит одинаково остро. При FC качеством занимаются по двум причинам (1) иначе не сдашь проект (2) плохой код будешь переделывать до посинения за свой счет.

Опять же при FC понятие качества сугубо утилитарно. У рефакторинга тоже должен быть заказчик, хотя бы и внутренний. Если нет четко осознанной бизнес-цели действия, то оно превращается в бессмысленный ритуал. Рефакторить весь код из любви к красивому коду - один из примеров такого ритуала. Многие выполняют, не задумываясь. Потому что в умных книжках так написано.

Reply

artamonov June 19 2011, 13:05:38 UTC
Я как раз и имею ввиду что (1) и (2) тут не работают. Я по крайней мере ни разу не видел где бы это работало. Сдать можно что угодно, ты же сам знаешь сотни примеров, мы даже не обращаем на это внимания, т.к. это уже общепринятая практика, болезнь энтерпрайз софта.

Да, про рефакторинг я обще выразился, не обязательно он конкретно.

Reply

d_zh June 19 2011, 13:26:20 UTC
(1) и (2) тоже работают. В Data Quality так вообще на ура, будешь фиксить до бесконечности, пока не достигнешь обещанных показателей.

А вообще у энтерпрайз софта другие критерии качества, чем у консюмерского. Критерий простой: решена бизнес задача или нет, превышает ли стоимость вложений и TCO бизнес-вэлью, и не превышает ли совокупная величина рисков допустимый уровень.

Reply


dima_1979 June 19 2011, 15:48:49 UTC
в нашем бизнесе (внедрение ERP систем) и в нашей компании большинство проектов делается TM, потому что так проще для исполнителя. Но в последнее время набирает популярность FC (у нас называется Fixed Price), потому что FC проще работать заказчику, он минимизирует свои риски при неудачном ходе проекта, и он при прочих равных выбирает консультанта с FC. Пока рынок не очень зрел, выбирать особо не из кого, и часто исполнитель может диктовать свои условия.

Reply

d_zh June 19 2011, 23:35:42 UTC
А проще - почему? Нет наработанной базы типичных рисков? Или каждый проект - новая вселенная?

Reply

dima_1979 June 21 2011, 06:47:33 UTC
В консалтинговом проекте всегда очень велики риски изменения объёмов проекта - заказчик не так сформулировал, исполнитель не так понял. А маржа консультанта не очень высока - порядка 30%. И затраты на проект очень неэластичны - командировки, гостиницы, зарплаты - это всё слабо поддаётся оптимизации и управлению. Поэтому если вдруг что-то в проекте пошло не так - консультант легко может начать работать себе в убыток. Этого все боятся и идут на это только в крайних случаях - когда есть очень высокая уверенность, что мы чётко понимаем все риски, заказчик адекватный, и объём проекта не поползёт ( ... )

Reply


b00ter June 19 2011, 19:57:37 UTC
Оптимист.

Сколько раз для оценки FC-проектов использовал методику TM-проектов с завышенной ставкой. Как оказалось - не зря, почти все FC проекты требовали большого числа смежных работ, а иначе "денег не заплачу". Поэтому важно просто хорошо делать свое дело, а какая методика оценки - FC, TM, гибрид и потолочно-пальцевые оценки - дело десятое.

Опять же, если хорошо делаешь свое дело, а заказчик не согласен с предложенной моделью оценки и навязывает свою - это хороший повод не прыгать вокруг наглого клиента как вокруг драгоценного артефакта. А это очень хорошо, ибо, как ни крути, бизнес - это желание и рыбку съесть, и жопу не ободрать.

Reply

d_zh June 19 2011, 23:27:02 UTC
TM и FC - это не про оценку, а про способ реакции на изменения и распределение рисков и премии за риски. А оценка может вообще не быть связана с трудозатратами.

Reply

b00ter June 20 2011, 06:15:26 UTC
Ну, а тогда вообщее зачем этими фиговыми листочками прикрываться? :)

Reply


c0s June 19 2011, 21:12:09 UTC
в каком-то смысле поддержу предыдущего оратора

лучшая из ситуаций (имхо) - когда проект FP, но обоснование P даётся в терминах TM (при этом оцененых очень детально и основательно, здесь очень важно включить всё, чтобы потом не только не было мучительно больно, но и та самая (сверх)прибыль образовалась, к которой все стремятся)

ничуть, однако, не хуже та ситуация с монотонным процессом, когда люди из команды продают своё время, например, для поддержки чего-то достаточно стабильного, где активностей в среднем на полдня в неделю, но платят каждому за 40 часов, а оставшиеся 36 часов можно использовать для своей же выгоды.

мне доводилось бывать в обоих ситуациях, и сожалеть можно лишь о том, что первое далеко не всегда удаётся на фазе обоснования (часто знаешь, чем ограничен потолок по проекту, и приходится идти на компромисс с самим собой, чтобы не остаться без заказа), а второе - конь, крайне редко выходящий из вакуума и не всем материализующийся в виде нормальной, а не сферической формы.

Reply

d_zh June 19 2011, 23:24:00 UTC
> обоснование P даётся в терминах TM

Обоснование для кого? При FP обоснования для заказчика такое: "Это столько стоит". Трудозатраты и свою почасовую ставку афишировать вообще не обязательно.

> когда люди из команды продают своё время <...> где активностей в среднем на полдня в неделю, но платят каждому за 40 часов

Это как раз FP, при TM им бы заплатили только за полдня.

Reply

c0s June 19 2011, 23:46:45 UTC
> Обоснование для кого?

Обычно заказчики просят обоснование цены. Можно и не обосновывать, но в тех случаях, с которыми сталкивался я, диалог сразу становился резко неконструктивным.

> Это как раз FP

Неа, речь именно о "длинном TM", когда договор заключается, к примеру, на год и на определённое кол-во людей в наличии (т.е. в офисе на подхвате, отчёт и выставление счетов ведётся по времени прихода-ухода).

Reply

d_zh June 20 2011, 11:33:20 UTC
Это уже даже не проектная деятельность, а аутстаффинг. Фактическим работодателем для проданных по такой модели людей становится клиент.

Reply


Leave a comment

Up