Сегодня снова попался на глаза старый мем про качели - как заказчик объяснил задачу, как её понял аналитик, как реализовал программист, что в итоге внедрили и чего на самом деле хотел заказчик.

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

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

Но со временем, мы поняли одну важную штуку - даже очень хорошее ТЗ не всегда объясняет, что на самом деле нужно заказчику. Оно отвечает на вопрос "что сделать", как это видит заказчик, но не объясняет "зачем это нужно".

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

1️⃣ Контекст проекта

В рамках какой более крупной программы или проекта выполняется эта работа? Является ли она самостоятельной задачей или частью какой-то цепочки работ? Какая причина запуска этого проекта?

2️⃣ Потребность в результатах

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

3️⃣ Сроки, не описанные в проекте

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

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

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

📌 Иногда вообще выяснялось, что предложенный в ТЗ подход к решению задачи не является корректным. Тогда мы предлагали изменить методику выполнения работ или увеличить объём проекта. А иногда и наоборот - сократить его и сэкономить заказчику время и деньги.

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

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

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

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