Имя: Пароль:
1C
1С v8
Опять сорвал свои же сроки выполнения или как правильно рассчитать время...
0 AlexITGround
 
14.11.13
07:54
1. Свой вариант расчета 64% (9)
2. Пользуюсь похожей формулой 29% (4)
3. Ты сам себе злобный буратино 7% (1)
4. Жирный тролль, пришел посмотреть 0% (0)
Всего мнений: 14

Доброго времени суток. Снова сорвал срок выполнения задачи, причем сам же себе их и устанавливаю, опять пришлось сдвинуть и изменить график. Моя формула: T + 0,2Т(поиск рационального решения) + 0,3Т(время на тестирование) + 0,4 (консультирование юзверей во время внедрения) + 0
,01Т(поковыряться в носу), где Т - время чистого кодинга. Несколько статей уже прочел на данную тему. Итак, рассуждения и предложения в студию.
24 France
 
14.11.13
08:15
(23) почитай тайм-менеджмент Архангельского. Стивен Кови хорош.
25 AlexITGround
 
14.11.13
08:17
(24) это по C++ он писал?
26 bushd
 
14.11.13
08:18
(22) ну тебе же сказали это искусство, а проще говоря опыт с огромным количеством переменных включающих предыдущий опыт по данной теме, текущее состояние человека, наличие параллельных задач, жизненная ситуация....
27 France
 
14.11.13
08:18
(25) нет)) как управлять временем и личную эффективность)
28 Лодырь
 
14.11.13
08:18
(0) Вопрос, вы хоть раз в последнее время заканчивали работу намного раньше чем плановая дата? А намного позже?
29 BlueSky
 
14.11.13
08:18
Т * П, где П = 3,1416925

Свой вариант расчета
30 AlexITGround
 
14.11.13
08:20
(27) скачал, благодарствую за вектор
31 bushd
 
14.11.13
08:20
(24) Он для управленцев хорош. 1С-ку не поможет. ИМХО. Хотя хз подробно не изучал.
(29) Если Пи то вроде не верно.
32 BlueSky
 
14.11.13
08:23
(31) подвела память :-) правильно 3,1415926
33 bushd
 
14.11.13
08:24
(32) Почему бросилось потмоу что в школе нас научили считалке)-  Три четырнадцать пятнадцать девяносто два и 6
34 Wasya
 
14.11.13
08:25
(0) Кодинг это весьма второстепенная задача. Считать общее время от времени на кодинг неверно. Самые трудозатратные этапы это:
1) Внедрение.
2) Написание ТЗ.
35 mzelensky
 
14.11.13
08:25
(0) Никогда не любил такие вот "точные сроки выполнения". Мое мнение - никогда ты его не просчитаешь адекватно.

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

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

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

Мое ИМХО лучше выставить большее время и уложиться быстрее, чем установить короткие сроки,а потом гнать в шею и все-равно не уложиться.
36 bushd
 
14.11.13
08:27
(34) Вчера с фиксероми общался он даже не понимает термина внедрение)... это говорит вы франчи все выдумали... (близко к тексту. Прикольно.  
Вообещм основное время пожиратель для меня на проекте это обумывание способа решения. вертишь и так и эдак и этом может быть вечно... Иногда надо остановится и начать делать)
37 Stepa86
 
14.11.13
08:30
Как минимум формула некорректна, потому что для разных задач будет разное распределение на поиск решения, кодирование, тестирование итп.

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

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

Порой нужно просто остановить этот поток мыслей и просто НАЧАТЬ! А уже в ходе работы многие вещи сами встанут на нужный путь.
39 France
 
14.11.13
08:31
(35) это говорит только о не умен и планировать.и, вообще-то, никто не отменял правило - задача занимает все выделенное время + "еще чуть чуть" (36) точно подмечено - начать делать)
40 ДенисЧ
 
14.11.13
08:32
(33) Эти знаки я помню прекрасно
пи многие знаки мне лишни, напрасны
:-))
41 Stepa86
 
