Коллеги, добрый день!

На работе столкнулся с такой задачей.

Есть информационная система (CRM). Она постоянно дорабатывается в соответствии с требованиями заказчика.
Дорабатывается она самим вендором. Разработчик поддерживает только одну ветку разработки, т.е. не создает отдельных версий под конкретного заказчика.

Проблема состоит в том, что у нас, как у заказчика, нет возможности оценить даже приблизительно, на сколько адекватны те трудоемкости, которые нам пытаются "продать" исполнитель.

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

Может кто-нибудь уже сталкивался с подобный вопросом? Существуют ли какие-либо методики, стандарты?

С ув., Саша

Это классическая проблема из сферы получения прибыли, которая строится на сокрытии истинной трудоёмкости.

Я не очень понимаю, зачем таковая прозрачность Компании-Разработчику. Существует традиционный подход к оценке трудоёмкости и стоимости изменений у него:

1. Если у Разработчика есть база требований с зависимостями, то при возникновении изменений, можно увидеть, какое количество косвенных модификаций породит данная.

2. Далее, на основании базы сведений о длительности реализации требований, выполненных в продукте, от лица аналитика и тимлида или, в идеале, команды, занимающейся данной функциональностью продукта, возникает оценка трудоёмкости данного функционала.

3. Далее Разработчик смотрит на предмет того, насколько данное изменение будет полезно остальным Клиентам, если скорее бесполезно, то возникает дополнительный коэффициент стоимости.

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

Эта схема в общем и целом разумна для Компании-Разработчика, но делать её прозрачной для Заказчика ему не очень выгодно.

Кстати, есть простой ответ — если вы умеете считать бизнес-эффект от новых фич и изменений, то сможете отсекать нерентабельные доработки. Если не умеете — придётся играть в политику.

Я пытаюсь решать этот вопрос именно с точки зрения Заказчика, а не разработчика... :-)

Я пытаюсь решать этот вопрос именно с точки зрения Заказчика, а не разработчика... :-)

А что тут решать?
Заказчик: Сколько времени займёт реализация фичи A?
Разработчик: 50 часов
Заказчик: Почему?

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

Поэтому лучший способ добиваться прозрачности — либо доверие, либо детализация сметы работ с точностью до задач, занимающих не более 3-5 человекодней.

На самом деле это бич Заказчиков особенно при доработке тиражируемых Решений.
И наверное кроме как требовать детальную смету - ничего не поможет.

Именно таким образом уменьшается стоимость возведения дома в строительстве -- детализацией сметы :-).
Но в разработке софта не так все просто. Если вы работаете по T&M с вашим разработчиком - то все равно у разработчика есть преимущество. Даже если вы их заставите писать реальное время, затраченное на разработку -- то они вам просто rates свои поднимут :-). И тут вопрос, можете ли вы отказаться от этой системы и быстро перейти на другую? Скорее нет, ибо если разработчик не идиот -- то будет делать так, что TCO этой CRM для вас будет меньше, чем переход на новую.

На мой взгляд, Заказчик, пытаясь обсуждать с Разработчиком трудоемкости доработок, заведомо играет на чужом поле и обречен на проигрыш. Согласен с Юрием, что "если разработчик не идиот", то найдет способ обосновать свои затраты.

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

На месте Заказчика я бы поискал возможности перевести переговоры с Разработчиком в более рыночное русло. У них товар, они хотят его продать, вы хотите купить, так обсуждайте цену, а не потенциальные затраты Разработчика. Попытайтесь как-то оценить экономический эффект от тех доработок, которые вы заказываете, и отсюда понимать, какие деньги вы готовы за это платить. Неплохо также было бы оценить альтернативы:
 - может ли эти доработки выполнить другой подрядчик? если да, можно ли организовать тендер среди потенциальных подрядчиков?
 - можете ли вы выполнить какую-то часть доработок своими силами?
 - а что если вам сэкономить деньги и НЕ заказывать доработок системы? (хотя бы временно) Вы больше нуждаетесь в этих доработках или компания-разработчик - в том, чтобы их продать?

Обычно даже самый малый намек Заказчика на то, что он рассмотривает возможные альтернативные варианты, оказывает эффект сродни детализации сметы в строительстве :-)

Бывает и так:

Описали Разработчику некую МаленькуюФичу. Разработчик объявляет - 6000 евро. Мы все в шоке - какие 6000, чего там делать-то?

Созваниваюсь с менеджером Разработчика

