Xpoint
   [напомнить пароль]

Оценка стоимости проекта

Метки: [без меток]
2005-12-02 14:30:38 [обр] dms(5/9)[досье]
Коллеги, давайте вернемся к весьма расплывчатой теме "Оценка стоимости проекта".
Все мы привыкли, что клиенты часто прямо с порога пытаются нас ошарашить вопросом "Сколько у вас стоит Человеко-Час разработчика". Такая постановка вопроса традиционна. Но вот на сколько она оправдана?
Во-первых, я очень слабо могу себе представить программиста-разработчика, который три часа работает над одним проектом, потом - полтора - над другим, и еще три с половиной над третьем. Мы все понимаем, что программист - не каменщик, которого вы можете перекидывать с одной стенки на другую без ущерба для всей стройки. Программисту подумать, втянуться надо и т.д. В общем - и два трудодня над одним проектом, потом - один над другим, потом опять два на первом - тоже представить себе трудно.
Во-вторых, даже если я скажу, что мой - к примеру - ЯВА-программист стоит ХХ тугриков в час или в день, а мой конкурент - YY тугриков, то не очень понятно, что может такой ответ сказать заказчику? Что мой программист лучше? Что я хуже умею организовывать его работу, что у меня стоит более качественное оборудование, что я создаю более приличный условия работы для разработчика, что у меня большие или меньшие накладные расходы и т.д.?
В-третьих. И наверное - в главных. В последнее время я на такой вопрос клиента задаю ему контрвопрос, - а как вы измеряете трудоемкость проекта? Если он не может внятно ответить на этот вопрос - а это бывает зачастую именно так - то тогда следует следующий вопрос - тогда зачем Вам стоимость человека-часа, ведь если оценка трудозатрат идет от фонаря, то оценка труда - идет примерно так-же.
Т.о. мне часто удается отвратить клиента от попыток мерять мифические человеко-часы а перейти на фиксированную стоимсоть проекта, объясняя при этом, что риск в ошибке объема работы при этом ложиться всецело на меня.
И хотя до сих пор пререкания клиента на этом заканчиваются, но я предвижу, что рано или поздно появиться заказчик, который захочет что-бы я ему обосновал, а какова все-таки трудоемкость проекта.
Есть конечно CОСОМО, есть другие "тяжелые" методы, есть старые совестские ГОСТы, был когда-то подход - считать в количестве строк кода (самое интересное, что кода еще в момент составления ТЗ как правило нет и им не пахнет). Но все это больше теория, или может-быть даже практика, но для "тяжелых", многолетних, многомиллионных проектов с несколькими сотнями исполнителями.
И вот собственно тема для обмена опытом и размышлений:
Как реально измерить трудоемкость БУДУЩЕГО проекта на этапе предварительного собеседования с клиентами, на этапе составления ТЗ и т.д. для средних проектов? Так что-бы и клиенту стало понятно, и себя любимого не обидеть и от правды было не далеко и главное - что-бы это могло бы быть хотя-бы экспертно (я уже не говорю - на уровне методики)проверено и подтверждено.
Давайте сосредоточимся пока именно на затратах кодеров-разработчиков-тестеров-аналитиков-руководителей проекта. А собственные накладные расходы и маржу каждый добавит уже сам :-).
спустя 1 час 52 минуты [обр] Денис Прилуцкий(0/66)[досье]
Вам поможет Function Point Analysis: http://www.pmprofy.ru/content/rus/20/203-article.asp
Есть еще Quick Function Point Analysis — как раз для случаев оценок "на коленке".
спустя 1 час 52 минуты [обр] Thirteensmay(0/157)[досье]
К счастью данная задача не решается детерминированно в принципе. Среди кого Вы хотите жить ? Стоит обьяснять это клиентам. m1: Если Ваши клиенты не способны думать - можете взять любую методику и притянуть ее к любым интересующим Вас цифрам - будет на что сослаться ;) Ессно желательно обладать некоторыми реально-приблизительными цифрами от которых можно былобы оттолкнуться - ну так этоже элементарно - обсудите проблему со своим персоналом за чашкой чаю - я надеюсь Вы общаетесь с нормальными людьми, иначе зачем они Вам ? - будут у Вас реальные цифры. А почему не решается в принципе ? - ну объясните мне что такое человеко-час ? или вездесущая трудоемкость анализа ? или еще миллион или... Не стоит рассчитывать трудоемкость - ее надо оценивать, в противном случае можно получить в глаз. В приложении к рассчету это всего лишь один из элементов западной потогонной системы. Так среди кого Вы хотите жить ? Говорите уроды с деньгами шарятся ? - goto m1;
спустя 6 дней [обр] dms(5/9)[досье]

