Как не профакапить дедлайны. Таск-трекер для разрабов и не только

Без нормального таск-трекера в разработке — не жизнь. Он нужен, чтобы сформировать план проекта, разбить его на спринты, наметить график выхода версий и напоминать всей команде о сроках в мягкой и ненавязчивой форме, не вызывая излишней тревожности в хрупкой психике разработчиков, дизайнеров и прочих девопсов.

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

Сегодня на связи Николай — молодой разработчик, участник IT-стартапа. Ему слово.

Мы вместе ещё с универа. Мы — трое друзей, Сергей, Виктор и Николай. Мой папа Юрий Алексеевич называет нас не иначе как «Серёга, Колька и Витёк». В этом списке я — Колька. Папа консультировал наш совместный диплом, оформил нам акт внедрения и предложил развивать проект дальше с тем, чтобы вывести его на рынок.

Папа давно в ИТ, начинал разработчиком, а теперь бизнес-аналитик в крупном интеграторе. С его лёгкой руки у нас появился бизнес-ангел, даже продюсер Пётр Сергеевич, который дал нам стартовый капитал. Теперь мы за полгода должны выйти на стадию MVP — минимально жизнеспособного продукта. Тогда продюсер запустит маркетинг — эти издержки он берёт на себя. И, надеюсь, за следующие полгода мы выйдем в плюс, вернув продюсеру долг. А возможно, он сам нас выкупит — время покажет.

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

Рассказывать о финансовых условиях я не имею права, как и о сути проекта — мы подписали кучу всяких документов, в том числе и NDA. Зато могу рассказать об условиях контроля, которые папа и Пётр Сергеевич нам поставили.

Во-первых, мы должны вести бэклог. Папа рассказывал, что когда дискеты были большими, а мониторы — маленькими, они расписывали график выхода версий и патчей на бумажке, а напоминал о сроках сдачи задач начальник отдела. В то время ни о дедлайнах, ни о тимлидах, ни о мобильных приложениях с уведомлениями даже не слышали. Хорошо, что сейчас с этим нет проблем.

Во-вторых, в бэклоге должны быть задачи по сдаче очередного этапа. Проверяют нас папа и Пётр Сергеевич лично.

В-третьих, оба наших старших должны иметь доступ на чтение к бэклогу.

В-четвёртых, мы должны вести техническую документацию:

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

Нас жизнь к такому не готовила, придётся осваивать всё в процессе или брать в команду технического писателя — в принципе, бюджет пока позволяет. Взяли же мы дизайнера.

Когда папа ещё сам писал код, у него в компании использовали связку Confluence + Jira + Mercurial. Теперь Конфлюэнс и Джира с Россией не работают, нужно какое-то отечественное решение. Папина компания после долгого выбора перешла на TEAMLY, а папа в категоричной форме порекомендовал и нам этот сервис, ибо не хотел заморачиваться с изучением ещё одной платформы.

Мы решили, что от добра добра не ищут. Взяли те пять условий, которые нам обозначили старшие, и наложили их на функциональность Тимли. У нас, как говорит один популярный обзорщик ресторанов в своих шортсах, «всё поженилось». Решили интегрироваться с GitLab.

Папа настолько всё контролирует, что сам завёл аккаунт и пригласил в него нас. Мы создали рабочее пространство, откуда очень просто попадать в нужный раздел.

1. Бэклог — создали по шаблону и выкинули лишние для нас состояния.

2. Спринты переименовали в этапы и сделали месячную периодизацию — так удобнее и нам, и старшим.

3. Этапы переименовали в Стадии.

4. Написали головные статьи для технической документации. По мере разработки туда будут постепенно добавляться зависимые статьи.

5. Сделали головную статью для «протоколов» решений.

6. Отправили приглашения Петру Сергеевичу.

О протоколах мы долго думали. Сначала хотели дать права на редактирование только одному из нас, назначив его самым честным. А потом познакомились с Тимли поближе и решили, что нам это не нужно — если кто-то что-то поменяет, всегда можно поднять историю. Так что править решения задним числом будет себе дороже.

