MISC · 02 декабря 2017, 10:08 · Отдел информации dev.by
Почему ваши разработчики хотят «просто кодить, и чтобы их не трогали»

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

Иллюстративное фото, Андрей Давыдчик для dev.by

Когда я нанял программиста Джейми в компанию ZenTech, он казался полным энтузиазма инженером. С прекрасными техническими навыками, идеями для улучшения процессов и продуктов, а также умением строить отношения внутри команды, он был очевидным выбором. Но буквально два года спустя Джейми уже был «тем самым парнем», который ничего не хочет, кроме как кодить — и чтобы его оставили в покое.

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

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

Так в команде появился очередной «стереотипный» программист, который «просто хочет кодить». В чём причина? Слишком много руководителей считают, что проблема кроется в самом Джейми. Если бы он был более эффективным сотрудником, трудоголиком — или хотя бы просто не таким «пофигистом»  — этого не случилось бы. Так ли это? К сожалению, нет. Переход от программиста-энтузиаста к программисту, которому всё равно, не происходит в одночасье. И он начинается раньше, чем вы думаете.

Первые идеи имеют большое значение

То, как именно вы обрабатываете идеи и предложения новых программистов, посылает очень важный сигнал и создаёт предпосылки для их дальнейших ожиданий. Это определяет, будут ли они генерировать идеи в будущем или предпочтут держать язык за зубами и кодить. Конечно, некоторые идеи могут оказаться невыполнимыми в вашей среде и ситуации, некоторые могут уйти на задний план («обсудим в свободное время»), некоторые окажутся великолепными, но противоречащими внутренним нормам — скажем, корпоративной культуры.

Независимо от причин, отклонение или обесценивание идей программиста, особенно в первые несколько месяцев, — это плохой ход. Вероятно, он попробует ещё несколько раз по-разному представить свои идеи, но в конце концов придёт к выводу, что единственный способ выиграть — это не играть. Полагаю, вы не хотите, чтобы ваши программисты это усвоили. В этот момент разработчик перестаёт представлять идеи, просить о встрече с клиентами и пытаться понять, как устроен бизнес. В конечном счете, это lose-lose.

Иллюстративное фото, Андрей Давыдчик для dev.by

Все фокусируются на успехе, и разработчики тоже 

Как и любой другой человек, разработчик стремится делать то, в чём успешен: создание кода, — если его энтузиазм насчёт изменения мира, креатива, инноваций и развития утерян. Его интерес, скажем, к доле рынка сменяется беспокоойством о том, сколько он зарабатывает, каков его тайтл и как он выглядит на LinkedIn.

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

Чему вы учите разработчиков?

Хотя вы никогда не скажете об этом напрямую, ваша внутренняя культура может транслировать установки вроде  «Наша компания не любит большие идеи от маленьких людей», «Сосредоточьтесь на разработке. Мы сами выясним, что нужно клиенту», «Делай свою обезьянью работу, code monkey», «Хм, почему ты задаёшь столько вопросов, тебе нечего делать?».

Культура — это не лозунг на вашей стене и не описание миссии компании во время  собеседования. Культура — это то, как люди действуют и о чём они на самом деле заботятся. Если вам интересно, какая у вас культура, посмотрите, как ведут себя люди. Если вам не нравится увиденное, измените это. Культура не диктуется, она изучается, моделируется, имитируется. Установки лидера будут копироваться на всех уровнях. Поэтому культура — не вина Джейми. Её формируют руководители команд, менеджеры, технический директор. Поэтому перестаньте обвинять Джейми и приступайте к изменения, в которых нуждается ваша культура. Чем скорее, тем лучше.

Дискуссия: а чем плохо хотеть «строить вещь правильно»?

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

— Это правда! — подтверждает Маркус Бланкеншип. — Я хочу, чтобы мои команды создали высококачественное программное обеспечение. Но вполне можно создать высококачественное, надёжное, масштабируемое, поддерживаемое ПО, которое не добавляет никакой ценности пользователям или компании. На самом деле, не просто возможно: это происходит постоянно.