2 Денис Прилуцкий
Что такое Function Point Analysis - более-менее понятно, как и СОСОМО. Но это пожалуй "тяжелый" метод. А вот о Quick Function Point Analysis - ничего не слыхал. Можно-ли попобробнее, или хотя-бы ссылочку.

2 Thirteensmay
Ваше описание на 105% соответствует моим реалиям :-). Вот только не всегда это "прокатывает", особенно, если разговориваешь с западными заказчиками. Поэтому и хотелось-бы как-то прикрыть тылы :-)

спустя 1 час 33 минуты [обр] Денис Прилуцкий(0/66)[досье]
dms[досье]
Этот метод иногда называют еще Early Function Points. Вот ссылка на общее описание метода: http://nemoluca.nm.ru/fpoints/fp_1.htm
спустя 5 дней [обр] dms(5/9)[досье]
Самое интересное, что там есть и более полное изложение http://nemoluca.nm.ru/fpoints/fpoints.htm.
Вот только жаль - без всех необходиміх таблиц и картинок :-(
спустя 21 день [обр] z...(25/47)[досье]

dms[досье]

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

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

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

Проблема может быть в последнем пункте, не все готовы честно называть желаемую прибыль (маржу) с проекта. Но это вопрос культуры менеджмента заказчика и исполнителя...

спустя 5 дней [обр] Sergei Erjemin (webdragon)(18/182)[досье]

dms[досье]
На самом деле, спршивая вас о ваших расценках человекочасв и прочих аспектвх предстоящих разработок заказчика интересует совсем иное. И даже еще больше: слушая вас он слышит совсем не то что вы ему говорите. Это нормальный переговорный процесс и не надо боятся таких вопросов и пытатся дать чткое обоснование. Такие вопросы — повод для вас сделать очередную презентацию себя и ваших услуг.

Вы правильно поступаете переводя разговор на общую оценку трудоемкости... можно даже усилить, заявив, что ваш спецталист стоит 200 или 500 у.е. в час. Просто он делает все в 150 раз быстрее конкурентов... а ваши замечательные технологии и ноу-хау (на которые затрачено более 60000 чел.часов) в смету не включаются, и на самом деле для выбора подрядчика нужно проводить перекрестный бенчмаркинг и прочее... не лучше ли положиться на отзывы наших заказчиков (прилагаются) и послужной список завершенных проектов.

спустя 11 дней [обр] z...(25/47)[досье]

! Sergei Erjemin (webdragon)[досье], фигню советуете. Старнно, не похоже на Вас.

Я о Вашей фразе

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

Это называется "дешевый развод лоха". Конечно, бывают клиенты которые на это клюнут.

Но намного больше клиентов, которые:

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

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

спустя 10 минут [обр] z...(25/47)[досье]

В продолжении темы.

dms[досье],
главный совет - четко представляете из чего складывается бюджет проекта, какова себестоимость, накладные расходы, норма прибыли, резерв на риски.

Если вы все это знаете, регулярно рассчитываете это "для себя" - то и до клиента всегда донести можно (чай, тоже в своей предметной области, в своем бизнесе аналогичные задачи решает), а если не знаете - то и клиента не убедите.

спустя 23 часа [обр] Thirteensmay(0/157)[досье]
А причем тут бухгалтерия ? Если человек не способен понять что затраты на анализ не поддаются
оценке - можно считать за счастье развести такого лоха, особенно западного...
спустя 2 дня 10 часов [обр] Sergei Erjemin (webdragon)(18/182)[досье]

z...[досье]
Это как вам угодно называйте. Решения о покупке все равно принимаются в значительной степени на ирациональном и эмоциональном... спонтанно. В большинстве случаев. И практически всегда если стоимость (потребление ресурса) у альтернатив примерно эквивалентна! Даже при условии проведения жестких тендеров и прочей лабуды есть масса способов воздействовать ирациональные каналы принятия решений... Главное иметь подод к людям а не умение рационально объяснить и оценить проект... Это для того чтобы начать переговорный процесс можно применять экономические модели ProjectExpert и оперировать коэфициентами рентабельности, ROI, IRR и прочим инструментарием "большого" бизнеса. А если переговорный процесс уже начат, то важно провести переговоры и увести их в область ирационального принятия решений, а не экономическое обоснование.

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

спустя 13 часов [обр] z...(25/47)[досье]

Уважаемый Sergei Erjemin (webdragon)[досье]!

Вот в такой формулировке с Вами согласен.
Неужели сами не заметили разницу между вашим последним сообщением и заявлениях про сотни долларов в час и тысячах человеко-часов? И потом, тайные знания о том как люди принимают решения – отлично. Но необходимость строгого управления бюджетом в проектах разработки – никто никогда не отменял. В любых методологиях – от RUPа до XP (я даже и не говорю про такие "инструменты большого бизнеса" как PMI, Prince2, P2M).

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

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

спустя 12 минут [обр] Денис Прилуцкий(0/66)[досье]

Sergei Erjemin (webdragon)[досье] Совершенно с Вами не согласен. Решение о покупке принимается в случае совпадения ожиданий клиента с предложением поставщика. Ничего иррационального в этом нет. Неужели Вы, собираясь купить, к примеру, утюг, прийдя в магазин, купите швейную машинку только потому, что Вас здорово "загрузили" продавцы-консультанты? Скорее всего, Вы, намереваясь купить утюг, уже приблизительно знаете с какой суммой Вам придется расстаться, что Вы за это получите, и мысленно готовы к этому. И единственным Вашим ожиданием будет ожидание адекватного предложения. А если Вы придете в магазин, чтобы Вам сделали проедложение купить утюг приемлемого для Вас качества за приемлемую для Вас цену, а вместо этого Вам начнут "напаривать" швейную машинку, то, скорее всего, Вы просто пойдете в другой магазин.

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

"Правильный подход к людям" — это в баньке с девочками попариться? А заодно и контрактик подмахнуть? Как-то это, извините... непрофессионально...

Простите за возможно излишнюю эмоциональность.

спустя 8 часов [обр] Александр aka Efreeti(0/111)[досье]

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

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

спустя 15 часов [обр] Денис Прилуцкий(0/66)[досье]

Александр aka Efreeti[досье]
Подождите... Возвращаясь к первоначальному вопросу, мы обсуждаем методологию обоснования стоимости разработки некоего решения для клиента, а не продажу ему некоего продукта. Колбаса стоит 3.50 за кг, и покупателя колбасы не интересуют трудозатраты, нормы прибыли, стоимость человеко-часа и прочие детали, когда он хочет колбасы. Тут Вы совершенно правы — покупателю нужно объяснить, что Ваша колбаса — самая вкусная. И что если он купит вагон колбасы за 350 млн., то 50 млн. он получит "откатом" (а на самом деле вагон колбасы и стоит 300 млн.). Тут я согласен.

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

Вариант первый... У этого потенциального заказчика есть бюджет Х, из которого он хочет получить "откат" Y. Соответственно, бюджет проекта по выпуску особеной колбасы составит X-Y. С помощью формальных методик оценки Вы определяете рентабельность данного проекта. В случае, если рентабельность Вас не устраивает — Вы предоставляете заказчику Вашу оценку, проведенную по формальным методикам, и обсуждаете увеличение бюджета.

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

В любом случае, "откатная" технология не делает Ваш проект нерентабельным. Не так ли?

спустя 5 часов [обр] Александр aka Efreeti(0/111)[досье]

Денис Прилуцкий[досье]
В большинстве случаев заказчик не смыслит ничего в производстве колбасы, поэтому все ваши раскладки для него - тёмный лес. Туда можно понаписать много чего. Если будет нанят консультант - тогда да. Иначе никто не будет рассматривать все эти расчёты.
А для себя, как я понял, автор топика и сам рассчитать может. Вопрос был в подаче клиенту этой информации. Так вот, при подаче более важна форма, а не содержание.

У Джоела на эту тему было хорошо написано.

спустя 11 дней [обр] Sergei Erjemin (webdragon)(18/182)[досье]

Денис Прилуцкий[досье]
Александр aka Efreeti все првильно ответил... Но даже в случае нанятого консультанта решение будет принято на ирациональном уровне... Все рациональные объяснения мозг уже постфактум приспособит к принятому решению.

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

Powered by POEM™ Engine Copyright © 2002-2005