Проблемы оценки ИТ-Проектов
Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.
В статье три части.
• Первая часть посвящена тем методам оценки, которые встречаются на практике, в том числе, которые я использую.
• Во второй части мы разберем наиболее часто встречающиеся ошибки при оценке проектов. Их много, и я собрал десяток наиболее важных.
• И в третьей части мы поговорим об оценке рисков.
В статье три части.
• Первая часть посвящена тем методам оценки, которые встречаются на практике, в том числе, которые я использую.
• Во второй части мы разберем наиболее часто встречающиеся ошибки при оценке проектов. Их много, и я собрал десяток наиболее важных.
• И в третьей части мы поговорим об оценке рисков.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Статья содержательная. Все оценки и риски разложены по-полочкам. В своей практике обычно я все возможные риски закладываю в договор. Как например, у Вас есть описание в одной из ошибок - изменение процессов в ходе реализации проекта. Наверно самый распространенный риск, если разложить его на количество внедрений.
Я всегда руководствуюсь двумя правилами:
1. "Что для Заказчика СЛОЖНО - значит для Исполнителя будет ПРОСТО. И наоборот. Что для Заказчика ПРОСТО - для Исполнителя ОЧЕНЬ СЛОЖНО". Например, если Заказчик говорит (очень утрировано): "Мне надо чтобы я нажал одну кнопочку и всех была вся информация, все пересчиталось, СМС отправлены, письма всем клиентам отправлены, отчеты на мониторе у руководителя". Значит я понимаю, что придется попотеть, чтобы выполнить его требования. Соответственно, закладываюсь на увеличенное количество работ + привлечение квалифицированных специалистов. И таким образом обосновываю стоимость работ. Но если мне Заказчик говорит: "Сделайте мне 1-2 отчета, мы его потом выгрузим в Excel и сами выполним все дальнейшие расчеты и т.п." Соответственно и стоимость будет небольшая. Тогда и к конечному результату претензий я не принимаю.
2. Так называемая трех-факторная модель "ДЕШЕВО - БЫСТРО - ХОРОШО". Выполняются всегда только 2 фактора, при этом третий фактор принимает противоположное значение". Вот с этих позиций и оценивать проект. Понятно, что каждый фактор величина относительная, и тем не менее....
Я всегда руководствуюсь двумя правилами:
1. "Что для Заказчика СЛОЖНО - значит для Исполнителя будет ПРОСТО. И наоборот. Что для Заказчика ПРОСТО - для Исполнителя ОЧЕНЬ СЛОЖНО". Например, если Заказчик говорит (очень утрировано): "Мне надо чтобы я нажал одну кнопочку и всех была вся информация, все пересчиталось, СМС отправлены, письма всем клиентам отправлены, отчеты на мониторе у руководителя". Значит я понимаю, что придется попотеть, чтобы выполнить его требования. Соответственно, закладываюсь на увеличенное количество работ + привлечение квалифицированных специалистов. И таким образом обосновываю стоимость работ. Но если мне Заказчик говорит: "Сделайте мне 1-2 отчета, мы его потом выгрузим в Excel и сами выполним все дальнейшие расчеты и т.п." Соответственно и стоимость будет небольшая. Тогда и к конечному результату претензий я не принимаю.
2. Так называемая трех-факторная модель "ДЕШЕВО - БЫСТРО - ХОРОШО". Выполняются всегда только 2 фактора, при этом третий фактор принимает противоположное значение". Вот с этих позиций и оценивать проект. Понятно, что каждый фактор величина относительная, и тем не менее....
Считаю что автор описал всего 2 метода:
1. На основании опыта (пилотный проект или коммерческое предложение);
2. Составление укрупненной сметы (с максимальной детализацией за оплаченное время).
Но это не разные методы, а разные этапы проектирования.
Причем оба этапа убыточны (чаще), но нормализуют отношения с клиентом и формализуют этапы выполнения проекта.
Рекомендую ознакомится с ГОСТОМ
:)
В идеале лучше разделить программистов и аналитиков. Хотя и сыр и масло и сливки - молочные продукты.
1. На основании опыта (пилотный проект или коммерческое предложение);
2. Составление укрупненной сметы (с максимальной детализацией за оплаченное время).
Но это не разные методы, а разные этапы проектирования.
Причем оба этапа убыточны (чаще), но нормализуют отношения с клиентом и формализуют этапы выполнения проекта.
Рекомендую ознакомится с ГОСТОМ
:)
В идеале лучше разделить программистов и аналитиков. Хотя и сыр и масло и сливки - молочные продукты.
Замечательная статья. Добавил бы еще три нюанса при оценке проектов:
1. Загруженность очереди проектов. Если работы мало - демпингуем, если работы много - задираем ценник повыше и меньше тратим времени на ухаживание за Заказчиком
2. Стратегическая важность проекта. Например если хотим зайти на новую отраслевую специфику, или Заказчик уж очень перспективный для будущих задач, то иногда стоит снизить ценник.
3. Объективно отлаженные технологии позволяют держать низкий ценник и сохранять достойную рентабельность - но требуется специализация, что, в свою очередь, требует отлаженный процесс продаж и масштаб.
1. Загруженность очереди проектов. Если работы мало - демпингуем, если работы много - задираем ценник повыше и меньше тратим времени на ухаживание за Заказчиком
2. Стратегическая важность проекта. Например если хотим зайти на новую отраслевую специфику, или Заказчик уж очень перспективный для будущих задач, то иногда стоит снизить ценник.
3. Объективно отлаженные технологии позволяют держать низкий ценник и сохранять достойную рентабельность - но требуется специализация, что, в свою очередь, требует отлаженный процесс продаж и масштаб.
(15) AlexO, по поводу затрат на оценку я говорил на круглом столе на позапрошлой конференции. Советую придерживаться следующего подхода:
- если продажа состоялась, относить затраты на проект;
- если продажа не состоялась, относить затраты на общие затраты по продажам, т.е. на само направление продаж (отдел например, или компанию в целом - от структуры компании зависит).
А оценивать надо тем методом, которым чаще угадать получилось.
- если продажа состоялась, относить затраты на проект;
- если продажа не состоялась, относить затраты на общие затраты по продажам, т.е. на само направление продаж (отдел например, или компанию в целом - от структуры компании зависит).
А оценивать надо тем методом, которым чаще угадать получилось.
Добрый день!
По оценке проекта. Я оцениваю по личному опыту плюс 30% на непредвиденные (30% могут и не появится, т.е. опционально, о чем заказчик предупреждается заранее). Но это что касается, когда проект веду я. Когда начинаешь оценивать со своей колокольни, отдавая его другому исполнителю, то тут просто пальцем в мимо. Соответственно вопрос в оценке уровня компетенции исполнителей. Как с этим вопросом быть? Наличие сертификатов не в счет, иногда такие дубы колдуны с сертификатами попадаются...
По оценке проекта. Я оцениваю по личному опыту плюс 30% на непредвиденные (30% могут и не появится, т.е. опционально, о чем заказчик предупреждается заранее). Но это что касается, когда проект веду я. Когда начинаешь оценивать со своей колокольни, отдавая его другому исполнителю, то тут просто пальцем в мимо. Соответственно вопрос в оценке уровня компетенции исполнителей. Как с этим вопросом быть? Наличие сертификатов не в счет, иногда такие дубы колдуны с сертификатами попадаются...
(17)Добрый день, Андрей,
Проблема известная, сталкивался с таким. Я когда оценивал, всегда исходил из того, своей командой делать, или это просто оценка. На конференции упоминал об этой проблеме. Раз Вы умеете оценивать для себя, значит сможете и для других. Что делать: наиболее подходящим в такой ситуации является метод, который я назвал "сметный" (№5 в презентации). Еще лучше сделать оценку несколькими специалистами, затем сравнить.
Проблема известная, сталкивался с таким. Я когда оценивал, всегда исходил из того, своей командой делать, или это просто оценка. На конференции упоминал об этой проблеме. Раз Вы умеете оценивать для себя, значит сможете и для других. Что делать: наиболее подходящим в такой ситуации является метод, который я назвал "сметный" (№5 в презентации). Еще лучше сделать оценку несколькими специалистами, затем сравнить.
(18) Проблема мне видится шире. Нет у нас в стране четкого понимания стоимости АйТи услуг у владельцев бизнеса. Я бы даже сказал хотя бы уровня затрат на АйТи. Многие относятся к этому как к неизбежному злу, а не как к реальной помощи и сокращению издержек (не будем употреблять слово Затарт). Посему оценка специалистом который даст меньше, будет заказчиком восприниматься как более объективная.
Из своего опыта скажу. Знаете что было бы,
если бы вы обладали сверхспособностями
как у доктора Манхеттена
и называли бы с точностью до минуты время проекта?
Вы думаете вы бы были нарасхват?
К вам бы перестали обращаться.
Слились бы как в игре на пабе.
А так да, весело.
Вы же не только от техкомпетенций
отталкиваетесь, но и от
* ограничений платформы
* ограничений режима совместимости
* ограничений СУБД
* ограничений настроек сервера
* чужого API (который без поддержки и не очень то работает)
* непонятного и уникального оборудования (контроллеры доступа)
* ИТ персонала
* доступа к месту разработки(вас могут не пустить, выключить сервер разработки.)
* вас могут дезинформировать о состоянии системы (ой а там такого быть не должно.../ ой а там должно быть по-другому)
* вам могут не давать говорить
* вас могут не слушать
* могут быть предложения сделать в одиночку (а внедрите ка нам ЕРП2 на завод. Ну да сами. Ну да скачали с интернета. Ну да, месяца вам хватит?)
* и вишенка на торт - вам могут не дать оценить трудозатраты. (Так любой дурак может, вы нам сразу скажите)
Вот такая вот реальность. С абсолютно незнакомыми людьми.
если бы вы обладали сверхспособностями
как у доктора Манхеттена
и называли бы с точностью до минуты время проекта?
Вы думаете вы бы были нарасхват?
К вам бы перестали обращаться.
Слились бы как в игре на пабе.
А так да, весело.
Вы же не только от техкомпетенций
отталкиваетесь, но и от
* ограничений платформы
* ограничений режима совместимости
* ограничений СУБД
* ограничений настроек сервера
* чужого API (который без поддержки и не очень то работает)
* непонятного и уникального оборудования (контроллеры доступа)
* ИТ персонала
* доступа к месту разработки(вас могут не пустить, выключить сервер разработки.)
* вас могут дезинформировать о состоянии системы (ой а там такого быть не должно.../ ой а там должно быть по-другому)
* вам могут не давать говорить
* вас могут не слушать
* могут быть предложения сделать в одиночку (а внедрите ка нам ЕРП2 на завод. Ну да сами. Ну да скачали с интернета. Ну да, месяца вам хватит?)
* и вишенка на торт - вам могут не дать оценить трудозатраты. (Так любой дурак может, вы нам сразу скажите)
Вот такая вот реальность. С абсолютно незнакомыми людьми.