Опрос

[kastaneda]

Согласны ли вы, что программист на постоянной работе должен более-менее точно прогнозировать сроки исполнения своей собственной работы и нести за эти прогнозы ответственность?

Comments

[the-petrovich.livejournal.com]

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

[kastaneda]

Точка зрения понятна, спасибо.

[egorfine.livejournal.com]

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

Ну а ответственность за собственную работу - это ты ваще хватанул :) Так еще и работать придется.

[kastaneda]

Точка зрения не совсем ясна, хотелось бы подробностей. Зачем тогда нужны, например, тим-лидеры?

[kievbear.livejournal.com]

Не всегда. В большинстве случаев - да.

[kastaneda]

Тоже понятно, спасибо.

[mt6561.livejournal.com]

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

P.S. И если он не заложил процентов 100-150 прогнозируемого времени на "непредвиденные расходы" - он сам себе злобный Буратино должен в полной мере отвечать перед своим начальством и/или заказчиками за срыв сроков.

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

[kastaneda]

Точка зрения понятна, спасибо за развёрнутый ответ.

[wi1dcat.livejournal.com]

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

[kastaneda]

Спасибо за ответ. Хотелось бы несколько уточнить...

То, что дизайнер может прогнозировать - для меня это очевидно; а как насчёт того, что он должен прогнозировать?

[egorfine.livejournal.com]

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

[fester-ua.livejournal.com]

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

[kastaneda]

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

[zmeuka.livejournal.com]

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

Мотивируют это тем, что сам программист лучше представляет свои возможности, чем они.

Как по мне, правильный подход - НАЗНАЧАТЬ сроки сверху (заказчику - одни, программисту - другие), а потом вежливо ипать программиста за срыв дедлайнов. Подразумевается, что заказчик при этом невежливо ипёт менеджера - но тут уже менеджер хотя бы понимает собственную ответственность за постановку сроков.

[egorfine.livejournal.com]

12) Never, ever let managers tell programmers to reduce an estimate. Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I'm behind schedule, I feel doomed and depressed and unmotivated. When I'm working ahead of schedule, I'm cheerful and productive. The schedule is not the place to play psychological games.

Src: http://www.joelonsoftware.com/articles/fog0000000245.html

Должен

[diggya.livejournal.com]

Если мы берем программера в нашем виденье (совковом) - должен.
Если мы берем кодера - не должен, должен систем-инженер.
Мнение об ответственности - хихикс.

Когда-то услышал рассказ о коеффициенте оптимизма. Т.е есть задача выполнимая за 8 часов. Человек знает что могут произойти непредвиденные трудности, которые задержат выполнение задачи на 4 часоа, получаем К.О. 1.5. и время на выполнение 12 часов. Но при этом начальство знает что человек резервирует себе 4 часа на вероятный пиздец и отпиливает кусок срока, т.е коеффициент оптимизма у начальства меньше единицы. А здесь живёт имхо что если у начальства коеффициент оптимизма перманентно ниже единицы - то срал я на сроки.

Кстати моё мнение что именно менеджер как раз и не должен контролировать сроки исполнения. Может максимум называть крайние приемлимые сроки выхода проекта.

Re: Должен

[kastaneda]

Спасибо за точку зрения. Кстати говоря, производительность кодера (в большинстве случаев) является весьма предсказуемой; точно так же относительно предсказуема скорость работы, например, корректора или верстальщика. Непредсказуемость возможна всегда: несоответствие чего-л. стандартам, несловарнеое слово с подковыркой, баг в полиграфическом софте...

И, кстати, менеджеры разные бывают. Змей выше по треду явно о project-менеджерах говорил.

[xekc.livejournal.com]

прогнозировать - должен. нести ответственность - нет, никогда, никакой.

[kastaneda]

Понятно. Спасибо за мнение.

[fpaint.livejournal.com]

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

[kastaneda]

Спасибо. Надо будет запомнить фразу про злых духов :)

[no--more.livejournal.com]

Угу.

[kastaneda]

Спасибо.

imho

[drdaeman.livejournal.com]

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

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

Нести ответственность - смотря с чем работа.

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

И это всё только для "классического" подхода, когда программист получает и оговаривает задание, некоторое время думает, говорит сроки, потом, пока он работает, ни одна живая душа его не дергает и в итоге он это задание сдает.

Re: imho

[kastaneda]

Спасибо за интересное и детально описанное мнение. Кстати, у меня суровым опытом выработалось такое же мнение: чем больше (сложнее) задача, тем меньше точность прогноза; а чужой код - это потенциальный фактор непредсказуемости.

[3meyc.livejournal.com]

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

Если программист приходит к начальнику отдела/заказчику и говорит, что он не сделал что-либо, то он:
а) если срок сдачи работы прошел - не прав - разъяснения надо было требовать до начала разработки, в крайнем случае в течении процесса разработки.
б) если срок сдачи не назначен или не прошел - прав - в таком случае после уточнения задачи и методов ее решения устанавливается новый срок.

[kastaneda]

Спасибо за мнение. Статистика потихоньку накапливается :)

[http://users.livejournal.com/_iggi_/]

Прогнозировать - да. Мы обычно делаем прогноз каждый сам себе, потом командой их просматриваем. Если у кого-то есть сомнения - прогноз увеличиваем (с расчетом на то, что задачи придется перетасовывать). Если нельзя оценить сходу - разбиваем задачу на более мелкие и/или говорим, сколько надо времени на оценку (почитать доки, сделать прототип, вникнуть). И сверху 30-50% на непредвиденные расходы. В итоге с оценками все согласны. Вот тогда человек, делающий задачу, несет ответственность за своевременное выполнение. А тим-лид - за адекватное распределение задач, свою часть работы и общий ход проекта.

[kastaneda]

Спасибо. Интересное мнение - ты напомнил про то, что ответственность зависит от обоснованности прогноза.

[m-bar.livejournal.com]

Обязан. Причём не только на постоянной, но и на сдельно-премиальной. Ибо на кой хрен нужен разработчик, который не может внятно сказать, когда работа будет готова?

[kastaneda]

Спасибо за мнение.

[malx.livejournal.com]

it depends.
Смотря какой стиль разработки (написание полного ТЗ или X-prog). Смотря сколько человек (1, 3 или 10.000). Смотря какое начальство (какое начальство, таких и работников себе найдет). Смотря какая задача по срокам (одно дело - наваять и массово продавать, другое - "у нас выставка 10го, сделаете задачу до этого срока?").

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

А ответственность - это уж как с начальником договоритесь. Если несет - то ему больше платят, за риски. Если мало платят - то за риски начальство отвечает. Если же фрилансер, то как договоритесь :)

А баг можно ловить до бесконечности (особенно если он не в твоем коде).

ps. Кто помнит статистику? Что-то вроде "только 20%" софтверных проектов заверщается в срок и с соблюдением сроков... Или еще меньше. Не помню откуда.

[malx.livejournal.com]

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

[malx.livejournal.com]

http://www.libo.ru/6328.html
;)

Мне понравилась фраза - "Ошибки могут находить интуитивно."

Так что к вопросу "кем работаете" можно добавить и "знак зодиака" ;)

[kastaneda]

А почему в том гороскопе всем тотально рекомендуют Бейсик и Фортран? :)

[gozra.livejournal.com]

О-о!
Очень интересно читать ветку, спасибо! :)

[kastaneda]

Эй, а как же высказать своё мнение? :))