Как правильно писать техническое задание на разработку веб-сайта
Всем привет, мы веб-студия Mad Design — специализируемся на разработке веб-проектов. Около 75% наших клиентов, при обращении к нам, не предоставляют вообще никакого ТЗ на разработку веб-сайта, около 20% пишут как могут, и оставшиеся 5% приходят к нам с подробным ТЗ (спасибо вам большое!). Эта статья для тех, кто хочет самостоятельно написать ТЗ для разработки своего проекта! Лично мы в 99% случаев ТЗ разрабатываем бесплатно.
13K открытий
Давайте разберемся, как все-таки правильно писать техническое задание на разработку веб-сайта?
Есть 2 варианта:
1. Описать все очень подробно в свободной форме и отдать это подрядчику, подрядчик на основании этого составит для вас профессиональное ТЗ. Минус — за это нужно заплатить дополнительно.
2. Если средства ограничены, то можно попробовать это сделать самому, давайте разберемся пошагово как что и к чему?
Суть техзадания:
Ваша первоначальная задача донести до разработчика суть вашего проекта. Именно с этого должно начинаться любое техническое задание на разработку сайта.
Опишите в свободной форме свой проект, расскажите разработчику, что вы хотите получить от своего нового сайта (или доработки уже существующего) и каким его должен видеть посетитель.
Пример: «Будущий интернет-магазин кондиционеров будет служить основным инструментом для привлечения клиентов и увеличения продаж. От большинства конкурентов нас отличает наличие собственного сервисного центра и технический персонал прошедший обучение в Японии. Наш посетитель и потенциальный клиент должен с первого взгляда понять, что попал на сайт серьезной организации, однако серьезность не должна „давить“ — мы хотим произвести впечатление открытой компании с которой легко работать.».
Подобное описание даст разработчикам возможность прочувствовать что им предстоит сделать, а значит все дальнейшее описание будет восприниматься через призму этих ощущений и избавит от необходимости без видимых причин вдаваться в ненужные и путающие на начальном этапе подробности. Вышеописанное особенно актуально для дизайнеров.
Название, логотип, стиль и дизайн и их значение в техническом задании
Сообщите разработчику название вашего сайта, пришлите логотип и руководство по использованию фирменного стиля. Если логотипа и стиля нет, вполне возможно вам может помочь разработчик, или порекомендуют нужных специалистов. Как минимум, вы должны сообщить свои предпочтения по стилистике будущего проекта. Даже если у вас пока нет четкой определенности — вы сэкономите массу времени и себе и разработчику просто в свободной форме изложив свои соображения о том, как должен выглядеть ваш сайт.
Например: «Мы видим наш сайт в светлых тонах, без лишних деталей, возможно использование оранжевого цвета для выделения заголовков и других акцентов. Ссылки, кнопки, навигация — на усмотрение дизайнера.»
Постарайтесь объяснить разработчику в каких аспектах вы хотите точного выполнения описанного, а в каких даете творческую свободу. Это необходимо для того, что бы исполнитель знал, как вы отреагируете на то или иное решение. Будьте готовы, что не все из того что вы хотите получить при написании ТЗ в итоге будет гармонично выглядеть. В этом нет ничего страшного и опытный разработчик, как правило, еще на этапе согласования ТЗ или первых эскизов укажет на ошибку и предложит пути ее решения.
В идеале вам нужно достаточно подробно описать ваше виденье будущего дизайна, так же привести в техническом задании список сайтов (желательно, но не обязательно) тематически близких к вашему. Снабдить список из 5-10 сайтов краткими описаниями, например:
- www.site1 — нравится цветовая гамма и подача товаров, размер шрифтов мелковат.
- www.site2 — отлично реализован «быстрый заказ», все остальное ужасно.
- www.site3 — основной конкурент, все хорошо, но на него похожим быть нельзя.
Не перегружайте дизайнера информацией, хороший дизайнер уже «видит» ваш проект, постарайтесь не менять свои пожелания, в противном случае есть вероятность запутаться самому и запутать дизайнера, это приведет к потере времени. Вышеописанный минимум даст разработчику возможность проявить свой творческий потенциал и задать вам интересующие его уточняющие вопросы.
Структура и основная функциональность сайта или интернет-магазина
Опишите предполагаемую структуру будущего ресурса. Структура один из самых информативных и важных разделов в будущем техническом задании на разработку сайта или интернет магазина. Структуру проще всего описывать в древовидной форме, кроме того это достаточно наглядно и даст техническому специалисту основную информацию о предстоящей работе. Например:
1.1. Руководство 1.2. Вакансии
2. Каталог товаров
2.1. Микроволновые печи
2.1.1. Panasonic 2.1.2. Samsung 2.1.3. Daewoo
2.2.1.1.1. Проточный водонагреватель Bosh BX5L 2.2.1.1.2. Проточный водонагреватель Bosh BX10L 2.2.1.1.3. .
2.2.3. Газовые проточные
3.1. Схема проезда
Схематическая структура:
При наличии задач, разделов или функциональных элементов которые нельзя структурно описать в виде дерева, можно нарисовать схему (главное не перестарайтесь как в примере выше) или дать пояснения, например:
- У пользователя должна быть возможность заказать товар, как из списка товаров, так и из карточки товара.
- У пользователя должна быть возможность перейти в «корзину заказов» с любой страницы сайта.
- На страницах каталога, в разделе «пылесосы», а так же в карточках товаров под основным списком содержащим модели и характеристики должны отображаться мешки для пылесосов.
- Обязательно распишите все что нельзя увидеть на близких по тематике сайтах или может быть истолковано неоднозначно. Любые ваши идеи и ноу-хау — важны.
- Обозначьте примерный размер сайта в страницах, например — 10 обычных страниц с информацией и 990 страниц с описанием продукции в каталоге товаров.
- Не забудьте указать в техзадании и обсудить с разработчиком стратегию дальнейшего развития, продвижения и рекламы вашего проекта.
- Укажите, как именно вы хотите получить готовый проект, кто будет устанавливать его на хостинг и осуществлять дальнейшую техническую поддержку.
- Продумайте нужна ли на сайте регистрация для посетителей? Зачем она нужна вам, а чем она будет полезна посетителю.
- Ваш будущий интернет-магазин в перспективе будет доставлять товары почтой в любой уголок мира? Не забудьте предупредить об этом.
- Договоритесь, кто будет писать и подготавливать к публикации текстовое наполнение сайта, кто будет заполнять сайт.
Сроки и стоимость
Указывать или нет вилку цен, в которой вы готовы работать с выбранным исполнителем — ваше дело, не указав ее в техзадании вы можете выиграть в том случае, если разработчик назовет стоимость ниже, но рискуете недополучить то, что разработчик готов предложить за те деньги которые вы в действительности готовы заплатить. Указав примерную стоимость — даете разработчику возможность сразу не гадая предлагать вам решения в указанных ценовых рамках, экономя время обеих сторон. Кроме того, указание вилки цены не отменяет необходимость разработчика обосновать ту сумму которую он просит за свою работу.
Со сроками все еще проще — вы знаете, когда вы хотите получить проект и когда он будет по-настоящему необходим. Сообщите разработчику, что он вас очень обрадует сдав проект через 6 недель, но через 8 недель у вас «выставка» и к этому сроку проект должен быть готов обязательно.
Ваши контакты
Высылая или другим способом передавая разработчику техническое задание на разработку сайта не забудьте указать ваши контактные данные (как минимум имя, телефон, email) и удобное время связи. Это может выиграть время как при первоначальном ответе разработчика, так и во время дальнейших обсуждений деталей.
Надеемся, что данным руководством по созданию предварительного технического задания мы не только поможем вам без лишних затрат времени и сил объяснить исполнителю суть и цели будущего проекта, но и на шаг приблизим к успешной реализации вашей задумки.
Если все же у вас планируется технически сложный проект, в этом случае рекомендуем вам все же потратиться и заказать разработку технического задания у исполнителя вашего проекта.
Команда веб-студии Mad Design благодарит вас за внимание и желает всем успехов и хорошего настроения!)
60 комментариев
Написать комментарий.
Заказчик не должен делать тз, не его работа.
И дополнительно платить не должен.
Вы ему сайт делаете нормальный или херню по его желанию? Тогда вы фиговая фирма. Человек может не смыслить ничего. Ваша задача объяснить, как нужно сделать, а потом выполнить отличный проект.
А инфо по сайту на этапе проектирования и анализа конкурентов собирается, это обычная практика.
Развернуть ветку
Вы же понимаете, что бесплатной работы не бывает? Любой относительно большой бизнес или пишет ТЗ сам, или платит за него. То, что студия должна бесплатно написать ТЗ — это забавно, ибо за эту работу все равно кто-то заплатит, пусть и неявно.
Развернуть ветку
1 комментарий
Андрей, доля правды есть, но судя по вашему ответу бригада, которя делает ремонт должна делать дизайн-проект квартиры?
Развернуть ветку
15 комментариев
Заказчик не должен делать тз, не его работа.
И дополнительно платить не должен.
Это феерическая чушь, Андрей.
Техническое задание, помимо того, что в своём классическом виде — 990 страниц текста — уже мертво, это ключевая часть процесса разработки.
Если клиент не знает, чего хочет, то итоговый результат контролировать не реально, и всё это может закончится, в лучшем случае, сорванными сроками, а в худшем — судом.
Любая работа должна быть оплачена, предоплачена и закрыта актом.
И составление ТЗ — а лучше называть это «агрегацией требований» — это такая же работа.
Развернуть ветку
10 комментариев
В России если не объяснишь подробно, то херню сделают
Развернуть ветку
7 комментариев
«Ваша задача объяснить, как нужно сделать, а потом выполнить отличный проект.»
Ну вон, Лебедев так работает со своими джипегами за 100к, вообще не слушая заказчика, а только убеждая всех (возможно, даже себя) что они выходят ох*енные. Скажем так, результаты весьма неоднозначные.
Развернуть ветку
7 комментариев
Не соглашусь.
Мы берем за проектирование деньги, это составляет около 15% от бюджета на разработку. Сюда входит аналитика, написание тз, прототипирование, дизайн концепция.
Если называть «ТЗ» то, что обычно дает заказчик, то да, это не стоит таких денег. Но и пользы от такого документа нет )
Развернуть ветку
ТЗ уже прошлый век. У меня опыт ведения проектов с трудозатратам в тысячи часов. Под конец большого проекта, сам проект уже не напоминал первоначальное ТЗ. Куча дополнительных документов, уточнений и изменений в проекте. В свете современных технологий удобнее и нагляднее это прототипы, например, в Axure. Клиент видит как ведёт себя интерфейс, можно покликать. А ТЗ выкиньте, старое это все.
Развернуть ветку
На деле все просто: ТЗ — результат интеллектуального труда, весьма определенный и конечный. Клиент может взять написанное ТЗ и идти по студиям — поэтому эти результаты, как правило, оплачиваются.
Можно написать небольшое ТЗ бесплатно, или написать большое — и не оплачивать его, если с авторами заключается контракт, но тем не менее.
Логичное и емкое обоснование того, что ТЗ также стоит денег, как и любая работа.
Развернуть ветку
Все верно. Такое часто бывает. ТЗ только после оплаты.
Развернуть ветку
«10 обычных страниц с информацией и 990 страниц с описанием продукции в каталоге товаров.»
Что-то я раза 3 перечитал и не могу понять, 990 страниц что? Это в нормальной ситуации 10 страниц + один шаблон страницы товара. Хотя, наверное можно с заказчика брать как за отдельные ��
Развернуть ветку
Это очень абстрактно, пример 10 уникальных страниц и 1000 единиц товара = 1000 внутренних типовых страниц, это имеется ввиду
Развернуть ветку
Мы всегда идем на встречу и простые ТЗ разрабатываем бесплатно. Но есть технически сложные проекты, которые требуют очень тщательной прораьотки функционала. Стоимость разработки одного ТЗ может быть от 2000 до 40000, в данном случае оплатить работу — это нормальная практика
Развернуть ветку
Практически всё предложенное ТЗ сосредоточено на функциональных требованиях и выглядит «заточенным» под интересы разработчика.
Иерархическая структура, логотип и цветовая гамма, продвижение и реклама — то, что мы умеем и любим при натягивании сайта на готовые шаблоны и CMS. А вот что мы не любим (и часто не умеем) — это бизнес-требования, особенно нефункциональные.
Для сайта важнейшей является нефункциональная сторона. И если заказчик не сформулирует свои бизнес-требования к характеристикам качества, то может жестоко за это поплатиться.
Производительность — ожидаемая скорость загрузки и отрисовки страниц, ожидаемое количество посетителей среднее и пиковое.
Надёжность — процент отказов, способы восстановления при сбоях, допустимый процент времени вынужденных простоев, а также какими средствами надёжность будет контролироваться.
Защищённость — как будут защищены данные пользователей и заказчика на разных этапах их обработки.
Ну и далее по списку, например, стандарта ISO 25010.
Очень актуальная на сегодняший день тема — соответствие законодательству. В первую очередь, поддержка требований закона о персональных данных и GDPR. Если на сайте что-то продаётся, то ещё и способы реализации 54-ФЗ.
Отдельно нужно сказать о юзабилити, которое в зависимости от назначения сайта, может быть важнейшим конкурентным преимуществом (или, наоборот, причиной провала). Если оно важно, то в ТЗ должно быть расписано, в каких сценариях ему нужно уделять особое внимание, какие показатели предполагается использовать для его оценки, и как они будут проверяться.
Разработчику, понятно, фиксация таких нефункциональных требований обычно не очень выгодна, потому что может в разы увеличить стоимость разработки и сопровождения.
Развернуть ветку
Все в кучу свалили.
1.Заказчик приходит с запросам сделать сайт, в идеальном мире каждый занимается своим делом заказчик вообще не должен ничего понимать в сайтах.
2.Включается pre-sale. Вы направляете ему ему бриф, где с помощью отточенных вопросов собираете с заказчика информацию о концепции
3. Pre-sale агрегирует данные, на основании этого составляет карту функциональных и нефункциональных требований к продукту, делает первоначальную грубую оценку стоимости (обычно вилкой) и сроков. Апрувит с заказчиком данные параметры, если все хорошо делаем точную оценку
4. Pre-sale / sale делает точную оценку проекта, составляет красивое КП с разбивкой по этапам (проектирование и дизайн, разработка, интеграции, внедрение), описывает работы в рамках этапа, возможно узнает у разработки загруженность, и информирует клиента о том когда готовы приступить. Апрувит это все у заказчика, если все круто, получаем предоплату и переходим к аккаунту.
5. Аккаунт принимает клиента, дополнительно апрувит функциональные требования, передает коллегам для разработки высокуровнего и низкоуровнего технического задания на сайт и на интеграции, параллельно дизайнеры брифуют клиента.
6. И дальше в разработку.
Естественно в больших проектах сначала так делает mvp, все остальные фичи уже просто приложения к спеке,. с описанием функционала, структур данных, апи и тд если все это есть.
Развернуть ветку
Довольно спорная статья в которой описан устаревший подход.
Из своего опыта могу сказать, что этап проектирования сайта всегда должен быть платным и за него нельзя брать меньше 50 000 руб (даже за лендинг) За крупный проект от 100-150к. Хотя бы для того, чтобы обезопасить себя от времени, потраченного на обсуждение проекта и составление сметы.
Кроме того, на этапе проектирования надо сделать структуру сайта в Mind Map и сделать прототип будущего сайта. Без этого невозможно поставить ТЗ на дизайн и дальнейшие этапы работы.
А сроки лучше всегда говорить финальные после завершения этапа «проектирование», а до этого обсуждать только вилку «от ххх и до ххх».
И за любую работу надо платить)
Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?
В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается «как получится». Как сказал Генри Шоу «Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи».
О чем эта статья?
- В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
- Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.
Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?» Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
- Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
- IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
- Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
- Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
- Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
- Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
- Возможны и другие, реже встречающиеся варианты;
Думаю, сейчас у читателя должны возникнуть вопросы:
- А почему нельзя разрабатывать Техническое задание всегда одинаково?
- Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
- Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
- Как понять, хорошо составлено Техническое задание или нет?
- За чей счет должно оно разрабатываться, да и нужно ли оно вообще?
Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).
Как ни странно, проблемы у всех одинаковые! У всех бывают как успешные документы (и проекты), так и совсем бестолковые (исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия). Почему так получается? Именно потому, что цели у проектов бывают разные, как и пользователи этих документов. И, конечно, компетенции непосредственных специалистов не на последнем месте. В этих двух статьях я попытаюсь поделиться своим личным опытом, накопленном за многие годы. Конечно, получится в сжатом виде, т.к. вопрос достоин целой книги (кстати, идея, а может написать?)…
Что такое техническое задание?
Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».
Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.
Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».
Если кому-то интересно, о каких ГОСТах я говорю, то вот они:
- ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
- ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
- ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Куда более удачное определение представлено в википедии (правда про ТЗ в целом, а не только для программного обеспечения ): «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.)»
Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ. А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках! И это так. Конечно, есть много отличных (!) трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…
И так, как следует из определения, основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе.
Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.
Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:
- Требования в функциональности;
- Требования к безопасности и правам доступа;
- Требования к квалификации персонала;
- …. И т.д. Вы можете прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).
Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания.
Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:
- Требование должно быть понятным;
- Требование должно быть конкретным;
- Требование должно быть тестируемым;
Причем последнее свойство невозможно без двух предыдущих, т.е. является этакой «лакмусовой бумажкой». Если результат выполнения требования невозможно протестировать, значит, оно либо не понятное, либо не конкретное. Подумайте об этом. Именно во владении этими тремя свойствами требований и заключается мастерство и профессионализм. На само деле все очень просто. Когда разберешься.
На этом повествование о том, что такое Техническое задание можно было бы завершить и перейти к главному: как формулировать требования. Но не так все быстро. Есть еще один крайне важный момент:
- на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
- Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
- А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?
В ответах на эти вопросы кроется очень коварная вещь. Именно поэтому часто возникают споры о достаточности или отсутствии необходимой детализации требований, о понятности документа Заказчиком и Исполнителями, об избыточности, формате представления и т.д. А где вообще граница между Техническим заданием и Техническим проектом?
Техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для Заказчика языке. При этом может и должна использоваться отраслевая терминология, понятная Заказчику. Никаких привязок к особенностям технической реализации быть не должно. Т.е. на этапе ТЗ в принципе не важно, на какой платформе будут реализовываться эти требования. Хотя есть исключения. Если речь идет о внедрении системы на основе уже существующего программного продукта, то такая привязка может иметь место, но только на уровне экранных форм, форм отчетов и пр. Выяснением и формулированием требований, а также разработкой Технического задания должен заниматься бизнес-аналитик. И уж никак не программист (если только он не совмещает в себе эти роли, такое случается). Т.е. этот человек должен говорить с Заказчиком на языке его бизнеса.
Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуютсятехническим специалистам. Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально). А точнее группа специалистов во главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.
Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо. Вот и мне знакомо, пришлось набить шишек в свое время.
Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени — это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.
Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.
Управленческий учет: с нуля до настройки в 1С, Excel и Google-таблицах
Хотите понимать, откуда приходят и куда уходят деньги компании? Мы составили программу курса повышения квалификации «Управленческий учет» , чтобы каждый бухгалтер научился видеть бизнес-процессы. А еще — сделали возможность выбора удобного графика и доступную стоимость обучения.
Смотрите программу и записывайтесь!
А нужно ли вообще техническое задание? А Технический проект?
Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.
А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.
Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.
Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»
Формулирование требований к информационной системе. Структура Технического задания
Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, т.е. предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса – помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть, считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.
Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).
Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.
И так, ГОСТ рекомендует следующие разделы:
- общие сведения;
- назначение и цели создания (развития) системы;
- характеристика объектов автоматизации;
- требования к системе;
- состав и содержание работ по созданию системы;
- порядок контроля и приемки системы;
- требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
- требования к документированию;
- источники разработки.
Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.
Раздел 1. общие сведения.
Рекомендации по ГОСТ
Что с этим делать на практике
полное наименование системы и ее условное обозначение;
Разработка без ТЗ
Техническое задание штука сложная и долгая. Написание ТЗ многих вгоняет в уныние. А чтение ТЗ некоторых доводит до трясучки. Так же и в нашей компании. После месяцев страданий и обвинений друг-друга во всех мыслимых и не очень проблемах родился подход. Спустя время подход доказал свою пользу и теперь им не стыдно делиться.
Мы применяем этот подход для мобильных приложений. Но он может легко подойти к разработке веб или десктоп приложений.
Документация
Вся разработка ведётся через документацию.
Мы используем confluence, но с тем же успехом может использоваться любая вики-система. Из необходимого в этой системе должна быть версионность, возможность форматировать текст и вставлять изображения. Остальное скорее про удобство.
Перед созданием какого-либо функционала заводится раздел в конфлюенсе.
В иерархической структуре это выглядит так:
- Наше приложение
- Раздел приложения 1
- Раздел приложения 2
- Раздел приложения N
- Функционал 1
- Функционал N
- Новый функционал
И состоит из нескольких обязательных элементов:
- Страница общего описания функционала
- Сценарии пользователя
- Схема взаимодействия экранов
- Описание экрана
Страница общего описания функционала
На этой странице описывается назначение нового фукнционала. Описывается для чего он нужен и что делает. Уже в дочерних вкладках заводится страница для пользовательских сценариев, отображения схемы взаимодействия экранов, описания экранов, и частных случаев, если они меняют свой вид при взаимодействии.
Иерархически выглядит так:
- Пользовательские сценарии
- Сценарий 1
- Сценарий 2
- Сценарий N
- Экран 1
- Экран 2
- Экран N
- Частный случай экрана
Сценарий пользователя
- Предусловие — по пунктам указывается всё то что необходимо для совершения сценария. Например быть уже авторизованным в приложении, или иметь выше определенной суммы на балансе. Допускается указывать в предусловии другой пользовательский сценарий.
- Сам сценарий — по пунктам указываются шаги пользователя начиная с первого экрана предполагаемого сценария. Один пункт — один шаг. Обычно пункт имеет вид: «Нажимаю на это, получаю такой-то результат».
Оплата некоего сервиса.
Предусловие:
- Пользователь уже залогинен в приложении.
- На балансе более 10 000 денег.
Сценарий:
- На главном экране нажимаю ячейку сервиса. Открывается экран ввода реквизита, фокус на поле ввода.
- Ввожу реквизит, нажимаю кнопку «Далее». Открывается экран ввода суммы.
- Ввожу сумму до 10 000 денег, нажимаю кнопку «Далее». Открывается экран подтверждения платежа.
- Вижу название сервиса, реквизит и сумму. Нажимаю кнопку «Оплатить». Открывается экран с чеком.
Схема взаимодейтсвия экранов
Нужна для наглядности и понимания общей картины функционала.
Для изображения схемы взаимодействия экранов у нас используется draw.io (его модуль для confluence). Внешний вид прост и довольно свободен. Есть только общие рекомендации по виду элеметов.
На данный момент у нас применяется два вида:
- Блочный — когда каждый экран это прямоугольник, стрелками показывается с какого экрана на какой возможен переход. Иногда встречаются условия, для них мы используем ромб.
- Блочный расширенный — когда на каждом экране схематично изображены элементы взаимодействия, и уже от них исходят стрелки к следующим экранам.
У каждого из этих двух видов есть небольшие приемущества и недостатки друг перед другом, например расширенный бывает более нагляден, но немного тяжелее в поддержании. На стадии активных обсуждений расширенный удобнее, а когда функционал уже готов и по нему нужно быстро поулчить справочную информацию то простой блочный читается легче и быстрее.
Каждый блок содержит в себе название экрана которое в свою очередь является ссылкой на страницу описания. Достаточно пробежать по схеме глазами, увидеть необходимый экран, нажать на него и получить страницу с подробным описанием.
Описание экрана
Пожалуй наиболее важный элемент. Так как именно определенный экран и действия на нём зачастую приводят к проблемам и распрям.
Имеет строгий определенный вид и набор компонентов.
Содержит в себе:
- Интерактивную схему экрана — все элементы взаимодействия кликабельные и ведут на страницу того экрана, который пользователь увидит в итоге нажатия.
- Изображение экрана — необходим для отображения реального вида экрана (опционально, если используется дизайн-система). Так же может быть ссылка, если используется Фигма.
- Список всех элементов на экране и их описание — названия элементов являются ссылками, ведущими на подробное описание использованного компонента а в пояснении указываются уточняющие детали для конктетного экрана.
- Описание дополнительной логики — если что-то не относится напрямую к какому-то элементу, или задействует несколько.
- Таблицу локализации — в первой колонке указываются названия полей. Остальными колонками идут поддерживаемые языки.
Работа над страницей описания итеративная и делается разными людьми в разное время. Часто начинает описывать аналитик, его дополняет дизайнер, может дополнить менеджер. После них разработчик дополняет техническими деталями, например указывается из каких полей подставляются значения, либо какой запрос делается при нажатии на кнопку. Если технических деталей много, создается вложенная страница описания. На этой странице описываются роуты, поля, и логика. Тестировщик может дополнить упущенные детали, которые всплыли во время тестов.
При нобходимости добавляются другие страницы, на которых описываются какие-либо аспекты присущие конкретному функционалу. Все страницы обильно снабжаются ссылками на общие элементы и связнные страницы.
Применение
Описание, это лишь часть работы над функционалом. Общий процесс может выглядеть примерно так:
Имея описание, довольно легко разделить его на задачи и оформить в таск-трекере. Зачастую раздел это эпик, фукнционал это юзерстори а экраны это задачи. Внутри задач создаются подзадачи на отдельные аспекты реализации.
При заведении тикетов у нас есть шаблон оформления, он довольно прост и включает в себя пункты:
- Мотивация — краткое описание для чего делается данный функционал.
- Путь решения — сама задача что надо сделать.
- Критерии приемки — обычно это ссылка на описанные пользовательские сценарии.
- Ссылка на документацию — где должен быть описан общий функционал (собственно то что описано в предыдущих пунктах).
- Дизайн — опциональный пункт.
- Дополнительное описание в свободной форме.
Небольшое послесловие
Что-то из написанного может показаться излишним. Некоторое спорным. Но всё из написанного было реально попробовано в нашей команде стремительно разросшейся от «команды одной пиццы» до отдела. Принесло порядок, вскрыло недостатки и точно повысило качество приложений.
Спасибо всем прочитавшим.
- техническое задание
- документация проекта
Что такое техническое задание. Объясняем простыми словами
Техническое задание (техзадание, или ТЗ) — документ, содержащий перечень задач, обязанностей и требований, которые заказчик предъявляет исполнителю.
Проще говоря, это подробное руководство к действию, в котором всё документально зафиксировано. Оно позволяет заказчику понять, что именно ему нужно, и требовать от исполнителя соответствия продукта или услуги всем пунктам, а исполнителю — вникнуть в суть задачи, спланировать выполнение проекта или отказаться от работ.
Техзадание имеет статус юридического документа и включается как приложение в договор.
Пример употребления на «Секрете»
«Из техзадания следует, что 500 квадрокоптеров должны в течение 420 секунд выполнить не менее шести «фигур анимации» над мурманской площадью «Пять Углов». Исполнитель должен полностью подготовить шоу и провести одну генеральную репетицию 1 октября. Само праздничное представление должно состояться 3 октября в тёмное время суток».
(Из новости о том, что в Мурманске на День города покажут шоу дронов за 6,5 млн рублей.)
Нюансы
Техническое задание должно включать следующие разделы:
- Описание проекта — что из себя представляет, какие задачи будут поставлены перед исполнителем.
- Цели проекта — для чего он был создан и какого результата ожидает заказчик.
- Требования, в соответствии с которыми исполнитель реализует проект.
- Порядок контроля и приёмки — стандарты, по которым заказчик будет оценивать качество полученного результата.
- Приложения — дополнительные элементы, которые необходимо учесть при реализации технического задания.
- Стоимость — как правило, цена работ прописывается в отдельном приложении к основному договору, но в некоторых случаях её указывают прямо в ТЗ.
Техническое задание можно составить в произвольном порядке. Однако органы государственной власти или крупные госкомпании требуют ТЗ, выполненное строго по ГОСТам. Например, техзадания к сайтам, приложениям и системам автоматизации пишутся по двум ГОСТам: ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».
Все изменения, дополнения и уточнения в ТЗ должны быть согласованы с заказчиком и утверждены им. Это необходимо в том числе и для определения степени ответственности каждой из сторон, если в работе обнаружатся ошибки и неточности.