14.11.13
08:32
кстати, самая низкая достоверность оценки у "Экспертной оценки", самая высокая у комбинации нескольких, основанных на подсчете и исторических данных текущего проекта
42 AlexITGround
 
14.11.13
08:32
(38) у меня план расписан на две недели вперед, как я могу делать задачу сразу, м...?
43 AlexITGround
 
14.11.13
08:33
(37) благодарю, скачиваю
44 bushd
 
14.11.13
08:34
(35) Это основной минус 1С-ков, разработка софта по заказ в сжатые сроки под клиента).  
Сравните с любым нормальным программером - пишет в команде на окладе приложение которое потом запускают в тираж. Никто никогда сроки не ставит четкие, никто не парится по баблу (оклад) - те. не ставит человека в стрессовую ситуацию. Причем как известно стресс противоречит умственной деятельности, стресс требует быстрых решений и простых типа бежать/прятаться. Думать поздно.
Я вот давно сделал выводы)... и принял решения по работе в сфере 1С. И знаете все гораздо лучше получается)
45 mzelensky
 
14.11.13
08:37
(42) Это уже совершенно другой вопрос.
46 Drac0
 
14.11.13
08:39
Можно по опыту угадывать, но 100% результата не будет никогда, ИМХО. Очень много факторов.

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

Есть положительные. Поменялась логика работы небольшого участка, пришлось организовывать новое хранение данных ,обработки по работе с ним, менять логику отчетов. Отвели две недели на это, но оказалось, что раньше я достаточно удачно все организовал и готово было через 3 дня.
47 mzelensky
 
14.11.13
08:41
(44) "Сравните с любым нормальным программером - пишет в команде на окладе приложение которое потом запускают в тираж. Никто никогда сроки не ставит четкие, никто не парится по баблу (оклад) - те. не ставит человека в стрессовую ситуацию"

_ да что ты говоришь! Знаю многих web-щиков, Делфистов, Разрабов мобильных приложений - во многом ситуация аналогичная. И дело тут не в проге, а в менеджере (топ-менеджере), который заключает контракт с клиентом (ну если утрированно).
48 mdocs
 
14.11.13
08:41
на обычных задачах исполнитель ошибается по срокам в два раза, на новых для него - в пять. где-то прочитал.
49 bushd
 
14.11.13
08:44
(47) Я же говорю писать что то стоящее под заказ для одного конечного клиента - дурдом... Все равно на чем... хоть на ассемблере)
50 bushd
 
14.11.13
08:46
(49) Не ну вопрос в условиях... просто конечнику надо обычно сжатые сроки и сжатые суммы...
51 Cube
 
14.11.13
08:46
Есть у меня дружбан, он всегда делает так:
1). Оцениваешь проблему. Допустим, оценил в 5 часов.
2). Умножаешь полученную цифру тупо на 2, но лучше на 3. Получаем 15 часов.
3). Сообщаешь клиенту.
4.1). Если клиент отказывается, то это не твой клиент (нищеброд).
4.2). Если клиент соглашается, выполняешь задание.
5.1). Если сделал за 15 часов - клиент доволен.
5.2). Если сделал за 5 часов - клиент просто счастлив.
6). Профит.
52 ProProg
 
14.11.13
08:46
(0) что тебе могут посоветовать бездельники которые вместо работы весь день на мисте флудят.
53 Stepa86
 
14.11.13
08:47
статьи по теме:

Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения 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
54 bushd
 
14.11.13
08:49
(53) О сколько изысканиий.... и все бестолку). Хорошо работать на Мискрософт, потмоу что на огромный тираж). Всё окупается и сроки и программисты со своими тараканами)
55 Stepa86
 
14.11.13
08:51
(54) при продуктовой разработке тоже нужно уметь оценивать задачи. Не кодеру, так архитектору точно. А то можно продукт никогда не выпустить и не уложиться в обещанный срок релиза
56 Lama12
 
