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

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

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

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

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

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

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

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