Часто возникает проблема между Заказчиками и Разработчиками в понимании друга друга и задачи.
Чтобы решить эту проблему обычно Разработчики говорят Заказчику — напиши ТЗ (техническое задание). Чтобы понять что нужно.
Чаще всего это приводит лишь к усугублению проблемы Потому что обычно вместо ТЗ пишется некий документ содержащий сочинение на тему желаний. Который затем достаточно сложно реализовать.
Почему так происходит? Смею предположить причина в том что стороны не понимают что такое ТЗ, в чем его смысл, как оно выглядит и что должно быть после него
ТЗ и ГОСТ
Чаще всего люди идут гуглить что такое ТЗ, налетают на ГОСТ и пытаются делать по нему Вот только они не учитывают что ТЗ по ГОСТ было придуман для проектов на 1000 человек, и только одна подготовка такого ТЗ если делать ее правильно может стоить 1-2-10 млн. руб. Не считая работ по его реализации.
А пытаются это применять для проектов где работает 1-2-3 человека Делается это все без понимания особенностей такого документа и получается как раз то самое собрание сочинений. Бессмысленное и беспощадное.
ТЗ и Бритва Оккама
Бритва Оккама в данном случае говорит о том что наиболее простое решение — наиболее верное. Если нет веских причин для усложнения.
Какое самую простую форму ТЗ можно придумать? Ответ — простой список задач (требования, пожеланий). Чаще всего именно эта форма наиболее адекватна.
Иногда она может расширяться некоторыми полезными артефактами (разделами):
- Цели — описать не только то что надо сделать, но и для чего мы это делаем? Чтобы что? Это бывает полезно для повышения качества результатов.
- Снимки, фото, звуки, примеры — бывает полезно добавить в задание снимок ошибки (например когда мы делаем сайт) или пример/фото того как это сделано у кого-то еще.
Да, если проект реально большой, у вас есть 10-20 человек заинтересованных в результате, ТЗ согласовывается с ними пол года, а потом есть 100-200 человек, которые будут реализовать этот проект — тогда можно взять ГОСТ или сделать какой-то большой документ. Иначе — у вас не хватит ресурсов сделать качественную постановку задачи, а потом те кто будут делать — не осилят изучение. И один лишь контроль приемки работ по такому ТЗ превратится в ад.
Техническое решение или ТР
А вот та самая часть, которую многие совсем не понимают. Кроме технического задания (в котором может быть просто 3-4 пункта пожеланий на салфетке из кафе), может быть еще техническое решение. Оно чаще всего гораздо важнее чем ТЗ и сильнее влияет на конечный результат.
Техническое решение — пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.
Зачем это нужно? Чтобы исключить разное понимание условий и снизить риски расхождения ожиданий.
Пример для понимания. Заказчик дает ТЗ «Я хочу есть», а Исполнитель предлагает ТР «На вот яблоко». Далее может быть 3 сценария: Заказчик соглашается, корректирует/просит предложить что-то еще или отказывается от дальнейшего общения
Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.
Почему ТР важно?
ТР важно по ряду причин:
- Только Разработчик реально знает как решать задачу (по этой причине Заказчик обычно к нему и обращается), а значит только он может описать детали того как можно получить ожидаемый результат
- У любой задачи может быть 3-4 варианта решения (а часто больше), и тут Заказчик должен убедиться что Разработчик может предложить нечто адекватное
- Задача одна, но несколько вариантов решений часто означает разные цены. причем вилка цен может быть условно от 100 000 руб до 10 000 000 руб. ТР позволяет составить список условий и сузить разброс цен — уложиться в нужный бюджет и срок.
По ходу составления списка решений, предложений и условий — Разработчику надо будет задавать вопросы, обсуждать детали, он просто начнет понимать задачу
Именно составление ТР — позволяет Разработчику понять Заказчика. А Заказчику убедиться что Разработчик понял задание. Именно отсутствие этой части в проекте — зачастую приводит к недопониманию и конфликту.
Когда можно без ТР?
Есть некоторые ситуации когда ТР не нужно. С ходу могу назвать 2 условия:
- Если между Заказчиком и Разработчиком есть полное взаимопонимание и доверие, большой успешный опыт совместной работы. Когда Заказчик целиком доверяет Разработчику и полагается на его знания.
- Если мы работаем по Agile и у нас мелкие простые задачи
Исключение из п.2 — даже в Agile, если есть большая задача (Epic-project), у которой как правило 3-4 стейкхолдера, ее будут делать 2-3 разработчика на 5-6 месяцев, то не помешает сформулировать ТЗ и потом прописать/согласовать ТР. Чтобы убедиться что Стейкхолдеры (Заказчики) и Разработчики (Исполнители) — поняли друг друга.
Шаблон
ЕСКД 2020: как оформлять документацию по-новому?
С 1 июля 2020 года действуют новые требования к оформлению текстовой документации. Цель нового свода правил — стандартизировать форму заполнения конструкторской документации. Структура и состав текстов в сфере строительства, машино- и приборостроения должны подчиняться единым нормам.
Два нововведения предусмотрены приказом Федерального агентства по техническому регулированию и метрологии № 175-ст от 29.04.2019.
- ГОСТ 2.105-95 утрачивает силу в качестве национального стандарта, но сохраняет действие в качестве межгосударственного;
- ГОСТ Р 2.105-2019 признают национальным.
Обратите внимание и на ряд других ГОСТов, принятых в данной сфере:
- ГОСТ Р 2.106-2019 «Единая система конструкторской документации. Текстовые документы», утверждён приказом Росстандарта от 29.04.2019
- ГОСТ Р 2.601-2019 «Единая система конструкторской документации. Эксплуатационные документы», утверждён приказом Росстандарта от 29.04.2019
- ГОСТ Р 2.711-2019 «Единая система конструкторской документации. Схема деления изделия на составные части», утверждён приказом Росстандарта от 29.04.2019
- ГОСТ Р 2.610-2019 «Единая система конструкторской документации. Правила выполнения эксплуатационных документов», утверждён приказом Росстандарта от 29.04.2019
Напомним, требования единой системы конструкторской документации (ЕСКД) в РФ считаются добровольными. И если вы выполняете заказ, можно руководствоваться стандартами, выставленными заказчиком. Если документация оформляется для российского рынка, стоит пользоваться правилами оформления из национального свода.
Продолжить работу по следует, если вы готовите бумаги для партнеров из ЕАЭС. Когда документами пользуются компании и из России, и из других стран, укажите наименование стандарта, который был использован при их подготовке.
Как оформлять документацию: 4 способа
Документы можно подготовить как в электронном, так и в рукописном виде. Для каждого варианта есть свои ГОСТы.
- Машинописным способом в соответствии с Межгосударственный стандарт. Репрография. Микрография. Документы для микрофильмирования. Общие требования и нормы (введен в действие Постановлением Госстандарта России от 26.02.2004
- Рукописным методом, используя положения Межгосударственный стандарт. Единая система конструкторской документации. Шрифты чертежные (утверждён Постановлением Госстандарта СССР от 28.03.1981 № 1562).
- Применяя ЭВМ, согласно Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ (утверждён Постановлением Госстандарта СССР от 28.11.1988 № 3843).
- На электронных носителях информации.
Обратите внимание, что текстовые документы электронных (ТДЭ), согласно правилам, допускается готовить с использованием стандартизованных информационных моделей программ. Данные будут либо сгенерированы автоматически с помощью специализированных программных средств из заранее подготовленных фрагментов, либо набираются вручную.
Техническое оформление документов: общие требования
Правила ГОСТ к оформлению тестовых документов отличаются. Всё зависит от того, кто утверждал стандарт (Таблица 1).
Таблица 1. Разница и сходство редакций ГОСТ.
Высота символов — не менее 2,5 мм.
- Шрифт Times New Roman или Arial размером 14 для основного текста и размером 12 для приложений, примечаний, сносок и примеров;
- допускается использование шрифта размером 13 и 11 для основного текста и размером 12 и 10 для приложений, примечаний, сносок и примеров соответственно.
Расстояние между боковыми линиями формы и текстом должно составлять минимум 3 мм.
Абзац начинается с красной строки, минимальный отступ —
Абзацы начинается с отступа, равного
От нижней и верхней границ следует отступать не менее 10 мм.
Интервал между строками — не менее 8 мм.
- Текст оформляют с использованием полуторного межстрочного интервала;
- допускается использование двойного межстрочного интервала.
- Расстояние между заголовком и текстом при выполнении документа машинописным способом равно 3, 4 интервалам, при выполнении рукописным способом — 15 мм;
- расстояние между заголовками раздела и подраздела — 2 интервала, при выполнении рукописным способом — 8 мм.
- Расстояние между заголовком и текстом, между заголовками раздела и подраздела — не менее 4 высот шрифта, которым набран основной текст. Расстояние между строками заголовков подразделов и пунктов принимают таким же, как в тексте;
- при выполнении машинописным способом интервал равен 3 или 4 интервалам, при выполнении рукописным способом — не менее 15 мм.
При переносе части таблицы на ту же или другие страницы наименование нужно поместить только над первой частью таблицы.
Нумерацию документов ЕСКД позволяет сделать как сквозной, так и отдельной для каждого раздела.
Чего делать нельзя: 9 запретов
В требованиях к текстовым документам содержится ряд запретов. Например, требования единой системы конструкторской документации (ЕСКД 2020) года запрещают:
- Указывать индексы стандартов без обозначения присвоенного им регистрационного номера.
- Писать математические знаки без числового сопровождения.
- Ставить знак минус для обозначения отрицательных чисел.
- Перечеркивать круг в качестве обозначения диаметра.
В самом тексте недопустимо применять:
- Сокращения слов, кроме установленных правилами русской орфографии, соответствующими государственными стандартами, а также в данном документе.
- Обороты разговорной речи, техницизмы, профессионализмы.
- Для одного и того же понятия различные научно-технические термины, близкие по смыслу (синонимы), иностранные слова и термины при наличии равнозначных слов и терминов в русском языке.
- Произвольные словообразования.
К физическим величинам тоже есть требования:
- Нельзя сокращать обозначения единиц физических величин (если они употребляются без цифр, за исключением единиц физических величин в заголовках и боковиках таблиц и в расшифровках буквенных обозначений, входящих в формулы и рисунки).
Отклонение от обязательных требований не допускается, в соответствии с действующими правилами следует оформлять любой элемент текста.