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

0. Александр Чавалах (chavalah) 728 31.03.15 12:12 Сейчас в теме
Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.
В статье три части.
• Первая часть посвящена тем методам оценки, которые встречаются на практике, в том числе, которые я использую.
• Во второй части мы разберем наиболее часто встречающиеся ошибки при оценке проектов. Их много, и я собрал десяток наиболее важных.
• И в третьей части мы поговорим об оценке рисков.

Перейти к публикации

Вознаграждение за ответ
Показать полностью
Комментарии
1. Игорь Steelvan (Steelvan) 30 14.04.15 15:15 Сейчас в теме
2. Александр Чавалах (chavalah) 728 15.04.15 01:09 Сейчас в теме
(1) Steelvan, Игорь, привет! Необычное место для "поздороваться"))
3. Дмитрий ДАГ (dag903) 15.04.15 10:18 Сейчас в теме
Статья содержательная. Все оценки и риски разложены по-полочкам. В своей практике обычно я все возможные риски закладываю в договор. Как например, у Вас есть описание в одной из ошибок - изменение процессов в ходе реализации проекта. Наверно самый распространенный риск, если разложить его на количество внедрений.
Я всегда руководствуюсь двумя правилами:
1. "Что для Заказчика СЛОЖНО - значит для Исполнителя будет ПРОСТО. И наоборот. Что для Заказчика ПРОСТО - для Исполнителя ОЧЕНЬ СЛОЖНО". Например, если Заказчик говорит (очень утрировано): "Мне надо чтобы я нажал одну кнопочку и всех была вся информация, все пересчиталось, СМС отправлены, письма всем клиентам отправлены, отчеты на мониторе у руководителя". Значит я понимаю, что придется попотеть, чтобы выполнить его требования. Соответственно, закладываюсь на увеличенное количество работ + привлечение квалифицированных специалистов. И таким образом обосновываю стоимость работ. Но если мне Заказчик говорит: "Сделайте мне 1-2 отчета, мы его потом выгрузим в Excel и сами выполним все дальнейшие расчеты и т.п." Соответственно и стоимость будет небольшая. Тогда и к конечному результату претензий я не принимаю.
2. Так называемая трех-факторная модель "ДЕШЕВО - БЫСТРО - ХОРОШО". Выполняются всегда только 2 фактора, при этом третий фактор принимает противоположное значение". Вот с этих позиций и оценивать проект. Понятно, что каждый фактор величина относительная, и тем не менее....
Lacrimosa0000; &rew; +2 Ответить
4. Николай Крылов (Nikola23) 360 15.04.15 11:17 Сейчас в теме
Где-то я этот текст уже видел.
Автор, вы Автор или просто перепостили?

Текст полезный? не спорю.
5. Сергей Ка (graZy) 15 15.04.15 12:14 Сейчас в теме
"плюс" статья хорошая

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


AntonSm; monkbest; &rew; Kovalenywka; +4 Ответить
6. Александр Теплов (hostguy) 15.04.15 14:49 Сейчас в теме
Содержательная статья, большое спасибо за то что все разложено по полочкам. Добавлю к себе в Избранное, чтобы по необходимости перечитывать.
7. Viacheslav Bilous (Gendalf_beliy) 15.04.15 15:18 Сейчас в теме
Спасибо за статью очень полезно и содержательно.
8. Александр Чавалах (chavalah) 728 15.04.15 17:02 Сейчас в теме
(4) Nikola23, Вы ничего не курили? )) Может на Инфостарт приезжали и в зале слушали?
new_user; +1 Ответить
9. Сергей Скворцов (sergsqvo) 15.04.15 22:14 Сейчас в теме
Считаю что автор описал всего 2 метода:
1. На основании опыта (пилотный проект или коммерческое предложение);
2. Составление укрупненной сметы (с максимальной детализацией за оплаченное время).
Но это не разные методы, а разные этапы проектирования.
Причем оба этапа убыточны (чаще), но нормализуют отношения с клиентом и формализуют этапы выполнения проекта.

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

:)

