Слово «благовещение» я первый раз услышал в церкви еще ребенком. В религиозном контексте оно употребляется в совершенно четком смысле и обозначает распространение хорошей новости. Много позже я услышал этот термин в светской интерпретации от Microsoft – словосочетание «благовестник продукта»[81] показалось мне чрезвычайно точной характеристикой для восторженного молоденького преподавателя, к которому я ходил на курсы программирования. Способность передавать знания есть второй необходимый признак лидера. Иногда говорят: «тот, кто умеет, делает; тот, кто не умеет, преподает». Это изречение я считаю неверным и предлагаю встречную мысль: у того, кто не может адекватно изложить свои мысли, их слишком мало. Полагаю, что именно эта проблема обусловливает плохую передачу информации в бизнесе: недостаточное понимание проблемы порождает комплекс, в результате чего субъект, который, по смыслу, должен эту проблему доходчиво изложить, начинает надеяться на то, что окружающие смогут интуитивно разобраться в ней и уяснить свои задачи. Наитие выходит на первый план, если документацию с бизнес-требованиями по ночам не читать, а использовать по естественному назначению – в качестве подушки; впрочем, и наитие никогда не сможет заменить четкое изложение мысли.

Цель передачи знаний – обеспечить понимание персоналом предъявленных к продукту требований на том же уровне, на котором их понимает лидер. Итак, каким образом вам самому удалось понять проблему в комплексе? Восстановите последовательность действий, направленных на изучение требований, и перенесите ее на процесс обучения сотрудников. Тот, кто способен четко доносить свои знания до окружающих, сможет преуспеть в педагогике. Да, действительно, даже самый лучший учитель не может обойтись без заинтересованных учеников, но как лидер программистов вы располагаете в этом отношении существенным преимуществом – ваши «студенты» работают под вашим же началом, и никуда им от вас не деться. Может быть, они не всегда вас слушают, но ведь вы – шеф и поэтому располагаете методами принуждения к обучению. Поощрение, несомненно, выигрывает в сравнении с принуждением, но бывают ситуации, когда выбирать не приходится. Вернемся к основной мысли: если передача знаний равнозначна педагогической деятельности, то как лучше составить «план урока»? Элементы, приведенные в табл. 8.1, являются минимально необходимыми для адекватной передачи знаний.

Тот, кто способен четко доносить свои знания до окружающих, сможет преуспеть в педагогике.

Многие лидеры излишне увлекаются стилем – в основном по той простой причине, что у них не все в порядке с содержанием. Основное внимание нужно все-таки уделять содержанию, ну а тонкости изложения можно будет наработать с опытом. Перечисленные в табл. 8.1 элементы передачи знаний следует задействовать как при устном, так и при письменном общении.

Необходимо различать запланированный процесс передачи знаний и случайные разговоры на ту или иную тему. Поскольку вы – лидер, ваши замечания, пусть даже высказанные по случаю, зачастую воспринимаются сотрудниками как официальные распоряжения. Большую часть жизни мы доносим до окружающих информацию интуитивно, не пользуясь заготовками и отталкиваясь исключительно от текущего контекста. Различия между бессистемным и формальным мышлением следует обязательно иметь в виду; бывают ситуации, когда случайно высказанная мысль приводит к непредусмотренным разрушительным последствиям для бизнеса. Способность контролировать поле боя общения помогает выиграть битву понимания.

Способность контролировать поле боя общения помогает выиграть битву понимания.

Как лучше всего донести до программиста суть требований? Показать ему частично функционирующий макет. Даже одни пользовательские интерфейсы способны помочь программисту составить представление о задаче. Впрочем, не стоит сбрасывать со счетов архитектуру. Как я говорил в главе 6, прежде чем собирать урожай программных объектов, необходимо разбить сад, в котором вы намерены их выращивать.

Испытанный способ улучшить передачу знаний – обратиться к помощи UML, PowerPoint или Visio. Возможно, в вашей организации применяется оригинальный процесс документирования требований и составления проектных документов. Если это так, придерживайтесь его, а при необходимости адаптируйте к конкретному проекту. Впрочем, имейте в виду, что строить разработку программных средств исключительно на основе документов не стоит. Нередко такие важные элементы процесса передачи знаний, как макетирование и критический обзор предварительных аспектов реализации, просто-напросто игнорируются. Полагаю, что, став руководителем и лидером, вы начали испытывать ностальгию по кодированию. Если так, то, обратив внимание на два упомянутых элемента, вы сможете освежить навыки программирования и одновременно решить свою непосредственную задачу. Утверждения о «самодокументированности кода» слышны повсюду, но на самом деле они редко соответствуют действительности. Конструирование макетов как средств передачи знаний приносит пользу в двух отношениях: во-первых, удовлетворяет привычку к кодированию, во-вторых, помогает донести до окружающих ваше понимание решения поставленной задачи.

Объяснив подчиненным, какая задача перед ними стоит, заставьте их ее решить. Делегирование – это тоже искусство, а о том, почему оно является вашей главной обязанностью, я уже неоднократно говорил. Способность к делегированию – это одно из тех качеств, которое вы, лидер, должны постоянно совершенствовать. Косвенно этой темы я касался в главе 1. Сопоставив перечисленные в ней типы программистов с личностными качествами ваших сотрудников, вы сможете принять правильное решение относительно распределения задач между ними.

В идеале проект нужно разбить на рабочие единицы, которые впоследствии можно будет распределить между всеми разработчиками. Впрочем, на практике этот подход не всегда себя оправдывает. Может статься, что для решения отдельных задач по проекту или даже для комплексной его реализации лучше всего подходит ограниченная группа сотрудников. Иногда, в тех ситуациях, когда две головы лучше, чем одна, программистов имеет смысл разбивать по парам. Этот прием описан в методике разработки программных средств под названием экстремального программирования[82]. В рамках этой методики также культивируется другой тип делегирования – он предусматривает создание команды из двух программистов, в которой один пишет код, а другой ежедневно тестирует его и проводит критические обзоры. Если подобрать подходящих кандидатов (лучше всего – опытного программиста и новичка), эта схема делегирования оказывается очень эффективной – сам видел. Однако если подобрать партнеров неверно, присущая программистам независимость сведет эффективность этой замечательной идеи нулю. Помимо прочих навыков делегирования, вы должны понимать, какие из ваших сотрудников могут работать вместе, а какие – нет.

Не забывайте и о хрестоматийном правиле, согласно которому введение в проект новых сотрудников на завершающих стадиях разработки только оттягивает срок его сдачи. Делегировать можно задачи, но не темпы их решения. Если вы обнаруживаете, что разбить проект на отдельные задания трудно, значит, возможно, проблема кроется в проектном решении. Вероятно, плану конструирования недостает модульности. Иногда в самом начале работы над проектом кажется, что никаких проблем с делегированием не возникнет. Впоследствии, однако, выясняется, что одни группы уже решили поставленные перед ними задачи, а другие запаздывают. Подобные ситуации возникают из-за неверного представления о продолжительности выполнения тех или иных заданий. Эта проблема опять же связана с проектированием. Качественное проектное решение (при наличии достойной архитектуры) обеспечивает удобство делегирования по модулям.