Я: Почему 6000?
Разработчик: Наш Отдел Разработок оценил это так.
Я: Можете детализировать?
Разработчик: Ля-ля Ля-ля ... вы не знаете нашу систему.... Ля-ля Ля-ля ... многопоточный серверный процесс ... Ля-ля Ля-ля
Я: Какой многопоточный серверный процесс? У вас что шедулера нету?
Разработчик: Ээээ Ну я обсужу ещё раз эту тему с Отделом Разработки

Через неделю договорились на 700 евро.

В целом соглашусь с тем, что Разработчик находится в более выгодном положении.
Однако и Заказчик изучая детализацию и видоизменяя требования может существенно повлиять на стоимость. Легко может оказаться что 80% трудозатрат пойдут на совершенно непринципиальные для Заказчика вещи.

Кстати, есть простой ответ — если вы умеете считать бизнес-эффект от новых фич и изменений, то сможете отсекать нерентабельные доработки. Если не умеете — придётся играть в политику.

А можно по-подробнее? О каких методиках идет речь?

С ув., Саша

А можно по-подробнее? О каких методиках идет речь?

Считать бизнес-эффект = получать количественную оценку изменения KPI в результате внедрения новой фичи — увеличение числа покупок, заказов, просмотров и т.д. и переводить их в деньги. Метод получения оценки зависит от вида бизнеса.

Почему Вы считаете, что цена несправедлива или сроки преувеличены? Может, это просто "антикризисный костинг", призванный любой ценой снизить затраты в краткосрочном периоде?

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

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

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

И ещё - считайте те трудозатраты и риски, которые потребует внедрение нового решения и/или построение взаимодействия с новым франчайзи со стороны Ваших сотрудников.

Есть ещё одна опасность. Начнёте "отжимать" своего вендора/франчайзи - он может начать делать дешевле, с меньшим "заделом на перспективу", "запасом прочности", с худшей архитектурой, не таким тщательным тестированием. Худшей мотивацией и качеством, в конце концов. И это может стать "плевком в будущее".

По поводу экономического эффекта - по-хорошему, нужно его прогнозировать, а для этого иметь:

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

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

Вот для этого и нужен реальный уровень CMM . Хотя многие IT-гики считают, что IT нельзя оценить и некорректно оценивать.

Почему Вы считаете, что цена несправедлива или сроки преувеличены? Может, это просто "антикризисный костинг", призванный любой ценой снизить затраты в краткосрочном периоде?
Есть ещё одна опасность. Начнёте "отжимать" своего вендора/франчайзи - он может начать делать дешевле, с меньшим "заделом на перспективу", "запасом прочности", с худшей архитектурой, не таким тщательным тестированием. Худшей мотивацией и качеством, в конце концов. И это может стать "плевком в будущее".

В моих планах нет цели кого-то "отжимать, ухудшать мотивацию в проектной команде, уменьшать запас прочности" и т.п.

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

В моих планах нет цели кого-то "отжимать, ухудшать мотивацию в проектной команде, уменьшать запас прочности" и т.п.

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

1. Необходим план доработок исполнителем, каждый пункт которого отражает дискретный этап работы, который может также дискретно оцениваться "сделано/не сделано" - соответственно не должен содержать расплывчатых определений "улучшение", "доработка".
2. Оценка человекочасов для каждого этапа - benchmarking по аналогичным работам уже выполнявшимся Исполнителем или разработчиками Вашей компании. Оценка должно проводиться с участием специалистов, имеющих реальный опыт разработки приложений в данной или близкой технологии. Метрики для сопоставления/оценки работ выбрать с учетом предпочтений участников процесса оценки трудоемкости (типа кол-во отчетов, интерфейсных форм, полей в форме, таблиц и пр. - для каждой задачи наиболее адекватные с согласия сторон - не пытайтесь сделать универсальный список на все случаи жизни). Искать какие-нибудь "абсолютно объективные" методики не советую - все они так или иначе содержат фактор субъективной экспертной оценки функционала, опирающийся на некий общий опыт/практику Исполнителя и Заказчика + возможно, громоздкие наукообразные расчеты.
3. Утверждение/согласование как плана, так и трудоемкости должен включать аргументированное согласование оценок (и предложенных метрик, задач-аналогов, использованных в качестве исходных). Если Заказчик считает деньги, молчаливое принятия оценок как основной режим работы мало реально.

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

По этому вопросу вспомнился анекдот...
В компании сломался сервер, нарушилась переадресация и т.п. - решали своими силами неделю, вторую - ничего не помогает... Вызвали специалиста со стороны... Он сел за компьютер, через 10 минут встал - говорит: "Готово"!
Директор счастлив, радуется, спрашивает, - сколько?

Программист - 500 у.е.!
Директор: за что?? За 10 минут работы?
Программист - нет, за то что я знал как...