[Перевод] Как программистам не дают больше ничем заниматься
Способность программировать — один из немногих навыков, который ограничивает вас в глазах окружающих.
Я был менеджером по продукту, менеджером проекта, скрам-мастером и владельцем продукта, инженером по юзабилити и делал кучу других вещей. Я могу проектировать интерфейсы по результатам собеседований с пользователями, могу руководить и обучать команды, распределять работу до дедлайна и запускать проекты. Всё это я делал, и успешно.
Но как только я упоминаю, что пишу код, то становлюсь «разработчиком». Полный стоп. Теперь обязательно нужно назначать менеджера проекта, который определит мне задание. Кто-то напишет техническое задание, по которому я должен дать оценку времени выполнения. Я больше не говорю с клиентами и должен периодически отчитываться о выполненной работе.
Это очень любопытный феномен, который я наблюдал неоднократно, во многих ситуациях и организациях, и не только со мной. Дошло до того, что теперь в некоторых проектах я активно избегаю писать код (или притворяюсь, что не умею), потому что хочу добиться доверия со стороны пользователя или заказчика (например), чтобы он разрешил мне заниматься планированием и составлением технических заданий. Но как только я что-нибудь напишу, то сразу становлюсь в команде «разработчиком». И останусь им навсегда.
В то же время выделенные менеджеры проектов сильно тяготеют к гармоничным разработчикам, которые способны на большее, чем просто писать код. Они исключительно рады работать с инженерами, которые хорошо общаются, способны создать рабочую архитектуру (не только на техническом уровне, но и на уровне проекта/бизнеса) и могут предвидеть сценарии использования продукта. Неудивительно; этих способностей не хватает им самим, они заполняют пустые места. Однако во многих проектах такое разделение обязанностей только добавляет лишний слой коммуникации, без которого гармоничный разработчик часто мог бы лучше выполнить свою работу.
Сначала я думал, что этот феномен в основном связан с возрастом. Если вы относительно юны и соглашаетесь быть программистом, то людям легче смотреть на вас как на типичного разработчика, вдохновлённого духом Кремниевой долины; эдакий живущий в каморке, одетый в балахон антисоциальный парнишка-гик. Но я видел, как то же самое происходит с опытными инженерами более старшего возраста.
Эти инженеры наблюдали, как компании появляются и исчезают, они начинали свои стартапы, работали в компаниях на разных уровнях и в разных ролях, у них всесторонние технические знания, которые делают их настолько ценными во всех ролях. Представим, что рядом будет другой человек (обычно «пиджак») и они отправятся на встречу к клиентам. Если клиентам сказать, что у одного из них всесторонние технические знания — все автоматически примут его за «технаря». По вопросам стратегии, планирования и так далее они будут обращаться к «пиджаку». Хотя инженер мог бы гораздо компетентнее обсудить эти вопросы.
Почему так? Почему такая острая необходимость поставить клеймо на парне с техническим образованием и отстранить его от участия в других областях?
Может быть, потому что люди склонны раскладывать всё по полочкам, относить вещи к разным категориям. В идеале, все вещи в жизни имеют единственную задачу и цель, так что вы можете сказать: «Это топор, им можно рубить» или «Это монитор, он показывает изображение». Так всё становится понятным и предсказуемым. Конечно, именно так мы разрабатываем и хорошее программное обеспечение, посмотрите хотя бы на философию Unix.
Но конечно люди не такие. Мы машины, польза которых постоянно изменяется и совершенствуется. Чем больше человек знает, чем больше он видел и где побывал, тем лучше и гармоничнее он подойдёт для любой данной задачи. Мы признаём это развитие опыта в рамках единственной роли, но почему-то не между разными ролями.
Я считаю, что умение программировать никогда не должно лишать права активнее участвовать в проекте. Наоборот: это делает человека более квалифицированным по сравнению с теми, у кого такой навык отсутствует. Если вы способны вывести стратегические обсуждения напрямую на конкретный технический уровень и пройтись по нему логическим умом разработчика, то это гораздо более ценно, чем пустая болтовня «пиджаков». Вы можете обсудить проблему пользователя и немедленно понять последствия всех возможных решений в системе — и не обязательно потому что вы создали эту систему, а потому что способны вывести технические последствия из опыта. Тогда вы с пользователем примете более информированное решение прямо на месте.
В моей идеальной команде каждый способен выполнять работу любого другого, но просто выбрал специализацию, которая ему больше нравится. Непрерывная смена ролей поощряется, линии связи оптимизируются, а набор ролей часто пересматривается. Такой идеал не совсем реалистичен в специализированных профессиях, но идеал — это не то, что достижимо, а то, к чему нужно стремиться.
Вот почему я думаю, что каждый разработчик должен стремиться к гармоничному развитию, тогда он сможет не только писать код, но и вносить свой вклад на разных уровнях. А для этого важно поощрять, а не запрещать разработчикам расширять свою роль.
