У меня возник такой вопрос: как сегодня обстоит дело с подготовочными мероприятиями к разработке ПП. Другими словами очень ли заморачиваются сейчас планируя сроки, зарплаты, число сотрудников и так далее. Опишите как делается это у вас. Какие проблемы возникают. Можно ли вообще оценить стоимость и сроки разработки нетипового ПП? Какими методами пользуетесь при оценке? Насколько можно предусмотреть неминуемые форсмажоры при разработке...

Хотелось бы узнать Вашу точку зрения на это.   

Заранее спасибо.

По-моему, никаких методов помимо экспертной оценки сдесь применить нельзя...

   Ну вот я знаю в СССР существовали нормативные таблицы (что ИМХО - глупость несусветная), но тогда это было оправданно общей состоянием системы разработки ПП. Процесс программирования от непонимания превратили в конвейер. И в нужный срок разработка заканчивалась (приказали - сделали), что было на выходе мы видим сейчас по нашему месту на международном рынке ПП (или я не прав?). Здесь укладывались в сроки, а как уложится в деньги и качество?
    Надо стараться сделать кофетку и не прогореть. То что экспертная позиция рулит - это факт. Но предусмотреть всего невозможно. Разве эксперт может сказать точные сроки разработки, итоговую стоимость и т. д.? А каждый $ на счету.
    В связи с чем у меня вопрос: как конкретно это выполняется у Вас. Мнение компетентного человека это хорошо. Но рисковать проектом, просто на него полагаясь несерьезно.
    Я понимаю, что предмет разговора очень объемный, поэтому прошу небольшие конкретные примеры с Вашего производства по вышеописанным вопросам.
    batigoal, вот как у тебя планируют новый проект?

Это сообщение отредактировал(а) AlexST - 20.10.2006, 18:40

...причем на всё. И это нередко приводило к очень смешным результатам, но это будет оффтоп 



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


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


Скажу честно - в детали процесса я не посвящен, у нас слишком большая контора. Но, судя по тем огрызкам материалов, которые попадали ко мне в руки, процесс у нас чаще всего выглядит следующим образом:
1) высказывается идея о востребованности на рынке того или иного продукта (например, системы управления контентом для IPTV-операторов)
2) прикидываются потенциальные клиенты, причем с наиболее вероятными из них уже на этой стадии ведутся конкретные переговоры. Рассчитывается необходимое число лицензий для наиболее вероятных клиентов. Так мы получаем планируемые суммы прибыли.
3) принимается решение о разработке продукта с нуля или покупке конторы/решения, которое примерно отвечает нашим нуждам (для последующего переделывания).
4) Рассчитывается величина CAPEX (что это такое - есть тут: http://en.wikipedia.org/wiki/Capital_expenditure). Вот это, собственно, и есть самая трудная часть - нужно определить необходимое количество оборудования, стоимость аренды здания и прочих расходов. Уже на этом этапе нужно представлять себе примерный состав команды разработчиков. Чрезмерное их количество приведет к непомерным усилиям для обеспечения их взаимодействия. В случае нашей предметной области количество участников проекта обычно колеблется в районе 10-15 человек.
Чтобы подсчитать количество людей, на этой стадии уже должен быть детализированный project plan с конкретными заданиями, хотя бы на архитектурном уровне. А для этого нам необходимо наличие конкретных требований к проекту. Как показывает практика, получить их с первой попытки довольно сложно, если у вас еще нет определенного заказчика. Поэтому чаще всего на первой стадии делается пилотный проект, для внутреннего пользования. Затем его показывают потенциальноу покупателю и спрашивают: "Что еще вы бы хотели видеть в этом продукте?" И только тогда начинается написание полноценного решения, с секьюрити-заморочками, решением проблем производительности и т.д. Или не начинается, если у клиентов нет интереса.

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


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

Сразу оговорюсь - я не специалист в этом вопросе и все что я скажу, было почерпнуто в институтском курсе управления проектами. 
Основные методы оценки времени и стоимости:
1. экспертная оценка - особое внимание здесь уделяется методу Дельфи - собирается несколько экспертов (каждый эксперт знает, что он не единственный, но кто именно кроме него есть он не знает), они дают свои оценки + их мотивации (т.е. факты, с помощью которых они получили именно эти значения), после чего каждый эксперт получает данные, выработанные другими экспертами), он изучает эти мотивации и делает новую оценку с новой мотивацией. Это повторяется до тех пор, пока не выработается какая-то более-менее одинаковая оценка у всех эксертов.
2. нормативы - те самые таблицы, в которых написано сколько на что нужно денег и врремени
3. опыт менеджера и команды проекта - оценки получаются на основе ранее реализованных проектов
4. коммерческие базы данных - аналогично предыдущему пункту, но используется не только свой опыт, но и чужой.

