Стоит ли всё-таки писать ТЗ?

Меня зовут Михаил Воронюк, я работаю с 1С v.8 больше 15 лет. За свою карьеру побывал и разработчиком, и аналитиком, и руководителем проекта.

В настоящий момент возглавляю компанию ООО «Трисофт». У нас команда из 6 разработчиков 1С, и мы развиваем направление парт-тайм-аутстаффинга.

Мой доклад будет о техническом задании. Постараюсь рассказать:

• зачем мы пишем ТЗ;

• что это такое;

• кто пишет ТЗ, если не мы;

• и как технические задания помогают нам в заказной разработке.

Немного терминологии

Начнем с терминологии.

• Есть ГОСТ 34.602-2020, который содержит определение технического задания.

• И в BABOK тоже есть нечто похожее на техническое задание – это требования к решению. Они бывают двух типов – функциональные и нефункциональные.

Но по нашему опыту на входе в проект редко бывает хорошо написанный документ, поэтому предлагаю обсудить роль ТЗ в успехе проекта.

Зачем вообще писать ТЗ

У человеческой памяти есть свойство забывать, притом забывать, не особо контролируя это.

Поэтому если вы хоть что-то где-то зафиксировали – это все же лучше, чем просто запомнить. Особенно когда дело касается договоренностей между несколькими людьми или компаниями.

Если посмотреть на техническое задание с точки зрения руководителя проекта, то задача – это, по сути, просто мини-проект.

Поэтом приведу небольшую цитату из PMBoK, заменяя слово «проект» на «задача»:

Устав проекта задачи – это документ, выпускаемый инициатором или спонсором проекта задачи, который формально авторизует существование проекта задачи и предоставляет руководителю проекта разработчику полномочия использовать организационные ресурсы для деятельности по проекту задаче.

Получается, что техническое задание – это ограничивающий задачу документ для исполнителя, где описаны ресурсы, сроки и требования к той функциональности, которую мы гарантируем сделать для нашего заказчика.

Кроме этого, техническое задание полезно, потому что оно может выполнять роль документации. Часто на техническую документацию по проекту не выделяется времени или бюджета. И если в какой-то момент по задаче написали хотя бы техническое задание, это потом может сильно помочь.

В нашей практике был случай – к нам обратился клиент, которому мы 5 лет назад делали доработку, и сказал, что она как-то не так работает. Мы нашли в своей системе учета задач в Redmine техническое задание по этой доработке и отправили его клиенту. Он был доволен.

Техническим заданием можно замотивировать разработчика тратить свое драгоценное время и кусочек своей жизни на реализацию задачи.

Всего лишь несколько предложений могут объяснить разработчику, какую пользу получит бизнес, и какую боль эта доработка снимет. Понимание смысла того, что он делает, повысит вовлеченность разработчика, а значит, повысит и качество выходящего продукта.

Что писать в техническом задании

Для качественного ТЗ достаточно всего нескольких составляющих:

• Начните с заголовка. Грамотно сформулированный заголовок – это уже полдела.

• Дальше можно добавить что-то в стиле User Story: указать, кто является пользователем, что именно он хочет получить, и с какой целью.

• И конечно, любое техническое задание станет лучше с конкретными примерами. Напишите, какое поведение вы ожидаете от системы. Например, если вы напишете, что что 2 + 2 должно быть равно 4, все сразу встанет на свои места.

Как не сделать из технического задания лонгрид?

• Используйте скриншоты – на них красным нарисовать, что куда должно переехать и где должно появиться.

• Встройте в документ макет Excel – можно сформировать имеющуюся печатную форму, сохранить ее в Excel, добавить в нее нужные детали и комментарии. Отчеты тоже легко проектировать в Excel, в том числе, используя группировки.

• Добавьте в техническое задание структуру в виде нумерованного списка – это тоже помогает в работе. В этом случае ваше общение с заказчиком будет сводиться к тому, что вы указываете на номер конкретного пункта, а не ссылаетесь на третий абзац где-то в середине пятой страницы.

Обычно лонгриды читаются по диагонали: что-то прочитали в начале, что-то в конце. А если вы добавили хорошую картинку, которая все это поясняет, ТЗ становится гораздо понятнее.

