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

Тогда ружно доносить до тех кто выделяет деньги мысль о том, что новые задачи == новые сроки. Срам попробуй - договоритесь какую минимальную функциональность можно выкатить, отшлифуйте, пусть будет бурбулятор бесполезный, но главное в проде. А дальше уже по одной фиче каждую неделю. Как то так оно в идеале должно работать.

Ну получается бабки за риск, который обязательно выстрелит.

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

2. Смотреть на производную. Поработали 1-2 недели, оценили сколько сделали и сколько осталось, рассчитали время как в диалоге копирования файлов. Обновили оценку для заказчика.

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

Ох, ну итог такой:

1. За все непонятные фичи требующие экспериментов - сроки говорить когда эксперименты будут закончены.

2. Все понятные вещи разбить на сроки.

3. Добавлять по одной фиче в неделю. Постоянно шлифуя.

4. Проставить майлстоуны.

Хорошо

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

Нет же, за умение договориться на разумное соотношение риска, итогового ценника и рисковых обязательств.

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

джва часа: гит клон, нпм старт или что там, свое говно не пахнет, мы сделаем луче?

таков путь.

Эй. Указывай первоисточник :-) © МандаЛОРец.

я на три умножал

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

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

Ну это идеал.

Особенно, если частично состоит из ресерча =(

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

Владимир

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

И какая цена за FAIL

Смотря на кого работаешь. А то и в лесу закопать могут...

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

Это все левые примеры. «Строители», «автозавод», «СТО» — ни один из этих примеров не катит для разработки софта и является «далекой аналогией». Особенно не канают эти аналогии с переходом от водопада к «аджайлу». Фактически ни строителям, ни работягам на заводе, ни тем более на СТО нихрена не приходится «разрабатывать». У них там типовые проекты, которые придумал умный дядя архитетор/промдизайнер, типовые материалы и узлы, типовые крепежи и т.д. благодаря стандартизации (то самое с чего удивляются долбодятлы на ютубе как «удивительно» подходят размеры многих предметов) Да еще и операции все нормированы заранее. И тем более не рядовые строители составляют сметы и т.д. Только смета один хер вырастает в процессе, особенно с постановкой задачи типа «разгрузить машину», о которой в процессе выясняется что это «камаз песка... под водой» :) Но те кто используют такие вот аналогии с реальными материальными производствами занимаются банальной «манипуляцией». Можешь смело плевать им в наглое литсо.

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

Предполагаемый бюджет сразу умножай на 2.71.

Прошареный манагер/заказчик будет просто делить на три все твои оценки :) Вот методикой PERT можно манипулировать в духе «шляпа здесь, но ты ее хер найдешь» :)

Да понятно, что манипуляция. Просто это уже не разработка, а какая-то политика.

Да понятно, что манипуляция. Просто это уже не разработка, а какая-то политика.

А как бы все «внешние сношения» все состоят из. Именно поэтому «when its done» и водопад в разработке софта заменили на «аджайл-практики» и «программные продукты», а «сырые альфы» сначала на «пруфы концепта», а потом на «MVP» (потому что «POC» — это даже звучит неприлично «поц») — эти подмены понятий в общем полные аналоги «кефирных продуктов» вместо кефира и «800 грамм за ту же цену» вместо полновесного килограмма.

Подари им книжку «Асимптотический анализ».
Спасибо не скажут, но призадумаются.Нет.

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

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

Как предсказать сроки по закрытию багов?

Аналогично.

Все, что не успели - в следующий спринт.

ага который не может куки в браузере почистить

Так и делал, но как бэ

не будь крайним.

ответственность за сроки должна лежать на исполнителе. сказал «я угадаю эту мелодию с трех нот»? угадывай.

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

контролировать процесс нужно ежедневно.

• что сделал
• что планируешь делать
• не мешают ли какие нибудь там яйца танцевать свою партию

твоя задача не давать процессу залипать. как только исполнителю нечего показать и не о чем рассказать - процесс залип.

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

выкатить полноценное решение займет овердофига времени? выкатываем прототип. прототип дорого? пишем мок. короче результат нужен тот, который ближе, проще, дешевле.

остальное суета и томление духа.

Спасибо большое

Тому который умеет «есть людей», это все не нужно :)

Можно только примерно при:

1. наличии известной тебе команды, знакомой с техническими инструментами и скиллами, которые тебе известны (кто на что способен в деле, а не на словах);

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

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

Рядовые молодые нифига не знают, что и как делать. Максимум, можно рассчитывать, что капитаны неплохо разбираются в конкретном ЯП и ОС, но не обязательно в нужных фреймворке, библиотеках, протоколах. А джунов надо еще доучивать в процессе, писать им инструкции детальные, как что делать, чтобы от них вообще была какая-то польза.

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

Один мой знакомый столяр сказал заказчикам: я делаю долго, плохо и дорого. Найдите себе того, кто делает хорошо, быстро и дёшево.

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

Имей план Б, что ты ещё можешь выкинуть

Выкинуть работу? =)

Это уже план В