Проблемы оценки ИТ-Проектов

Привет !

(1) Steelvan, Игорь, привет! Необычное место для "поздороваться"))

Статья содержательная. Все оценки и риски разложены по-полочкам. В своей практике обычно я все возможные риски закладываю в договор. Как например, у Вас есть описание в одной из ошибок - изменение процессов в ходе реализации проекта. Наверно самый распространенный риск, если разложить его на количество внедрений.
Я всегда руководствуюсь двумя правилами:
1. "Что для Заказчика СЛОЖНО - значит для Исполнителя будет ПРОСТО. И наоборот. Что для Заказчика ПРОСТО - для Исполнителя ОЧЕНЬ СЛОЖНО". Например, если Заказчик говорит (очень утрировано): "Мне надо чтобы я нажал одну кнопочку и всех была вся информация, все пересчиталось, СМС отправлены, письма всем клиентам отправлены, отчеты на мониторе у руководителя". Значит я понимаю, что придется попотеть, чтобы выполнить его требования. Соответственно, закладываюсь на увеличенное количество работ + привлечение квалифицированных специалистов. И таким образом обосновываю стоимость работ. Но если мне Заказчик говорит: "Сделайте мне 1-2 отчета, мы его потом выгрузим в Excel и сами выполним все дальнейшие расчеты и т.п." Соответственно и стоимость будет небольшая. Тогда и к конечному результату претензий я не принимаю.
2. Так называемая трех-факторная модель "ДЕШЕВО - БЫСТРО - ХОРОШО". Выполняются всегда только 2 фактора, при этом третий фактор принимает противоположное значение". Вот с этих позиций и оценивать проект. Понятно, что каждый фактор величина относительная, и тем не менее....

Где-то я этот текст уже видел.
Автор, вы Автор или просто перепостили?

Текст полезный? не спорю.

"плюс" статья хорошая

надеюсь "заказчики" тоже со временем начнут понимать

Содержательная статья, большое спасибо за то что все разложено по полочкам. Добавлю к себе в Избранное, чтобы по необходимости перечитывать.

Спасибо за статью очень полезно и содержательно.

(4) Nikola23, Вы ничего не курили? )) Может на Инфостарт приезжали и в зале слушали?

Считаю что автор описал всего 2 метода:
1. На основании опыта (пилотный проект или коммерческое предложение);
2. Составление укрупненной сметы (с максимальной детализацией за оплаченное время).
Но это не разные методы, а разные этапы проектирования.
Причем оба этапа убыточны (чаще), но нормализуют отношения с клиентом и формализуют этапы выполнения проекта.

Рекомендую ознакомится с ГОСТОМ http://www.it-gost.ru/content/view/101/51/

:)

В идеале лучше разделить программистов и аналитиков. Хотя и сыр и масло и сливки - молочные продукты.

(9) sergsqvo, так всё таки считаешь, что описал два метода?

Замечательная статья. Добавил бы еще три нюанса при оценке проектов:
1. Загруженность очереди проектов. Если работы мало - демпингуем, если работы много - задираем ценник повыше и меньше тратим времени на ухаживание за Заказчиком
2. Стратегическая важность проекта. Например если хотим зайти на новую отраслевую специфику, или Заказчик уж очень перспективный для будущих задач, то иногда стоит снизить ценник.
3. Объективно отлаженные технологии позволяют держать низкий ценник и сохранять достойную рентабельность - но требуется специализация, что, в свою очередь, требует отлаженный процесс продаж и масштаб.

(11) SunShinne,

+ за п.3

(9) sergsqvo, а что там в ГОСТе про оценку сказано?

(11) SunShinne, Да, все 3 пункта справедливы. Но с "меньше тратим времени на ухаживания за Заказчиком" надо осторожнее, чтобы не сказалось на качестве и репутации. Иногда лучше совсем отказаться, чем сделать плохо.

(11) SunShinne, (14) chavalah, ну так, и по какому методу оценивать? По 6-ти, по 3-м, по 1-му? И как затраты на оценку - лягут потом в общие расходы?

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

А оценивать надо тем методом, которым чаще угадать получилось.

Добрый день!

По оценке проекта. Я оцениваю по личному опыту плюс 30% на непредвиденные (30% могут и не появится, т.е. опционально, о чем заказчик предупреждается заранее). Но это что касается, когда проект веду я. Когда начинаешь оценивать со своей колокольни, отдавая его другому исполнителю, то тут просто пальцем в мимо. Соответственно вопрос в оценке уровня компетенции исполнителей. Как с этим вопросом быть? Наличие сертификатов не в счет, иногда такие дубы колдуны с сертификатами попадаются...

(17)Добрый день, Андрей,

Проблема известная, сталкивался с таким. Я когда оценивал, всегда исходил из того, своей командой делать, или это просто оценка. На конференции упоминал об этой проблеме. Раз Вы умеете оценивать для себя, значит сможете и для других. Что делать: наиболее подходящим в такой ситуации является метод, который я назвал "сметный" (№5 в презентации). Еще лучше сделать оценку несколькими специалистами, затем сравнить.

(18) Проблема мне видится шире. Нет у нас в стране четкого понимания стоимости АйТи услуг у владельцев бизнеса. Я бы даже сказал хотя бы уровня затрат на АйТи. Многие относятся к этому как к неизбежному злу, а не как к реальной помощи и сокращению издержек (не будем употреблять слово Затарт). Посему оценка специалистом который даст меньше, будет заказчиком восприниматься как более объективная.