Когда инженер присоединяется к компании, он обычно заинтересован в понимании ценности того, что эта компания строит. Он хочет знать, какие факторы влияют на бизнес, что думают пользователи и т.д. Я считаю, что обсуждения таких тем очень важны для инженеров по многим причинам. Это то, что я назвал заботой о «построении правильной вещи». Если же инженеры замечают, что их голос не слышат, их идеи игнорируют или говорят «это не ваше дело», они переходят на позицию заботы только о «правильном построении». Хотя оба эти аспекта важны, и когда один из них выпадает из поля зрения инженера — это плохо.

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

Источник: dev.by
Новые комментарии

Обсуждение

Missing

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

Missing
+17

Смешно, как каждый считает говнокодом все, что до него было написано. А потом на его место приходит кто-то еще - и считает говнокодом уже его код. Ха-ха!

Missing
+2

да, так и есть

Missing

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

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

Missing

В такую компанию надо же было как-то для начала (сознательно, надеюсь) устроиться на работу.

Missing-male
+1

Вся разница в том, что девелопер знает причины почему его говнокод написан именно так но не знает/понимает причин почему предыдущий говнокод были вынуждены написать так, как он написан.

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

Missing

Так и надо быть позитивнее - это жизнь ) Увидел плохой код - исправь, а не ной ))) Шутка.

Missing
-4

Кодер должен кодить.

Программист должен программировать.

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

Picture?type=square
+3

хех, еще один смешной коммент, прямо как в статье написано:

«Наша компания не любит большие идеи от маленьких людей», «Сосредоточьтесь на разработке. Мы сами выясним, что нужно клиенту», «Делай свою обезьянью работу, code monkey», «Хм, почему ты задаёшь столько вопросов, тебе нечего делать?»

Вот только объясните мне одну простую вещь: Зачем нанимать умных людей, устраивать мега интервью, проверять их соц скилы и проч. Если по вашей методе можно банально нанять "волокущий в технических вопросах продукт менеджер и кволити ашшуренс менеджер" (с) и будет счастье. Эти двое разобьют все задачи на мелкие таски, так чтобы даже студент мог сделать. Эти же двое проверят качество. Сделают код ревью. Всегда будут знать в каком именно направлении надо развивать продукт и улучшать его внутренности. Профит по практически бросовой цене в 2.5 сениор заработной платы .

По вашему получается весь мир iT где-то свернул не туда.

Missing

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

Picture_2702?1356409883
+2

Не поверите, именно это "эти двое" и должны делать. Но, как правило, оне на это тупо неспособны, потому как слегка туповаты-с... да-с ;)

Missing

Товарищ Дударев. Смешно не то, что я написал, а то, как вы это исказили в своем сознании.

Продукт менеджер и кволити ашшуренс менеджер, должны обладать и профильными менеджерскими скиллами в т.ч. "софт", и "быть волокущими в технике" на уровне "солюшенс архитекта". Тут логика И, почему вы исключающее ИЛИ тут увидели, есть тайна для меня.

когда недостаток одних или других скиллов у менеджеров - и то и другое плохо, видел и то и другое.

Такчто, уважаемый товарищ Дударев, это не it мир не туда свернул, а лично Вы, когда не понятно на каком основании увидели тут исключающее "ИЛИ" в вопросах скиллов продакта и кволити ашуренса.

Picture_2702?1356409883

То, что они должны еще ни разу не значит, что они на самом деле этим самым обладают. Как правило нет.

Missing
+3

С таким подходом ты останешься просто безликим "программистом" 40$ час, а потом тебя заменят на более энергичного. Даже для инженерного роста, нужно вылезать из своего кокана и интересоваться миром вокруг, читать новые пейперы, интересоваться новыми алгоритмами, задавать вопросы. А еще лучше если ты начнешь задавать вопросы, зачем ты это делаешь, для кого, что ты решаешь. Нельзя принимать эффективные решения и дизайнить систему не понимая как её будут использовать и почему.

