Доброго времени суток. Снова сорвал срок выполнения задачи, причем сам же себе их и устанавливаю, опять пришлось сдвинуть и изменить график. Моя формула: T + 0,2Т(поиск рационального решения) + 0,3Т(время на тестирование) + 0,4 (консультирование юзверей во время внедрения) + 0
,01Т(поковыряться в носу), где Т - время чистого кодинга. Несколько статей уже прочел на данную тему. Итак, рассуждения и предложения в студию.

(23) почитай тайм-менеджмент Архангельского. Стивен Кови хорош.

(24) это по C++ он писал?

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

(25) нет)) как управлять временем и личную эффективность)

(0) Вопрос, вы хоть раз в последнее время заканчивали работу намного раньше чем плановая дата? А намного позже?

Т * П, где П = 3,1416925

(27) скачал, благодарствую за вектор

(24) Он для управленцев хорош. 1С-ку не поможет. ИМХО. Хотя хз подробно не изучал.
(29) Если Пи то вроде не верно.

(31) подвела память :-) правильно 3,1415926

(32) Почему бросилось потмоу что в школе нас научили считалке)-  Три четырнадцать пятнадцать девяносто два и 6

(0) Кодинг это весьма второстепенная задача. Считать общее время от времени на кодинг неверно. Самые трудозатратные этапы это:
1) Внедрение.
2) Написание ТЗ.

(0) Никогда не любил такие вот "точные сроки выполнения". Мое мнение - никогда ты его не просчитаешь адекватно.

Скажешь слишком мало - 100% в процессе исполнения вылезут какие-нибудь нюансы, которые потребуют дополнительных временных затрат. Следовательно ты либо срываешь сроки (дабы сделать все как надо), либо забиваешь на это и вкладываешься в срок (заведомо отдавая поделку с косяками).

А скажешь слишком много (с запасом) - сразу косые взгляды - фууу, вон тот обещает в 3 раза быстрее.

В связи с этим стараюсь точных сроков не давать ну или по крайней мере значительно округляю в большую сторону (например, прикинув, что займет 3 часа работы - говорю "в течении дня". Если по прикидкам выходит 5-7 часов - говорю "два-три дня").

Мое ИМХО лучше выставить большее время и уложиться быстрее, чем установить короткие сроки,а потом гнать в шею и все-равно не уложиться.

(34) Вчера с фиксероми общался он даже не понимает термина внедрение)... это говорит вы франчи все выдумали... (близко к тексту. Прикольно.  
Вообещм основное время пожиратель для меня на проекте это обумывание способа решения. вертишь и так и эдак и этом может быть вечно... Иногда надо остановится и начать делать)

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

Считается, что чем лучше разработчик, тем больше он думает и меньше кодирует.

Оценка задач это настолько обширная тема, включающая теорию вероятности, управление неопределенностью, управление историческими данными, управление рисками итп, что даже книги мало прочитать, чтоб начать ее понимать. (Рекомендую почитать Макконнелла "Сколько стоит программный проект")

(36) отчасти верно говорит. Порой можно днями и неделями рассуждать об оптимальности, методах, подходах, вдаваться во всякие тяжкие и так далее...но так и не написав и строчки кода.

Порой нужно просто остановить этот поток мыслей и просто НАЧАТЬ! А уже в ходе работы многие вещи сами встанут на нужный путь.

(35) это говорит только о не умен и планировать.и, вообще-то, никто не отменял правило - задача занимает все выделенное время + "еще чуть чуть" (36) точно подмечено - начать делать)

(33) Эти знаки я помню прекрасно
пи многие знаки мне лишни, напрасны
:-))

кстати, самая низкая достоверность оценки у "Экспертной оценки", самая высокая у комбинации нескольких, основанных на подсчете и исторических данных текущего проекта

(38) у меня план расписан на две недели вперед, как я могу делать задачу сразу, м...?

(37) благодарю, скачиваю

(35) Это основной минус 1С-ков, разработка софта по заказ в сжатые сроки под клиента).  
Сравните с любым нормальным программером - пишет в команде на окладе приложение которое потом запускают в тираж. Никто никогда сроки не ставит четкие, никто не парится по баблу (оклад) - те. не ставит человека в стрессовую ситуацию. Причем как известно стресс противоречит умственной деятельности, стресс требует быстрых решений и простых типа бежать/прятаться. Думать поздно.
Я вот давно сделал выводы)... и принял решения по работе в сфере 1С. И знаете все гораздо лучше получается)

