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

Недавно мы рассматривали шаблоны разработки технических заданий на автоматизированные и информационные системы, а также стандарты спецификации требований к ПО. Сегодня поговорим, можно ли практике обойтись без всех этих ГОСТов, как бизнес-аналитику написать ТЗ, понятное для разработчиков, тестировщиков и Заказчика, а также при чем здесь UML с Agile.

Agile по-разгильдяйски или зачем нам ТЗ?

Российские ГОСТы по разработке ТЗ (уже недействующий 34.602-89 и  заменивший его с 01.01.2022 ГОСТ 34.602-2020, что мы рассматриваем в новой статье, а также 19.201-78), а также зарубежные стандарты спецификации требований к ПО (ISO IEEE 29148-2018 и IEEE 830-1998), которые мы разбирали здесь – отличные шаблоны для составления технического задания, знать которые должен каждый аналитик. Однако, содержание любого предмета важнее его формы, поэтому давайте абстрагируемся от строгих рекомендаций и вспомним, зачем вообще нужно ТЗ и как его написать с максимальной пользой. Для этого ответим на 3 простых вопроса:

• зачем нужен этот документ;
• кто и для чего будет использовать изложенную в ТЗ информацию;
• есть ли в проекте жесткие правила и ограничения насчет структуры и содержания ТЗ.

Хотя ответ на первый вопрос может с первого взгляда казаться очевидным, все не так просто. К сожалению, на практике часто бывает, что ТЗ на продукт разрабатывается уже ПОСЛЕ его реализации в каком-то виде и нужно только в качестве обязательной части комплекта проектной документации, чтобы Заказчик и Исполнитель подписали договоры и акты выполненных работ. Другой вариант этого нежелательного кейса – так называемое «ТЗ для галочки», когда структура технического задания на разработку АС/ПО/ИС полностью соответствует стандарту, например, ГОСТ 34.602-89 или 19.201-78, но содержание написано общими фразами и не содержит полного набора функциональных и нефункциональных требований к будущему продукту.

В обоих случаях команда реализации рискует сорвать сроки и/или поставить результат, не соответствующий ожиданиям Заказчика. Поэтому важна не форма представления ТЗ, а полнота его содержания, обеспечивающая возможность создать работающий продукт, решающий проблемы бизнеса. Но не стоит ожидать от бизнеса четкого формулирования его пожеланий в виде готовых требований к продукту и тем более, документированного ТЗ. Определение требований и написание технического задания – это работа профессионального аналитика, которая требует определенных знаний и навыков, а также занимает массу времени. Поэтому опытный разработчик первым делом спрашивает у Заказчика ТЗ и не поддается провокациям типа: «У нас все по Agile, сейчас я на словах быстренько расскажу, что нужно». Однако, ТЗ необходимо не только для разработчика и Заказчика, этот документ читают и другие участники команды, о чем мы поговорим далее.

Для кого аналитик пишет техническое задание?

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

• Заказчик – стейкхолдеры со стороны бизнеса, проблемы которого должен решить продукт с помощью его функциональных возможностей в заданных условиях его использования;
• Разработчик – к этой роли можно отнести как непосредственно программиста, пишущего программный код, так и архитектора ИТ-решения, а также тим/техлида и DevOps-инженера, т.е. всех непосредственных участников процесса реализации заявленных в ТЗ требований;
• Тестировщик – который проверяет, что результат соответствует заявленным ожиданиям, трассируя требования в набор тестов;
• Руководитель проекта – отвечая за бюджет и сроки поставки продукта, project manager должен понимать объем работы, который следует из контекста и набора требований к создаваемому продукту.

Несмотря на такой «разношерстный» состав читателей ТЗ, оно создается с единой для всех целью: описать, ЧТО должна делать проектируемая система, а не КАК (каким образом). А описание в ТЗ ограничений, зависимостей, экранных форм, а также доменных сущностей и взаимоотношений позволяет показать это точнее и понятнее. Помните, что техническое задание – это, прежде всего, набор однозначных и проверяемых требований к продукту, а НЕ план проекта, НЕ бизнес-кейс с технико-экономическим обоснованием разработки для инвесторов и НЕ проектное решение (пошаговое руководство для разработчиков).

