Синдром студента

[craz]

Товарищи, никто не встречался с положительными оценками данного проектного феномена?

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

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

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

Короче было бы интересно услышать ваше мнение как практиков.

 

[флоппик]

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

 

[craz]

@флоппик, привет. Ты немного прав. Давайте я конкретизирую. Приходит проект: дистрибуция нового альбома группы "Какая-то там группа" и есть некие требования(я прям вот находу придумал), которые мы формализировали, уточнили - нам надо онлайн продавать альбомы. Проект идет и перешел в стадию исполнения.
Почему в любых источниках борются с "синдромом студента"?
1) мы определили сроки проекта, к примеру 100 дней
2) трудозатраты 2*48=96 часов на исполнение(12 дней)
3) анализ проектирование и т.п. уже "отожрало" 50 дней.
4) остается 50 дней.

50 дней будет потрачено с 90% вероятностью следующим образом: 38 непонятно на что и 12 дней последних или с увеличением срока на исполнение.

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

 

[флоппик]

Я кстати, ожидал, что никто не ответит на твой вопрос.
Во-первых, проблема у тебя в голове: когда ты не можешь описать конкретную проблему одним предложением из простых слов, значит, ты не знаешь в чем проблема, и пытаешься это скрыть за словесной кашей с придуманными терминами. Сформулируй проблему простыми словами в короткой форме, так что бы проблему могла понять твоя мама или дедушка — ты будешь знать какая проблема у тебя на самом деле.
Во-вторых, ответ на тот вопрос, который ты не сумел задать: http://fff.works/done/done-vs-doing/

 

[iceman]

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

имхо, чем больше дашь им ДЕНЕГ, тем качественнее будет проект xD

 

[AmdY]

от денег должно зависеть количество фич, а не качество продукта.

 

[Тугай]

Любая работа занимает все отведенное на нее время. Время - деньги. Давать больше времени, то вскоре захотят больше денег, которых им не дадут и пойдут искать в другом месте.
Кадры решают все.
Есть еще закон Мерфи, по которому количество управленцев всегда растет. Сначала все дольше планируем, потом так долго что и помощник нужен и т.д.

Тут нужен психоаналитик, который тебя убедит, что твоя интуиция верная или неверная

 

[nw]

Выкопаю пост.

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

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

Наверное.