Для написания ТЗ мы используем Документы Google. Очень удобно работать одновременно, гибкие настройки доступа и возможность комментирования любой части документа. У нас все проекты разбиты по папкам в Google Drive, структура унифицирована и это позволяет сотрудникам быстро ориентироваться в портфеле проектов. Есть шаблоны документов и набор простых регламентов, по которым происходит документооборот. Самый большой плюс от работы с документами Google — заказчик очень легко вовлекается в процесс работы над проектом: комментирует, уточняет.

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

Перед началом работ по каждому из функциональных блоков мы делаем детальную оценку трудозатрат и согласовываем с заказчиком ТЗ. В зависимости от вида работ мы можем использовать разные шаблоны: начиная от «Описание бизнес-процесса as is» / «Описание бизнес-процесса to-be» и заканчивая пунктом «Обязанности заказчика». Такой подход напоминает чек-листы и помогает разработчику ничего не упустить. Учёт в разрезе проекта ведётся как раз на уровне этих функциональных блоков.

Если речь конкретно о ТЗ и управлении проектами, то у нас два основных инструмента: Basecamphq, Google Docs.

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

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

В CreativePeople любой проект начинается с разработки Задания. Несмотря на то, что мы работаем в том числе и со сложными интернет-проектами, назвать разрабатываемый документ именно «Техническим заданием» мы не готовы.

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

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

Несмотря на большое количество разнообразных инструментов для согласования текстовых документов (например, Блокнот в Basecamp, Google.docs и прочее), самым удобным всё-таки оказался обычный текстовый редактор (OpenOffice или MS Office), так как содержит минимальный набор необходимых возможностей (комментарии, режим правки, сверка версий) и знаком абсолютно любому клиенту. Пожалуй, единственным существенным минусом нашего решения для нас является необходимость последовательного согласования документа, что может увеличить общие сроки согласования. Однако уверенность в качестве созданного Задания данный минус пока «покрывает».

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

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

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

Для согласования ТЗ в основном используем Google Documents. Клиент вносит свои правки, работа идёт оперативно. Для коммуникации с клиентом используем Битрикс24, e-mail, Skype.

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

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

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

Работа по сбору, формализации и согласованию требований в нашей компании разбита на ряд стадий. Написанию технического задания предшествуют стадии сбора бизнес-требований, проектирования интерфейсов и (опционально) различных исследований.

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

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

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

Перед началом разработки ведущий разработчик детально знакомится с техническим заданием, составляет общий план работ. Если проект сложный, то план работ сначала делается в общем виде, после чего каждые2-3недели детализируется. План работ содержит список задач, которые переносятся в редмайн с указанием ссылок на конкретные разделы технического задания. Само техническое задание передаётся непосредственному разработчику, что позволяет ему быть в курсе всего проекта, а не только конкретной задачи.

Начальные требования клиента после первых бесед собираются нашими американскими коллегами в одном коротком письме. Они же чаще всего составляют начальный «план» проекта. Что-то вроде гант-чарта в Google Sheets. Этот самый первоначальный план мы обсуждаем с нашими американскими коллегами, насколько реалистичны данные оценки. План нужен для подписания контракта, чтобы дать клиенту ощущение, сколько может стоить проект. План не особо точен, диапазон оценок (между нижней и верхней границей) может быть один человеко-месяц.

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

По результатам одной или двух бесед складывается понимание, чего же на самом деле хочет клиент. Тогда UX-дизайнер с менеджером проектов облачают свои мысли в образы, используя сервис myBalsamiq. Это самое удобное средство для прототипирования из десятком нами опробованных. Готовые экраны системы обсуждаются с клиентом и выясняются «новые подробности». Зачастую эти подробности могут перевернуть понимание системы целиком.

Так проходит несколько итераций по прототипам. Иногда клиенты подключаются к процессу и вносят комментарии прямо в myBalsamiq. Но чаще всего они ограничены по времени и максимум, что можно добиться — обстоятельной беседы и нескольких писем с мыслями, которые к ним пришли уже после звонка и внутренних обсуждений. Да, все звонки мы проводим или в Google+ Hangouts, или через Скайп. Последний, правда, обладает худшим качеством.

Все комментарии к экранам мы пытаемся разместить там же, внутри прототипов (обклеивая их жёлтенькими листочками с комментариями). Это позволяет ещё раз подтвердить наши мысли с клиентом. Все более обширные комментарии мы проговариваем с клиентами по почте и вносим в Simplenote или более ужасный по интерфейсу Evernote. Записи в онлайн-блокнотах нужны не для синхронизации с клиентом, а как слабо систематизированное хранилище данных о проекте. Туда смотрят и менеджеры, и UX-дизайнеры и разработчики.

Когда фаза прототипирования заканчивается, мы переходим к графическому дизайну. Здесь все экраны делаются в Photoshop и ещё раз обсуждаются с клиентом. Прототипы описывают то, какую информацию мы хотим разместить на экране и принципы взаимодействия с системой. Графический дизайнер принимает конечное решение, как должны выглядеть элементы интерфейса. Он может предложить своё видение элементов интерфейса и т. п. Фактически он производит «полировку» UX приложения. Иногда встречаются заказчики, которые не могут полноценно оценивать систему по прототипам. Для таких приходится раньше выходить на стадию графического дизайна.

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

• Проверить несколько технологических гипотез, которые внушают нам наибольшие опасения (например, работающая интеграция с какой-то системой, на которую можно было потратить от 2 дней до 2 недель).
• Как можно раньше показать клиенту «работающую» будущую систему.

Когда у нас есть понимание системы, прототипированная система в виде вайрфреймов, дизайны экранов, прототипы кода для решения сложных технических проблем, то мы планируем её реализацию. Для этого мы модифицируем высокоуровневый, стратегический план проекта в Google Sheets. Минимальный элемент здесь — фича. Минимальный интервал — неделя. Эдакий гант-чарт, который мы обсуждаем с клиентом. На основе стратегического видения мы планируем итерации в Pivotal Tracker. Там уже маленькие задачи, каждая имеет исполнителя.

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

Просуммирую вышесказанное:

• Самое главное техзадание — видение проекта в голове менеджера (он же у нас по совместительству техлид).
• Техзадание представлено в виде набора макетов myBalsamiq, экраны снабжены комментариями по работе определённых частей.
• Вещи, которые не находят отражение в интерфейсе пользователя, обсуждены с клиентом по почте и систематизированы в онлайн-блокноте.
• Клиент утверждает конечные экраны системы. Это могут быть как Look & Feel приложения + несколько дополнительных элементов интерфейса, так и детальные поэкранные рисунки.
• Проект ведётся в Google Sheets (стратегически) и Pivotal Tracker (тактически).
• Изменения в процессе работы вносятся во все составляющие.