Они с Марса, а мы – с Венеры: как научить заказчика говорить на одном с аналитиками языке?

25.09.25

Управление ИТ - Стандарты и документация

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

Меня зовут Ольга Рябая. Я системный аналитик в компании «DNS Технологии».

 

 

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

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

 

Опытно-ориентированное обучение (цикл Колба)

 

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

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

Теория опытно-ориентированного обучения основана на трудах Джона Дьюи, Льва Выготского, Жана Пиаже. Дэвид Колб обобщил их труды, подчеркнув, что нельзя просто передать знания – взрослый учится на собственном опыте. Согласно Колбу, обучение проходит через получение опыта (теоретические знания) и трансформацию опыта (понимание, интерпретацию и применение). По такому принципу мы учимся и приобретаем новые навыки.

 

 

Цикл Колба состоит из четырех этапов: личный опыт, рефлексия, теория и практика.

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

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

  • Теория. Кратко (не дольше 30-40 минут) объясняем простую тему, которую можно сразу применить.

  • Практика. Самый важный этап – применение теории на практике и связь знаний с реальными действиями.

 

Тренинг по написанию ТЗ

 

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

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

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

 

 

Этап 2. Рефлексия. Задаем вопросы:

  • Какую боль пользователя мы решаем?

  • Что, по-вашему, является главной проблемой?

  • Верно ли, что при установке флага в таблице должно что-то меняться?

  • Каковы альтернативы?

  • Галочка или тумблер?!

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

Этап 3. Теория. Обсуждаем, когда появляются плохие требования, зачем нужны хорошие и какие выгоды получает бизнес. Говорим про виды и характеристики требований. Раздаем материалы для разных типов восприятия – для чтения и прослушивания.

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

 

 

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

 

 

Закончу словами Сократа: «Знание – единственное богатство, которое увеличивается, когда его делят». Призываю вас делиться своими знаниями.

 

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

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

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Работа с требованиями Бесплатно (free)

Каким должно быть техническое задание, чтобы разработчик понял задачу так же, как аналитик, тестировщик и бизнес? Покажем, почему требованиям нужны обоснование, конкретные формулировки по SMART, единый командный контекст и визуальная опора в виде схем, макетов и глоссария. Объясним, как недосказанность, размытые формулировки и отсутствие коммуникации превращают даже хорошо оформленное ТЗ в источник ошибок. Отдельно поговорим о soft skills: регулярных встречах, синках, воркшопах и умении вовремя проговорить нюансы с исполнителями.

21.05.2026    940    0    batsy66    16    

9

Стандарты и документация 1С:Предприятие 8 1С:ERP Управление предприятием 2 Машиностроение и приборостроение Бесплатно (free)

В связи с тем, что большинство предприятий, на которых мы проводим внедрения, работают с конструкторской документацией, составили краткую справку по подготовке к внедрению «1С:ERP Управление предприятием 2».

20.05.2026    376    0    AiBCifra-1S-ERP-UH    1    

1

Стандарты и документация Бесплатно (free)

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

14.05.2026    540    8    primat    0    

2

Взгляд со стороны Заказчика Внедрение изменений Бесплатно (free)

В проектах внедрения 1С:ERP консалтеры часто призваны «поставить учет под автоматизацию», но их участие не всегда приносит пользу. Вместо практических требований интеграторы нередко получают тома методических документов, которые ничем не помогают проекту. В статье разберем причины, по которым взаимодействие с консалтерами может создавать проблемы, и приведем пример успешного опыта, когда методология реально легла в основу модели автоматизации расчета себестоимости. Проясним, что такое «методология» учета и как по-разному ее понимают консалтеры, ИТ-интеграторы и заказчики.

08.05.2026    401    0    1СERP    0    

3

Канбан и поставка ценности Взгляд со стороны Заказчика Бесплатно (free)

Почему клиенты на самом деле выбирают исполнителя и какие метрики действительно отражают их ожидания, а какие – лишь создают иллюзию контроля? Разбираемся, как определить свое положение в глазах клиентов (и почему NPS уже не дает нужной глубины), как проверить «здоровье» продукта и качество доставки ценности через дизайн, исполнение и поставку. Вы узнаете о четырех типах метрик – от критериев выбора до драйверов улучшений – и поймете, почему «метрики тщеславия» делают счастливыми компанию, но не клиента, хотя их часто ошибочно включают в KPI. В заключение сформулируем практические выводы о том, как точнее попадать в ожидания клиентов и получать от них устойчиво позитивный отклик.

07.05.2026    403    0    svartemov    2    

1

Стандарты и документация Бесплатно (free)

Безопасная конфигурация в 1С начинается с соблюдения стандартов v8std, которые определяют требования к защите серверного API, работе с внешним кодом, запуску приложений и хранению чувствительных данных. Объясняем ключевые принципы безопасной разработки: от корректного использования признака «Вызов сервера» и безопасного хранения паролей до правил запуска внешних программ, ограничения исполнения произвольного кода и работы с внешними компонентами. Подробный разбор каждого требования показывает, как минимизировать риски и создать конфигурацию, устойчивую к типовым угрозам безопасности.

07.05.2026    2042    0    zeegin    3    

22

Работа с требованиями Бесплатно (free)

Разбираемся, почему проекты разваливаются из-за требований, и показываем техники добычи скрытых потребностей заказчика – от работы с ролями до уточнения контекста. Учимся использовать инструменты визуализации от простых схем до User Story Mapping, чтобы сделать требования понятными всем участникам проекта. Показываем, как найти баланс между идеальным решением и реальной реализацией, не превращая проект в бесконечную доработку. А также приводим практический кейс, в котором корректная работа с требованиями позволила сократить бюджет проекта примерно на 30%.

24.04.2026    690    0    Бэнни    2    

4

Управление рисками Взгляд со стороны Заказчика Бесплатно (free)

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

21.04.2026    1777    0    IgorVasilyev    25    

18
Для отправки сообщения требуется регистрация/авторизация