С ТЗ или без ТЗ? Вот в чем вопрос

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

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

Причины некорректных постановок задач

Фото — Размытый снимок экрана как один из неудачных примеров постановки ТЗ

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

Фото — Для заказчика очевидно, что в этом месте ошибка, но исполнителю недостаточно этой пометки

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

Фото — Не все ошибки одинаково полезны

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

Что должно включать в себя идеальное ТЗ

1. Содержание. Перед составлением технического задания важно провести декомпозицию на разделы. При этом каждый раздел следует включать в оглавление. В пакете программного обеспечения MS Word для этого имеется специальная команда на вкладке “Ссылки”.

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

2. Список сокращений — данный пункт добавляется в ТЗ при необходимости, если есть общепринятые сокращения и, в особенности, сокращения, принятые внутри компании заказчика – такие аббревиатуры могут быть интуитивно понятны внутри самой компании заказчика, но далеко не факт, что данные сокращения будут интерпретированы “внешним миром” абсолютно так же. Кроме того, есть, так называемые, двойственные сокращения – как пример, сокращение “РС” может расшифровываться как “Регистр сведений” и как “Ресурсная спецификация”, или сокращение “МК” может быть как маршрутной картой, так и металлокомплектом (оба примера из реальной практики 5ТЕК).

3. Цель – для чего нужно делать эту доработку. Пишем не более двух-трех предложений и желательно в виде списка (1,2,3, …).

4. Краткое описание – так называемый, процесс AS IS (как работает сейчас). Кратко, без воды. Задача этого пункта – ввести постановщика в контекст происходящего.

5. Проблематика – данный пункт должен содержать краткое описание того, что в текущем процессе не устраивает постановщика задачи, где “искрит”, что хотелось бы улучшить. Пишем не более 5-6 предложений. Далее у исполнителя уже будет “замыливаться глаз”.6. Описание задачи — самый важный этап, которому стоит уделить больше всего внимания. Предыдущие пункты были направлены на подготовку исполнителя к более эффективному выполнению задания, т.к. чтобы что-то доработать, очень важно знать, как работает сейчас и какие есть недостатки в текущем процессе. Все это позволит максимально легко и эффективно “переварить” пункты из описания задачи. Грамотное описание задачи должно быть составлено так, чтобы его понял не только программист, но и бизнес-заказчик. В идеале, текст описания должен быть понятен даже тому, кто видит это ТЗ впервые.

Рекомендации для составления описания задачи

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

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

С задачей оформления скриншотов и оформления подписей и стрелочек прекрасно справляется программа Snagit (не на правах рекламы — вполне реальная практика аналитиков 5ТЕК) или даже обычные Ножницы из Windows 10 / 11. На крайний случай, подойдет даже старый добрый Paint.

в) При оформлении ТЗ следует придерживаться единого формата документа и определенных стандартов визуальной части. К примеру, на практике выявлено, что человеческий глаз лучше всего воспринимает шрифт Times New Roman, 11. Заголовки, как правило, аналитики 5ТЕК, оформляют тем же шрифтом, но на 1-2 размера больше и выделяют жирным шрифтом. Также важно делать отступы полей – каких-то жестких рекомендаций тут нет, но, как правило, отступы лучше делать в MS Word с помощью функционала “Линейка” как можно ближе к краю страницы, чтобы на одном листе вмещалось больше информации.

Фото — Удобные инструменты для форматирования документа

г) Следует избегать ситуаций, когда описание скриншота на одной странице, а сам скриншот на другой. Это существенно снижает восприятие формулировок по задаче, поскольку основная концентрация направлена в этом случае на постоянном перелистывании, а не на разборе формулировок.

Раздел P.S. Это опциальный раздел. Оформляется, когда нужно прокомментировать что-то дополнительно. Это может быть информацией для разработчика (к примеру, такой-то функционал делаем в таком-то общем модуле или расширении), или же это может быть какая-либо другая доп. информация, которую следует учесть в рамках всего ТЗ, но которая не вошла ни в один из перечисленных выше разделов в силу своей специфики.

Вы можете спросить, а дадут ли данные рекомендации 100% гарантии, что «идеальное» ТЗ полностью исключит ситуации, когда у исполнителя совсем не останется вопросов, и он тут же приступит к выполнению задачи? И мы ответим – конечно же нет! Но данные рекомендации в значительной степени минимизируют количество вопросов, а также, что еще важнее, сделают эти вопросы более предметными, более «глубокими». И, более того, даже когда формулировки предельно ясны и, на первый взгляд, ясно, что нужно делать, не будет лишним связаться с постановщиком и проговорить тезисно основные формулировки.

Это очень важный момент, которым мы крайне не рекомендуем пренебрегать. В лучшем случае исполнитель просто проговорит с заказчиком ключевые пункты и убедится, что понял ТЗ правильно. В худшем случае, если исполнитель этого не сделает, что уже после первичной демонстрации результата выяснится, что, оказывается, «нужно было сделать еще то-то, а вот это нужно было сделать не так, а вот так». А ведь всего этого могло бы и не быть, уточни исполнитель у заказчика это «на берегу», или же скажи заказчик об этом исполнителю заранее. Будет крайне обидно, не правда ли?

Как быть в ситуациях, когда ТЗ отсутствует?

Мы разобрали то, как правильно составлять ТЗ, и как важно его наличие. А как работать, если ТЗ вообще нет? Давайте разберемся.

Отсутствие технического задания (ТЗ) в разработке на платформе 1С — это ситуация, с которой сталкиваются многие разработчики и бизнес-аналитики. Хотя наличие ТЗ не является строго обязательным, оно значительно упрощает процесс разработки и обеспечивает более высокое качество конечного продукта.

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

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

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