14.11.13
08:57
(0) Как то очень смело. Чистый кодинг, обычно занимает не более 20% от проекта. Т.е. для оценки времени нужно время кодинга умножать на 5 или более. Это уж очень приблизительно.
Тестирование, не отладка, может занимать столько же времени или больше.
57 bushd
 
14.11.13
08:57
(55) Ну там все гораздо мягче. А под заказ, - ты не вписался в бюджет и все проект умер,  и самое плохое - умерло желание вообещ начинать все это... повторно. Бизнес требует четких сроков и сумм.
58 Gantosha
 
14.11.13
08:57
а собственно никак - когда задач много отклонение от сроков   будет меньше сумма отклонений по отдельным задачам. Поэтому или дробить на множество задач или рассматривать все задачи как одну большую.
59 DarKySiK
 
14.11.13
08:58
ИМХО, для того, чтобы более менее точно распланировать свое время, нужны достоверные нормативы. Нормативы всегда субъективны. Т.е. нужно знать, сколько именно ТЫ можешь потратить времени на решение конкретного типа задачи. При планировании широкой задачи необходимо детализированное разузлование на подзадачи, для которых имеется норматив. Тем самым могут вылезти те нюансы, которые ты с первого взгляда не заметил.
Важно фиксировать большинство из того, что ты делаешь по плану и вне плана.
Тем самым будешь корректировать свои нормативы и закладывать в дальнейшие планы дельту на внеплановые хотелки.
Ну и не забывать про гигиену труда ;) и погрешность на "тупизм" ))

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

Свой вариант расчета
60 wowik
 
14.11.13
09:02
просто расчетное время * 2.

Пользуюсь похожей формулой
61 bushd
 
14.11.13
09:04
(60) В переводе на русский: время с потолка *2 = время с потолка.  (для новой задачи, ранее не делавшейся)
62 Stepa86
 
14.11.13
09:07
(57) все зависит от менеджера проекта. Продуктовая разработка обычно сложнее проектной и требует больше знаний, опыта, сил. Если сравнивать проектную работу франча и продуктовую майкрософта, то есессно кажется, что разработать продукт намного проще, но на самом деле все дело в технологиях, опыте и людях, что стоят над кодерами: тимлиды, техлиды, МП, линейные менеджеры итп


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

Можно отреагировать ранее и обрезать содержание проекта, можно выбить увеличение бюджета, можно делать проект так, чтоб не вылезти за треугольник... Причин превышения бюджета масса, и не так уж и часто среди них плохая оценка
63 mzelensky
 
14.11.13
09:07
(61) не так. Есть общая задача. В ней присутствуют как "однозначно понятные моменты" так и моменты с которыми ранее не приходилось сталкиваться. Значт - бьем общую задачу на подзадачи. Каждую "понятную" подзадачу оцениваем и оцененное время умножаем на 2 (3), а на каждую "не понятную" закладываем "время с потолка", которео зависит от собственных сил (уверенности).
64 bushd
 
14.11.13
09:07
(51) Т.е он не только время свое оценивает но и сумму для клиента?  Забавно. С одной стороны люди рискуют с другой даже не пытаются играть по правилам рынка в свою пользу.
65 ifso
 
14.11.13
09:08
(6) +1 (только сначала на два умножить нужно)
66 bushd
 
14.11.13
09:10
+(64) И сразу клиент плох). Нищеброд... смешно. Человеку не рентабельно делать данную работу и все. Надо предложить готовые варианты и все ли так и объяснить ваши изыскания вам не по карману - вам типовое отраслевое решение.
Все 1С-ки нищеброды потому что не могут заказать индивидуальный проект машины под себя, а сплошь катаются на тиражных типовых машинах)))
67 mzelensky
 
14.11.13
09:11
(62)(57) понравилась фраза из

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

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

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

Вот о чем я и говорил. Обычно с клиентами разговаривают\договариваются именно менеджеры, а потом уже начинают "натягивать" итоговое решение на разрабов.
68 bushd
 
