Как управлять интеллектуалами. Я, нерды и гики

Мы платим этим типам из руководства реально большие деньги, а они думают такую чушь. Еще раз: моя ключевая идея состоит в том, что на нашей планете множество гениальных и очень усердных разработчиков; они действительно гениальны и усердны, хотя и не потратили ни одной минуты на сидение в аккредитованных университетах. О да, сейчас таких становится всё больше и больше!

Я не предлагаю вам начать беспокоиться за свое место лишь потому, что некие гениальные товарищи якобы на него охотятся. Я предлагаю вам начать беспокоиться за него, потому что эволюция разработки ПО, возможно, движется быстрее, чем вы. Вы работаете уже десять лет, из них пять лет как руководитель, и думаете: «Уж я-то знаю, как разрабатывается софт». Да, вы знаете. Пока…

Прекратите писать код, но…

Если вы будете следовать моему первоначальному совету и перестанете писать код, то одновременно вы по собственному желанию перестанете участвовать в процессе создания. Именно по этой причине я не особо активно использую аутсорсинг. Автоматы не создают, они производят. Хорошо разработанные процессы позволяют экономить много денег, однако они не привнесут в наш мир ничего нового.

Если у вас небольшая команда и она делает много за небольшие деньги, то идея прекратить писать код кажется мне плохим карьерным решением. Даже в компаниях-монстрах с их бесконечными регламентами, процессами и политикой вы не имеете права забыть, как самостоятельно разрабатывать софт. А разработка софта непрерывно меняется. Она меняется прямо сейчас. У вас под ногами! В эту самую секунду!

У вас есть возражения. Понимаю. Давайте послушаем.

• «Рэндс, я на пути в директорское кресло! Если я продолжу писать код, никто не поверит, что я способен расти».

Я хочу спросить вас вот о чем: с тех пор, как вы сели в свое кресло «Я скоро стану директором!», замечали ли вы, что сфера разработки соф­та меняется даже в пределах вашей компании? Если ваш ответ «да», то я задам вам другой вопрос: как именно она меняется и что вы собираетесь предпринять в связи с этими изменениями? Если на мой первый вопрос вы ответили «нет», то вам нужно пересесть в другое кресло, потому что (зуб даю!) сфера разработки софта меняется в эту самую секунду. Как вы вообще собираетесь расти, если вы медленно, но верно забываете, как разрабатывать софт?

Мой совет состоит не в том, чтобы поручить себе реализацию тонн функций для вашего следующего продукта. Нужно постоянно принимать меры, чтобы оставаться в курсе того, как ваша команда создает софт. Вы вполне можете делать это и будучи директором, и будучи вице-президентом. Что-то еще?

• «Уф, Рэндс! Но ведь кто-то должен быть арбитром! Кто-то должен видеть общую картину. Если я буду писать код, то я потеряю из виду перспективу».

Вы по-прежнему должны оставаться арбитром, вы по-прежнему должны транслировать решения, и вы по-прежнему каждое утро понедельника должны четыре раза обходить всё здание вместе с одним из своих инженеров, чтобы в течение 30 минут слушать его еженедельную тираду «Мы все обречены!». Но помимо всего этого, вы должны сохранять в себе инженерный образ мышления, а для этого вам не обязательно быть программистом на полную ставку.

Мои советы по сохранению инженерной ментальности:

1. Используйте среду разработки. Это значит, что вы должны быть знакомы с инструментарием своей команды, включая систему сборки кода, контроль версии и язык программирования. В результате этого вы будете владеть языком, которым ваша команда пользуется, когда говорит о разработке продукта. Это также позволит вам продолжать использовать ваш любимый текстовый редактор, который отлично функционирует.

2. Вы должны уметь нарисовать подробную архитектурную схему, описывающую ваш продукт, на любой поверхности и в любое время. Сейчас я не имею в виду упрощенный вариант с тремя ячейками и двумя стрелочками. Вы должны знать детальную схему продукта. Самую сложную. Не просто какую-нибудь симпатичную схему, а схему, которую трудно объяснить. Это должна быть карта, пригодная для полнейшего понимания продукта. Она постоянно меняется, и вы всегда должны знать, почему произошли те или иные изменения.