Управление в стиле ООП

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

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

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

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

Абстракция

Вы помните, в чём заключается главный смысл абстракции? В том, что мы вместо конкретных объектов работаем с некоторым интерфейсом, не имея представления, какой конкретно объект будет его реализовывать.

Давайте посмотрим, может ли этот принцип применяться в управлении проектами? Может, и даже очень часто применяется. Например, планируя проект никто, обычно, не принимает в расчёт цвет волос программиста или его пол (и не ухмыляйтесь! Я лично знаю пару натуральных блондинок, которые невероятно круты как программисты). 

[Комментарий постаревшего автора: как же за шесть лет изменилась культура! Тогда это казалось невинной шуткой, а теперь - весьма дурнопахнущим сексизмом]

А вы когда-нибудь слышали от менеджера слово «ресурс»? Да-да, я его тоже не очень люблю. Всё-таки программисты, они почти как живые люди, и иногда у них есть какие-то ещё мысли и переживания помимо программирования и отладки. Но, с другой стороны, в условиях планирования проекта на 20 человек по тысяче часов каждому, вам, в любом случае, придётся писать в каком-нибудь MS Project “Developer 1” и “Developer 2” вместо Вася, Ася и Петя.

Если подумать, то у «объекта класса Developer» есть вполне себе понятный интерфейс: получить задачу и отчитаться о её выполнении (это, кстати, уже событие, на которое менеджеру обычно необходимо подписываться). Ну и ещё с десяток менее важных методов.

Возмущённым защитникам дикой природы, утверждающим, что каждый человек-де уникален и с людьми надо работать (к которым, впрочем, принадлежу и сам) сообщу, что такая индивидуальная работа с каждым сотрудником легко реализуется в виде паттерна проектирования Visitor. Лишь бы сотрудник был готов с тобой разговаривать (в терминах паттерна — реализовал метод visit).

В общем, работать с абстрактными программистами вместо конкретных Васи и Аси, в отдельных случаях, просто необходимо.

Инкапсуляция

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

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

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

С другой стороны, в случае завала, все «прелести жизни» познаёт также руководитель проекта, оставляя внутренние разборки, выговоры, покупку пиццы и дружеское похлопывание по плечу внутри своей команды.

[Комментарий постаревшего автора: а вот заказчику такая инкапсуляция совсем не нравится. Особенно, если он - чайка-менеджер как я]

Полиморфизм

Этот зверь с красивым именем применяется, в частности, для того, чтобы делать объекты взаимозаменяемыми, основываясь на том, что они оба имеют один и тот же интерфейс.

Тут примерно то же, что и с абстракцией. Например, заказчик будет работать одинаково с любой командой, которая выполняет его проект. Кстати, результаты работы разных команд могут быть в корне различными. До тех пор, пока он работает с руководителем проектов и не лезет внутрь (ага, инкапсуляция), ему совершенно без разницы, что за команда выполняет его задачи. Более того, он может раскошелиться и нанять, скажем, офигенную команду из России или Украины (приходите, у меня есть контакты) или обратиться к товарищам из известной страны, омываемой одноимённым океаном, которые обещали сделать дешевле и быстрее. Результаты, естественно, предсказать не сложно.

Наследование

А вот с примерами наследования несколько хуже. Но всё равно они есть. Например, роль тимлида – наследник роли программиста. Он может работать как программист, но получает дополнительные методы (функции) в виде постановки задач команде, обучения новичков и т.д.

[Комментарий постаревшего автора: данный пример не вполне корректен, так как в случае ролей тимлида и разработчика происходит всё-таки не наследование, а композиция двух ролей в одном объекте]

Думаю, вы сами можете придумать ещё десяток таких примеров. 

Паттерны проектирования

Ну и, напоследок – пара адаптаций паттернов проектирования к управлению проектами. 

Возьмём, к примеру, шаблонный метод. Он такой простой, помните? Алгоритм создаётся на базе абстрактного класса, а наследники реализуют отдельные методы каждый по-своему.

Пример лежит на поверхности. Абстрактная команда, абстрактный проект. Абстрактные шаги для каждой фазы – инициация, планирование, исполнение, мониторинг и контроль, закрытие. А вот как выполнять каждый из этих шагов решает конкретная команда. И каждая, кстати, выполняет эти шаги по-своему.

[Комментарий постаревшего автора: PMBoK такой PMBoK...]

Компоновщик – тоже довольно легко ложится на командную структуру. Каждую задачу может выполнять либо программист самостоятельно, либо группа программистов. При этом постановка задачи будет одинаковая, а я, как руководитель проектов, буду ставить задачу одному программисту и группе совершенно одинаковым образом.

А вот про паттерн Цепочка обязанностей я и говорить не буду. В условиях управления проектами он приобретает вид антипаттерна. Судите сами: задачу можно передавать бесконечно, контроля выполнения нет, никаких гарантий, что она будет выполнена – тоже. В общем, этим паттерном лучше не пользоваться.

Серьёзное заключение

А вот в заключение я хочу сказать одну серьёзную штуку.

А штука эта такая: в команде, в процессах, в структуре компании грамотная архитектура: чёткие связи, специализация участников, а также разделённые строго очерченные сферы ответственности не менее важны, чем в коде программного продукта. 

Поэтому обращение к коллегам-менеджерам, выросшим из программистов: вспомните молодость, попробуйте проанализировать вашу команду и процессы с точки зрения архитектуры. Уверен, что у вас появится много пищи для размышлений!