14.11.13
09:12
+(66) Ну да я согласен некоторые отчетики дописывают ))) в сервисах типа шумки, или музыки), кресло там поменяют или еще что)))
69 VladZ
 
14.11.13
09:14
(0) поиск рационального решения не зависит от времени кодинга.
70 bushd
 
14.11.13
09:15
(67) Гы гы, ты прочел, но не так понял... Это как раз пробелма ФРИ. Делов том что пошли договариваться разработчиков и их тоже уболтают)...
71 NcSteel
 
14.11.13
09:16
Время умножаю на 2 минимум.

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

Свой вариант расчета
72 bushd
 
14.11.13
09:16
+(70) Как раз таки в подобных переговорах должны участвовать оба или менеджер в теме.
73 bushd
 
14.11.13
09:19
+(70) Проблема менеджеров заказчика в том что они не понимают правильно цели при подобной задаче. Уболтать на сроки и суммы меньше необходимых - гарантированно провалить проект!))) К несчастью это не переговоры о поставкой готовой продукции...
74 bushd
 
14.11.13
09:20
+(73) Потомоу что никто и никогда не будет работать бесплатно...даже если их уговорить - вытянуть согласие).
75 bushd
 
14.11.13
09:21
+(74) Почему с торгашами и трудно говорить о работе... Потому что они по инерции переносят свой опыт на другую сферу...
76 mzelensky
 
14.11.13
09:22
(72) не знаю какой опыт у тебя, но из личного опыта могу сказать сразу - прогов допускают к переговорам далеко не сразу, а лишь во втором-третьем общении. До этого преговоры проходят исключительно между манагерами, где уже примерно обсуждаются сроки, а уже после слегка корректируются оценками прогов.

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

Если и манагер и разработчик это одно лицо (как наш ТС), то тут ситуация другая.
77 bushd
 
14.11.13
09:22
+(74) И так то ошибка высоко вероятно, а когда еще такие "помошники" помогают... то вообещ амба.
78 bushd
 
14.11.13
09:23
(76) Непонятно что могут обсуждать манагеры.... не зная темы.
79 mzelensky
 
14.11.13
09:24
(78) Прикольный у тебя монолог. Интересно, а если вообще все замолчат - ты сможешь самостоятельно продолжать и развивать тему?
80 bushd
 
14.11.13
09:24
+(78) Хотя если это внедрения типовых решений то тут более менее все ясно.
81 bushd
 
14.11.13
09:25
(79) Не понравилось? Не читай)
82 mzelensky
 
14.11.13
09:25
(78) (80) Заблуждаешься. Манагеры знают тему, но зают ее достаточно поверхностно (как правило), а как говорится "дьявол кроится в деталях"
83 mzelensky
 
14.11.13
09:26
(81) Может тебе бложик завести ?! :)
84 VladZ
 
14.11.13
09:27
Начни сначала... Должно быть как-то так.

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

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

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

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

Как-то так.
85 Maxus43
 
14.11.13
09:28
(0) Дак на мисте поди сидишь, включи в формулу +Миста 0,5Т.

И зачем сроки на фикси? всмысле я тоже на фикси, спрашивают когда сделаешь - прикидываю в пределах дней а не часов
86 Серго62
 
14.11.13
09:28
(0) Время тестирования это как минимум 2Т.
А вот что имелось ввиду под поиском рационального решения не понял. Если это алгоритм решения задачи, то как ты сначала определил Т, не имея способа решения этой задвчи?

Пользуюсь похожей формулой
87 Серго62
 
14.11.13
09:29
+(86) ошибся с голосованием

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

Свой вариант расчета
89 bushd
 
14.11.13
09:32
(82) В чем я заблуждаюсь? В том что это дурдом договариваться о сроках не зная темы?
(83) Может тебе модератором стать?
90 VladZ
 