Техническое задание можно составить не только для продукта или разработки – его можно написать даже на само техническое задание.

К примеру, у заказчика может возникнуть вопрос: зачем платить более 100 тысяч за ТЗ, если он не собирается внедрять все предложенные доработки? В таком случае можно подробно описать, что именно он получит в ТЗ, и какие ключевые вопросы будут раскрыты в документе. Это помогает обосновать стоимость работы, особенно если подготовка ТЗ требует значительных временных затрат.

Кто пишет ТЗ

Расскажу, кто у нас писал или кто нам писал технические задания, для кого.

Бывали случаи, когда старшие программисты писали технические задания для младших. Но если в ТЗ уже подробно указано, какие метаданные создать и как обрабатывать данные, опытному разработчику становится неинтересно – за него уже все продумали.

Кроме того, такая схема снимает с него ответственность за принятые решения. Если что-то работает не так, как ожидалось, он всегда может сказать, что следовал ТЗ: например, просто создал регистры накопления и необходимые движения по ним.

Иногда технические задания для нас писали аналитики.

Цифра сверху – это количество символов с пробелами в трех подготовленных страничках одного из ТЗ. А справа – переписка по этому техническому заданию, которая длилась больше месяца.

Конечно, такое задание лучше, чем ничего, но когда вам дают три страницы текста и просят оценить стоимость работы, это далеко не всегда возможно.

Потому что если система имеет множество ограничений и плохо документирована, то даже такое маленькое или среднего объема ТЗ может превратиться в месячную загрузку программиста, не джуна.

Когда задачи ставит топ-менеджмент заказчика, они, как правило, не пишут, а просто звонят. Иногда могут написать пару фраз, вроде «должно быть готово завтра» или даже вчера. Но основное обсуждение происходит в ходе созвонов.

В качестве примера – по результатам часового разговора получилось техническое задание на 5 918 символов с иллюстрациями. И сами задачи от таких заказчиков обычно на неделю-две разработки.

Лучшие технические задания в нашей практике мы получали от администраторов 1С, потому что они обладают техническими знаниями и глубоко понимают возможности программы, они ее супер-пользователи.

Единственный минус – они не могут поставить всеобъемлющую задачу. Но с ТЗ для задач на два-три дня разработки (от 8 до 24 часов) администраторы 1С очень хорошо справляются, и сотрудничество между ними и программистами в моей практике идеально.

Когда техническое задание пишут пользователи, это иногда превращается в настоящий квест. На слайде показано письмо от пользователя и мое выражение лица, когда я получил это письмо. Только после созвона стало понятно, что пользователь имел в виду.

Если ваш заказчик не только путается в постановке, но еще и вредный – дело плохо. Но если он настроен на сотрудничество – почему бы и нет. В конце концов, никто не может быть профессионалом во всем – возможно, человек отличный бухгалтер или финансист, но не разработчик.

Когда писать ТЗ

Несколько слов о том, когда хорошо бы написать ТЗ, чтобы оно хотя бы появилось.

Мы оформляли ТЗ на разных этапах: до начала работы над задачей, во время и даже после завершения задачи. На мой взгляд, не столь важно, когда именно будет написано ТЗ, гораздо важнее другое.

• Во-первых, если работа над задачей выполняется по фиксированной оценке, в оценку должны изначально закладываться риски, потому что требования могут расширяться.

• Во-вторых, после сдачи задачи заказчику с учетом всех его пожеланий, программисту стоит обновить ТЗ: зафиксировать в нем все договоренности с клиентом, включая обсуждения из чатов – хотя бы тезисно. Это поможет избежать путаницы в будущем и понять, почему решение было реализовано именно так, а не иначе.

Как писать ТЗ

Несколько слов о том, как мы в компании пишем технические задания.

• Для постановки ТЗ мы протестировали разные таск-трекеры и остановились на Redmine, которым пользуемся до сих пор. Еще в качестве эксперимента пробовали Trello – мне в нем понравилась доска: у нас старая версия Redmine и там доски нет (ее можно частично заменить сменой статусов задач, но это не так наглядно). Однако у Trello есть серьезный минус – отсутствие трек-номеров. Когда проект разрастается, карточек на доске становится слишком много, и найти среди них нужную информацию довольно сложно. В Redmine же поиск гораздо удобнее – можно искать по названию задачи, совпадению ключевых слов в описании и даже отсортировать задачи по затраченному времени (в этом случае крупные задачи оказываются наверху списка).

