Как считать творческих программистов?

[mr.Karapuz]

Вдруг есть новый свежий взгляд.

Без оценки трудоёмкости сложно адекватно планировать. Точнее говоря - не сложно,... "но такой бред получается" ©

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

Читать "Как пасти котов" не предлагать.

[pumpkin]

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

[mr.Karapuz]

Спасибо!

Декомпозиция = трудоёмкость подготовки, "неповоротливость" ТЗ, но предсказуемость.

Думал на тему классификатора, для простоты "взвешивания" запросов, но... даже так получается не достаточно точно.

[axel]

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

[mr.Karapuz]

Потеря доверия заказчика - т.к. задачи могут растягиваться во времени. Нет конечной стоимости.
Потеря доверия исполнителя - т.к. объем доработок и изменений будет бесконечным. Нет конечного срока.

[axel]

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

[Lex]

Бляяя

[egold]

Если досконально не представляешь себе предметную область - то никак.

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

[WPanda]

многостратегический многоаккаунтный торговый бот на американскую фонду

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

[Lex]

Как сталин
Промотивируешь
А как иначе с ними?

[egold]

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

[WPanda]

Сдавать заказчику одинаково тяжело и то, и другое.

[Бабай]

Что-то превознесли эту категорию в разряд богов. Десяток лет назад забросил IT сферу, так как никто нормально платить не хотел. Сейчас просто удивляюсь как за элементарщину башляют кучу бабок. Ну и превозносят их те, кто сами не в зуб ногой в этой области. Такие и сидят в верхах всего. Пусть платят. Без лоха и жизнь плоха.

[egold]

Это да.

[pumpkin]

Декомпозиция = трудоёмкость подготовки,

ну тут как бы это... ты либо платишь сначала, либо потом Любое планирование занимает время. Декомпозиция - считай хотя бы примерное понимание объёма работ, какой специализации и сколько народу тут нужно. Иначе выглядит так, что ты вообще без планирования хочешь получить оценки Когда ко мне с таким приходят - я сразу говорю, либо хотя бы пару недель на декомпозицию и понимание очень примерных трудоёмкостей (но даже не сроков на данный момент, ибо трудоёмкости != сроки), либо полгода и +/- полгода, как пойдёт

К сожалению, в нормальных проектах/продуктах почти не бывает "мы это уже делали, знаем сколько это стоит". Особенно с учётом всякого легаси и желания поверх этого прикрутит современные технологии, которые ещё толком никто не пробовал... Иногда даже такие вроде понятные вещи, типа "как поменять БД в проекте" на практике сталкиваются с такими чудесами...

[pumpkin]

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

[Telepuz]

А потому что все забросили и работать некому :-)

[javdet]

>как оценить гипотетическую трудоёмкость разработки?

Хз как.

Вот я начинаю единолично пет-проект. Стадия подготовки, сбор данных, формирование первой версии ТЗ, прикидка чего хочу в итоге и ПРИМЕРНОЕ представление как реализовывать буду, возможно даже MVP. На основании всех этих вводных я оцениваю сроки и трудоёмкость как - "ну, вроде не сложно, захерачу за недельку, неспешно". На практике - начинается такой $#@$%ный цирк на стадии реализации - что волос в интимных местах просто не остаётся. И это я сам себе менеджмент - нет интереса самому себе наврать про сроки и прочее. Плюс я даже близко не шапкозакидатель и стараюсь трезво подходить к реальности.

Как ты думаешь, по какому сценарию реализуется следующий пет-проект? Ну, с учётом опыта реализации предыдущего? Да точно также как и первый - ПОЛНЫЙ объе@бос по срокам и трудоёмкости. Вот прям полный, вот прям ваще.

Каждый раз в шоке.

[akm]

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

[mr.Karapuz]

Реально, спасибо, что обратили своё внимание на вопрос. Не оставили одного. Видно, что из предметной области, со своим опытом.

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

Полез читать про управление в условиях неопределённости. Пока нашел про: "белый", "серый" и "черный" анализ.

"Белый" - всё определено = одно правильное решение.
"Серый" - частично определено = набор неоптимальных решений.
"Черный" - неопределённость = нет решения.

Планирование в разработке, в большинстве своём, "серый" анализ.