Когда-то давно, данная статья здорово мне помогла. Нашёл её в архиве и делюсь с вами. Спасибо, отделу аналитики и проектирования агентства Notamedia!
Демонстрационный пакет проектной документации
Нет, мы не сошли с ума.
Да, мы выкладываем наши внутренние документы.
Нет, мы не боимся, что у нас украдут наши наработки.
Да, вы можете это использовать в своей работе.
Их Величества грабли
Глава, в которой мы спокойно рассказываем про наш неспокойный путь к жесткой системной методологии.
Когда-то мы начинали проектировать так же, как и все — на коленке.
У нас не было методологии, у нас не было стандартов документации, у нас не было ни малейшего представления о правильных процессах управления проектированием. Наконец, у нас было мало людей.
Все, что у нас было — это желание составить полезный документ, который описывал бы все, что можно сказать о разрабатываемом продукте — сайте, мобильном приложении, да о чем угодно. Мы называли этот документ ТЗ, не зная, что через много лет откажемся от этого слова, найдем совершенно другие понятия и образы и создадим бронебойную, стройную и эффективную методологию по работе с требованиями. Нам предстоял долгий путь проб, ошибок и хождения по граблям.
Мы перепробовали следующие варианты:
- Писать ТЗ по чужим стандартам;
- Писать ТЗ по своим стандартам;
- Писать очень простые ТЗ;
- Писать суперсложные ТЗ;
- Делать прототипы до ТЗ;
- Делать отдельную аналитику;
- Отдельно составлять архитектуру;
- Еще тысячу странных вариантов.
Что-то сработало, что-то нет, а некоторые нововведения чуть не похоронили под собой несколько важных проектов.
Но мы не падали духом. Мы смотрели. Мы учились.
Мы искали правильный подход к проектированию — и мы нашли его. Мы создали Метод.
Что мы вам сейчас расскажем
Глава, в которой раскрываются наши планы.
Чтобы все было предельно просто и понятно, мы будем рассказывать о нашей проектной документации на примере простого, даже камерного проекта, придуманного специально для демонстрационных целей.
В реальной ситуации такой проект, конечно же, не потребовал бы столь глубокой аналитической проработки — но, тем не менее, он является удобным демонстрационным оъектом.
Мы будем рассказывать о создаваемых документах в том порядке, в каком они создавались бы в реальной жизни — и их содержимое будет максимально приближено к реальности.
Итак, поехали!
Что происходит перед продажей
Глава, в которой раскрывается последовательность действий на этапе продажи.
Как это часто бывает, началось все с письма. Оно было следующего содержания:
Добрый день!
Мы подбираем подрядчика по веб продакшену. Задача сделать уникальный сайт с красивым дизайном. Мы любим креатив и хотим его от вас.Сам сайт не сложный, тем более они связаны общей идеей. Наш бизнес — это родео на экзотических животных. Страусы, быки и хряки (к следующему году возможно расширение сети до овец и сельского сафари).
Сайты должны продавать и поражать. Скорее всего нужна будет анкета для заказа животного по дате и месту. Функционал минимален.
Необходимо проработать юзабилити, актуальный (трендовый и современный) дизайн и удобные интерактивные элементы (подсказки, карты и т.п.).
Как ориентир нашему руководству симпатичны сайты hh.ru или apple — просто, но и смотрится достойно.
Нам необходимо получить от Вас чёткое ценовое предложение.
Если у Вас есть опыт работы с продающими сайтами, то это стоит отразить в предложении.
Специфика правильного проектирования заключается в том, что оно начинается еще до продажи. Так произошло и здесь: после получения письма с клиентом было проведено предпродажное интервью и была составлена концепция продукта (ссылка на файл) — легкий документ, который позволил оценить примерную стоимость продукта и договориться на берегу о главных его чертах. Кроме того, данный документ показал клиенту степень заинтересованности исполнителя проекта и погружения его в предметную область.
Этим документом закончился этап предпродажной аналитики — но работа над продуктом только началась.
Жизнь после договора
Глава, в которой раскрывается суть этапа аналитики.
После подписания договора и проведения оплаты стартовал официальный этап аналитики. Он начался с обстоятельного интервью с клиентом, на котором были детализированы изначальные бизнес-требования и выяснены условия задачи, которую необходимо будет решить.
По итогам данного этапа постепенно конкретизировался и детализировался концепт, составленный еще на этапе пресейла (новые разделы в него, впрочем, не добавлялись).
После детализации концепта появилась необходимость подробно описать пользовательские задачи глазами простых пользователей, чтобы не упустить важные аспекты взаимодействия продукта с пользователями. Для этого были составлены и согласованы Сценарии использования (ссылка на файл) в формате пользовательских историй — подробных сценариев восприятия продукта пользователем.
На этом закончился этап аналитики (разбора условий) и начался этап проектирования (формирования решения).
Будни Бумажного тигра
Глава, в которой описывается работа над архитектурой проекта.
В начале этапа проектирования был составлен так называемый Бумажный тигр (ссылка на файл) — комплект бумажных (в редких случаях — электронных, но чаще именно бумажных!) документов, содержащих описание архитектуры будущего продукта.
Бумажный тигр был отвезен к клиенту и согласован с ним. Прямо на встрече в Тигра вносились нужные правки — это было легко и быстро сделать благодаря бумажному формату.
По итогам встречи клиенту был отправлен исправленный электронный вариант Тигра для дальнейшего согласования и утверждения.
Интерфейсы
Глава, в которой рассказывается про работу над прототипами.
После окончания работы с Тигром был составлен и согласован Прототип (ссылка) — схематичное изображение интерфейса, определяющее наличие или отсутствие тех или иных элементов, их логическую увязку и, отчасти, приоритет.
Прототип был составлен в Axure RP — пожалуй, самом универсальном инструменте для проектировщика интерфейсов.
Важно помнить, что прототип не определяет однозначно форму элементов, их окончательное положение, цвет и т.п. — все это будет утверждено только на этапе дизайна.
Окончательная фиксация требований
Глава, в которой рассказывается про работу над спецификациями.
Когда была согласована и общая архитектура проекта, и его интерфейсы, пришел черед «заливки цемента» — окончательной фиксации требований.
Эту роль выполнил документ под названием Спецификации продукта (ссылка на файл), исчерпывающе и комплексно описавший продукт с разных сторон — как со стороны интерфейсов, так и со стороны функционала и структуры данных.
Спецификации были согласованы с клиентом, доведены до сведения разработчика и легли в основу последующей разработки.
Зачем мы это сделали
Глава, в которой раскрываются все наши тайные мотивы, интенции и замыслы.
Наверное, вы удивляетесь, почему мы публикуем актуальный пакет проектной документации в открытом доступе.
Все просто.
Мы напрямую заинтересованы в том, чтобы все проектировали правильно, эффективно, с полным осознанием всех процессов, поскольку:
- Разумная конкуренция идей и взглядов позволит развивать методологию дальше, находить эффективные приемы проектирования и отсекать ненужные форматы документов и способы их согласования;
- Появление большого числа грамотных проектировщиков неизбежно приведет к тому, что клиенты начнут с бОльшим вниманием относиться к этапам аналитики и проектирования — и наша работа будет строиться еще эффективнее;
- Чем больше будет логичных подходов, тем лучше будет становиться мир вокруг нас, а одна эта цель заслуживает отдельного внимания.
Проектируйте на здоровье! И да восторжествует здравый смысл!