В различных гибких методологиях проекты рассматриваются как бесконечно совершенствуемый процесс. Но даже там выделяются стадии развития любого проекта, которые он обязательно пройдёт. Не бывает так, что проект существует бесконечно: или закончится поток финансов от инвестора, или пользователи потеряют интерес, или задачи, которые решает проект, потеряют свою актуальность.
Несмотря на повсеместную автоматизацию и уменьшение ручного труда, современный бизнес не может полностью отказаться от сотрудников. По крайней мере, необходимо, чтобы люди обеспечивали обслуживание оборудования и информационных систем, а клиенты должны иметь возможность получать четкие человеческие ответы и консультации по спорным вопросам.
Стейкхолдер – это очень широкое понятие, которое используется в проектировании систем и в управлении проектами. В частности, термин активно применяется в PMBoK (серьёзный фреймворк для запуска сложных проектов), в ISO 9000 (серия стандартов, касающихся менеджмента качества), а также в ISO/IEC 42010 (наш аналог ГОСТ Р 57100, описание архитектуры для системной и программной инженерии).
Долгое время в России не было даже теоретической базы для проектирования корпоративных систем и предприятий корпоративного типа. Основная ставка делалась на унитарные организации. С 1990-х годов после перестройки в страну потекли иностранные капиталы, стали появляться более крупные предприятия, которые функционируют и управляются иначе, чем унитарные.
Период нестабильности создает много сложностей в работе организаций, требуется большое количество ресурсов для того, чтобы просто сохранять прежние темпы работы, не говоря уже о продолжении роста. Многие цепочки поставок рвутся, и из-за этого компаниям приходится заново выстраивать все свои внешние связи.
Одно дело, когда какая-либо задача будет реализовываться вами лично. Никто не будет мешать или подгонять, стоять над душой, контролировать, тыкать носом в проблемы. Принимать результат будете вы сами и только для себя. Никаких приёмных комиссий, актов приёма-передачи, сопровождения…
Но совсем другое дело, когда над проектом трудятся два и более человека, результат нужно кому-то передавать, есть чёткие сроки, список требований и кто-то должен нести за всё это ответственность.
Сегодня многие любят говорить о планировании. Но планирование – это не просто составление списков задач и того, что можно было бы реализовать. Задача правильного планирования – привести к такому состоянию, когда конечный фактический результат будет максимально соответствовать ожиданиям, то есть изначальному плану. И чем масштабнее совпадение, тем выше качество планирования.
Чтобы команда работала быстро, слажено и достигала поставленных целей, у каждого из участников должна быть определена зона ответственности, а также круг должностных обязанностей, строго соответствующих роли.
Одна из ключевых ролей – это администратор проекта.
Ниже подробно рассмотрим, что конкретно делает и за что отвечает администратор проекта в процессе его реализации.
В небольших проектных командах обычно используют гибкие и понятные методологии с короткими циклами итераций. Однако у каждой команды могут быть свои предпочтения. Где-то уже сложились определённые механики, а где-то применения конкретной системы управления требует сам проект или объект разработки.