(42) Это уже совершенно другой вопрос.

Можно по опыту угадывать, но 100% результата не будет никогда, ИМХО. Очень много факторов.

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

Есть положительные. Поменялась логика работы небольшого участка, пришлось организовывать новое хранение данных ,обработки по работе с ним, менять логику отчетов. Отвели две недели на это, но оказалось, что раньше я достаточно удачно все организовал и готово было через 3 дня.

(44) "Сравните с любым нормальным программером - пишет в команде на окладе приложение которое потом запускают в тираж. Никто никогда сроки не ставит четкие, никто не парится по баблу (оклад) - те. не ставит человека в стрессовую ситуацию"

_ да что ты говоришь! Знаю многих web-щиков, Делфистов, Разрабов мобильных приложений - во многом ситуация аналогичная. И дело тут не в проге, а в менеджере (топ-менеджере), который заключает контракт с клиентом (ну если утрированно).

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

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

(49) Не ну вопрос в условиях... просто конечнику надо обычно сжатые сроки и сжатые суммы...

Есть у меня дружбан, он всегда делает так:
1). Оцениваешь проблему. Допустим, оценил в 5 часов.
2). Умножаешь полученную цифру тупо на 2, но лучше на 3. Получаем 15 часов.
3). Сообщаешь клиенту.
4.1). Если клиент отказывается, то это не твой клиент (нищеброд).
4.2). Если клиент соглашается, выполняешь задание.
5.1). Если сделал за 15 часов - клиент доволен.
5.2). Если сделал за 5 часов - клиент просто счастлив.
6). Профит.

(0) что тебе могут посоветовать бездельники которые вместо работы весь день на мисте флудят.

статьи по теме:

Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения http://habrahabr.ru/post/75903/

Откуда возникают ошибки в оценке сроков программных проектов (по мотивам собственного опыта)?   http://habrahabr.ru/company/intel/blog/100290/

Почему 9 женщин не могут родить ребёнка за 1 месяц или О применении имитационного моделирования в управлении проектами   http://habrahabr.ru/post/83621/

5 самых распространенных ошибок менеджеров   http://habrahabr.ru/post/92082/


Как бороться с человеческим фактором при внедрении ПО? http://habrahabr.ru/post/77581/

Учёт рисков при оценке трудоёмкости ПО и планировании проекта    http://habrahabr.ru/post/77958/

Что делать, чтобы проекты не занимали в 2-3 раза дольше, чем планируется? Часть 2    http://habrahabr.ru/post/137839/

Использование статистических инструментов в планировании  
http://www.slideshare.net/Cartmendum/hitting-moving-target  и  http://www.slideshare.net/Cartmendum/back-to-the-future-3344717

(53) О сколько изысканиий.... и все бестолку). Хорошо работать на Мискрософт, потмоу что на огромный тираж). Всё окупается и сроки и программисты со своими тараканами)

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

(0) Как то очень смело. Чистый кодинг, обычно занимает не более 20% от проекта. Т.е. для оценки времени нужно время кодинга умножать на 5 или более. Это уж очень приблизительно.
Тестирование, не отладка, может занимать столько же времени или больше.

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

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

ИМХО, для того, чтобы более менее точно распланировать свое время, нужны достоверные нормативы. Нормативы всегда субъективны. Т.е. нужно знать, сколько именно ТЫ можешь потратить времени на решение конкретного типа задачи. При планировании широкой задачи необходимо детализированное разузлование на подзадачи, для которых имеется норматив. Тем самым могут вылезти те нюансы, которые ты с первого взгляда не заметил.
Важно фиксировать большинство из того, что ты делаешь по плану и вне плана.
Тем самым будешь корректировать свои нормативы и закладывать в дальнейшие планы дельту на внеплановые хотелки.
Ну и не забывать про гигиену труда ;) и погрешность на "тупизм" ))

Сама пользуюсь именно этим методом)

просто расчетное время * 2.

