Про Технические задания и Проектные требования
02.03.2018
Недавно мой коллега Алексей Горностаев выразил давно обсуждаемое недовольство качеством технических заданий на разработку или создание интеграций с внешними системами. Попробую выразить свою позицию.
Большинство Заказчиков не обладают штатными специалистами, которые способны сформулировать ТЗ на разработку, а собственная занятость и представление о желаемом решении часто воплощается в простые текстовые пояснения на том уровне, который доступен Заказчику. Это не хорошо и не плохо, это факт, с которым работают потенциальные Исполнители работ.
Мы живем в несовершенном мире, потому эмоционально реагировать на подобные ситуации не имеет смысла, ведь повлиять системно на это невозможно одной компании или человеку. Но можно помочь Заказчику стать немного системнее. Покажу на примере, как это делаю в своем Агентстве для некоторых проектов, где Заказчики готовы вовлекаться.
С конца декабря 2017 года один из моих клиентов запросил проведение выездного анализа процессов и составление Проектных требований по итогу анализа. Первую часть работы я прекрасно знаю, но Проектные требования в первой своей версии напоминали классическое ТЗ на разработку IT-проекта. И это не понравилось Заказчику. Он хотел Проектные требования, как предварительный этап до ТЗ. Это был вызов к компетенции.
Поиск в интернете не дал результата, кроме как изучить серьезные книги мудрых авторов. Времени не хватало, книг в продаже недостаточно, электронных вариантов не купить. Логические рассуждения заставили разработать собственный подход к созданию проектных требований на основе пояснений Заказчика.
Проектные требования — документ, которые позволяет составить структурированное представление о том, как Заказчик представляет себе работу будущей системы. ПТ включают в себя алгоритмическую часть, функциональную и ролевую. На его основе проходят обсуждения среди трудового коллектива, корректируется ролевая модель, появляются новые вопросы. Но при этом Заказчик получает понимание всех процессов, происходящих в системе на доступном ему языке. Вот как это выглядит на примере простого процесса авторизации в системе.
*В этом месте смотрим скриншот.
Новый документ был принят без замечаний, проведен дополнительные обсуждения и уточнения, сейчас внесены правки для перехода к макетированию и ТЗ.
Это один из множества процессов, которые происходят в Системе. Часть из них полностью технические и для пользователя представляют интерес только с точки зрения названий элементов интерфейса. Но другие процессы и функциональные сценарии дают понимание, как именно Пользователь будет работать в системе:
- Сколько будет нажатий мышки;
- Сколько окон откроется;
- На что он должен будет обращать внимание;
- Какие поля ему предстоит заполнять;
- Как будет реагировать система на его действия.
Главное отличие ТЗ от Проектных требований в том, что на основе Проектных требований можно составить макеты интерфейсов и подготовить ТЗ, а на основе только ТЗ получается оторванный от реальности макет и «иначе работающий проект».
Я знаю, что есть международные стандарты и наши ГОСТы по составлению документации на разработку проектов. Эти документы невозможно читать неподготовленному человеку, их готовят месяцами, и они создаются только ради соответствия этим требованиям, но не для облегчения труда Разработчика. Эта работа в разы дороже той, которую предлагаю в Агентстве я.
Я упоминал еще один вид документа — Бриф. Этот документ в большинстве случаев является кратким лирическим описанием Проектных требований. Там нет сложных конструкций, это скорее развернутая расшифровка того, что хочет клиент с точки зрения Исполнителя, и этот бриф очень легко обсуждать с Заказчиком, но потом обсудить решение с Разработчиком будет так же сложно, как и без него.
Одна из функциональных реформ моего Агентства в 2018 году — составление проектных требований на проекты в комплексе, и на локальные микрозадачи по разработке или поддержке. Подобные документы мы сначала обкатаем на нескольких проектах, а в дальнейшем распространим как стандарт по всем нашим проектам на всех фазах.
Составление Проектных требований — трудоемкая работа менеджера проекта со стороны Заказчика или со стороны Исполнителя. В нашем случае мы новаторы, потому составлять будем сами и обучать Клиентов, которым понравится подход. Так же Проектные требования решают одну из важнейших проблем всех проектов — проблему учета времени менеджера и тестировщиков, который работает на стороне Исполнителя.
Большинство Заказчиков оценивают работу только по трудозатратам непосредственного исполнителя задачи, но про сопровождение этой работы со стороны Менеджера в виде переговоров и постановке задач на исполнение все забывают и не желают оплачивать эту часть работы. Подрядчики решают эту проблему через повышение стоимости часа, в которую закладывают и время менеджера, и время других технических специалистов. Но повышать стоимость часа зачастую сложно для тех ниш, в которых Подрядчики работают. И тут начинается свистопляска с отбиванием стоимости тура менеджера так, чтобы казалось убедительным. Я против такого подхода, и я за чистый подход к раскадровке трудозатрат.
Мой подход помогает четко понять, чем занимается менеджер, почему он стоит не дешевле технического специалиста, и почему его работа важна на более высоком уровне, чем непосредственная разработка. Ошибки на уровне подготовки могут вылиться в серьезны ошибки разработки, а исправление может стать и вовсе невозможным.
Может возникнуть вопрос, почему этим занимается менеджер, а не Архитектор систем, или Тимлид, или Технический директор, или Аналитик? Ответ прост — они технари, а клиенты — не технари в большинстве случаев. Менеджер — единственное звено, которое осведомлено о проблемах Клиента, о проблемах разработки каких-либо решений, и он консультируется со всеми упомянутыми выше, чтобы составить Проектные требования.
Чтобы перейти к ТЗ от Проектных требований, мы макетируем интерфейсы и экраны. Очень грубо, так как это помогает технарям составлять ТЗ с наглядной картинкой перед глазами. Они вносят свои помарки в макеты, описывают сущности, а дизайнер дорабатывает макеты по мере поступления замечаний и составления ТЗ.
Вы все верно поняли, когда дело дойдет до ТЗ. Подключаются к работе технари, которые добавят к проектным требованиям то, без чего проект не может быть выполнен — информацию КАК сделать описанную систему. Такой документ можно считать полноценным руководством по запуску проекта или отдельных решений.
Вы можете задать еще один вопрос.
А если я хочу подешевле и без вот этого всего, но «как всегда» и «как у всех», но при этом хочу получить хороший продукт, что делать?
Все просто. Для этих случаев вам нужно всего 5 действий:
- Найти очень опытную команду;
- Предоставить им готовые Проектные требования, макеты и ТЗ;
- Сторговаться на тот ценник, который вы считаете адекватным за проект;
- Не мешать ребятам разрабатывать;
- Принимать проект согласно Проектных требований, макетов и ТЗ.
То есть, залог экономии в максимальном снижении затрат на подготовку со стороны Исполнителя и максимальном вовлечении вас в проект на нужных этапах. Нарушение любого из этих пунктов грозит повышением стоимости проекта, сроков и появлением непредвиденных рисков.
Пару лет назад я помогал Илья Жаркий с составлением ТЗ на работы. Я показал пример, сказал, сколько стоит составление ТЗ, а он не поверил в объективность стоимости. Но как профессионал — полностью вовлекся в составление ТЗ, предоставил его разработчикам.
За несколько итераций и торга ни у меня, ни у Ильи не осталось вопросов, почему Разработчик просит те деньги, которые были в КП. И, надо сказать, что цена была выше первых вариантов от Подрядчика, но оценка плавала и вызывала сомнения. Но с последним вариантом ТЗ и принятием коммерческого со стороны Ильи, он получил еще один примерно такой комментарий со стороны менеджера Исполнителя на вопрос о наличии вопросов по ТЗ:
- «Честно говоря, я еще никогда не видел такого качественного и подробного ТЗ. В нем все понятно и никаких сомнений не возникает».
Насколько я знаю, проект успешно завершился и бюджет не был превышен. Со стороны Исполнителя я так же слышал благодарность за хорошего клиента.
Буквально на днях приходит запрос на оценку разработки собственной системы email-рассылки на основе самописной CRM. Искушенные в разработке и в email-рассылках сразу понимают, что при любой адекватной стоимости часа разработчика, полноценным сервис будет только за месяцы или годы разработки с соответствующей командой и бюджетом.
Профессионал во мне задает вопрос, почему бы не интегрироваться с текущими рассыльщиками? Ведь это быстрее, дешевле, и во много раз лучше собственной разработки. Но суть бизнеса оказалась настолько узкой, что решение рассылать все через свой сервис оказывается единственным.
Второй этап — расшифровать 14 тезисов, которые представлены в запросе, чтобы разработчики могли оценить разработку и понять этапы запуска проекта. Это простые пункты, которые можно назвать от части названиями процессов, а отчасти размышлениями на тему. Это можно называть даже Брифом проекта, но весьма поверхностным. О Брифах выше отдельно.
Для проекта я быстро (2 часа) подготовил Проектные требования для оценки работ. И уже сутки идет обсуждение, функционала по Требованиям, а не по тезисам.
На этой позитивной ноте заканчиваю. Приглашаю к дискуссии в комментарии.
P.S. О стоимости часа мы поговорим как-нибудь отдельно, этот пост я уже несколько недель не могу дописать.