Разработкой руковожу
0,0
рейтинг
11 февраля 2010 в 10:14

Управление → Управление проектами – управление людьми

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.


Про команду


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

Кстати, работы над одним проектом совершенно недостаточно для создания команды. Над этим надо работать. Я встречался с «командой», которая скорее напоминает группу фрилансеров, которые почему-то собрались в одном офисе и сидят за соседними компьютерами. В принципе, я не считаю, что целенаправленный тим-билд (поездки «на пиво», совместные походы и т.д.) может улучшить ситуацию. По-моему, только ухудшит. Гораздо неприятнее увольнять или лишать премии человека, с которым пил пиво на прошлой неделе. Думаю, что достаточно, чтобы каждый член команды имел конкретно определённую роль в ней и, чтобы внутри проекта была непрерывная коммуникация (на которую, как говорил Брукс, тратится основное рабочее время). Формула 1+1 = 2,5 тут работает как нельзя более эффективно. И самое главное в команде – это взаимное уважение.

Про уважение


Очень важно добиться того, чтобы каждый член команды уважал остальных. А для этого, в первую очередь, надо уважать каждого руководителю. Да, действительно, Вася ленив, а Ася считает всех остальных идиотами. Гоша считает себя гораздо умнее, чем есть на самом деле, а Сёма пишет отвратительный код. Но при этом, никто не разбирается в Linux-системах лучше Васи, Ася, несмотря ни на что, очень неплохой архитектор, Гоша стремится писать аккуратный чистый код, а Сёма очень неплохо обучается. И это – главное.

Дайте понять (публично) Васе, что кроме него никто не смог бы написать этот скрипт автоматического развёртывания, похвалите Асину диаграмму классов и Гошин код, опять же, публично. Объясните Сёме, что он делает не так и, при всех, похвалите, как только его код станет улучшаться. Это очень многое. В команде появится уважение только тогда, когда вы будете над этим работать. И, главное, никогда публично не оскорбляйте своих ребят. Это позорно и непрофессионально. Да и ругать, желательно, отводя в сторонку и тихо (ну это уже общеизвестное правило). А вообще, каждый человек уникален, и это надо учитывать.

Про индивидуальность


Обычно, с каждым человеком надо работать. И это одна из главных обязанностей (и головной боли) руководителя проекта. К сожалению, ПМы об этом часто забывают, заваленные с головой планами, сроками, требованиями и письмами неадекватного заказчика. Мне кажется, у любого разработчика есть ключ, который необходимо повернуть, чтобы заставить его работать эффективно. Этакая «точка G», помогающая добиться максимальной отдачи. (прошу прощение за слишком фривольное сравнение, поэтому назовём её лучше «точкой Е», от слова эффект). Более того, эта точка требует непрерывной стимуляции в течение всего времени работы.

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

Про собственные технические навыки


Отлично, когда руководитель проекта имеет подробнейшее представление о технологии, которую использует его команда. Но это не главное (что бы ни говорил Рейнвотер, специалист по выпасу котов). Достаточно, чтобы у вас были такие специалисты, которым бы вы могли доверить техническую часть, сосредоточившись на управлении. Признаюсь, я имею только общие представления о том языке, на котором пишет моя команда. Иногда я думаю, это даже хорошо, так как иначе я обязательно навязывал бы свои, достаточно узкие, взгляды. Более того, я считаю очень важным, чтобы ПМы ни в коем случае не писали код сами. Ну, действительно, что будет, если программисты начнут договариваться с заказчиком о сроках, а специалисты по продажам – тестировать код? Как у Чуковского: «Свинки замяукали, кошечки захрюкали…» (полный текст этого бессмертного произведения смотрите здесь: www.stihi-rus.ru/1/chukovskiy/19.htm).

Про информацию


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

Про виноватых


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

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

Если этим не заниматься, то проект будет на 90% провальным. Остальные 10%, скорее всего, говорят о том, что в данной команде ПМ не нужен в принципе.

Про заботу