Можно ли написать ТЗ не по стандартам?

Как уже было отмечено, все российские и международные стандарты по разработке ТЗ и спецификации требований – это всего лишь шаблоны для создания документа «техническое задание». Поэтому, если вы не работает с госзаказчиками и нет необходимости четко следовать структуре и содержанию этих ГОСТ’ов, а ТЗ нужно для единого понимания требований к продукту у бизнеса и исполнителей, можно разработать этот документ самостоятельно. Например, я предлагаю вам следующую рабочую структуру ТЗ на основе SRS по ISO IEEE 29148-2018, исключив некоторые пункты, предписываемые стандартом. Курсивом отмечены мои комментарии по включению в данный документ иллюстраций в виде UML-диаграмм и экранных форм.

• Введение
  • Краткое описание – зачем и кому нужен продукт, какие бизнес-задачи и проблемы он решает, т.е. каковы бизнес-требования с плановыми целями и показателями их достижения
  • Термины и сокращения
  • Категории и характеристики пользователей и их потребности относительно продукта, т.е. требования стейкхолдеров, которые можно наглядно показать в виде UML-диаграммы use case
  • Ограничения, бизнес-правила и стандарты
• Функциональные требования
  • Функциональные требования – по каждому требованию:
    • Название и кодировка
    • Приоритет и трассировка с другими требованиями и/или бизнес-правилами
    • Детальное представление в виде вариантов (сценариев) использования, так называемых юз-кейсов (use case) с возможными иллюстрациями основных и альтернативных потоков, например, в виде UML-диаграммы деятельности, BPMN или EPC-схемы бизнес-процесса. Также здесь можно показать экранные формы, доступные для актора в данном варианте использования.
    • форматы и объем входных и выходных данных (результатов выполнения функции) – может входить в пункт Результат в описании вариантов использования
  • Системные (архитектурные) требования
    • Доменные сущности и связи между ними, что можно показать в виде UML-диаграммы классов или ER-схемы, описывающей таблицы базы данных
    • Среда развертывания (программное и аппаратное обеспечение, например, операционная система ПК или мобильного телефона) – можно показать с помощью UML-диаграммы развертывания и компонентов
    • Внешние компоненты (СУБД, браузер, сетевые подключения и пр.)
    • Программные интерфейсы
    • Интерфейсы оборудования
    • Интерфейсы связи и коммуникации
  • Нефункциональные требования
    • Производительность
    • Надежность и доступность
    • Информационная безопасность и сохранность данных
    • Удобство использования (пользовательские интерфейсы)
  • Прочие требования
    • К интеллектуальной собственности (патентная чистота)
    • Требования к документации

Предложенную структуру можно дополнять и изменять по своему усмотрению. Например, добавить RACI и CRUDL-матрицы или включить в состав нефункциональных требований некоторые характеристики качества ПО, регламентированные стандартом ГОСТ Р ИСО/МЭК 25010-2015 «Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов» (ISO/IEC 25010:2011). О том, что такое нефункциональные требования и чем, например, надежность отличается от доступности, а также как измерить удобство пользовательского интерфейса, мы поговорим в следующий раз, а сейчас предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях.

Требования и ТЗ: открытый тест по российским и зарубежным стандартам

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

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

Пишем спецификации. часть 1. инструменты — начинаем с простого

(не)полнота

Согласно Гёделю, нет никакого смысла стремиться к полной спецификации. Любая полная спецификация противоречива. Так что надо смириться с тем, что любая спецификация будет неполна. Максимум, на что можно надеяться, это на непротиворечивость.

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

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

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

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

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

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

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

Добби свободен! О мнимых рамках при анализе

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

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

Согласна, эту фразу было довольно скучно читать. И это довольно узкое поле для творчества, не так ли? Тем не менее, творчество здесь присутствует, и ограничения могут послужить стимулом разработать весьма причудливые и при этом работающие механизмы!

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

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

Как это работает в Туту: В рамках работы над каждой задачей мы обсуждаем возможные решения с командой, тимлидами и владельцем продукта (он же Product Owner, он же ПО), которые поощряют креативные идеи, даже если в итоге в разработку попадает наиболее простой вариант из предложенных.

Об анализе после анализа

