Каковы основные ожидания программиста от старшего программиста?


41

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

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

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


19
joelonsoftware.com Читайте столько его блога, сколько у вас есть времени.
P.Brian.Mackey

@ P.Brian.Макки классная ссылка!
Аватар

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

1
Интересно ... Мой босс набрал 4 из 5 в этом тесте ... Я должен предупредить его о хороших новостях;)
Aeo

Ответы:


79

Вещи, которые, кажется, работают хорошо для меня:

  • Дайте значимую работу и поощряйте владение - даже когда проблема возникает, не решайте ее, обсуждайте ее и дайте человеку понимание, чтобы он мог решить ее самостоятельно.
    • изменить - дополнение - это также должно было включать - держаться подальше от деталей. Предположите, что ваши люди знают достаточно, чтобы выполнить задание без микроменеджмента или требования постоянно проверять. Создайте набор руководящих принципов для того, когда они должны зарегистрироваться - что должно быть только тогда, когда работа либо выполнена, либо действительно испорчена, что серьезное вмешательство необходимо. Если возможно, держитесь подальше от необходимости быть в курсе проблем, связанных с межгрупповой поддержкой.
  • Будьте честны - у этого есть несколько следствий:
    • Будьте честны с собой: «У меня не будет времени до вторника», «Я никогда этого не делал, вот мое лучшее предположение» и т. Д.
    • Будьте честны в отношении команды и того, где они вписываются в компанию - если вы знаете что-то о деловых вещах, скажите им, если можете, и скажите им то, что вы знаете, как прямые факты.
    • Будьте честны в предоставлении отзывов - не используйте слова или мягкую педаль, если вы дали отрицательный отзыв. Это отличается от "грубо честного" - у вас все еще может быть сострадание, но если что-то не так, скажите так.
    • Будьте честны, когда знаете, что работа больше связана с редтапом, чем с выполнением чего-то значимого. В жизнь каждого попадет какая-то бессмысленная работа. Не притворяйся, что это значимо. Называйте это как есть, так что вы можете сосредоточиться на том, чтобы пройти мимо этого и заняться чем-то полезным.
  • Слушайте . По крайней мере, 50% вашей работы слушает, а может и больше. Вы неожиданно стали ответственными не только за техническую работу, но и за людей, выполняющих ее. Вы должны слушать, чтобы узнать не только о проблемах, с которыми сталкивается команда, но и о том, как ваши люди подходят к проблеме и каковы недостатки команды как группы.
    • Важное следствие - слушание может напрямую привести к пункту 1 - дать значимую работу - инженеры способны придумать способы облегчить разработку. Вы не можете одобрить все, но там, где идея хороша, дать инженеру задание, и они по существу сделали вашу работу для вас - они создали значимую работу и сказали вам, что это такое.
  • Скажи "спасибо" . Я знаю, это кажется очевидным. В то время как мы все любим деньги, лучшие инструменты, более приятную рабочую среду и рекламные акции - путь к этим вещам заключается в серии хороших усилий, каждая из которых заслуживает «спасибо». «Спасибо» абсолютно бесплатно, вы никогда не исчерпаете их, и знание того, что ваш менеджер увидел и оценил вашу тяжелую работу, определенно мотивирует.
  • Потратьте время на общую картину , даже если это означает пожертвовать частью повседневной работы, которая принесла вам должность. Вероятно, это правда, что вы можете писать лучше, чем некоторые из ваших людей, но если вы не тратите приличное количество времени на общую картину - команду, общее направление проекта, состояние вашей кодовой базы, эффективность ваших процессов окружение вашей команды - тогда вы не будете выполнять работу, в которой вы нуждаетесь.
  • Научитесь быть буфером для вашей команды . Инженерные команды работают лучше всего, когда у них есть время заняться ... инжинирингом. Корпоративная бюрократия не инженерная. Все, что вы можете сделать, чтобы принимать раздражающие 1 раз в год / месяц / неделю встреч с внешними людьми, лучше. ПРИМЕЧАНИЕ. Это не означает гибких встреч с заинтересованными сторонами - это инжиниринг, для этого должна быть ваша команда. Я имею в виду встречу с учреждениями, которые хотят поставить рядом с вашей командой громкий вопящий механизм, или с группой процессов, которая хочет, чтобы ваша команда заполняла документы в трех экземплярах, прежде чем какой-либо код будет проверен. Вы - система абсорбции.
  • Предположим, что проблемные люди не злые , это люди, которые хотят делать добро, но еще не поняли, как это сделать. Вы не сможете починить всех, но часто первые несколько полных провалов являются таким же фактором неудачного общения, как и некомпетентность или преднамеренная злоба. Если вы начнете с предположения, что люди не являются злом, у вас есть надежда избежать множества архетипов злого босса из списка выше.

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

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


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

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

2
Вау! ... это был один из лучших ответов, которые я когда-либо встречал @Stackexchange
explorest

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

2
@PrinceCoder у каждого пользователя есть свой фид, вы можете следить за этим в некоторых программах для чтения RSS.
svick

12

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

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


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

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

+1 @James, кто-то отредактировал название, кажется. По вопросам стоит о лидерах / менеджерах. Слово «босс» выглядит жестоким, поэтому я выбираю слово старший программист.
Аватар

6

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

Слушание важно.

Пожалуйста и спасибо вам важно и ничего не стоит.

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

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

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

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

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

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

Понять важность бизнес-сферы и стать экспертом в этом, а также в программировании.


3

Ключевые слова здесь - доверие и ответственность.

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

ИМХО, это одно делает чудеса в создании здоровой атмосферы.


2
При условии, что они достаточно компетентны и мотивированы. Если команда наследуется как есть, это, к сожалению, не дано. Если вы выбрали участников самостоятельно, это, конечно, другая история.
Петер Тёрёк

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

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

@ Péter Török - конечно, каждый знает несколько таких людей в каждой компании (на самом деле, читая это, я подумал, что вы знаете того же парня, что и я :). Но по моему опыту, большинство людей сосредотачиваются и стараются изо всех сил.
Jas

Я согласен, большинство людей стараются изо всех сил. (Или я должен сказать, что каждый старается сделать все возможное - только для некоторых «лучшее» не достигает порога заметности? :-) Следует все же быть внимательным, чтобы заметить исключения во времени - потому что есть исключения. Как и в рабочем коде, мы должны правильно обрабатывать ошибки, даже если они редки при нормальных обстоятельствах.
Петер Тёрёк

3

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

Главное, что следует избегать ИМО, - это быть «да-мужчиной» для высшего руководства и всегда соглашаться, что бы они ни говорили (другими словами, задница)


+1: верно. И если вы обнаружите, что сообщаете «Да», оставьте как можно скорее.
Джим Г.

1
К сожалению, есть много сред, где старший / ведущий / менеджер-программист - не что иное, как Да-Человек (или, как я предпочитаю называть их, «Смитерс»), и худшая часть в большинстве случаев - вы этого не узнаете до тех пор, пока вы не приступите к работе.
Уэйн Молина

3

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

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

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


2

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


2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.