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

25.09.25

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

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

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

 

 

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

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

 

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

 

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

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

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

 

 

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

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

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

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

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

 

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

 

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

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

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

 

 

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

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

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

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

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

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

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

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

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

 

 

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

 

 

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

 

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

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

Инфостарт A&PM Event 2026

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

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

См. также

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

Разбираем, почему управление требованиями остается одним из ключевых факторов успеха проекта, и как ошибки на этом этапе приводят к срывам сроков, перегрузке команды и «синдрому скользящей дорожки». Показываем, как превратить сбор требований в понятный процесс: вовлекать заинтересованные стороны, использовать активное слушание, визуализацию, прототипирование и микротребования. Объясняем, как расставлять приоритеты через MoSCoW и матрицу Эйзенхауэра, визуализировать задачи в Jira на Kanban-доске и сохранять фокус даже в условиях постоянных изменений. На практическом кейсе портала кандидата показываем, как системная работа с требованиями помогает довести проект до результата и получить продукт, который не просто используют, но и любят.

28.10.2026    183    0    user1916475    1    

1

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

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

23.10.2026    312    0    jack_nsk    0    

1

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

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

02.10.2026    1232    0    romandredan    26    

11

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

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

01.10.2026    386    0    YA_826532418    0    

5

Работа с требованиями Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Каждый архитектор и руководитель 1С-проектов рано или поздно сталкивается с выбором: продолжать латать старую систему или снести всё до основания и заложить правильный фундамент. Что делать, если появились "золотые гвозди"? Когда система на "пластырях" не работает.

28.09.2026    344    0    nik-boss    2    

1

Работа с требованиями Оценка проекта Аналитик Руководитель проекта Бесплатно (free)

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

25.09.2026    575    0    YA_826532418    6    

5

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

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

25.09.2026    428    0    Rico17    3    

1

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

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

24.09.2026    302    0    YA_826532418    0    

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