Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: AlexP от 29 Декабря 2008, 16:02:26
-
Коллеги, добрый день!
На работе столкнулся с такой задачей.
Есть информационная система (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 минут работы?
Программист - нет, за то что я знал как...
-
Соответственно, появилась задача, суть которой заключается в создании некой методики в рамках проекта, которая бы сделала процесс оценки трудоемкости доработки более прозрачным и понятным для обоих сторон.
Может кто-нибудь уже сталкивался с подобный вопросом? Существуют ли какие-либо методики, стандарты?
Добрый день, Саша!
Для данных целей существует методика оценки трудоемкости CETIN, которая в том числе дает оценку трудоемкости и стоимости доработки программного обеспечения. Принципы методики приведены http://www.factor.kz/publ/detail.php?ID=1 (http://www.factor.kz/publ/detail.php?ID=1)
-
>> существует методика оценки трудоемкости CETIN
существует - это громко сказано, насколько я понимаю это методика разработана для Гос заказов в Казахстане. Мирового признания пока не получила.
-
В рамках госзаказа да, т.к. методика ориентирована на раннюю оценку и применяется в госзаказе.
Но никто не мешает воспользоваться ее принципами, нежели использовать расчет по строкам кода
-
http://www.nitec.kz/?mod=chapter&lng=rus&opt=viewdoc&id=343
Методика, которая используется в Казахстане.
-
Саша, позволь добавить свои "5 коп.":
Если я правильно понял, существует следующая проблема:
Есть общая задача на доработку (разработку) функционала. Эта работа заказывается некоторому внешнему исполнителю. Исполнитель выкатывает какие-то оценки (с тайной мыслью: попробуй проверь!). Вам данные оценки кажутся неадекватными. Как самим получить оценки, которым вы а) доверяете и б) с которыми вы можете сравнить оценки исполнителя.
Я в такой ситуации поступил бы следующим образом:
- во-первых: оценил бы масшатаб работ. Это то, что входит в такую область деятельности, как "Change Management". Об этом очень подробно написал Денис. Добавить можно только некоторые незначительные моменты. Для чего это делатся? Мы оцениваем общий скоуп работ- определяем границы будущей работы;
- нам необходимо оценить стоимость элементов входящих в этот скоуп. Здесь возможны два варианта:
- Исполнитель провел декомпозицию работ (WBS). Разбил общую задачу на атомарные шаги (работы). Потом оценил. Об этом писал Shur. Вы в свою очередь, тоже, запросив его декомпозицию, экспертным путем оценили трудозатраты на каждую атомарную задачу. Потом сравнили. Если оценки исполнителя на выполнение конкретной задачи сильно отличаются от вашей в большую сторону, необходимо выяснить "почему?". Как это сделать? Есть много техник так называемого Root Cause Analysis. Нет смысла затевать какое-то глобальное исследование. Можно использовать самый простой его вариант: "5 Why?". Считается, что достаточно 5 раз последовательно задать вопрос "почему?" ??? и вы докопаетесь до истинной причины. Пример из личной практики. Мы очень успешно использовали данный прием в общении с нашим удаленным разработчиком. Выясняя, почему он на выполнение плевой работы запрашивает несколько дней, в конце концов высняли, что собственно работа будет выполненна за 2 часа, остальное время - это почитать о новой технологии (т.е. читай - самообучится за счет проекта), потратить полдня на техосмотр машины и т.п.
- второй вариант - это когда исполнитель описывает и затем разрабатывает (кодит) требования в форме Вариантов Использования (Use Cases). Для оценки затрат на реализацию требования в форме ВИ разработана и успешно используется методика Use Case Points. Вот здесь лежит очень внятный документик: http://www.bfpug.com.br/Artigos/UCP/Banerjee-UCP_An_Estimation_Approach.pdf (http://www.bfpug.com.br/Artigos/UCP/Banerjee-UCP_An_Estimation_Approach.pdf) Понятно, что это оценка очень средняя, но во всяком случае позволит выявить ситуацию, когда вам пытаются впарить за $6000 работу, стоимостью в $700. Это будет хорошей базой для обсуждения цен исполнителя (вспоминаем "5 Why?" :) )
-
второй вариант - это когда исполнитель описывает и затем разрабатывает (кодит) требования в форме Вариантов Использования (Use Cases). Для оценки затрат на реализацию требования в форме ВИ разработана и успешно используется методика Use Case Points
alex6565, согласен с вами в том плане, что при разработке новой системы оценка use case работает отлично, но в процессе доработки сам вариант использования может не измениться, меняется внешняя среда, интеграция между компонентами, т.е. получается необходима детализация UC.
- при большой степени детализации целесообразнее использоватьIFPUG - www.ifpug.org (http://www.ifpug.org)
- при малой степени детализации CETIN - factor.kz/~CETIN (http://factor.kz/~CETIN)
-
- при большой степени детализации целесообразнее использоватьIFPUG - www.ifpug.org (http://www.ifpug.org)
- при мало степени детализации CETIN - factor.kz/~CETIN (http://factor.kz/~CETIN)
Пасиб! Очень интересно - обязательно почитаю!