Как перевести на язык финансистов особенности внедрения программы?

В ИТ достаточно давно, более 15-ти лет. Где-то с 2000-го года стал заниматься 1С. Сразу столкнулся с проблемой: более-менее сложная задача, проект - ошибка расчета затрат и времени на внедрение программного продукта 1000%. Т.е. ошибиться можно в 10(!) раз. Попытки изучить предментые области (бухучет, различные методики ведения проектов и т.п.), работать в команде достаточно квалифицированных специалистов только утвердили мнение: предварительная оценка затрат автоматизации хоть какого либо крупного проекта может быть произведена с ошибкой в 10 раз.
Естественно, что нормальным и адекватным заказчикам нельзя говорить "сделаем сейчас или через год", но и обещание нереальных сроков черевато санкциями.
Как быть, как можно сформулировать все выше сказанное, чтобы, например, финансисты могли правильно все понять и отразить в своих планах/бюджетах и т.п.?
Так же интересует как грамотно и доходчиво объяснить то, что создание сложной сисетмы учета происходит обычно в 2-3 прохода, т.е. делается 1-й прототип программы, подвергается жестокой критике и по причине его неработоспособности создается 2-й .... пока не получится приемлемый программный продукт.

Сам сталкивался с подобными проблемами. Со временем интуитивно начал "угадывать" реальные сроки +/- 20%. Т.е. для крупных задач приемлемая погрешность. Но меня это не устраивает. Если срок ставишь в 200 чел/дней, то ошибка в 20% - 40 дней. Один чел/день оценивается минимум в 200 американских рублей, т.е. ошибка может стоить 8К. Конечно лучше когда я ошибаюсь в боьшую сторону.
Полученные доп. дни можно дополнительно загрузить лишним прогоном по тестам и усовершенствованием пользовательской документации (но тоже не удобно - люди видят, что я воду лью).

В общем начал смотреть в сторону COCOMO2. Суть такая, что все что можно измерить, нужно измерить. Любая прикладная бизнес-задача сводится к определенному числу таблиц с определенным числом полей. Там же определенное число связей. В интерфейсе определенное число диалоговых окон с определенным числом управляющих элементов. И определенное число выходных отчетов с определенным числом элементов (заголовки, строки, итоги).
Соответственно, все это можно посчитать на опыте предыдущих проектов (другого пути нет) и вывести общую формулу.

Суть, думаю, я довел - остальное легко можно найти в спец источниках.

_________________
я пишу "Непопулярные заметки"

Денис Шаповаленко
Я немного о другом. То, что можно проинтуичить срок и затраты, это одно. Кстати, +-20% для связанных в клубок систем не удается получить даже при неплохом знании предмета и наличии статистики предыдущих внедрений. Всегда на этапе системного тестирования находится заковырка, которая непредсказуемо изменит срок проекта.
Все-таки хочется знать, можно ли на языке финансистов выразить РЕАЛЬНОЕ течение проекта внедрения с отражением многопроходности, существенных сдвигов сроков и т.п.?
А то в реалии имееем "клубок проблем", а в планах финансистов вместо этого "клубка" срок и цена - все очень просто, но неверно.
Быстрый поиск дал странные ссылки на COCOMO2. Нет ли у Вас случайно ссылки на COCOMO2, чтобы ознакомиться в целом?

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

Вариант 2:
Определяете сроки и условия, которые должен выполнить заказчик для выполнения этих сроков (режим max поддержки и благоприятствования etc). Заказкика (всегда) хватает не на долго - по объективным причинам. Таким образом, Вы задержку переваливаете на плечи заказчика и НЕ паритесь - и спокойно работаете. Он Вас не достает, Вы делаете свое дело. И все согласно договора! Проверено множество раз на самых разных внедрениях: "железо", it, услуги.

Вариант 3:
Согласно статистике - ошибка всегда + 30%.
Практика показвает - оно так и есть.
Заранее учтите эту ошибку, но работайте так, как будто срок без учета ошибки - тогда пролезете по срокам.

Для несложных поставок тоже годится.
Работает.

Вариант 4:
Закон Мерфи:
При определении сроков поставки:
1. Рассчитайте необходимый срок
2. Умножьте его на 2
3. Переведите в цифры следующего более высокого порядка

Таким образом, если первоначально необходима было 1 неделя, то реальный срок составит 2 месяца.

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

_________________
Пусть Путь Ваш освещается Светом Души Вашей!

Все возможно.
Для этого существует управление проектами.
в MS Project все давно реализовано.

Ссылка по теме:
[...]
Автор - Вадим Богданов - является автором русского учебника по использованию MS Pro + официально локализует эту компоненту на русский язык для корпорации Microsoft.
Я был у него на семинарах - Вадим дело знает и умеет грамотно объяснить. Так что для начала купите книги - по MS Project и по методологии управления проектами.

