Доброго времени суток. Хотелось бы порассуждать об одном из известных аспектов проектов — ресурсном. Предпосылка такова — если открыть, например, учебник Мазура, Шапиро, Ольдерогге «Управление проектами», то там сходу проект рассматривается как «процесс перехода из исходного состояния в конечное— результат при участии ряда ограничений и механизмов».

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

Реализация, очевидно, является цепочкой преобразования одних ресурсов в другие, как и любое производство. Этот пост будет посвящен рассмотрению ИТ-проектов если не как производства, то как ряда преобразований уж точно.

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

Распространенные ресурсы ИТ-проектов

Что можно отнести к ресурсам? Помимо очевидных «деньги» и «время», также можно отнести их производные:

1. Инструментарий (начиная от банального рабочего места и заканчивая стендами и средствами разработки) — требует денег
2. Персонал и его специфические знания — требует денег (он такой, да:)), и, в случае знаний, возможно время
3. Клиентские базы и лояльность клиентов — требует и времени и денег
4. Любой артефакт-«полуфабрикат», произведенный в проекте, требует и денег и времени

Последние в свою очередь бывают, для примера:

• Программный код
• Документация (ТЗ, пользовательская и всякая другая)
• Развернутые решения
• Информация в базах данных, информация о клиентах
• Если речь о производстве устройств, то собранные прототипы и непосредственно материалы для производства (готовые комплектующие)

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

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

Взаимосвязь методики ведения проекта с цепочкой ресурсных преобразований

Итерационный (с таймбоксами, буду называть далее обобщенно Agile) и каскадный подходы различаются с точки зрения преобразования ресурсов в основном тем, как они обходятся со временем. В одном случае оно «нарезано» на равные куски, в каскадном нет. Итерации могут быть и там и там, весь вопрос в том, какие промежуточные результаты создает проект: в случае гибких подходов мы имеем конечный неполнофункциональный продукт на каждой итерации, в случае каскада — мы имеем отдельные функции/модули. При этом количество результатов, очевидно, разное, особенно чем короче таймбокс.

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

1. Невоспроизводимые, складируемые, накапливаемые — «энергия» (финансы для ИТ-проектов),
2. Воспроизводимые, нескладируемые, ненакапливаемые ресурсы — «мощности» (люди для ИТ-проектов).

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

Примеры цепочек преобразований

Рассмотрим пару вариантов — B2B и B2C. Для B2B рассмотрим проект разработки что-нибудь по типу простецкого документооборотного ERP, для B2C — сайт-биржу, где посетители заказывают и покупают друг у друга услуги.

Стрелки на диаграммах отражают последовательность.

B2B «ERP» Agile

B2C «Биржа» Cascade

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

И да. Если (вдруг) покажется, что гибкий подход «стройнее», то за примитивностью его диаграммы скрывается отсутствие некоторых ресурсов, которые есть во второй.

Вместо заключения — управление рисками в проекте через призму ресурсной цепочки

«План без рисков — набор пожеланий, риск без плана — казино». ((с) моё).

Риск — это событие, которое отклонит показатели проекта от нужных. Риск влияет на конечный результат проекта (либо он не в срок, либо некачественный, либо за бюджет вылезли). Теперь внимательно следим за руками :)

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

Доказательство. Рассмотрим произвольный показатель, его риском будет возможность отклонения значения от планового. Значения показателя в некоторый момент времени есть функция задействованных до этого момента ресурсов, в конце проекта — всех ресурсов. Из этого вытекает, что изменение состава ресурсов и их последовательности приводит к изменению (графика) значений показателя. Отсюда же вытекает и то, что проектов без риска не бывает (поскольку ресурсы по факту никогда не соответствуют плановым). Само «содержание» ресурса генератором риска назвать нельзя, так как меняя его «содержание» мы меняем ресурс (например база не MS SQL Server, а Firebird — это два разных ресурса). [Конец доказательства]

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

Спасибо за то, что прочитали. Всем удачных проектов!