Разработка сайтов

В этом гайде наглядно объясним, как выстроить в WEEEK процессы разработки сайтов с помощью Канбан-досок и диаграммы Ганта. Пригодятся и наши новые инструменты — спринт-доски и WIP-лимиты.

Чем поможет гайд

Шаг 1. Выстраиваем процессы 

Для начала создадим новый проект под разработку сайта. 

В WEEEK для этого есть отличный шаблон с Канбан-доской. Чтобы найти его, в левом нижнем углу кликни на «Шаблоны» — «Разработка и продукт» — WEB Development. Шаблон достаточно многоступенчатый: если твой процесс чем-то отличается, просто переименуй или удали ненужные колонки. Я тоже немного упрощу доску и уберу несколько колонок.

Кстати, одно из недавних обновлений WEEEK — цветные колонки. Добавляют проекту наглядности — круто же!

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

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

Когда мы настроим зависимости, связи между задачами будут отображаться на диаграмме Ганта.

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

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

Шаг 2. Планируем спринты

Теперь в WEEEK можно заводить специальные доски под спринты. Это обновление особенно пригодится для разработки.

Спринты — это часть Scrum-методологии, отрезки работы по 1–4 недели с чёткими задачами на этот срок. Они позволяют делить большой проект на составляющие (инкременты) и делать конечные цели более понятными для команды. 

В нашем случае конечную цель можно сформулировать как «Запилить сайт», но тогда усилия команды будут разрозненными, а работа — неравномерной. Когда глобальная задача масштабная, проще разделить её на этапы, из которых сложится финальная версия.

Этими этапами могут быть, например, «Запилить дизайн сайта», «Запилить контент» или «Запилить, чтобы все кнопочки работали» (прости за формулировку, я всего лишь копирайтер 🙂).

Для примера сделаем отдельный спринт по дизайну. Разделение по колонкам оставим дефолтное — и, конечно, сделаем их разноцветными.

💡 Кстати, у нас есть подробный разбор о том, как планировать спринты

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

Шаг 3. Контролируем нагрузку

Ещё одна возможность WEEEK из серии декомпозиции работы — WIP-лимиты, расшифровывается как Work in Progress. Это ограничение по числу задач, которые одновременно могут быть в работе.

Зачем нужны WIP-лимиты: если разработчики примутся очень много и быстро кодить, то «бутылочное горлышко» образуется в тестировании, и работа станет неравномерной. Или дизайнеры интерфейсов решили отрисовать все страницы сразу, а на редакторов упал месячный объём работы с пометкой «срочно».

WIP-лимиты напоминают: не надо копить задачи на одном этапе работы, усилия надо распределять.

Подробно о том, как внедрить WIP-лимиты не только в планер, но и в сознание сотрудников, мы уже рассказывали. В WEEEK они включаются отдельно для каждой колонки доски — по количеству задач или по времени исполнения. 

Вернёмся на нашу основную доску. Чтобы тестировщики в колонке «Тест» не умирали от нагрузки, установим WIP-лимит на предыдущую колонку «Разработка». Так куча фич от разрабов не прилетит на тест одновременно.

Предельное число задач отображается рядом с названием колонки. Добавить в неё больше пяти задач не получится, разве что, если специально разрешить превышать этот лимит. 

Если ты — гуру планирования, WIP-лимиты можно выставить не только по задачам, но и по предполагаемым затратам времени в часах.

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

Шаг 4. Детализируем задачи

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

У WEEEK есть все нужные инструменты: теги, дедлайны, исполнители, описания. В идеале команда должна увидеть карточку и понять, что делать и куда идти. А если всё-таки что-то нужно спросить, можно сделать это здесь же — в комментариях, отметив руководителя. 

Благодаря продвинутому редактору и интеграциям, ты можешь подшить к задачам код на гите, дизайны в Figma, документы в Google Docs, мудборды, картинки или видео с котиками — в общем всё, что поможет в работе.

Особенно пригодятся кастомные поля. Это специальные поля в задаче, сделанные под конкретный проект — например, «Согласовано» или «Ссылка на макет».

В WEEEK есть 9 разных типов кастомных полей. Недавно появилось поле «Утверждающие»: в нём можно отмечать тех, кто должен проверить выполненную работу.

Какие ещё функции пригодятся