Missing
+6

>> Нельзя принимать эффективные решения и дизайнить систему не понимая как её будут использовать и почему.

Опять же, это очень правильно и очень крутая идея, которая не работает, если тебе не дают на это время. Скажем у меня план и ты мне должен сделать эту работу. Я поздравляю что ты интересуешься всем вне своего кокана, но мне нужен этот сервис завтра к вечеру, хоть усрись. Поэтому твои вне-рабочие активитисы это круто, но за твой счёт пожалуйста. И когда у меня такой план, что хоть усрись, но надо, и знаю, что не успеем, а мои гребцы строят из себя sales team или usability experts (вместо того, чтобы налечь на вёсла), то все дружно идут в сад. Это мой вид на мир, маленького тех лида.

63637f4ec5ea136f9d17ce151501368e?1401052531

А если дают время?

Picture_2702?1356409883
+6

Угу, а в ПМ-ы и прочее мелкое начальство у нас обычно идут карьеристы, которые поняли, что программинг это 'не их'. Мозгов не хватает ибо... ну и скил у них один: бить на галере в барабан - задавать ритм. О какой продуктовой заботе вы говорите? ;) Они тупо не в состоянии. Был бы мозг - остались бы техлидами. А так, хватает только тасочки в жире заводить и мозг программероф компостировать. Фууу.

Не все конечно, но большинство.

Missing
-1

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

Missing
+3

Ну как бы в научном менеджменте уже лет сто назад предположили что работник лучше выполняет свои задачи, если объяснить ему нормально цель его работы, а не рассматривать его как придаток к станку. Причем у них там речь шла о профессиях типа работника на конвейре.

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

Picture_1216?1356409833
AnthonyBY
– гребец в галеры

+3

>Ну как бы в научном менеджменте уже лет сто назад предположили что работник

Боюсь что основатель научного менеджмента Фредерик Тейлор, с вами бы не согласился. Рекомендую прочитать его работу "Принципы научного менеджмента"(1911) там "о переноске чугуных болванок" весьма поучительно, нужно отдыхать с секундомером и всё такое прочее. То о чём вы говорите — это уже Эдвард Деминг (14 принципов и прочее), в 60х пошло в тайота систем продакшен и др.

Missing
+2

Ок. Может со 100 годами я переборщил, но от основного посыла я все равно не отказываюсь =)

B22cf3b2327970a0352447b567a4841a?1511649146
+13

Я не против посидеть, порассуждать о юзабилити (как известно, все без исключения умеют очень хорошо разбираться в политике, футболе и в юзабитили), повыдумывать новые фичи (желательно позаковыристее и "погиковее" - чтобы пользователь почувствовал себя дураком). В принципе, я могу поучастовать во всех митингах, что проходят за день - не проблема.

Только не надо после просить меня остаться подольше в офисе, когда дедлайн будет поджимать :)

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

Picture?type=square
-3

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

А понимание процесса развития проекта очень важная часть работы любого разработчика иначе вы простите становитесь просто кодером.

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

Или сделаете банально убив в себе всю лояльность и увлеченность конкретным проектом.

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

Picture_1216?1356409833
AnthonyBY
– гребец в галеры

+9

>А почему собственно нельзя потом попросить остаться в офисе на подольше? Вы же сами эстимейтили таски, сами следили за их исполнением, надо было раньше подойдти к руководству и сказать что ребята вот смотрите у нас куча новых митингов на этой неделе, надо сдвигать сроки, что будем делать?

То бишь разработчик должен делать, говорить что делать, а потом ещё идти к менеджменту и вопросы по срокам решать? А если что-то пошло не так, то опять таки разработчик овертаймить должен. Мне кажется что с процессами явно что-то не так.

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

всё правильно говорит. В нормальных процессах таких ситуаций не происходит. Перед тем как взять тикет проводится example mapping или BDD сессия что бы все на одной волне были.

Шутки шутками, но менедежмент с такими подходами нужно отправить лечиться к Agile-сектантам. Ну или не нужно, с такими подходами всё равно компании долго не живут (невидимая рука рынка всё раставить на свои места)

