Пользователь
0,0
рейтинг
23 апреля 2013 в 07:11

Управление → Кен Нортон. Как работать с программистами перевод

Я работаю в сфере IT 20 лет, последние 13 — в качестве руководителя проектов. Так получилось, что за это время я заслужил репутацию менеджера, эффективно работающего с программистами. Благодаря этому навыку я вошел в историю как один из трех величайших руководителей проектов и направлений – наряду с Николо Маккиавели и Стивом Джобсом.

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

Собственно, с какой стати вам вообще меня слушать? Просто взгляните на цифры. За свою карьеру одного из трех величайших руководителей проектов всех времен и народов мне довелось поработать примерно с 3 875 000 программистов. Из них все мои поручения в точности выполняло более 95% – т.е. целый 1 000 000 программистов (оценка приблизительная – руководителям проектов, честно говоря, не до математики). Это гигантское количество и гигантский опыт, который, безусловно, стоит принять во внимание.

1. Приписывайте все заслуги себе.

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

2. Не берите на себя вину.

Нет-нет, что-нибудь да пойдет вкривь и вкось. И в случае разработки ПО, вкривь и вкось, как правило, идет ПО. Если программа не работает, виноват программист. Это чистой воды логика. Так что, когда обвиняют вас, переводите стрелки, а по возможности подготавливайте почву для выбора «козла отпущения» заблаговременно. Помните: «мы» не имеет ничего общего с «я» (за исключением того, что это местоимения).

3. Не заморачивайтесь насчёт деталей.

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

4. Привлекайте их в конце.

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

5. Как следует упорядочьте их работу.

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

6. Никогда не говорите о причинах решений.

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

7. Берите обязательства, ни с кем не советуясь.

Одна из ваших функций в качестве руководителя проекта – брать на себя обязательства от имени команды. Быть лидером – это значит задрать планку в космос и поставить перед всеми цель через нее телепортироваться. Утверждайте сроки проекта, не советуясь с вашей командой – тем самым вы проявите здоровое честолюбие. Ситуация, в которой человек вынужден отвечать за чужие обещания, закаляет характер и раскрывает его лучшие черты. Вспомните президента Кеннеди. Он назначил дату высадки на Луну «от фонаря» и НАСА прекрасно справилось, в итоге закрепив лунные минеральные ресурсы за компанией «Стандарт Ойл».

8. Не стесняйтесь отвлекать их от работы.

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

9. Будьте неоднозначны.

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

10. Они всё время врут.

Бывает, программисты говорят, что то или иное «невозможно». Это вранье. В программировании нет ничего невозможного, если только хорошенько пораскинуть мозгами. Братьям Райт даже в голову не приходило, что невозможно перелететь через Антлантику! Всегда исходите из предположения, что программист хочет обвести вас вокруг пальца, и поступайте соответственно. Скажем, впредь, когда вы услышите фразы вроде «технический долг» или «работаю дома», будьте готовы тут же уличить его во лжи.

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

Послесловие

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

  • 1. Не приписывайте себе все заслуги.
  • 2. Принимайте вину на себя.
  • 3. Прорабатывайте детали.
  • 4. Привлекайте программистов на ранней стадии.
  • 5. Упростите их работу.
  • 6. Всегда говорите о причинах решений.
  • 7. Никогда не берите обязательства, не посоветовавшись с программистами.
  • 8. Уважайте их время.
  • 9. Будьте точны и однозначны.
  • 10. Доверяйте программистам.

И наконец…
  • 11. Всегда приносите печеньки.
