LINUX.ORG.RU

Срок выполнения проекта

 ,


0

1

Всем привет!

Возможно ли достоверно рассчитать срок разработки программного продукта? Особенно, если частично состоит из ресерча =(

Если нет, то хотя бы приблизиться к реальности как-то можно? Требуют точных данных, а через сетевое планирование не вложились

Если нет, то хотя бы приблизиться к реальности как-то можно?

Да, основываясь на опыте.

Если что-то совсем новое, и требует «ресерча», то после релизации части новых возможностей. Т.е. взять неделю на «ресёрч», потом посчитать.

vvn_black ★★★★★ ()

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

Обычно это не спасает, так как заказчик все равно будет голосить, что это чет долго, давай завтра.

Zhbert ★★★★★ ()
Ответ на: комментарий от vvn_black

Если что-то совсем новое, и требует «ресерча», то после релизации части новых возможностей. Т.е. взять неделю на «ресёрч», потом посчитать.

Там ситуация такая, 30% проекта завязано на блокчейне, работы по которому всегда в ресерче. И сроки прям совсем не известны.

Остальной проект на расте, гоу и яве. Что тоже добавляет.

И любой срок оказывается вперде. А меня уже третий месяц чпокают за это

AntonyRF ★★★ ()
Ответ на: комментарий от Zhbert

Обычно это не спасает, так как заказчик все равно будет голосить, что это чет долго, давай завтра.

Ну да и примеры со строителями мол если к тебе придут строители и скажут что хз сколько стоит и сколько будем делать, ты же на хер пошлёшь этих строителей.

AntonyRF ★★★ ()
Ответ на: комментарий от AntonyRF

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

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

Nervous ★★★★ ()
Ответ на: комментарий от AntonyRF

Там ситуация такая

Вот, уже хорошо, есть некая декомпозиция.

на расте, гоу и яве

Это же разные исполнители, пусть каждый считает estimate на свои задачи. Оценку каждого исполнителя умножать на 1.5.

Т.е. точных сроков всё-равно не будет, а получится некий таймлайн, где будут лакуны блокчейна и посчитанные отрезки для кодинга.

vvn_black ★★★★★ ()
Ответ на: комментарий от Nervous

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

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

AntonyRF ★★★ ()

приблизиться к реальности как-то можно?

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

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

запой рационален и в целом не рекомендуется.

anonymous ()
Ответ на: комментарий от anonymous

Ну с разработкой, окей. Допустим что-то можно представить.

А что с тестированием? Как представить производительность труда при юнит/интеграционном/ручном тестировании? Как предсказать сроки по закрытию багов?

AntonyRF ★★★ ()

через сетевое планирование не вложились

ну если знаешь слова «сетевое планирование» — методы оценки знаешь. следующий уровень — правильная декомпозиция. на последнем уровне сможешь завалить ПМа.

vedowi6419 ()
Последнее исправление: vedowi6419 (всего исправлений: 1)

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

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

pinus_nigra ()

ресерч

Всё, можешь вешаться. Предсказать не удастся.

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

Result-Code ()

Ну вообще все просто - берёшь сумму денег за проект и делишь на три (зарплата, накладные, прибыль), зарплатную треть делишь на стоимость человеко-часа.
Т.е. если у тебя заказ на 300 тыщей и прогеры в среднем получают по тыще в час, то твой проект не должен делаться дольше ста часов, если его делают 2 человека, то они должны сделать его за 50 часов или 50/8 = 6 с копейками рабочих дня по 8 часов. В противном случае - прибыль будет ниже запланированной. При выполнении проекта за 9-10 дней он будет иметь околонулевой профит (накладные обычно растут при задержках), при бОльшем времени - убыточен.

rukez ★★ ()
Ответ на: комментарий от AntonyRF

Я, как яростный ненавистник аджайла, в упор не вижу как можно вести R&D иначе. Зависит от того, что ты конкретно разрабатывашь, конечно, но, наверняка, можно собрать требования, спроектировать архитектуру и заложиться с запасом на основные фичи. Только в целом хрен ты подгадаешь всё равно, либо оценка будет такая, с которой никогла не согласятся, либо все сроки будут продолбаны, либо половина фич будет выброшена / отложена до лучших времён, либо технического долга накопится на дважды по столько, сколько ты на изначальную разработку потратишь.

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

В каком направлении разработка-то хоть?

WitcherGeralt ★★ ()

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от vvn_black

Т.е. взять неделю на «ресёрч»

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от AntonyRF

Блокчейн это не ресёрч. Ресёрч это когда блокчейн придумали. Проверяется наличие ресёрча в случае если ты совсем не в теме просто - есть ли кроме программистов в проекте яйцеголовые или нету.

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от vedowi6419

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 2)

Если нет, то хотя бы приблизиться к реальности как-то можно?

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

ya-betmen ★★★★★ ()
Ответ на: комментарий от peregrine

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

WitcherGeralt ★★ ()

Если поставленная задача содержит ресёрчи, которые кто-то пытается ужать в фиксированные временные рамки, то такие ресёрчи подразумевают ровно два возможных исхода - PASS с каким-либо полезным результатом, который успели получить вовремя, и FAIL, когда отведённое время просто профукано и никакого полезного результата в отведённое время не получено.
Если ПМ готов взять на себя риск такого FAIL, тогда может фиксировать время.

blexey ★★★★★ ()
Ответ на: комментарий от peregrine

Блокчейн это не ресёрч. Ресёрч это когда блокчейн придумали.

Ну в любом случае, есть вещи без аналогов, сколько их пилить ни кто не знает. И как это пилить тоже практики нет.

AntonyRF ★★★ ()
Ответ на: комментарий от ya-betmen

А если серьезно, когда следующий дедлайн?

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

AntonyRF ★★★ ()
Ответ на: комментарий от WitcherGeralt

Сбор и анализ данных — ресёрч.

Да у нас механизм роботы с БЧ, для которого много гуглежа и экспериментов уходит перед построением какой-то работающей модели. Притом за все время 4 подхода сменили

AntonyRF ★★★ ()

Можно границу сверху определить, при наличии определённого уровня компетенции. Точное время - это фантастика, либо что-то супертиповое и короткое типа лендинга. Обычно всем проще такие вещи делать за times and materials. Хотя календарные сроки всё равно нужны, хотя бы с погрешностью.

pon4ik ★★★★★ ()