Ваша команда – это ваше всё, поэтому очень важно, чтобы люди были довольны. Только от руководителя проектов зависит, насколько комфортные условия будут созданы команде и каждому человеку в отдельности. По большому счёту, именно ПМ определяет как карьерный, так и профессиональный рост своей команды. Поэтому, если вы считаете, что ваш сотрудник достоин повышения, то необходимо поставить это своей целью и добиваться всеми возможными способами. Оговорюсь, что рассматриваются, конечно же, исключительно профессиональные качества. Главное следить, чтобы личные привязанности или предвзятость не повлияли на принятие такого решения (опять же про вред совместного распития пива). Так что, над благополучием и комфортом людей тоже надо работать.

Про выводы


Выводы очевидны. Чтобы выполнять эффективные проекты, с командой надо работать. Это необходимое условие (но, конечно, не достаточное). Можно сформулировать так: невозможно достичь успеха в проекте, не имея слаженной и подготовленной проектной команды. Да здравствует капитан Очевидность!
Михаил Пайсон @Tomcat
карма
186,0
рейтинг 0,0
Разработкой руковожу
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (78)

  • +6
    на случай если когда-нибуть буду руководителем, добавлю пост в избранное
  • +8
    как бы так дать аккуратно почитать этот пост начальнику…
    • +1
      Тут я думаю тут вариант один, если начальник у вас толковый (адекватный, нужное подчеркнуть), он сам найдёт эту статью.

      Это я вам как руководитель одного маленького проекта говорю (:
      • 0
        дело в том что он не ищет способа как более эффективно и правильно управлять разработчиками, а должен был бы!
        • 0
          Значит он не очень толковый/адекватный(
      • +3
        Мне кажется что толковый или адекватный начальник сам такие статьи писать может.
        • 0
          Может, но напишет что-то свое. Расти можно бесконечно, тем более в такой необъятной области, как управление персоналом.
    • +3
      Просто скиньте ссылку в _____ (jabber, email,… — подставить нужное).
      Это я Вам говорю тоже, как руководитель -)

      Сначала, откровенно говоря, было немного неприятно получать такие «руководства» от сотрудников, но потом понимание приходит довольно быстро, ведь это, по своей сути — один из способов сообщить своему начальнику, что тебе не нравиться и как это улучшить.
      Адекватный человек, сделает для себя выводы и если ответит Вам на такую «подсказку», то ответит в конструктиве (не знаю, есть такое слово или нет), если же начальник отреагирует в негативе на такую «подсказку» — то самое время подумать на тему, нужна ли тебе такая работа и такой начальник.
      • 0
        а еще некоторые руководители просят сотрудников включать в отчет пункт о том что им в их команде не нравится и идеи по решению проблемы.
    • 0
      киньте ссылку- а потом скажите «не читайте это я бабушке отправлял и ошибся адресом»
  • +4
    PS: А вообще, каждый человек уникален, и это надо учитывать.

    За Чуковского отдельная благодарность (:
  • 0
    Для PM у вас крайне уникальный для нашей действительности взгляд на управление. К сожалению большинство увлекается именно технической стороной руководства проектом.
    • 0
      Это вполне себе обыденный взгляд на управление. Можно даже сказать, по книжке.
  • +6
    Вы извините, но я скажу — хочется работать в вашей команде *смутился_и_закрыл_вкладку*
  • +1
    Как только стану Pm'ом, достану пост из закладок
  • 0
    Весьма верно. Местами и пролетает Капитан Очевидность.
  • 0
    В избранное, хоть я и не руководитель сейчас. Но пригодится, спасибо.
  • +1
    У меня есть несколько «заваленных» проектов, в основном по срокам. Буду признателен, если вы продолжите эту тему! Пост на 5 с +.
    Можете описать, что ИМЕННО должен делать ПМ? Конкретно, а не просто «руководить»… Хочу определиться, какие функции на него возложить, и кого из программистов «прокачивать» до руководителя.
    • +1
      Насчёт прокачки — оно не очень хорошая идея. Тут не прокачка нужна, а склад души, что ли… Вообще, программисту и ПМу обычно нужны прямо противоположные качества (почитайте Рейнвотера, у него это прописано). А если уж сильно нужно «превращать» (а не прокачивать) кого-то из команды, попробуйте спросить, кто из ваших программистов готов стать руководителем проектов, если ему при этом уменьшат зарплату (хотя бы немного). Если таковые найдутся — присматривайтесь к ним, они и есть потенциальные руководители.
      • +1
        ОГО! Уменьшить? И каким образом вы можете это объяснить?
        p.s. Спасибо за Рейнвотера («Как пасти котов. Наставление для программистов, руководящих другими программистами») — пошел читать :)
        • 0
          Объяснение простое — мотивация. Если человек готов ради долгосрочного развития (и более интересной с его точки зрения работы) поступиться краткосрочными выгодами — это многого стоит и за такими людьми, правильно написано, нужно присматривать.
    • 0
      А что вы подразумеваете под ПМ? Производственный менеджмент или финансовый? Сначала опишите ваше видение этой должности, чтобы понимать, кто именно вам нужен.
      • 0
        ПМ-PM — Project manager. Конечно же производственный
        • 0
          Тогда он должен бесперебойно подносить патроны работникам. Другими словами, работник в любой момент времени должен иметь четкое и ясное представление о своей задаче, сроках и методах ее реализации.

          Неправильно поставленная задача:
          Иван, сделай там по-быстренькому чатик заказчику…

          Правильно поставленная задача:
          Заказчик планирует внедрять систему быстрого реагирования на проблемы пользователей. Для этого мы должны интегрировать ресурс xyz.com в наш продукт. Документация по API этого сервиса лежит по адресу такому-то. Дизайн блока предоставит работник такой-то через столько-то часов, другие изменения дизайна не планируются. Срок реализации — столько то часов. Дедлайн такого то числа. Предварительный прототип — такого-то числа.

          Вторая задача ПМ-а, следить за приоритетами задач и вовремя изменять приоритетность.

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

          Четвертая — отчитываться перед руководителем о расходах бюджетов.
  • +2
    Про виноватых согласен — «ПМ ответственен за крах проекта, разработчики — за успех проекта!» :)
    Я вот тут написал статейку про обязанности менеджера.
    Вкратце:
    1. Постановка целей
    2. Организаторская работа
    3. Мотивация работников и общение с ними
    4. Измерение показателей
    5. Развитие своих подчиненных
  • +1
    Ну вроде бы прописные истины (Демарко etc.), а все-равно приятно, когда человек после года практики пишет не разочаровавшись, а наоборот. Значит справился, значит хороший ПМ. Приятно читать :)
  • +3
    «Всё верно, бумага написана правильно, всё-всё хорошо». Но есть нюанс. Он, как всегда, во взаимопонимании. Когда у тебя в команде четыре человека, можно общаться с каждым лично, вникать во все проблемы и быть классическим правильным руководителем в стиле «слуга царю, отец солдатам». Но когда людей становится больше и больше, все эти прекрасные идеи так или иначе искажаются, и руководитель рано или поздно встает перед выбором: принять «непопулярное» решение или нести убытки. Если он ставит интересы членов команды выше интересов дела, то дело рано или поздно развалится.
    • 0
      «Но когда людей становится больше...»

      А не должно становиться больше. 6 человек. команда.
      Дальнейший рост — путем создания еще одной команды.

      Ну и как будто в маленьких командах «непопулярные» решения принимать не приходится.
      • 0
        Приходится, но реже, и всегда можно лично каждому объяснить, почему так произошло. А по поводу «не должно становиться больше» — соглашусь, чем меньше, тем лучше. Но жизнь обычно далека от абстрактных моделей, описанных в специальной литературе.
    • 0
      К сожалению, не имел опыта руководить большой командой (максимум — 9 человек, включая программистов, QA, аналитика и меня). Поэтому пост написан именно с этой точки зрения.

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

      А что касается «непопулярных» решений, так их приходится принимать и в маленьких командах, к сожалению.
      • +1
        Да-да, принцип «разделяй и властвуй» неоднократно проверен как в практике управления командами, так и в ходе мировой истории в целом. По поводу непопулярных решений: как я уже упомянул чуть выше, чем меньше людей, тем меньше поводов такие решения принимать. Но даже если приходится, в маленькой команде легче предугадать последствия и нивелировать негативные реакции.
      • +1
        С точки зрения психологии, в команде до 9 человек каждый разработчик может более-менее представлять, кто и чем занимается и за какую часть работы отвечает. Поэтому и взаимодействие внутри небольшой команды эффективнее и проще. 5-7 разработчиков на группу- это идельно с точки зрения взаимодействия между ними. Микрогруппы редко выходят за эти пределы.

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

        Поэтому и полезно большие команды разделять на более мелкие, распределяя между группами относительно независимые задачи. Понятно, что если команда 9 человек, включая архитектора, тимлида и аналитика, то делить ее смысла нет, только хуже будет.
      • 0
        Tomcat, а сколько душ в твоей команде сейчас?
        • 0
          Сейчас — пятеро. В компании некоторая реструктуризация, поэтому людей теряем, к сожалению.
          • 0
            ПМ, аналитик, архитектор, QA и тимлид? А где негры??
            • 0
              У нас всю работу белые люди выполняют. Им даже нравится ;)
              • 0
                Смешно сказал. Я имела в виду рядовых разработчиков. Истинных арийцев, конечно. У вас их есть, не так ли? Кто мужики, а кто генералы в твоей пятёрке?
                • 0
                  Я это понял, просто хотел уйти от ответа. Не получилось :).

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

                  Я осуществляю общую координацию проекта. Ежедневные митинги помогают всем быть в курсе того, как обстоят дела у остальных. Серьёзные архитектурные решения обсуждаются. Последнее слово в дискуссиях, очевидно, за ПМом.

                  Когда команда будет больше, появится тимлид, через которого централизованно будет проходить архитектурная информация. Пока не вижу смысла (сейчас мы некоторое время занимаемся исключительно саппортом, готовимся к новому проекту).
                  • 0
                    А вот на этот раз получилось.
                    За сим позвольте откланяться.
  • +3
    Проблема большинства ПМ в ИТ-компаниях в том, что они выросли из программистов. Программисты — циники по натуре и им намного проще работать с программами и процессами, а не людьми. Поэтому появляются монстры-методологии, на которые возлагаются надежды автоматизации процесса управления. Методологии хороши на крупных проектах с большими командами. А для большинства мелких компании-разработчиков достаточно факта планирования.
    К сожалению, в небольших же компаниях на ПМ вешают и обязанности аккаунт-менеджера, хорошо еще если и не сейла. В результате имеем, что имеем.
  • +1
    >Ну, действительно, что будет, если программисты начнут договариваться с заказчиком о сроках, а специалисты по продажам – тестировать код?
    А если немного «подправить» систему и переодически делать отступ от правил, действительно ли будет плохо?..

    Спрашивать сроки и у программиста. Во первых программист начнёт реальней оценивать работу, потому что если он сказал «неделя», а справился за две — он понимает, что виноват он, а не «тупой начальник давший не реально короткие сроки». Во вторых — это даёт чувство ответствености и участия. Когда чувствуешь себя участником проекта, а не «гайкой», то и мотивация появится.

    Давать маркетингу тестировать систему — это увеличить знания о товаре. Возможность маркетингу узнать о сильных сторонах, а разработчикам о слабых (фидбек пользователей со знанием принципов «привлекательности» товара и интереса клиентов). Когда продаёшь продукт в который веришь и который знаешь — это видно.
    • 0
      спрашивать сроки у программиста бывает опасно
      можно обсудить сроки по планируемой задаче,
      но итоговую оценку надо самому принимать
      учитывая сложность задачи, навыки программиста, придирчивость заказчика + возможные доводки
      + программиста просто нет все информации по задаче, а только что-то локальное
    • +2
      однажды я с удивлением обнаружил, что архитектор CRM-системы никогда не занимался обзвоном клиентов с использованием своего продукта и как следствие там были не учтены многие элементарные моменты
    • 0
      Тут немного не о том я хотел сказать. Прежде чем дать оценку задачи я, в большинстве случаев, спрошу у программиста (а потом оценю реалистичность и введу коррективы, если посчитаю нужным). И потенциальному пользователю показывать систему обязательно. И это — факт.

      В слове про сроки ключевое слово было не «сроки» а «договариваться с заказчиком», а под тестированием понимается реальный процесс QA с составлением грамотных багрепортов и т.д. Здесь я хотел сказать, что каждый должен делать свою работу. Ну не заставлять же, в самом деле, маркетологов багрепорты писать в трекер.
  • 0
    А что автор хотел пообсуждать? не вижу никаких поднятых вопросов…
    • +1
      думаю это его рекомендации к действию и выводы из практического опыта
    • 0
      Ну, по большому счёту, хотебось бы понять, насколько это согласуется с практикой в других командах. Возможно, у кого-то появятся дополнительные идеи, которыми я сам смогу воспользоваться.
  • +5
    «На самом деле, в провале проекта никто кроме руководителя не виноват.»
    Вот за это 5. От этого и надо отталкиваться. В команде должно быть четкое распределение ответственности. Кто моет посуду, кто кофе греет, а кто за пиццей бегает иначе будет бардак, выяснение отношений и сваливание вины на других.
  • +1
    Интересно, а во всех странах принято вискарь директору вручать или это наше ноу хау?
  • 0
    А я то думаю, почему нет вакансий на ПМ в ИТ компании, а ПМов просто берут из программистов.
    По поводу поста вы сами написали Капитан Очевидность, то есть все в общем то очевидно и нет предмета для дискуссии. Если только кто опытом поделиться, опытом разруливания межличностных отношений в команде. К сожалению, человека действительно нужно постоянно мотивировать и работать с ним на психологическом уровне. Мне иногда кажется, что хорошим ПМом мог бы быть проф. психолог, а не программист.
  • +4
    Мое сугубо личное, к сожалению, подтвержденное опытом, мнение:

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

    — В 30% — настоящие руководители получаются из целеустремленных и профессиональных исполнителей, когда они очень много времени уделяют собственному образованию в менеджменте/психологии/социальном управлении.
    • 0
      Давай те не будем вводить людей в заблуждение — правильные цифры 50% и 50%. :) Вот например мой случай. Я появился на свет с врожденным повышенным уровнем ПМства в крови: в 1 год я уже строил игрушечные замки из кубиков, в 3 года — сдал на сертификат PMP, в 6 — открыл небольшую, я бы даже сказал микроскопическую, компанию по производству софта — микрософт :) Верите??? Есть только 2 фактора для становления настоящих руководителей: труд (книги и практика) и везение (вменяемое руководство, зрелая компания). Генетическая предрасположенность отражает лишь заложенный потенциал, да и то лишь в некоторой степени.
      • –1
        Сказок не бывает, поверьте
        • 0
          а как вы отличаете людей те которые «кристаллизируются и набираются практического опыта» от тех кто «очень много времени уделяют собственному образованию в менеджменте/психологии/социальном управлении»? Ведь чтобы посчитать проценты надо их как то отделять друг от друга?
          • 0
            Как минимум — реальное практическое/жизненное понимание и детальное знание развития профессиональной биографии того или иного руководителя.

            + Непосредственное практическое взаимодействие.

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

            Подобные вопросы, впрочем, достаточно академичны, всесторонний анализ даст вам ответы на все вопросы.
  • –3
    Пользуясь случаем, передаю привет Гошиному роботу-трансформеру.
  • 0
    Я не ПМ, но мое мнение о том, каким он должен быть, полностью совпадает с вашим.
  • +2
    Про «уволить человека с которым пил пиво» написано — но углублю. Не только уволить, но и просто сделать замечание, поручить делать непопулярную/неинтересную часть проекта, в конце концов, заставить отвечать за сроки — очень психологически тяжело. Причем насколько руководителю, настолько и подчиненному. Поэтому панибратство и тесное дружеское общение с подчиненными не очень хорошая штука. Я не говорю, что надо общаться высокомерно на «вы», но очень необходимо найти этот предел с каждым подчиненным…

    По поводу квалификации руководителя не совсем согласен — она однозначно в его 80% должностных обязанностей должна быть выше подчиненных. Если руководителю приходится кодить (ну бывает так, да) — кодить он должен лучше. Если нет — подчиненные должны понимать что их квалификация как менеджеров на порядок ниже. Т.е. не должно возникать разговоров типа «а хули ты тут с умным видом вещаешь — я тоже могу встать порулить». Как только что-то подобное почувствовали — надо что-то делать, иначе через некоторое время от субординации ничего не останется.

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

    Не освещен момент про набор/выбор подчиненных — если это делает ПМ — определяющий всю дальнейшую работу процесс. Месяц-два, без отрыва от текущей работы, с простыми некоммерческими тестовыми заданиями, несколькими беседами и пр. На рынке труда ходит куча дятлов, которые хотят сесть на пригретое место, получать потихоньку оклад, делать видимость работы и придумывать очередные отмазки. Сталкиваюсь лично…

    Если вы руководитель без году неделя (ну, год-два), надо всегда помнить, что в этом временном промежутке карьеры отдача падает в разы, а затрат энергии получается в разы же больше — по сравнению с предыдущей областью работы (инженер, кодер). Так вот надо об этом помнить, не пугаться и не отчаиваться. Оно пройдет, как только перейдете на этот новый уровень. Эт правда не мой вывод, это меня так старшие товарищи учат =)
    • 0
      Мне кажется, что для ПМа, не то что разговоры, но даже мысли, о субординации, подчиненных, власти очень опасны :). Заставить кого то делать то, что тебе хочется, приказом или угрозами — это очень очень тяжело. А креативную и творческую личность разработчика — тяжело вдвойне. Я ассоциирую себя в проекте как помощника разработчику — т.е. мы вместе делаем продукт, только просто обязанности и активности разные. Иногда слышу от разработчиков (в шутку надеюсь), что я ничего не делаю в проекте — но трактую это как похвалу, так как «Хорошо сделанная ПМом работа — не заметна» :) Когда разворачивается сражение на поле боя (активная фаза кодирования\разработки в проекте), я стою с биноклем на вершине горы (мания величия???) и смотрю что происходит и не надо ли где нибудь подкорректировать что то, так как моя работа уже сделана — планы атаки согласованы и утверждены, обозы с продовольствием готовы, транспорт заправлен горючим :).
      • 0
        Нуну. В таком случае рад, что у вас пока что-то получается.
        • 0
          она: тебе нравится программировать?
          он: да!
          она: охренеть…
          он: а тебе что ли не нравится?
          она: а с чего бы мне нравилось? )
          он: ну смотри
          int i = 5;
          разве это не круто? ты сказала, что в i будет 5 и оно там реально будет. А почему? Потому что ты так сказала! власть!
      • 0
        Тут есть очень тонкая грань, которую переступать нельзя, но вплотную подходить — обязательно. Грань между «что тебе хочется» и «что необходимо делать для успеха проекта».

        Если программист отказывается выполнять «недостойную его светлой головы» часть работы, необходимо его убеждать. Сделать всё возможное, чтобы убедить. А если не получится — то вариантов, кроме как надавить. к сожалению, не будет.

        Сразу оговорюсь, что при первой возможности от людей, которых невозможно убедить, а можно только заставить, надо избавляться. Второй вариант (причём, гораздо более правильный, на мой взгляд) — понять, что, если я не могу убедить своих людей что-то сделать, то, как руководитель, ценности представляю мало и лучше найти себе другую профессию.
        • 0
          даже если один раз надавить, то потом «светлая голова» сделает за вашей спиной вашу вуду-куклу и будет тыкать в нее иголки когда вы отвернетесь :)
          • 0
            Хороший ПМ таких людей видит и принимает меры, чтобы у них доступа к иголкам не было. А просто куклы — пусть его делает, может хобби у него такое, жалко то ли…
  • +1
    Правильные мысли, поддерживаю.

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

    Очень правильно это делают в японском менеджменте, где можно поругать своего руководителя и это считается нормой.
    • +1
      У нас в компании демократия :) Я как руководитель ругаю их, а они меня, хотя как правило я больше ругаю и но при этом более добро что ли + так чтобы смешно было :)
      • 0
        Тоже хороший подход! А не замечали какое-то стеснение, когда видно, что человек чем-то не доволен, но не «ругает» вас?
        • +2
          Бывает, нужно пытаться разговорить! Хотя бывает редко, они у меня разговорчивые, уже разговорил :)
    • +1
      Объявлял. Не под торжественные фанфары, конечно, а неявно. Были действительно очень хорошие идеи высказаны ребятами. Принял на вооружение и с успехом пользуюсь.
      • 0
        Если все правильно сделать, от сотрудников можно постоянно идеи получать и улучшать работу. Да и у них будет ощущение вовлеченности, ощущение, что они сами принимают активное участие в построении компании, а это приводит к лояльности, что очень важно.

        Я б на вашем месте явно объявил это, все люди разные и могут не сделать, пока не услышат про это прямо, но решать, конечно, только вам :)
  • 0
    я виду цитаты из знакомых книг, какие книги порекомендуете?
    • 0
      Собственно — книг много, но эти три стоит прочитать в первую очередь, ИМХО:

      Peopleware (Демарко, Листер) — must read. Плюс — всё, что можно найти у этих авторов
      Мифический человеко-месяц (Брукс). Классика, хоть и больше 25 лет книге
      Как пасти котов (Рейнвотер) — местами поподает в точку. местами — не очень (по крайней мере, я с ним не везде согласен. Плюс — перевод нудноват)

      • 0
        последние две читал — именно цитаты из них я и узнал. Есть что на замену?
  • 0
    последние две читал — именно цитаты из них я и узнал. Есть что на замену?
  • 0
    Тоже руковожу проектами, и совершенно вас не понимаю. По моему опыту, разрозненная, в идеале находящаяся в разных городах и не общающаяся в отрыве от работы группа разработчиков способна сделать большее, чем слаженная команда.

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

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

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

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

    А вывод, который я из всего этого сделал — нельзя сажать разработчиков в одном месте, и если тебе досталась сплоченная команда — сначала её нужно поссорить между собой и разбавить новыми людьми.
    • 0
      Георгий, кажется, что ваш комментарий лишний раз подтверждает то, что написано в статье. Простите, но буду говорить прямо.

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

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

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

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

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

      3. Затраты на коммуникацию у распределённой команды в разы выше, чем у команды, которая находится в одном месте. Доказано. Брукс.

      4. «Коллектив быстро принимает неоптимальное решение и ни в какую не соглашается его изменить, используя в свою защиту всё более глупые аргументы.» — к этому приводит не «соглашательство» и «ДК-эффект», а некорректно построенная работа с командой. Вы можете возразить, что «нянчиться с каждым программистом» — не ваша задача. Я придерживаюсь противоположного мнения.

      5. Эксперимент с командами ничего не доказывает. «Профессионализм» команды — вещь достаточно субъективная и не всегда коррелирует с её опытом разработки. Исходя из вашего рассказа, сделаю гипотезу, что во второй команде был человек, который принял на себя роль тимлида, а в первой грамотного лидера не было. Именно поэтому первая команда сплотилась вокруг не слишком компетентного, но харизматичного программиста и ушла в неконструктив. Я прав?
      • 0
        Не правы. Во второй (удаленной) команде я просто раздавал задачи и контролировал их выполнение. Не было ни команды, ни лидера, люди просто делали работу или в рамках своей компетенции объясняли, почему она невозможна. Идеал. Такого, чтобы кто-то говорил «Начальник дурак, он заставил меня делать нереальное, бредовое, давайте саботировать » — такого не было. Зато в первой команде было именно так. Ибо — состоявшийся коллектив. Они немного грызлись, у них недавно ушел старый лидер, но они были абсолютно уверены в своей компетентности, методах и способах. И это при том, что их веб-подразделение никогда не делало ничего прорывного и регулярно срывало сроки.

        И я не клал болт на работу. Я знаю про ошибку гиперопеки, что нельзя контролировать каждый шаг и делать всё за других. Первое время я только и делал что объяснял всем и каждому, пока у них не начала появляться гримаса страдания перед каждым таким разговором:) Извините за аналогию, но это было похоже на украинских майданщиков: «мы плевать хотели на мировой опыт, на логику, на законы — у нас своя логика, мы обсудили друг с другом и решили, что так лучше».

        Вообще, спасибо человеческое, что попытались вникнуть в мою проблему. Но имхо, примеры тут бессмысленны. Я закончу свой пример, чтобы больше не поднимать эту тему. Решение, которое было выигрышным, заключалосьв том, чтобы программисты-многостаночники освоили Parser-3 (поганую русскую поделку), на котором был написан движок работающего и приносящего доход сайта. Конечно, человек, который это предлагает — мудак и не понимает вещей, тут не может быть другого мнения:)
  • 0
    Слова все правильные, но увы… Пока везде действует железное правило: если руководитель начинает называет возглавляемое им подразделение словом «команда» — то пора валить куда подальше из этой «команды».

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.