(60) В переводе на русский: время с потолка *2 = время с потолка.  (для новой задачи, ранее не делавшейся)

(57) все зависит от менеджера проекта. Продуктовая разработка обычно сложнее проектной и требует больше знаний, опыта, сил. Если сравнивать проектную работу франча и продуктовую майкрософта, то есессно кажется, что разработать продукт намного проще, но на самом деле все дело в технологиях, опыте и людях, что стоят над кодерами: тимлиды, техлиды, МП, линейные менеджеры итп


>>А под заказ, - ты не вписался в бюджет и все проект умер

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

(61) не так. Есть общая задача. В ней присутствуют как "однозначно понятные моменты" так и моменты с которыми ранее не приходилось сталкиваться. Значт - бьем общую задачу на подзадачи. Каждую "понятную" подзадачу оцениваем и оцененное время умножаем на 2 (3), а на каждую "не понятную" закладываем "время с потолка", которео зависит от собственных сил (уверенности).

(51) Т.е он не только время свое оценивает но и сумму для клиента?  Забавно. С одной стороны люди рискуют с другой даже не пытаются играть по правилам рынка в свою пользу.

(6) +1 (только сначала на два умножить нужно)

+(64) И сразу клиент плох). Нищеброд... смешно. Человеку не рентабельно делать данную работу и все. Надо предложить готовые варианты и все ли так и объяснить ваши изыскания вам не по карману - вам типовое отраслевое решение.
Все 1С-ки нищеброды потому что не могут заказать индивидуальный проект машины под себя, а сплошь катаются на тиражных типовых машинах)))

(62)(57) понравилась фраза из

http://habrahabr.ru/post/75903/

2. Говорить «Да» тогда, когда вы, на самом деле, подразумеваете «Нет»

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

Вот о чем я и говорил. Обычно с клиентами разговаривают\договариваются именно менеджеры, а потом уже начинают "натягивать" итоговое решение на разрабов.

+(66) Ну да я согласен некоторые отчетики дописывают ))) в сервисах типа шумки, или музыки), кресло там поменяют или еще что)))

(0) поиск рационального решения не зависит от времени кодинга.

(67) Гы гы, ты прочел, но не так понял... Это как раз пробелма ФРИ. Делов том что пошли договариваться разработчиков и их тоже уболтают)...

Время умножаю на 2 минимум.

Так же расчет дней произвожу по форумуле, что в день не более 2 часов.
Таким образом разработка на 20 часов будет выполняться месяц.

+(70) Как раз таки в подобных переговорах должны участвовать оба или менеджер в теме.

+(70) Проблема менеджеров заказчика в том что они не понимают правильно цели при подобной задаче. Уболтать на сроки и суммы меньше необходимых - гарантированно провалить проект!))) К несчастью это не переговоры о поставкой готовой продукции...

+(73) Потомоу что никто и никогда не будет работать бесплатно...даже если их уговорить - вытянуть согласие).

+(74) Почему с торгашами и трудно говорить о работе... Потому что они по инерции переносят свой опыт на другую сферу...

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

Но это если брать достаточно крупные фирмы.

Если и манагер и разработчик это одно лицо (как наш ТС), то тут ситуация другая.

+(74) И так то ошибка высоко вероятно, а когда еще такие "помошники" помогают... то вообещ амба.

(76) Непонятно что могут обсуждать манагеры.... не зная темы.

(78) Прикольный у тебя монолог. Интересно, а если вообще все замолчат - ты сможешь самостоятельно продолжать и развивать тему?

+(78) Хотя если это внедрения типовых решений то тут более менее все ясно.

(79) Не понравилось? Не читай)

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

(81) Может тебе бложик завести ?! :)

Начни сначала... Должно быть как-то так.

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

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

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

4. Поддержка на начальном этапе. Здесь есть "волшебная палочка", которая тебя спасет. Называется она "ИНСТРУКЦИЯ".  Чем понятнее инструкция, тем у тебя на поддержке меньше вопросов.

Как-то так.

(0) Дак на мисте поди сидишь, включи в формулу +Миста 0,5Т.

И зачем сроки на фикси? всмысле я тоже на фикси, спрашивают когда сделаешь - прикидываю в пределах дней а не часов