Говоря о разных фреймворках и моделях процесса разработки программного обеспечения — таких как Waterfall, RUP и прочие, стоит помнить, что это не просто разные подходы и методики управления, это могут быть еще и принципиально разные культуры и паттерны поведения.

Например, в консалтинге весьма привычна ситуация, когда при возникновении новых немаловажных требований или новых вводных (о которых забыли — такое бывает, проекты большие) подрядчик находит письмо, в котором вы договаривались о таком-то объеме и составе работ, а новые требования не обозначались в рамках плана.

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

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

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

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

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

Гибкость против Паники

Иногда эта картинка из прошлого возникает и по сей день. Прилетает какой-то баг, и вот, нужно всё бросать, быстро за 10 минут рисовать логику и код, потом ещё 5 минут на тестирование и ещё 5 минут на установку на продакшен. А потом можно выдохнуть, если не прилетел еще один аналогичный баг.

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

И ты остаёшься с этими доработками до полуночи, до часу ночи — пока системные администраторы не доберутся до домашних компьютеров и не зальют их на продуктивную базу, и ты не напишешь пользователям позднее письмо «всё исправили, можно закрываться!». И по выходным то же самое…

Но нет. Всё же в продуктах по-настоящему блокирующие задачи, из-за которых нужно немного попаниковать, возникают весьма редко, ЕСЛИ речь не идёт о высоконагруженных продуктах, где цена простоя очень высока. В стандартной ситуации большинство багов (не утверждаю, что все) едва ли требуют решения здесь и сейчас, через одно мгновение: можно остановиться, выдохнуть, подумать о том, что и как мы правим.

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

Хотя, признаюсь вам честно: иногда срабатывает какой-то давно забытый рефлекс — вот, нужно на прод прямо сейчас, прямо через 10 минут!

Как это работает в Туту: Так как наш сервис путешествий является высоконагруженным, безусловно, у нас существует понятие «блокирующей задачи» — той, которую нужно делать прямо сейчас. Тем не менее мы стараемся провести эту задачу по всем ролям, включая аналитику и качественную проверку тестировщиком на всех необходимых стендах, разве что делаем это в более оперативном режиме.

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

Группа design time

К этой группе относятся следующие атрибуты качества:

• Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
• Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
• Требования к переносимости (Portability) приложения или системы на другие платформы.
• Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
• Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
• Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
• Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
• Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы

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

Группа runtime

К этой группе относятся следующие атрибуты качества:

• Доступность — атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
• Надежность — требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
• Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
• Масштабируемость — требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
• Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
• Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
• Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
  1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
  2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
  3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
  4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
• Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
• Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи

Детальный дизайн

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

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

Готовый дизайн таймланов в Targetprocess 3

Итак, законченный дизайн должен быть непременным атрибутом любой спецификации. Может ли дизайн заменить всю спецификацию? К сожалению, нет. Обычно в дизайне не показаны все состояния системы, не описаны потоки взаимодействий, не проработаны все сценарии. Дизайн статичен. А нам нужна динамика. Можно и в дизайне показывать динамику:

Три варианта изменения карточки требования с течением времени

Но это долго и сложно. Лишь избранные способны так скрупулезно прорабатывать варианты.

Живые прототипы

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

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

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

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

Однако для разработчика негативные сценарии крайне важны. Если разработчики не хотят о них думать, то тестировщики обожают. В результате придется терпеливо выяснять нюансы поведения системы, мучительно фиксить баги и править сообщения “You can’t do that!”.

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

Первый прототип Targetprocess 3, сделанный для проверки концепции. Показывался клиентам и вызывал общее одобрение. Кликабельно, но работает не все, что видно.

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

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

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

Как правильно сформулировать и контролировать цель проекта?

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

Метрика — измеримая характеристика проекта, продукта или процесса.Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

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

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

Критерии качественных нефункциональных требований

Как к функциональным, так и к нефункциональным требованиям применяются

критерии качества требований

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

Ниже приведены основные характеристики качественных требований.

• Полнота (отдельного требования и системы требований) — требование должно содержать всю необходимую информацию для его реализации. В него включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и не определенных требований. Причины неполноты описания следует явно объявлять.
• Однозначность — требование должно быть внутренне непротиворечиво и все работающие с ним должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
• Корректность отдельного требования и согласованность (непротиворечивость) системы требований — требование не должно содержать в себе неверной, неточной информации, а отдельные требования в системе требований не должны противоречить друг другу.
• Необходимость — требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
• Осуществимость — включаемое в спецификацию требование должно быть выполнимым при заданных ограничениях операционной среды. Осуществимость требований проверяется в процессе анализа осуществимости разработчиком. В частности, для нефункциональных требований проверяется возможность достижения указанных численных значений при существующих ограничениях.
• Проверяемость — проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно нефункциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО. Для атрибутов качества (как мы помним, отдельной разновидности нефункциональных требований) критерием проверямости можно считать наличие численных значений характеристик качества продукта или системы

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

Наброски интерфейса

Многие управляющие продуктами побаиваются ручек, а от набора цветных карандашей у них портится настроение. Они стесняются рисовать и уверены, что наброски от руки выглядят непрофессионально и недостаточно круто. Вместо карандаша они предпочитают Visio, OmniGraffle или любой другой дорогой профессиональный инструмент.

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

Набросок системы отчетов в Targetprocess 3.

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

Набросок разрешенных назначений задач на людей в зависимости от роли, проекта и команды в Targetprocess 3

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

Набросок таймлайнов в Targetprocess 3.

Я лично скетчи очень люблю.

Нарративные

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

История про Васю и Батч DnD
Вася планирует следующую итерацию. Он смотрит на доску, заполненную карточками. Слева он замечает список карточек в бэклоге. Вася читает названия юзер сторей, и понимает, что три первые стори надо обязательно сделать в следующем релизе. Вася привычно прижимает Ctrl и кликает по каждой карточке, карточки призывно желтеют в ответ. Вася хватает первую карточку и начинает тащить ее в правую колонку. Карточки красиво складываются в одну, увенчанную эффектной цифрой 3 в правом углу. Вася перемещает карточки в нужную колонку, но пока еще не отпускает их, наслаждаясь тем, как колонка желтеет карточкам в ответ.

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

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

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

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

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

Нефункциональные требования: какие они бывают

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

что

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

как

должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать).

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

Примеры ограничений

: «Разработка должна вестись на платформе вендора

X

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

Примеры бизнес-правил

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

Примеры внешних интерфейсов

: «Обеспечить запись в журнал операционной системы следующих событий: сообщения о запуске и остановке сервиса

XX

»; «Обеспечить запись в журнал параметров модулей программы: сканера, ядра, антивирусных баз (информация должна заноситься в журнал при запуске программы и при обновлении модулей)»

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

Нефункциональные требования: работа над определением

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

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

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

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

1. Система получает оповещение о событии, инициирующем рассылку уведомлений.
2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.
3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.

Требования к времени оповещения о событии, инициирующем рассылку уведомлений: система должна получать оповещение не позднее чем через XX секунд после возникновения события.
Требования к времени отправки уведомлений: все уведомления должны быть отправлены не позднее YY минут после получения оповещения о событии
Требования к повторной отправке рассылки после неудачной попытки: число повторных попыток должно быть равным 10, с интервалом в 10 мин после каждой неудачной попытки отправки.

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

Раскадровки / storyboards

Раскадровки любят режиссеры. В общем-то это просто набор отдельных ключевых кадров какой-то сцены.

Типичная раскадровка к непонятному фильму.

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

Типичная быстрая раскадровка.

В нашей индустрии раскадровка — это набор отдельных состояний системы.

Раскадровки довольно компактны и позволяют понять, какие вообще состояния есть. Отличные раскадровки еще и показывают, как в эти состояния переходить.

Раскадровка быстрого добавления задач в Targetprocess 3 с альтернативным сценарием.

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

Спецификации и программисты

Многие программисты не любят спецификации. Введем определение, пусть это будут “Программисты класса 1”. Они твердо знают, как система должна работать, на какие сценарии можно выдавать сообщения “Unknown error” или “You can’t do that” и где нужно срезать углы, чтобы меньше возиться с неинтересными вещами.

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

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

Распределение программистов по типам. Большинство нормально относится к спецификациям.

Программисты класса 2 читают спецификацию от корки до корки, методично ее переваривают и задают убийственно точные вопросы.

Для программистов класса 2 можно создавать любые спецификации — они проглотят все. Программистам класса 1 можно показывать только картинки, снабженные короткими, ясными надписями без сложных слов. Еще лучше им показать мультфильм. Я хотел сказать — анимацию.

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

Спецификация = визуальное объяснение

Цель спецификации — донести идеи в максимально понятной и полной форме. Лучше всего это работает, когда используются и текст, и графика.

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

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

Все методы донесения идей в одном флаконе.

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

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

P.S. У меня в запасе осталось еще штук 20 красивых картинок, но статья и так огромная, так что извините.

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

Написать идеальное ТЗ проще простого:

1. Договорился о минимальном этапе (на 2-4 недели).
2. Описал юзер-стори по шагам.
3. Составил список экранов будущей системы.
4. Прописал названия методов API и форматы данных.
5. Запросил тестовый контент и составил таблицы с тестовыми данными.
6. Сформулировал из всего этого цели и задачи.
7. Согласовал план работ и выставил задачи в таск-менеджер.

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

Скан салфетки (Что это мы нарисовали на встречке?)

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

Лайфхак: “Как ты к этому пришел, приятель?”

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

Извращенная логика

Открываем ТЗ и видим, что бы вы думали? Портал с виртуальным кладбищем:

* поднять захоронение в топ 100;
* поделиться захоронением с другом;
* отправить захоронение на главную;
* добавить в некрополь;
* добавить захоронение в черный список;
* активировать карту вип-пользователя;
* установить антивирус;
* кастинг;
* групповые склепы со знаменитостями.

Лайфхак: “Правильно ли я вас понял?”

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

А всего-то, ему нужно услышать свои мысли немного другими словами:

— Правильно ли я понимаю, что вы хотите сделать кастинг захоронений?
— Правильно ли я понимаю, что пользователи будут выводить склепы в ТОП-100?
— Я правильно вас услышал, что пользователи будут приглашать друзей в братские могилы?
— Правильно ли я понимаю, что пользователи будут добавлять могилки в “черный список”?
— Правильно ли я понимаю, что знаменитости мечтают вписать в групповые склепы?
Т.е. вы не критикуете, не сопротивляетесь, не спорите, просто уточняете.

Все и так понятно (прочитайте мои мысли)

— Зарегистрируйся в нашей системе и стань известным и успешным.
— А что нужно делать, дальше?
— Ну вот ты зарегистрировался первый шаг уже сделан!
— ОК, а какой второй шаг?
— Ну активируй карту и подними свою анкету в топ-100.

Иии? Очень хочется услышать рецепт до конца!

Лайфхак: “А что если?”

Ха! Все было бы идеально, если бы заказчик вменяемо отвечал на заданные вопросы. Не спорю, многие отвечают, но есть и те, чьи ответы ничерта не проясняют. С ними нужно немного по-другому. Им нужно нарисовать сценарий в виде вопроса:

— А что, если пользователь зарегистрировался, активировал карту, поднял анкету, но не стал известным и успешным?

Описание математики рисунком

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

Лайфхак: “А давайте посчитаем это в XLS”

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

При этом просто попросить контрольный пример не получается. Если бы заказчик мог сделать контрольный пример, он бы его сделал и не занимался бы изобразительным искусством. Поэтому контрольный пример придется делать вам как минимум в “Экселе”. Не всегда хватает “Экселя” — возможно, потребуется MathLab или же полноценный исследовательский этап, если у вас внезапно нарисовался DSP, или 3D расчеты, или же распознавание образов с блэк-джеком и нейросетями.
Результатом этой работы должен быть набор тестов, который дает однозначные с точки зрения математики результаты.

Не грузи меня деталями

— Хотим стримить порно через приложение в AppStore.
— Но нас же заблокируют!
— Не грузи меня деталями!

— Хотим стримить по wi-fi аквалангистов с кораллового рифа
— А wi-fi работает под водой?
— Не грузи меня деталями!

— Хотим раздавать 4G wi-fi с автономного роутера, но только тем, кто зарегистрировался в нашей базе.
— То есть придется колхозить прошивку для роутера и ехать в Китай?
— Не грузи меня деталями!

— Хотим подключиться к базе общественного транспорта Москвы
— А вы уже договорились с DIT?
— Не грузи меня деталями!

Лайфхак: “Был тут один случай!”

Перед нами стратег, у которого свой vision, и ничто не способно остановить его движение к успеху! Какие-то мелкие детали (законы физики, современные технологии, политики платформ) их не волнуют — это все только для технических специалистов.

Однако способ достучаться до “негрузидетальных” заказчиков есть — это нарратив. Они вполне смогут услышать историю, про то как:

* На AppStore недавно забанили вашего дружбана за порнушку.
* Мужик на YouTube пытался заняться зимней рыбалкой с wi-fi экшн камерой, чтобы посмотреть как рыба реагирует на наживку (черт, я ведь не шучу сейчас!).
* Как другой ваш дружбан колхозил прошивку для роутера, а в Гуанчжоу его киданул гид.
* Как вы уже полтора года ждете ответа от DIT Москвы.

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

Д — Дичь! (так никто не делает)

— Давайте спарсим выдачу “Яндекса”!
— ЧТОА? Эээ… Мммм… Как? Заачееем?
— Чтобы сэкономить на поисковом движке!

— Давайте для iPhone напишем три приложения которые будут внутри iPhone друг с другом взаимодействовать!
— Заааааачеееееем???
— Для повышенной безопасности: одно будет шифровать трафик, другое будет следить за обновлениями, а третье будет чатом.

Лайфхак: “Без нас”

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

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

В целом, метод такой:

* Задать вопросы.
* Определить ценности и потребности.
* Предложить несколько альтернативных вариантов заказчику, о которых он не знал или не думал.

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

С — Схема! (как хотелось бы, но не работает)

Сэйлз выцепил клиенток из Tinder’а.

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

Лайфхак: “А все остальное идеально?”

Обычно, когда разработчики видят такое, то они цепляются за это мозгом и спорят с заказчиком. А нужно задать себе вопрос: “ОК, тут затык, а все остальное в этом проекте — идеально?”
Конечно же нет! Ведь причуды не ходят поодиночке. Выясняется, например, что: между соучередительницами не улажены юридические вопросы, они находятся в разных странах и ненавидят друг друга, какая-то несчастная команда уже начинала это пилить, теперь проект покоится на компакт-диске, который не читается, и нужно заняться полировкой царапин…
И тут вы сразу расслабляетесь, перестанете спорить и предлагаете заказчику вернуться к обсуждению после улаживания всех остальных вопросов.

Коллективное творчество (правка в правке в режиме правки, “Ворд” — в лоскуты)

Представьте себе миленькую международную компанию-гигантика. В ней ТЗ нужно согласовать со всеми департаментами. Нами предложены три варианта реализации. Ну, знаете, как в крупных компаниях говорят с подрядчиками? А вот так: “Предложите нам вариааанты!” (обязательно с оттяжечкой и “н” так в носик). Так вот, одним отделам понравился один вариант, вторым — второй, третьим — третий. И все так чатятся в режиме правки. Смогу ли я узнать ТЗ, которое получу на выходе после правок?

Лайфхак: “Жрем слона по частям”

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

У меня в почте есть 18-ая, а есть даже и 23-я версия ТЗ из 6-ти страничек. Все уже настолько задолбались, что никто уже не хочет сводить это все вместе… Нестерпимо хочется в производство!

Заключение

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

Давайте рассмотрим применение ТЗ на салфетке на реальном примере.

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

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

Заполняем левую часть дальше. Ключевой показатель – себестоимость 1 кг продукции, план-факт и отклонение. Этот KPI директору важно видеть по фабрикам, статьям затрат и в помесячной динамике – это вносим в ячейку «категории, фильтры».

Переходим к пункту «выводы»: заказчику необходимо понять, кто виноват в превышении норматива себестоимости. Статей затрат много, но они сводятся к двум группам: те, за которые отвечает сама фабрика, и те, которые формируют конечную себестоимость (маркетинг, логистика и прочие вспомогательные службы).

Что вносим в ячейку «решения»? На основе полученных данных финдиректор принимает решение, платить или нет премию директору фабрики. Если норматив себестоимости превышен, это плохо. Но если при этом фабрика уложилась в свои лимиты, то она получает свой бонус.