Как пасти котов. Наставление для программистов, руководящих другими программистами

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

Делегирование

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

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

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

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