Перевод: Kenneth Norton, руководитель группы проектов в Google
Сумма технологий @sumteh
карма
2,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Такое ощущение, что до конца вы так и не дочитали.
  • +2
    Мне кажется или это полностью объясняет то, что о нем мало кто слышал?
    • 0
      Ну он был PM в Yahoo, сейчас уже много лет PM в google (занимается google+). Как велик шанс прославиться у сотрудника google, одного из 50000?
  • +7
    Всё здорово, а больше всего я за 11 пункт!

    PS: люди, которым не нравится статья, вы точно послесловие прочитали?
    • 0
      Конечно, это же метод глобального пряника…
    • 0
      Больше всего не понятно, как можно с первых строк пунктов не догадаться, что это сарказм.
  • –5
    «Благодаря этому навыку я вошел в историю как один из трех величайших руководителей проектов и направлений – наряду с Николо Маккиавели и Стивом Джобсом.»
    Самоирония — это замечательно. Если это конечно ирония…

    «довелось поработать примерно с 3 875 000 программистов»
    «все мои поручения в точности выполняло более 95% – т.е. целый 1 000 000 программистов»
    У меня с арифметикой проблемы или?..
    • +13
      Руководителям проектов не до математики… (с)
    • +20
      Или с чувством юмора :)
      • +3
        Видимо, слишком тонкий юмор, не уловил.
        • +4
          Ну, в остальном он до таких тонкостей не опускался. Если честно, мне уже немного поднадоел такой топорный стиль «вредных советов», как в этих «десяти заповедях». Хотя, возможно в оригинале все это несколько более изящно реализованно, как знать.
  • 0
    Ничего особенного, но весело написано :)
  • 0
    Макиавелли зовут Никколо. Он не какой-то там «Ник».
    • 0
      Один из трёх величайших руководителей проектов вполне может называть другого запросто, по-дружески.
      • –3
        У них разница в 400 лет, какие еще «по-дружески»?
        • +7
          здесь нужно больше пафоса и очки в роговой оправе
        • +2
          Пускай будет «фамильярно».
  • 0
    Интересно, Кен Нортон знает что Джобс нарушал 1 пункт, и некоторых кто с ним работал это бесило.
  • +2
    В иллюстрации не хватает «Безумный, просто Безумный» :)
  • +2
    А «Сумма технологий» — это скромненько так назвали фирму? Ну типа Джобс-Макиавелли-Я и Лем-Уэлс-Я?
    • 0
      • 0
        Между прочим, сам факт, что автор-американец это читал, делает его не просто гиком-любителем НФ, а Гражданином Земли с большой буквы — это произведение никогда толком не публиковалось на английском языке и уж тем более не общеизвестно среди «читающих», как у нас.
  • +5
    «Послесловие» меня разочаровало:(
  • +1
    Применил все правила сразу и уже к часу дня все разбежались.
    Что я делал не так и кто возместит убытки?
    • +4
      Сразу видно, что вы не величайший руководитель проектов. Сначала надо было приковать (не обязательно в переносном смысле слова) программистов к рабочему месту, а потом уже применять правила!
  • 0
    Так зачем вам впустую тратить время программистов, привлекая их к проекту до стадии программинга? Прийдя в офис к архитектору, вы не встретите там пинающих балду строителей. Зовите их, только когда вы продумали всю стратегию, все со всеми обсудили, и осталось только написать код.

    А вот здесь «совет» не однозначный. Действительно, зачем привлекать программистов на стадии обсуждения архитектуры или бизнес-задач проекта с архитектором, аналитиком или инженером? Последние должны знать как предметную область, так и возможности программирования, и выдавать реальное ТЗ для программистов. Естественно, подразумевается, что все роли в процессе проектирования и разработки ПО распределены по разным людям и программист программирует, а архитектор проектирует и осуществляет авторский надзор.
    • +1
      А еще это частенько заставляет нарушать пункт 5, отвлекая программистов от выполнения текущего проекта на планирование следующего, который возможно будет начат буквально с года на год. И, конечно же, эти проектные совещания не входят в план ни одного из проектов разработки, соответственно финансируются за счет разработчиков.
      Это, безусловно, необходимо, но нужен баланс и понимание от менеджеров за счет чьего времени проводятся эти совещания.
    • +1
      Прочитайте послесловие.
      • 0
        Я прочитал. Я про то, что совет выглядит разумным, а не вредным. Руководителю проекта (внутреннему заказчику) действительно обычно нет нужды обращаться к программистам (рядовым исполнителям) и обсуждать с ними детали реализации, иначе рискует погрязнуть в деталях, а то и холиварах тиа какой фреймворк или либу выбрать, а может писать велосипед. Должна быть иерархия, по-моему. Как минимум трехуровневая: руководитель (менеджер) проекта, решающий бизнес-задачи — архитектор (аналитик, ведущий инженер-программист и т. п.), конвертирующий их в технические — программисты, решающие технические задачи. Если второй уровень недостаточно компетентен и/или авторитетен среди исполнителей, чтобы принять глобальное техническое решение единолично, то он должен взять таймаут и обсудить проблему с исполнителями.
        • 0
          Руководителю проекта (внутреннему заказчику) действительно обычно нет нужды обращаться к программистам (рядовым исполнителям)
          Это смотря какие роли выполняет РП. В моей практике, например, заказчиком является не РП, а ПМ(продукт-менеджер).РП же — координатор исполнителей, планировщик, главный ответственный и приниматель оперативных решений.
  • 0
    del
    • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Слишком толсто. Надо чтобы мы начали о чем то догадываться где — то к середине, а не в начале.
    P.S не могу видеть уже печеньки, почему нету фрозен йогурта?
  • 0
    Отлично!

    Особенно «Прийдя в офис к архитектору, вы не встретите там пинающих балду строителей».

    Вообще, софт производства крупных компаний (почти всех) оставляет впечатление, что делали его по этому руководству.
  • +3
    К сожалению зная «как не надо» мы все равно не узнаем «как надо».
  • 0
    А чем таким руководил Макиавелли? Городской стражей?
    • +7
      «Не знаешь, кого упомянуть для пафоса — упомяни Макиавелли»
      (Конфуций)
    • +1
      Видимо имеется ввиду его труд «Государь» о природе власти
      • +1
        И философский труд от теоретика делает оного «величайшим руководителем проектов». Ок.
        • –1
          Почитайте что, зачем и для кого он написал, он не совсем теоретик, и как и большинство великих, формализовал то «что и так всем ясно».
  • 0
    до послесловия — хотелось прочно уйти во фриланс.
  • +2
    Слишком тонкая шутка для нашего цирка.
  • 0
    Так вот с кого слямзили в свое время друга Барби! Офигенный, просто офигенный!
  • 0
    Александр, перелогиньтесь! =)
  • 0
    Я знаю такого человека!
    Прямо как с него все писано… нда… это было что-то…
  • –2
    С очень многим не согласен. Например, возьму первые пункты только. «Приписывайте все заслуги себе». То есть пирог руководителю, а крошки от него команде? Руководитель без команды — ничто, а вот команда — уже хоть что-то.
    «Не берите на себя вину». Если кто-то в отделе косячит и вышестоящее начальство его гнобит, его руководитель должен и даже обязан его защищать и, возможно, даже брать вину на себя. Ведь это он ответственный за свою команду. Это важно.
    Да, кто-то накосячил, но на это были какие-то причины. Руководитель должен внутри своей команды решать такие вопросы и он должен на него как-то влиять. Но кто-то «из вне» не смеет предъявлять притензии работнику. Если руководитель будет это позволять делать, остальные участники команды увидят в своем руководителе подхалима к вышестоящему руководству и не будут видеть какой-то поддержки и, в конце концов, утратят доверие к нему.
    Про остальные пункты уже говорить не буду.
    • +1
      Послесловие.
  • 0
    Статья, похоже, задумана как «вредные советы», но по сути изложены весьма полезные и практичные идеи.
    Кроме «5. Как следует упорядочьте их работу.» и «8. Не стесняйтесь отвлекать их от работы.», пожалуй.
    Хотя, может и они имеют смысл.
  • 0
    А интересный подход — не сообщить что делать надо, а чего делать не надо. Я думал я один так размышляю.

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