(0) Время тестирования это как минимум 2Т.
А вот что имелось ввиду под поиском рационального решения не понял. Если это алгоритм решения задачи, то как ты сначала определил Т, не имея способа решения этой задвчи?

+(86) ошибся с голосованием

Не, надо не так
(T(Время кодинга)+0.2T(На всякий случай)+0.5...1Т(тестирование и отладка, в зависимости от сложности))*К
где К - коэффициент геморройности > 1

(82) В чем я заблуждаюсь? В том что это дурдом договариваться о сроках не зная темы?
(83) Может тебе модератором стать?

+84 Раз ты снова сорвал сроки, скорей всего проблема у тебя с первыми двумя пунктами... Да, и забуть про "01Т(поковыряться в носу)". Представь, что ты должен выставить счет за проделанную работу. Ты так и напишешь "ковыряние в носу"? Согласись, несерьезно?

+90 Упс. "и забуть" -> "и забудь".

+(89) Я никогда один не разговариваю с клиентами если не знаю темы.

а я считаю, что прибавлять 0,5Т и т.п. это самообман. надо считать коэффициентами, типа как при расчете страховки.
т.е.

T * 1,2Т(поиск рационального решения) * 1,3Т(время на тестирование) + 1,4 (курнуть) * 0,5Т(а то дорого)

на 3 умножаю свою перв. оценку
если не успеваю, то работаю ночами

Вот не понимаю, как вообще можно ТЗ написать подробное.
Я когда свои нетленки писал получалось примерно так:
1.Пишешь сразу код
2.Забиваешь реальные данные и смотришь отчеты
3.Понимаешь что нифига не оптимально написал и 50% кода переписываешь заново

(76) Вот это вот самый жесткий вариант, когда манагеры договорились о сроках, а программистам надо в эти сроки уложиться.

(94) Никогда не работаю ночами... на мой взгляд - потеря времени. Но возможно это мои особенности.

(95) Представь, что ты строитель... И строишь не какой-нибудь сарай, а элитный многоэтажный дом.

(95) Тут баланс нужен.

(95) А ты словами не пробовал сформулировать, то что накодить планируешь?

(89) модератором твоего бложика? А платить сколько будешь? :)

+(98)
http://www.xakep.ru/post/12860/

(97)мужик сказал, мужик должен сделать

(84) спасибо за дельный ответ

(95) уволить нельзя оставить.

(0) Читал вроде у Макконелла, что кодинг занимает чуть ли не 20% времени разработки. И это именно разработки, без тестирования и т.п.

Мой вариант расчета - от балды, основываясь на опыте и личных ощущениях))

+(106) часто идет просрочка, т.к. сам затягиваю, работаю не спеша)

(103) это два разных мужика

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

1)нет вопросов с которыми ты не разобрался прежде чем приступить к оценки, в крайнем случае можно взять тайм аут почитать посмотреть поспрашивать.
2)разбиваешь конкретную задачи на множество подзадач (по факту готовишь тз)
3) в этом же тз прописываешь этапы выполнения в каждом этапе у меня заложено время по принципу
a)2t(точно знаю где что и как писать делал такое много раз)
b)4t( точно знаю что где писать не делал не разу)
с)8t(знаю где писать не точно что писать не точно но знаю где все можно узнать)
d)если не одно условие не подходит возвращаемся к 1)
где т это время кодинга в его чисто субъективном проявлении(сильно зависит от самооценки) и самое главное чтоб не остаться в накладе то время которое ты потратил в начале на подготовку тз тоже сплюснуть в чек (заказчик поймет по факту ты уже работал над его задачей без всякой гарантии с его стороны)

(109) грозит тем, что неправильно планирую; выше рынка

(98)эх если бы со стройкой так было можно. А пока у меня стройка стоит, во многом по этим же причинам
(100)не получается. Тут и заказчик до конца не понимает что ему надо и ты пока не попробуешь влезть в шкуру пользователя не все видишь. Речь идет о нетленках с "0", где какой-то основы совсем нет. Дорабатывать типовые в этом плане проще

Просто Кодинг T. Плюс время на превращение этого "кода" в продукт (тестирование, доработки) - 3*Т. Плюс время на внедрение - 9*T.

