Для организации работы проектной команды необходим единый информационный центр, с помощью которого решаются следующие задачи:
- Хранить проектные документы
- Вести рабочие материалы: протоколы, риски, открытые вопросы
- Информировать участников о правилах, событиях, планах
- Вести всевозможные реестры — задач, бизнес-процессов, разработок (Excel — не самый лучший инструмент для коллективной работы)
- Раздавать задания и поручения
- Собирать информацию по выполнению задач и поручений
Есть бесконечное число вариантов решения — вместе или по отдельности. Мы использовали связку Confluence + JIRA, и это было удобно и эффективно.
Портал проекта — Confluence
Confluence — это удобный и продвинутый wiki движок от компании Atlassian. Он позволяет организовать внутренний интернет портал и дать доступ к нему всем пользователям — для редактирования или для чтения.
- Он очень прост и удобен, для обучения достаточно нескольких часов. У нас на проекте странички создавали и редактировали почти все участники.
- Довольно богатые возможности форматирования, необходимые для того чтобы сделать страничку красивой и легко читаемой. Есть средства, автоматизирующие создание навигации внутри сайта — оглавления, таблицы, ссылки, включения отрывков из других страниц и т.д.
- Написано огромное количество плагинов для расширения функциональности.
- Можно хранить документы, при этом сохраняются версии. По умолчанию пользователь берет всегда последнюю версию, что снижает количество ошибок. В любой момент можно можно вернуться к любой из предыдущих версий.
- Также сохраняются версии страниц, и всегда можно увидеть, кто и какие изменения внес, сравнивая любые две версии попарно.
- Можно ограничивать доступ в целом на сайт проекта или на отдельную страницу.
- Полнотекстовый поиск осуществляется по всем страницам и вложенным документам портала, включая pdf.
Мы сделали на Confluence проектный портал, домашняя страничка которого содержала ссылки на ключевые материалы проекта, контактную карту, регламенты и инструкции. На этой же странице публиковались все новости проекта. Управляли содержанием страницы администраторы и руководители проекта.
Проектные материалы
Проектный портал содержал все проектные материалы, часть которых мы сделали в виде иерархии страниц.
Верхний уровень иерархии — это этапы проекта. На каждом этапе создали страницы-ключевые задачи этапа. Причем на каждой странице — описание задачи, каково ее содержание, зачем она необходима, кто ее выполняет, приложены шаблоны документов.
Все контрактные документы, которые должны сдаваться в качестве результатов проекта, выкладывали на соответствующую страницу в Word, Excel или pdf. Таким образом все проектные материалы, были в одном месте, структурированы, и не было путаницы с версиями.
Справочная информация
Масса полезной информации мы организовали в виде специальных страниц. Например, для большой команды крайне популярной является контактная карта, на которой у нас был список проектной команды по группам, с фотографиями и данными участников.
Страница со ссылками на экземпляры системы поддерживались системными администраторами. Там же была схема эволюции технической инфраструктуры — когда какие экземпляры появлялись и выводились из эксплуатации.
Процедуры и регламенты
Собрание всех инструкций и проектных регламентов на портале, в актуальном и удобном для чтения виде позволяет экономить на объяснениях новым участникам и бороться с отговорками «не прочитал, не нашел, не видел». Когда вопрос все-таки возникает, можно выслать ссылку на страничку, чтобы не пересылать документ и тратить время на его поиск. Версия — всегда актуальная, т.к. обновление происходит непосредственно на портале.
Риски и открытые вопросы
Мы вели на портале риски и открытые вопросы. На каждый риск или вопрос мы заводили отдельную страницу, по заранее созданному шаблону. На странице риска, кроме обязательных названия и классификаторов, было подробное описание содержания, последствий, а также план действий со сроками и ответственными, и статус риска. Примерно так же были организованы открытые вопросы.
Специальная страница автоматически собирала список страниц с рисками, образуя таким образом реестр рисков.
Просматривая список можно перейти на соответствующую страницу, прочитать описание риска и посмотреть план действий по нему.
Поручения
План действий может представлять из себя простой текст, задачу в Confluence или ссылку на задачу в JIRA.
Рассмотрим варианты, которые можно использовать, которые позволяют напоминать о действиях участникам и контролировать их исполнение.
Задача в Confluence — это отдельная сущность, которую можно добавить на страницу. Напоминание о задаче высвечивается для пользователя, когда он входит на портал, значком в правом верхнему углу. Кликнув по этому значку пользователь переходит к списку своих поручений. Когда задача выполнена, он ставит галочку, и статус задачи меняется за завершенный.
Однако так же точно можно снять галочку и задача опять становится не выполненной. Поэтому такая система выглядит не очень надежно и контроль за поручениями в этом случае слабый.
Второй вариант — использование для поручений задач в JIRA. Непосредственно со страницы проектного портала можно создать задачу в JIRA, назначить ответственного и установить срок исполнения. Для этого мы сделали специальный макрос, срабатывающий по кнопке Создать поручение.
В отличие от предыдущего варианта эта задача может быть настроена так, чтобы ее мог закрыть только ответственный, отличный от исполнителя, что дает хороший контроль ее выполнения.
Ведение протоколов
Практика, которой мы придерживались, помогала нам сохранять все решения, которые мы принимали на совещаниях. В ходе каждого совещания мы вели протоколы непосредственно на портале проекта. В начале каждого совещания мы создавали новую страницу протокола на основании шаблона, и записывали основные моменты по ходу обсуждения. В конце формулировали решение и план действий.
Если кто-то после совещания хотел уточнить текст протокола, тот мог это сделать прямо на страничке портала, и было видно, кто и когда какие изменения внес. Протокол считался согласованным сразу после совещания, это экономило массу времени.
JIRA — Система для ведения списков, поручений, задач
JIRA создана как система регистрации и исполнения запросов на обслуживание. Однако она может быть использована для ведения любых реестров и управления любыми задачами.
В нашем проекта мы использовали JIRA для контроля исполнения поручений, ведения разработок и отслеживания задач по конвертации данных.
Ведение разработок с помощью JIRA подробно описано в статье Управление разработками. Здесь я расскажу о контроле поручений и интеграции с Confluence.
Для создания задачи JIRA из Confluence достаточно выделить текст, навести курсор на выделенный текст и нажать кнопку в контекстном меню, чтобы вызвать экран JIRA для создания задачи.
На странице протокола появится ссылка на задачу, а в задаче JIRA будет ссылка на страницу в Confluence.
Таким образом мы можем переходить между этими двумя системами, с одной стороны, чтобы уточнить состояние и историю исполнения поручения, а с другой — посмотреть контекст и причину возникновения задачи.
Интеграция между системами также помогала нам отслеживать списки открытых вопросов, связанными с разработками.
В конце проекта, когда остался список критичных разработок, которые необходимо было закрыть для завершения проекта, мы организовали его в виде таблицы на странице портала проекта, в одной из ячеек которой была ссылка на разработку в JIRA. Кроме номера задачи там отображается и текущий статус. Просматривая список мы можем видеть, какие задачи еще не закрыты, в каком состоянии они находятся, и при необходимости можем перейти к ней, чтобы увидеть всю историю и переписку по ней.
Работа с JIRA требует определенной квалификации и опыта. Здесь я описал некоторые варианты использования, однако на самом деле их гораздо больше. Прелесть в том, что можно начать с самых базовых вещей, и это уже будет работать, а затем развивать систему по мере приобретения опыта и понимания потребностей.
Кроме Confluence, в интеграции с JIRA, мы также использовали BitBucket, также продукт Atlassian — репозиторий разработок, позволяющий отслеживать версии кода. Для этих же целей на другом проекте использовали бесплатный SVN.
Множество плагинов позволяет расширять функциональность системы, в частности, для интеграции с MS Project или реализации диаграммы Гантта непосредственно в JIRA.
Большое количество вариантов использования может стать препятствием для тех, кто берется за использование этих инструментов в первый раз. В этом случае можно воспользоваться опытом других проектов, которых великое множество, либо начать с самого простого.
Организация проектного пространства с помощью JIRA и Confluence доказало свою эффективность и удобство. Ключевые преимущества — это удобство, надежность и широчайшие возможности для адаптации. На наших проектах такая системам стала стандартом де факто.
Комментарии (9)
ivsedm
06.12.2018 03:39Прям сплошной елей :) из минусов я бы отметил жадность у компании разработчика (если вы не микро команда до 10 человек). Плюс есть "проблема" (из-за хорошей интеграции систем), когда купив одну систему, например, Jira, хочется к ней добавить Confluence, а потом Fisheye и Crucible, а потом ещё ServiceDesk и сверху пару платных, но жутко полезных, плагинов. И в итоге для 12 разработчиков + ещё человек 15 заинтересованных лиц, набегает весьма ощутимая сумма (для вспомогательного ПО). Хотя и удобно, да.
dantipov Автор
06.12.2018 07:37Это правда, дополнительных покупок может быть много. Из интересных плагинов я бы еще упомянул BigPicture и Structure. Они дают хорошую видимость и структуру задач JIRA.
Но по сравнению с проектами SAP или Oracle, которых мы продаем нашим Заказчикам, стоимость всего этого добра исчезающе мала, а повышение эффективности работы команды полностью окупает затраты.
Приведу конкретный пример. На одном проекте SAP, где я возглавлял группу РМО, кроме меня было еще 3 человека, и мы собирали данные из многочисленных реестров Excel и готовили отчеты. На другом проекте, не менее масштабном, я был РП и львиную долю информации брал из JIRA. Группы РМО у меня просто не было. Минус 4 человека.
bespechnost
06.12.2018 11:57В моих проектах confluence не подошёл по одной причине — нет возможности версионировать всю базу знаний целиком. То есть вы можете контролировать изменения в одном документе, то как это сделать в нескольких одновременно? Может быть вы знаете?
Для FRD и PRD мы в команде используем GitBook с кучей плагинов, которые нужны нам. Дока пишется, версионируется и выкладывается в общий доступ так же как и код. В этом случаи в доке написано, то что есть в коде. Плюс так как это markdown, то его можно собирать в любом виде (html, pdf)
dantipov Автор
06.12.2018 12:03В конфлюенс есть возможность архивировать всю базу целиком. А потом восстанавливать ее как другое пространство. Таким образом у вас будет несколько версий. Может быть я не совсем понимаю, зачем это делать, но ничего другого в голову не приходит.
bespechnost
06.12.2018 12:20У нас разработчики делают одновременно несколько фичей. По мере готовности мы включаем их в ближайший релиз. У меня вопрос можно ли как то держать основную ветку документации продукта, который сейчас в проде и померк готовности фичей ее дополнять? У меня сейчас есть прод и у него своя версия доки, а есть ещё десяток stage серверов с разным функционалом и соответсвенно разным набором доки. Как только код выйдет в прод, то автоматом и дока будет включать информацию по новому функционалу.
dantipov Автор
06.12.2018 13:41Я бы сделал это все на страничках в конфлюенс, которые легко дополнять по мере выхода нового функционала. Можно или копировать текст, или включать в виде текста другую страницу, что позволяет разделить ответственность за подготовку. Наверху всегда будет лежать самая последняя версия документации. Мы на проекте все инструкции пользователей реализовали в конфлюенс, а потом перевели туда и все функциональные дизайны.
NewMan_by
«Порат проекта — Confluence», похоже надо поправить на «портал»
dantipov Автор
Спасибо! Поправил