Для постановки методологии рекомендую:
Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г.
Управление проектами: учебное пособие
М: Омега-Л, 2004
(Постоянно переиздается)

_________________
Пусть Путь Ваш освещается Светом Души Вашей!

Czyan
За ссылки спасибо.
Все-таки думаю, что мы говорим о разных проектах. Если проект - доработка функционала существующей системы, то, возможно, 30% - обычная ошибка. Если проект - переход на другую систему (например, 1С 7.7 -> 1С 8.0) с переносом немалого доработанного функционала и данных, то 1000% - максимум, 500% - обычное дело, 100% (т.е. в 2 раза). Речь идет о проектах, которые занимают по благоприятным расчетам не менее полугода.
Вариант 1 отпадает, ибо заказчик хочет заплатить за комплекс в целом. И чтобы ответственность за работоспособность комплекса в целом нес один исполнитель. Так легче вернуть деньги при неисполнении заказа.
Вариант 2 - читал и не понял. Можно переформулировать?
Вариант 3 - 30% для процесса перехода на новую платформу ... это же просто праздник какой-то. 30% подойдет для доработки функционала, который несильно интегрируется в основную систему.
По крайней мере у меня такая статистика из разных источников.
Вариант 4 отпадает из-за заведомо непростого расматриваемого случая.

Чистое проектное внедрение на практике для большинства компаний приведет к неудаче. Проект будет выполнен, но он никому не будет нужен. Причина - как правило переход на другую систему (давайте уж я буду тогда рассматривать именно этот случай) начинается в условиях, когда заказчик уже не представляет как автоматизированы его бизнес-процессы и в состоянии лишь отвечать на конкретные вопросы, не подозревая, что в тени остаются существенные для разработки моменты (например, могут не сообщить о каких-то нестандартных хозоперациях типа возврата и т.п., могут даже в один момент времени сказать одно, в другой - абсолютно противоположное и т.п.).
Можно долго обсуждать кто прав, а кто виноват, но единственным реальным на сегодняшний день решением, приводящим к рабочему результату, является путь построения прототипов. Разве он укладывается в проектную технологию?
По сути сейчас многие проекты в процессе своей жизни плавно мигрируют в прототипный вариант автоматизации.

Добавлю еще, возможно опережая события, что и экстремальное программирование (ЭП) неприменимо в данном случае. Основа ЭП - полный исчерпывающий набор тестов, 100%-ное выполнение которых есть по сути ответ на вопрос работает система или нет.
Невозможность составить полный набор тестов для программ учета делает невозможным применение в полном объеме ЭП.

Если мы говорим о создании новой системы, это одно, если о переходе с платформы на платформу - совсем другое.

При переходе с платформы на платформу, все зависит от качества реализации исходного проекта. Если есть качественная проектная документация и код написан не сапожником и не индусом, то на первом этапе необходимо изучить проект, изучить рекомендации разработчика платформы о процессе перехода и тогда строить свои планы. Для сложных систем, можно выполнить тест-проект сроком до пары недель, на котором отработать все основыне моменты.
Если проект был сделан "на коленке" без документации и с постановками типа "чтобы вот", то и переход будет таким же. Тут возможно даже просто написание задачи с нуля.

При разработки сложных прикладных задач рекомендую проект разделить на несколько этапов. После беседы с заказчиком можно сформировать основные задачи, реализуемые сиситемой и в относительно короткие сроки реализовать первый релиз с основным функционалом. Этот релиз отдать заказчику на опытную эксплуатацию. И вот после этой опытной эксплуатации, можно будет что-либо определить с конечным результатом.

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

Про КОКОМО: [...] ftp://ftp.usc.edu/pub/soft_engineering/ ... delman.pdf

Ну и википедия: [...] там внизу хорошие ссылки

_________________
я пишу "Непопулярные заметки"

У нас есть ТЗ (ТехЗадание) - сделать что-либо. В данном случае неважно что.

Работа производится при тесном взаимодействии с заказчиком. Если этого взаимодействия нет - необходимо создать/придумать/обосновать.

В рамках этого взаимодействия заказчик должен в достаточно сжатые (но разумные - не нужно злобствовать ) срок предоставлять что-либо/согласовывать/делать.

Срыв сроков согласования на n-дней ведет к n-числу дней задержке сдачи проекта.
Если сроки предоставления заказчиком чего-либо срываются на большое число дней - напр, на 30 дней - сроки должны согласовываться отдельно.... читайте "сроки плывут в никуда"...

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

_________________
Пусть Путь Ваш освещается Светом Души Вашей!