14.11.13
09:32
+84 Раз ты снова сорвал сроки, скорей всего проблема у тебя с первыми двумя пунктами... Да, и забуть про "01Т(поковыряться в носу)". Представь, что ты должен выставить счет за проделанную работу. Ты так и напишешь "ковыряние в носу"? Согласись, несерьезно?
91 VladZ
 
14.11.13
09:33
+90 Упс. "и забуть" -> "и забудь".
92 bushd
 
14.11.13
09:33
+(89) Я никогда один не разговариваю с клиентами если не знаю темы.
93 samozvanec
 
14.11.13
09:33
а я считаю, что прибавлять 0,5Т и т.п. это самообман. надо считать коэффициентами, типа как при расчете страховки.
т.е.

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

Свой вариант расчета
94 wms
 
14.11.13
09:33
на 3 умножаю свою перв. оценку
если не успеваю, то работаю ночами
95 Джордж1
 
14.11.13
09:35
Вот не понимаю, как вообще можно ТЗ написать подробное.
Я когда свои нетленки писал получалось примерно так:
1.Пишешь сразу код
2.Забиваешь реальные данные и смотришь отчеты
3.Понимаешь что нифига не оптимально написал и 50% кода переписываешь заново
96 Серго62
 
14.11.13
09:37
(76) Вот это вот самый жесткий вариант, когда манагеры договорились о сроках, а программистам надо в эти сроки уложиться.
97 bushd
 
14.11.13
09:38
(94) Никогда не работаю ночами... на мой взгляд - потеря времени. Но возможно это мои особенности.
98 VladZ
 
14.11.13
09:38
(95) Представь, что ты строитель... И строишь не какой-нибудь сарай, а элитный многоэтажный дом.
99 bushd
 
14.11.13
09:38
(95) Тут баланс нужен.
100 Серго62
 
14.11.13
09:40
(95) А ты словами не пробовал сформулировать, то что накодить планируешь?
101 mzelensky
 
14.11.13
09:41
(89) модератором твоего бложика? А платить сколько будешь? :)
102 Серго62
 
14.11.13
09:41
103 wms
 
14.11.13
09:42
(97)мужик сказал, мужик должен сделать
104 AlexITGround
 
14.11.13
09:43
(84) спасибо за дельный ответ
105 France
 
14.11.13
10:04
(95) уволить нельзя оставить.
106 Sabbath
 
14.11.13
10:09
(0) Читал вроде у Макконелла, что кодинг занимает чуть ли не 20% времени разработки. И это именно разработки, без тестирования и т.п.

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

Свой вариант расчета
107 Sabbath
 
14.11.13
10:11
+(106) часто идет просрочка, т.к. сам затягиваю, работаю не спеша)
108 Sabbath
 
14.11.13
10:12
(103) это два разных мужика
109 MaxisUssr
 
14.11.13
10:18
Стараюсь тоже какую-нибудь плевую задачу "делать" неделю, хотя сначала вроде бы думаешь что за день-два выйдет (бывает что так и выходит). Но в половине случаев вскрываются нюансы и косяки, поэтому себя благодаришь что не сказал срок в один день.
По теме - срыв сроков грозит чем-то? Зарплата выше рынка? Если хотя бы один ответ "нет" то и не парься

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

Пользуюсь похожей формулой
111 AlexITGround
 
14.11.13
10:55
(109) грозит тем, что неправильно планирую; выше рынка
112 Джордж1
 
14.11.13
10:57
(98)эх если бы со стройкой так было можно. А пока у меня стройка стоит, во многом по этим же причинам
(100)не получается. Тут и заказчик до конца не понимает что ему надо и ты пока не попробуешь влезть в шкуру пользователя не все видишь. Речь идет о нетленках с "0", где какой-то основы совсем нет. Дорабатывать типовые в этом плане проще
113 Поросенок Петр
 
14.11.13
10:59
Просто Кодинг T. Плюс время на превращение этого "кода" в продукт (тестирование, доработки) - 3*Т. Плюс время на внедрение - 9*T.

Свой вариант расчета
114 AlexITGround
 