Вроде бы так.

 Нее ну какой это офф! Очень интересно и в тему, как раз про одну из не самых удачных систем подготовки. ПЛИЗ расскажи!

вот тут у меня возникает вопрос: как можно непонимать, что затем фирма получит некий имидж "быстряка тяп-ляпщика" и даже короткие сроки не помогут продать её кривые (ну может даже в первой версии только) ПП? Это прямой удар по качеству продукции.

А насколько оправданн такой лёгкий подход? Неужели нет желания всё перепроверить и убедится в надёжности расчётов?

Вот тут неясно. Если при разработке возникла "долгоиграющая проблема", где будете брать деньги на её решение?

Кстати. Психологи рекумендуют не более 7 человек в группе.   

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

У нас по-моему сейчас действует ФАП РФ? Но мне кажется что там ничего ценного нет. Я прав? Хорошие разработки разглашать и продавать не будут. Самим нужны.

Насколько хорошо брать чужой ПП, модуль, алгоритм? Пока его переделываешь столько времени проходит, за которое можно взять и свое написать. Ведь надо где-то брать уверенность в чужом коде как в своем, а кто её даст? Иначе хорошей проги не получится.

Добавлено @ 22:03 
batigoal, спасип за рассказ. Хотелось бы побольше таких прочесть.   
Тогда и тема раскроется.

Это сообщение отредактировал(а) AlexST - 22.10.2006, 22:14

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


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


Если разработчики опытны, то это работает. А за крупными проектами, как правило, присматривают серьезные гуру (хотя бы в качестве консультантов или high-level архитекторов).


Для этого в плане проекта предусматривается пункт "Возможные риски". Как правило, это проблемы thirdparty-контор. Например, мы изначально закладываем риск неполучения ТВ-приставок (Set-top boxes) в срок, и информируем об этом заказчика.


Я имел в виду вообще всех людей, занятых на проекте. Т.е. это, в том числе, и менеджерская сторона. Я, например, напрямую плотно работаю с тремя разработчиками, двумя тестерами, тимлидом и менеджером проекта. Общение с архитекторами и остальными участниками носит эпизодический характер.

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


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


По идее, там содержатся не разработки, а данные отчетов, сформированных в ходе и после выполнения проектов...

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

В любом случае, составляя график проекта, вам придётся оценивать длительность выполнения этапов. И для того, чтобы Ваш проект не выбился из графика, вам нужно знать, ЧТО вы хотите получить и КАКИМ ПУТЕМ в к этому пойдёте!

имхо.   

Если интересно, то эту книгу о советском планировании я брал вот отсюда: http://antisoviet.imwerden.de/#samizdat
Игорь Ефимов - "Без буржуев" (Франкфурт-на-Майне, 1979)

P.S. Книга, я имел в виду об общем планировании, а не о ПО

Это сообщение отредактировал(а) batigoal - 24.10.2006, 21:28

Bikutoru, нормирование - частный случай стандартизации.

Конечно ДА   . Говоря о разработке ПП в первую очередь имеется в виду разработка его кода. Причем тут среда, платформа и т. д.? Алгоритм, программные средства реализации (я имею в виду технологии) и т. д. - это проблема. Ведь я уже сказал, "что если он реализует какую-то идею, революционно отличающуюся от всех остальных". Воть.   

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


Ясно. Значит если эксперта нет - то только кучей денег. В принципе я так и думал. Спасибо.


Это сообщение отредактировал(а) AlexST - 26.10.2006, 10:45