Как написать ТЗ программисту не только в 1С.
Написать полноценное ТЗ с помощью завершенной системы, либо позаказных доработок – задача непростая. Однако условия заказчика необходимо прописывать. На вопросы: зачем и каким образом прописывается ТЗ, а также какие использовать для этого программы?
Нужно ли в итоге писать ТЗ?
- Что представляет из себя техническое задание;
- Для чего мы его пишем;
- Кто занимается написанием технических заданий, если не мы;
- Каким образом ТЗ способствует нашей работе над заказом.
Немного терминологии
- ТЗ (техническое задание) – это основной документ, который определяет требование, порядок выполнения работы, в соответствие с которыми производится принятие и разработка АС и ее приемка.
- Требования к решению (англ. Solution requirement) имеют описательный характер: они говорят нам о том, какие качества и возможности должны быть у решения (детализируя его), которое соответствует требованию заинтересованных сторон.
- ГОСТ 34.602-2020 – это стандарт, содержащий трактование технического задания.
- ВАВОК – требования к решению, которые бывают 2 видов: функциональные и нефункциональные.
Для чего необходимо прописывать ТЗ.
Фиксирование каких-либо требований к работе, а не их запоминание – всегда наилучший вариант, чтобы не забыть о договоренностях с людьми или компаниями. Ведь человеческой памяти свойственно забывать информацию, при и этом, не особо контролируя этот процесс. Так что для того, чтобы не отнимать времени ни у себя, ни у клиентов, стоит это делать.
Выполняемая задача всегда является мини-проектом, если рассмотреть её с позиции координатора проекта.
Отталкиваясь от этого, продемонстрирую цитату из PMBoK, говоря вместо «проект» – «задача»:
«Устав проекта задачи – это документ, выпускаемый инициатором или спонсором проекта задачи, который формально авторизует существование проекта задачи и предоставляет руководителю проекта разработчику полномочия использовать организационные ресурсы для деятельности по проекту задаче».
Выходит, что ТЗ – это текст, который разграничивает поле для работы исполнителя, включающий в себя сроки, инструменты, условия, обеспечивающие гарантию функциональности, предоставляемую нашему заказчику.
Ещё одним из преимуществ ТЗ является его документационная роль. Зачастую техническая документация отсутствует в проекте, так как на неё не выделяются время или средства. А запись ТЗ по той или иной задаче может значительно облегчить труд исполнителю.
Случай из практики
В контексте вышенаписанного, стоит упомянуть случай из нашей практики: к нам поступило обращение от клиента, с которым мы работали 5 лет назад. По его словам, доработка, которую мы для него сделали, не выполняла необходимых ему задач. Решение проблемы оказалось простым: в нашей системе учета задач Redmine мы отыскали ТЗ, которое после отправили заказчику. В конечном счете, он остался доволен и вопрос был решен.
Еще одна немаловажная черта техзадания – его мотивационная составляющая, которая стимулирует программистов вкладывать своё время на выполнение задания.
Небольшое количество предложений несут за собой разъяснение и смысл, выполняемого задания. Конкретное понимание исполнителем сути своей работы значительно повышает не только его заинтересованность в проекте, но и качество итогового результата.
Пишем ТЗ качественно! Придерживаемся следующих составляющих:
- Всё начинается с заглавия. Его верная формулировка гарантирует вам 50 процентов выполненной работы.
- Пропишите требования в духе User Story: для каких пользователей этот продукт, что именно и с какой целью они хотят от него получить.
Не забудьте указать конкретные примеры, ведь именно благодаря им ТЗ станет понятным и эффективным. Допустим, вы можете указать, какое поведение вы ждете от системы (прописав, что 2 + 2 должно быть равно 4, вы дадите разработчику полную и ясную картину его действий).
«А если получится лонгрид?»
Несколько правил, чтобы не допустить этого:
- Скриншоты наше всё: используйте их, не забывая помечать красным появление либо передвижение определенных объектов.
- Макет Excel в документе также поможет избежать вам этого: сформируйте уже готовую текстовую форму, сохранив её в Excel и добавив в неё необходимые замечания и уточнения. Проектировка отчетов с помощью группирования доступна и в Excel.
- Структура в виде нумерованного списка, в том числе является незаменимым помощников в составлении технического задания. Благодаря ей, общение программиста с клиентом ограничиться тем, что ему надо будет уточнять какие-либо моменты через указание номера необходимого пункта, а не ссылкой на третий абзац где-то в середине пятой страницы.
Чтение лонгридов часто происходит по диагонали: на что-то обратили внимание в начале, на что-то в конце. Поэтому, добавив изображение, которое раскрывает основную мысль ТЗ, всё станет сразу же куда яснее и проще.
Составление ТЗ не ограничивается только продуктом или разработкой – его пишут и на само техническое задание.
Допустим, клиента может посетить мысль: а зачем ему платить 100 тысяч и более за техзадание, если не все предложенные доработки он планирует использовать. Тогда необходимо подробно написать о том, какие именно данные он получит от ТЗ и на какие вопросы будут даны ответы. Благодаря такому подходу легко обосновать стоимость проекта, особенно если подготовка его технического задания потребует ощутимых временных затрат.
Когда начать писать ТЗ?
Сейчас речь пойдет о выборе даты начала написания ТЗ, для того чтобы оно просто появилось.
Оформление технического задания на нашей практике происходило в разные моменты времени: это мог быть старт работы над проектом, во время работы над ним или вовсе после завершения всех разработок. Как мне кажется, момент написания технического задания не имеет большого значения, более важным считается другое:
- В первую очередь, разработка проекта выполняется с учётом фиксированной оценки: то есть эта оценка обязательно включает в себя риски, так как требования могут увеличиваться или меняться.
- Во вторую очередь, разработчику необходимо внести корректировки в техническое задание, после выполнения и предоставления проекта клиенту. То есть в ТЗ нужно отразить все условия заказчика, не исключая и онлайн обсуждений (достаточно будет и тезисного формата).
Такие действия помогут избежать неясностей в дальнейшем и будет понятно, почему задачи были реализованы так, а не иначе. Кстати, заказать разработку 1С можно у нас в компании.
Инструкция как написать ТЗ:
Воспользуйтесь таск-трекером
Протестировав разные таск-трекеры для составления технического задания, мы выбрали Redmine, который используем по сей день. Также мы работали с Trello – особенно мне в нем приглянулась доска, так как в версии нашего Redmine её нет (конечно, есть возможность замещать её сменой статусов задач, но это не так эффективно и понятно).
В работе с Trello могло бы быть всё идеально, однако у него есть существенный недостаток – трек-номера отсутствуют. Это чревато тем, что при увеличении масштабов заказа, карточек на доске становится очень много, и обнаружить среди них нужное практически невозможно. В Redmine же поисковая система проста в использовании: найти требуемое можно или по наименованию задачи, или посредством совпадения основных слов, или благодаря сортировки заданий по затраченному времени (в такой ситуации масштабные задачи будут находиться на вершине списка.
Используйте разметку
Что касается разметки, то Redmine работает в связке с Markdown. Хотя стоит заметить, что начальном этапе работы с ним, вместо Markdown был Textile. При сравнении этих разметок, однозначно скажу, что Textile я предпочитаю больше из-за его нумерованных списков.
После того, как вы проставите в Textile «#» и все это сохраните, автоматически появляется нумерованный список. В это же время, в Markdown такого нет: необходимо прописывать 1, 2, 3, и если нумерация собьется, поправить её возможно только вручную, что достаточно дискомфортно.
Прототипирование форм (шаблоны)
При помощи конфигуратора мы прототипируем формы. Благодаря ему есть возможность за короткое время (от 5 до 10 минут) набросать форму невысокой сложности, которую потом можно было бы быстро согласовать с клиентом, и внести её в ТЗ.
Такой процесс обычно происходит двумя путями: или это скриншоты и отправка черновиков техзадания на почту заказчика, или же это непосредственное воспроизведение тестовых данных в онлайн-формате, что выглядит как живая система. Благодаря последнему, можно избежать дальнейших расхождений во мнениях, а также в моменте отразить необходимые критерии в техническом задании.
Визуализируйте информацию
Когда-то мы написали генератор технических заданий, включающий в себя стек Redmine, 1C, Pandoc, LaTeX. Делать таблицы и многоуровневые нумерованные списки, а также использовать изображения возможно в Redmine. Нажимая в нем кнопку, мы запрашиваем доступ к веб-сервису 1C, после чего создается PDF файл, который будет или заявкой на разработку, либо ТЗ.
Получается, что текст, который разметили в Redmine, перегружается в формате Textile в Pandoc и проходит конвертацию в LaTeX. Затем все это проходит процесс преобразования в 1С, что в конечном счете превращает их в документы технических заданий.
Используйте средства совместной разработки
Если дело касается масштабных документов, например, устав проекта, по которому необходимо что-то предварительно прописать и впоследствии проанализировать это онлайн, то в качестве помощников выступают редакторы, в которых печатаются тексты (в нашем случае это Google Docs).
Централизованное хранение
Централизованное хранение техзаданий мы осуществляем благодаря Redmine.В нём же есть возможность создать Вики, в которой будет возможность вставлять описания из задач при помощи определенной языковой модели.
Уточнения
Также стоит отметить, что для наших разрабов в Redmine мы прописываем отдельные уточнения. Подстрочник (т.е. информацию, где можно уточнять определенные моменты) пишется для мидлов и джунов с использованием заглавного слова – collapse.
Когда программист начинает работу с задачей, него эти уточнения скрыты (однако он может развернуть их, чтобы впоследствии с ними ознакомиться). При этом когда создается финальный вариант технического задания парсер на автопилоте стирает данные уточнения, чтобы клиент не смог их увидеть.
В завершении отметим, что написание ТЗ необходимо. Ваше право называть их функциональными требованиями, однако прописывать их нужно. Опыт доказывает, что техническое задание всегда понадобится в будущем, даже если сейчас в нём нет нужды.