• В качестве разметки Redmine поддерживает Markdown. Причем раньше, когда мы начинали с ним работать, там использовался Textile. И если сравнивать эти две разметки, мне Textile нравится больше тем, что в нем есть нумерованные списки. В Textile можно поставить несколько «#» подряд, и после сохранения появится нумерованный список. А в Markdown надо писать 1, 2, 3, и если нумерация сбивается, ее нужно править вручную, что не слишком удобно.

• Для прототипирования форм мы используем конфигуратор. В нем можно за 5-10 минут накидать форму средней сложности, чтобы согласовать ее с заказчиком, и включить ее в техзадание. Это можно сделать либо в виде скриншотов и отправки черновика технического задания по почте, либо в режиме онлайн-демонстрации с тестовыми данными, чтобы это выглядело как живая система. Такой подход помогает избежать недопонимания и сразу зафиксировать требования в ТЗ.

• Мы в свое время написали генератор техзаданий, который охватывал стек Redmine, 1С, Pandoc и LaTeX. В Redmine можно делать таблички, вставлять картинки, делать нумерованные и многоуровневые списки. По нажатию кнопки в Redmine происходит запрос к веб-сервису в 1С, и генерируется файл PDF – либо техническое задание, либо заявка на разработку. Т.е. размеченный текст из Redmine перегружается в виде Textile в Pandoc конвертируется в LaTeX, производятся небольшие преобразования в 1С, и в итоге это превращается в документы техзаданий, которые я показывал на слайдах.

• Для больших документов вроде устава проекта, когда нужно что-то накидать предварительно, чтобы обсудить с кем-то онлайн, на помощь приходят редакторы, в которых печатают тексты – мы пользуемся Google Docs.

• А для централизованного хранения технических заданий мы используем Redmine. Там же можно организовать Вики, вставляя в нее описание из задач с помощью специальной языковой конструкции.

• Кроме того, мы пишем в Redmine специальные дополнения для разработчиков. Если задача поступает не старшему разработчику, а мидлу или джуну, мы пишем подстрочник – информацию, где можно уточнить некоторые моменты, используя ключевое слово collapse. Когда человек открывает задачу, у него такие комментарии в Redmine свернуты – он может развернуть и прочитать, что там написано. А при генерации финального ТЗ один из парсеров автоматически удаляет эти комментарии для разработчиков, чтобы заказчик их не увидел.

В качестве заключения скажу, что лучше все же писать технические задания. Если хотите, называйте их функциональными требованиями, но надо где-то их писать. Потом они пригодятся.

Вопросы и ответы

Вы сказали, что актуализацией ТЗ по завершению задачи занимается разработчик. Почему разработчик, а не аналитик?

Если со стороны заказчика нет аналитиков, например, задачу поставил пользователь или топ-менеджмент, то за документацию по задаче отвечает исполнитель. Так как у нас в компании только разработчики, то они и отвечают за актуализацию.

Если у заказчика есть аналитик, то схема другая: разработчик садится с аналитиком, показывает, что он сделал, а тот потом уже доделывает.

Своих аналитиков у нас в компании нет.

Если аналитик пишет техническое задание, должен ли он опускаться до описания метаданных, реквизитов, ресурсов, измерений или это на усмотрение программиста?

Если аналитик обладает знаниями в разработке 1С (например, проходил профильные курсы или имеет опыт программирования), то почему бы и нет. Если аналитик понимает, о чем пишет, и ему важно спроектировать это именно так, он может опускаться до такого уровня.

Но если аналитик настаивает на конкретной реализации, то программист над этим уже не думает. Например, если аналитик написал, что в регистре накопления должны быть такие-то измерения, программист даже не подумал, кинул их в таком порядке. А потом оказывается, что в запросе это работает неэффективно. Кто будет нести ответственность – программист или аналитик?

