Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Работаем над ошибками
В недалеком прошлом на этом замечательном ресурсе была опубликована статья Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Статья — сама по себе неплохая — содержит, к сожалению, ряд неточностей, о которых следует упомянуть. Сделаем это в «один проход» по абзацам. По второму абзацу:Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет.Уточнения:
- Технические задания не пишут (составляют, подготавливают, оформляют и пр.), а разрабатывают, см. хотя бы п. 1.2 ГОСТ 34.602-89;
- Если заказчик и исполнитель руководствуются требованиями ГОСТов, то совершенно противоположных мнений у них в принципе быть не может и не должно. Если же взаимодействие осуществляется «по понятиям» — как сейчас принято — то без «плюрализЬма мнений» тут, конечно, никак не обойтись.
Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения.Палка о трех концах:
- Чрезмерно детализированное техзадание становится техническим проектом, что, в общем-то, и неплохо, но кто даст исполнителю столько времени и денег на разработку излишне подробного ТЗ?
- Вменяемый исполнитель всегда стремится сократить объем технического задания, поскольку «меньше слов — меньше вопросов». И меньше работы. Более того, на стадии технического задания очень трудно предугадать технический облик изделия, программы или автоматизированной системы в целом, поэтому существует типовая отмазка «то-то и то-то должно уточняться на стадии технического проекта»;
- Исполнитель не должен забывать, что он несет обязательства не только в части реализации функциональных требований, но и общих требований — требований к надежности, безопасности и т.д. Нет смысла перечислять, поскольку их довольно много и все они подробно изложены в том же ГОСТ 34.602-89.
При этом заказчик, который точно не определился с параметрами будущей системы или у которого «ветер в голове», может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования.А вот тут уже все зависит от опыта исполнителя. Толковый исполнитель обязательно пропишет в договоре или ТЗ условие, при котором все дополнительные «хотелки» заказчика должны будут финансироваться отдельно с соответствующим увеличением срока разработки (дополнениями к ТЗ, допсоглашениями и т.п.). При этом очень важно — крайне важно! — не доверять всецело подготовку договора юристам, обязательно выверять все вплоть до каждой запятой, безжалостно уничтожать в документах любую юридическую казуистику, приводить документы к виду стройному, строгому и прозрачному. По третьему абзацу:
По сути правильно, только это будет не ТЗ, а нечто вроде оперативно-технической записки, ТТЗ, заявки, письма с хотелками — общими функциональными требованиями. Теперь о неточностях: нельзя смешивать понятия модулей и подсистем, поскольку подсистема — это та же система, только маленькая. Подсистема, как и система, включает в себя все виды обеспечения, все те же общие требования, а модуль есть всего лишь «Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения с другими программными модулями и загрузки в оперативную память [из п. 15 Таблицы 1 ГОСТ 19781-90]»Как уже говорилось выше, в момент начала работы над ТЗ вы можете слабо себе представлять… В качестве исходных данных у вас могут быть разрозненные, часто противоречащие друг другу запросы… Хорошо, если вашей ИТ-службе удалось… Если же нет, то лучший вариант – это сначала разработать очень общее ТЗ, крупными мазками описывающее видение системы, перечислить необходимые модули (подсистемы), не углубляясь в подробности их функционирования, и далее совместно с исполнителем работать над детализацией требований к ним.
Это даст вам время лучше понять что же вы хотите получить в итоге, мобилизовать на работу над проектом подразделения компании, собрать необходимую информацию, освоить основные понятия, если тематика создаваемого решения для вас нова. Также исполнитель сможет лучше познакомиться с деятельностью вашей компании.Что касается «основных понятий», то существует громадное количество ГОСТов, содержащих в своих названиях строчку «… Термины и определения». Их и следует применять в работе, чтобы быстрее освоить новую предметную область, но ни в коем случае не ссылаться на всяческие «… педии», поскольку это не только несолидно, но еще и «чревато боком» в части последствий. По четвертому абзацу:
Немаловажным моментом является вероятность дрейфа требований… Во избежании ненужных проблем в будущем это сразу надо проговорить с исполнителем и настраиваться на долгосрочное сотрудничество. Грамотный исполнитель в этих условиях может выбрать т.н. спиральную модель разработки ПО, в рамках которой ТЗ, фактически, разрабатывается на каждом новом витке спирали и описывает те изменения, которые должны произойти в следующей версии программного продукта.
Сложность задачи также оказывает влияние на подход к написанию ТЗ… Сложность обычно заключается в том, что… В этом случае очень важно грамотно разбить проект на этапы (шаги), подразумевая то, что каждый следующий шаг будет корректироваться по результатам, достигнутым на предыдущих. Соответственно и техническое задание будет разрабатываться в начале каждого этапа, опираясь на опыт предыдущего.Смешаны понятия этапов и очередей. Применительно к автоматизированным системам: Этап — Часть стадии создания АС, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей [из п. 4.4 ГОСТ 34.003-90] Очередь — Часть АС, для которой в техническом задании на создание АС в целом установлены отдельные сроки ввода и набор реализуемых функций [из п. 4.5 ГОСТ 34.003-90] По девятому абзацу:
Степень детальности ТЗ и разнесенность во времени его разработки, конечно же, не являются единственными моментами, важными для заказчика. Перед началом разработки ТЗ очень рекомендую определиться с его структурой, фактически, составить страницы с его содержанием, перечнем пунктов и подпунктов до начала работ по ТЗ, а не в процессе или после. При этом и вы и исполнитель договоритесь о том какие вопросы должны быть рассмотрены на данном этапе. Вы будете хорошо понимать, что получите в итоге, а исполнитель будет понимать, что вы от него ждете. Не смотря на кажущуюся простоту, это делается не всегда, даже для крупных и сложных проектов. В итоге ТЗ может получиться совершенно непотребным для дальнейшей работы.
… ТЗ в явном или неявном виде присутствует в любой из них. При этом шаблоны этого документа могут существенно различаться для различных компаний и процессов разработки ПО. Будущий разработчик вашей системы может навязывать вам принятые у него шаблоны ТЗ, но в данном случае важно понимать, что, во-первых, ТЗ является важнейшим инструментом не только для исполнителя, но и для заказчика, который также имеет полное право определять его структуру…Вот тут совсем непонятно: ведь заказывает музыку тот, кто платит, а платит заказчик. Как исполнитель может хоть что-то ему навязывать? Тут возможно лишь взаимное «согласие как продукт при полном непротивлении сторон»… По одиннадцатому абзацу:
В настоящее время в РФ действует ГОСТ 34.602-89 «Техническое задание на создание автоматизируемой системы», который, не смотря на 89-й год своего создания, неплохо отражает общую структуру ТЗ. Тем не менее, для многих случаев, он является недостаточно детальным и хорошо описывающим специфику разработки современных программных продуктов.Слезы потекли ручьем:
- Плохо или неплохо — судить не нам, поскольку все существующие зарубежные стандарты, включая MIL, даже близко к ГОСТ 34-й системы не стояли в части детализации и полноты охвата;
- ГОСТ 34.602 к программным продуктам вообще
Категории (роли) пользователей, работающих с системой – перечислить роли и кратко описать каким должностям из каких подразделений они соответствуют.Все это не предусмотрено как ГОСТ 19.201, так и ГОСТ 34.602, но имеется подраздел «Требования к численности и квалификации персонала системы и режиму его работы», который разумно добавить в ТЗ на ПО и детально расписать в нем категории персонала. И даже роли… А еще в ГОСТ 34.602 предусмотрены требования к организационному обеспечению — в них можно отлично развернуться и дать волю фантазии.Все, что перечислено ниже, детально расписано в РД 50-34.698-90. Если интересны подробности — задавайте вопросы в комментариях. По заключению:
В заключении хотелось бы отметить, что по моему опыту самое лучшее ТЗ – это ТЗ написанное самим заказчиком или при самом активном участии заказчика, т.к. никто лучше сотрудников вашей компании не знает ваших потребностей, деталей работы и далеко не всегда это удается выяснить на интервью. Конечно, для этого необходимо иметь в штате достаточно квалифицированных ИТ-специалистов или воспользоваться услугами ИТ-консультанта. Полученное ТЗ можно использовать в составе тендерной документации для того, чтобы дать большому количеству потенциальных подрядчиков четкое понимание требуемого результата и получить от них предложения.
- «Законодательно» ТЗ разрабатывается самим заказчиком только в том случае, если он представляет Министерство обороны или иное силовое ведомство;
- Тендерную документацию разрабатывает именно тот подрядчик, который заведомо должен выиграть конкурс. Простите, но это жизненные реалии…
Образец формы технического задания по 44-ФЗ в 2020 году
Техническое задание разрабатывается для корректного определения задач заказчика и достижения конкретных результатов, ожидаемых организацией-заказчиком от закупки. Ответственность за формирование ТЗ несет контрактная служба (контрактный управляющий). Благодаря описательному приложению к информационной карте, организация-заказчик устанавливает четкие требования к приобретаемым товарам, работам, услугам и объективные критерии для участников торгов, исключая возможность злоупотреблений со стороны участника-победителя.
Если в закупочной документации отсутствует техническое задание, но при этом в проекте контракта и извещении подробно указана вся необходимая информация, то это не является нарушением действующего законодательства.
Основные требования к техническому заданию
Требования к техническому заданию по 44-ФЗ, формальный вид и содержательная часть документа не регламентируются действующим законодательством. Однако ст. 33 44-ФЗ предъявляет строгие правила к описанию объекта заказа и устанавливает порядок его формирования. Согласно ст. 33, к описанию закупаемого объекта устанавливаются единые требования, которым заказчик обязан следовать неукоснительно в процессе разработки техдокументации торгов.
Пример технического задания по 44-ФЗ, образец которого можно скачать ниже, продемонстрирует определенные правила, действующие в отношении описания объекта закупки:
- Описание предмета заказа должно быть составлено объективно. В ОЗ допускается включение технико-функциональных, качественных и эксплуатационных особенностей приобретаемых ТРУ.
- Разрабатывая описание ОЗ, работник контрактной службы заказчика имеет право использовать только ту терминологию, которая предусмотрена регламентом, закрепленным действующим законодательством.
- В описании ОЗ допускается использование чертежей, фотографий, эскизов, результатов тестовых испытаний и подобных сведений.
- Если в ТЗ определяется условие о предоставлении исполнителем образца приобретаемой продукции, то в закупочной документации необходимо обозначить время и место осмотра товарного образца.
- В том случае, если ОЗ — лекарственные препараты, то заказчику необходимо указывать непатентованные наименования, признанные во всем мире. Если такие наименования отсутствуют, то вносятся химические или группировочные наименования ЛП.
Техзадание должно быть составлено максимально нейтральным образом, чтобы не ограничивать возможность потенциального участия поставщиков в торгах путем установления чрезмерных характеристик и условий заказа ТРУ.
Запрещено в описании объекта закупки указывать конкретные показатели: товарные знаки, фирменные наименования, сведения о производителе и проч. Если включение подобной информации является необходимостью, то в описании предмета заказа необходимо написать «или эквивалент» для поддержания здоровой конкуренции между участниками.
Организации-заказчику запрещается предъявлять к ТРУ и информации о них такие требования, которые приводят к ограничению количества участников торгов, за исключением тех ситуаций, когда не имеется другого способа, обеспечивающего более точное и четкое описание характеристик ОЗ (п. 1 ч. 1 ст. 33 44-ФЗ).
Образец технического задания по ГОСТу может быть использован не во всех случаях, то есть заказчику не обязательно при каждой закупке руководствоваться ГОСТом, стандартами или иными регламентами (п. 2 ч. 1 ст. 33 44-ФЗ). Организации-заказчику необходимо обосновать использование в описании ОЗ других показателей, требований, условных обозначений и терминологии только в случае, если законодательством установлены такие регламенты и стандарты.
При отсутствии ГОСТов и регламентов на товары, работы, услуги, для которых существует функционирующий рынок, заказчик вправе разработать описание на основании сведений производителей и иных качественных показателей, которые необходимы для конкретного предмета заказа (Письмо Минэкономразвития России № ОГ-Д28-9745 от 03.08.2016).
В том случае, если ГОСТ необязательный, но он указан в ТЗ тендера, он становится обязательным для обеих сторон контракта.
Далее представим образец формы технического задания по 44-ФЗ.
Скачать
Как составить техническое задание
Нормативными источниками для формирования ТЗ могут выступать:
- отраслевые нормативы;
- технико-технологические условия;
- госстандарты;
- методические разработки министерств и ведомств.
Дополнительными источниками информации могут выступать данные из ранее заключенных контрактов, из общедоступных источников, коммерческие предложения иных предприятий.
Так как техническое задание (образец) по ФЗ-44, его формальная и содержательная части на законодательном уровне не утверждены, организация-заказчик может использовать самостоятельно разработанную форму, составленную по актуальным нормам и правилам.
Техническое задание — это часть закупочной документации. В него должны быть включены следующие параметры:
- Сведения об организации-заказчике. Его юридический и фактический адрес, координаты для связи, банковские реквизиты и коды по Общероссийскому классификатору.
- Сведения о заказе. В техническом задании надлежит указать полное наименование предмета торгов с указанием всех используемых терминов, способ проводимой закупки (ч. 1 ст. 24 44-ФЗ), обоснование способа определения поставщика (ч. 5 ст. 24), источник финансирования.
- Описание ОЗ.
- Требования к упаковке товара и безопасности объекта заказа.
- Сроки поставки ТРУ.
- Гарантийный срок.
- Условия по сервисному обслуживанию, монтажу, пусконаладочным работам, обучению сотрудников грамотной эксплуатации поставляемой продукции (при необходимости).
При разработке условно можно выделить три этапа.
На первом, подготовительном, этапе необходимо определить потребность в приобретаемых ТРУ, рассчитать и обосновать НМЦК, описать предмет заказа.
Второй этап — основной. Во время данного этапа организация-заказчик детерминирует основные качественные и количественные характеристики ТРУ, оговаривает условия и регламент поставки продукции, а также параметры заполнения первых частей заявок, проверяет заполненные параграфы ТЗ.
На заключительном этапе специалисты по закупкам организации-заказчика согласовывают, дорабатывают и утверждают ТЗ. После утверждения закупочная документация публикуется в ЕИС.
Рекомендации по составлению технического задания
Содержательная часть ТЗ напрямую зависит от объекта закупки и от конкретных потребностей организации-заказчика.
После изучения технического задания каждый участник торгов должен четко понимать значения показателей, необходимых заказчику. Такие данные он и должен отражать с своей заявке.
Предлагаем специалистам организаций-заказчиков свод базовых рекомендаций, которым можно следовать для подготовки корректного ТЗ.
- Техзадание должно быть тесно взаимосвязано с инструкцией по заполнению заявки.
- Все термины, которые включены в техническое задание, должны быть упорядочены, а инструкция по составлению заявок должна легко читаться и адекватно восприниматься потенциальным поставщиком. При этом судебная практика расценивает заявки, затрудняющие восприятие и не содержащие соответствие объекта закупки и инструкции по формированию заявок, как ограничивающие конкуренцию.
- Специалисту надлежит указывать, когда значение диапазонного показателя не должно изменяться. Диапазонные показатели должны быть максимально приближены к реальности. Заказчик может определить диапазонный показатель как набор из минимального и максимального значений, а участник заказа выбирает конкретное значение в указанных рамках. Либо же заказчик должен определить, что значение диапазонного показателя не может изменяться, а потенциальный поставщик указывает в заявке диапазон в неизменном виде. Ошибки при установлении диапазонных показателей сводятся к неправильному или недостаточно четкому выбору между указанными альтернативами. При этом вариант «по умолчанию» — это первый вариант, когда участнику закупки нужно указать в заявке конкретное значение показателя.
- Все альтернативные значения показателей должны быть реальными.
- По общему правилу не стоит устанавливать требование о соответствии техническим условиям, это также признается судами ограничением конкуренции.
- Если заказчик устанавливает требования к цветовым характеристикам товара, то они должны быть обоснованными и целесообразными.
- Запрещается устанавливать требования к участнику заказа и его ресурсам (ч. 3 ст. 33).
- Запрещается закупать ТРУ, которые не соблюдают законодательные требования к энергоэффективности. Это грозит заказчику штрафными санкциями. Если в заказе присутствует необходимость изображения или эскиза, то лучше его предоставить в составе ТЗ.
Главное, что должен помнить заказчик, — все показатели ТЗ должны позволить потенциальным поставщикам, участвующим в торгах, определить реальные потребности организации в определенных товарах, работах, услугах.
надо ли и как писать. Критика примера / Habr
При создании объекта есть два способа описать требования: «что должен уметь/делать объект» (описание цели) и «каким должен быть объект» (описание реализации). Прощу прощения если формулировка не точна, источника сией мысли я не знаю, формулирую сам. Далее речь пойдет о втором способе описания объекта — дизайна сайта.
Есть два вопроса: нужно ли формализованное ТЗ на дизайн и если да, как его следует писать? Мое мнение, что ТЗ необходимо, а как его писать… мне нравится приложенный пример. Предлагаю рассмотреть и покритиковать. Естественно, не суть, а скорее форму изложения и перечень рассмотренных вопросов.
Интересует мнение руководителей проектов, арт-директоров и дизайнеров.
Исходные материалы: логотип, визитка, буклет, примеры продукции компании, фотографии работ, текстовое наполнение (15 стр в doc).
Компания специализизируется на производстве рекламных, сувенирных и полиграфических материалов, штемпельной продукции.
Сайт создается с целями:
— информирования клиентов об услугах компании,
— продвижения бренда АА как успешного, надежного и развивающегося поставщика рекламных услуг,
— популяризация положительного имиджа компании,
— увеличение объемов продаж,
— привлечение новых заказчиков на услуги компании.
— выход на рынок сувернирной продукции.
Конкуренты
Основные:
— Конкурент 1
Достоинства: необычный, хотя и странный, коллаж в шапке, много различного контента, грамотного написанного.
Недостатки: стиль сайта не выдерживается на страницах, меню производит впечателение криво повешенного,
— Конкурент 2
Достоинства: обширное портфолио.
Недостатки: дизайн сайта крайне примитивен, как и навигация.
— Конкурент 3
Достоинства: яркая, хотя и не очень впечатляющая, графика. Много грамотно написанных текстов (встречаются ошибки).
Недостатки: каталог товаров и услуг не проиллюстрированы фотографиями и ценами. приходится качать файлы прайсов.
Дополнительно рассмотрены:
— Конкурент 4
Достоинства: достаточно интересный классический дизайн
Недостатки: внутренние страницы, в частности по сувенирке, не проработаны. масса странных ссылок и страшных фотографий
— Конкурент 5
Достоинства: нет.
Недостатки: скучный дизайн, примитивное оформление страниц
— Конкурент 6
Достоинства: удачный дизайн с применением флеш-элементов. Персонажики повсюду. Применены разумно. Много различного контента.
Недостатки: сайт не растягивается, что портит неплохой дизайн (половина экрана белая), внутри проблемы со структурой страниц.
— Конкурент 7
Достоинства: нетрадиционный дизайн во всем: структура, шрифты
Недостатки: шрифты трудночитаемы, фотографии размещены неудобно для скачивания, внутри стиль первой и вторых страниц не соблюдается.
— Конкурент 8
Достоинства: яркий и простой дизайн с применением флеш-анимации. Простая и понятная навигация.
Недостатки: шрифты страниц неконтрастны, плохо читаемы.
Хороший дизайн и концепцию испортили наполнением.
— Конкурент 9
Достоинства: проработанный дизайн, множество иллюстраций
Недостатки: внутри сайта нет фотографий, тексты смотрятся слепыми
— Конкурент 10
Достоинства: яркий дизайн, качественное наполнение, удачная флеш-анимация.
Недостатки: нет
— Конкурент 11
Достоинства: любовно и старательно наполнен
Недостатки: некоторые странные решения по дизайну и огрехи по наполнению
В целом очень достойно
— Конкурент 12
Достоинства: яркие страницы, простой и хорошо структурированный каталог.
Недостатки: глаза устают.
Сайт абсолютно классический, на твердую 4.
— Конкурент 13
Достоинства: флешка красивая.
Недостатки: крайне неприятная цветовая гамма, наполнение сделано странно.
Ключевые особенности компании, которые должны найти отражение в дизайне и структуре навигации сайта:
— собственное производство
— сеть филиалов и представительств
— доверие к фирме со стороны многочисленных клиентов и партнеров
Целевая аудитория — собственники и руководители организаций среднего и малого бизнеса, желающие получить качественное комплексное обслуживание в сфере рекламных услуг и продукции от печатей до интерьерного и фасадного дизайна. Молодые социально активные люди среднего достатка.
Пожелания к визуальному образу:
1. соответствие фирменной символике и стилистике
2. использование интересных решений в дизайне или навигации, не мешающей восприятию сайта как удобного инструмента получения информации
3. информативность, удобство, легкость
Слоган для использования на сайте:
главная ценность нашей компании — наши клиенты
Сайты, на стиль исполнения которых следует обратить внимание, т.к. они нравятся заказчику:
www.alfa-suvenir.ru
www.elenara.ru
www.tipograf.info
www.vremenagoda.biz
www.viveska.info
www.emotiondesign.ru
www.driada-pr.ru — не открылся
www.corporative.ru
www.credo-positive.ru
Образцами можно считать:
alfa-suvenir.ru — да
www.viveska.info — да, построение шапки, стиль оформления текстов и меню
www.vremenagoda.biz — да, структура страницы. можно использовать как образец при наличии исходных материалов для создания коллажей. создание иллюстраций не включается в разработку сайта
Пункты меню главной страницы:
О компании
Новости
Услуг
Портфолио
Контакты
Полезно знать (статьи о рекламе)
Заказать
Оплаченные модули и графические средства:
— статичный дизайн — да
— анимация — нет
— система текстовых страниц
— каталог услуг
— лента работ
— лента заказчиков
— лента новостей
— лента статей (полезно знать)
— форма заказа
На всех страницах — шапка, меню, логотип.
Первое предлагаемое решение по созданию дизайна сайта.
Сайт создается как растягивающийся на любую ширину страницы.
1. Стартовая и внутренние страницы имеют разную структуру. общие цвета: белый/кремовый, оранжевый, гамма синего, буквы черные.
2. Стартовая страница:
— содержит крупный логотип (до 25% высоты сайта) и в качестве шапки цветовую полосу (может быть неправильной формы) с блоками, иллюстрирующими направления деятельности (или конкретные работы) компании
— имеет структуру, собранную из информационных блоков: о компании, наши преимущества, что умеем, полезно знать, последние работы, наши услуги, новости, баннер перехода на форму, возможно еще что-то (скомпоновано по принципу www.ra-alterego.ru/?id=manufacture). Каждый блок построен по принипу вынесения главного или самого современного. Все блоки одного размера. В будущем возможно расширение и обновление сайта путем замены одного блока на другие.
2. Основные страницы (портфолио, клиенты, новости, услуги):
— логотип и шапка имеют меньшую высоту (10-15%), шапка содержит коллаж из работ или иллюстрацию (при наличии)
— имеют трехколоночное построение (лого, шапка, вертикальное меню, поле дополнительной иформации). В поле дополнительной информации выводятся небольшие блоки информации, которая может быть интересна при просмотре раздела (в новоястях-портфолио, в клиентах-услуги и т.п.) или блоки, аналогичные блокам на главной.
3. Внутренние и текстовые страницы имеют двухколоночное представление: шапка+меню+текст страницы.
4. Наобходимо придумать визуальное решение, позволяющее подчеркнуть широкий спектр оказываемый услуг и собственную производственную базу.
Второе предлагаемое решение по созданию дизайна сайта.
Идея решения заключается в использовании в дизайне в качестве рамки символов печати (штампа), сувенирной продукции, других примеров продукции компании. Сайт будет иметь фиксированную ширину. По периметру располагаются графические элементы, созданные на основе графики продукции компании (печати, буклеты, сувенирка).
По высоте сайт растягивается либо путем добавления белого пространства слева и справа по периметру, либо повторяющегося рисунка.
1. Стартовая и внутренние страницы имеют разную структуру. общие цвета: белый фон, графика фона с приглушенными серо-сине-желтыми тонами, заголовки в гамме синего, буквы черные.
2. Стартовая страница:
— содержит крупный логотип (до 25% высоты сайта) и левое текстовое меню с графическими маркерами (стиль как на www.viveska.info)
— имеет структуру, собранную из вертикально следующих информационных блоков: о компании, наши преимущества, что умеем, полезно знать, последние работы, наши услуги, новости. Каждый блок построен по принципу вынесения главного или самого современного. Все блоки одного размера. В будущем возможно расширение и обновление сайта путем замены одного блока на другие.
Под меню можно разместить ленту работ.
2. Основные страницы (портфолио, клиенты, новости, услуги):
— логотип имеет меньшую высоту (10-15%), левая колонка содержит коллаж из работ или иллюстрацию (при наличии)
— имеют двухколоночное построение (лого вертикальное меню).
3. Внутренние и текстовые страницы имеют двухколоночное представление: шапка+меню+текст страницы.
ТЗ написано по результатам изучения брифа, двух бесед с руководителем и изучения продукции заказчика.
Имена заказчика и конкурентов я поубирал. Если кто-то поделится своими образцами или требованиями к ТЗ на дизайн (из фрилансеров), будет здорово.
Как создать ТЗ для программиста / Habr
Рекомендации геймдизайнеру от программиста (архитектора).
Вступление
Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.
Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.
Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.
Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.
Самое важное:
- Четкое понимание конечного результата. (Контроль качества.)
- Сроки исполнения.
Зачем нужна документация:
- Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
- Способ увидеть, как будет выглядеть готовый проект.
- Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка — тем дешевле ее исправить)
- Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
- Планирование работ.
Какие бывают документы:
- Концепция («Про че игра?»)
- Спецификация (Что мы хотим получить?)
- Техническое задание (Как это устроено — именно о нем будет идти речь.)
- План работ (Как мы это будем делать.)
Кто участвует в обсуждении ТЗ:
Чем раньше будет получена обратная связь от заинтересованных специалистов — тем меньше будет сделано лишней работы.
- Геймдизайнер (Написание документации)
- Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
- Программист (Оценка объемов работ.)
Требования к оформлению документации:
Чем более неряшливо будет оформление — тем меньше людей вообще начнет это читать. Читатели проявляют невероятную изобретательность, чтобы избежать неприятной для них работы. Поэтому так важно прилагать усилия к тому чтобы чтение документации было легким и приятным настолько, насколько это вообще возможно.
- Форматирование. (Легко напечатать и приятно читать/держать в руках)
- Выделение ключевых фраз. (Для чтения документа по диагонали)
- Составление списков. (Вместо сплошного текста)
- Разбиение длинных списков по группам. (По три пункта в группе)
- Многократные повторения. (Избегать ссылок по документу)
- Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
- Оглавление, список документов, история изменений. (Для поиска по документации/версиям)
Требования к содержанию ТЗ
Нет четкого списка требований, которому должна удовлетворять документация. Поэтому разработка ТЗ приостанавливается задолго до приближения к ее полноте. В итоге следующий этап разработки начинается без ТЗ, в надежде, что ТЗ будет дописана по ходу, или даже по итогам разработки.
- Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
- Никаких общих слов типа:
- все возможные варианты
- карта придумывается компьютером
- взаимодействие различных объектов
- после всех действий и т.д.
- Все названия видов сущностей(классов) должны иметь:
- русское название (для игрока)
- английское (для кода)
- краткое описание (расшифровка/подсказка/комментарий)
- Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
- Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
- Все что можно измерить, должно быть измерено.
- размеры картинки в пикселях и байтах
- количество столбцов и клеток в таблице
- количество символов в текстовом поле
- количество оружия на уровень
- время сессии и т.д.
Главные требования к результату работы программиста:
Эти важные требования подразумеваются, но никогда никем не озвучиваются.
- Гибкость системы к изменениям. (Динамические требования.)
- Автоматический сбор данных об ошибках. (Обратная связь.)
- Простота запуска и настройки заказчиком. (Демонстрация результата.)
Первый этап написания ТЗ:
Описание предметной области, ее формализация в понятных программистам терминах.
- База данных (метаданные)
- список типов объектов
- характеристики объектов
- связь/зависимость между объектами
- Бизнес-процессы (полный игровой цикл)
- список процессов (сценарии работы)
- список функционала (что должен уметь)
- список ожидаемых изменений (что вообще может быть)
Второй этап написания ТЗ:
Как должен выглядеть/работать продукт для всех типов пользователей (игроки и администраторы).
- Интерфейс (визуальная часть)
- список экранов игры с названиями (или группы элементов)
- список элементов на каждом экране с названиями и текстом подсказок
- описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
- Админка (управление)
- сервер (жизненные/системные показатели )
- игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
- игровые данные(контент генерируемый игроками)
- статистика и отчеты (какую статистику нужно собирать?)
Третий этап написания ТЗ:
Как мы собираемся это все делать.
- Исследование необходимых технологий
- Список требований к каждой технологии
- Описание тестов/демонстрации работы каждой технологии
- Список будущих требований/возможных проблем (что дальше?)
- Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
- Список небходимых инструментов для работы с контентом (редактор карт, админка квестов, ).
- Расстановка приоритетов по задачам.
- Требования к первой работающей сборке (что должен уметь первый прототип).
- Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)
Сопровождение документации
- Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
- Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
- Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
- Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
- После каждого цикла планирования — проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно.)
- Составить список неудобных вопросов. Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
- Предоставлять краткие инструкции конечным исполнителям. Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
- Признак мастерства: каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.
Срезание углов
Любая технология будет упрощена до абсурда, чтобы уменьшить количество работы и расходов. Хлеб из химических дрожжей, вино из спирта, разработка без документации.
Многие считают что документация не нужна, если:
- Проект в 2-3 месяца.
- Команда из 2-3 человек.
- Ограниченный бюджет. (Он всегда ограничен)
- Нет требований к документации. (Никто не знает как надо делать)
- От нее нет никакой пользы. (Никогда не использовали документацию)
Однако следует помнить: разработка документации занимает 40% всех усилий. И определяет на 90% вероятность успешного завершения разработки проекта.
Первые шаги
Настоятельно рекомендуется новичкам выбирать в качестве первых проектов «клоны» классических игр. Пока нет успешного опыта такой игры — нет виденья всего цикла разработки продукта. А значит нет понимания того, как дойти до финиша.
Не стоит начинать разработку игры, не написав хотя бы двух полноценных ТЗ в качестве упражнения. Это может быть ТЗ по арканоиду. Но это обязательно должен быть ТЗ по которому разработчики смогут написать полноценный арканоид, даже если они никогда не видели этой игры прежде.
макеты или текст? / Habr
В заметке ТЗ для web-разработчика автор пишет:считаю что одно из самых правильных способов подачи информации есть графический, т.е. лучше один раз увидеть, чем сто раз услышать.
Никак не комментируя заметку в целом, хотелось бы сделать несколько замечаний по поводу разных способов представления информации в ТЗ и не только в нём.
Вступление
Не далее как полгода назад у нас с одним из директоров вышел спор, какой из вариантов представления информации в ТЗ предпочтительнее — макеты или описание. Он стоял за макеты, мотивируя это большей наглядностью и компактностью. Я же настаивал на описании, потому что, на мой взгляд, макет не даёт полной информации и может трактоваться по-разному. Тогда мы остались каждый при своём мнении, но я продолжал думать над этим вопросом, и вот к чему я пришёл…
Задача определяет выбор инструмента
Только так и никак иначе. Согласитесь, было бы полным бредом заколачивать гвоздь отвёрткой, только потому что отвёртка легче молотка и занимает меньше места. Но чтобы правильно выбрать инструмент, надо знать его возможности.
Макеты
Макеты предоставляют
- Наглядность
- Однозначность расположения элементов
- Лаконичность
Макеты не предоставляют
- Информации о функционировании элементов
- Формализации
Текстовые описания
Текстовые описания предоставляют
- Полную информацию о функционировании
- Полное описание свойств блоков, элементов и т.д.
- Формальность описания
Текстовые описания не предоставляют
- Наглядность
Примечание. Под формализацией и формальностью описания я подразумеваю возможность закрепить нечто в договоре с заказчиком и использовать как критерий для оценки готовности работы при приёмке.
Исходя из этих свойств, можно составить таблицу предпочтительных инструментов для решения разных задач:
| Задача | Предпочтительное представление |
|---|---|
| Описание расположения элементов на странице | Макет |
| Описание назначения и функционала элемента | Текст |
| Описание свойств объекта | Текст |
| … | … |
Важное замечание. Приведённые достоинства/недостатки, а так же таблица, являются не более чем примером. Естественно что эти списки можно расширить, а уж набор задач очень сильно зависит от специфики работы.
Каждому своё
Важен так же адресат информации. Если это дизайнер, то ему важнее представление информации (хотя и основные сведения о функционировании тоже нужны!), и лучшим вариантом для него наверное будет макет. Программиста же расположение элементов волнует слабо, ему важнее функционал и требования. Задание для него лучше записать словами. Заказчики бывают разные, так что здесь тоже всё может быть индивидуально.
Примеры неправильного применения
Описание расположения при помощи текста
Пример приведён в заметке «ТЗ для web-разработчика»:
Сверху должен распологаться логотип, правее форма для авторизации пользователей, чуть ниже логотипа — ссылки сайта, под ссылками — топ комментируемых новостей, и еще ниже блок рекламы. По центру должна находиться форма поиска, под ней — последние добавленные объявления, затем блок рекламы, и последние новости. Под формой авторизации должен распологаться блок с последними комментариями на форуме, и ниже блок рекламы. В самом низу страницы будут находиться счетчики-пузомерки, а так же копирайты
Я согласен с автором — здесь явно уместнее будет макет.
Описание свойств при помощи макета
Пример, с которым я не раз сталкивался у нас — описание свойств товара макетом «карточки товара» (просмотр информации о товаре в каталоге).
Почему здесь должно быть текстовое описание?
- Не все свойства товара могут отображаться в «карточке»
- Не всегда можно однозначно понять из макета тип свойств. Пример — цена может быть числом, а может строкой, текст может быть коротким или очень даже длинным, картинок может быть ограниченное количество, а может и нет.
- На макете за свойства товара могут быть приняты свойства других объектов (напр. категории) или вычисляемые свойства
Выводы
Общие
- «Самых правильных» способов подачи информации не существует!
- Подходящий способ подачи определяется:
- Характером информации
- Задачей (адресатом)
- Одна и та же информация может быть подана в одном документе различными способами для разных пользователей документа
Применительно к ТЗ (моё личное мнение)
- ТЗ — это технический (а часто и юридический, напр. приложение к договору) документ и большая его часть должна быть представлена в текстовой форме.
- Макеты должны быть приложением к ТЗ, призванным увеличивать доступность текстовой информации, но не заменять её.
- Кроме «чистого» текста и макетов есть ещё таблицы и списки, которые могут увеличить наглядность, лаконичность и доступность информации. Иногда они могут успешно заменить макеты. Используйте их чаще!
Ссылки по теме
Как разработать Техническое задание. Часть 2. Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов
Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.Хорошо подумав, я решил, что вместить весь материал планируемой второй части в одну статью опять не получится, иначе это будет верхами и в теории, что и так написано во многих учебниках. Но ведь я ставлю задачу, чтобы это можно было применять на практике, поэтому не буду больше загадывать на будущее о том, сколько выпусков еще потребуется, чтобы закончить с темой. На это будет влиять и обратная связь с читателями, так что пишите, не стесняйтесь!
Пользуясь случаем, хочу задать вопрос: на сколько интересна была бы организация практического семинара-тренинга в Санкт-Петербурге на тему разработки Технического задания? Встретились бы, опытом обменялись. Если такой интерес будет не единичным, обещаю организовать.
Поскольку читателями являются не только специалисты в области разработки программного обеспечения, а также бизнес-аналитики и руководители различного уровня, постараюсь писать так, чтобы было интересно всем.
В этой части мы будет говорить о том, как организовать этап работ по сбору требований, из чего он должен состоять и какими инструментами можно пользоваться. Повторюсь, что данные работы с точки зрения этапов очень похожи на обследование предприятия с целью описания бизнес-процессов.
Как обычно происходит в жизни:
| Как это происходит в большинстве проектов |
|
| Шаги |
Как это происходит |
| Решение принято, проекту быть! | Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому. |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать). |
| Документирование результатов работы | После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много. |
Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».
Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?
Как видим, процесс заканчивается вопросом, т.к. на этом работа далеко не закончена и дальше начнется самое сложное и самое практичное – именно то, что будет определять применимость полученного результата в реальной жизни. Именно то, что будет определять судьбу предыдущей работы: или она отправится в шкаф (на полку или еще куда-нибудь), либо будет представлять собой ценный источник информации. А еще лучше, если она станет образцом для последующих проектов.
Хочу особо отметить, что до последнего шага на схеме (там, где вопрос) общий принцип сбора информации о деятельности компании выглядит одинаково, независимо от того, что планируется делать в дальнейшем, описывать бизнес-процессы или внедрять автоматизированную систему. Да, сама последовательность шагов одинаковая, но инструменты, применяемые на некоторых из них, могут отличаться. Мы данный момент обязательно рассмотрим, когда будем изучать методики и инструменты отдельных этапов. Подробно будем это делать в отдельных статьях, а сейчас рассмотрим только самое главное. Дальнейшие шаги будут отличаться и определяться тем, что требуется от проекта: описать бизнес-процессы или внедрять систему учета.
Давайте посмотрим, как можно реорганизовать подход к сбору информации о деятельности компании.
| Как это может происходить при более грамотной организации работ |
|
| Шаги |
Как это происходит |
| Решение принято, проекту быть! | Тут ничего не меняется относительно первого варианта, эмоции никто не отменял |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Этот шаг тоже остается, и он имеет большое значение. Но основное назначение первой встречи (или нескольких встреч) с руководителями и собственниками это знакомство. Знакомство в первую очередь с людьми и компанией. Сформулированные цели и пожелания на таких общих встречах могут быть самими различными, в том числе фантастическими. Все они будут, конечно же, выслушаны, но не факт, что будут реализованы. При более глубоком погружении в бизнес компании будут как появляться другие цели, так и отвергаться предыдущие. Я это к тому, что из предварительных встреч нельзя сформулировать четкие цели, все это потребует тщательной проработки.На таких встречах необходимо конспектировать все посылы от собственников и первых лиц, чтобы потом можно было к ним вернуться и обсудить, когда будет собрано достаточное количество информации. Даже простое на первый взгляд требование может оказаться нереализуемым либо очень трудоемким. |
| Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей | Необходимо определиться, кто будет работать над проектом как со стороны Заказчика, так и со стороны Исполнителя. Несмотря на кажущуюся простоту данного этапа, он имеет очень большую роль. Если не зафиксировать четко, кто за что отвечает, в ходе реализации работ Вы рискуете столкнуться с неразберихой. Если со своей стороны Вы можете всегда конкретизировать роли в своей команде, то у Заказчика с этим могут возникнуть проблемы. На что следует обратить внимание: в состав рабочей группы Заказчика обязательно должны войти те люди, которые будут в дальнейшем хоть как-то влиять на принятие результата. Если допустить ситуацию, что при сдаче работ подключатся сотрудники Заказчика, которые не принимали участие в работах по формированию целей и выявлению требований, то проблемы гарантированы. Возможна даже такая абсурдная ситуация, что все, оказывается, сделано не так, как требовалось.В моей практике я сталкивался с такой ситуацией не раз.Поэтому, Вы себя можете обезопасить, если оговорите и зафиксируете документально, что никто, кроме рабочей группы Заказчика не может принимать участие в приемке-сдаче работ. А лучше всего, прописать такое в договорных условиях (В договоре или Уставе проекта). Помню, был такой случай: в одном крупном проекте учредитель решил подключиться к процессу (уж не знаю почему, скучно видать стало) и посетил одну из рабочих встреч, где обсуждался вопрос формирования счетов клиентам. Он с удивлением для себя узнал, что счет клиенту выставляет менеджер по продажам. В его представлении счет должен выставлять бухгалтер, и никак иначе. Но на самом деле бухгалтер вообще не представлял, о чем идет речь, а менеджер не мог себе представить, как так работать, если за каждым счетом бегать к бухгалтеру. В результате потеряли кучу времени, но ничего не поменялось, счет по-прежнему выставлял менеджер. А учредитель остался при своем мнении, но больше в процесс не вмешивался. На этом же этапе целесообразно разработать Устав проекта, в котором зафиксировать роли участников, порядок коммуникаций, регламент и состав отчетности, а также все остальное, что следует прописать в Уставе. Разработка Устава проекта это тема опять же отдельная. |
| Обучение проектной команды методикам и инструментам работы, согласование правил работы, видов и состава документации | Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике. Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны. |
| Анкетирование | Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами:
Обращаю внимание, что методика анкетирования для последующей внедрения автоматизированной системы или описания бизнес-процессов в правильном случае различается. Конечно, структура анкет может быть и одинаковая, но это не самый лучший вариант. Когда мы описываем бизнес-процессы, то анкеты обычно носят более общий характер, т.к. неизвестно точно, с чем придется столкнуться. Если же речь идет о внедрении конкретной автоматизированной системы, то лучше иметь анкеты, учитывающие особенности этой системы. При таком подходе можно сразу выявить все узкие места системы, которые не подходят для данного предприятия. Как правило, методики внедрения готовых систем предусматривают наличие таких анкет. Такие анкеты могут разрабатываться либо по отдельным областям учета (например, учет заказов, продажи, ценообразование), либо для конкретных должностей (финансового директора, например). Состав вопросов примерно одинаковый. |
| Опросы | Опросом называется проведение устного собеседование со специалистами с целью выяснить особенности отдельных процессов. Необходимо организовать опрос так, чтобы он не выглядел как просто «встретились-поговорили», а более организовано. Для этого необходимо подготовить так называемый план опроса. В него можно включить те части анкеты, которые у Вас вызывают вопросы, противоречат сведениям других анкет или информация представлена поверхностно. Целесообразно добавить вопросы и просто из личного опыта.Ответы надо конспектировать в обязательном порядке. Идеально, если Вы договоритесь о ведении аудиозаписи. На этом же этапе следует проследить за полнотой предоставленной информации о документообороте (как форм первичных документов, так и различных отчетов) |
| Выделение ключевых бизнес- процессов или областей автоматизации | После анкетирования и опроса можно обосновано считать, что информации достаточно, чтобы делать выводы о выделении ключевых бизнес-процессов. На самом деле, уже можно выделить не только ключевые бизнес-процессы, но и практически все (если состав участников был выбран правильно). Вопрос выделения бизнес-процессов это тема совсем отдельная и не простая. Научиться тут сложно и вырабатывается в основном опытом. Из выделенных бизнес-процессов следует составить перечень (классификатор). Затем можно будет принимать решения, какие из них следует исследовать более глубоко, какие нет, а также выделять приоритеты. |
| Формулирование ключевых требований к системе, целей, критериев успешности проекта, процессов для детального изучения | К этому этапу должна быть собрана вся первичная информация о деятельности компании, составлен перечень бизнес-процессов. Теперь в самое время вернуться к целям, конкретизировать их, при необходимости обсудить с первыми лицами компании. При формулировке целей следует учесть конкретные показатели, при достижении которых будем считать проект успешным. Если речь идет о внедрении автоматизированной системы, то отдельным перечнем можно выделить требования к системе от ключевых пользователей. Я это делаю в виде отдельной таблицы, где все требования сгруппированы по подсистемам, для каждого требования указывается автор требования, формулировка и приоритет. Данную информацию можно будет использовать для составления плана развертывания системы (последовательности внедрения отдельных подсистем), а также для предложений по дальнейшему развитию системы (если отдельные подсистемы в текущем проекте внедрять не планируется). Если необходимо описать бизнес-процессы, принимаются решения о тех процессах, которые необходимо исследовать более детально. |
Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.
| Шаги |
Что и как делать |
| Выделяем бизнес-процесс | Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично. |
| Детальное изучение бизнес- процесса | Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать) |
| Графическое и/или текстовое описание бизнес-процесса (первичное) | Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть. |
| Согласование с исполнителями и владельцем бизнес-процесса | Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить. |
| Выделение показателей бизнес-процесса | После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет. |
| Окончательное документирование бизнес-процесса | После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов. |
Теперь рассмотрим, как будет выглядеть подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
| Шаги |
Что и как делать |
| Выделяем бизнес-требование/область автоматизации | Выделение в качестве требований целой области автоматизации (например, «Складские запасы») на практике используется, однако, это не самый эффективный способ детализации требований. Область автоматизации представляет собой группу требований, и рассматривать их лучше каждое в отдельности. Например, «Учет поступления материала на склад» |
| Детальное изучение бизнес-требования | Под детальным изучением бизнес-требования понимается то, как это хочет видеть и будет использовать конечный пользователь (разумеется, в соответствии с целями проекта). В технологиях разработки программного обеспечения это часто называют «вариант использования». Таким образом, детальное изучение бизнес-требования сводится к проработке вариантов использования. Пример такого варианта приведен в приложении 2 к статье. В простейших случаях варианты использования вовсе не обязательно рисовать в виде графических схем, можно ограничиться и текстовой формулировкой. Например, требование «При вводе номенклатуры цена должна рассчитаться как цена закупки +20%» рисовать не имеет смысла. В виде диаграммы имеет смысл представлять требования, объединенные до области автоматизации, как показано в примере в приложении 2. |
| Моделирование требований в информационной системе | Вот оно! Как Вы наверное помните, я уже обращал внимание на этот важнейший элемент в методике разработки Технических заданий. «Построй модель – получишь результат!» А что надо моделировать? Моделировать надо варианты использования, полученные на предыдущем этапе. Что должно быть на выходе моделирования? Должна получиться демонстрационная программа, в которую внесены пользовательские данные, причем желательно привычные его (пользователя) слуху, с учетом отраслевой специфики, актуальных проблем. И не просто так внесены, а должно быть понятно, откуда эти данные взялись, как рассчитались. В этом месте у читателя должны возникнуть вопросы:
Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная. Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит). Целесообразно сопроводить такую модель текстовым описанием, пусть даже кратким, чтобы пользователь мог самостоятельно попробовать поработать с моделью в свободное время. В этом же описании можно формулировать требования к доработкам. |
| Демонстрация информационной модели рабочей группе | Полученную модель показываем Заказчику и рассказываем, как все должно работать.Демонстрацию модели лучше проводить по подсистемам, т.е. по группам требований. В случае, если выяснится, что у клиента предлагаемая схема работать не будет, надо подумать о других вариантах использования, внести изменения в модель и показать еще раз. Только если есть уверенность, что планируемая модель у данного клиента «будет жить», можно считать модель удачной. |
| Разработка тестов | Зачем нужны тесты? То, как мы смогли реализовать требования, нужно будет проверять. Соответственно, на все ключевые участки, сложные алгоритмы и пр. тесты желательно сделать. В том числе эти тесты могут быть использованы при сдаче работ. Вовсе необязательно делать тесты на каждую функцию системы, везде должен быть здравый смысл. Если речь идет о готовой системе, то делать тест на «ввод нового элемента в справочник клиентов» будет выглядеть глупо и бесполезной тратой сил и времени. А вот если это совсем новая система, такое вполне возможно. Зачем делать тесты, если еще нет системы?Во-первых, разработчику будет понятнее, чего от него хотят добиться. Во-вторых, мы облегчаем жизнь тестировщику (кто-то ведь будет тестировать результат разработки). Вообще, тестирование это отдельная дисциплина, весьма не простая с множеством методик. На практике, как правило, все равно используются самые простые методы тестирования. |
| Документирование требований в виде Технического задания | Собранная информация на предыдущих этапах будет являться как раз тем, что и должно войти в основу документа «Техническое задание» в раздел с требованиями.Так что остается все это грамотно оформить. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дольше может начаться процесс разработки, поиск партнеров для проекта, тендер и т.д., все зависит от ситуации. |
Да, разработка Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет Заказчика от не сбывшихся ожиданий. Исполнителю приходится делать то, что требуется Заказчику и не переделывать сто раз одно и тоже. Да и вообще, придает всему проекту прозрачность.
Приложение 1. Описанный бизнес-процесс в нотации EPC.
Приложение 2. Вариант использования подсистемы « Заказы»
Как правильно написать ТЗ на систему или доработку системы 1С / Habr
Для того, чтобы Вам как заказчику, консультанту или методологу понять, что нужно разработчику 1С для того, чтобы доработать Вашу систему или разработать новую, нужно понимать, какими категориями информации он оперирует в ходе своей работы. Это сильно упростит программисту понимание того, что же от него хотят.В данной статье я постараюсь кратко и, при этом, достаточно полно объяснить, что Вам нужно написать в техническом задании помимо общих разделов с глоссарием, титульным листом и описанием бизнес-требований.
Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.
Итак, приступим.
Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:
Давайте отдельно рассмотрим каждую категорию.
Формы ввода информации
Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).
Не забывайте указывать перечень кнопок-команд, которыми пользователь должен командовать Вашей системой.
Если техническое задание не содержит продуманного Вами заранее прообраза таких форм или шаблонов, то программист будет придумывать их по своему усмотрению, а Вы будете жаловаться, что вам это неудобно в работе.
Контрольные процедуры
В бизнес-процессах эти процедуры являются предварительными контролями, чтобы вам было понятно. Т.е. это такие контроли, которые система делает сама в тот момент, когда пользователь с той или иной ролью пытается работать с системой, и выдает предупреждение или намеренно прерывает работу пользователя, не позволяя ему выполнить задуманное.
В эту категорию попадают:
- Матрицы ролевого доступа
- Правила предоставления доступа к полям форм и данных
- Проверки корректности заполнения данных в формах ввода
- Процедуры сверки данных
Если техническое задание не содержит контрольных процедур, то созданная система будет позволять делать все что угодно любому пользователю, почти как в Excel, только с другим оформлением. Какая Вам от этого выгода?
Модель данных
Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.
Если Вы тоже «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:
- Перечень бизнес-объектов, с которыми имеет дело пользователь и отношения между ними, ссылки на какие объекты в каких объектах должны храниться
- Состав полей данных (табличка в эксель) по каждому бизнес-объекту, у которого есть форма ввода
- Поддержка иерархичности — нужна или нет
- Сколько данных планируется хранить
- Регулярность ввода и изменения этих данных
- Нужно ли хранить в одном объекте несколько таблиц данных, и если да, то с какими аналитиками, будет ли какой-либо другой объект ссылаться на записи этих таблиц
- Поддержка хранения данных с историей по датам — нужна или нет
- Поддержка расчета итогов на какую-либо дату, или оборотов за период — нужна или нет
- Поддержка двойной бухгалтерской записи — нужна или нет
- Поддержка вытесняющих графиков величин во времени — нужна или нет
- Поддержка процессов взаимодействия пользователей по объекту — нужна или нет
Эти сведения помогут программисту создать нужную категорию объектов системы, которую потом не нужно будет переделывать, если он сам не догадался о вышеперечисленных характеристиках.
Алгоритмы автоматического заполнения данных
Если у Вас формы ввода содержат много полей или таблиц, Ваши пользователи вряд ли захотят каждый раз заполнять все поля с чистого листа.
Здесь Вы должны продумать, какие поля или таблицы могут быть заполнены по другим полям или таблицам этого или других бизнес-объектов.
Так же, здесь Вы продумываете зависимые автоматические заполнения форм ввода в зависимости от только что измененных полей пользователем. Например, после выбора номенклатуры пользователю не надо выбирать ее основную единицу измерения, система подставит ее по-умолчанию сама.
Формы вывода информации
В эту категорию попадают отчеты и формы объектов «на просмотр» или «выбор». Понятное дело, программист не должен сам придумывать форму отчета, которую Вы представляете себе совершенно определенным образом.
Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.
Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.
***
Формы ввода и вывода часто могут объединяться с алгоритмами заполнения данных и контрольными процедурами в функциональные интерактивные АРМы пользователей, дополняться кнопками, вызывающими определенные действия и события в системе. Тем не менее, к ним применимы те же самые принципы написания технического задания, с учетом этих особенностей.
Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.
P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?