Picture_2702?1356409883
+1

> То бишь разработчик должен делать, говорить что делать, а потом ещё идти к менеджменту и вопросы по срокам решать? А если что-то пошло не так, то опять таки разработчик овертаймить должен. Мне кажется что с процессами явно что-то не так.

Аха-ха... вот не так давно в одной "милой" компании работу работал именно по этому "процессу"...

> ...Ну или не нужно, с такими подходами всё равно компании долго не живут (невидимая рука рынка всё раставить на свои места)

И да, компания в итоге умерла. Все верно, да.

Просто есть одна беда, умирают таким образом не сильно большие компании. С определенного этапа развития "невидимая рука рынка" уже перестает работать. Типа "они сильно большие, чтобы умереть". Клиенты платят больше, внутри компании вводят KPI, начинается "шабаш HR инициатив" и прочий ад... а программеры, которые остались (пришли) в этой системе становятся редкостными пофигистами. Об чем и статья.

B22cf3b2327970a0352447b567a4841a?1511649146
+12

Хм :) Разработчики критикуют уже потвержденные фичи, устраивают саботаж и срывают сроки (в том числе из-за вечно оптимистичных эстимейтов), а менеджмент за это их оставляет на переработки в офисе. Звучит как описание моей "компании мечты".

Как говорил профессор Преображенский в "Собачьем сердце": "Это вот что: если я, вместо того, чтобы оперировать каждый вечер, начну у себя в квартире петь хором, у меня настанет разруха".

Я разное видел пока работаю и на сегодняшний день мое мнение таково: каждый должен профессионально заниматься своим делом + по возможности быть в курсе происходящего вокруг. И конечно же, если у человека есть мнение, то было бы неплохо иметь возможность это мнение высказать (в нужное время, в нужном месте).

Но, повторюсь, основная задача разработчика - разрабатывать. "Вписывать" новый функционал в продукт никогда не сводилось к "просто кодить". Никто менеджера же не просит помочь с разработкой, почему же условные управленцы так любят спихнуть немножко ответственности (за сроки, за "не те фичи", за QA в конце концов) на разработку?

И еще одно забавное наблюдение. В компании есть "просто кодер", "просто менеджер", "просто тестировщик", "просто дизайнер" и так далее. Но при этом из всего перечисленного именно "просто кодер" чаще всего используют в качестве оскорбления :) Синдром "ты ж программист" - он повсюду.

Missing
+2

>> А понимание процесса развития проекта очень важная часть работы любого разработчика иначе вы простите становитесь просто кодером.

Очередная попытка dumb down инженерный процес. Ведь что такое методика разработки программного обеспечения в наше время? Это 100% фокус на менеджменте и 0% на инженерной части. Давайте программиста сделаем ответственным за всех! Ведь он сидит в углу и мало говорит и видимо совсем ничего не делает. Вам надо в agile coaches идти.

Picture_1216?1356409833
AnthonyBY
– гребец в галеры

>Вам надо в agile coaches идти.

due all respect, любой аджайл коуч скажет что овертаймы, плохо описаные тикеты, эстимирование в реальных часах — это большое зло. Поэтому нужно отправлять ... ну не знаю, в белорусское министестерство образование что-ли, там тоже считают что просто учить детей не достаточно, нужно ещё собирать картфоель, делать обходы, и сейчас ещё новая фишечка: проследить чтобы дети с собой калл в школу принесли (мониторинг глистов). Такие многофункциональные, не нарадуются.

Picture_572?1356409814
agentcooper
– PM в Softeq Flash Solutions

+4

Овертаймы и эстимация в реальных часах - куда меньшее зло, чем аджайл коучи :)

Missing
+9

