Любому приличному программисту известно, что грамотно написанная система должна иметь хорошую архитектуру, обеспечивающую чёткую структуру, удачное сочетание и взаимодействие объектов, чётко распределённые между объектами роли и разделение на слои.
Каждый приличный руководитель проекта знает, что для успешного, сданного в срок проекта хорошего качества (который, к тому же, не слишком вылез из бюджета) необходим отлаженный процесс, обеспечивающий прозрачное взаимодействие между членами команды, чёткое распределение ролей и обязанностей, полномочий и ответственности. Т.е. грамотная архитектура команды.
В этой статье я (очевидно, не слишком серьёзно) попробую спроецировать основные принципы ООП на проектное управление и посмотреть, что из этого получится.
Абстракция
Вы помните, в чём заключается главный смысл абстракции? В том, что мы вместо конкретных объектов работаем с некоторым интерфейсом, не имея представления, какой конкретно объект будет его реализовывать.
Давайте посмотрим, может ли этот принцип применяться в управлении проектами? Может, и даже очень часто применяется. Например, планируя проект никто, обычно, не принимает в расчёт цвет волос программиста или его пол (и не ухмыляйтесь! Я лично знаю пару натуральных блондинок, которые невероятно круты как программисты).
А вы когда-нибудь слышали от менеджера слово «ресурс»? Да-да, я его тоже не очень люблю. Всё-таки программисты, они почти как живые люди, и иногда у них есть какие-то ещё мысли и переживания помимо программирования и отладки. Но, с другой стороны, в условиях планирования проекта на 20 человек по тысяче часов каждому, вам, в любом случае, придётся писать в каком-нибудь MS Project “Developer 1” и “Developer 2” вместо Вася, Ася и Петя.
Если подумать, то у «объекта класса Developer» есть вполне себе понятный интерфейс: получить задачу и отчитаться о её выполнении (это, кстати, уже событие, на которое менеджеру обычно необходимо подписываться). Ну и ещё с десяток менее важных методов.
Возмущённым защитникам дикой природы, утверждающим, что каждый человек-де уникален и с людьми надо работать (к которым, впрочем, принадлежу и сам) сообщу, что такая индивидуальная работа с каждым сотрудником легко реализуется в виде паттерна проектирования Visitor. Лишь бы сотрудник был готов с тобой разговаривать (в терминах паттерна — реализовал метод visit).
В общем, работать с абстрактными программистами вместо конкретных Васи и Аси, в отдельных случаях, просто необходимо.
Инкапсуляция
О чём нам говорит инкапсуляция? О том, что мы должны работать с объектом, основываясь только на интерфейсах, и не влезая в его внутреннюю структуру, а уж как увязать данные и методы для работы с ними, объект и сам решит.
Инкапсуляция имеет, наверное, наиболее понятные и полезные аналоги в проектном управлении. Рассмотрим, например, заказную разработку, при которой заказчик оплачивает разработку своего ПО сторонней командой аутсорсеров. В этом случае (очевидно, при хорошей архитектуре команды), в роле интерфейса объекта типа «Команда» будет выступать руководитель проекта. Этим интерфейсом сможет воспользоваться заказчик, топ-менеджмент или любые другие заинтересованные лица.
Например, заказчик передаёт в команду ТЗ, получает текущий статус проекта, изменяет требования, добавляет запросы на изменения и т.д. При этом он не знает состав команды, обязанности и сферы деятельности каждого её члена, не может ставить задачу напрямую программистам и любыми другими способами влиять на внутренние процессы команды, кроме как через её интерфейс (руководителя проектов).
С другой стороны, в случае завала, все «прелести жизни» познаёт также руководитель проекта, оставляя внутренние разборки, выговоры, покупку пиццы и дружеское похлопывание по плечу внутри своей команды.
Полиморфизм
Этот зверь с красивым именем применяется, в частности, для того, чтобы делать объекты взаимозаменяемыми, основываясь на том, что они оба имеют один и тот же интерфейс.
Тут примерно то же, что и с абстракцией. Например, заказчик будет работать одинаково с любой командой, которая выполняет его проект. Кстати, результаты работы разных команд могут быть в корне различными. До тех пор, пока он работает с руководителем проектов и не лезет внутрь (ага, инкапсуляция), ему совершенно без разницы, что за команда выполняет его задачи. Более того, он может раскошелиться и нанять, скажем, офигенную (не могу не пропиариться) команду из России или обратиться к товарищам из известной страны, омываемой одноимённым океаном, которые обещали сделать дешевле и быстрее. Результаты, естественно, предсказать не сложно.
Наследование
А вот с примерами наследования несколько хуже. Но всё равно они есть. Например, роль тимлида – наследник роли программиста. Он может работать как программист, но получает дополнительные методы (функции) в виде постановки задач команде, обучения новичков и т.д.
Думаю, вы сами можете придумать ещё десяток таких примеров.
Паттерны проектирования
Ну и, напоследок – пара адаптаций паттернов проектирования к управлению проектами.
Возьмём, к примеру, шаблонный метод. Он такой простой, помните? Алгоритм создаётся на базе абстрактного класса, а наследники реализуют отдельные методы каждый по-своему.
Пример лежит на поверхности. Абстрактная команда, абстрактный проект. Абстрактные шаги для каждой фазы – инициация, планирование, исполнение, мониторинг и контроль, закрытие (детальнее можно посмотреть вот эту PDF). А вот как выполнять каждый из этих шагов решает конкретная команда. И каждая, кстати, выполняет эти шаги по-своему.
Компоновщик – тоже довольно легко ложится на командную структуру. Каждую задачу может выполнять либо программист самостоятельно, либо группа программистов. При этом постановка задачи будет одинаковая, а я, как руководитель проектов, буду ставить задачу одному программисту и группе совершенно одинаковым образом.
А вот про паттерн «Цепочка обязанностей» я и говорить не буду. В условиях управления проектами он приобретает вид антипаттерна. Судите сами: задачу можно передавать бесконечно, контроля выполнения нет, никаких гарантий, что она будет выполнена – тоже. В общем, этим паттерном лучше не пользоваться.
Серьёзное заключение
А вот в заключение я хочу сказать одну серьёзную штуку, которая следует из всего того юмора, который я писал выше.
А штука эта такая: в команде, в процессах, в структуре компании грамотная архитектура: чёткие связи, специализация участников, а также разделённые строго очерченные сферы ответственности не менее важны, чем в коде программного продукта.
Поэтому обращение к коллегам-менеджерам, выросшим из программистов: вспомните молодость, попробуйте проанализировать вашу команду и процессы с точки зрения архитектуры. Уверен, что у вас появится много пищи для размышлений!
Автор: Tomcat
