Олег!
В бюро нет жёстких требований к тому, где и каким именно образом вести задачи и баги разработки. Главное, чтобы задачи не потерялись и были на виду у дизайнеров, а разработчики хорошо себе представляли, что нужно сделать.
Например, бюрошные разработчики самостоятельно записывают баги в Бейскемпе в виде тудушек по результатам устных и письменных обсуждений, а некоторые клиентские разработчики дополнительно ведут свои списки в других привычных им системах. Ну а я в своих проектах использую гугль‑доки. Точно не помню, когда и почему я это начал делать, но оказалось удобно.
Во‑первых, объяснение «правил игры» занимает не больше минуты устного разговора или нескольких строк текстом, а интерфейс гугль‑дока все уже и так знают. Во‑вторых, всё на виду и очень наглядно: гугль‑док превращается не просто в список, а почти что прогресс‑бар проекта — чем больше зелёного, тем ближе успех. В‑третьих, выдача доступа кому бы то ни было занимает секунды — не нужна никакая регистрация, в отличие от того же Бейскемпа. В‑четвёртых, всё хранится вечно и без необходимости помнить дополнительные пароли и адреса. В‑пятых, да, оно бесплатно.
Как это работает
С самого начала заводятся два списка: «Задачи» и «Принятые». В первый дизайнеры пишут баги, проблемы и задачи, во второй — переносят решённые задачи:
Начинается разработка, появляются баги и хотелки, всё заносится в документ. В сложных и разноплановых проектах лучше группировать задачи с помощью заголовков:
Разработчики продолжают пилить функционал и в какой‑то заранее согласованный момент принимаются за исправление багов. Исправленные баги они выделяют зелёным цветом, а те, что ещё находятся в работе, — многоточием в начале строки или ещё каким‑то способом:
Дизайнеры дописывают новые баги и принимают исправленные. Принятые баги они просто зачёркивают, не принятые выделяют оранжевым цветом и поясняют с помощью обычных комментариев гугль‑дока:
Кстати, любой баг хорошо бы дополнять скриншотом или ссылкой, но для скорости в своих примерах я решил обойтись без них.
Разработка продолжается, баги появляются, описываются и исправляются. Сложные случаи и непонятные проблемы обязательно проговариваются устно. В какой‑то момент исправленных и принятых багов становится так много, что пора переносить их в список «Принятые»:
Приближается время пуска и приходится расставлять приоритеты. Горящие и блокирующие пуск задачи дизайнеры выделяют красным:
Разработчики сделали рывок и за день поправили кучу всего. Много зелёного мотивирует и дизайнеров, и самих разработчиков:
И так далее до пуска.
Из неудобств работы в гугль‑доке получается припомнить только одну вещь: очень долго переносить принятые баги в нижний список.
Напоследок ещё один скриншот. В одном из проектов разработчики из компании «Цифрономика», партнёра бюро, придумали объяснять всё описанное выше с помощью легенды, которая добавляется в самом начале работы:
Если хотите попробовать, воспользуйтесь моей заготовкой гугль‑дока.
Приглашаю уважаемых советчиков поделиться своими секретами и фишками управления разработкой.