Как писать тз: инструкция по составлению грамотного техзадания

Введение

Запрос и имеющиеся наработки

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

Были уже различные наработки и решения:

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

АРМ Начальника производства и АРМ Рабочего цеха для 1С:УНФ. Цифровое производство малого и среднего бизнеса

Расширение для 1С:УНФ с комплектом из двух АРМ: «АРМ для начальника производства» и «АРМ для рабочего цеха». «АРМ Начальника производства» позволяет анализировать общую картину состояния заказов покупателей и наличие конечных комплектующих и сырья для производства заказанной продукции. Есть возможность направлять заказы в производственную работу (в случае, если заказанную продукцию нужно произвести), резервировать и отгружать готовую продукцию. «АРМ рабочего цеха» позволяет обычным работникам оперативно закрывать производственные задания (оформлять документы выпуска) сразу в программе 1С.

14400 руб.

74

Шаг 2 — работа с посадочными страницами: анализ текстового контента, title и мета-тегов

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

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

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

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

Если же размещенный на странице текст просто требует некоторой корректировки, то в ТЗ это указываю и выделяю красным цветом проведенные изменения:

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

Далее, разобравшись с текстовым контентом страницы, перехожу к анализу description и keywords. Если они нуждаются в корректировке, в техническом задании прописываю их новые варианты (см. скриншот ниже):

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

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

5 ошибок в составлении ТЗ: как не надо делать

Ошибки	Пояснения
Некорректные требования	К примеру, вы написали, что объем текста 3 000 символов, при этом не указали, с пробелами или без них. В такой ситуации копирайтер либо задаст вопрос, либо будет действовать на свое усмотрение.
Четкое значение вместо интервала	Написать статью ровно на 2 000 знаков проблематично и, по сути, отклонение даже на 1 символ будет считаться отклонением от ТЗ.
Субъективные требования	Задачу написать «позитивный и красочный текст» каждый исполнитель может понять по-своему.
Неполное ТЗ	Если вы не укажите план статьи или необходимые ключевые слова – это будет вашей ошибкой. В такой ситуации потребовать от автора доработки после сдачи результата не получится.
Устное ТЗ	По сути, его отсутствие.

Как должно выглядеть ТЗ

Обратите внимание, что мы описываем структуру ТЗ по нашему шаблону. Наше ТЗ — гибрид из стандарта по ГОСТу и собственных предпочтений

Можно сказать, что этот шаблон — тот документ, который мы видим у “идеального” заказчика. По нашему мнению, такая структура ТЗ максимально удобна для описания системы, и поверьте, технических заданий за 10 лет работы мы видели не малое количество…

Документ состоит из основных разделов:

• общие сведения,
• назначение и цели создания,
• требования к системе в целом,
• функциональные требования,
• виды, состав, объем и методы испытаний системы,
• общие требования к приёмке,
• статус приемочной комиссии;

Немного о подходе к исследованию бизнес-процессов

НСИ со своими физическими и виртуальными свойствами описан

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

Немного теории про исследования.

Прямой метод

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

Обратный метод

Особенностью метода являетсяизучение результата операции(бумажного или электронного документа, файла или события) и поиском автора документа. Далее определяется кто и зачем сформулировал эту потребность. Цикл этих действий определяет БП в обратном порядке. Например, конечным пунктом деятельности по продаже продукции является передача водителю заказчика «Универсального передаточного документа» , ТТН, Материального пропуска. 

Типы требований

Принято выделять четыре категории:

Бизнес-требования

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

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

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

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

Пользовательские требования

Если бизнес-требования должны отражать потребности бизнеса, то пользовательские  — потребности пользователей системы. Иными словами, пользовательские требования — это задачи, которые определенные классы пользователей должны иметь возможность выполнять в системе (например, «регистрация на обучающий курс», «бронирование отеля» и т.д.).

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

Функциональные требования

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

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

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

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

Требования к программному обеспечению.

3.1. Требования к программному обеспечению в целом.

В этом пункте необходимо указать:

— режим работы программного обеспечения и использующий его персонал (24*7, 8*5 и т.д.),

— порядок обучения персонала (необходимо разработать инструкции, памятки и т.п),

— если требуется дополнительная защита информации или ограничение прав доступа,

