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