Устав проекта

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

Общее описание

Чтобы понять смысл устава проекта, представьте, что в ходе работы поменялась часть штата со стороны ИТ-компании. Поднимаются типовые вопросы: кому и с чем звонить, адреса серверов, правила работы с репозиторием и трекером, какой компилятор использовать, можно ли выпускать релизы по выходным и т.д. Хороший проектный устав отвечает на большинство из них, идеальный - на все. И вы, и клиент экономите время, а вероятность ошибок значительно снижается.

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

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

Самые важные моменты дублируйте в договоре:

• сотрудники с обеих сторон несущие ответственность за свои области разработки;
• официальные контакты и способы обмена информацией;
• список работ и ответственностей, которые несет заказчик.

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

Содержание

Что, помимо лиц, участвующих в проекте со стороны клиента и разработчика, их контактов, пула задач и ответственности должен содержать устав?

• Способы коммуникаций между сторонами и внутри команд: почта, чаты, трекеры, репозитории документов.
• В явном виде перечисленные работы, которые делает заказчик: составляет документацию, принимает решения (опять-таки, какие?), пишет часть кода, проводит тестирование, деплой, отрабатывает аварийные сценарии, вводит решение в опытную эксплуатацию и так далее — как договоритесь.
• Схему передачи документов, релизов, исходных текстов.
• Описание аппаратных и программных ресурсов: серверов, репозиториев, баг трекеров.
• Данные о нахождении проектной документации и структуре хранилища.
• Карту ресурсов со всей необходимой информацией.
• Используемые технологии и инструменты (библиотеки, инструменты для сборки, версии языков и т.п..
• Планы релизов, их развертывания, тестирования, согласования выкладки с заказчиком.
• Другие правила работы.

В устав включают также принятые схемы работы.

С репозиториями:

• работа с ветками кода (в какой разрабатывается версия, а где — замороженный код релиза), их создание и объединение;
• выкладка релизов и их версий на тестовые, отладочные и боевые сервера;
• список разработчиков, отвечающих за ревью кода и слияние веток.

С баг трекером:

• логика маршрутизации задач;
• маршрутизация по типам и темам задач;
• ответственные сотрудники (кто распределяет задачи, кто отвечает за отдельные компоненты или подпроекты и пр.).

Цель

Устав — источник взаимопонимания с заказчиком и его командой, легкого вхождения новых сотрудников в проект и ответа на вопрос «кто виноват, что делать?».

Автор

Первые наброски устава предоставляются сотрудниками проектного офиса в качестве одного из типовых документов.

В целом он пишется менеджером проекта, но к отдельным его частям привлекают:

• ведущего разработчика или архитектора;
• ведущего сотрудника по линии devops;
• аккаунта, ответственного за связь с клиентом;
• ответственного со стороны заказчика.

Написать документ нужно до старта проекта или на этапе его запуска, что будет значительно хуже. Согласование должно быть официальным, при этом устав допускает незначительные корректировки и доработки в ходе проекта, но обязательным требованием будет доносить изменения до всей команды. Устав может меняться, но должен всегда содержать актуальные и верные сведения.