Как сделать оценку проекта

Олег Пашинин

Одна из серьезных проблем в проектах – превышение сроков и бюджета. Можно даже сказать, что провальных проектов как бы и нет вовсе, а есть такие, срок которых увеличен до бесконечности, а бюджет пока закончился. Примечательно, что от превышения сроков страдают и исполнитель и заказчик. Заказчик не получает ожидаемого результата, а исполнитель – ожидаемых денег. Казалось бы, общая проблема должна объединять, но она зачастую только создает дополнительные проблемы между сторонами. Как сделать так, чтобы сроки и бюджет всегда выдерживались? Кое-чего в этом направлении нам удалось достичь.

бюджет

Перед тем как рассказать о своем опыте, хотелось бы ответить на несколько принципиальных вопросов: чего хочет заказчик и чего хочет исполнитель при выполнении проектов? Будем исходить из того, что заказчик действительно хочет сделать проект. У него есть определенный бюджет, и он не собирается «кидать», а готов заплатить оговоренные деньги за получаемый результат. Понятно, что он хочет сделать за свои деньги как можно больше. А вы, когда делаете дома ремонт, разве этого не хотите? И как каждый хозяин, нанимающий бригаду строителей, заказчик, возможно, подозревает, что исполнитель будет его надувать раздувать бюджет. Что поделать, такова наша действительность.

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

Каждая из сторон, по-своему, права. С этим приходится мириться и в таких условиях, не договорившись окончательно, начинать проекты. Но изначальное недопонимание, как правило, в ходе проекта только увеличивается и приводит… не будем о грустном. Расскажу о принципах и методах ведения проекта, используемых нами, которые, так или иначе, имеют отношение к соблюдению сроков и бюджета. Возможно, кому-то это поможет улучшить качество собственных проектов.

Рамки проекта

Первый ключевой момент – проработка рамок. Рамки проекта – это документ, в котором написаны требования заказчика к системе, но не настолько фундаментальный как ТЗ. Функциональные рамки проекта составляет консультант/аналитик – сотрудник проектной команды исполнителя – на основе интервью с ключевыми специалистами заказчика. Рамки проекта – это полное понимание всех задач, которые нужно решить в ходе проекта, но без детализации. Это также перечень задач, которые не будут решены в ходе проекта. Этот вопрос занимает одну-две недели. Столько же может занять согласование и уточнение.

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

Проработка архитектуры

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

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

Архитектурные ограничения системы, вытекающие из решения, также фиксируются в документе «Рамки проекта». Помимо этого, в документе фиксируются события, значимые для проекта – необходимые ресурсы, которые должен предоставить заказчик, сроки подготовки оборудования, классов обучения и т.п.

Планирование работ

После проработки требований и понимания их реализации, производится предварительное планирование работ и ресурсов – архитектор определяет, каких исполнителей для реализации тех или иных требований можно привлечь, в каком порядке критично требования выполнять, какие существуют взаимозависимости между требованиями. Всю информацию аккумулирует руководитель проекта, перенося ее в план проекта.

В этот момент рождаются сроки проекта. Сначала все работы выстраиваются линейно. Далее задачи распределяются по ресурсам. Исходя из пожеланий, высказанных заказчиком по срокам, а также из оптимального сочетания привлекаемых ресурсов определяется длительность проекта. Под «оптимальным сочетанием привлекаемых ресурсом» имеется в виду простая мысль – сроки проекта должны быть минимальны, людей надо привлечь как можно меньше, но задействовать их максимально. Так появляются оценки длительности пребывания людей на проекте, которые являются основой для составления бюджета проекта.

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

Для корректировки оценки важно знать продуктивность каждого конкретного разработчика. Это третий ключевой момент. То же самое относится к остальным работам – инсталляция системы, подготовка технического задания, тестирование и т.п. Чтобы знать, сколько работа займет времени, мы должны знать, кто эту работу будет делать. Фактически, для планирования и оценки проекта, мы должны собрать проектную команду.

Оценка бюджета

В результате планирования работ появляются роли и люди, участвующие в проекте и длительность их пребывания на проекте.

Дальнейшие расчеты я, как руководитель проекта, делаю в таблице Excel. Примерно так:

Ресурс

Длительность (мес.)

Загрузка

Единиц

Трудо-

затрат, (час)

Ставка в час

Стоимость (месяц)

Стоимость (без НДС)

РП (Пашинин)

5

0,5