Это новая фишка такая. Давай-ка ты у нас будешь кодить, ещё дизайнить, ещё архитектить, ещё тех-лидить, ещё на все митинги ходить, ещё продакшн-суппорт тянуть, ещё у нас дизайн говно (мы за него заплатили 120 штук, правда) и ты ещё будь добр UI красивше сделай с картинок красивых, ещё мы уволили админов (это модно и называется девопс) и ты будешь админить серваки, ещё помогать по старым проектам, так как сапортить их не могут, потому что не хотят вникать в детали (это же так скушно) и в конце концов сказать "хм, что-то не очень понятно, что ты делаешь там..." и добавить, что незаменимых у нас нет!

B22cf3b2327970a0352447b567a4841a?1511649146
+16

И после 8-ми часового дня с перерывом на обед (под завязку загруженным работой, без катаний на гироскутерах и поигрушках на приставках), приходишь домой, открываешь интернеты, а там:

- Ваши разработчики не хотят работать больше 40-ка часов в неделю? Это не рок-звёзды!

- У ваших разработчиков нет крутых проектов на гитхабе? Видимо, они пошли в профессию только ради денег

- Разработчику уже за 30, а он до сих пор не стал менеджером? Он не хочет выходить из "зоны комфорта"!

Missing
+8

Ничего страшного. Однажды приходит скилл "поржать над придурками в интернете" и пофиг, что они там пишут :)

Missing
-1

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

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

Missing
-4

Статья говно, даже обсуждать не хочется.

Missing-male

>> отклонение или обесценивание идей программиста, особенно в первые несколько месяцев, — это плохой ход

То есть, если новый сотрудник генерирует бред (а так часто бывает потому что он новый), то ему нельзя об этом говорить, чтоб он не обиделся, и не сидел в углу надувшись.

1) Мне кажется, на основании материала из подобных статей можно не один хороший диссер защитить на тему инфантильности у 40-летних мужиков.

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

Missing
+4

/То есть, если новый сотрудник генерирует бред (а так часто бывает потому что он новый), то ему нельзя об этом говорить, чтоб он не обиделся, и не сидел в углу надувшись./

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

Missing-male
+1

Я и не имел ввиду хамство с употреблением терминов типа "бред". В статье речь идет о вполне дипломатичных отказах, типа отсутствия свободного времени или невписывания в планы или еще что-то. Но в следующем предложении "Независимот от причин, это плохой ход". Плохо то, что мир не оценил его гениальности, таски надо делать независимо от их "интересности", а мы все не "одна семья", как было написано в тексте вакансии. Мир рушится, ёпт! Как тут не уйти в себя.

>> нормально объяснить сотруднику почему его идеи не могут быть применимы

На моей практике был случай, когда товарищ отказывался вообще делать работу, пока ему не "объяснят нормально", почему его идеи не могут быть реализованы. Ведь все дураки и говнокодеры, а он умный и в белом пальто.

Missing

/На моей практике был случай, когда товарищ отказывался вообще делать работу.../

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

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

Missing-male
+2

У нас, по видимому, просто расхождение в терминах. Я не говорю, что нужно всем говорить "заткнитесь и пишите код" в первый день работы. И безусловно, инженер должен понимать, зачем он делает то, что он делает, и как это будет использоваться (ну, в идеале). Но речь идет о том, что товарищи начинают генерировать идеи, не связанные с со своей работой (на тему бизнеса, продуктов и прочего), а потом, когда оказывается, что эти идеи не очень в тему, обижаются и демотивируются. Это ж детский сад, ясельная группа.

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

Missing

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

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

Missing-male

Как бы вопрос не в том. Что-то может быть неправильно не потому что все вокруг дураки, а по объективным причинам, в которых нужно разобраться, а не рассказывать всем, как им надо работать. Все заинтересованы в том, чтобы улучшить проект и когда на это появляется время, то о том, что можно было бы улучшить, спрашивают и принимают все идеи во внимание. А просто так генерировать идеи это ни о чем. Вот в этом поинт. Ну и второе, человеку разменяв четвертый десяток вообще не ок думать в категориях "я обиделся". Почему? Потому что это восприятие на личный счет того, что не нужно воспринимать на личный счет. Идеи отклонили не потому что ты не классный или тебя не любят и не ценят, а потому что см выше.