14.11.13
12:59
(113) в итоге у тебя время кодинга 1/13 от общего времени без предварительного обследования...хм
115 Asvss
 
14.11.13
23:49
Рассуждения и предложения не программиста (безотносительно к конкретному случаю):
нужно понимать, что когда работник не укладывается в срок, фактически нарушая условия договора, пусть и устного - он подводит не только себя ("слово пацана", "мужик сказал..." и т.д.), но и всю команду. Возможно некоторым людям наплевать, что их считают балаболами, да и фиг бы с ними, если они работают одни, в противном случае - репутация проецируется на всю группу разработки, отдел, департамент, менеджера, фирму и т.д.. И нужно понимать, что на вашем куске кода, который вы сами пообещали сдать к определенной дате, дело не заканчивается, окружающие планируют свою деятельность (релизы, командировки, бюджеты, следующие задачи и т.д.), т.е. вы крадете чужие ресурсы.
Но еще большее зло чем нарушить самим собой установленный срок, это сообщить об этом непосредственно в момент истечения срока!  В жизни все бывает, можно ошибиться в планировании, можно встретиться с непредсказуемыми сложностями, но замалчивать проблему до последнего и не давать шанса партнерам перепланировать -  свинство.   Рекомендую почитать "черную книгу менеджера", жестковато но по данной теме хорошо написано.
P.S. 2 AlexITGround  вышенаписанное не в укор персонально Вам, то что Вы озадачились данным вопросом уже большой плюс, работайте над ошибками и все придет с опытом, удивляют некоторые комментарии, люди кто ж вам деньги то платит с таким наплевательским отношением?

Ты сам себе злобный буратино
116 Steel_Wheel
 
15.11.13
00:55
(0) Используй экспертную оценку.
1) Если есть более крутые товарищи -- спроси у них (важно, чтобы у нескольких), посчитай среднее, сделай поправку на свое "нубство" и на "тупизм" Заказчика.
2) Сделай работу. Попробуй определить: какого рода она была. Запиши, сколько времени потратил. Когда будешь брать заказ, посмотри: была ли у тебя уже такая работа. Если была -- ориентируйся на прошлое время, если нет, сделай работу. Попробуй определить...
117 Jackman
 
15.11.13
01:14
Тема интересная и нужная. У нас на работе ввели квартальное планирование для сотрудников. Недавно меня прессовали по заданиям и срокам, вроде расписали, но что делать со срочными и объемными заданиями, которые валятся постоянно?
118 disk-2008
 
15.11.13
02:07
(117)Сообщать про утвержденный план и отсылать к руководству за его изменение со сдвигом сроков ранее предполагаемых заданий, если кто-считает своё задание более срочным.
119 КонецЦикла
 
15.11.13
02:13
(0) Сие есть тупость
Бывают задачи где надо 90% думать, бывают где 10% кода отнимают 90% времени
Поэтому имхо только опыт... сын ашипак трудных
Бывает, конечно "неожиданности", но это, в основном, опять же из-за отсутствия опыта и знаний.
120 Stepa86
 
15.11.13
08:40
(116) если и использовать экспертную оценку, то лучше использовать формулу: оценка = (ОО + 3*РО + ПО)/6

где:

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

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

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

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

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

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



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

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

Обязательство - обещание предоставить требуемую функциональность на согласованном уровне качества к конкретной дате/за конкретное количество часов/конкретное количество денег. Обязательство может совпадать с оценкой, быть больше (добавляем риски, закладываем прибыль) или меньше (политика) и в общем случае оценка и обязательство не равны.
121 dmpl
 
15.11.13
08:52
Хороший руководитель называет заказчику срок 3...7 * Срок_названный_программистом.

Свой вариант расчета
122 AlexITGround
 
15.11.13
08:58
(115) абсолютно с Вами согласен, принял меры)
123 Поросенок Петр
 
15.11.13
09:05
(114) 9*T. Указаны итоговые оценки включая предыдущие этапы.

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