В этом пункте можно дополнительно указать:

— специальные требования на усмотрение Заказчика или застройщика.

3.2. Требования к функциям (задачам), выполняемым программным обеспечением.

В этом пункте необходимо указать:

— список функций, задач для автоматизации,

— необходимость создания дополнительных групп, ролей,

— форма представления выходной информации и ее характеристики,

— реакция программного обеспечения на некорректные действия пользователя,

— общая схема работы программного обеспечения,

— необходимость использования текущих справочников Компании.

3.3. Порядок приемки.

В этом разделе вы можете указать:

— график и методология тестирования программного обеспечения,

— группа для тестирования,

— место и способы размещения готовой документации.

ПРИМЕР

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ/СОВЕРШЕНСТВОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1. Общие сведения.

Название программы: 1С:УПП

Наименование подразделения Заказчика: Отдел закупок и логистики

Тип задачи: Разработка

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

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

2. Экономическое обоснование.

Сокращение времени формирования отчета

Должность	Среднее ручное формирование отчетов (мес.)	Среднее ручное формирование отчетов (год), шт.	Минимальное время ручного формирования отчета, мин.	Максимальное время ручного формирования отчета, мин.	Среднее время задержки ручного формирования отчета, мин.	Среднее время задержки автоматического формирования отчета, мин.	Экономия времени на формирование отчета, мин.	Экономия времени генерации всех отчетов (за год), час.
Сокращение времени формирования отчета	70	840	тридцать	Четыре пять	37,5	10	27,5	525,00

PSE (сумма) = 525 / 1970 = 0,266

По отчетности в среднем 2 раза в день

3.1. Требования к программному обеспечению в целом.

Режим работы программного обеспечения и персонала, использующего его: 24*7

Порядок обучения персонала (необходимо разработать инструкции, памятки и т.п.): требуется разработать инструкции для пользователя по работе с функционалом

Требуется ли дополнительная защита информации или ограничение прав доступа? Юр отдел или назначенное им лицо и только для привязки номера к сотруднику в его зоне ответственности

3.2. Требования к функциям (задачам), выполняемым программным обеспечением.

Документ телефонной книги

Вывести в виде отчета список «Активных» номеров с указанием ФИО, должности и электронной почты (при наличии сотрудника на карточке). Отображаются только записи номерных карточек с выбранным полем «Показать в справочнике номеров». Доступ: Доступен для всех.

Образец:

Полное имя	Телефонный номер	Позиция	Электронная почта (если есть)
Полное имя	Телефонный номер	Позиция	Электронная почта (если есть)

Что нужно:

1. Сохраняйте/обновляйте загруженные ежемесячные данные о потреблении со ссылкой на номер (или код номерной карты) автоматически при загрузке/изменении/планировании.
2. Сохранять рассчитанный баланс с привязкой к номеру (или номеру кода карты) автоматически при списании/обмене/постинге.
3. Сохраните данные из пунктов 1 и 2 со ссылкой на ФИО/код сотрудника. При удалении сотрудника из системы 1С имя сотрудника сохраняется в реестре (на усмотрение программиста).

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

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

3.3. Порядок приемки.

Тестируемая группа: Функциональные испытания будет проводить сотрудник розничной торговли Иванов И.И.

Место и способы размещения подготовленной документации: Документация должна быть предоставлена ​​в ЭПС ведущему специалисту по закупкам Иванову И.И., а также должна быть размещена в Слиянии в разделе Инструкции

План работ Функционального моделирования 1С: ERP

Результатом работ первого этапа работ является документ «Функциональное моделирование бизнес-процессов продаж и производства металлических дверей и их материального обеспечения в программе 1С: ERP» со следующим содержанием:

• Описание бизнес-процессов продаж по модели «Как надо» (список моделируемых процессов продаж, блок-схема(-ы) с применением объектов системы 1С: ERP).
• Построение архитектуры нормативно-справочной информации (номенклатуры, характеристик, спецификаций, в т.ч. параметрических, дополнительных свойств), описание назначения используемых объектов в подсистеме продаж 1С ERP.
• Разработка механизма плановой себестоимости с включением накладных расходов.
• Ценообразование производимой продукции
• Формирование плана продаж в 1С: ERP
• Описание бизнес-процессов обеспечения материалов по модели «Как надо» (список моделируемых процессов, блок-схема с применением объектов системы 1С: ERP).
• Формирование плана закупок и резервирования материалов
• Описание бизнес-процессов планирования производства и отражения выпуска по модели «Как надо» (список моделируемых процессов, блок-схема с применением объектов системы 1С ERP) в исполнении:
  • производство без заказов,
  • производство по этапам (одноэтапное/многоэтапное),
  • пооперационное планирование,
  • пооперационное MES планирование.
