Как из гиков собрать команду программистов
Автор: Нана Альгарад
Источник: Searchengines.ru
Совершенно замечательное пособие по социологии, технике и технологиям коммуникаций для всех, занятых в сфере разработки ПО. Именно для всех. В оригинале книга "Идеальная IT-компания" называется «Team Geek. A software developer’s guide to working well with others», и адресована она не только потенциальным «сборщикам команд», но и непосредственно тем, кто работает с кодом.
Авторы книги — программисты, прошедшие путь от сисадминов до руководителей проектов. Все, о чем они пишут, они знают из собственной практики. На момент написания книги — в оригинале она вышла в свет в 2012 году — Брайан Фитцпатрик (Brian Fitzpatrick) возглавлял команды Data Liberation Front и открытого инжиниринга Transparent Engineering в компании Google, а Бен Коллинз-Сассмэн (Ben Collins-Sussman), один из первых разработчиков системы контроля версий Subversion, работал менеджером команды инженеров партнерской сети Google.
Вообще, это первая книга, посвященная управлению, которая признает, что слово маркетинг вызывает у инженеров — разработчиков софта негативные эмоции и представление «ушлого менеджера с фальшивой улыбкой и прилизанными волосами». Что регулярное пение корпоративных речовок вызывает у технарей глубокое отвращение. Что существуют не только вредоносные программы, но и вредоносные люди — для работы команды, естественно. Что непрерывный контроль не повышает, а понижает эффективность работы и, наконец, что не стоит насильно толкать людей вверх по карьерной лестнице — можно приобрести посредственного менеджера и потерять блестящего программиста.
Основой для социального взаимодействия в команде Бен и Фитц называют «три кита»: скромность, уважение, доверие. Соблюдение каждого из этих принципов авторы считают абсолютно обязательным для всех членов эффективной команды, включая лидера.
Поскольку авторы много занимались разработкой проектов с открытым кодом, немалая часть советов в книге посвящена именно этой теме: как организовать такой проект, как фиксировать авторство и стоит ли это делать вообще, как наладить общение между разработчиками при парном программировании или удаленной работе и избавиться от «троллей».
Тема «троллей», или вредоносных людей здесь рассматривается в самом общем смысле, не только сетевом. Любой, кто своим поведениям или действиями влияет на климат команды, нарушая принципы скромности, уважения и доверия, наносит команде вред. Причем это может быть прекрасный программист, дающий рецензии на код коллег в хамской форме, и «революционер», начинающий бурные дискуссии по любому поводу. Авторы советуют для начала попытаться их обезвредить — попросту, поговорить наедине, попросить подкорректировать поведение. Если не изменится — прощаться независимо от технических навыков: вовремя не «вылеченный» вредоносный человек способен развалить всю команду.
Менеджерам авторы отводят роли лидера-слуги — человека, который обеспечивает команду всем необходимым для работы (включая советы и решения), защищает от бурь внешнего мира — если речь идет о крупных корпорациях, и помогает в работе. При этом оптимально, чтобы как программист он по уровень был не ниже уровня сложившейся команды, нанимал людей более сильных специалистов и постоянно учился. Впрочем, это касается всех членов команды.
Что расти в карьерном отношении все-таки стоит, Бен и Фитц стараются убедить программистов в главе с честным названием «Искусство корпоративной манипуляции». Основной аргумент — когда стоишь на вершине, больше шансов выжить при потопе. В этой же главе они признают, что многие коллеги работают в «плохих» компаниях или с плохим руководителем, и предлагают инструменты выживания в такой ситуации. Если ни один не работает, выход один — эвакуация.
Наконец, пользователи — тоже люди, напоминают авторы программистам. И правильно делают. Речь идет о двух моментах — поведенческом и собственно программном. Мне не раз обычные граждане жаловались на IT-отделы своих компаний — мол, программисты высокомерные, хамят и пр. Бен и Фитц напоминают акулам кода: навыки пользования компьютерами и ПО, знание терминологии ничего не говорят об интеллектуальном уровне пользователя. Если вас попросить, к примеру, вставить стекло вместо разбитого, попутно назвав все инструменты и свои действия правильными терминами, или приготовит тесто, вы будете выглядеть такими же идиотами. Так что не надо считать маразматичкой бабушку, которая не понимает, где папка, а где — ярлык. С другой стороны, даже опытные пользователи (среди которых такие же программисты) делают оценку софта на основе первого впечатления. Первые минуты работы решают все. Если пользователь не может сходу разобраться в меню, в том, как применить элементарные функции — он снесет вашу программу при всех ее внутренних достоинствах. Он просто до них не доковыряется. Сплошь и рядом битву за пользователя выигрывает не самый мощный или надежный, а самый простой для пользователя софт. Игнорировать это нельзя. «Три кита» должны применяться и к пользователям.
«Если вы построите свою работу на скромности, уважении и доверии, то достигнете прекрасных результатов, затратив меньше усилий. Мы полагаем, что это лучший способ уделять максимум времени любимому делу (созданию замечательных программ) и сводить к минимуму участие в социальных конфликтах, бюрократических процедурах и прочих человеческих драмах», — пишут Бен и Фитц. И признаются, что все изложенные в книге подходы и принципы (помимо специфичных для программирования) посвящены поддержке любого здорового и эффективного сообщества.
|