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

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

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

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

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

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

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

432 голоса | спросил AgentSmith 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

30 ответов


331

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

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

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

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

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

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

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

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

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

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

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

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

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

  • они знали о моих личных целях и интересовались их тем, что могли

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
161

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
70

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

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

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

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

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

  

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
37

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

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

Kaizen имеет пять основных элементов:

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

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

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

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

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

( Источник )

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
26

Прочтите это:

http://agilemanifesto.org/

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

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

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

  •   
  • Ответ на изменение в соответствии с планом

  •   

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

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
22

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
20

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

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

  • M entor больше, чем управлять.
  • A ленивые члены команды высказывают свои мысли и проблемы. Будьте все уши к нему. Возьмите конструктивные.
  • N когда-либо предавали членов команды, играя в разделяющую политику. Эта назад и тихо.
  • A nger нет. Никогда не делайте гримасы на вашем лице, когда вы со своим команда, придет, что может. Это действительно сложно.
  • G enuinely и открыто оценивает победителя за его /ее хорошую работу. В одинаковой ширины, очень мягко и тактически критически оценивать работу, а не лицо за любые ошибки, лицу, которое несет ответственность, в изоляции а не открытыми.
  • E ncourage владение и лидерство у каждого человека. Это повышает мораль и приверженность человека, потому что он почувствовал бы уважаемый.
  • R с вашей командой раз в то время. Вот этот индуцирует /увеличивает связь между членами команды.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
16

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

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

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
11

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

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

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

"Точно так же, если вы ненавидите его, пожалуйста, подробно расскажите, почему."
Хорошо, что здесь откроются шлюзы. И если бы я не использовал openID, который, очевидно, мог бы быть связан со мной, я бы тоже сказал. Если вам действительно нужен гигантский список того, что не нужно делать, спросите на форуме, который более дружелюбен к анонимной публикации.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
8

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

Удачи.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
7

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
7

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
5

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
5

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
4

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

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

Если они будут оценены, вы, вероятно, получите лучшую связь.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
2

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
2

Короткий и сладкий. Excel в том, что вы делаете - это вызовет связь.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

Все замечательные идеи и комментарии в сообщениях выше!

Вот идея: отправьте свой I.T. персонал к семинарам по коммуникации в вашем местном колледже - конечно, оплачивается компанией.

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

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

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

Только мои 2 бита:)

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

Возьмите команду за пивом (и вы покупаете).

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

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

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

Грунты никогда не рассказывают всей правде костюмы. Rands говорит об этом в ДНК , но не рассматривает его, на, он на другой теме.

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

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

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

Это может быть вызвано двумя причинами.

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

Если это все или все вышеперечисленное, вам необходимо исправить его.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
-1

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
-1

Очень легко держать команду счастливой.

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
-1

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132