• Описание производственных мощностей – видов рабочих центров (ВРЦ) и рабочих центров (РЦ).
• Формирование плана производства по ВРЦ и РЦ по разным производственным моделям (точно в срок, равномерно, минимальное количество переналадок) в 1С: ERP.
• Описание структуры цеховой автоматизации. Изучение вопроса разработки автоматизированных рабочих мест (АРМ) в цехе.
• Учёт трудозатрат выпуска продукции 1С: ERP
• Расчет фактической себестоимости в 1С: ERP
• План-фактный анализ себестоимости в 1С: ERP

Длительность по договору — 3 месяца, а по факту составила 4 месяца с регулярными командировками. Отклонение было адекватным и связано с классическими причинами — где-то требуется дополнительно проработать, осознать, согласовать. Как Заказчику, так и Исполнителю.

С целью минимизации риска сторон ФМ разбили на 2 этапа с авансовым платежом и конечным расчетом по каждому из этапов. 

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

Особенности проектного управления в основе опускаю — там всё по классике — устав проекта, периодические отчеты по состоянию проекта, различные протоколы. Пример протокола демонстрации функционала в части приёмо-сдаточных работ

Польза ТЗ для разработчика чат-бота

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

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

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

1. Главная
2. Общее
3. Как правильно составить ТЗ для разработчиков чат-бота?

Полезные материалы

Как чат-боты обучают и проверяют знания

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

10 маркетинговых KPI для бота, о которых следует заботиться

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

Как зарабатывать на создании чат-ботов?

Подробно расскажем о самых распространенных вариантов заработка на чат-ботах. Смотрите, какой из вариантов подойдет вам в зависимости от навыков и предрасположенностей.

Типичные ошибки при проектировании чат-ботов самостоятельно

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

Узнайте про контент, поддержку, рассылки, тупиковые ветки и многое другое.

Чатботы для онлайн-школы: чем полезны и как настроить

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

Чат-боты для обучения и проверки знаний

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

Чат-боты в здравоохранении: ТОП вариантов использования

За последнее время возможности и качество медицинских услуг возросли

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

Интерактивные проекты и чатботы: воплощение желаний пользователей в жизнь

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

Эффективный чат-бот лендинг

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

Что такое чат-боты и как их использовать?

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

ТОП полезных ботов и сервисов для телеграмм каналов и групп

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

Бизнес боты. Использовать или нет?

Бизнес боты. Использовать или нет? Какие задачи можно решить с их помощью? Какие чат-боты стоит использовать именно в вашем бизнесе?

165

Сэкономьте время на самостоятельном создании ботов

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

×

Шаг 1 — разбиваем список запросов по посадочным страницам

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

Итак, у меня получается таблица, состоящая из таких колонок:

Поисковый запрос

Частота по (указываете ПС и регион)

Позиция на (указываете дату)

Текущая страница в выдаче

Рекомендуемая посадочная страница

Заполняю таблицу полученными данными. Пустой остается только колонка «Рекомендуемая посадочная страница», поскольку их только предстоит выбрать.

Далее провожу анализ:

• релевантна ли текущая страница тому или иному поисковому запросу;
• какие страницы в выдаче Топ-10 по тому или иному запросу — главные или внутренние. Причем этот анализ вы можете проводить как вручную, просто вбивая запрос в строку поиска, так и с помощью автоматических сервисов. Например, с помощью скрипта «»;
• есть ли пересечения сайтов в выдаче по списку высокочастотных запросов. Данный анализ необходимо проводить для того, чтобы определить, какие из ВЧ запросов можно продвигать по одной и той же странице (запросы коррелируют между собой), а какие необходимо разнести по разным (запросы взаимовытесняющие).

В результате у меня получится таблица, как на рисунке ниже:

