Рост команды, первые шаги

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

Люди мимоходом представлены друг другу — к чему пламенные речи, если к нам возвращаются друзья, с которыми с детсва мы делаем одно дело? Программист из прекрасного города Омска, где прошло его и дизайнера детство. Дизайнер, уже больше года живущий в центре Питера. Скиластый программер, талантливый дизайнер и наша команда…

Всё понятно, но что конкретно?

Идея есть, понимание перспективы есть, надо приступать к работе.

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

Когда я планировал рост компании, конечно же встал вопрос о командном взаимодействии и программного продукта для этих целей. Все, к кому я обращался, советовали basecamp. Наш программист предложил trac. Сам взвёл, русифицировал, рассказал и показал. С этого момента началась новая эра. Эра озадаченного молчания: любая задача заносится в трак и выполняется человеком в плановом порядке в зависимости от приоритета. Устная постановка задач воспрещается ввиду нерентабельности по времени (быть может вопрошающему и кажется, что решение его задачи займёт всего 5 минут, но для того, чтобы восстановить нормальный ритм работы программиста, вернуть его на основную задачу, зачастую после такого переключения требуется гораздо больше времени, например, попробуйте востановить смысл прерванного скобками повествования!). Задачи, какими бы простыми они не казались, записываются в тикеты, туда же идут глюки и ошибки, вопросы и пожелания. Проект выходит на стадию непрерывного улучшения.

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

Подразумеваемый Workflow

1. При возникновении задачи (не важно, баг это, мелкий фикс или новая фича) ВСЕГДА создается новый тикет.
   Тикету назначается майлстоун (дедлайн), т.е. срок, до которого его нужно закрыть (т.е. выполнить задачу).
   Разработчик смотрит список открытых тикетов и берет себе те, которые он может закрыть.
   Разработчик работает над одним или несколькими тикетами. При этом у тикета (-ов) меняется статус на assigned, т.е. «в процессе». Таким образом, всегда можно посмотреть, кто чем занят.
   После окончания работы над задачей разработчик закрывает тикет.
   
   NB Разработчиком может быть дизайнер, администратор и т.п., то есть любой человек, задействованый в проекте. Поэтому тикеты создаются для всех и каждого. Идеальный вариант, к которому нужно стремиться: нет тикетов — нет работы, есть тикеты — есть работа. Среднее число тикетов на рабочий день — 3 — 4 штуки.
   
   Как создать правильный тикет
   
   Тикеты бывают нескольких типов. Самые распространенные — это defect (баг, ошибка) и task (новая фича). При создании тикета важно правильно указать все его параметры и доходчиво описать задачу или ошибку. Если добавляется тикет о баге, то в описании тикета нужно указать следующие данные:
   
   
   • URL страницы с ошибкой
     Действия, которые нужно совершить
     Что ожидалось после выполнения этих действий
     Каков результат на самом деле
     
     Параметры тикета, которые нужно ОБЯЗАТЕЛЬНО указывать при создании:
     
     
     • Shor summary (Краткое описание)
       Type (Тип) — defect (баг), enhancement (небольшое некритичное улучшение), task (новая фича)
       Priority (Приоритет) — bloсker (мешает закрытию других тикетов), critical (сделать как можно быстрее), major (сделать), minor (сделать в свободное время), trivial
       Component (Компонент) — Компонент системы, к которому относится тикет
       Milestone — срок, до которого нужно закрыть тикет
       Version (Версия VideoZZ, к которой относится тикет) — trunk (текущая версия в Subversion) и deployed (то, что залито на сервер)
       
       Расставляются вехи (т.н. milestone) проекта, сроки исполнения некоторого набора улучшений. Сами тикеты имеют привязку к вехам, приоритет, а также разделяются на задачи (task), улучшения (enchantment) и багрепорты (defect). Задачи — это всё, что требует больше одной итерации или обсуждения, улучшения — небольшие конкретные улучшения в работе проекта. Багрепорты теперь не говорятся программисту, а записываются всеми участниками проекта.
       
       Заассигнил тикет — выполни его! Задача ставится на компонент проекта (проигрыватель видео, интерфейс сайта или социальная составляющая), обязательно расписывается в подробном описании, что облегчает последующую документацию. Трак связан с репозиторием и имеет встроенный вики, что позволяет связывать воедино весь процесс разработки («жду такой-то тикет» или «описано подробно в таком-то комментарии», «изменения в коде согласно такому-то тикету»). Уведомления на почту обо всём, что касается изменения тикета, всем, кого этот тикет касается (пользователю, владельцу компонента, прокомментировавшего) — таким образом решается вопрос обмена информацией в группе.
       
       На заглавную страницу трака проекта выносится в вики вся необходимая информация по проекту: участники, вехи, краткое описание проекта и его компонентов, сроки и готовность, где что лежит и кто за что отвечает. В самих тикетах подробно расписываются задачи условно говоря менеджерам подразделений — владельцам компонентов. Основную работу по расстановке задач и приоритетов берёт на себя менеджер проекта, оставляя на самостоятельное управление горизонтальный уровень:
       
       Надо сделать историю чата? Дизайнеру — нарисовать страницу и отдать программисту, который её заверстает и подключит. Попутно обсуждается порядок сообщений в истории, сверху вниз или снизу вверх, самые последние сверху и на первой странице или нумерация страниц должна идти с начала истории? Ответы на такие вопросы прописываются подробно к каждому тикету, в этих ответах и заключается пресловутое «юзабилити». Из единства реализации мелочей для посетителя складывается впечатление об удобстве сайта.
       
       Итак. Малая группа переживает рост. Расширяется штат разработчиков, стандартизируется хождение информации, определяются вехи, распределяется ответственность.
       
       —
       
       Предыдущий пост: Вирусный HR или На ловца и зверь бежит. Вирусный найм персонала.