Gaen Dec 3 2009 at 17:30

Очередная выстраданная истина

1 min

585

Lumber room

Comments 19

ra1nbow Dec 3 2009 at 17:38

согласен :(

Andrey_Rogovsky Dec 3 2009 at 17:51

Как определить реальный срок проекта?
Узнать у программиста за сколько дней он сделает (X)
Функция будет такой
R=X*X+X

aleo Dec 3 2009 at 18:08

То есть если программист говорит 15 дней, то надо думать 240 дней? ;-)

Я думаю ближе к правде будет X*2 + X.

ashofthedream Dec 3 2009 at 18:12

Тогда уже X*3

homm Dec 3 2009 at 18:21

м… X*2 + X
По моему точнее X*4 — X

meteozond Dec 4 2009 at 01:28

обычно это x*k, где k — показатель оптимизма, колеблющийся от кодера к кодеру.
Хороший менеджер знает k своих сотрудников :)

Gaen Dec 4 2009 at 01:41

Проблемы начинаются, когда сам менеджер тоже является кодером)

meteozond Dec 4 2009 at 09:14

Это да, главное вовремя понять, что контроль и управление занимает не меньше времени чем кодинг. Я так свой первый проект пролюбил — переоценив силы как руководителя-кодера.

amlet Dec 3 2009 at 18:01

Блин и не поспоришь… Хотя опредлённая доля лени всё же присутствует, особенно если уж совсем не уметь правильно оценивать свои силы: даже оценив как-то то, что делаешь, вроде бы учтя риски, думаешь, вот де это пока можно отложить, а потом я поднажму… ага… щаз… Очередная неправильная оценка сроков внутри уже неправильно оцененных сроков :))

mrThe Dec 3 2009 at 18:02

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

dragvs Dec 3 2009 at 18:25

Ага, действительно, это относится к программистам, которые еще не научились оценивать объем работы и выдавать истинные сроки.

dragvs Dec 3 2009 at 18:26

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

Coolver Dec 3 2009 at 18:32

Вообще-то всё очень зависит от задачи. Если это создание сайта-визитки, который делался многократно этим программистом на протяжении долгого времени, то он с большой долей вероятности сможет назвать вам реальные сроки. Но если это сложный программный продукт, который содержит в себе функционал, с которым данная компания/команда не сталкивалась, то реальных сроков назвать нельзя. Есть так называемые риски, которые могут присутствовать в проекте. Это именно те задачи и подводные камни, которые не видны на первый взгляд. Поэтому программист и может назвать оптимистичный прогноз. Но реальность такова, что не смотря на появление всех этих новомодных (хотя уже так долго они существуют, что можно назвать и старомодных) тенденций в управлении проектами, IT-проекты по статистике где-то в 60% случаев — не сдаются в срок. Но самое интересное то, что те оставшиеся 40% нельзя назвать успешными. Так как завершение в срок большей их части было сделано ценой превышения первоначально запланированного бюджета в разы. Сегодня программирование пока ещё остаётся чем-то творческим и исследовательским. Поэтому есть ещё куда стремиться в развитии индустрии производства программного обеспечения. Всё-таки отрасль относительно молода и сейчас идёт период становления.

andreycheptsov Dec 3 2009 at 19:09

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

iv_s Dec 3 2009 at 19:31

Простая формула для личной оценки сроков(ёпт метод":)).
Прикинуть сколько дней это займет(t) и помножить получившееся значение на e(≈2.7).
Затем помножить итог на π(≈3.14:)) и сказать результат заказчику.
В итоге, если в процессе выполнения не одалеет понос или золотуха, то функция реального времени от прикинутого:

ƒ(t)=eπt

Gaen Dec 3 2009 at 20:50

клевый метод)

erley Dec 3 2009 at 21:54

Чёрт побери, опередили — именно так сам и делаю! Как ни странно, работает :)

Equ Dec 3 2009 at 20:24

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

makulia Dec 8 2009 at 16:26

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