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