|
Опять сорвал свои же сроки выполнения или как правильно рассчитать время... | ☑ | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0
AlexITGround
14.11.13
✎
07:54
|
Доброго времени суток. Снова сорвал срок выполнения задачи, причем сам же себе их и устанавливаю, опять пришлось сдвинуть и изменить график. Моя формула: 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. Указаны итоговые оценки включая предыдущие этапы.
Такую же оценку дают Брукс и Йордон (или один из них, не помню). Конечно, здесь Т это время кодинга до выдачи первого релиза. Исправление ошибок и доведение до ума включено в остальное. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |