Я менеджер. Как я могу улучшить рабочие отношения и общение с программистами? [закрыто]

Сначала немного предыстории. Я менеджер проектов в компании среднего размера. Я начинал как майор CS и немного занимался программированием, но через несколько месяцев я понял, что это не мой путь, поэтому я переключился на менеджмент. Это оказалось хорошим решением, и после окончания я работал в области управления программным обеспечением в различных компаниях (уже 5 лет).

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

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

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

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

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

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

• Почему? это очень важный вопрос - почти любой фактический ответ имеет за собой «почему», и это «почему» вполне может быть важнее, чем фактический вопрос. Есть несколько касательных к этому:
  • Почему разработчик - у разработчиков будет много ответов, которые не имеют абсолютно никакого смысла для менеджмента. Я, конечно, сделал, и одним из способов, которым я попал в менеджмент, было действительно хорошее объяснение командам «почему» с точки зрения менеджмента. Если у вас нет «говорящего для гиков» под рукой, вы можете научиться говорить гиковым путем повторения ответов на вопрос «почему» в более понятных метафорах. Продолжайте, пока вы оба не поймете и не согласитесь с тем, что происходит.
  • Управление Почему- ваше «почему» так же важно. Зачем вам нужны оценки времени? Для чего вы их используете? Насколько нам будет плохо, если они будут слишком высокими или слишком низкими? Это то, что вы, как менеджер, наверняка хорошо понимаете, но это все вуду для разработчика. Хитрость в том, что разработчик может не спросить. Менеджмент попросил его о чем-то, и он собирается сделать все возможное, чтобы быть точным, своевременным и вдумчивым - но если он не знает «почему», он может оптимизировать его так, как вы бы предпочли, чтобы он этого не делал. Предложите свою причину и попросите его сделать то же самое - переформулируйте ответ в его собственных терминах.

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

• Никто не ошибается - вопрос «почему» идет долго с следствием - спрашивая «почему» вместо того, чтобы сказать «это возмутительно! Ни за что!» поддерживает разговор. Иногда существует серьезное несоответствие между тем, о чем кто-то спрашивает, и тем, что спрашивает спрашивающий. Мои лучшие менеджеры были ужасно удивлены моими ответами, а когда они удивлены, они удивленно моргают, а затем спрашивают: «Почему ты так говоришь?». Они не говорят (сразу) - «нужно это изменить». Я сократил количество предложений по достижению конкурентной цели, но только после того, как интенсивно поговорил о том, как мы могли бы изменить сцену и создать другой контекст для вопроса.

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

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

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

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

И вот тот, который невероятно сложен для меня, но отлично сработал, когда я смогу это сделать - осознавать разницу между интровертами и экстравертами . Скорее всего, вы экстраверт - вот почему ваша работа казалась хорошей, а должность разработчика - нет. Разработчики, по большей части, интроверты. «Интроверт» не означает «не может общаться», но это означает, что их структура, процесс и скорость значительно различаются, и желание постоянно общаться практически отсутствует. Планируйте время и спокойное (но расположенное рядом) пространство, чтобы позволить интровертированным основанным мыслям выйти наружу. Многие из моих интровертных друзей говорят мне, что они просто ждут, чтобы я "заткнулся примерно на 5 минут", чтобы они могли составить мысль и ответить. Вот'5 вещей, которые экстраверты должны знать об интровертах и рандах в Repose on the Nerd Cave - особенно впечатляющий пример того, что отлично подходит для интровертов . Кстати, Рэндс довольно фантастический. Он сам выродок, поэтому он пришел к этому с точки зрения разработчика, который может быть неуместен, если это не ваш стиль, но он забавен и имеет некоторые действительно хорошие идеи по развитию команды.

Я думаю, что первое, что я любил в своих любимых менеджерах, было:

• они были так же глубоко преданы и взволнованы проектом, как и я (если не больше)

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

• В то время мне дали право владеть чем-то значительным и соответствующим моим навыкам, но у меня было достаточно ресурсов, чтобы расширить мои навыки и выполнить работу.

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

• они знали о моих личных целях и хотели включить их как можно больше

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

• всегда было время в неделю (может быть, не сейчас), чтобы объяснить общую картину

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

• всегда была правда Если что-то было чувствительным и не могло быть обсуждено, они сказали это в упор. Если что-то было неопределенным, они давали уровень уверенности.

Сначала самое простое: в вашем сообщении есть технический красный флаг: я содрогаюсь от вашего упоминания о «ошибочных оценках» - это оценка, она НЕ МОЖЕТ БЫТЬ ОШИБКА , поэтому она называется оценкой. Это может быть немного, это может быть много, поэтому это называется оценкой. Если вы воспринимаете оценки как евангелие, это будет одной из основных проблем, с которыми «ваши» разработчики сталкиваются с вашим стилем.

Тем не менее, я на 100% согласен с вами по поводу сложности общения с разработчиками. У меня было откровение несколько лет назад, как разработчик в тренинге по управлению проектами. Я видел, как несколько моих коллег-разработчиков были абсолютно противны руководству после создания открытой атмосферы обсуждения (здесь присутствовало руководство). Все, что было не так, было ошибкой менеджеров в глазах разработчиков. Главное, что руководство не знало почти всех огромных проблем, которые были подняты в тот день. Разработчики предполагали, что все было настолько очевидно, что руководство не могло пропустить это, а руководство предполагало, что разработчики скажут им, что им нужно.

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

И что бы вы ни делали, НЕ задавайте им вопросы, ответы на которые вы на самом деле не хотите знать - ссылаясь на «ошибочные оценки» выше ;-). Это криптонит разработчика.

Здесь много хорошего, но я чувствую, что нужно сказать следующее ... Извините за резкость ... Но это нужно сказать:

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

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

Лично я бы никогда не нанял премьер-министра, у которого не было опыта разработки. Я думаю, что в вашем следующем проекте вы должны посвятить небольшую часть своего времени как часть Dev. команда . Скажем, 8 часов в неделю, работая младшим разработчиком под руководством команды.

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

«Мы потеряем нашего лучшего парня, если ты ничего не сделаешь»

Это должен быть красный флаг № 2.

Как менеджер, я уверен, что вы слышали о кайдзен , одном из принципов Toyota Production System, означающем постоянное совершенствование .

Вы признали, что у вас есть проблемы, так что это отличное начало.

Кайдзен имеет пять основных элементов:

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

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

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

• Личная дисциплина : команда не может добиться успеха, если каждый член команды не является сильным в себе. Приверженность личной дисциплине каждого сотрудника гарантирует, что команда останется сильной.

• Предложения по улучшению : Запрашивая обратную связь от каждого члена команды, руководство гарантирует, что все проблемы будут рассмотрены и решены до того, как они станут значительными.

( Источник )

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

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

Итак, мой первый совет:

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

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

И, наконец, хотя я видел здесь некоторые критические замечания по этому поводу, я хотел бы рекомендовать вам прочитать книгу под названием «Мифический человеко-месяц: очерки по разработке программного обеспечения» . Книга рассказывает об опыте Фреда Брукса в IBM при управлении разработкой OS / 360. Хотя некоторые вещи здесь и там могут быть устаревшими, это первый шаг к пониманию того, как работает процесс разработки сложного программного обеспечения. С.Лотт цитирует Agile Manifesto , который мне не особо интересен, но также стоит прочитать.

Прочитай это:

http://agilemanifesto.org/

• Индивидуумы и взаимодействия над процессами и инструментами

• Рабочее программное обеспечение над исчерпывающей документацией

• Сотрудничество с клиентом в рамках переговоров по контракту

• Реагирование на изменения после плана

Во многих случаях организация (т. Е. Ваш начальник) требует, чтобы вы

• следуйте четко сломанному процессу до логического завершения, ведущего к «маршу смерти». Это приводит в свою очередь к аргументам и отставкам.

• создавать чрезмерную, низкую стоимость, неиспользованную документацию.

• участвовать в комплексном контроле изменений а / к / при заключении договора. Каждое изменение пользователя требует тщательно продуманного ритуала «качества» и «расстановки приоритетов» изменения. На самом деле, все дело в «заморозке» - предотвращении изменений.

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

Возможно, проблема не в ваших личных навыках общения.

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

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

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

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

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

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

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

• M entor больше , чем управлять.
• А Llow членов команды , чтобы выразить свои мысли и проблемы. Будьте всем вниманием к этому. Возьми конструктивные.
• Никогда не предавай членов команды, играя в разногласия. Этот ответный огонь рано и тихо.
• Не nger. Никогда не имейте гримасы на лице, когда вы со своей командой, что бы ни случилось. Это действительно сложно.
• G искренне и открыто ценю победителя за его хорошую работу. В той же широте очень мягко и тактично критикуйте работу не человека за любые проступки, а человека, который несет ответственность, изолированно и не открыто.
• Е ncourage собственности и лидерство в каждом человеке. Это повышает моральный дух и приверженность человека, потому что он будет чувствовать себя уважаемым.
• р OAM вокруг с вашей командой один раз в то время. Это вызывает / увеличивает связь внутри членов команды.

Желаю вам удачи в ваших искренних усилиях :)

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

Я - Теория, вроде как парень, и большинство «работников умственного труда» склонны к этому; Нам предоставлена ​​возможность, нам нравится наша работа, и мы хотим делать ее хорошо. Однако недостатком рабочего места Theory-Y является то, что может быть не сразу очевидно, что есть проблема, потому что люди, желающие преуспеть и, следовательно, не желающие делать волны, найдут способы обойти эту проблему или просто проигнорируют ее. Это приводит к неудовлетворенному разочарованию, которое в конечном итоге взрывается перед лицом всей команды. В магазине, управляемом менеджером Theory-X, наверняка есть парни, которые жалуются гораздо раньше; сотрудники работают только ради денег, поэтому, если работа отстой больше, чем обычно, они начнут беспокоиться.

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

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

Говоря об Agile; Моя первая работа была в маленькой компании, и под «маленькой» я подразумеваю, что вся фирма не могла выставить команду по софтболу. Когда я начинал, было четыре программиста, а до того, как я ушел, их стало два. Основатель, президент, генеральный директор и 95% -ный акционер компании управляли ею железным кулаком, и он был единственным источником планирования в организации, то есть не так много. Босс был трудоголиком и ожидал, что все остальные будут такими же; Все, что вы должны были дать, было не больше и не меньше, чем его ожидание, и за это он платил зарплату начального уровня людям, которые работали на него десятилетие.

Я покинул эту компанию и начал работать в другой фирме, которая делала вещи ОЧЕНЬ иначе; они практиковали базовую методологию SCRUM Agile с ежедневными дежурствами, парным программированием, спринт-командами и ретроспективами. В течение одного дня каждые две недели в начале каждого спринта мы ничего не делали, кроме как планировали работу на следующие две недели. Большую часть дня мы ничего не делали, кроме как оглянулись назад на то, что мы сделали, и нашли способы улучшить свою команду. Рядом со мной сидели разработчики, которые были Microsoft MVP, выполняли свою работу, поощряли и дополняли то, что я делал.

Ночь. А также. День. Основное отличие? Во-первых, я не чувствовал, что должен был убить себя за проект; Основополагающим принципом Agile является устойчивый темп развития. Во-вторых, у меня был голос, чтобы решить, как я буду выполнять свою работу. Я должен был сделать работу, но если бы у меня была «изжога» из-за того, что я собирался осуществить в следующем спринте, я мог бы высказать это мнение, и оно будет услышано и получит вес. Если бы я чувствовал, что есть лучший способ, я мог бы сказать так, и это было бы развлечено.

Что касается поиска решений и решения проблем, вы должны быть осторожны, чтобы не выглядеть так, как будто вы работаете сверху вниз. Для компьютеров; скажем, ваш RMR (постоянный ежемесячный доход) позволяет компании обновлять четыре компьютера каждые две недели. Первые четыре компьютера не должны все идти к руководителям и пожилым людям; они должны идти к людям с самыми медленными компьютерами. Если вы даете бонусы команде, не просто отдайте их «нашим ценным пожилым людям и лидерам, без которых это было бы невозможно»; ВСЕ в вашей команде разработчиков сделали это возможным. Если у младшего есть жалоба, выслушайте его; только то, что он младший, не означает, что он ничего не знает.

Улучшение отношений:
Просто был тяжелый проект? Дайте им отдохнуть потом. Время отпуска, чтобы расслабиться, отдышаться.
Кодеры Билль о правах Эти вещи являются данностью. Основные вещи, которые должны идти без слов. Если вы нарушаете их, вы злоупотребляете своими кодами.
Тест Джоэля Я согласен с большинством из них. Но некоторые действительно зависят. Если вы что-то упускаете, вы, вероятно, усложняете жизнь своим программистам, чем это должно быть.
Технический долг . Таким образом, вы можете настаивать на завершении, но вы должны понимать, что, сокращая углы, вы несете техническую задолженность, которая в более поздний срок потребует исправления. Если эта дата наступит ДО конца проекта, вы действительно облажались.
RSA animate: мотивацияЭто фантастический эпизод, который действительно показывает, как мотивировать работников умственного труда.
Свободный день для кодирования того, что они хотят.Из видео RSA. Не помню названия, но компания, которую она упоминает, имеет краткое объяснение этого на своем сайте. Похоже, хорошая идея для меня. В большинстве магазинов есть вещи, о которых все знают, что они обанкротились, но никто не успевает их починить, и это не является приоритетом. Это позволяет им решать технические долги. Это также позволяет им показать свои блестящие идеи.

И ради любви к Богу, постарайся сохранить 40-часовую рабочую неделю. Кроме того, flextime. Flextime может компенсировать весь мир ерунды. По крайней мере для меня.

Улучшение общения между программистами и боссами.
Это сложнее для меня. Вся эта шумиха - это скорее набор навыков босса, чем фокус программиста. Я мог бы сказать, что некоторые основные вещи, такие как оценки времени, являются только оценками. Ходить по воде и выполнять требования легко, если они заморожены. Может быть, попросить застенчивых программистов представить презентацию своего проекта в обзоре кода или что-то в этом роде. Практика делает идеальным, да? Но я бы поклонился советам других на этот счет.

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

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

Удачи.

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

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

• Мне не нужно тратить слишком много времени, чтобы обосновать, почему изменение занимает так много времени или не может быть реализовано. Технически, любое изменение может быть реализовано, и высшее руководство обычно требует реализации любым способом. Но, по крайней мере, в такой ситуации ваш непосредственный менеджер на вашей стороне, требуя больше времени (вместо того, чтобы толкать вас или выгорать).
• Я знаю, что у меня больше шансов получить поддержку в случае плохой ситуации (взлом WTF, проблема с производством и т. Д.). Обычно нетехнические люди склонны обвинять разработчика в такой ситуации, в то время как хороший менеджер ПОНИМАЕТ, что на самом деле происходит, и поддерживает его / ее разработчика (а не просто знает или готов принять это таким образом за то, что он хороший).
• Я знаю, что моя работа и работа должны оцениваться соответствующим человеком.

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

Я также один из парней в костюме, и был в течение более 15 лет. Я был разработчиком программного обеспечения, когда начинал, и я все еще пишу код, когда у меня есть шанс. Так что я думаю, что могу говорить за обе стороны, и у меня есть немного опыта в этих ситуациях. У меня также есть полномочия, такие как «Сотрудник года», избираемый персоналом, что позволяет мне уверенно справляться с этими ситуациями.

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

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

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

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

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

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

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

В-третьих, подумайте, какие у вас навыки эмоционального интеллекта . Эмоциональный интеллект для менеджеров проектов: навыки людей, которые вам нужны для достижения выдающихся результатов Энтони Мерсино - это книга, которую я получил вчера на ланче и узнал об эквалайзере. Если вы действительно хотите углубиться в психологию, здесь можно использовать различные инструменты профиля личности, например, эннеаграмму, социальные стили и MBTI.

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

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

Если они оценят, у вас, вероятно, будет лучшее общение.

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

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

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

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

Что я действительно хочу, так это хорошие, высококачественные HLD и BRD. Я хочу, чтобы графики и сроки были достижимы, и, если будут представлены новые проекты или планы, я хочу, чтобы график и сроки были скорректированы. Я работал над проектами, где требования меняются на лету - для меня это мой красный флаг, что я имею дело с некачественным руководством проектом. Как разработчик, худшее, что вы можете сделать, это ежедневно предъявлять мне новые требования к проекту, особенно после того, как у нас уже есть график или мы взяли на себя обязательства по графику. Недопустимо, когда вводятся новые требования, без компенсации сроков. Работая больше часов, работая допоздна, у меня нет проблем с этим, но это не всегда количественно с развитием. Некоторые изменения могут занять несколько дополнительных часов, некоторые изменения могут занять несколько недель для проведения надлежащих НИОКР, тестирования, контроля качества и т. д. Это не всегда похоже на выпечку торта, иногда одно изменение требований может быть похоже на изменение всего рецепта. Я был свидетелем того, как менеджеры проектов таяли и раздражались на конференции, потому что их сроки не допускают дополнительного развития, но они требуют развития, которого не было в их первоначальных требованиях к проекту.

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

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

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

Хорошая ссылка на один на один - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Коротко и сладко. Excel в том, что вы делаете - это порождает общение.

Что означает исключение для ваших разработчиков? .. Читайте, перечитывайте, да даже изучайте PeopleWare

Все отличные идеи и комментарии в постах выше!

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

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

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

Эта идея ни в коем случае не волшебная пуля, но она является хорошей основой головоломки. Ваши коллеги не только научатся лучше общаться друг с другом, но и бонусом будет то, что они начнут лучше понимать и уважать ВАШУ работу (общение лежит в основе PM).

Просто мои 2 бита :)

Просто чтобы сделать ответ из рекомендации, которая уже была в нескольких ответах . Майкл Лопп (aka rands ) писал об управлении разработчиками и о том, как «заполучить их в голову», в своем блоге « Rands in Repose» и в книге « Управление людьми». ( источники в книге ). Книга содержит в основном отредактированный контент из его постов до 2007 года и предоставляет хороший способ узнать связанные с управлением части своего блога (он также говорит, например, об азартных играх и о том, хотите ли вы читать, это другой вопрос). Его сочинения, как правило, великолепны и часто юмористичны, поэтому читая его, риск не велик.

Убери команду за пивом (а ты покупаешь).

Я опоздал на вечеринку, но только что увидел этот вопрос.

Одна вещь, которую я не вижу очень хорошо решенной, состоит в следующем:

Ворчания никогда не рассказывают всю правду по костюмам. Рэндс говорит это в ДНК но не рассматривает это в лоб, он на другую тему.

Вы носите костюм, и вы подписываете чеки. Вы представляете интересы компании. Вы не представляете инженеров. Если бы вы это сделали, вы бы не подписывали их чеки, они подписывали бы ваши.

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

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

Я удивлен, что никто не упомянул эту замечательную книгу, которая имеет дело именно с вашим вопросом и темой - «Персонал: продуктивные проекты и команды» Демарко и Листера . Из редакции: основные проблемы разработки программного обеспечения - человеческие, а не технические . Первых трех отзывов об Амазонке было бы достаточно, чтобы убедить меня купить эту книгу, если бы я был в вашей ситуации.

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

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

Читая ваш вопрос, я думаю, вы видите ценность общения. Я лично считаю, что общение для менеджера или руководителя важнее, чем деловые или технические навыки. Люди, которыми вы руководите, должны обладать необходимыми навыками, необходимыми для выполнения большей части проекта. Хороший технический руководитель или менеджер проекта должен уметь сосредоточиться на коммуникации, будь то внутри команды или между командой и клиентом или командой и бизнес-субъектом (или даже комбинацией этих трех).

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

• Хакеры, Стивен Леви - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Кафедральный собор и базар, Эрик Рэймонд - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Они так же важны, как и любые типичные мемуары об управлении (Drucker et al).

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

Из вашего вопроса - совершенно очевидно, что ваши разработчики не рассказывают вам вещи, потому что они не думают, что вы можете помочь.

Это может быть из-за 2 причин.

1. Они не думают, что у вас есть сила, чтобы все исправить. Тем не менее, я думаю, что это маловероятно, потому что тогда вы, вероятно, знаете об этом, а также разработчики скулили бы вам об этом.
2. Вы тот человек, который, когда разработчик приходит к вам с проблемой, делает одну или несколько из следующих вещей
   • Когда они приходят к вам с проблемами, вы им говорите - мне нравятся решения, а не проблемы.
   • Вы слушаете их хорошо, а затем поручаете им решить проблему. Вы говорите им о том, что для них большая честь быть ответственными за решение проблемы. Со временем ваши ребята понимают, что когда они обращаются к вам с проблемой, у них возникает дополнительная работа, поэтому они не приходят к вам с проблемами.
   • Вы отрицаете, что это проблема. Вы приводите убедительные причины для этого. Но так как это продолжается, со временем ваши ребята узнают, что нет смысла приближаться к вам с проблемой.
   • Вы говорите: «Да, я понимаю». Вы говорите, что такие вещи случаются время от времени, и никто ничего не может сделать. Если это закономерность, то, опять же, ваши ребята это понимают.

Если это что-то или все из вышеперечисленного, то вам нужно исправить это.

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

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

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

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

Поддерживать команду очень легко

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

Командный выход - хорошая идея (может быть, какой-то игровой план)

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

делайте раз в месяц 1: 1 с каждым членом команды, чтобы убедиться, что он чувствует себя комфортно.

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

Пожалуйста, дайте мне знать, если у вас есть дополнительные вопросы

Я также (французский извините за мой английский) менеджер по программному обеспечению, у которого есть опыт в области инженерных наук, но изначально я не специализировался в области программного обеспечения. Таким образом, у меня нет особого отношения к кодированию с самого начала, но я был инженером-статистиком из школы Деминга, в которой преподавание было совершенно разным для всех «современных» школ, которые следовали, хотя они притворялись, что унаследовали от Деминга. Худшее - это 6 сигм, худое было лучше, но, к сожалению, это произошло http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

«Первоначально Six Sigma была получена из Toyota Quality Management (TQM) компанией Motorola для достижения шести уровней качества сигмы, а затем с помощью Allied Signal и GE она превратилась в проекты Black Belts, основанные на статистике, и стала программой снижения затрат - каждый проект нужна четкая рентабельность инвестиций. Другими словами, мы переросли программу из философии лидерства в ряд разовых проектов, чтобы сократить расходы. Это была полная убогость оригинала, и она редко приводила к длительным, устойчивым изменениям, потому что лидерство и культура отсутствовали.

«Подобная вещь случилась, когда она превратилась в инструментарий (например, отображение потока создания ценности, доски KPI, ячейки, канбан).

«Lean и Six Sigma никоим образом не отражают оригинальное мышление отличных японских компаний или их учителей, таких как Деминг».

Сегодня Agile-движение похоже на стройное (см. Курс Джеффа Сазерленда и его почитание Деминга http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), это лучше, чем Waterfall, но оно все еще очень далеко от первоначального учения Деминга, потому что вместо чтения Деминга в его оригинальном тексте, гуру просто перепаковывают его, примерно никогда не цитируя его целых 14 принципов управления, и продает инструменты и семинары, которые имеют небольшую ценность сами по себе.

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

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

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

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

В заключение: исключите лозунги разработчиков (на самом деле это один из 14 принципов Деминга), покажите им, что вы заботитесь о конкретном программном обеспечении проекта, а не о документах или встрече только с высшим руководством.