Missing-male
panchesman
– Software Engineer в XB Software

-2

>> если новый сотрудник генерирует бред (а так часто бывает потому что он новый), то ему нельзя об этом говорить, чтоб он не обиделся

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

Missing-male

Всякое бывает, но вообще я писал не об этом.

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

Missing

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

Fbd86b7dabc5c38eb4fc2a1b9ecb3aef?1401052262
+5

Могу писать хороший код. Могу CI настроить, автотесты с метриками прикрутить, кодревью организовать. Могу дизайн и архитектурные документы писать.

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

"заботиться о ценности продукта и бизнеса в целом" — могу, наверное, но.. что это вообще значит и нафига оно мне надо?

Missing

Единственный правильный подход. Респекто.

Missing-male
+1

Однако не редко встретишь 35 комментариев под статьёй в первые дни, значит тема очень живая.

Да, корни лежат в той самой проблеме "говнокода" других программеров, а если ещё глубже расшифровать - мысли о том что ты самый умный и клёвый. Т.е. тот же самый человек который жалуется на "говнокод" других - сам же первым будет подавлять инициативы других. К сожалению, зачастую даже самым продвинутым программерам не хватает широкого объективного взгляда на мир.

Missing
+1

>> К сожалению, зачастую даже самым продвинутым программерам не хватает широкого объективного взгляда на мир.

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

Missing
+4

В статью скромно умалчивается, что у софта есть product owner, и программист должен прежде всего делать софт для него, а не для себя. Новые технологий и подходы, круто, когда начинается новый продукт или новая часть старого, а вот внедрение чего-то нового в уже существующий продукт связанно с рисками для бизнеса. Идеи программистов заворачивают не потому, что они плохие, а потому, что они несут риски для бизнеса или не несут ценности с глазах бизнеса. Для примера переход на новый js фреймворк, может занять около месяца, а это оплачиваемая работа всей команды, и как результат для конечного пользователя ничего не поменяется + это связно с возможностью внесения новых ошибок. Кто будет в случаи ошибки при реализации идеи отвечать за много тысячные убытки бизнеса? Программисту легко сменить работу, а вот для компании потеря заказчика может стать очень болезненной. Хуже всего, что он настроения заказчика зависит не только зп программиста, который выдвигает идеи и их кодит, но и зп, всех остальных членов команды.

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

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

Missing
+3

Ничего не знаю.. погнали лепить новые JS-фишечки! ))

Missing

У нас другая проблема. Есть понимание что изменения нужны, что текущая модель разработки пробуксовывает и это приводит к низкой скорости внедрений запросов заказчиков. Даже простая вещь занимает несколько месяцев. Низкая производительность, странные баги и пр. И надо менять да никто из менеджеров не берёт на себя ответственность и все откладывается и откладывается и откладывается, а проблемы все копятся. Самое интересное менеджеры тоже согласны и высказывают идеи, но они не ответственны за принятие технических решений. Чертова бюрократия.

Missing
+4

"программисты должны не только создавать код, но и заботиться о ценности продукта и бизнеса в целом"

А компании должны не только платить ЗП но и делиться процентом от прибыли с продаж, чего уж там.

Missing
+1

Так в том и обман:) Ни слова об опционах.

Picture_572?1356409814
agentcooper
– PM в Softeq Flash Solutions

+1

Пусть расцветают сто цветов (С) Мао.

Всё ведь так просто на самом деле. Хорошо писать код - нужно, заботиться о продукте, клиентах, бизнесе - нужно. И еще до хрена чего - тоже нужно. Каждый член команды имеет интегральную ценность - есть место и прекрасному кодировщику, и прекрасному генератору идей, и прекрасному менеджеру, и тем, кто сочетает несколько достоинств, не будучи чемпионом ни в одном. Главное, чтобы в результате сложения (а лучше умножения - синергетический эффект никто не отменял) сотрудников в команду все нужды организации были покрыты в достаточной степени - без тонких мест и тем более дыр.


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси