ТЗ как обязательный атрибут в автоматизации. Реальные кейсы из 16-ти летнего опыта

Тема моего доклада – техническое задание как обязательный атрибут в автоматизации. Мы разберем реальные кейсы из моей 16-летней проектной практики.

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

О себе

• Я руковожу консалтинговым направлением в группе компаний СофтБаланс.

• В проектной деятельности я более 16 лет.

• Начинала с московского франчайзи, потом работала в фирме «1С», в «Учебном центре №3», и даже проводила сертификацию преподавателей ЦСО по бухгалтерскому учету в 1С – принимала экзамены.

• В декабре 2020 года я запустила первую онлайн-школу бизнес-архитекторов, потому что на текущий момент, к сожалению, никто не дает для архитекторов 1С совокупных знаний, которые можно было бы освоить за 6 месяцев. Из-за этого, к сожалению (или к счастью), очень многие специалисты в сфере 1С вырастают «кустарным методом».

• Также я являюсь профессиональным корпоративным спикером.

Но в первую очередь, конечно, я руководитель отдела консалтингового направления в группе компаний СофтБаланс. В моей команде 25 человек, мы растем, и в ближайшее время я ожидаю пополнения своей команды.

В поисках универсального подхода

Вкратце расскажу про свой 16-летний опыт.

Начинала я как консультант горячей линии. Будучи по натуре аналитиком, я не могу не анализировать всю информацию, которая ко мне приходит. И все 16 лет я искала этот «философский камень» написания технического задания.

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

Когда я уже работала бизнес-архитектором, я знала всех программистов у нас в компании. У нас, как и во многих других франчайзи, есть пул абсолютно разных специалистов, каждого из которых я могла подключить на проект. Я знала их всех наизусть – знала все нюансы и подходы, знала, какого программиста надо 2-3 раза проверить, а кого проверять не надо и можно даже попросить ещё кое-что сделать. Это было очень забавно, как какая-то игра.

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

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

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

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

ТЗ: для кого и для чего

Давайте разберемся, для кого и для чего нужно техническое задание, на чем оно базируется, на что нужно обратить внимание?

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

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

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

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

Поэтому ТЗ – это инструмент управления рисками. И в принципе любая документация на проекте нужна для снижения рисков.

Остановимся на некоторых моментах подробнее.

Хочу начать с цитаты моего коллеги, технического руководителя Олега Олейниченко.

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

Получается, что аналитик – это некий «универсальный солдат»: ему нужно донести информацию и до заказчика, и до программиста, и дать оценку руководителю проекта.

А со своей стороны мы, руководители проектов, руководители направлений и отделов, должны обеспечивать аналитиков нужной информацией.

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

Ключевые положения регламента по составлению ТЗ

Все требования, которые формирует аналитик, должны подчиняться трем ключевым правилам:

• быть понятными;

• конкретными;

• и тестируемыми.

Кейс №1: когда ТЗ не нужно

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

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

Сюда можно отнести задачу уровня «добавить новый реквизит с типом Строка в документ Реализация товаров и услуг». Правда, исходя из моего опыта, мне в этой постановке не хватает длины этой строки, понимания, многострочная строка или нет и т.д. Поэтому, в зависимости от того, кому вы даете эту задачу – опытному или начинающему программисту – уточнения все-таки могут потребоваться. Но если мы знаем уровень разработчика, который будет делать эту задачу, мы понимаем, как с этим работать.

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

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

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

Паспорт проекта можно вести в СППР – не все эту систему используют, но у всех, кто работает с 1С, к СППР есть доступ. Что бы ни говорили о сложности СППР, в ней, как минимум, можно фиксировать требования и вести паспорт проекта.

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

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

Еще ТЗ не нужно, когда важна скорость проверки гипотез. Здесь клиент просто не согласится на длительное согласование ТЗ, ему нужна скорость – нужно проверить одну, вторую, третью гипотезу.

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

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

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

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

Вам в этом плане поможет совокупность «техническое задание – система учета задач – паспорт проекта». Если эти три инструмента работают в связке, они вам дальше помогут.

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

Кейс №2: не решайте за программиста

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

У меня был случай, когда я, будучи еще простым аналитиком, готовила для проекта концептуальную модель и задала своему руководителю проекта вопрос: «Кто из программистов будет это разрабатывать?». На что руководитель проекта сказал, что меня это не должно волновать, это вопрос будущего – когда начнется разработка, тогда и станет ясно.

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

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

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

Я помню свое негодование, когда программист сделал все не по моему ТЗ и, не спрашивая меня, перевел допреквизит во встроенный реквизит.

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

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

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

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

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

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

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

Кейс №3: ТЗ – совместный труд аналитика и программиста

Давайте посмотрим еще один кейс, который доказывает, что ТЗ – это совместный труд аналитика и программиста.

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

Аналитик пишет техническое задание, базирует на этом документе отчет.

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

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

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

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

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

Поэтому ТЗ – это труд совместный. Нужно взаимодействовать.

Кейсы №4, 5, 6. Описывайте реквизиты, визуализируйте диалоговые окна и печатные формы

В ТЗ рекомендую оформлять реквизиты в виде таблицы. Это очень важно.

Обязательно визуализируйте формы.

Это можно делать в Excel.

Или в 1С Maker.

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

Сценарии тестирования

И, наконец, сценарии тестирования. Это – то, что поможет программистам. Если у вас есть сценарии тестирования, программист сможет проверить, как с этим работать.

В сценариях тестирования нужно обязательно определять:

• входящие данные;

• ожидаемый результат, который считается «хорошим».

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

Сценариев тестирования может быть достаточно много.

На слайде показан маленький пример.

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

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

Дополнительные рекомендации для работы со сценариями тестирования:

• если есть расчетные цифры, нужно давать конкретные расчетные данные;

• если есть вариативность получения результата, пишите в сценарии все варианты;

• идеально, если в базу будут заведены данные, на которых нужно тестировать.

Итоги

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

Хотя вначале заказчику кажется, что техническое задание – это неоправданно дорого, в итоге он видит, как сокращено время. И, если руководитель проекта умеет донести до заказчика ценность технического задания, то вам, аналитикам и программистам, будет удобно с этим работать.

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

Вопросы

Дайте определение, что такое ТЗ с вашей точки зрения, и что такое паспорт проекта, о котором вы упоминали. Потому что разные люди вкладывают в эти понятия разные вещи.

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

А как соотносятся понятия «паспорт проекта» и «устав проекта»?

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

Учитывается ли длина жизненного цикла информационной системы при определении нужности ТЗ? При добавлении одного реквизита или для систем с коротким жизненным циклом ТЗ действительно не нужно. А если жизненный цикл системы больше 20-40 лет, лучше писать ТЗ или вносить изменения в существующее ТЗ и вести историю изменений?

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

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

В любом случае, эффективна связка трех подходов: «ТЗ – система учета задач – паспорт проекта».

Например, мы в команде для этого используем систему учета задач – заводим задачу, где четко видно, что и как. И параллельно в системе техпроекта мы фиксируем, что был добавлен такой-то реквизит, такая-то роль по требованию из Redmine под номером таким-то. Связка сохраняется, и через 40 лет информация будет актуальна.

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

Можно и нужно. Мы это делаем, и у нас это получается. Я горжусь, что мы пришли к регламенту, где совместили эти практики. Но опять же это из моего опыта.

Допустим, мы написали ТЗ, все согласовали, заказчику дается конечный продукт, а он говорит, что хотел другое, и ему неважно, что так написано в ТЗ. Ему нужно, чтобы работало так, как он хочет, а не так, как написано. Что в такой ситуации делать?

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

Я обычно говорю так: если клиент что-то хочет, мы всегда соглашаемся, но… И в это «но» мы уже дописываем все, что нужно. А дальше уже все решает мастерство руководителя проекта – переговорные моменты и т.д.

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

Есть ли какой-то стандарт по написанию ТЗ или «что хочу, то пишу, я руководитель проекта, мне виднее»?

Представители 1С знакомы и с технологией корпоративного внедрения, и с технологией быстрых результатов, и т.д. Загляните в Профкейс, если никогда этого не делали.

Я уверяю, что многие аналитики даже не знают, что такие материалы есть в Профкейсе, это то, что рекомендует сама фирма «1С» – вы как сотрудники фирмы-франчайзи имеете право на эти документы посмотреть.

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

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

Поэтому есть общие какие-то моменты, на что нужно обращать внимание, есть регламент системы менеджмента качества (СМК), который спускает вендор. А дальше уже все решают ваш опыт, творчество и умение творить чудеса.

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Сбор требований и составление ТЗ: современные подходы в управлении проектами".