2,5

420

2000 р.

336 000 р.

840 000 р.

Ведущий консультант (Плешкова)

4

1

4

672

1400 р.

235 200 р.

940 800 р.

Архитектор (Шаповалов)

5

1

5

840

1400 р.

235 200 р.

1 176 000 р.

Консультант (Корх)

4

1

4

672

1100 р.

184 800 р.

739 200 р.

Ведущий разработчик (Харитонов)

3

1

3

504

1400 р.

235 200 р.

705 600 р.

Разработчик (Колесников)

3

1

3

504

1100 р.

184 800 р.

554 400 р.








4 956 000 р.

В результате появляется бюджет проекта. На планирование и составление бюджета уходит еще примерно два-три дня.

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

Уточнение рамок, срока, бюджета

В результате проделанной работы мы получили документы:

  • Рамки проекта, согласованные с заказчиком.
  • Оценка проекта с предполагаемой архитектурой и трудоемкостью реализации требований.
  • План проекта.
  • Бюджет проекта.

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

Бюджет проекта и сроки – это параметры, на основе которых заказчик будет принимать решение. Требования – это параметр, которым будут управлять заказчик и исполнитель для корректировки бюджета и сроков.

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

После пересмотра требований, руководитель проекта производит перепланирование, руководствуясь теми же принципами: минимальные сроки – оптимальная загрузка ресурсов. После перепланирования корректируется бюджет. Рамки, сроки и бюджет являются предметной частью контракта. Вся работа по формированию рамок, планированию и оценке у нас занимает две-шесть недель.

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

Управление сроком и бюджетом

Мы выполнили оценку, согласовали бюджет и сроки. Готовы к заключению контракта и выполнению работ. Но необходимо ответить еще на один вопрос – что исполнитель продает заказчику? С одной стороны он продает результат – в контракте содержатся рамки работ, которые обязуется выполнить исполнитель. Это договор типа «fix price». С другой стороны он продает ресурсы – бюджет составляется на основании длительности привлечения ресурсов, то есть «time & materials». Это разные типы взаимоотношений.

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

Суть их заключается в следующем:

1) Исполнитель гарантирует выполнение проекта в оговоренные сроки и бюджет, в случае, если рамки проекта не будут изменены.

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

3) Если в ходе проекта происходит изменение или несоблюдение рамок проекта, но они не влекут изменения сроков и бюджета, то обязательства сторон остаются в рамках контракта.

4) Если изменения, вносимые в рамки проекта, влекут дополнительное привлечение ресурсов, то составляется дополнительное соглашение и заказчик оплачивает работы, превышающие первоначальный бюджет.

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

Подведем итоги. Ключевые моменты соблюдения бюджета и сроков закладываются в самом начале проекта при проведении оценки и закрепляются в контракте:

  • Для оценки сроков и бюджета необходимо сделать тщательную проработку рамок проекта. На это требуется время.
  • Во время оценки трудоемкости выполнения задач выполняется проработка архитектуры предполагаемого решения, которая фиксируется письменно.
  • Планирование трудоемкости задач производится на основе продуктивности тех специалистов, которые будут эти задачи выполнять. Продуктивность – это параметр, вычисленный по предыдущим проектам для каждого специалиста.
  • Расчет бюджета выполняется на основе длительности пребывания ресурсов на проекте.
  • В рамки проекта вносятся функциональные требования, архитектурные ограничения, а также обязательства заказчика, критичные для выполнения проекта исполнителем в срок.
  • Исполнитель берет на себя обязательства по своевременному выделению качественных ресурсов в полном объеме на сроки, оговоренные в контракте для выполнения рамок проекта. Заказчик берет на себя обязательства по выделению дополнительного бюджета, в случае, если изменения в ходе проекта приводят к увеличению сроков и бюджета.

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

Впервые статья была опубликована на Executive.ru 10 сентября 2010 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции

Источник изображений: Фотобанк stockphotos