При грамотном взаимодействии внутри команды аналитик может предлагать свое видение, обсуждать его с разработчиком, а затем фиксировать финальное решение в ТЗ. Но если аналитик работает со стороны заказчика, а программист – со стороны исполнителя, в вопросах проектирования и ответственности за итоговый результат могут возникнуть разногласия.

Стоит ли в техническом задании объединять функциональные требования для заказчика и технические детали для разработчика, чтобы упростить работу методолога, особенно в условиях, что подписантом этого документа является заказчик? Или лучше разделять эти части и расписать их более детально?

Если со стороны заказчика техническое задание будут читать не только бизнес-пользователи, но и ИТ-специалисты, включение в него технических деталей может быть полезным.

Например, если у заказчика есть свой ИТ-отдел, который не справляется с объемом задач и привлекает вас как подрядчика, логично зафиксировать технические предложения. Это поможет избежать доработок в будущем и обеспечит более прозрачное взаимодействие. Если техническая часть пройдет ревью со стороны специалистов заказчика, объединение функциональных и технических требований в одно документе вполне оправдано.

Однако, если ТЗ предназначено для управленцев, которые не знакомы с техническими нюансами (например, не знают, что такое регистр накопления), углубляться в технические детали бессмысленно – информация все равно будет проигнорирована. В таких случаях лучше ограничиться функциональными требованиями, а технические аспекты вынести в отдельный документ или внутреннюю документацию.

При необходимости можно уточнить у заказчика, какие детали стоит включить в ТЗ. Однако важно учитывать, что пользователи нередко осознают свои реальные потребности только после начала работы с новым функционалом. Поэтому детально описывать технические решения до их реализации имеет смысл только в том случае, если это действительно необходимо для понимания проекта. До реализации конкретных технических решений описывать их в ТЗ для заказчика бессмысленно. Это только запутает всех.

Как вы относитесь к контрольным примерам в спецификациях? Например, если в отчете должна получиться конкретная сумма, логично привести пример и показать, как рассчитывается значение. Но это занимает время, и не все готовы детально описывать процесс. Насколько часто вы используете такие контрольные примеры в своих ТЗ?

В нашей практике попадались заказчики, которые не могут или не хотят согласовывать требования оперативно, в ходе диалога. Они предпочитают взаимодействовать с нами асинхронно и могут изучать ТЗ в течение недели или месяца. В этом случае нет ничего лучше, чем сделать прототип за них. Либо попросить, чтобы они прислали свой прототип – часто заказчики уже ведут нужные отчеты в Excel, и можно попросить их прислать существующий вариант, проанализировать его и зафиксировать ключевые моменты в ТЗ.

Но подобные отчеты могут оказаться не приспособлены для реализации средствами СКД. В таких случаях мы в рамках технического задания за 2-3 часа воссоздавали отчет в Excel, поскольку задача может и не «выстрелить». Просто делали нужное количество группировок – по контрагентам, номенклатуре, документам «Отчет по продажам» – и проверяли, чтобы все цифры сходились. Чтобы заказчик, посмотрев на этот отчет, сказал – это то, что он хочет, или нужны доработки.

Поэтому нет ничего лучше, чем сделать наглядный пример, который поймут обе стороны. Если у вас в согласовании задачи участвуют 3 человека – заказчик, аналитик и программист, то в итоге все трое должны друг друга понять.

А когда программисту спускается какая-то задача, и нужно более подробное описание, то есть 2 способа.

• Если подготовка примеров занимает у вас много времени, стоит заранее объяснить заказчику, что написание ТЗ должно превышать 4-8 часов. Если требуется больше, это время должно оплачиваться дополнительно – бесплатно работать никто не будет.

• Выкручиваться за счет завышения оценки других задач. Но это рискованный путь, поскольку заказчик может в итоге остаться недоволен.

Программа и методика контрольных испытаний важны для больших проектов, а я больше говорю о позадачном выполнении проекта – например, о поддержке уже готовых систем либо о внедрении через небольшие хорошо декомпозированные таски.

Но в целом я не вижу ничего плохого в том, чтобы добавлять это в ТЗ. Другой вопрос, если начинаются споры по их оплате – тут уже на ваше усмотрение, как это тарифицировать.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.