Как научиться расчитывать затраты человеко-часов на написание системы с заданными требованиями? Особенно если функции не везде расписаны подробно, и иногда вскрываются непонятные места в задании, не до конца описанные требования.
Это возможно делать, не тратя 10 лет на программирование?

Здравствуйте, D.O., Вы писали:

DO>Как научиться расчитывать затраты человеко-часов на написание системы с заданными требованиями? Особенно если функции не везде расписаны подробно, и иногда вскрываются непонятные места в задании, не до конца описанные требования.
DO>Это возможно делать, не тратя 10 лет на программирование?

Сомнительно. Особенно если в задании есть непонятные места. Даже стандарты управления проектами говорят: первый год компания лишь целенаправленно набирает статистику. Дальше она использует эту статистику для управления сроками проекта в первом приближении. То есть второй год (и последующие) она сравнивает прогнозы и итоговые сроки.

Здравствуйте, D.O., Вы писали:

DO>Как научиться расчитывать затраты человеко-часов на написание системы с заданными требованиями? Особенно если функции не везде расписаны подробно, и иногда вскрываются непонятные места в задании, не до конца описанные требования.
DO>Это возможно делать, не тратя 10 лет на программирование?

Почитай про COCOMO, к примеру. Она именно для этого и предназначена.

Один человек на реальных проектах это никогда точно не оценит.
Группой, проводя review планов, можно давать довольно точные оценки.
А вообще да, это приходит только с опытом.

Здравствуйте, D.O., Вы писали:

DO>Как научиться расчитывать затраты человеко-часов на написание системы с заданными требованиями? Особенно если функции не везде расписаны подробно, и иногда вскрываются непонятные места в задании, не до конца описанные требования.
DO>Это возможно делать, не тратя 10 лет на программирование?

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

Например, программист говорит: 8 недель. Множим на 2. 16 недель. Округляем по месяцам и получаем 4 месяца.

Здравствуйте, D.O., Вы писали:

DO>Как научиться расчитывать затраты человеко-часов на написание системы с заданными требованиями? Особенно если функции не везде расписаны подробно, и иногда вскрываются непонятные места в задании, не до конца описанные требования.
DO>Это возможно делать, не тратя 10 лет на программирование?

Если требования не до конца — нельзя.
В общем случае для одного человека — Personal Software Process

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Например, программист говорит: 8 недель. Множим на 2. 16 недель. Округляем по месяцам и получаем 4 месяца.

И миллион баксов примерно. И заказчик говорит: — а пошли не пошли бы вы, ребята, нах.

Здравствуйте, D.O., Вы писали:

DO>Как научиться расчитывать затраты человеко-часов на написание системы с заданными требованиями? Особенно если функции не везде расписаны подробно, и иногда вскрываются непонятные места в задании, не до конца описанные требования.

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

Человеко-часы поддаются калькулированию при достаточно чётком знании временных затрат на различные работы. Эти затраты достаточно индивидуальны для каждой компании, поэтому ИМХО только с опытом анализа уже созданных проектов можно с достаточной степенью приближения вычислить время на различные виды работ.

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

Однако, могу могу поделиться, как это делалось ранее (простыми словами).

1) Вариант "по аналогии" — берётся сходная по требованиям задача, которая была уже реализована и из неё берётся объём человеко-часов.

2) Вариант "расчёт участниками" — строится план реализации задачи, затем конкретные исполнители анализируют собственные задачи, а вы собираете эти данные и на их основе формируете конечную сумму, включая временные затраты на логистику и административную часть (процентов 50 плюс).

Можно заказать оценку у консалтинговой компании, если бюджет задачи позволяет это сделать.

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

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

P.S. Можно сделать "финт ушами" и скинуть задачу (предварительно слегка её переправив) какой-нибудь другой (а то и нескольким компаниям) и запросить у них стоимость работы и стоимость их человеко-часа (среднего), а потом вычислить количество человеко-часов. Но это опять только прикидки...

Здравствуйте, Gollum, Вы писали:

СШ>>Например, программист говорит: 8 недель. Множим на 2. 16 недель. Округляем по месяцам и получаем 4 месяца.

G>И миллион баксов примерно. И заказчик говорит: — а пошли не пошли бы вы, ребята, нах.

Юмор непонятен, ибо процедура общеизвестная и проверенная десятилетиями. Можно даже дать ссылку на весьма серьёзную литературу.

Здравствуйте, Слава Шевцов, Вы писали:


СШ>Юмор непонятен, ибо процедура общеизвестная и проверенная десятилетиями. Можно даже дать ссылку на весьма серьёзную литературу.

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

Здравствуйте, Gollum, Вы писали:

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

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

Подработать под свой проект эту схему не сложно.

Одно важное замечание — хорошо бы дать понять заказчику, что от него тоже потребуется кое-какая работа...

СШ>Можно даже дать ссылку на весьма серьёзную литературу.
ССЫЛКУ-ССЫЛКУ-ССЫЛКУ-ССЫЛКУ-ССЫЛКУ!

Здравствуйте, Gollum, Вы писали:

СШ>>Юмор непонятен, ибо процедура общеизвестная и проверенная десятилетиями. Можно даже дать ссылку на весьма серьёзную литературу.
G>Для дней может это и подходит а для месяцев уже нет. Ждать вместо трех месяцев полгода никто не будет, нужно уметь обосновать сроки чем-то кроме такой замечательной формулы.

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

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

Здравствуйте, D.O., Вы писали:

DO>Это возможно делать, не тратя 10 лет на программирование?

