Обновить
Комментарии 16
Вникнуть в проблему, предусмотреть последствия и предложить улучшения/решения однозначно нужно.
Заниматься улучшениями, доработками «втихоря» не стоит. Потому что эти «улучшения» могут оказаться никому не нужны.
ИМХО, главное — правильная налаженная коммуникация.
Если следовать практикам DDD — то обязательно.
К сожалению в Enterprise'е инициатива очень часто наказуема. Т.к. менеджмент на столько боится на себя брать отвественность хоть за какое-нибудь изменения дизайна или функциональности (пусть даже это намного лучше), что потом очень часто достается программисту — т.к. он всегда оказывается крайним.
Было несколько раз, когда наша команда делала по другому, иногда даже говорили спасибо за это, но всегда добавляли — что бы в следущий раз советывались. Но сколько мы не пытались советываться — ответ от менеджера была всегда один — делаем так как написано в спецификации.

Такой уж этот кровавый энтерпрайс.
Недавно на хабре было несколько интересных статей о том, как работают процессы в финансовой сфере в NY.
Было несколько раз, когда наша команда делала по другому, иногда даже говорили спасибо за это, но всегда добавляли — что бы в следущий раз советывались. Но сколько мы не пытались советываться — ответ от менеджера была всегда один — делаем так как написано в спецификации.


Как я Вас понимаю!!! Только нам спасибо не говорили, а вежливо просили оставить вариант как в требованиях!
Зато когда они поняли свою ошибку и пришил за доработками (а у нас-то уже готовый код был) слупили с них по полной :)
Да, как написали тут выше, инициативный разработчик — это хорошо. Но хорошему разработчику нужно хорошее понимающее начальство.
по поводу вашего первого примера — а почему тестировщик не смог «прощелкать» и кнопку, и крестик и поставить соответствующую задачу сразу? я думал, что тестировщики должны проверять за программистами, а не наоборот.
Изначально (сразу) было сломано только одно. После починки сломалось другое.
Тестировщик-то конечно и проверял;)
Есть пара нюансов:
— нужно именно предлагать, а не делать по-своему без обсуждений (бывали грустные прецеденты);
— если идеи, предлагаемые разработчиком, постоянно отвергаются (к сожалению, не всегда разработчик хорошо понимает предметную область), это явно демотивируют.

Тем не менее, я всецело за — преимущества чаще перевешивают недостатки.
(бывали грустные прецеденты);

а можно первому пункту пример привести, если его приемлемо разглашать?
Из своей практики могу только о своих ошибках говорить (именно архитектурных). А вот о чужих архитектурных ошибках очень интересно и познавательно рассказывает Сергей Мартыненко. На прошлом DevConf 2013 его небольшой доклад был одним из интереснейших, по крайней мере для меня!!!

ИМХО 2 подхода:
1. Есть умные люди, кто расписывает все (разрабы) и отдает это кодерам, которым думать можно только в рамках текущей задачи (в каком порядке массив заполнить и т.п. мелочи) = Разрабы получают Х денег, но их мало, кодеров много, но они получают меньше Х
2. ПМ расписывает задачи «вольным стилем», а разрабы уже вникают каждый в свою задачу и реализовывают сами — разрабов больше, но меньше цикл разработки.
У вас как на практике встречалось? Оба варианта?
Да.
Первый вариант — это большие проекты: инхаус разрабы + фрилансеры-кодеры на оутсорсе/подрядчики
Второй вариант — обычно небольшой коллектив/группа работающий/ая над проектом. Часто это проект-стартап или просто нечто что имеет непонятные ТЗ/исследования и т.п.
В упоминаемой проблеме есть два аспекта — инициатива и ответственность. В статье разбирается только один аспект, связанный с инициативой: «Нужно ли и можно ли разработчикам проявлять инициативу?»

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

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