Время — деньги. Создание команды разработчиков программного обеспечения - Эд Салливан

Часто в ответ на вопрос о планах от разработчика можно услышать такое: «Сначала нужно обновить менеджер ресурсов поддержкой 32-разрядных идентификаторов, потом изменить алгоритм анализа индекса PRODUCT ID, чтобы разрешить дублирование записей, а затем переписать обработчик ошибок, чтобы поддерживалась многопоточностъ». Каждый из этих пунктов вполне допустим, как элемент работы программиста, однако следует удостовериться, что все они находятся в контексте функций программы или не выходят за рамки её требований. В контексте некоторой функции задачу разработчика можно сформулировать, например, так: «организовать поддержку печати из диалогового окна ввода заказа» или «обеспечить возможность ввода нескольких заказов одновременно». Более узкая сосредоточенность также полезна для других разработчиков команды, поскольку им важно знать, когда некоторые функции станут доступны, а не срок завершения задач, необходимых для реализации этих функций. Когда план чётко определяет срок завершения всех функций или требований, остальные участники команды могут быть уверены, что их работа завершится в параллели с другими задачами.

Трудности в работе с людьми

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

Распределение работы

Не все разработчики от рождения наделены равными способностями. Некоторые лучше всего программируют интерфейсы, другие — системную логику. У одних опыта больше, у других — меньше. У некоторых производительность труда очень высока, у других средняя или даже низкая. Нельзя назначать задания случайным образом, полагая, что все люди обладают «типовыми» способностями. Распределяя задания между разработчиками, тестировщиками, технологами и другими членами команды, следует быть очень осторожным. В каждом случае надо учитывать уровень мастерства, индивидуальную производительность, опыт практической работы над проектами и привычки.

Балансировка нагрузки

Задача состоит в равномерном распределении рабочей нагрузки по реализации проекта на основе индивидуальных способностей участников команды. Однако будьте осторожны и не перегрузите лучших участников команды. Хотя они могут сделать больше других, у них тоже есть свой предел. Эти люди ещё пригодятся, чтобы помочь другим, когда возникнут неприятности.

Возможные накладки

Наивно полагать, что все своё рабочее время люди будут трудиться над своими основными задачами. В каждой организации возникают накладки, к которым относится время, потраченное на собрания, наладку технологии, отпуска, стажировки, командировки, больничные и выходные. Даже при 80 рабочих часах в неделю, нетрудно заметить, что 10 из них тратятся на отвлечённые действия. Это тоже следует учесть в плане. Кроме предсказуемых событий (отпусков, командировок и т.п.), план должен учитывать и неожиданные: болезни сотрудников, зимнюю непогоду и пр.

Задачи: критичные и некритичные

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

Ловушки, подстерегающие любую команду

Ниже описан ряд наиболее распространённых проблем с планированием, с которыми приходится сталкиваться командам разработчиков.

Сроки: конечный и согласованный

Конечный срок — это предположительная дата сдачи проекта. Обычно он основывается на внешней рыночной конъюнктуре и состоянии дел в отрасли. Эта дата очень важна, поэтому нельзя соглашаться с конечным сроком, не составив прежде план. Подставьте этот срок в «уравнение» планирования, как одну из переменных и попробуйте уравновесить требуемую функциональность ПО и ресурсы для её разработки. Если уравнение не решается, придётся исключить часть функций, добавить ресурсы или сделать то и другое в некоторой пропорции. Конечная цель в том, чтобы составить уравновешенный, реалистичный и правдоподобный план, против которого не стал бы возражать ни один член команды.

Как только появится хороший план, необходимо удостовериться, что в команде нет возражений.

Согласованный срок — это дата сдачи ПО, с которой согласны все участники команды. Они считают эту дату разумной и вполне достижимой. Таким образом, команда разработчиков принимает на себя обязательство закончить ПО к этому сроку. Ситуация в небольших начинающих фирмах и крупных компаниях сходна тем, что от своевременного окончания работы над ПО зависит результат работы множества людей и значительных затрат, как денежных, так и временных. Для компании чрезвычайно важно выдержать утверждённый согласованный срок, чтобы, выполнив принятые обязательства, завоевать доверие к своей компании.

Ответственность за реализацию плана

Чаще всего команду ставят перед фактом, жёстко определяя необходимый объём функциональности ПО, выделенные для этого ресурсы и срок, к которому всё должно быть готово. И получается, что ответственность за выполнение плана лежит не на разработчиках, а на организации или персоне, которая эти требования «спустила сверху». Такова общая формулировка этой серьёзной проблемы. Боевой дух участников команды будет невысок: ведь они будут чувствовать, что их поставили в заведомо проигрышное положение. Без чувства ответственности, не принимая на себя обязательств, команда не сможет вложить в реализацию проекта сердце и душу, и никакого энтузиазма.

Вместо этого группа разработки должна создать свой собственный план, точнее, сама поддерживать баланс в рамках плана. С принятием обязательств в команде появляется чувство ответственности. Выдвинув свой план разработки ПО, за который она отвечает, команда должна приложить все усилия, чтобы выдержать установленные в нём сроки. Доверие — это следствие выполненных обязательств.

Из собственного опыта

Разработка ПО в NuMega обычно проходила под огромным давлением необходимости уложиться в срок. Конечные сроки сдачи наших продуктов обычно приурочены к выходу Microsoft Visual Studio или появлению новых платформ и технологий, например Microsoft Windows 95, Microsoft Windows NT или Microsoft COM. Чтобы воспользоваться преимуществом этих событий, наши группы маркетинга разработали всесторонние планы продвижения продукта, включающие рекламу, пресс-конференции, аналитические исследования, презентации и обучение продавцов. Ассигнования на эти мероприятия, зависящие от даты выхода ПО, достигают сотен тысяч долларов. Кроме того, наши специалисты по продажам и старшие менеджеры рассчитывали на существенный прирост прибылей с выходом каждой последующей программы. Любая задержка была чревата не только потерей больших денег и времени, но и упущенными возможностями по продаже и потерей выгодной для нашего товара рыночной конъюнктуры.

Чтобы обеспечить своевременный выпуск ПО, вся «домашняя работа» (поиск компромиссов между реализацией функций, доступным временем и ресурсами) выполнялась заранее, затем на основе конечного срока выхода ПО составлялись реальные планы. Таким образом, автором планов были технические специалисты, а не экономисты или старшие менеджеры. Приходилось брать на себя ответственность за реализацию этих планов независимо от их содержания. Любая ошибка планирования была нашей проблемой, и мы отвечали за то, чтобы найти решение, не допуская задержки выпуска ПО.

Вопрос доверия к техническим специалистам

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