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

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

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

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

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

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

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

3. Возьмите на себя реализацию одной из функций. Я буквально вздрагиваю, когда пишу это, потому что этот пункт таит в себе много скрытых опасностей, но я действительно не уверен в том, что вы сможете выполнить пункт № 1 и пункт № 2 без того, чтобы взять на себя реализацию хотя бы одной функции. Благодаря самостоятельной реализации одной из функций вы не только будете активно участвовать в процессе разработки, это также позволит вам периодически переключаться с роли «Руководителя, отвечающего за все» на роль «Человека, отвечающего за реализацию одной из функций». Эта скромная и непритязательная позиция будет напоминать вам о важности маленьких решений.

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

5. Пишите модульные тесты. Я все еще делаю это на поздних этапах производственного цикла, когда люди начинают сходить с ума. Рассматривайте это как чек-лист работоспособности вашего продукта. Делайте это часто.

Снова возражение?

• «Рэндс, если я буду писать код, то я буду сбивать с толку свою команду. Они не будут знать, кто я — руководитель или разработчик».

Хорошо.

Да, я сказал: «Хорошо!» Я рад, что вы считает, что сможете сбить с толку свою команду лишь тем, что плаваете в пруду разработчиков. Тут всё просто: границы между различными ролями в сфере разработки софта в настоящий момент сильно размыты. Парни, занимающиеся пользовательским интерфейсом, делают то, что можно в целом назвать программированием на JavaScript и CSS. Разработчики всё больше и больше узнают о проектировании взаимодействия с пользователем. Люди общаются друг с другом и узнают об ошибках, о воровстве чужого кода, а также о том, что не существует никакой уважительной причины для того, чтобы руководитель не мог участвовать в этой массивной, глобальной, перекрестно опыляющейся информационной вакханалии.

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

Я не хочу, чтобы в вашей команде царили путаница и хаос. Напротив, я хочу, чтобы коммуникация в вашей команде стала более эффективной. Я уверен в том, что если вы сами участвуете в создании продукта и работаете над функциями, вы будете ближе к своей команде. И что еще более важно — вы будете ближе к постоянным изменениям в процессе разработки софта в пределах вашей организации.

Не переставайте разрабатывать

Одна моя коллега из Borland однажды вербально атаковала меня за то, что я назвал ее «кодером».

« Рэндс, кодер — это безмозглая машина! Обезьяна! Кодер не делает ничего важного, кроме написания скучных строчек бесполезного кода. Я не кодер, я разработчик софта !»

Она была права, она бы возненавидела мой первоначальный совет новоиспеченным руководителям: «Перестаньте писать код!» Не потому, что тем самым я как бы предполагаю, что они — кодеры, а больше потому, что я проактивным образом предлагаю им начать игнорировать одну из самых важных частей их работы — разработку ПО.

Итак, я доработал свой совет. Если вы хотите быть хорошим руководителем, то вы можете перестать писать код, но…

Будьте гибкими. Помните, что значит быть инженером, и не переставайте разрабатывать софт .

8 То, что нужно обязательно сделать. — Примеч. пер

19. Сотрите их в порошок!

Существуют три лидерские роли

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

• Кто из вас может назвать себя самопровозглашенным яблочником? (Шутки про визуальное оформление = ОК.)

• Много ли среди присутствующих инженеров? (Программистские шутки = ОК.)

• Сколько человек в аудитории имеют степень MBA? (Юмор по поводу табличных расчетов = ОК.)

И последнее, если разговор как-то связан с лидерством, то я задаю дополнительный вопрос: «Много ли среди присутствующих руководителей?»