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

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

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

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

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

Как составить хороший план

Теперь можно сосредоточиться на особенностях составления хорошего плана разработки ПО. В этом процессе три основных этапа: определение задач, объединение задач в группы, называемые базовыми уровнями, и группировка последних в этапы проекта.

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

Задачи

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