Эх молодость, отдайте мне ее обратно (бесплатно работать буду). Помню
как сейчас, как я первый раз стал начальником — бригадиром строительной
бригады по строительству 2х квартирников под ключ в регионе Сибири. Кушать
хотелось так, что чем только не занимался в академии наук. Вступив в должность и с задумчивой
важностью оглядывая голую землю будущей стройплощадки, спросил — ладно, все ясно,
только кто будет шпингалеты на окна ставить и стекла вставлять. Здесь меня и вмочили
на всю оставшуюся жизнь, сказав — слушай парень, может ты чего-то не понял, но теперь
ВСЕ это ТВОИ проблемы. До сих пор лечу с благодарностью.

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

Така овета есть — можна и нужна. Шурупь мозгами быстрее — вся страна кусать осень
хочет — ждать некогда.



Any stone in your boot always migrates against the pressure gradient to exactly the point of most pressure.

Здравствуйте, D.O., Вы писали:

DO>Это возможно делать, не тратя 10 лет на программирование?

http://www.microsoft.com/rus/msdn/msf/default.mspx

Здравствуйте, Denis, Вы писали:

СШ>>Можно даже дать ссылку на весьма серьёзную литературу.
D>ССЫЛКУ-ССЫЛКУ-ССЫЛКУ-ССЫЛКУ-ССЫЛКУ!

"Путь камикадзе", глава "Переговоры", подглава "Переговорные игры".

Этот же результат можно получить из Брукса: на написание требуется 1/6 времени проекта, на тестирование — 1/4. "Мифический человеко-месяц", глава 2, подглава "Системное тестирование".

Здравствуйте, Gollum, Вы писали:

DO>>Это возможно делать, не тратя 10 лет на программирование?
G>http://www.microsoft.com/rus/msdn/msf/default.mspx

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

СШ>"Путь камикадзе", глава "Переговоры", подглава "Переговорные игры".
СШ>Этот же результат можно получить из Брукса: на написание требуется 1/6 времени проекта, на тестирование — 1/4. "Мифический человеко-месяц", глава 2, подглава "Системное тестирование".

спасибо, дома посмотрю!

Здравствуйте, Spidola, Вы писали:

S>P.S. Можно сделать "финт ушами" и скинуть задачу (предварительно слегка её переправив) какой-нибудь другой (а то и нескольким компаниям) и запросить у них стоимость работы и стоимость их человеко-часа (среднего), а потом вычислить количество человеко-часов. Но это опять только прикидки...

да, есть такая тема

конечно, если задача типа "сколько стоит написать контрол (не очень сложный)" — то ее наверное быстро и бесплатно оценят многие.

но вот помедитировать пару недель над ТЗ попутно загружая линию обсуждением его с заказчиком, потом пару недель на поработать над дизайном (естественно все включает оформление проектной документации), пару недель разбить получившееся на подзадачи, поддающиеся уже какой-то реальной оценке с параллельной оценкой рисков по каждой подзадаче + подбить итоги — итого 1,5-2 мес труда закладывающего реальную базу будующего проекта за просто так вряд ли кто согласится. Плюс труд должен быть весьма квалифицированный по понятным причинам.

Серьезные ребята на такие "финты ушами" (длительностью больше примерно человеко-недели на грубую оценку) вряд ли пойдут — заключается сначала контракт на разного рода preliminary project activities, including (rough) estimations. А несерьезные если... ну тут и рез-ты могут оказаться любые.

Сколько таких "финтов ушами" проделали индусы несколько лет назад, завалив наш оффшор вот таким мартышкиным трудом... по идее сейчас уже компании с минимальным опытом доджны серьезнее быть

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

Здравствуйте, Valerio, Вы писали:

V>но вот помедитировать пару недель над ТЗ попутно загружая линию обсуждением его с заказчиком, потом пару недель на поработать над дизайном (естественно все включает оформление проектной документации), пару недель разбить получившееся на подзадачи, поддающиеся уже какой-то реальной оценке с параллельной оценкой рисков по каждой подзадаче + подбить итоги — итого 1,5-2 мес труда закладывающего реальную базу будующего проекта за просто так вряд ли кто согласится. Плюс труд должен быть весьма квалифицированный по понятным причинам.

Если Вам требуется оценка, только на прикидку которой у серьёзной компании уйдёт несколько недель (!), то "финтить ушами" здесь, по крайней мере, неразумно. Бюджет ТАКОЙ задачи ДОЛЖЕН включать квалифицированную.

Кстати, для создания коммерческого предложения с предварительной оценкой нужно не более нескольких дней (даже с проработкой задачи и подготовкой материалов). Мы же говорим о ТКП (технико-коммерческом предложении), а не о ТЗ или даже Requirements...

V>Серьезные ребята на такие "финты ушами" (длительностью больше примерно человеко-недели на грубую оценку) вряд ли пойдут — заключается сначала контракт на разного рода preliminary project activities, including (rough) estimations. А несерьезные если... ну тут и рез-ты могут оказаться любые.

Ну разумеется. "Серьёзные ребята" работают только с "серьёзными ребятами" (это не шутка). Это раньше на любой клич какого-нибудь Газпрома к нему сыпались проработанные коммерческие предложения. Теперь "серьёзные ребята" эту модель бесплатного консультирования засчёт других прочувствовали и без официального оформления тендера или без контракта никто и шагу не сделает.

Здравствуйте, D.O., Вы писали:

DO>Как научиться расчитывать затраты человеко-часов на написание системы с заданными требованиями? Особенно если функции не везде расписаны подробно, и иногда вскрываются непонятные места в задании, не до конца описанные требования.

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



Как ты видишь при состоянии Vision/Scope approved — т.е. уже в принипе понятно что делать в ообщем, но нет детального ТЗ ошенки могут расходится до 2 раз.

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

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

Полученное разбиение кстати называется по научному Work Breakdown Structure. И у методики оценки такой тоже название есть только забыл его — вспоминать лень, да и не нужно т.к. это почти единственная рабочая методика.