Как лень научила нас поддерживать проектную документацию актуальной

Рассказываем, как работает с документами IT-отдел TEAMLY, чтобы тестирование и релизы не превращались в ад из доработок

Всем привет! На связи команда TEAMLY. Мы создаем платформу для совместной работы и управления знаниями.

В TEAMLY можно организовать работу IT-отдела от концепции до релиза:
✅ создавать отдельные пространства для каждой команды и настраивать права доступа к файлам и папкам;
✅ использовать Умные таблицы, календарь, диаграммы Ганта и канбан для планирования проектов и спринтов;
✅ писать документацию, Release Notes и шаблоны с отрывками кода, таблицами, чек-листами;
✅ собирать данные о багах в формах обратной связи и отслеживать эффективность работы в диаграммах;
✅ интегрировать с другими сервисами: мессенджерами, почтой, GitHub, GitLab и многим другим.

Попробовать TEAMLY бесплатно

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

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

В статье поделимся, как мы прошли через этот этап и упорядочили ведение документации и почему наши сотрудники сами поддерживают информацию актуальной.

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

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

Четкость в организации работы позволяет добиваться целей и выдавать стабильный результат. Это так не только для IT-сферы,
но и для маркетинга.
Как взять беспорядок в процессах и задачах под контроль, если вы руководите департаментом маркетинга или маркетинговым агентством? Ответы на нашем вебинаре 3 сентября.
💡 Узнайте, что повышает продуктивность команды
и эффективность кампаний!

Зарегистрироваться

А пока вернемся к работе с документацией внутри нашего IT-отдела.
В итоге структура базы знаний выглядит так:

На главной странице статьи, которыми мы пользуемся чаще всего: Release Notes, информация про хосты.
В быстрых ссылках слева закреплены основные разделы.
Бэклог организован в Умной таблице, в задачах есть ссылки на документацию, а информация дублируется. Из документации тоже можно сразу увидеть, какие задачи запланированы для выполнения функционала.
Задачи сгруппированы: тимлиды выводят бэклог по командам, спринтам или проектам, а исполнители могут посмотреть только то, что должны сделать именно они.
Есть представление этой же Умной таблицы для отображения функций, готовых к релизу. Тут же хранится архив и инструкция, где написано, кто и как отправляет обновления в релиз (её написали сами фронтенды).
Мы ведем Release Notes — фиксируем результаты работы. Это особенно полезно для команды, которая внедряет коробочные версии, и для тех, кто работает с контентом для нашего сайта и социальных сетей.
Есть описание рабочих процессов компании для менеджеров: онбординг и обучение, зоны ответственности сотрудников.
Там же хранятся результаты обсуждений прошедших спринтов. На таких собраниях мы фиксируем, как решали необычные и сложные ситуации, какие возникали ошибки и как их предотвратить, чтобы не наступить на грабли дважды.
Ну и отдельный раздел с проектной документацией — подробнее в следующем блоке.

Из задачи в <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fteamly.ru%2F%3Futm_source%3Dvc%26amp%3Butm_medium%3Darticle%26amp%3Butm_campaign%3Ditdocs&postId=1411579" rel="nofollow noreferrer noopener" target="_blank">TEAMLY</a> можно сразу перейти в связанную проектную документацию и наоборот

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

Менеджеры заводят по нему новые задачи, а команда использует информацию оттуда на каждом этапе разработки.

Шаблон проектной документации выглядит так:

В начале документа есть краткая информация о статусе задачи, названиях функций и ответственной команде. Там же ссылки на артефакты, которые команда использует и заполняет на всех этапах работы: ТЗ, макеты, тест-кейсы.

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

Дальше мы согласовываем верхнеуровневое ТЗ с командой, в том числе с разработчиками. Так мы сразу понимаем, можно ли вообще реализовать то, что мы напридумывали. Согласовывать можно в самом TEAMLY — личные встречи и планерки не нужны.

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

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

Год назад мы выпустили сложный функционал. Разработчик, который его реализовал, больше не работает в компании, а продакт-менеджер на момент релиза был в отпуске. Месяц назад мы обнаружили баг, который нужно срочно исправить.

Команда открыла документацию и обнаружила, что в процессе работы функционал выполнили совсем не так, как задумали изначально, но никто не зафиксировал изменения. В результате
на отладку ушло 24 часа вместо двух!

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

Каждый из команды хоть раз сталкивался с подобными ситуациями. Именно такие моменты мотивируют сотрудников поддерживать документацию актуальной. Мы сделали актуализацию базы знаний частью бизнес-процесса и выделили на это время.

Ради чего мы навели порядок в базе знаний? Вся информация, нужная для работы, хранится в одном месте.

Вот какие в этом плюсы:

Все сотрудники в курсе обновлений, несмотря на размер штата: команды могут выпускать совместные решения.
На всех этапах разработки команда пользуется документацией, которую мы подготовили.
Из одной статьи можно управлять всеми этапами работы над функционалом — не нужно проводить личные встречи.
Тестировщики не отвлекают продакт-менеджеров и разработчиков вопросами, они просто изучают четкую и конкретную информацию.
Если баг попал в релиз, можно понять из документации, как всё должно работать. Если сотрудники, трудившиеся над этим функционалом, уволились, на больничном или в отпуске, информация не потеряется.
Легко писать пользовательские инструкции: в документации есть референсы, скрины и подробные описания.
Релизы выходят спокойно и вовремя. Все этапы работы регламентированы, каждый знает, что и к какому дедлайну должен сделать.

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

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

Узнать о TEAMLY больше

А о том, как навести порядок в процессах и задачах в маркетинге, можно узнать от нашего эксперта на вебинаре.

Юлии Морозовой есть чем поделиться: она руководит нашим отделом маркетинга и обладает большим опытом в выстраивании бизнес-процессов и управлении проектами.
➡️ Регистрируйтесь и вносите событие в календарь