В руководстве TEAMLY описаны две реализованные на платформе модели — ролевая и правовая. Мы пока не заморачивались с правовой, сделали по ролям.

Редакторы могут изменять любой объект в пространствах TEAMLY, но не могут менять права доступа для себя или другого редактора.

Вкладки Отделы и Группы дают возможность применения прав к группе пользователей «оптом». Включение пользователя в отдел или группу означает, что он автоматически получит такие же права, как и остальные участники группы или отдела. Например, при создании нового рабочего пространства можно будет выдать доступ к нему сразу нескольким «пачкам» сотрудников. Мы создали свои отделы — Разработка и Дизайн.

Администратор может всё то же, что и редактор, плюс управление пользователями. Ему также доступно управление:

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

Основной каркас проекта у нас уже был — тот самый диплом. Но папа и Пётр Сергеевич посоветовали мягко, как они это умеют, дополнить наше приложение блоком аналитики — пока на рынке такого нет, поэтому у нас будет конкурентное преимущество.

Блок аналитики мы описываем в двух местах. Во-первых, это статья «Блок аналитики. Описание» в разделе «Техническая документация / Архитектура приложения». Во-вторых, это майнд-карта «Блок аналитики.Концепция» на верхнем уровне рабочего пространства.

В Тимли удобно сделана работа с задачами. Когда мы писали диплом, я вёл примерно такой же лог, только попроще, на Ноушн. А умные таблицы TEAMLY — полный аналог баз данных Notion, так что всё привычно и знакомо.

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

А Сергей, Виктор и дизайнер Алина работают только в канбане, им так удобнее.

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

А когда задача уходит на документирование, происходит три события: уходит уведомление Сергею, дата исполнения меняется на текущую и исполнителем назначается Сергей.

В самой задаче автор пишет краткое содержание, я устанавливаю приоритет и сроки. Если есть взаимные блокировки, мне удобнее пользоваться интерфейсом диаграммы Ганта — в ней и сроки видно нагляднее. А ещё, отфильтровав её по исполнителю, я вижу текущую загрузку и стараюсь сделать так, чтобы разработчик не решал одновременно более трёх задач. Ну и отслеживаю дедлайны, разумеется, тоже в Ганте — более наглядное представление сложно себе вообразить.

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

Документирование мы ведём в статьях, а Глоссарий взяли штатный, так гораздо удобнее, чем городить свой. На рисунке он отмечен красной стрелкой.

Синяя рамка выделяет наше рабочее пространство «Проект Б».

Документация по проекту делится на три больших блока:

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

Одноуровневая концепция принята и относительно решений — это «протоколы», в которых мы фиксируем результаты обсуждений, чтобы потом не было разночтений в стиле «я не слышал», «я думал иначе» или «мы об этом не говорили». Работа над дипломом научила нас предварительно снимать конфликты определений, а все используемые термины мы заносим в Глоссарий.

А вот раздел «Архитектура приложения» будет иметь уже не один уровень вложенности и перекрёстные ссылки на, как минимум, раздел структур данных. В нём будут храниться не только описания полей базы, но и описания базовых классов. Что не освобождает разработчиков от комментирования кода. Здесь процесс такой: описал класс, сделал комментарии, почти что один в один перенёс в статью.

Для чего это дублирование? В случае, если придётся брать ещё разработчиков, не заставлять же их читать весь исходный код в поисках описания класса.

Процедурам и функциям бизнес-логики посвящены отдельные статьи. В них тоже будет множество вложений, а в самих статьях — отображение вложенных, но по разделам. Порядок примерно тот же:

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

Пока что мы сидим на бесплатном тарифе. Семи аккаунтов, каждый из которых может редактировать контент, нам хватает, в том числе и для старших. Но закрадывается мысль перейти на тариф «Командная работа» — 199 рублей в месяц при оплате за год за редактора, зато нет ограничений по функциональности. В частности, нам здорово помог бы AI-ассистент, а сумма в 14,5 тысяч (199*6*12) рублей в бюджете проекта выглядит достаточно смешно.

Чем бы мы «нагрузили» AI:

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

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

Больше новостей, фишек и лайфхаков в нашем телеграм-канале. Присоединяйтесь!