Проекты открываются и закрываются, а устав нужен всегда!
Предлагаю подумать для чего нужен устав проекта.
Устав проекта - документ, который содержит описывает проект. Он нужен для того, что бы зафиксировать правила проекта. На берегу договориться, без долгого глубокого анализа, кто и что делает. На мой взгляд, это быстрый документ для того чтобы принципиально понять делаем или не делаем. Что бы поток сознания преобразовать в форму.
Многие аналитики ломают голову, что же включить в устав проекта? Основываясь на своем опыте могу предложить нижеследующее содержание:
Проблемы бизнеса - то, с каким ограничением столкнулся бизнес, чего не хватает для улучшения процесса. В проблеме нужно описать текущее состояние процесса и чем плохо это. Обычно, в плохих процессах тратится больше времени на выполнение операций и в проблеме можно указать сколько времени сотрудники тратят на выполнение операции. Вторая распространенная причина связана с расширением организации и с созданием новых услуг/ новых товаров/ привлечение новых клиентах. Обычно функционал системы реализует текущие потребности, а будущие разрабатывают в будущем :-) и как только бизнес созреет до нового направления, так потребуется это направление положить в функциональность.
Проблема бизнеса - чего не может сделать бизнес без доработки
Цель и задачи проекта - указываются как будем достигать плановых показателей. Очень важный раздел. Он заставляет задумать, почему же нам нужно делать этот проект. В продвинутых компаниях даже считают цифры, которые получат после реализации и на основании таких цифр происходит оценка необходимости проекта. Приведу пример, благодаря проекту, компания сэкономит 5 минут рабочего времени оператора ТМЦ в месяц. Но компания потратит 20 человекочасов на разработчика, плюс написание инструкций, поддержка и возможно доработка усложнит обновление. И тут вопрос - оно того стоит? Может оператор ТМЦ потратит эти 5 минут в месяц? Я конечно привела грубый пример, но на моей практике были подобные задачи и в таких случаях я рада, что работаю в богатой компании, которая не считает деньги и процветает.
Цели и задача нужно аналитику, что бы понять насколько щедра компания работодатель.
Организационные рамки проекта - раздел служит для фиксации заинтересованных в проекте лиц, рабочей группы. В начале проекта важно понять кто есть кто, какую роль в проекте выполняет. Люди должны понимать, что они важны в проекте.
Зачем я здесь? - ответ на вопрос находится в разделе организационные рамки проекта
Этапы проекта - здорово выделить крупно этапы проекта. Основными этапами любого ИТ проекта являются:
- обследования предметной области - там рождается бизнес-процессы;
- интервьюирование заинтересованных лиц;
- формирование БТ, ТЗ, спецификации - документа, который будет содержать описание доработки;
- согласование описания доработок;
- выбор архитектуры решения;
- разработка;
- тестирование, в том числе и формирование документации для сдачи: программа и методика испытаний или сценарий тестирования, инструкции пользователей, администраторов;
- демонстрация функционала заказчику;
- Обновление;
- Опытно - промышленная эксплуатация
А как будет делать? - ответ на вопрос находится в разделе "Этапы проекта"
Коммуникации в проекте - указывает как часто собираемся, кто инициатор встреч.
А что ещё?
Можно добавить еще разделы:
- бюджет - кто платит за проект. Тут каждая организация решает самостоятельно учитывать кто платит или не учитывать;
- риски и ограничения - важно, если вы осознанно что-то выбрасываете из проекта.
- не функциональные требования - указать, что нужно сделать для организации процесса, например, закупить оборудование, или преднастроить систему.