3. Возьмите на себя реализацию одной из функций. Я буквально вздрагиваю, когда пишу это, потому что этот пункт таит в себе много скрытых опасностей, но я действительно не уверен в том, что вы сможете выполнить пункт № 1 и пункт № 2 без того, чтобы взять на себя реализацию хотя бы одной функции. Благодаря самостоятельной реализации одной из функций вы не только будете активно участвовать в процессе разработки, это также позволит вам периодически переключаться с роли «Руководителя, отвечающего за все» на роль «Человека, отвечающего за реализацию одной из функций». Эта скромная и непритязательная позиция будет напоминать вам о важности маленьких решений.
4. Я всё еще весь дрожу. Кажется, кто-то уже орет на меня: «
5. Пишите модульные тесты. Я все еще делаю это на поздних этапах производственного цикла, когда люди начинают сходить с ума. Рассматривайте это как чек-лист работоспособности вашего продукта. Делайте это часто.
Снова возражение?
Хорошо.
Да, я сказал: «Хорошо!» Я рад, что вы считает, что сможете сбить с толку свою команду лишь тем, что плаваете в пруду разработчиков. Тут всё просто: границы между различными ролями в сфере разработки софта в настоящий момент сильно размыты. Парни, занимающиеся пользовательским интерфейсом, делают то, что можно в целом назвать программированием на JavaScript и CSS. Разработчики всё больше и больше узнают о проектировании взаимодействия с пользователем. Люди общаются друг с другом и узнают об ошибках, о воровстве чужого кода, а также о том, что не существует никакой уважительной причины для того, чтобы руководитель не мог участвовать в этой массивной, глобальной, перекрестно опыляющейся информационной вакханалии.
Кроме того, вы же хотите быть частью команды, состоящей из легкозаменяемых составных элементов? Это не просто сделает вашу команду более проворной, это даст каждому ее члену возможность видеть продукт и компанию с самых разных точек зрения. Как вы сможете еще сильнее зауважать Фрэнка, того спокойного парня, ответственного за компоновку, если не после того, как увидите простую элегантность его сборочных скриптов?
Я не хочу, чтобы в вашей команде царили путаница и хаос. Напротив, я хочу, чтобы коммуникация в вашей команде стала более эффективной. Я уверен в том, что если вы сами участвуете в создании продукта и работаете над функциями, вы будете ближе к своей команде. И что еще более важно — вы будете ближе к постоянным изменениям в процессе разработки софта в пределах вашей организации.
Не переставайте разрабатывать
Одна моя коллега из Borland однажды вербально атаковала меня за то, что я назвал ее «кодером».
«
Она была права, она бы возненавидела мой первоначальный совет новоиспеченным руководителям: «Перестаньте писать код!» Не потому, что тем самым я как бы предполагаю, что они — кодеры, а больше потому, что я проактивным образом предлагаю им начать игнорировать одну из самых важных частей их работы — разработку ПО.
Итак, я доработал свой совет. Если вы хотите быть хорошим руководителем, то вы можете перестать писать код, но…
8 То, что нужно обязательно сделать. —
19. Сотрите их в порошок!
Существуют три лидерские роли
Когда я выступаю как спикер, я обычно начинаю с нескольких вопросов, которые помогают мне познакомиться с аудиторией. Моя цель — выявить парочку ключевых демографических типажей, чтобы оценить, на чем мне нужно фокусироваться, и отрегулировать присутствие разных тем в каждом конкретном выступлении. Как правило, я задаю следующие вопросы:
• Кто из вас может назвать себя самопровозглашенным яблочником? (Шутки про визуальное оформление = ОК.)