(Картинка кликабельна)

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

Затем провожу анализ разбивки, о котором я писала выше, и получаю таблицу, которая показана на следующем скриншоте:

(Картинка кликабельна)

Для удобства я обычно разделяю блоки страниц по цвету

Также обратите внимание на пометку возле рекомендуемой страницы «Новый URL» — это означает, что для данной группы запросов на сайте нет релевантной посадочной страницы и её необходимо создать

На этом шаг 1 закончен, и мы переходим к шагу 2.

Типовые варианты планирования ИТ-процессов на 1 год и более

Рекомендации в зависимости от того, что надо улучшать:

• если текущее состояние ИТ-процессов непонятно, насколько плохо или хорошо, а точнее непонятно исходя из чего далее планировать улучшения ИТ-процессов, то лучше провести аудит ИТ-процессов.Аудит должен дать независимую оценку, адекватны ли ИТ-процессы вашей компании. Вряд ли вашей компании надо работать также четко как Google и IBM, но и регулярно терять запросы пользователей вроде бы тоже ни к чему, т.е. для каждой компании, в конкретный момент времени, есть небольшой диапазон оптимальных уровней зрелости ИТ-процессов.Осталось лишь определить, каков этот «оптимальный уровень зрелости» по каждому из основных ИТ-процессов. Вот и вся задачка.
• если обязательно нужно улучшить ИТ-процессы, спланировав их развитие на 1-3 года, но при этом остальные элементы ИТ (информационные системы, инфраструктура, управление ИТ) планировать не нужно или не получается, то можно предложить разработать стратегию улучшения ИТ-процессов.Хотя существенно лучше запланировать развитие не только ИТ-процессов, но и всех основных элементов ИТ, сделав это в рамках комплексной стратегии развития ИТ (если такой стратегии пока нет, то лучше начать с совместной с консультантами разработки ИТ-стратегии).
• если гендиректор вашей компании обеспокоен (или наоборот, воодушевлен) цифровой трансформацией бизнеса, то запланировать развитие ИТ процессов (да и всех основных элементов ИТ) можно в рамках разработки стратегии цифровой трансформации бизнеса (или его первого шага — стратегии создания единой цифровой платформы бизнеса).

А вот рекомендации в зависимости от размеров компаний:

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

Реализация адаптивного плана работ

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

3.1. Визуальное и «многомерное» техническое задание

Люди хорошо работают с визуальными образами, mind map’ами и схемами. Поэтому в своей практике мы мало пишем «плоского» текста, зато активно используем карты и образы. Рисунки и карты легко перестроить в отличие от 300-страничного документа. К тому же эти карты быстро считываются и помогают людям на проекте эффективно коммуницировать.

Для построение карты целей и нахождения кратчайшего пути до цели мы рисуем Impact Map:

Взаимодействие всех частей IT-продукта, пользовательский опыт и сценарии работы пользователя описываются в Customer Journey Map и User Story Map.

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

3.2. Циклы и пересмотры

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

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

3.3. Объем работ — не фиксированная величина

Для обеспечения гибкости в классическом проектном треугольнике нужно поменять две вещи: перестать фиксировать объем работ и начать фиксировать качество.

• Фиксация качества — т.к. направление разработки ПО всё время меняется, то архитектура и код не должны ломаться при внесении изменений. Код не должен быть хрупким. Для повышения качества кода используют практики Экстремального программирования и следят за уровнем технического долга.
• Плавающий объем работ — обычно для заказчика важны срок и цена, эти величины остаются зафиксированными. Но что конкретно мы сделаем в указанный срок? Сделаем то, что максимально приблизит заказчика к бизнес-цели, а это будет видно по картам и схемам, которые используются при планировании. Разработчикам хорошо известно, что одну и ту же задачу можно сделать бесконечным количеством способов. Например, если вывести красивый индикатор, то это займет два дня работы дизайнера, верстальщика и программиста, а если вместо него показать цифру, то это делается в пять раз быстрее. Поэтому мы часто «флексим», т.е. делаем меньше, но не ухудшаем достигаемость бизнес-цели.

3.4. Ориентация на бизнес-цель

Заказчик и исполнитель вместе ориентируются на бизнес-цель при прокладывании пути без формального технического задания:

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