(113) в итоге у тебя время кодинга 1/13 от общего времени без предварительного обследования...хм

Рассуждения и предложения не программиста (безотносительно к конкретному случаю):
нужно понимать, что когда работник не укладывается в срок, фактически нарушая условия договора, пусть и устного - он подводит не только себя ("слово пацана", "мужик сказал..." и т.д.), но и всю команду. Возможно некоторым людям наплевать, что их считают балаболами, да и фиг бы с ними, если они работают одни, в противном случае - репутация проецируется на всю группу разработки, отдел, департамент, менеджера, фирму и т.д.. И нужно понимать, что на вашем куске кода, который вы сами пообещали сдать к определенной дате, дело не заканчивается, окружающие планируют свою деятельность (релизы, командировки, бюджеты, следующие задачи и т.д.), т.е. вы крадете чужие ресурсы.
Но еще большее зло чем нарушить самим собой установленный срок, это сообщить об этом непосредственно в момент истечения срока!  В жизни все бывает, можно ошибиться в планировании, можно встретиться с непредсказуемыми сложностями, но замалчивать проблему до последнего и не давать шанса партнерам перепланировать -  свинство.   Рекомендую почитать "черную книгу менеджера", жестковато но по данной теме хорошо написано.
P.S. 2 AlexITGround  вышенаписанное не в укор персонально Вам, то что Вы озадачились данным вопросом уже большой плюс, работайте над ошибками и все придет с опытом, удивляют некоторые комментарии, люди кто ж вам деньги то платит с таким наплевательским отношением?

(0) Используй экспертную оценку.
1) Если есть более крутые товарищи -- спроси у них (важно, чтобы у нескольких), посчитай среднее, сделай поправку на свое "нубство" и на "тупизм" Заказчика.
2) Сделай работу. Попробуй определить: какого рода она была. Запиши, сколько времени потратил. Когда будешь брать заказ, посмотри: была ли у тебя уже такая работа. Если была -- ориентируйся на прошлое время, если нет, сделай работу. Попробуй определить...

Тема интересная и нужная. У нас на работе ввели квартальное планирование для сотрудников. Недавно меня прессовали по заданиям и срокам, вроде расписали, но что делать со срочными и объемными заданиями, которые валятся постоянно?

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

(0) Сие есть тупость
Бывают задачи где надо 90% думать, бывают где 10% кода отнимают 90% времени
Поэтому имхо только опыт... сын ашипак трудных
Бывает, конечно "неожиданности", но это, в основном, опять же из-за отсутствия опыта и знаний.

(116) если и использовать экспертную оценку, то лучше использовать формулу: оценка = (ОО + 3*РО + ПО)/6

где:

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

РО - реалистичная оценка - сколько времени займет с учетом стандартных рисков

ПО - пессимистичная оценка - если сработают почти все риски

Если использовать метод критической цепи, то формула: оценка = ОО + 0.5*(ПО-ОО)

Если задач очень много, то можно использовать метод маек, когда задачи классифицируются только по сложности: простая, средняя, сложная. У нас под это дело даже данные собираются http://screencast.com/t/cC19hQnvzItz

Если задач много, и их как то расценили все в часах/функ. точках или еще в чем, то можно прикинуть вероятность уложиться в срок на основе распределения скорости выполнения задач. У нас как то так http://screencast.com/t/Tjea9PA6nw



ЗЫ очень часто путают понятия:
Оценка - это как некоторая функция от задания, если на входе задание1, то на выходе оценка1, задание2 - оценка2. Больше никакие параметры не участвуют. Оценка не зависит от харизматичности консультанта или программиста, не зависит от сроков проекта и нетерпеливости РП/Клиента, не зависит и от мотивации и демотивации. Это всего лишь результат подсчета.

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

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

Хороший руководитель называет заказчику срок 3...7 * Срок_названный_программистом.

(115) абсолютно с Вами согласен, принял меры)

(114) 9*T. Указаны итоговые оценки включая предыдущие этапы.

Такую же оценку дают Брукс и Йордон (или один из них, не помню). Конечно, здесь Т это время кодинга до выдачи первого релиза. Исправление ошибок и доведение до ума включено в остальное.