Начиная наш разговор, давайте уточним, что ТЗ на разработку системы или приложения — это зачастую не единичный документ, шаблон которого можно найти в Интернете, а группа создаваемых документов (так называемых “артефактов”).
Хорошее ТЗ максимально четко и однозначно определяет требования к проекту и для команды, и для бизнеса, делая прозрачными конечные цели и задачи. Благодаря нему уточнять требования к проекту по ходу разработки нужно существенно реже, а приёмка готового продукта происходит проще и быстрее.
ТЗ бывают крайне разными. Наполнение и содержание напрямую зависит от проекта, производственных процессов и подхода к разработке. Например, ТЗ для приложения, которое создается по модели Waterfall, не совпадает с ТЗ приложения, команда которого работает по Agile. Они, как двоюродные братья: общие черты есть, но и различий хватает.
Наши аналитики часто сталкиваются с представлением о том, что ТЗ — общее, верхнеуровневое описание стратегии или идеи приложения. Встречается и другое мнение: ТЗ обязательно должно быть объемным, и чем больше в нём страниц, тем лучше.
Для нас это не так. То, зачем и в каком объёме пишется ТЗ, в каждом случае определяется командой. Мы формируем его на основе конкретных задач проекта, списка пользовательских требований и критериев качества, а не по стандартным лекалам. На выходе это — набор смысловых блоков, разделов документа, который определяет необходимые и достаточные требования бизнеса и команды разработки.
Разрабатывая ТЗ, аналитики должны определить и прояснить требования к проекту на основании требований стейкхолдеров. Стейкхолдеры — заинтересованные лица, которые существенно влияют на принятие решений по проекту.
Со стороны бизнеса это, как правило — собственники, руководители, акционеры. Со стороны разработки: разработчики, проджект-менеджеры, QA-специалисты и др. Со стороны внешних систем (от бизнеса или технической команды исполнителя) — архитекторы ПО либо разработчики.
Обычно в формировании бизнес-требований изначально участвуют топ-менеджеры. Хотя зачастую требования к продукту исходят от конкретных сотрудников или отделов, которым предстоит активно пользоваться им. Эти требования могут быть как утверждены, так и не утверждены высшим руководством.
Важно учитывать мнение о процессах разработки и со стороны технической части. Гораздо лучше для проекта, если команда сразу знает, кто входит в круг заинтересованных лиц и формирует цели приложения, а не выясняет перед релизом.
Чем больше стейхолдеров, тем больше углов зрения учитывается при разработке ТЗ, и выше вероятность, что документация по проекту разрастется.
Примером объемного ТЗ служит ТЗ, написанное по ГОСТ. С такими мы работаем редко. Прежде всего, потому, что документы этого типа нечасто требуются нашим клиентам. Они нужны, когда ожидается долгое и многоступенчатое согласование деталей. Например, с госструктурами без ТЗ по ГОСТ работать проблематично: слишком много стейкхолдеров участвует в обсуждении проектов.
ТЗ по ГОСТ применяется на проектах, где важны максимальная полнота технической информации и стремление предельно четко определить требования к продукту. Документы насыщены информацией и деталями, от этого они теряют в читабельности и в простоте для восприятия. На разработку ТЗ по ГОСТ уходит много времени, и прорабатывать его стоит только тогда, когда оно объективно нужно на проекте.
Каковы границы проекта? Аналитик начинает прорабатывать любое ТЗ с поиска ответа на этот вопрос. Чтобы разобраться, нужно:
В процессе прояснения задач проекта и требований к нему создаются артефакты. Они нужны для фиксации договоренностей, достигнутых между клиентами и командой, и дальнейшего уточнения ограничений в выбранном варианте реализации.
На первом этапе анализа мы готовим артефакт под названием Vision — наше видение проекта. Этот документ определяет границы будущего приложения, которое планируется разработать. В Vision аналитики определяют и явно формулируют цели всего приложения. Важно зафиксировать их так, чтобы все стейкхолдеры понимали смысл одинаково.
Также на этом этапе аналитики определяют основной скоуп фич и цель создания каждой фичи. Иначе говоря, определяем, что надо сделать, и зачем.
На втором этапе на основе Vision мы можем сделать грубую оценку разработки и более точную оценку аналитики. Определяем структуру документации по проекту — какой комплект артефактов понадобится для исчерпывающего описания программного обеспечения, какие правила наполнения, управления изменениями и оповещения будем использовать.
Нужно понять: зачем нужен каждый артефакт? Конечно, мы всегда можем составить максимально подробный комплект документов, но это должно быть обосновано. Если клиент торопится выпустить новый продукт на быстро развивающемся рынке, начинать работу лучше с минимального набора артефактов.
Создание полного комплекта артефактов — дело небыстрое, сдвигает по времени и старт разработки. Лучше не плодить архивы, а определить цели создания и ценность всех артефактов и разработать действительно важные.
Цели разработки артефактов у заинтересованных лиц могут разниться и доходить до противоположных. Задача команды — сформулировать и выявить противоречия, точно установить задачи каждого документа и проекта. Увидеть, какими должны быть артефакты, команде помогают критерии качества.
Выбрав критерии качества, актуальные для проекта, мы снова определяем, какие ожидания есть у стейкхолдеров, вносим технические коррективы и проясняем, что нужно команде, чтобы продолжить работу.
Теперь можно заниматься глубокой проработкой ТЗ: детализацией частей системы и углублением в нюансы. В дальнейшем мы можем вернуться к обсуждению проекта со стейкхолдерами, если появится потребность изменить часть системы, или откроются новые детали, требующие внимания.
При проработке ТЗ аналитики нередко используют шаблоны документов. Они используются, как черновики структуры документов либо как референсы, и наполняются информацией под задачи. Например, мы используем такие шаблоны, как Видение, Роли-кейсы, ТЗ, Описание прототипов. При наполнении мы добавляем в каждый документ описания частей системы с разных ракурсов, позволяющие точно понять требования к программному обеспечению.
Аналитик выбирает шаблоны в зависимости от проекта. Так, например, прототипы интерфейса и описание элементов можно не делать, если речь идет о панели администратора со стандартными интерфейсами. Как правило, общего описания основных сценариев достаточно.
Критично важно сразу учесть, на какой платформе будет выпущено приложение. Это задаёт технические ограничения и базовые характеристики. Например, в приложении на Android кнопка “Назад” на экране не обязательна, а в iOS необходима, там нет физической кнопки “Назад”.
Немаловажно учитывать, что основа мобильного приложения сейчас — визуальная часть, а главная часть логики ложится на сервер. Изменение требований к визуальной части зачастую влечет необходимость переделки большей части приложения. Как следствие, растут затраты на разработку.
При проработке ТЗ приложения аналитики выявляют и определяют технические требования и ограничения, например, какие версии OS должны поддерживаться. Некоторые фичи, предлагаемые клиентом или командой, могут быть недоступны для старых версий либо требовать дополнительных затрат времени при реализации.
Как показывает опыт Azoft, есть случаи, когда важно прорабатывать ТЗ с начала проекта, а есть — когда можно начать с верхнеуровневого описания и динамично стартовать по Agile.
Детальная проработка ТЗ перед стартом разработки нужна, когда заказчикам принципиально важно зафиксировать сроки и стоимость работ.
При этом стейкхолдеры должны быть уверены, что изменения в требованиях после подробного описания и оценки будут минимальными.
ТЗ помогает, когда клиент выбирает подрядчика среди множества вариантов, сравнивая условия сотрудничества. Четкое и однозначное ТЗ — возможность убедиться, что все потенциальные подрядчики точно оценивают одно и тоже. Оно позволяет выбрать команду разработки взвешенно.
Чем больше неизвестных характеристик и меньше деталей, тем шире простор для интерпретаций. Особенно это актуально для крупных компаний, которые ищут подрядчиков поступенчато. В принятии решения о выборе разработчиков участвует много людей, это создает риск, что в процессе отбора информация исказится.
В таких случаях можно начинать с проработки “Видения” проекта. Под него подбирают команду, подходящую по технической экспертизе и опыту разработки продуктов в условиях динамически меняющихся требований. С этой командой, определив цели и границы будущей системы, можно стартовать работу по методологии Agile. Разработчики регулярно выкатывают промежуточные версии системы, что позволяет заказчику эффективно корректировать требования по ходу разработки.
Аналитику невозможно не делать — для разработки проекта команда в любом случае должна прояснить и уточнить все требования к нему. Часть этого процесса начинается ещё до разработки системы, часть происходит во время неё. Клиент выбирает: либо он контролирует аналитику, либо аналитика протекает стихийно.
Проработка ТЗ, как часть аналитики, позволяет управлять соотношением числа деталей, которые проясняются заранее и по ходу реализации.
При создании и проработке ТЗ аналитики в Azoft максимально учитывают специфику каждого проекта и требования к нему. Они помогают клиенту найти баланс между естественным желанием всё предусмотреть заранее и желанием начать тестировать готовый функционал, а не в сотый раз перечитывать описание.
Если вы хотите заказать приложение, и вас интересует разработка ТЗ, напишите нам на [email protected]. Мы будем рады обеспечить ваш проект услугами профессиональных аналитиков.
Все
Технологии
Ликбез
Места
HowTo
Стартапы
Новости
Сервисы
Приложения
