Как менеджеры узнают, хороший человек или плохой программист?

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

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

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

В чем секрет?

Обычно менеджер будет смотреть на

• Программист выполняет работу?
• Что их коллеги думают о них? Код, который они пишут?
• Программист четко общается с менеджером?
• Программисту нравится изучать новые вещи? Хорошо ли они наставляют других?
• Нужно ли им много внимания со стороны руководства, чтобы добиться цели?
• Кажется ли, что программист получает удовольствие от своей работы?

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

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

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

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

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

• Статус - это ясно, точно и своевременно? Когда обсуждается, человек на вершине статуса или немного размыто по текущим вопросам? Есть ли у человека правильное решение поднять красный флаг, когда что-то загорелось?
• Решение проблем - важно задавать вопросы и отвечать на них. Знает ли человек, когда обращаться за помощью, или где они крутят свои колеса бесконечно? Еще лучше, когда у других есть проблемы, помогает ли человек найти решение или становится частью проблемы? Даже имея здравый смысл отступать, когда проблема не в вашей области знаний, стоит несколько баллов. Также есть пункты для выхода за пределы группы или компании и посещения сайтов, подобных этому, или других интернет-ответов.
• Внимание к процессу - обычно это довольно очевидно - даже в компании, не сохраняющей анальный доход, если кто-то ругает систему, это видно в хаосе, который они оставляют после себя. Если другие люди убирают функции другого человека, потому что они не придерживаются руководства или архитектуры, то у нас есть проблема. Бонусные баллы получают те, кто ищет способы сделать последовательность и качество проще .
• Степень завершенности в сравнении с ошибками и сложностью - сделайте что-нибудь, но сделайте это правильно. У всех есть несколько ошибок, но если парень делает вещи быстро и с ошибками, у нас проблемы. Я обычно нахожу, что это не то, что вы можете оценить в повседневном смысле - это оглядка на выпуск, фазу или финансовый квартал.

И чужой вклад. Часто я был в положении, когда разные инженеры отвечали за различные части проекта. Иногда команда ведет, а иногда и просто владелец определенного выхода продукции (например, «парень сборки»). Люди любят говорить о крайностях - актах героизма или разочаровании проблемных детей. Обычно в процессе решения этих проблем я узнаю много о ОБАХ вечеринках.

Там также есть фактор, касающийся управления людьми . Ни один инженер не такой, как любой другой. Таким образом, они не все сияют в одном свете. Один пишет блестящий код без ошибок, а другой помогает решить сквозные проблемы, которые нарушают код каждого. Один велик лично, другой лучше в письменной форме. Один из них бессвязен в 9:00, а другой отсюда к 3:00. Существует определенная необходимость сделать шаг назад, выяснить, что является наиболее полезным для команды и что может быть фактором личной предвзятости (например, желание убить этого бодрого парня в 4:00 утра, просто потому, что я не могу работать до 11: 00 утра).

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

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

Как правило, они этого не делают.

Вот почему программирование - это «Рынок лимонов». http://en.wikipedia.org/wiki/The_Market_for_Lemons

Код испорчен, и это обычно не на 2-3 года, прежде чем вы узнаете. Программисты, как правило, остаются 18 месяцев, поэтому вы никогда не увидите виновников неудачи.

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

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

Как менеджеры узнают, хороший человек или плохой программист?

Я начну с грубого обобщения: большинство менеджеров не могут отличить «хорошего» программиста от «плохого» программиста.

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

Как они это делают?

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

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

человек работает хорошо, если он или она должны быть ответственны за что-то

Быть «ответственным» требует иных навыков, чем написание кода. Если человек обладает человеческими навыками, необходимыми для руководства командой, то этому человеку следует воспользоваться для этого. Если вы будете продвигать людей, основываясь на ключевых элементах работы, которую они выполняют в настоящее время, в конечном итоге они достигнут уровня, на котором они теперь некомпетентны. Это называется принцип Петра .

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

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

