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

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

Можно всю эту статью ужать до одной фразы. Manage people, not tasks. Управляйте людьми, а не задачами.

Этим все сказано. Но если внутри вас, когда вы читаете, еще что-то ёкает, остались сомнения, — предлагаю пойти немного вглубь. Вы согласны с фразой «проект — это команда»? Это же можно сказать более научно: «качество результата проекта эквивалентно качеству процесса».

Если не согласны с последним, это ваше дело. Потому что на этой идее построена вся современная научная часть управления проектами. Six Sigma, Toyota Production System, TQM — это все результат той же идеи, которая в своем самом жестком варианте звучит так. «Проект — это команда». Особенно читывая, что фактически единственный инструмент и ресурс в информационном бизнесе — это люди.

От «командной работы» до TPS в действительности не так далеко. Сначала появилось управление командной работой, HIM (Human Interactions Management), потом уже возникло управление бизнес-процессами, BPM (Business Process Management). Так что начинать выстраивать Тойоту из своей компании нужно с команды. С людей.

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

Как утверждает Уильям Джойс в книге "Формула устойчивого успеха в бизнесе 4+2", есть 4 фактора успеха бизнеса:

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

Два из четырех пунктов относятся исключительно к людям и внутренней структуре организации!

Для начала в команде выстраивается процесс сотрудничества и переговоров (важные качества: творчество и доверие). Затем каждый участник команды работает с внутренним желанием удерживать формат (ответственность, четкость). А уже только потом форматы процессов формализируются и «зашиваются» в систему, в ПО. Система — «после» человеческого взаимодействия, не «до». Именно об этом говорит Манифест быстрой разработки, Agile Manifesto: «Люди и взаимодействия важнее чем процессы и инструменты».

Эту идею мы положили в основании Comindwork, системы ведения проектов и сотрудничества. Используя базовые договоренности, можно достичь синергии в работе, то есть истинно командной работы. А уже потом мы предлагаем инструменты настройки процессов. Уже на базисе доверия, постоянного улучшения, ответственности каждого участника как за результат, так и за поддержку процесса.

Стиль изложения может показаться сбивчивым

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

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

Сегодня у человечества есть современный автомобиль, у которого есть современное колесо. Они развивались параллельно. С точки зрения человека начала века, они являются идеальными. Если бы мы решили создать такое колесо и работали бы над ним с начала века как над отдельным проектов, у нас не было бы сегодня нашего колеса.

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

Каждый хороший проект должен пройти эволюционный процесс, который всегда един и не может быть разделен части, которые проходят последовательные этапы. Если вы хотите поделить все таким образом - придумайте для ваших этапов стыковочные API, которые будут выступать искусственными точками фиксации, "якорями" проекта, меняя конфигурацию которых вы сможете органично управлять разработкой. строго говоря, каждый API является описанием некой конфигурации и будет являться одновременно для одного проекта целью, и стартовыми данными для другого. В этом случае можно вести разработку одновременно, обладая гарантией совместимости результатов на стыке.

Почему качество губит? Таким образом, мы подошли к самому главному. Проект - это мешок ресурсов, на которых написано, в какой результат он должен превратиться. Ресурсы всегда конечны, и молитесь, чтобы этот конец был счастливым. Рано или поздно наступит точка, которую вы обозначали на своих ранних графиках латинской буквой G, а в поздних, возможно, стали использовать её русский антоним. Так вот, если заклепочный отдел сделает заклепку нового самолета идеальной, которая по характеристикам даже на 20% лучше, чем планировалось, потратив ради благого дела (кто поспорит?) ресурсы в виде 20% превышения выделенного времени и денег, эти 20%, для простоты выраженные в чистой энергии, не достанутся менее харизматичным соседям из отдела, который занимается, например, системой охлаждения.

Я не говорю, что от этого чаще падают самолеты, я лишь хочу, чтобы перестали бороться с плохим качеством только с помощью повышения качества ;)