Короткая ссылка: ProjectDocs

Выступление на TeamLead Conf 8-9.02.2018 в Москве 
Доклад на сайте конференции
Расшифровка доклада в статье на habr
Пост на FB

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

Маленький пример: в формате user story "как <роль> я хочу <сделать что-то> для того чтобы <достичь целей>" часть с целью появилась не сразу. Она нужна, чтобы разработчик мог поставить себя на место пользователя, если в процессе реализации надо выбрать между несколькими альтернативами. Казалось бы, можно спросить, однако прерывание разработки – дорого, и разработчики часто додумывают за пользователя, и часто ошибались. Указание цели пользователя позволяет уменьшить число неверных решений. Кстати, сам формат появился при переходе к итеративной разработке как средство обеспечить инкрементальную поставку ценного продукта.

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

Подход к проектированию документации аналогичен проектированию интерфейсов: описываешь кейсы коммуникаций, определяешь, какими документами и артефактами это обеспечивается, понимая, что каждый документ имеет свою цену, и потому часть можно оставить в головах людей. И только после определения документов стоит выбирать, какими инструментами пользоваться: Wiki, Google Docs, что оставить в Task tracker и так далее.

Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM).

В целом доклад развивает мое выступление Agile и управление знаниями в ИТ-проектах на конференции KM Russia 15-16.12.2016.