Комментарии
Генеральный директор, Москва
Валерий Овсий пишет: Именно по этой причине, по причине непонимания у Вас и неудачные проекты. Неудачные потому что НЕ НУЖНО НИЧЕГО автоматизировать. Нужно запускать НОВЫЕ ТЕХНОЛОГИИ.
Валерий, по поводу того, что такое автоматизация и новые технологии, я надеюсь, нам еще удастся поговорить. Это тема для другой статьи. В данном случае речь идет о бюджете. Основные мои тезисы были: 1. Оценку бюджета делать на основе скопа задач, условий выполнения проекта и архитектуры предполагаемого решения (пресловутых рамок). 2. Условия влияющие на бюджет (рамки) фиксировать в контракте. 3. Расчет трудоемкости выполнять на основе фактической продуктивности тех членов проектной команды, которые будут выполнять проект. 4. Бюджет рассчитывать на основе планируемой длительности пребывания людей на проекте (а не трудоемкости отдельных задач). 5. Бюджет привязывать к рамкам. Изменение рамок, влияющее на длительность проекта, влечет изменение бюджета. 6. Выдавать Заказчику гарантии полной отработки бюджета Исполнителем. Данные действия направлены на то, чтобы получить наиболее достоверный бюджет и снизить опасение у Заказчика в необоснованном его завышении. Вы сказали, что вы так не делаете. Но пока у вас все больше лозунги. Что вы считаете здесь принципиально неверным, что вызвало у вас столько категоричные оценки? Кто и как делает оценку бюджета у вас? Как отражается на бюджете проектов то самое согласованное изменение сроков, о котором вы упомянули? Интересуют консалтинговые проекты, в которых высокий уровень неопределенности результата, не типовые.
Researcher, Москва
Олег Пашинин, [COLOR=blue=blue]Цитата: Но пока у вас все больше лозунги. Что вы считаете здесь принципиально неверным, что вызвало у вас столько категоричные оценки? Кто и как делает оценку бюджета у вас? Как отражается на бюджете проектов то самое согласованное изменение сроков, о котором вы упомянули?[/COLOR] Я никого не учу и не собираюсь учить! Я делаю оценку Вашей статьи. А то, что вы называете «лозунгами» в моем понимании – это «миссия» компании в части отношения к заказчику. Если эта Миссия не на бумаге, а в головах сотрудников, то лозунги приобретают смысл прямых указаний. У Вас принципиально НЕВЕРНЫЙ подход к заказчику. Из статьи видится, что для Вас заказчик, это враг которого нужно победить в тяжёлой борьбе. У нас – это друг и партнёр! У Вас контракт – максимально гарантированный способ получения денег, а у нас помочь ЗАКАЗЧИКУ в его бизнесе. Возможно, Вы думаете иначе, но я читаю статью, а не Ваши МЫСЛИ. Далее, если перейти к некоторым деталям статьи, то мы используем понятия «бюджет проекта» и «цена проекта» «Бюджет проекта» - внутренний термин, это деньги, которые выделяет инвестор на ИСПОЛНЕНИЕ проекта. «Цена проекта» - внешний термин, это деньги, которые платит заказчик, за «результат». «Инвестор» - тот, кто выделяет «реальные» деньги на выполнение проекта и которому принадлежат (юридически права собственности, авторские право) результаты. «Инвесторы» - это чаще я (директор), иногда заказчики (банки) или наши акционеры. «Предпроектные исследования» - выполняются за счёт бюджета «маркетингового отдела» и включают. 1. Бизнес-аналитик: Экспресс анализ первичных требований заказчика. 2. Маркетинг: Определение, выяснение проблем заказчика, побудивших его к формированию данного заказа. 3. Маркетинг: Определение РЕАЛЬНЫХ заказчиков, людей заинтересованных в проекте. 4. Системный аналитик: Определение локальных задач. 5. Системный аналитик: Определение способов (методов) реализации. 6. Производство: Экспресс оценка трудоёмкости на основе опыта решения подобных, задач. 7. Маркетинг: Оценка трудоёмкости. Умножаем на «статистический коэффициент» разброса. «Заключения контракта» - определение «цены проекта» и «обязательств заказчика и исполнителя». Очень много вариантов, т.к. базируется на «проблемах» заказчика, ЛПР заказчика, учитываем тактические и стратегические цели компании, кто инвестор … . Исполнение проекта происходит в «философии» Agile software development.
Генеральный директор, Москва

Валерий,
Из ваших пояснений я понял, что сначала у вас есть внутренний проект, функционал которого формируется на базе требований маркетинга и аналитиков. Финансируют этот проект инвесторы. Бюджет проекта в данном случае - его себестоимость.
Далее проект (система) продается. Цена проекта формируется в каждом случае своя, зависит от ряда условий. Т.е. она скорее всего не коррелирует напрямую с бюджетом проекта, т.к. система продаются по несколько раз, возможно, с вариациями (доработками). Так?