В идеале лучше разделить программистов и аналитиков. Хотя и сыр и масло и сливки - молочные продукты.
aleksashin; +1 Ответить 2
10. Андрей Смелов (Gesperid) 2 16.04.15 15:51 Сейчас в теме
(9) sergsqvo, так всё таки считаешь, что описал два метода?
11. Сергей Алферов (SunShinne) 599 16.04.15 20:52 Сейчас в теме
Замечательная статья. Добавил бы еще три нюанса при оценке проектов:
1. Загруженность очереди проектов. Если работы мало - демпингуем, если работы много - задираем ценник повыше и меньше тратим времени на ухаживание за Заказчиком
2. Стратегическая важность проекта. Например если хотим зайти на новую отраслевую специфику, или Заказчик уж очень перспективный для будущих задач, то иногда стоит снизить ценник.
3. Объективно отлаженные технологии позволяют держать низкий ценник и сохранять достойную рентабельность - но требуется специализация, что, в свою очередь, требует отлаженный процесс продаж и масштаб.
Lacrimosa0000; &rew; Steelvan; +3 Ответить 3
12. Игорь Steelvan (Steelvan) 30 16.04.15 22:41 Сейчас в теме
13. Александр Чавалах (chavalah) 728 17.04.15 04:19 Сейчас в теме
(9) sergsqvo, а что там в ГОСТе про оценку сказано?
14. Александр Чавалах (chavalah) 728 18.04.15 16:34 Сейчас в теме
(11) SunShinne, Да, все 3 пункта справедливы. Но с "меньше тратим времени на ухаживания за Заказчиком" надо осторожнее, чтобы не сказалось на качестве и репутации. Иногда лучше совсем отказаться, чем сделать плохо.
15. Алекс Ю (AlexO) 118 20.07.15 10:46 Сейчас в теме
(11) SunShinne, (14) chavalah, ну так, и по какому методу оценивать? По 6-ти, по 3-м, по 1-му? И как затраты на оценку - лягут потом в общие расходы?
16. Александр Чавалах (chavalah) 728 05.11.15 08:38 Сейчас в теме
(15) AlexO, по поводу затрат на оценку я говорил на круглом столе на позапрошлой конференции. Советую придерживаться следующего подхода:
- если продажа состоялась, относить затраты на проект;
- если продажа не состоялась, относить затраты на общие затраты по продажам, т.е. на само направление продаж (отдел например, или компанию в целом - от структуры компании зависит).

А оценивать надо тем методом, которым чаще угадать получилось.
17. Андрей Суханцов (&rew) 6 28.11.16 11:07 Сейчас в теме
Добрый день!

По оценке проекта. Я оцениваю по личному опыту плюс 30% на непредвиденные (30% могут и не появится, т.е. опционально, о чем заказчик предупреждается заранее). Но это что касается, когда проект веду я. Когда начинаешь оценивать со своей колокольни, отдавая его другому исполнителю, то тут просто пальцем в мимо. Соответственно вопрос в оценке уровня компетенции исполнителей. Как с этим вопросом быть? Наличие сертификатов не в счет, иногда такие дубы колдуны с сертификатами попадаются...
18. Александр Чавалах (chavalah) 728 28.11.16 15:44 Сейчас в теме
(17)Добрый день, Андрей,

Проблема известная, сталкивался с таким. Я когда оценивал, всегда исходил из того, своей командой делать, или это просто оценка. На конференции упоминал об этой проблеме. Раз Вы умеете оценивать для себя, значит сможете и для других. Что делать: наиболее подходящим в такой ситуации является метод, который я назвал "сметный" (№5 в презентации). Еще лучше сделать оценку несколькими специалистами, затем сравнить.
19. Андрей Суханцов (&rew) 6 02.12.16 10:25 Сейчас в теме
(18) Проблема мне видится шире. Нет у нас в стране четкого понимания стоимости АйТи услуг у владельцев бизнеса. Я бы даже сказал хотя бы уровня затрат на АйТи. Многие относятся к этому как к неизбежному злу, а не как к реальной помощи и сокращению издержек (не будем употреблять слово Затарт). Посему оценка специалистом который даст меньше, будет заказчиком восприниматься как более объективная.
Оставьте свое сообщение