• Должны ли они быстро / регулярно / последовательно освещать проблемы, возникающие при выполнении задач, отвечающих указанным в настоящее время требованиям ... и сильно ли это раздражает (в конце концов, это разработка программного обеспечения, если она не достаточно сложна, чтобы иметь такие проблемы, это не настоящий девелоперский проект).
• Если они не уверены в чем-то, немедленно ли они так говорят - только программист, уверенный в своих силах, мог бы на самом деле сделать это (и они знают, что если вам это не нравится, они могут легко найти другую работу). И наоборот, кто-то, кто знает, что он серьезно из своей глубины, имеет тенденцию прятаться и искать укрытие.
• Что другие программисты в команде говорят / подразумевают о других программистах? Если вы наполовину порядочный менеджер, вы находитесь в окопах со своей командой программистов - особенно во время тестирования интеграции / исправления ошибок. Так что, если вы не получаете такого рода обратную связь, кто-то другой должен делать вашу работу.
• И мой любимый: то, что я называю программистом tomcat. Если через некоторое время вы постоянно замечаете, что разные программисты постоянно бродят по столу одного и того же программиста (предполагая, что они делают работу и обсуждают какую-то проблемную проблему, а не постоянный искатель классных и забавных веб-материалов) ... тогда есть причина, по которой другие программисты тяготеют к столу этого человека. Если они еще не являются руководителем группы, то, вероятно, их следует сделать как можно скорее.

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

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

1. В большинстве случаев, когда ваш код не оценивается вашим менеджером, он оценивается вашими коллегами (формально или неофициально, когда они пытаются работать с вашим кодом). Ваш босс будет использовать мнения ваших коллег (опять же, формальные или неформальные) в некоторой степени.
2. Ваша общая надежность и то, насколько быстро вы продвигаетесь и завершаете задачи, часто являются очень важным фактором, отличным от ваших навыков кодирования.
3. Связь. Если вы делаете много и делаете это хорошо, ваш менеджер должен знать об этом! (Избегайте хвастовства, конечно). Научитесь «управлять своим менеджером», а не просто быть пассивным. Помогите своему боссу узнать, как вы работаете.

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

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

Как менеджер, вот несколько вещей, на которые я смотрел при оценке моих программистов:

• Обратная связь с коллегами. Я попросил программистов из моей команды и программистов из других команд прислать мне отзыв о моих людях.

• Уважение сверстников . Когда мои программисты сталкиваются с проблемой, которую не могут решить, они говорят: «Пойдем, спросим у такого-то совета».

• Получает вещи делать . Я говорю «Я хочу Х», и на следующий день Х готово.

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

• Исправляет меня . Я говорю «Я хочу X», а программист говорит: «X не прав, мы должны сделать Y, и вот почему».

Там не так много хороших менеджеров (см. Смежный вопрос: как программисты узнают, хороший человек или плохой менеджер?). Хорошо управлять людьми очень сложно, и это требует много времени и тяжелой работы. Как только я управлял пятью людьми, у меня почти не было времени на программирование. Когда я управлял 8+ людьми, я больше не мог управлять ими так, как они заслуживали.

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

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

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

Безответственные просто пойдут со своими "внутренними" реакциями, если они используют какие-то вообще не поддерживаемые "метрики".

Это дерьмовая стрельба, но вы всегда можете бросить курить и надеяться на что-то лучшее в другом месте.

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

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

Ваша работа требует от менеджера больших затрат, поэтому вы должны быть финансово прибыльными, чтобы продолжить работу.

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

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

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

Жизнь была бы проще, если бы вы могли рассчитывать на то, что скажете людям: «Просто заставьте это работать». Когда вы понимаете и заставляете людей придерживаться правильного процесса, вы устраняете много проблем. Вы можете иметь требовательные сроки, которые являются реалистичными. Любой дурак может выдвинуть нереальные требования и рискнуть потерять талантливых людей.

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

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

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

Иногда я думаю, что код переоценен.

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

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