«Разве у тебя нет цикла, который можно написать?»
Самая популярная моя статья называется «Почему ваш программист просто хочет кодировать». К настоящему моменту её прочитали более 62 000 раз.
В статье рассказывается о программисте Джейми, который пришёл в компанию переполняемый энтузиазмом и идеями. Прошло пару лет — и Джейми стал одним из тех, кто «хотят просто кодировать». Одним из тех, кто не предлагает новых идей, новых способов работы — а только хочет, чтобы его оставили в покое, просто писать код.
К сожалению, я не получил почти никакого отклика от менеджеров или руководителей по поводу этой истории.
Похоже, кто-то не понял суть, так что я скажу прямо.
Технические менеджеры, такие ситуации — это ваша вина
Вы несёте ответственность за немотивированных программистов, которые «просто хотят кодировать» и которых, похоже, волнуют только модные новые технологии.
Как руководитель, вы несёте ответственность за создание среды, где каждый может внести свой вклад в решение проблем.
Вместо этого создаётся впечатление, что многих программистов рассматривают как слабоумных всезнаек — вундеркиндов, способных только программировать.
Прекратите это. Серьёзно.
Огромный резонанс той статьи должен напугать вас до чёртиков. Рынок разогрет, что даёт им власть отправить вас в отставку и заменить лучшим руководителем.
Я чувствую, что они сердиты как черти — и больше не собираются это терпеть.
Не верите? Читайте дальше…
Я написал ту статью в надежде, что руководители поймут: программисты стремятся полноценно задействовать свой мозг, но слишком часто окружение мешает им делать это.
Вместо этого я получил тысячи ответов («аплодисменты» на Medium, комментарии и сообщения) от программистов, которые хотят понимания со стороны менеджеров. Хотят, чтобы их культуру принимали, чтобы их идеи обсуждали и оспаривали.
Вот некоторые комментарии, которые выделяются среди всех…
«О господи! Этот феномен принятия в штыки новых идей — главный убийца на всей земле, он вредит каждому отделу (это не только проблема программистов)».
«Когда я пришёл на работу, то был готов изменить мир. Теперь я каждый день изо всех сил стараюсь подавить свои истинные мысли — и просто мириться с тем, как обстоят дела… Я ДЕЙСТВИТЕЛЬНО надеюсь, что руководство скоро начнёт понимать проблему».
«Мне пришлось пройти через нечто подобное, я даже перестал работать над домашними проектами, потому что программирование на работе стало противным и требовательным — я рад, что просто уволился через пять месяцев!»
«Грустно, что культура программирования в моём нынешнем окружении требует от программистов просто завершать задачи, а не думать и делиться идеями».
Комментатор по имени Hasen имеет немного другое мнение.
«Нам не нужно “принятия” идей. Мы должны видеть, что наши идеи обсуждаются и оспариваются, а решение основано на ценности идеи, а не на должности её автора.
Если я подам идею, её обсудят, а затем отвергнут, это нормально.
Если я подам идею, а мне просто скажут, что я не должен этого делать — а следует просто заниматься текущей работой, то это ясный сигнал, что мне разрешено только выполнять приказы, как солдату.
Когда это произойдет, я по сути буду искать другую работу».
Этот последний комментарий подводит итог. Создайте окружение, в котором программисты могут полноценно вносить свой вклад, иначе лучшие из них уйдут.
Будем смотреть на вещи реалистично. Если в команде проблема — её не исправишь за день. НО вы можете предпринять важные шаги для решения этой проблемы.
Приступим к изменениям
Начните слушать и прекратите говорить
Если некоторые ваши разработчики просто хотят, чтобы их оставили в покое, то сегодня отличный день, чтобы всё изменить.
Начните это в следующем разговоре один на один. (Не проводите разговоры один на один? Обратитесь к моему руководству для начала).
Шаг 1: будьте скромным
Начните заново разговор с каждым сотрудником и честно спросите, не были ли вы глухи к его идеям, не рассматривали ли его как «ресурс» и не разочаровывали ли его.
Независимо от ответа скажите, что вы не хотите быть таким начальником и что просите прощения. (Да, всегда хорошо извиниться перед человеком, которого вы могли обидеть. Даже если вы начальник).
Далее скажите, что вам нужна его помощь. Нужно его мнение, чтобы улучшиться. Разрешите остановить вас в следующий раз, когда поступите таким образом — и в приватном разговоре высказать мнение о вашем поведении.
Наконец, поблагодарите за то, что он с вами и делает всю эту тяжёлую работу. Поблагодарите за то, что он вас выслушал и помогает вам превратиться в такого менеджера, который им нужен.
Шаг 2: больше слушайте, меньше говорите
Во всех взаимоотношениях с командой говорите вдвое меньше. А потом ещё вдвое меньше.
Вероятно, это застигнет их врасплох, особенно если вы всегда «наступали с передовых позиций» и раздавали распоряжения.
Вместо этого слушайте, как они разговаривают друг с другом. Как они говорят о клиентах, руководителях или других командах. Кто контролирует поток? Кто до сих пор пытается выдвигать идеи? А кого полностью заткнули?
Посмотрите, можно ли вовлечь всех в дискуссию с помощью открытых вопросов. Подумайте об использовании «говорящей палки», если некоторые товарищи не дают слова другим. Аккуратно дайте понять, что вы хотите услышать мнение каждого по поводу решения проблемы.
Шаг 3: чаще спрашивайте, чем говорите
Большинство менеджеров по разработке привыкли говорить инженерам, как нужно выполнять работу. Вероятно, потому что они сами раньше были инженерами и они «ясно видят решение».
Тем не менее, такие распоряжения не укрепляют команду, а затыкают коллег.
Так что начинайте задавать больше вопросов. Много вопросов «ПОЧЕМУ?» Конечно, придётся подключить любопытство и внимательно слушать ответы.
По правде говоря, от разработчиков зависит выполнение вашей работы и миллион ваших мелких решений. Вы должны очень интересоваться их мнением и обсуждением их идей.
Книга Эда Шейна «Скромный вопрос» — прекрасный ресурс, чтобы научиться задавать лучшие вопросы.
Менеджеры, вам лучше всё исправить, пока не стало слишком поздно.
(Все ещё не убеждены? Почитайте сотни комментариев от разочарованных разработчиков, которые требуют лучших менеджеров, а затем спросите себя: «Не такая ли ситуация у меня?»).
Продолжение: «Выученная беспомощность в разработке ПО»
Комментарии (83)
Penb69
04.03.2018 20:07+2Все чаще встречаю статьи в которых программисты жалуются на свою судьбу(начальство, "тупых" юзеров или, как здесь, плохого РМ).
Однако, работая на стороне разработчиков, а потом на стороне пользователя, могу сказать, что бывают совершенно разные ситуации.
Есть компании, где проект уже в продакшене, и от программиста требуется вовсе не полет мысли, и чудо идеи как бы все изменить к лучшему (по его мнению), а поддержка проекта и реализация нужд потребителя продукта. Причем в короткий срок, что приводит к тому, что все идеи требующие затрат времени как на обсуждение так и на реализацию лишь идеи, воспринимаются как пустая трата времени.
P.S. по моему опыту могу сказать, что при устройстве на работу(либо во время испытательного срока) практически безошибочно можно определить, что от тебя нужно фирме, человеко-ресурс или твои мысли.
Zeitung
04.03.2018 21:38+2А мне пришлось поработать программистом, а потом средним звеном между саппортом (т.е. решал проблемы пользователей, которые не могли быть исправлены саппортом) и командой разработчиков (у меня были задачи для добавления нового функционала, но 60-70% времени я тратил на разгребание проблем юзеров). Компания была стандартной «галерой», но команда в которой я работал была «продуктовой», т.к. работала над одним и тем-же продуктом с начала его разработки.
Работая «изнутри», я понял что куча проблем юзеров — однотипные, но «тривиального» решения, которое можно передать в саппорт, не существует. Решения чтоб устранить целые классы проблем пользователей часто предлагались заказчику. Что-то принималось, что-то откладывалось до лучших времен. Понятно, что при выводе нового продукта на рынок (ака «Стартап»), важно зарабатывать, а баги исправить когда будет финансовая «подушка». И современный разработчик это понимает, принимает и способствует. Но когда проект живёт в таком цикле 5+ лет, то технический долг становиться неразгребаемым.
Поэтому когда Вы говорите, что пользователям нужна «поддержка продукта», то в итоге это приводит к тому, что разработчик занимается не своей прямой работой, а исправлением лажи из-за не правильной… скажем, архитектуры. И не нужно сейчас говорить про то что «архитектура» плохая. Она была заложена Х лет назад с ТЕМИ требованиями, более того, некоторые хорошие идеи были «отложены», т.к. новая кнопочка «нужна сейчас», а как оно работает пользователю\заказчику не важно. Но время никогда не выделялось на доделывание.
В итоге это приводит к тому, что куча ресурсов тратиться на саппорт, эффективность и скорость добавления новых сущностей замедляется, продуктивность и мотивация падает (ну не будет нормальный разработчик в 100-й раз писать скрипт чтоб вычистить юзер-данные).
А еще, когда разработчик предлагает «простое» и «advanced» решение проблемы, часто «advanced» продиктовано личным опытом: всё это он уже проходил на другом проекте\в другой компании и знает, что после этой кнопочки нужно будет ещё 3, которые чуть-чуть отличаются, но чтоб их добавить «потом», нужно будет с нуля переписать самую первую\простую.
VolCh
05.03.2018 09:58Поддержка и медленное усовершенствование — это как раз те области в жизненном цикле продукта, где технический долг особенно сказывается. На этапе разработки и ввода в эксплуатацию можно на многое забить, лишь бы успеть запустить как можно раньше, но надо сознавать к чему это приведёт в дальнейшем.
Eagle_NN
05.03.2018 12:32+1Как бы странно это не выглядело, но руководящий состав все больше становится заложниками в этой игре интересов.
Давайте рассмотрим типичную ситуацию. Есть несколько категорий работников:
1. Есть программист, который получает неплохие деньги и который кипит идеями.
2. Есть руководство (менеджер/директор) который ставит ему задачи и платит деньги из бюджета проекта.
3. Есть продажник, который занят продажей продукта. Ему без разницы как работает кнопочка, ему сам факт ее наличия делает продажи.
4. Есть заказчик/покупатель, который платит денежку за продукт, из которой формируется бюджет.
Теперь вспомним, что зарплата программиста (1.) растет регулярно (он же прокачивается, да и вообще рынок тут растет). Он начинает выламывать руки руководителям (2.) для проталкивания правильных идей, однако он не представляет потребности потребителя (4.).
Продажник (3.) примерно представляет, как та или иная функциональность повлияет на воронку продаж (а значит и на прибыль). Т.е. нужда потребителя (4.) ему сильно ближе. Однако все мы знаем, что на рынке продажников (3.) особого роста нет из-за нереально высокой конкуренции. Поэтому, он либо не доносит вообще эту информацию до руководителя (2.), либо делает это максимально аккуратно, чтобы не потерять место.
В результате руководитель (2.) опять требует от программистов (1.) не полета фантазии, а реализации конкретики, которую он смог понять от продажника (3.) и заказчика (4.). И это реально важно, т.к. он видит, что в противном случае бюджета на зарплату программиста (1.) не хватит.
Система переходит из состояния покоя в маятник, когда руководители пытаются найти баланс между бюджетом, генерируемым продажником (3.) и потребителем (4.) с одной стороны и потребностями программиста (1.) с другой. Отсюда и нарастание технического долга, и неудовлетворенность.
Понятно что схема примитивная, но к реальности она достаточно близка.
maryrus
04.03.2018 20:33Тут прям крик души программистов. Но как написал предыдущий комментатор — «многое завит не от РМ, а от заказчика, его бюджета.» И по моему, не для кого не новость, что крутых классных проектов на которых нужны эти самые идеи, которые по мнению автора руководство не дает высказывать/обсуждать/внедрять, не так уж и много.
Не спорю с автором, все что написано в статье должно применять на таких проектах, где это допустимо с точки зрения бизнеса.
Второй момент, это комментарий, который приводит автор, некого Хасена:
Нам не нужно “принятия” идей. Мы должны видеть, что наши идеи обсуждаются и оспариваются...
И как его итог:
Этот последний комментарий подводит итог. Создайте окружение, в котором программисты могут полноценно вносить свой вклад, иначе лучшие из них уйдут.
Боюсь вы тут абсолютно не правы. Судя по этому комментарию человеку хочется просто поговорить. Потому что, когда у меня возникает идея, и я считаю что она достаточно стоящая, чтобы дергать руководство на ее обсуждение, я жду что ее хотя бы на оценку к аналитикам отправят, но уж точно не отвергнут.
SirEdvin
04.03.2018 20:50Звучит так, как будто ПМ не имеет никакого отношения к решениям, которые принимает заказчик.
kenny_gomel
04.03.2018 20:33+1Вот почитал статью и порадовался за своё текущее место, т.к. у нас практически полная автономия и тимлид старается для команды.
А если бы не было автономии и разнообразия из задач, которые просто нужно сделать как сказали и в которых можно проявить инициативу и фантазию, я бы наверное уволился спустя полгода — год, если бы никто ничего не захотел менять.
DexterHD
04.03.2018 21:26Менеджеры для программистов стали ответом на бурный рост кол-ва программистов, настолько бурный, что средний стаж в индустрии стал равным нескольким годам. При зарождении отрасли программисты были довольно хорошими спецами, их было мало, они были профессионалами в своей отрасли и им не нужны были менеджеры. Рано или поздно наша отрасль вырастет и все эти менеджеры отправятся на улицу. Останутся только менеджеры вышедшие из программистов и собственно сами программисты. :)
Serg046
05.03.2018 00:04Странный комментарий. Сначала он сообщает, что раньше программисты были профессионалами в своей отрасли. А потом, что им, почему-то, не нужны менеджеры.
DexterHD
05.03.2018 11:57Изучите историю, программисты вышли из разнообразных прикладных областей. Лишь потом разработка ПО выросла в отдельную отрасль. В своей области имеется ввиду, что программисты вышли из банкиров, математиков, физиков, инженеров, военных и т.д. Данная отрасль не возникла на пустом месте и изначально вычислительные машины решали исключительно прикладные задачи. Только спустя много лет они стали пригодны для того чтобы лайкать котиков. К тому моменту число программистов возросло экспоненциально и в отрасли стало 90% людей чей трудовой стаж менее 5 лет. Назовите хотя бы еще одну такую отрасль в современном мире? Современные менеджеры и РП как правило из личного опыта не являются специалистами ни в IT ни в прикладной области в которой они руководят, возникает резонный вопрос, нафиг они нужны?
i86com
05.03.2018 13:13Современные менеджеры и РП как правило из личного опыта не являются специалистами ни в IT ни в прикладной области в которой они руководят, возникает резонный вопрос, нафиг они нужны?
Чтобы не тратить дорогое время и внимание нескольких программистов на задачи, с которыми может справиться один менеджер — переговоры, присутствие на совещаниях, контроль сроков, написание отчётов, координация усилий.
Если говорить о менеджерах-неспециалистах, то их зарплата часто намного ниже зарплат специалистов, с которыми они работают.
imikh
05.03.2018 09:59Ничего подобного. Тот же «Мифический человеко-месяц» Брукса как раз рассказывает про работу менеджера проектов, причём действие происходит где-то в 70х годах. Никогда менеджеры не исчёзнут. Востребованность их только растёт, и не только в ИТ сфере.
DexterHD
05.03.2018 11:59Только вот Брукс «учёный в области теории вычислительных систем». Они изучал физику и прикладную математику. А современные менеджеры 20-30 лет в большинстве компаний они кто? Они какое отношение имеют к IT? Многие из пользоваться компом на уровне продвинутого пользователя не умеют.
SandDanGlokta
05.03.2018 13:46+1Вообще не согласен. Каждый должен заниматься своим делом. Слишком сложно стать профессионалом во ВСЕХ областях. Это из разряда «Нам нужен фронтенд разработчик, который настроит нам сеть в холдинге, напишет крутой сайт, наладит работу 1С и создаст десктоп приложение на Java». Любой адекватный айтишник воспримет такое требование как бред сивой кобылы. Потому что каждая из этих задач для качественного решения требует глубоких знаний в своей области. Точно также глупо говорить, что из хорошего программиста получится хороший менеджер. Это совершенно разные области, требующие разных навыков и компетенций. И это в обозримом будущем не поменяется. А как раз наоборот. Чтобы быть хорошим программистом в будущем, придётся ещё сильнее погружаться в новые технологии. И уже не будет достаточно времени, чтобы повышать навыки в области менеджмента.
Мне кажется, что у тебя несколько снобистская позиция. Дескать программисты эдакие гении, а менеджеры обычные дармоеды. Это как мерить среднюю температуру по больнице. Потому что есть и хреновые программисты, и замечательные менеджеры. И утверждать, что одни смогут заменить других, мне кажется слишком самонадеянно.DexterHD
05.03.2018 17:09Моя позиция в другом. Парень который вчера продавал компы в Эльдорадо не может управлять командой инженеров, ни программистов ни авиаконструкторов ни какими либо еще. Командой инженеров должен управлять менеджер-инженер. Командой банкиров менеджер-банкир. Командой архитекторов менеджер-архитектор.
Менеджер-банкир знает основы банковского дела, а менеджеры IT-шники по крайней мере из тех с которыми я сталкивался, «Hello World» написать не могут. Что не скажешь о других областях. Когда я работал на производстве инженером по автоматизации мой менеджер мог и проект разработать и напряжение поменять и программу для ПЛК написать и я считаю что любой другой менеджер должен выйти из сферы в которой он руководит. Вот моя позиция.
PS На производстве тоже попадались дурачки которые только закончили ВУЗ и сразу сели «начальниками». От них были только проблемы, которые приходилось решать за них их же подчиненным. Потому что они только в теории и на бумажках знают как устроен мир, но увы в реальности мир устроен иначе.
viras777
04.03.2018 21:51Возможно, если заказчик и исполнитель одно лицо, то возможности пофантазировать разработчику будет поболее. Он, заказчик, сам определяет сроки и функционал решения, в котором программисты не просто кодеры, а люди обязанные разбираться в предметной области, для чего пишется программное решение.
lexore
05.03.2018 02:05А это разве проблема "программист — менеджер"? В отношениях "синьор — джуниор" такой проблемы нет, все друг друга слушают?
Areso
05.03.2018 08:24+4Если джуниор скажет толковую вещь, то его похвалят и обязательно это отметят. Затыкать джуниора смысла нет, наоборот, есть смысл джуниору дать высказаться первым — чтобы он предложил решение, как он его видит, а потом ему сказали правильное решение или скорректированное коллегами. Если его предложенное решение достаточно хорошо — флаг в кулак, на шею барабан и вперед реализовывать. Более того, сегодняшний джуниор через год будет вполне себе специалистом чуть ниже среднего, и если он в команде останется, то лучше уважительно относиться к нему с первых дней.
alek0585
05.03.2018 16:08Если джуниор скажет толковую вещь, то его похвалят
В фантазиях ждуниора так и будет)
Color
06.03.2018 13:08Ой, да ладно вам! Что за отношение к джуниорам (которое, кстати, часто встречается в саркастическом контексте) как к дебилам?
Между коллегами всегда должно быть уважительное рабочее отношение, независимо от того, кто какую позицию занимает. Если человек с малым количеством опыта предложит отличную идею (идею, заметьте, а не план ее реализации), она от этого станет хуже идеи, предложенной опытным сотрудником? Или такой человек достоин похвалы меньше, чем порицания?alek0585
07.03.2018 02:40Я откуда знаю? Сколько наблюдал — всегда идею посылают вместе с джуниором. Даже если идея хорошая. Но если очень нужно реализовать эту идею, то применяется хитрый трюк) Просто эту идею еще раз предлагает кто-нибудь поближе к начальству(то есть повыше рангом-должностью). И этому человеку может даже и премию выпишут. А джуниору нет. Вы прям как с луны свалились, честное слово. Не знаете что ли как дела делаются?
Конечно, это неправильно и человек достоин похвалы и так далее. Но так не везде. Увы.
ту-ду
Kwisatz
05.03.2018 08:18Когда я пришёл на работу, то был готов изменить мир. Теперь я каждый день изо всех сил стараюсь подавить свои истинные мысли — и просто мириться с тем, как обстоят дела… Я ДЕЙСТВИТЕЛЬНО надеюсь, что руководство скоро начнёт понимать проблему
Очень знакомо, испытываю такое в каждой компании. Первый раз решил проблему радикально: стал ком директором, что позволило мне принимать решения без оглядки на кого бы то ни было.
Хотя в некоторой степени стало еще хуже. Многие аспекты жизни предприятия стал понимать намного лучше. В итоге наступать себе на горло все же нужно, ибо все сами сильно умные 8(
orcy
05.03.2018 09:23+4Мне приходится часто заворачивать идеи разработчиков и вот почему:
- За новой идеей разработчика может мотивация которая не совпадает с целями проекта. Например он говорит «давайте сделаем это как микросервис на го», в то время как весь остальной сервер это java, C# или python. Мотивация разработчика в том что он недавно изучил Go, и он ему понравился. Менеджеру с небольшой командой может быть тяжело поддерживать зоопарк языков.
- Не всякий разработчик опытный настолько чтобы предлагать что-то обдуманное и долгосрочно хорошее. «Давайте добавим нам tarantul, mongo, nodejs, kubernetes для этой фичи». «Я тут почитал хабр и хочу использовать <икс>.» Может ли разработчик трезво оценивать и выбирать решения или это на уровне импульсов.
- Разработчик предлагает идею, но ответственность не несет. Не он будет разгребать негативные последствия реализации этой идеи, он может вообще сказать «ой, я пошел на новую работу, всем пока».
При этом я согласен и с этой цитатой: «Мы должны видеть, что наши идеи обсуждаются и оспариваются, а решение основано на только на ценности идеи, а не на должности её автора»
Надо вовлекать людей и обсуждать предложения, а не просто бросить «нет, мы это не делаем». На мой взгляд не надо говорить сразу «мне не нравится это идея». Есть более человеческий способ того чтобы человек получше подумал, спросить например «а что мы будем делать с <икс>». Правда проблема с некоторыми людьми остается: они не учатся генерировать идеи хорошего качества и их энтузиазм теряется.jetcar
05.03.2018 09:58разработчик разработчику рознь, опытные не начнут предлогать малоизученные технологии, джуниоров же и так никто не будет слушать, ведь нужно в первую очередь убедить опытных, кроме негативных последствий у любого подхода есть и позитивные именно поэтому его и выбрали, ну и да ответственность на менеджере не сильнее чем на разработчике, любой может уйти на новую работу, оставив всё как есть, разгребать последствия кстати менеджер не будет, а будут разработчики, так что это они в первую очередь пострадают
Oxidant
05.03.2018 10:06+1Вы мне кажется плохо представляете чем заняты PM. Подобные факапы будут разребать ПМ и только потом разработчики, так как ПМ несет ответственность за команду и принятые решения касаемо проекта. Так что какое бы решение не было принято, плохой всегда ПМ, но не команда.
n1ks2n
05.03.2018 14:13Это ж как у вас построен процесс, что программист не отвечает за свои предложения и реализации? Ок я согласен, если было принято стратегическое решение всей командой, то ответственность распределяется на команду, то бишь на ПМ, Тим Лидов и линейный состав, да при таком распределении больше спроса будет с ПМ и Тим Лидов, но опять же неудачные решения должны быть отсечены опытными участника ми команды. Плюс ведущие разработчики должны понимать нужды бизнеса и обкатывать новые идеи только в рамках новых микросервисов, если есть такая возможность. А то уж очень однобокая у вас позиция получается. Мол программист за свои идеи не отвечает, следовательно право голоса у него урезано, да и в общем то вся власть у меня, как у ПМа, так что забудьте друзья про инновации =) Я согласен с вами, что внедрение технологий должно иметь бизнес мотивацию — например сокращение накладных расходов, ускорение критичных мест, улучшение масштабируемости, сокращение технического долга. Опять же крайне печально, если ваши разработчики такого не понимают, а хотят лепить технологии ради технологий — тут кстати может быть и проблема обучения разработчиков. Во всяком случае ни когда я работал ПМом, ни когда перешел в ряды разработчиков не было даже идеи о том, чтобы влепить новую технологию без бизнес-обоснования. Да и за коллегами такого не замечал.
Oxidant
05.03.2018 10:04+1Согласен с большинством сказанных примеров. Очень часто «идеи» генерируют джуниоры ( хотя бывают и исключения увы), которые соответственно начитались умных примеров со стек оверфлоу и в полностью пхп проект предлагают встроить нод.жс только потому что он вчера о нем прочитал и это же так круто. Может быть, но не здесь и не сейчас. Так же надо отделять «Хорошие идеи» в том проекте где они подойдут от «говнокода», который «генератор идей» считает лучше только потому что никогда не сталкивался с такой проблемой ранее и соответственно нести ответственность за который он не намерен ведь ему «разрешили» его использовать.
Marui
05.03.2018 09:59+1Менеджеры это люди, которых нанимает начальство чтобы не общаться с этими вашими программистами.
Менеджер не заставляет программиста работать, но они любят так считать. Работать заставляет нужда есть и ночевать.
proxykon
05.03.2018 09:59Скажите, а не бизнес ли заказчик софта?
OK, если бизнес то мы программисты обслуживаем его(бизнес).
То же делает и секретарша, занимаясь документооборотом!
Не так ли?
Что получиться, если в этой статье слово «программист» заменить на слово «секретарша»?
Да, все будут крутить у виска!
Не нужно возводить разработку софта в ранг Высоких материй.
Без конечной бизнес идеи, ради которой и разрабатывается софт, разработка софта бессмысленна!
Muxto
05.03.2018 12:20+2Вы, наверное, менеджер?
Труд разработчика в большинстве случаев требует гораздо большей квалификации, чем секретаря.
И когда квалифицированный хорошооплачиваемый работник предлагает идеи, он ждет конструктивной критики, а не каких-то отмашек.SandDanGlokta
05.03.2018 14:22-2Ключевое тут то, что он квалифицирован в своей области. А собственник квалифицирован в области ведения бизнеса.
Если взять гипертрофированный пример, то это как если бы выдающийся деятель в области палеонтологии давал бы советы строителям как строить дома.
Это я к вопросу о том, что квалификации далеко не всегда играет ключевую роль.Muxto
05.03.2018 16:35+1Если взять гипертрофированный пример, то это как если бы выдающийся деятель в области палеонтологии давал бы советы строителям как строить дома.
Некорректный пример.
Зачем строительная фирма заводит себе департамент палеонтологии, дает ему задачи, а потом не слушает советы?SandDanGlokta
06.03.2018 08:26Так эта строительная фирма и даёт этому условному палеонтологу задания раскладывать косточки динозавров по полочкам в кабинете генерального директора. А не спрашивает советы в каком месте и какой глубины рыть котлован под торговый центр. Может этот пресловутый палеонтолог и думает, что знает больше, чем директор фирмы, но зачастую это далеко не так.
Muxto
06.03.2018 12:04Но директору не нужно знать, где рыть котлован, его задача — чтобы фирма была прибыльной и не нарушала законы.
Вы правда считаете что рабство самая эффективная форма управления?
LynXzp
05.03.2018 20:09Ключевое тут то, что он квалифицирован в своей области. А собственник квалифицирован в области ведения бизнеса.
Да, но программист зачастую не может быть просто квалифицированным в одной области. Как-то сравнивали программирование с переводом с человеческого на машинный. Так вот как можно переводить если не знать предметной области? (Переводить то можно, но все мы знаем как это потом получается)SandDanGlokta
06.03.2018 08:32Точно также всякие менеджеры и руководство не ограничивается одной областью знаний. Мне кажется излишне самонадеянно считать, что одни только программисты самые умные и любознательные. Как будто если человек работает не в сфере IT, то он априори унылое говно. Есть куча областей знаний, никак не связанных с технологиями, но оттого не менее важных.
Да, зачастую среди менеджеров встречаются круглые дебилы. Но это не значит, что все менеджеры идиоты. Также и среди программистов встречаются говнокодеры с синдромом вахтёра. И это опять не доказывает, что все айтишники зажравшиеся снобы.LynXzp
06.03.2018 13:50Также и среди программистов встречаются говнокодеры с синдромом вахтёра. И это опять не доказывает, что все айтишники зажравшиеся снобы.
Две противоречащие друг другу фразы.
Так же прошу заметить что я ничего плохого про менеджеров не говорил. В одной компании все примерно одинакового уровня запущенности. И каждый специалист и занимается своим делом. Но одно и то же с разных мест видно по-разному. И ВСЕГДА неслушать программиста вредит не только программисту, но и бизнесу. (Я если честного такого не встречал, мои идеи, наравне с идеями других сотрудников точно так же обговаривались, часто после неправильных идей мне потом читали азы предметной области которые я пропустил, и наоборот, если другие идеи невозможно реализовать я объяснял со своей стороны. Точно так же некоторые идеи безоговорочно внедрялись вне зависимости кто их придумал.)
Kwisatz
05.03.2018 21:29А собственник квалифицирован в области ведения бизнеса.
Как минимум в 50% случаев это не так.
michael_vostrikov
07.03.2018 07:04Ключевое тут то, что он квалифицирован в своей области. А собственник квалифицирован в области ведения бизнеса.
Ну так а что мешает сказать в ответ на идею "Ты не учитываешь то-то и то-то, поэтому мы так делать не будем"? Об этом речь, а не о том, что все предложения программистов надо принимать.
ankh1989
05.03.2018 13:59Программист это скорее строитель или плотник. Но поскольку количество строящихся домов и небоскрёбов заметно превышает количество строителей — стоят они дорого.
constantinnosov
05.03.2018 09:59-3Программирование/разработка это всего лишь ремесло, пусть и достаточно новое.
Программисты априори не должны лезть дальше чем того требует задача или руководитель, по этому нравится это кому то или нет, никого не волнует.
Если такой расклад не устраивает, пожалуйста, собственный бизнес, собственные проекты и делай что хочешь, если ума хватит.Murat1992
05.03.2018 13:07Ваш подход приводит к программистам, которые «просто хотят кодировать».
Суть статьи в том, чтобы улучшить «бизнес», вовлекая разработчиков проявлять инициативу.
mirrr
05.03.2018 21:18Хуже, когда своими попытками мотивировать, менеджмент превращает кодеров в ребят, которые не хотят кодить.
VolCh
06.03.2018 10:16Программирование как реализация алгоритмов, их кодирование на одном или нескольких ЯП — ближе всего к ремеслу, да. Но программирование как создание программ, как разработка ПО — гораздо большее. Это, как минимум, инженерная деятельность.
aikus
06.03.2018 17:35Ну не совсем.
Даже в советские времена дельные рац. предложения от рядовых сотрудников принимали.
Другое дело, что предложения должны быть «рац.» А они не всегда такие.
dgstudio
05.03.2018 10:50В цитатах программистов детский сад какой-то, «я рад, что просто уволился через пять месяцев» — да ты должен был встать и уволиться через 5 минут, дурак!
fr33z3
05.03.2018 14:52+1Не все любители встать и уйти. Некоторым людям свойственно, оценивать, принимать взвешенные решения. Иногда жаль покидать проект, который ты поднял с нуля и вложил туда очень много сил. Так что, ситуации бывают разные. С моей точки зрения, встать и уволиться через 5 минут — это как раз таки детский сад. А вот если говорить про работу в Германии например, то тут встать и уволиться через 5 минут вообще не получится — notice period 3 месяца.
laphroaig
05.03.2018 11:51После прочтения этой статьи у меня сложилось впечатление, что автор сам рассматривает многих программистов:
как слабоумных всезнаек — вундеркиндов, способных только программировать.
amarao
05.03.2018 11:56Тут ещё такой момент, что все идеи программистов по техническому решению интересных проблем (которые могут стать прорывными решениями) — это инвестиция. Получится или нет — не понятно, а процесс сбивает.
Просто это разные рабочие места. Послушные кодеры которые идут и пишут что сказали (не пытаясь) умничать — тоже ценный ресурс.
В советском лозунге — от каждого по способностям, (дальше не важно) упор стоит на «по способностям». Хорошая работа должна подходить характеру.VolCh
06.03.2018 10:12В советском лозунге не имелось в виду "от каждого по его наиболее выдающимся способностям". Способен землю копать — вот лопата и копай Беломорканал. Способен самолёты конструировать — вот "шарашка" и конструируй. Партия решит, какие из твоих физических и интеллектуальных способностей ей нужны здесь и сейчас.
odissey_nemo
06.03.2018 19:00Со слов антисоветчиков и не такого можно прописать. А на деле, которого в СССР было качественно больше чем в РФ, по вполне объективным причинам, программист и станочник оба обладали абсолютно равными правами и работа их варьировала по интересу. И программист мог программировать отчёты Госстата на ЕС ЭВМ, а станочник мог изготовлять АМС «Венера-№».
Партия в СССР, невзирая на прогрессирующую деградацию, жить народу не только не мешала, а ещё и помогала. Задача у ней такая была, поставленная дедушками Лениным и Сталиным. От этого она и стремилась отвязаться. И отвязалась, через Горбачёва и Ельцина. И сегодня их наследники бдят, чтобы страна не развивалась, была не самостоятельной. Станочники исчезли практически, программисты все перешли на задачи западных компаний создаваемых с помощью чисто западных продуктов.
А главный принцип капитализма всегда был «Максимальная личная прибыль любой ценой». Как для хозяина средств производства, так и для его тёмной рабочей силы, обслуживающей его средства, будь то станок, или клавиатура.VolCh
06.03.2018 20:13Как же по интересу при наличии института распределения? Закончил институт — будь добр работай по диплому, а не станочиником и всё равно на твои интересы партии. А при Сталине так вообще прикрепления к предприятию практиковались, по собственному уволиться нельзя было, а на другое предприятие перевести могли согласия не спрашивая.
odissey_nemo
07.03.2018 16:10Про сталинское время ничего сказать не могу конкретно. Но ничего про эту систему ни один из знакомых старшего поколения не произнёс ни слова, хотя возможности в том, более чем свободном обществе (по современным меркам, ПМСМ), имелись.
Институт распределения в 80-е был более чем гибок, по личным ощущениям и опыту. Вполне могли и учесть обстоятельства. Всё было (в конце советской власти! а ведь уже чувствовалось. что человечность то убывает!) по человечески. В любом случае, на порядок человечнее, чем сегодня. Так, я получил распределение свободное, куда хотел. Были обстоятельства, чем-то пришлось пожертвовать, но зато осталось воспоминание на всю жизнь о работе в коллективе, занятом создание системы приёма и обработки наземного комплекса приёма и обработки сканерной спутниковой информации трёх уровневой (космос-самолёт-земля) системе в народохозяйственных-целях.
Другие сокурсники отработали по 2-4 года там, куда послали в счёт бесплатной учёбы в бесплатном ВУЗе государством обеспеченного качества обучения. Ни один ни разу не заикнулся о суровых лишениях или личной обиде. Некоторые пошли в армию, офицерами метеорологической службы, чтобы не работать там, куда их распределили.
Собственно, распределение тех времён, с т.з. зрелого возраста и жизненного опыта, было и будет (но не есть сегодня) признаком системы, где нужны люди, нужны средства и где есть внятные и глубоко продуманные задачи и планы масштаба страны и планеты Земля. Сравните с личными амбициями и фантазиями отдельных атомов нестройной массы населения, которую и народом то назвать сложно, из за хаотичного искусственно поддерживаемого хаоса мнений по мириадам тупейших разногласий.
mclander
05.03.2018 12:21+1Работал я в одной конторе занимающейся компьютерными играми. Когда обсуждали монетизацию игроков, то меня не слушали. Ну как же — ребята в бизнесе куда больше меня. То что я единственный среди команды был «по ту сторону баррикад». То есть не просто много играл в разный фритуплей, но и не стеснялся донатить, как-то не учитывалось ))) Меня обзывали циником и говорили, что «их игроки не такие».
В итоге, мои предложения принимались, эдак через месяца три. Как правило, как идеи кого-то другого. А игра тем временем имела проблемы с монетизацией и, в итоге, продалась за бесценок конкуренту. А недавно проект вообще был дропнут.hd_keeper
05.03.2018 15:17+1Ну и отлично. Игры со встроенной монетизацией — практически чистое зло.
gohan
06.03.2018 09:14+2Есть разные модели монетизации. Если там чисто косметические штуки без влияния на геймплей, то пожалуйста. Но это же сложно, это надо ещё рисовать, анимировать, а продажа «крутости» зачастую просто рисование циферок в текстовом редакторе — ноль времени и ресурсов тратится на такое. Такие игры, конечно, должны гореть в аду вместе с разработчиками.
mclander
06.03.2018 12:12+1Косметические штуки без влияния на геймплей как раз никак не продавались) Хотя это была одна из тех вещей, в которую я таки верил… до начала продаж. У нас была классная атмосферная игрушка с хорошим добрым комюнити. И мы (и даже циничный я) верили, что сможем заработать на косметике. Ага, конечно ;) После этого я стал ещё циничнее.
На самом деле, я вижу только пользу в том, чтобы в игрушках можно было купить за реал то, что можно задрочить. Конечно, логично, что дети и студенты у которых полно времени должны иметь преимущество в игре. Они же потратили время и силы на развитие.
Но я работаю, зарабатываю. И мне проще купить расходники за реал, чтобы спокойно поиграть несколько часов вечером. И совсем неохота за свои деньги отхватывать от задрота, который убил неделю на то чтобы получить +1 в характеристики от бешеной ачивки (а он убил далеко не одну неделю своей жизни).
Плохо, когда в игре нет возможности, пусть и с большими усилиями получить тоже развитие, что доступно за реал. С другой стороны, ни чем не лучше, если можно получить развитие недоступное реальщику. Подписка работает плохо. Просто доступ к игре игроки не готовы покупать. Поэтому в подписку «насыпают» рулезов, что по сути тот же фритуплей.
Поэтому приход денег в игру в русскоязычном пространстве — это покупка игровых преимуществ. И если такая покупка не приводит к ожиданиям игрока, то игра загнётся от недостатка финансов (сейчас я говорю не о руле, а только о равных возможностях за деньги).LynXzp
06.03.2018 13:57можно было купить за реал то, что можно задрочить.
Простите, но если в игре нужно что-то майнить, лутить или иным способом задрачивать как Вы выразились — сразу удаляю, даже если игра понравилась — удаляю через силу, потому что это плохая игра, уничтожающая время, превращающая игрока из человека в крысу нажимающую педаль стимулирующую центр удовольствия.
И, уж простите, но ставлю оценку похуже.mclander
06.03.2018 16:05Тут другая проблема — в людях «выедающих» контент. Ты делаешь игру с циклом на 6-8 месяцев из расчёта, что люди будут играть 15-20 часов в неделю максимум. А получаешь товарищей, которые играют 15 часов в день… минимум. В итоге они весь контент проходят за месяц — вылезают на форум и начинают вопить, что админы ленивые ослы.
Приходит инвестор/директор и спрашивает «вы что действительно ленивые ослы?». И что делать? Качественный контент делается не быстро. В итоге тупо режется экспа и увеличиваются объёмы квестов. Насыпаются тупые «горизонтальные линейки», просто чтобы занять задротов… В итоге,… это плохая практика, но так оно и есть.
На эту тему я давно собираюсь написать статью. Может таки и соберусь)LynXzp
06.03.2018 16:08Спасибо, печально. А я на удивление наоборот люблю игры которые за пару дней можно пройти.
eldog
05.03.2018 12:32Не могу полностью разделить эмоциональный накал статьи. Я, как разработчик, работал в разных компаниях, и тех, где идеи принимались, и тех, где они были совершенно не нужны. Разумеется, приятнее работать в первых. Но самореализация программиста является задачей менеджера ровно постольку, поскольку способствует эффективной работе. И то, что автор описывает как loose-loose в каких-то ситуациях может на самом деле быть win-loose — в пользу менеджера и компании. Менеджер программисту не отец родной, его задача обеспечить эффективную работу, а не творческий расцвет сотрудника.
mclander
06.03.2018 12:13Ну да, есть такие фантазёры, что… лучше бы они просто работали. Для всех лучше.
lxsmkv
05.03.2018 14:29У нас в багтрекере есть категория improvement request. Пишешь, обосновываешь — и время не тратится на болтовню, и мысли в письменном виде стройнее, и требования к написанному строже, (как минимум должно быть обоснование) и все это на веки-вечные, публично для всех видимо. Всегда можно сослаться на свои заявки, ведь они задокументированы.
engine9
05.03.2018 16:07We need to go deeper. Давайте подумаем почему человеческие ценности (уважение к труду, радость сотрудничества, удовольствие от решения сложных задач и т.п.) разбиваются о корпоративный гранит. Разгадка простая —
безблагодатностьпотребительская эгоцентрическая парадигма. Менеджерам не хочется вникать в созвучие фибр тонкой и глубокой программистской души, так как на кону продвижение по иерархии и доступ к кормушке.
Не подумайте, что я хиппи-антиглобалист, вовсе нет. Призываю лишь чуть чуть «подкрутить» жизненные приоритеты. И оценить, что человеческое сотрудничество и благодарность дарит ощущение полноты жизни, которое не купить. И именно по этому в начинающих фирмах как правило атмосфера намного лучше, душевнее.
cheripocker
05.03.2018 18:17Никто не будет слушать человека, который не может заставить себя слушать.
Это естественный отбор, эволюция такая.
Свое решение надо уметь обосновать, добиться одобрения, и важно (!) и после защищать его от нападок и попыток отмены / отката.
Если не автор решения, то кто же еще это будет делать??
Ну в общем «критикуешь — предлагай». Вместо программиста и менеджера можно вставить «рабочего — прораба», «главврача — доктора», и т.п. Наивно думать что это проблема уникальна.
Конечно бывают клинические случаи, или просто нововведения реально не нужны в компании — ну так ты же программист, найти новую работу тебе это 2 дня работы.mclander
06.03.2018 12:14Ещё вариант. Сделать по своему. Но не всегда прокатывает )
cheripocker
07.03.2018 13:47Это кстати вполне годный вариант. Когда ты приходишь с готовым решением, и четко говоришь какие есть плюсы и какие минусы, но все уже готово. Как говорится лучше извиниться после, чем не сделать вообще.
Но тут как — если ты таким образом генеришь хорошие решения — то молодец, тебя заметят. Иначе попросят не портить код в будущем без согласования. И это может привести к написанию подобных статей.
Например если ты генеришь решения которые не совсем целям компании служат, и реализуешь их без обсуждения. К примеру потратил втихаря неделю чтоб ускорить код на 30%, в то время как вся команда пытается реализовать новую фичу, заваливая дедлайны, а со скоростью и так все было ок и запас есть.
gavrilovm
05.03.2018 18:17Не думаю что программисту стоит вмешиваться в продакт, например предлагать какие-то фичи в проекте или говорить как должна работать фича. Если хороший сотрудник продакт-мэнэджер который всем этим владеет и он должен отвечать на эти вопросы и говорить что да как. И в то же время продакт мэнеджер не должен говорить как та или иная фича должна быть реализована, какие технологии зайдействованы и т.д. потому что есть тим-лид проекта у которого есть команда. Если проект большой то в нем есть еще и архитектор который отвечает за вопросы подобные выбору технологий для реализации фич. А программисту остается просто реализовывать то что обговорено с клиентом используя технологии которые предложены тим лидом и/или архитектором проекта. Так работают большинство успешных компаний.
isironn
05.03.2018 18:17Это проблема талантливых кодеров. Им нравится писать. Им нравится писать ради кода. Это как кузнецы, которые куют доспех.
Ошибка менеджера запрещать им этим заниматься.
Я за индивидуальность в человеке. Если направлять команду в русло: «Ты гребец №15 на нашей галере, у тебя рост 170, вес 70 кг. Ты должен грести», то через некоторое время ты получишь отличных гребцов, которые во время нападения пиратов будут дальше грести. Им нельзя будет дать в руки оружие, они не будут знать как им пользоваться. Так же и кодеры: код, новые рюшки, технологии- вещи которые влияют на развитие его как профессионала и личности будут отброшены. А подавление личности копит негатив в сторону работодателя и менеджера. Как следствие- уход или деградация. Развитие личности и кто знает, сотрудник, который завершил проект несколько лет назад вернется к вам опять- помогать его реализовывать.
aikus
05.03.2018 18:17Какая-то однобокая статья. Из-за чего складывается двойственное чувство. Вроде, написано всё по делу, и надо срочно брать на вооружение. С другой стороны раскрыт вопрос только с точки зрения разработчиков.
Ну хорошо, обсуждать будем. Был у меня сотрудник, который тратил по 4 часа времени своего руководителя на пропихивание гениальных идей. Некоторые были очевидными и обсосанными командой со всех сторон. Но 99% были не жизнеспособны. На некоторых мы сильно обожглись. Но даже объективное тестирование ему не помогало, и он продолжал стоять на своём. Вот если б он от нас не ушёл, мне надо было бы извинение у него просить, что я к нему не прислушивался? И, что ещё важнее, после траты моего времени на один рабочий месяц мне надо было бы прислушиваться к его идеям?
Ok. А идеи переписать всё на язык X надо обсуждать? А если у нас разработчиков на этом языке нет вообще? Или можно просто сказать: «Чувак, у нас на X пишешь, только ты. А только вот в этом модуле 100500 строк. Мы переписывать не будем, т.к. долго и дорого»?
По моему, было бы клёво, если б разработчик, до того как произнесёт своё предложение, немного его обдумал. Как он сам это делать собирается.
Одним словом, истина оказалась не в крайностях.
lotse8
05.03.2018 18:38Эта проблема всегда была и всегда будет.
Заказчику надо просто покрасить дверь в белый цвет. Приходит талантливый Пикассо и начинает грузить всех идеями, как эту дверь можно разрисовать. Но заказчику нужно просто покрасить дверь в белый цвет, ему не нужна картина на двери.
И бОльшей частью заказчики такие. Что делать с этой командой, состоящей из одних Пикассо?
Возможно я ошибаюсь, но мне видится это дело так:
— на типовые проекты заказчиков брать бригаду маляров
— а Пикассо лучше не насиловать себя типовыми проектами, а идти в стартап или самому его организовывать
Тогда все будут на своих местах и все будут довольны.VolCh
06.03.2018 12:36Есть заказчики, которым не нужны типовые проекты, им нужны конкурентные преимущества. Кроме того, слово "заказчик" очень широко можно трактовать, а можно очень узко. В продуктовой компании есть заказчик? В аутсорс-компании, которые решает бизнес-задачи, а не работает по готовому ТЗ?
lotse8
06.03.2018 22:22Заказчик — это кто заказывает или покупает. Клиентом назовите, если заказчик не нравится. Это не принципиально. Принципиально, что есть кто покупает.
Да, у кого деньги есть и кто готов платить за конкурентные преимущества, тому эти конкурентные преимущества можно делать. Но эти конкурентные преимущества делаются не на уровне программирования и кодирования (разве что оптимизация кода), а на уровне продукта и ТЗ. Если программист хочет быть одновременно и продукт-менеджером, писать сам ТЗ и одновременно программистом — не вопрос, таких надо только приветствовать, которые двойную работу делают за одну или полторы зарплаты. Но если программист не хочет быть продукт-менеджером, писателем ТЗ, тогда надо делать то, что написано в спецификации. Вопросы по ТЗ спецификации конечно приветствуются, потому что ТЗ из головы на 50 страниц написать и нигде не ошибиться — это редко кто сможет. Да, можно это красиво закодировать, но кроме тимлида это никто не оценит. Бизнесу без разницы, что там под капотом, лишь бы не падало и свои функции выполняло.
MaratPro
Я предлагаю дополнительно разбивать проекты на те которые просто приносят деньги и те, над которыми стоит подумать и предложить что-то лучшее. Тут многое завит не от РМ, а от заказчика, его бюджета. А далее просто стараться брать проекты, которые можно обсуждать и добавлять идеи всех, как программистов так и дизайнеров и всех всех всех.
ilyaplot
Разве не может быть хороших идей для проекта, который просто приносит деньги? Разработчик тоже может придумать как заработать больше денег.
MaratPro
Все верно, но есть такие заказчики, которые хотят только как они, все тут. И когда реально третий раз твое предложение отвергают, то уже не хочется дале предлагать. Поэтому такие проекты проще воспринимать как проект для заработка, закончить, сдать клиенту и забыть.