Проектов без документации не существует, вопрос в том, что что именно должно входить в конкретный базовый набор на старте и как оптимально поддерживать документацию в процессе.
Что и как фиксировать РМ-у, чтобы не утонуть в бумажном водовороте, спросили у двух экспертов:
Денис Шаматажи начинал как девелопер, а последние 5 лет работает в проектном и продуктовом менеджменте, поэтому видит процесс документирования с разных сторон.
Наталья Белоусова 9 лет в роли РМ-а, знает как «вытащить» сложные проекты и умеет найти общий язык с любым клиентом.
Приступая к проекту, нужно понимать, что документацию создают не просто ради процесса. Сделать документ — не самое увлекательное занятие, поэтому опытный РМ сразу ищет, где можно сэкономить время и ресурсы.
Для создания действительно полезных бумаг учитывайте два фактора:
- цель — для чего создается конкретный документ;
- потребитель — кто будет использовать то, что вы написали.
Определите, для чего пишете
Документы, без которых трудно обойтись, попадают в одну из трех категорий:
- Формальные бумаги: отчетность перед руководством, заказчиком или договор. Не делать их нельзя, однако нужно делегировать все, что возможно.
- Фиксация договоренностей: обязательства по поводу проектного треугольника: денег, сроков, скоупа. Записывать можно в вордовских документах, таблицах, минутках, имейлах.
- Экономия времени, чтобы не повторять одно и то же разным людям. Например, сделать один раз страницу в Confluence и каждому, приходящему в проект, отправлять ссылку на эту страницу. Человек прочитает и будет в курсе, а РМ-у не придется тратить время на объяснения.
Денис Шаматажи Project / Product Manager в Redmadrobot, спикер курсов РМ Hard Skills: Planning и РМ hard skills: Release:
Когда я был в стартапе, наша документация решала сразу несколько целей. Поэтому случалось, что онбординг, согласования, follow-ups или техдокументация аналитика были записаны вместе. Человеку говорили: «Эта часть документа тебе не нужна, читай отсюда».
В какой-то момент мы пришли к абсолютно очевидному открытию. Один документ должен решать одну главную цель, потому что так получится сэкономить время.
По каким целям можно сгруппировать документы:
- Онбординг: процессы в Jira, правила общения с заказчиком, как проходят встречи.
- Пласт документации, которая отвечает за скоуп: база знаний, техническое задание. Оптимальный вариант — пространство в Confluence с базой знаний.
- Документы для этапа сдачи проекта, например, программа и методика испытаний.
Подумайте о том, кто будет читать
Определить цель документа — это первый шаг. Следующий — подумать об аудитории, кто будет пользоваться написанным.
Иногда РМ пытается суммировать абсолютно все в бизнес-значениях, и команда не понимает, что от них требуется: куда добавлять логику — на этот response или на тот? Так же неправильно выносить технические подробности клиентам, которые не разбираются в таких деталях.
Денис Шаматажи Project / Product Manager в Redmadrobot, спикер курсов РМ hard skills: Planning и РМ hard skills: Release:
Приходя на проект, я пытаюсь составить психологический портрет заказчиков, чтобы увидеть, насколько они понимают технический язык. Если не понимают, пытаюсь писать максимально стерильно, а затем еще и показать кому-то из нетехнарей, чтобы увидеть, насколько это понятно.
Если обращаюсь к ребятами из команды — тут сложнее, потому что им нужны как системные, так и бизнес-требования.
Часто возникает ситуация, когда РМ дает настолько техническое описание какой-то спеки, что разработчик не понимает, для чего ее строить. А ключевой фактор в построении любой новой функциональности — донести до разработчиков, какая бизнес-задача решается.
Потому что, если один участник не понимает бизнес-задачи, велика вероятность, что команда сделает не то или не будет мотивирована.
Попробуйте набросать в черновике формулировки, с которыми обратитесь к аудитории. Важен индивидуальный подход, чтобы сделать задачу более понятной. Нужен отдельный язык для клиента и для команды, поэтому, составляя документ, учитывайте, для кого пишете. Разработчикам лучше писать, а кому-то — объяснить с картинками.
Всегда старайтесь получить фидбэк о том, нужен этот конкретный документ или нет, понятно ли написанное. Можно задать уточняющие вопросы и, если человек «плавает», лучше пересмотреть формулировки.
Понимая цель и кому понадобится документ, давайте посмотрим, каким будет минимальный набор, чтобы начать проект без проблем для РМ-а и команды.
Минимальный набор на старте проекта
Базовый набор стартовой документации включает:
- Паспорт проекта — документ, в котором описано кто клиент, что делаем, когда это нужно сделать, цель и т.д. Бывают компании, где паспорт проекта обязателен, но иногда без него можно обойтись. Например, если в компании хороший онбординг, тогда команда и заказчик в курсе, как именно работаем, чего хотим достичь.
- Фич-лист обязателен, именно с него начинается проект: РМ оценивает фич-лист, согласовывает с заказчиком, и на его основе создает план проекта.
- Иерархическая структура работ — тот же фич-лист, только уже более структурированный и распределенный на роли. Может понадобиться, если нужно показать составные части проекта более удобно.
- Оценка проекта — обязательная часть.
- План проекта — важно правильно выбрать инструмент, в котором будете вести план: Excel, Project, Miro.
С заказчиком нужно договариваться не только о том, как начинать и вести проект, но и как будете сдавать работу. ПИМИ (программа и методика испытаний) может быть описана формально или в более свободной форме. Главное, зафиксировать договоренности о сдаче проекта письменно, причем, в самом начале.
Наталья Белоусова, PM в Redmadrobot:
Обратите внимание на договор. Почему-то не все РМ-ы его читают, а это очень важно, потому что в договоре могут быть написаны вещи, которые формально нужно сделать, а вы на них не закладывались. Например, список поддерживаемых устройств или список версий. Поэтому всегда имеет смысл почитать этот документ.
Чтобы понять как поступить в конкретном случае, подходите с экономической точки зрения. Задайте себе вопросы: «Что будет, если документ не сделать, какие могут сыграть риски? Если эти риски сыграют, как буду гасить последствия? Мне это будет стоить всего нескольких дополнительных часов работы с разработчиком и аналитиком? Либо грозит тем, что заказчик скажет: вы мне этого не обещали, а вот это обещали, — и придется потратить дополнительные 20% бюджета?»
Соответственно баланс документации нужно искать, исходя из ответов на вопросы:
- Для кого я это делаю?
- Зачем я это делаю?
- Что будет, если этого не сделать?
- Чем мне это грозит?
Создавать документ под каждую потребность или объяснять устно — часто вопрос экономической целесообразности. Нужно понимать, что обойдется «дешевле»: рассказывать каждый раз новым участникам, что и как происходит на проекте, либо один раз написать это в Confluence.
Недостаточно собрать стартовый набор документации и расслабиться. Все, что РМ написал, нужно обновлять в течение жизни проекта.
Работа с документами в процессе
Конечно, с документами нужно работать систематически. Но бывает, что проект не очень приоритетный и ресурсы экономят за счет документации, тогда у РМ-а остается больше времени на другие активности проекта. Однако, когда поступят запросы от клиента, времени на ответ потребуется очень много.
Наталья Белоусова, PM в Redmadrobot:
Бывает так, что вы сэкономили на обновлении документации, а потом заказчик спрашивает:
«Ребята, а что, если в методах поменяем это и это, — у нас что-то полетит или нет?»
Вы отправляете запрос разработчику, аналитику, или тестировщику, либо сами смотрите, и понимаете, что на ответ придется потратить несколько часов. Поскольку это нигде не зафиксировано, сложнее разобраться, как все работает.
Правильнее обновлять документы «по ходу пьесы», но так получается не всегда.
Однажды мы 1,5 года жили без обновляемой документации. Продукт был вялотекущий, его поддерживали, периодически дорабатывали мелкие вещи, но ничего глобального не делали. Соответственно, экономили как могли и базу знаний не обновляли. При этом, клиент от нас не отказался, ничего критичного не случилось, просто тратили больше времени на запросы.
Чтобы не доводить ситуацию до критической точки, придерживайтесь правила: сделали фичу — и сразу апдейт документации. В процессе это занимает мало времени, а позже приносит много пользы. Если так не делать, то на большой дистанции увидите, что потратили кучу лишнего времени. Поэтому лучше обновлять всю документацию вовремя.
Если уж совсем некогда, попробуйте создать базовый шаблон, чтобы по нему делать экспресс вариант аналитики.
Денис Шаматажи Project / Product Manager в Redmadrobot, спикер курсов РМ hard skills: Planning и РМ hard skills: Release:
В стартапе однажды получилась ситуация, что документацию 9 месяцев никто не вел, просто не было времени. Все было хорошо, приходили инвестиции, а потом бурный рост прекратился. Когда проект стал развиваться медленно и линейно, оказалось, что мы ничего не знаем о происходящем: как работают API, где какие поля приходят. Все это почему-то было в бесплатном Slack. В какой-то момент, накопилось столько работы, что для написания недостающей документации понадобился бы месяц или больше.
В итоге, мы дотянули до того момента, когда разработчики начали жаловаться: «Ребята мы не можем отвечать на вопросы, что, где и как работает».
Пришлось выделить время на доработку и дальше мы старались в течение каждого спринта выделять время на поддержание документации в актуальном состоянии.
Правильные инструменты
Выбор неправильных инструментов — одна из причин, почему в растущем проекте снижается качество. Для ведения документации существуют разные форматы файлов и подходы.
Список самых используемых инструментов:
- Google Drive для хранения разного вида файлов с общим доступом и редактированием онлайн.
- Dropbox — альтернатива Google Drive. На Dropbox значительно раньше появилась возможность отключить какой-то девайс. Если, например, кто-то из сотрудников потерял телефон, то в Dropbox можно отключить доступ к этому устройству. Получается очень секьюрно.
- Confluence — общее рабочее пространство, база знаний для создания, хранения, редактирования документов.
- Notion — «википодобный» ресурс. Хорошо работает для базовой документации, особенно о каком-то продукте. В целом, можно использовать как замену Confluence и сильно экономить, потому что Notion дешевле.
- Miro помогает сделать быстрое ревью документа. Похож на большой lite-board или Paint, куда можно вставлять различную информацию: ретроспективу, анонсы, согласование дизайна со стейкхолдерами, превью дизайна с разработчиками.
Наталья Белоусова, PM в Redmadrobot:
Все, что можно, веду в Confluence, остальное — выкладываю в файлах на Google диск.
Для согласования требований с заказчиком удобно использовать Miro, потому что людям трудно воспринимать только словесные описания. Гораздо понятнее и продуктивнее сделать карты экранов в Миро, а во время общего созвона, дополнительно объяснить голосом и пройтись по кейсам. Заказчику понятно, к тому же он может прямо в Miro оставить комментарии. РМ поправит вместе с дизайнером, а заказчик отметит, что коммент решен.
Какими бы инструментами вы ни пользовались, соблюдайте базовые правила:
- Документация должна быть синхронной и, по-возможности, онлайн. Каждый сталкивался с ситуацией, когда приходят документы в виде Microsoft Word, PM вносит правки, скидывает обратно, — и все это длится максимально долго. Для удаленных команд с десятью часами разницы во времени, онлайн оборот особенно актуален: можно быстро редактировать документ и все это видят.
- Всегда проверяйте доступы. Иначе может получиться неприятная ситуация например, компания синхронизировалась с заказчиком по базе знаний в Confluence. Параллельно в базе вели учет: с кем компания работает, что за заказчик, по каким вопросам к кому обращаться. И была еще маленькая колонка — характеристика общения: этому человеку лучше писать в телеграм, этот — очень тяжелый, с этим лучше не общаться, а решать с другим. Заказчик увидел, был скандал, получилось некрасиво. Поэтому, как бы банально это не звучало, перепроверяйте права доступа.
Документов на проекте много, поэтому без логичной структуры легко запутаться. Когда навигация слабая, команда не сможет найти документ через поиск и будет считать, что нужной информации просто не существует.
Понятная навигация
Чтобы проектные документы приносили пользу, придерживайтесь простых правил:
- Нужные документы доступны из поиска.
- Навигация происходит по понятной древовидной структуре.
- Раз в квартал документация пересматривается.
Универсальных советов нет, отталкивайтесь от банального правила: задачи надо структурировать так, чтобы человек мог сформулировать свою боль и интуитивно найти ее в документации.
Иначе получится, что, например, нужно посмотреть, где лежат ключи от сертификатов, но искать придется среди названий типа screens, risks, requirements.
Денис Шаматажи Project / Product Manager в Redmadrobot, спикер курсов РМ hard skills: Planning и РМ hard skills: Release:
Есть такое понятие — «коридорное тестирование»: посадите кого-то, кто очень слабо знаком с проектом, дайте ему структуру вашего Confluence, и попросите что-то найти. Если 2-3 человека не могут найти документ интуитивно, значит, надо разбираться с навигацией.
У РМ-а на проекте много задач. Поэтому, если есть возможность делегировать на кого-то документацию, нужно сделать это максимально.
Делегирование
Делегировать тоже нужно правильно. Бывает, что РМ слишком доверяет команде, особенно, когда на проекте сильный аналитик. РМ настолько расслабляется, что перестает вникать в документы и позже, на этапе сдачи возникают проблемы.
Поэтому при делегировании не забывайте о проверке. Не идет речь о том, чтобы вычитывать все полностью. Нужен систематический просмотр обновленной документации, чтобы понимать все ли в порядке с аналитиком, тестировщиком, не заглох ли процесс, который настроили много месяцев назад. В этом и состоит искусство менеджмента — потратить немного времени и, при этом, не упустить процесс.
Денис Шаматажи Project / Product Manager в Redmadrobot, спикер курсов РМ hard skills: Planning и РМ hard skills: Release:
У меня часто возникала ситуация, когда ВА берет на себя всю документацию, не связанную с финансами. Тогда РМ выступает, с одной стороны, в роли аккаунт-менеджера, а с другой стороны – таким «отцом проекта», который следит за своим «семейством», чтобы оно не сделало ничего непутевого. В такой ситуации работа РМ-а сделать так, чтобы все продуктивно договорились и решили конфликты. Задачи по фасилитации занимают много времени, поэтому большую часть спек пишет аналитик, и тем не менее, я обязательно просматриваю все написанное.
Не стоит делегировать отчетность по финансам или акты с заказчиком, а вот бизнес-требования можно со спокойной душой передать ВА. При этом, обязательно читайте все документы, потому что сдавать проект придется РМ-у. Если в бизнес-требованиях будет что-то странное или невыполнимое, это нужно сразу откорректировать.
Что запомнить
Не существует универсального списка документов. Даже в одной компании, при одном способе ведения проектов, набор документации может быть разным, потому что отличаются клиенты, по-разному строится коммуникация с командами разработчиков.
Бывает формальный набор, например, для государственных компаний. Или более лайтовый — для обычных бизнес-заказчиков, с которыми можно говорить на человеческом языке.
Когда РМ понял, какие цели выполняет документ и кому предназначен, становится ясно, какие документы нужны, а какие нет.
В процессе жизни проекта:
- выбирайте правильные инструменты для хранения и работы с документами;
- создавайте навигацию, в которой сможет разобраться даже новичок;
- делегируйте работу, и проверяйте сделанное другими.
Как создавать документацию с пользой для проекта и не тратить много времени, рассказали в чек-листе. Оставляйте email — вышлем короткий список с подсказками.
