Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Вникнуть в проблему, предусмотреть последствия и предложить улучшения/решения однозначно нужно.
Заниматься улучшениями, доработками «втихоря» не стоит. Потому что эти «улучшения» могут оказаться никому не нужны.
ИМХО, главное — правильная налаженная коммуникация.
Заниматься улучшениями, доработками «втихоря» не стоит. Потому что эти «улучшения» могут оказаться никому не нужны.
ИМХО, главное — правильная налаженная коммуникация.
Если следовать практикам DDD — то обязательно.
К сожалению в Enterprise'е инициатива очень часто наказуема. Т.к. менеджмент на столько боится на себя брать отвественность хоть за какое-нибудь изменения дизайна или функциональности (пусть даже это намного лучше), что потом очень часто достается программисту — т.к. он всегда оказывается крайним.
Было несколько раз, когда наша команда делала по другому, иногда даже говорили спасибо за это, но всегда добавляли — что бы в следущий раз советывались. Но сколько мы не пытались советываться — ответ от менеджера была всегда один — делаем так как написано в спецификации.
Такой уж этот кровавый энтерпрайс.
Недавно на хабре было несколько интересных статей о том, как работают процессы в финансовой сфере в NY.
Было несколько раз, когда наша команда делала по другому, иногда даже говорили спасибо за это, но всегда добавляли — что бы в следущий раз советывались. Но сколько мы не пытались советываться — ответ от менеджера была всегда один — делаем так как написано в спецификации.
Такой уж этот кровавый энтерпрайс.
Недавно на хабре было несколько интересных статей о том, как работают процессы в финансовой сфере в NY.
Было несколько раз, когда наша команда делала по другому, иногда даже говорили спасибо за это, но всегда добавляли — что бы в следущий раз советывались. Но сколько мы не пытались советываться — ответ от менеджера была всегда один — делаем так как написано в спецификации.
Как я Вас понимаю!!! Только нам спасибо не говорили, а вежливо просили оставить вариант как в требованиях!
Зато когда они поняли свою ошибку и пришил за доработками (а у нас-то уже готовый код был) слупили с них по полной :)
по поводу вашего первого примера — а почему тестировщик не смог «прощелкать» и кнопку, и крестик и поставить соответствующую задачу сразу? я думал, что тестировщики должны проверять за программистами, а не наоборот.
Есть пара нюансов:
— нужно именно предлагать, а не делать по-своему без обсуждений (бывали грустные прецеденты);
— если идеи, предлагаемые разработчиком, постоянно отвергаются (к сожалению, не всегда разработчик хорошо понимает предметную область), это явно демотивируют.
Тем не менее, я всецело за — преимущества чаще перевешивают недостатки.
— нужно именно предлагать, а не делать по-своему без обсуждений (бывали грустные прецеденты);
— если идеи, предлагаемые разработчиком, постоянно отвергаются (к сожалению, не всегда разработчик хорошо понимает предметную область), это явно демотивируют.
Тем не менее, я всецело за — преимущества чаще перевешивают недостатки.
ИМХО 2 подхода:
1. Есть умные люди, кто расписывает все (разрабы) и отдает это кодерам, которым думать можно только в рамках текущей задачи (в каком порядке массив заполнить и т.п. мелочи) = Разрабы получают Х денег, но их мало, кодеров много, но они получают меньше Х
2. ПМ расписывает задачи «вольным стилем», а разрабы уже вникают каждый в свою задачу и реализовывают сами — разрабов больше, но меньше цикл разработки.
1. Есть умные люди, кто расписывает все (разрабы) и отдает это кодерам, которым думать можно только в рамках текущей задачи (в каком порядке массив заполнить и т.п. мелочи) = Разрабы получают Х денег, но их мало, кодеров много, но они получают меньше Х
2. ПМ расписывает задачи «вольным стилем», а разрабы уже вникают каждый в свою задачу и реализовывают сами — разрабов больше, но меньше цикл разработки.
В упоминаемой проблеме есть два аспекта — инициатива и ответственность. В статье разбирается только один аспект, связанный с инициативой: «Нужно ли и можно ли разработчикам проявлять инициативу?»
Однозначного ответа на этот вопрос нет. Большинству разработчиков комфортнее работать в условиях, когда все решения уже приняты заранее и при случае можно свалить ответственность на тех, кто ставил задачу, дескать сами виноваты. Но встречаются и такие, которые хотят проявить инициативу, но им не дают, потому что ответственность за принятые решения несет кто-то другой. То, что кажется разработчику лучше, удобнее и полезнее, совершенно не обязательно окажется приемлемо для конечного заказчика.
На мой взгляд, без инициативы невозможен профессиональный рост. Но, как следствие связи инициативы и ответственности, рост происходит тогда, когда вместе с проявлением инициативы вы берете на себя и ответственность за то, что делаете. Безответственная инициатива обычно приносит больше вреда чем пользы.
Однозначного ответа на этот вопрос нет. Большинству разработчиков комфортнее работать в условиях, когда все решения уже приняты заранее и при случае можно свалить ответственность на тех, кто ставил задачу, дескать сами виноваты. Но встречаются и такие, которые хотят проявить инициативу, но им не дают, потому что ответственность за принятые решения несет кто-то другой. То, что кажется разработчику лучше, удобнее и полезнее, совершенно не обязательно окажется приемлемо для конечного заказчика.
На мой взгляд, без инициативы невозможен профессиональный рост. Но, как следствие связи инициативы и ответственности, рост происходит тогда, когда вместе с проявлением инициативы вы берете на себя и ответственность за то, что делаете. Безответственная инициатива обычно приносит больше вреда чем пользы.
Ну да. Только менеджер должен понимать кто перед ним и задачи ставить соответствующие.
p.s. Я с безответственными и безынициативными работать так и не научился :)
p.s. Я с безответственными и безынициативными работать так и не научился :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Должен ли программист быть немножко «product manager-ом»?