Первая из статей, опубликованных на Хабре. Статья была написана в далёком 2009 году. Актуально, хотя материал и кажется слегка наивным...
Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.
Про команду
Я думаю, очевидно, что ни один проект не мог бы нормально завершиться (да и начаться) без команды, которая его выполняет. Тут главное понять, что бывает «команда», а бывает «группа разработчиков». В классике (Peopleware Демарко и Лестера) описан процесс «кристаллизации» команды. Поэтому, надо стараться максимально получить контроль над распределением людей в твоей команде на проекты и приложить все возможные усилия (от громкого возмущения до вискаря директору), чтобы не допустить их разделения, чтобы на всех проектах они работали вместе.
Кстати, работы над одним проектом совершенно недостаточно для создания команды. Над этим надо работать. Я встречался с «командой», которая скорее напоминает группу фрилансеров, которые почему-то собрались в одном офисе и сидят за соседними компьютерами. В принципе, я не считаю, что целенаправленный тим-билд (поездки «на пиво», совместные походы и т.д.) может улучшить ситуацию. По-моему, только ухудшит. Гораздо неприятнее увольнять или лишать премии человека, с которым пил пиво на прошлой неделе. Думаю, что достаточно, чтобы каждый член команды имел конкретно определённую роль в ней и, чтобы внутри проекта была непрерывная коммуникация (на которую, как говорил Брукс, тратится основное рабочее время). Формула 1+1 = 2,5 тут работает как нельзя более эффективно. И самое главное в команде – это взаимное уважение.
Очень важно добиться того, чтобы каждый член команды уважал остальных. А для этого, в первую очередь, надо уважать каждого руководителю. Да, действительно, Вася ленив, а Ася считает всех остальных идиотами. Гоша считает себя гораздо умнее, чем есть на самом деле, а Сёма пишет отвратительный код. Но при этом, никто не разбирается в Linux-системах лучше Васи, Ася, несмотря ни на что, очень неплохой архитектор, Гоша стремится писать аккуратный чистый код, а Сёма очень неплохо обучается. И это – главное.
Дайте понять (публично) Васе, что кроме него никто не смог бы написать этот скрипт автоматического развёртывания, похвалите Асину диаграмму классов и Гошин код, опять же, публично. Объясните Сёме, что он делает не так и, при всех, похвалите, как только его код станет улучшаться. Это очень многое. В команде появится уважение только тогда, когда вы будете над этим работать. И, главное, никогда публично не оскорбляйте своих ребят. Это позорно и непрофессионально. Да и ругать, желательно, отводя в сторонку и тихо (ну это уже общеизвестное правило). А вообще, каждый человек уникален, и это надо учитывать.
Обычно, с каждым человеком надо работать. И это одна из главных обязанностей (и головной боли) руководителя проекта. К сожалению, ПМы об этом часто забывают, заваленные с головой планами, сроками, требованиями и письмами неадекватного заказчика. Мне кажется, у любого разработчика есть ключ, который необходимо повернуть, чтобы заставить его работать эффективно. Этакая «точка G», помогающая добиться максимальной отдачи. (прошу прощение за слишком фривольное сравнение, поэтому назовём её лучше «точкой Е», от слова эффект). Более того, эта точка требует непрерывной стимуляции в течение всего времени работы.
Приведу пример: у нас работал человек, скажем, Вася, которого хотели уволить как совершенно некомпетентного. Причём не просто так, а по результатам нескольких проектов, которые «он завалил». Я попросил дать мне месяц на то, чтобы понять, почему специалист, которого я знал как «серьёзного компьютерщика, чуть ли не гуру» ещё со времён университета, показывает такие устрашающие результаты (потери исчислялись, кстати, десятками тысяч долларов в месяц). Всё оказалось просто и банально. Вася был отличный программист, но он совершенно не умел ставить себе задачи. И, как только требования были хоть немного неясны, он впадал в ступор, граничащий с летаргическим сном. Но стоило потратить пятнадцать минут, чётко сформулировать задачу и ожидаемый результат, как всё оказывалось сделано, причём быстро и качественно. После того, как мы стали работать в таком режиме, прогресс стал настолько очевидным, что его даже повысили в должности. Очевидно, что при этом необходимо минимальное понимание руководителем технологии, на которой происходит разработка.
Отлично, когда руководитель проекта имеет подробнейшее представление о технологии, которую использует его команда. Но это не главное (что бы ни говорил Рейнвотер, специалист по выпасу котов). Достаточно, чтобы у вас были такие специалисты, которым бы вы могли доверить техническую часть, сосредоточившись на управлении. Признаюсь, я имею только общие представления о том языке, на котором пишет моя команда. Иногда я думаю, это даже хорошо, так как иначе я обязательно навязывал бы свои, достаточно узкие, взгляды. Более того, я считаю очень важным, чтобы ПМы ни в коем случае не писали код сами. Ну, действительно, что будет, если программисты начнут договариваться с заказчиком о сроках, а специалисты по продажам – тестировать код? Как у Чуковского: «Свинки замяукали, кошечки захрюкали…» (полный текст этого бессмертного произведения смотрите здесь).
Разработчики должны быть в курсе текущего положения проекта, а также текущей ситуации в компании и перспектив её развития. Это неоднозначный тезис. Я более чем уверен, что многие перечислят некоторые вещи, которые доводить до разработчика совершенно не обязательно (например, сколько платит заказчик за час их работы). Но, реально, разработчик работает гораздо лучше, если чувствует, что от него ничего не скрывают. Пусть он знает, что заказчик платит по десять, двадцать, пятьдесят баксов за час его работы, а он при этом за этот же час получает в три, пять, десять раз меньше. Зато у него есть гарантированный заработок, стабильный доход и гарантия того, что зарплата будет выдана вовремя. Да и проекты самому искать не надо. С другой стороны, не стоит скрывать факты (да и причины) выхода проекта за бюджет и т.д. Если разработчик адекватный, он правильно поймёт, из-за чего проект провалился, и почему ему не выплатили премию.
Кстати, про провалившиеся проекты. К сожалению, от руководителей проектов иногда можно слышать высказывания типа: «Этот проект провалился из-за того, что программисты недостаточно квалифицированы, что они делают много ошибок. А Вася так вообще фрилансит по вечерам»). Отличный способ переложить всю вину на программистов (а, да, ещё тестеры не нашли ошибки вовремя, да и аналитик с требованиями накосячил).
На самом деле, в провале проекта никто кроме руководителя не виноват. И это очень важно! Не хватает квалификации у программистов – обучай, ищи подход, эту самую «точку E». Если человек «совсем деревянный» – никто не будет переживать, если его уволить, пока ещё не врос в команду, и заменить кем-то другим.
Если этим не заниматься, то проект будет на 90% провальным. Остальные 10%, скорее всего, говорят о том, что в данной команде ПМ не нужен в принципе.
Ваша команда – это ваше всё, поэтому очень важно, чтобы люди были довольны. Только от руководителя проектов зависит, насколько комфортные условия будут созданы команде и каждому человеку в отдельности. По большому счёту, именно ПМ определяет как карьерный, так и профессиональный рост своей команды. Поэтому, если вы считаете, что ваш сотрудник достоин повышения, то необходимо поставить это своей целью и добиваться всеми возможными способами. Оговорюсь, что рассматриваются, конечно же, исключительно профессиональные качества. Главное следить, чтобы личные привязанности или предвзятость не повлияли на принятие такого решения (опять же про вред совместного распития пива). Так что, над благополучием и комфортом людей тоже надо работать.
Выводы очевидны. Чтобы выполнять эффективные проекты, с командой надо работать. Это необходимое условие (но, конечно, не достаточное). Можно сформулировать так: невозможно достичь успеха в проекте, не имея слаженной и подготовленной проектной команды. Да здравствует капитан Очевидность!
Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.
Про команду
Я думаю, очевидно, что ни один проект не мог бы нормально завершиться (да и начаться) без команды, которая его выполняет. Тут главное понять, что бывает «команда», а бывает «группа разработчиков». В классике (Peopleware Демарко и Лестера) описан процесс «кристаллизации» команды. Поэтому, надо стараться максимально получить контроль над распределением людей в твоей команде на проекты и приложить все возможные усилия (от громкого возмущения до вискаря директору), чтобы не допустить их разделения, чтобы на всех проектах они работали вместе.
Кстати, работы над одним проектом совершенно недостаточно для создания команды. Над этим надо работать. Я встречался с «командой», которая скорее напоминает группу фрилансеров, которые почему-то собрались в одном офисе и сидят за соседними компьютерами. В принципе, я не считаю, что целенаправленный тим-билд (поездки «на пиво», совместные походы и т.д.) может улучшить ситуацию. По-моему, только ухудшит. Гораздо неприятнее увольнять или лишать премии человека, с которым пил пиво на прошлой неделе. Думаю, что достаточно, чтобы каждый член команды имел конкретно определённую роль в ней и, чтобы внутри проекта была непрерывная коммуникация (на которую, как говорил Брукс, тратится основное рабочее время). Формула 1+1 = 2,5 тут работает как нельзя более эффективно. И самое главное в команде – это взаимное уважение.
Про уважение
Очень важно добиться того, чтобы каждый член команды уважал остальных. А для этого, в первую очередь, надо уважать каждого руководителю. Да, действительно, Вася ленив, а Ася считает всех остальных идиотами. Гоша считает себя гораздо умнее, чем есть на самом деле, а Сёма пишет отвратительный код. Но при этом, никто не разбирается в Linux-системах лучше Васи, Ася, несмотря ни на что, очень неплохой архитектор, Гоша стремится писать аккуратный чистый код, а Сёма очень неплохо обучается. И это – главное.
Дайте понять (публично) Васе, что кроме него никто не смог бы написать этот скрипт автоматического развёртывания, похвалите Асину диаграмму классов и Гошин код, опять же, публично. Объясните Сёме, что он делает не так и, при всех, похвалите, как только его код станет улучшаться. Это очень многое. В команде появится уважение только тогда, когда вы будете над этим работать. И, главное, никогда публично не оскорбляйте своих ребят. Это позорно и непрофессионально. Да и ругать, желательно, отводя в сторонку и тихо (ну это уже общеизвестное правило). А вообще, каждый человек уникален, и это надо учитывать.
Про индивидуальность
Обычно, с каждым человеком надо работать. И это одна из главных обязанностей (и головной боли) руководителя проекта. К сожалению, ПМы об этом часто забывают, заваленные с головой планами, сроками, требованиями и письмами неадекватного заказчика. Мне кажется, у любого разработчика есть ключ, который необходимо повернуть, чтобы заставить его работать эффективно. Этакая «точка G», помогающая добиться максимальной отдачи. (прошу прощение за слишком фривольное сравнение, поэтому назовём её лучше «точкой Е», от слова эффект). Более того, эта точка требует непрерывной стимуляции в течение всего времени работы.
Приведу пример: у нас работал человек, скажем, Вася, которого хотели уволить как совершенно некомпетентного. Причём не просто так, а по результатам нескольких проектов, которые «он завалил». Я попросил дать мне месяц на то, чтобы понять, почему специалист, которого я знал как «серьёзного компьютерщика, чуть ли не гуру» ещё со времён университета, показывает такие устрашающие результаты (потери исчислялись, кстати, десятками тысяч долларов в месяц). Всё оказалось просто и банально. Вася был отличный программист, но он совершенно не умел ставить себе задачи. И, как только требования были хоть немного неясны, он впадал в ступор, граничащий с летаргическим сном. Но стоило потратить пятнадцать минут, чётко сформулировать задачу и ожидаемый результат, как всё оказывалось сделано, причём быстро и качественно. После того, как мы стали работать в таком режиме, прогресс стал настолько очевидным, что его даже повысили в должности. Очевидно, что при этом необходимо минимальное понимание руководителем технологии, на которой происходит разработка.
Про собственные технические навыки
Отлично, когда руководитель проекта имеет подробнейшее представление о технологии, которую использует его команда. Но это не главное (что бы ни говорил Рейнвотер, специалист по выпасу котов). Достаточно, чтобы у вас были такие специалисты, которым бы вы могли доверить техническую часть, сосредоточившись на управлении. Признаюсь, я имею только общие представления о том языке, на котором пишет моя команда. Иногда я думаю, это даже хорошо, так как иначе я обязательно навязывал бы свои, достаточно узкие, взгляды. Более того, я считаю очень важным, чтобы ПМы ни в коем случае не писали код сами. Ну, действительно, что будет, если программисты начнут договариваться с заказчиком о сроках, а специалисты по продажам – тестировать код? Как у Чуковского: «Свинки замяукали, кошечки захрюкали…» (полный текст этого бессмертного произведения смотрите здесь).
Про информацию
Разработчики должны быть в курсе текущего положения проекта, а также текущей ситуации в компании и перспектив её развития. Это неоднозначный тезис. Я более чем уверен, что многие перечислят некоторые вещи, которые доводить до разработчика совершенно не обязательно (например, сколько платит заказчик за час их работы). Но, реально, разработчик работает гораздо лучше, если чувствует, что от него ничего не скрывают. Пусть он знает, что заказчик платит по десять, двадцать, пятьдесят баксов за час его работы, а он при этом за этот же час получает в три, пять, десять раз меньше. Зато у него есть гарантированный заработок, стабильный доход и гарантия того, что зарплата будет выдана вовремя. Да и проекты самому искать не надо. С другой стороны, не стоит скрывать факты (да и причины) выхода проекта за бюджет и т.д. Если разработчик адекватный, он правильно поймёт, из-за чего проект провалился, и почему ему не выплатили премию.
Про виноватых
Кстати, про провалившиеся проекты. К сожалению, от руководителей проектов иногда можно слышать высказывания типа: «Этот проект провалился из-за того, что программисты недостаточно квалифицированы, что они делают много ошибок. А Вася так вообще фрилансит по вечерам»). Отличный способ переложить всю вину на программистов (а, да, ещё тестеры не нашли ошибки вовремя, да и аналитик с требованиями накосячил).
На самом деле, в провале проекта никто кроме руководителя не виноват. И это очень важно! Не хватает квалификации у программистов – обучай, ищи подход, эту самую «точку E». Если человек «совсем деревянный» – никто не будет переживать, если его уволить, пока ещё не врос в команду, и заменить кем-то другим.
Если этим не заниматься, то проект будет на 90% провальным. Остальные 10%, скорее всего, говорят о том, что в данной команде ПМ не нужен в принципе.
Про заботу
Ваша команда – это ваше всё, поэтому очень важно, чтобы люди были довольны. Только от руководителя проектов зависит, насколько комфортные условия будут созданы команде и каждому человеку в отдельности. По большому счёту, именно ПМ определяет как карьерный, так и профессиональный рост своей команды. Поэтому, если вы считаете, что ваш сотрудник достоин повышения, то необходимо поставить это своей целью и добиваться всеми возможными способами. Оговорюсь, что рассматриваются, конечно же, исключительно профессиональные качества. Главное следить, чтобы личные привязанности или предвзятость не повлияли на принятие такого решения (опять же про вред совместного распития пива). Так что, над благополучием и комфортом людей тоже надо работать.
Про выводы
Выводы очевидны. Чтобы выполнять эффективные проекты, с командой надо работать. Это необходимое условие (но, конечно, не достаточное). Можно сформулировать так: невозможно достичь успеха в проекте, не имея слаженной и подготовленной проектной команды. Да здравствует капитан Очевидность!
Комментариев нет:
Отправить комментарий