В данном случае, тогда, вероятно, стоит вести речь о бюджете проекта, а не о цене проекта. Каким образом формируется он? Знаете ли вы его в самом начале проекта? Стремитесь ли вы к его соблюдению?
Насколько я понимаю, философия Agile - это итерационная разработка. Каждая итерация - полный цикл разработки от планирования и анализа требований до тестирования, длительностью в несколько недель. Цель - получение в конце каждой итерации работающего функционала, значимого для заказчика. Т.о. проектная команда избавлена от необходимости жесткого фиксирования всех требований в самом начале проекта - в этом достоинство гибкой методологии разработки. Но это же не позволяет заранее оценить бюджет. Разве нет?

Researcher, Москва
Олег Пашинин, [COLOR=blue=blue]Цитата: Из ваших пояснений я понял, что сначала у вас есть внутренний проект, функционал которого формируется на базе требований маркетинга и аналитиков. Финансируют этот проект инвесторы. Бюджет проекта в данном случае - его себестоимость.[/COLOR] Почти так, но с оговоркой 1. «…требований КЛИЕНТА, маркетинга и аналитиков…» 2. Себестоимость для компании, а не самого проекта. Поясню. В проекте могут и часто используются внешние исполнители (бизнес-аналитики, кодировщики, системные аналитики…) [COLOR=blue=blue]Цитата: Далее проект (система) продается. Цена проекта формируется в каждом случае своя, зависит от ряда условий. Т.е. она скорее всего не коррелирует напрямую с бюджетом проекта, т.к. система продаются по несколько раз, возможно, с вариациями (доработками). Так? [/COLOR] Да! Так! Поэтому бывает, что цена первой продажи «проекта» может быть меньше бюджета. Первая продажа может быть УБЫТОЧНА. [COLOR=blue=blue]Цитата: В данном случае, тогда, вероятно, стоит вести речь о бюджете проекта, а не о цене проекта. Каким образом формируется он? Знаете ли вы его в самом начале проекта?[/COLOR] Есть его ОЦЕНКА. См п 1-7 предыдущего сообщения. [COLOR=blue=blue]Цитата: Стремитесь ли вы к его соблюдению?[/COLOR] В соответсвии с оценкой бюджета проводится планирование. План проекта – это закон для менеджера проекта и остальных участников. Все мотивированы на исполнение плана и возможного его сокращения как по срокам так и по трудоёмкости. Иными словами если проектная команда выполнила быстрее и с меньшими трудозатратами, то бюджет от этого не меняется и люди получают все деньги бюджета. [COLOR=blue=blue]Цитата: Каждая итерация - полный цикл разработки от планирования и анализа требований до тестирования, длительностью в несколько недель. Цель - получение в конце каждой итерации работающего функционала, значимого для заказчика[/COLOR]. Это не совсем так… [COLOR=blue=blue]Цитата: Т.о. проектная команда избавлена от необходимости жесткого фиксирования всех требований в самом начале проекта - в этом достоинство гибкой методологии разработки.[/COLOR] Требования фиксируются «на этап», далее для следующего этапа уточняется и иногда меняются. Маркетинг в этом принимает активное участие от лица инвестора. И если вносимые изменения изменяют ЦЕННОСТЬ проекта или/и трудоёмкость может корректироваться и цена и бюджет. [COLOR=blue=blue]Цитата: Но это же не позволяет заранее оценить бюджет.[/COLOR] Оценить позволяет ;) , а рассчитать НЕТ! А мне и не нужно оценивать ВЕСЬ возможный бюджет в начале. Важна процедура его корректировки. Посмотрите на это с позиции «бизнеса клиента» и «удовлетворённости клиента» и все станет на свои места.
IT-менеджер, Москва
Виталий Амбалов пишет: ИМХО, заказчика вообще не должна интересовать трудоемекость и затраты исполнителя. Его интерес - получить то, что называется экономическим эффектом. ПлАчу 1 млн., после внедрения экономлю 2 млн. в год. А типовое оно или нет мне фиолетово. Если хочу получить дополнительную экономию на разработке и внедрении - провожу тендер, можно двухэтапный. Может кто за 1/2 миллиона сваяет. Сколько при этом заработает исполнитель? Его проблемы.
Виталий, боюсь, в таком подходе и кроется основная причина неудач крупных проектов в ИТ-отрасли. Заказчик фиксирует деньги, но получить за свой миллион хочет всё. Точный объём проекта ''на берегу'' чётко не фиксируется. Ну а Исполнитель обычно применяет подход ''сначала ввяжемся в драку, а потом посмотрим''. До кризиса риски серьёзного увеличения проектных объёмов обычно компенсировались возможностью увеличить бюджет проекта. Сейчас ситуация другая. Бюджет фиксируется на входе. И изменить потом его практически невозможно. А объёмы могут резко вырасти. И как бы не было фиолетово Заказчику, что заработает Исполнитель, нужно помнить, что в убыток никто работать не сможет. Результат - неудачный проект. Моё мнение - для сложных и больших ИТ-проектов нужно уходить от схемы fix price и переходить на договоры типа ''компенсация затрат с фиксированным процентом прибыли либо с фиксированной прибылью''. Думаю, в итоге это будет дешевле Заказчику и спокойнее Исполнителю. Да и результат будет.
Директор по развитию, Беларусь
Олег Кашуба пишет: Ну а Исполнитель обычно применяет подход ''сначала ввяжемся в драку, а потом посмотрим''.
Не только, мне импонирует подход господина Овсия, часто можно сознательно пойти на занижение и убыток, поскольку разработка таких проектов позволяет получить не только деньги заказчика, но и его знания. Если коммерческий расчет верен, то это не убытки, а инвестиции. При последующем использовании результатов ''убыточного'' проекта затраты компенсируются.
IT-менеджер, Москва
Виталий Амбалов пишет: При последующем использовании результатов ''убыточного'' проекта затраты компенсируются.
Это хорошо, если решение тиражируется. Я же часто встречаюсь с тем, что на каждом предприятии (даже внутри одной отрасли) уникальные или псевдоуникальные бизнес-процессы. Унифицировать свои процессы Заказчик не хочет. Поэтому приходится почти всё начинать с начала. И предыдущие инвестиции не окупаются. У господина Овсия в проектах реализуются более узкие решения.
Старший консультант, Москва
Олег Кашуба пишет: Моё мнение - для сложных и больших ИТ-проектов нужно уходить от схемы fix price и переходить на договоры типа ''компенсация затрат с фиксированным процентом прибыли либо с фиксированной прибылью''. Думаю, в итоге это будет дешевле Заказчику и спокойнее Исполнителю. Да и результат будет.
Формула контракта ''компенсация затрат с фиксированным процентом прибыли'': Контракт = Затраты + 10% * Затраты. Второе слагаемое – прибыль исполнителя. Такой контракт – мечта исполнителя: прибыль пропорциональна затратам, которые производит Исполнитель. То есть основная забота Исполнителя – производить затраты. Для ИТ это означает, что програмеры любое задание будут растягивать до бесконечности. Кстати, этот контракт в цивильных странах запрещен для гос.заказчиков. Его еще называют «коррупционным». А ''компенсация затрат с фиксированной прибылью'': Контракт = Затраты + Фикс.Бонус. Он как бы не провоцирует исполнителя раздувать затраты, так как прибыль якобы фиксирована и не зависит от затрат. Однако все мы догадываемся, что когда затраты формируются самим исполнителем, то в них всегда сидит и его прибыль. Типа так: Затраты = Ставка * Кол.Чел-час. А ставка – конечно же, уж никак не ниже рыночной, а с малюсенькой такой маржой. Да и кол-во чел-часов - как Заказчик узнает, чем там в эти часы заняты програмеры исполнителя? Уж если говорить о компенсационных контрактах, то имхо вариант один – Time&Material c фиксированным тарифом (ставками). Где-то выше Виталий Амбалов заметил, что в форуме присутствуют и Заказчики, и Исполнители. Похоже, цитируемый автор – из племени исполнителей.
IT-менеджер, Москва
Сергей Вратенков пишет: , цитируемый автор – из племени исполнителей.
Это Вы угадали. В основном я работал и работаю на стороне Испонителя. А вот далее повозражаю, с Вашего позволения:
Сергей Вратенков пишет: Уж если говорить о компенсационных контрактах, то имхо вариант один – Time&Material c фиксированным тарифом (ставками).
T&M хорош для организации работы типа ''body shop'', когда Заказчик получает ресурсы и сам управляет проектом. Иначе это превращается в производство затрат. Или в другие уродливвые формы. Например, Заказчик начинает возражать (при чём по завершению работ): - Эта работа не могла выполняться 10 дней. Её можно было сделать за 2 дня. Исполнитель: - Да нет, с чего Вы взяли? Заказчик: - Ну... как-то дорого - 10 дней оплачивать? Исполнитель: - Так сами бы сделали за 2 дня! Заказчик: - Мы не специалисты. Но, кажется, Вы нас обманываете... и т.д. Конечно, если отношения с Заказчиком налажены или у Заказчика это не первый проект, то обычно оценки так не расходятся. А если не так? Ещё проблема T&M: кто будет оплачивать простои? Исполнитель сделал задачу, Заказчик затянул приёмку, и Исполнитель лишний день просидел без дела. Но при подписании тайм-шитов Закзчик хочет учитывать только чистое время. И т.д. А с другой стороны
Сергей Вратенков пишет: Да и кол-во чел-часов - как Заказчик узнает, чем там в эти часы заняты програмеры исполнителя?
T&M при управлении Исполнителем эту пробему не решает :(
Сергей Вратенков пишет: Однако все мы догадываемся, что когда затраты формируются самим исполнителем, то в них всегда сидит и его прибыль. Типа так: Затраты = Ставка * Кол.Чел-час. А ставка – конечно же, уж никак не ниже рыночной, а с малюсенькой такой маржой.
Это лечится - конкуренцией. В ИТ она сейчас жёсткая и ставки особо не заломишь. В общем затраты можно ограничивать - контрактно. Главная сложность - подобрать схему контракта, который бы адекватно позволял управлять объёмом проекта как Заказчику, так и Исполнителю. С этим - беда.Кстати, в Европе в ИТ-консалтинге fix price никто не применяет. Только компенсационные контракты на консультационные услуги.
Директор по производству, Украина
Виталий Амбалов пишет (30.09.2010 23:34:22): «…часто можно сознательно пойти на занижение и убыток, поскольку разработка таких проектов позволяет получить не только деньги заказчика, но и его знания. Если коммерческий расчет верен, то это не убытки, а инвестиции. При последующем использовании результатов ''убыточного'' проекта затраты компенсируются» Это – точно. Именно такое отношение Исполнителя к работе и есть важнейшая предпосылка к росту его квалификации. В 1992-м году по радио «Свобода» мелькнула передача о том, что, с крушением коммунизма, в СССР приходит коммерциализация; которая уничтожает познавательный аспект в работе исполнителей. Да, живя в советские времена, мы не особо заботились о хлебе насущном. А работали, потому что нам было интересно. Каждый заказ был поводом для внутренних работ по построению модели, описывающей заказанную «железку» (сверхпроводящую магнитную систему, СМС). Изучение моделей выявляло типы СМС и их типовые рабочие элементы. Результаты этих работ мы публиковали в журнале «Вопросы атомной науки и техники» (в секции «Прикладная сверхпроводимость»). Как и ожидалось, со временем, обнаружилось, что проектирование СМС по новым заказам стало чаще сводиться к уточняющим расчётам для ранее изученных типовых СМС. Ясно, что наши внутренние работы относились к прикладной науке, а не к фундаментальной. Поэтому, познавательный аспект в них был прагматичным. Со временем, в части публикаций, приходили определённые ограничения. Но такого тотального исчезновения научных работ прикладного характера, как в нынешние времена – кто бы ожидал! Сейчас, в подавляющем большинстве публикаций доминирует пустопорожняя игра в термины. Её цель – «25-м кадром» убедить читателя в том, что сам он не разберётся, поэтому умнее будет заказать работу авторам публикаций. Кстати, думаю, что и на Западе, тоже, лёгкость создания-распространения текстов и коммерческая озабоченность их авторов привели к чудовищному снижению полезности публикаций. И авторы и их оппоненты очень редко говорят о том, что 2+2=4. Но, очень часто и непримиримо рассуждают о том, что такое 2; что такое 4. Вот почему я своей оценкой увеличил средний балл статьи с 3,7 до 4,0. Её автор находится в начале пути; он начал пытаться излагать свои наработки. Но, пока, эти попытки далеки от стандартного стиля написания статей; стиля доинтернетовских времён. И последнее. Чтение дискуссии показало, что автор рискует превратиться в афффтора. Ибо, обоснованную критику Сообщников, явно превосходящих его во всех отношениях (по опыту, по выполняемым обязанностям, по возрасту) он позволяет себе трактовать, как брызгание слюной.
1 3
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии