Уважаемые гуру,

существует ли некие модели или методики позволяющие хоть как-то формализовать правила образование цены на программый продукт?

вопрос не праздный. есть гос. контора, испытывающая потребность в периодическом ПО, выполненного третьими подрядчиками. Подрядчики выставляют некоторую цену, или с потолка или каким-то образом приброшенную в уме, но вот вопрос для гос.конторы - а какова структура этой цены? быть может она реально в 3 раза меньше? ну или в 1,5 ...

Понимаю, что четкого ответа нет и наверное правильный ответ - цена=рыночной стоимости этих услуг. Однако все осложняется тем что выяснить эту рыночную стоимость не представляется возможным для конторы, при этом объявляется конкурс на услуги такого рода. Никто не гарантирует что на конкурс заявятся репрезентативное кол-во участников, их может быть 2,3 или даже 1. О каком рынке здесь может быть речь?

Собственно такие мысли побудили спросить совета - а есть ли методики кроме пальцем в небо и стоимость человко-часа*срок реализации проекта в часах?

РеалистСтоимость реализации или себестоимость производства?

реализации.

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

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

ну пошлет или будет придумывать отчет о структуре своей цены зависит от желания подрядчика поиметь лакомный кусок в пару десятков млн:)

Coolibin
Что есть у покупателя для оптимизации цены закупки.
-Конкурентный рынок с множеством предложений одного и того же товара.

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

Coolibin
-Тендер (конкурс) для выяснения оптимального соотношения цена/качество и т.п.

да, но в каждом тендере есть куча процедурных заморочек на основании которых легко обламываются реальные конкуренты, оставшиеся 1-2 "диктуют" свою цену, которую никто не понимает

Coolibin
Если у них нет, как у поставщика, конкурентов, то покупателю остается расслабиться и получить максимальное удовольствие, цену они могут назначать, какую вздумается. Все, что ты можешь сделать, так это попытаться найти такое количество конкурентов, какое будет оптимально для проведения конкурса. Так что забей на методики. Эти методики должны волновать самих поставщиков.


вот -вот :(

mindstreamМожет быть стоит покопать в сторону COCOMO и им подобных?

что это?

А как вам такая мысль.

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

Далее софтверные компании отвечают о своей цене для таких работ, после чего берется по некоторй методике средневзешенная цена из поступивших ответов. К это цене прибрасывается некоторый коэффициент K на ошибку в оценке сложности и риски. После чего такая цифра закладывается в бюджет.

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

Вот и болит :)

Я со стороны заказчика, который должен спланировать бюджет и при этом потом иметь обоснования цены для счетной палаты или ФАС.

CoolibinЧто есть у покупателя для оптимизации цены закупки.
1.Конкурентный рынок с множеством предложений одного и того же товара.
2.Тендер (конкурс) для выяснения оптимального соотношения цена/качество и т.п.
3.Антимонопольное законодательство
Специалисты добавят, наверное, еще что-нибудь.


1. скорее всего нет, т.к. заказываемое ПО как правило очень специфично для деятельности гос.конторы, хотя бы потому что такой деятельностью занимается она одна :)

2. Тендер будет потом на следующий год, а планировать расходы нужно сейчас.

3. Это не совсем понятно как пристегнуть на этапе формирования бюджета

Сергей Васкецов Rus000Вот и болит :)
А че ей болеть-то? Сделали цепочку поставщиков - и все дела.

точнее болит не у меня а у руководства. У меня болит оттого что нужно предложить метожику от которй бы у руководства голова тоже не болела :)

Ну вот предлагаю для обсуждения и критики следующие варианты

1. Усредненная рыночная стоимость услуг (котировки)
- Заказчик подготавливает перечень функциональных и технических требований к вновь создаваемому ПО. В требованиях обязательным образом указывается требуемый срок исполнения заказа.
- Заказчик определяет список фирм, специализирующихся на разработке ПО, как в регионе присутствия Заказчика, так и в других регионах. Пусть количество таких фирм будет N.
- Заказчик подготавливает и направляет N запросов в адреса фирм из указанного перечня, с предложением указать стоимость их услуг по разработке ПО с требуемой функциональностью в требуемый срок.
- Полученные ответы (котировки) обобщаются Заказчиком, стоимость услуг усредняется по какой-либо методике, например, путем взятия средней цены, или путем отброса самой большой и самой малой цены и взятием среднего.
- Полученная усредненная цена УЦ услуг корректируется (умножается) на следующие поправочные коэффициенты:
а) коэффициент-дефлятор на год исполнения работ – КД;
б) коэффициент репрезентативности котировок – КРК;
в) коэффициент непредвиденных расходов – КНР.
- Полученная цена Ц=УЦ*КД*КРК*КНР закладывается в бюджет.

Данная модель имеют следующие плюсы:
- при увеличении числа участников, направляющих котировки, цена Ц будет приближаться к объективно-рыночной;
- высока вероятность найти исполнителя, который будет готов выполнить работы за сумму равную или меньшую рассчитанной Ц.

2. Оценка по базовой стоимости с коэффициентамиДанная методика основывается на применении повышающих или понижающих коэффициентов к абстрактной базовой стоимости услуг (аналог расчета вмененного налога или страхование ОСАГО).
- Заказчик определяет абстрактную базовую стоимость услуг (БЦ) исходя из следующих множителей:
1) средняя стоимость труда программиста в месяц, например $2000/мес.
2) количество программистов в усредненной группе способной решить абстрактный проект средней сложности, например - 5 чел.
3) средняя продолжительность разработки абстрактного проекта средней сложности, например - 1 год.
4) сопутствующие и непредвиденные расходы, закладываемые подрядчиком от стоимости проекта, например - 20%.
5) средняя прибыль, закладываемая подрядчиком от стоимости проекта, например - 30%.
Например, БЦ = 2,000*12*5*(20%+30%) = $180,000/год.
- Заказчик подготавливает перечень функциональных и технических требований к вновь создаваемому ПО. В требованиях обязательным образом указывается требуемый срок исполнения заказа.
- Базовая цена абстрактного проекта умножается на повышающие/понижающие коэффициенты, отражающие сложность реальной задачи по отношению к усредненной абстрактной (см. ниже) на основании имеющихся функциональных требований. Шкала значений коэффициентов может быть выбрана любая, при этом коэффициент 1 соответствует базовому абстрактному проекту.
1) срок исполнения работ отличается от базового (1 год) в меньшую или большую сторону – Кс.
2) методическая изученность бизнес-процесса – ИБП;
3) необходимость миграции данных– НМ;
4) необходимость интеграции с имеющимся ПО – НИ;
5) несколько видов интерфейсов пользователя – ИП;
6) специфичность ОС - СпОС;
7) специфичность СУБД – СпСУБД.
- Полученная цена Ц=БЦ*КС*ИБП*НМ*НИ*ИП*СпОС*СпСУБД закладывается в бюджет.

3. Оценка «в попугаях»
- Заказчик подготавливает перечень функциональных и технических требований к вновь создаваемому ПО. В требованиях обязательным образом указывается требуемый срок исполнения заказа.
- Заказчик определяет уже исполненный эталонный проект, который удовлетворяет заказчика по функциональным характеристикам и на разработку которого в некоторый срок С затрачена сумма денег П, при этом, Заказчик субъективно считает, что показатель стоимость ПО/эффективность ПО является оптимальным (идеальным). Назовем такой проект-эталон, оцениваемый в сумму П, «попугаем».
- Заказчик рассматривает сложность и трудоемкость новых проектов, а соответственно и стоимость, «в попугаях», т.е. стоимость нового проекта определяется как Ц=П*К*Кс, где К - коэффициент сложности/простоты (т.е. «количество попугаев»), Кс - срок исполнения работ отличается от срока С для «попугая» в меньшую или большую сторону.

ну, собственно я примерно ту же идею описал в п.1 своего поста

по Вашем замечаниям непонятно следующее:
KGP3. рассылаете ТТЗ по компаниям и предлагаете определить им их
3.1 предварительные суммы
3.2 предварительные отчетные документы (считай смета)

разве не достаточно разослать только требования и желаемые сроки которые должен и может готовить заказчик? ТЗ если к нему тщательно подходить штука достаточно трудоемкая и как правило возлагается уже на исполнителя на первоначальном этапе работ. По крайней мере практика сечас у нас такова.

далее, что такое "3.2 отчетные документы"? это смета расходов подрядчика? Что-то я сомневаюсь, что на уровне предварительных котировок фирмы потратят на это время, более того, это и не в их интересах на данном этапе.


KGP5. закладываете среднюю сумму по компаниям, которым вы доверяете
критерий субъективный, для методики годится большо натяжкой. Почему Вам не понравился коэффициент репрезентативности котировок (КРК), в который заложено, то что если компаний приславших котировки достаточно мало, то верить такой усредненной цене можно меньше чем если бы их было много, например более 10 или 20.

мне понравилась Ваша мысль добавить еще одну итерацию по оценке проекта на этапе предваряющим тендер но до окончания верстки бюджета :)

стесняюсь спросить разницу между ТЗ иТТЗ

[quot kvasov]какие могут быть проблемы если деньги есть? - надо не лениться их тратить
мне так кажется
[/kvasov]

я говорю про гос.организацию, планирующую свой бюджет на 3 года вперед. Денег еще нет, но они могут появиться если их заложить в бюджет, а заложить можно только обосновав на бумаге, в первую очередь для ФАС и прокуратуры, а не поковыряв пальцем в носу.

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

[quot KGP1. есть понятие прототип ... но это достаточно дорогое удовольствие
2. хм ... может мы ведем речь о проектах разного уровня? имхо:
2.1 большенство успешных компаний за 1000$ просто послют за птицами
[/quot]
именно
KGP
2.2 Заказчик ТЗ не в состоянии подготовить в том виде, что можно было даже архитектуру набросать, тем более прототип

тоже верно

KGP Rus000стесняюсь спросить разницу между ТЗ иТТЗ

не претендуя на верность: ТТЗ - описание необходимого к разработке в самых общих чертах, а ТЗ более детальное.

хотя я придерживаюсь для себя скорее терминов vision, srs; и считаю, что в подготовке vision заказчик выполняет большую роль, чем в подготовке srs, use case specification ... особенно это важно при больших/неопределенных проектах

смотрим гост 34.601-90


в нашем случае 1.1-1.2 как раз подойдет