Какие еще к черту требования?

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

“Будь у меня час, чтобы решить проблему, от которой зависела бы моя жизнь, я бы потратил 55 минут, размышляя и формулируя вопрос, а остальные 5 минут использовал бы на поиск ответа”. Цитата приписываемая Альберту Эйнштейну. 

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

И с этим трудно спорить — задачу невозможно решить, если она не ясна, то есть не сформулирована правильно. Но, что такое задача? 

No method is more effective than the good example. Ни один метод не является более эффективным, чем хороший пример. Игнвар Кампрад, основатель компании Икеа. 

Рассмотрим простейший, но наглядный пример. Предоложим, что нам требуется, чтобы ИИ написал для нас код: 

— Создай функцию, которая возвращает разницу между датами

—  fn diff<T: Date + PartialOrd>(date1: T, date2: T) -> T { …

— О, нет, я же хотел функцию на Typescript

— function diff(date1: Date, date2: Date) : Date { …

— Не годится, дат может быть больше чем две

— function diff(dates: Date[]) : Date { …

— Я хочу чтобы функция возвращала разницу в миллисекундах

— function diff(dates: Date[]) : number|null { …

— Нет, вводные даты должны быть в формате ISO8601 

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

Но что если дело касается не функции, а целого проекта? Что если его разрабатывает не ИИ, а человек? А ведь так оно обычно и происходит! Каковы тогда будут издержки на постоянную доработку? 

Чтобы не отвечать на этот вопрос нужно понять, что такое задача. 

"Создай функцию, которая возвращает разницу между датами"

Давайте подумаем, является ли это задачей? 

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

“Создай функцию на Typescript, которая принимает массив дат в формате ISO8601 и возвращает разницу между датами в миллисекундах.”

Это уже больше похоже на задачу. Разница существенная, правда? 

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

Вот как будет выглядеть контекст нашей задачи в формате технической документации: 

Цель: Создать функцию, которая возвращает разницу между датами.

Требования: 

• Использовать язык программирования Typescript

• На входе функция принимает один аргумент, типа массив строк

• Строки в массиве представляют собой даты в формате ISO8601

• Результат функции выражен числовым типом и представляет собой количество миллисекунд

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

Наконец мы приблизились к Требованиям. 

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

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

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

Однако, сбор требований не такая уж простая задача. 

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

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

В-третьих, требования должны быть простыми, понятными и достаточными (не следует терапевтировать все на свете; для того, чтобы поставить правильный диагноз, не нужно исследовать все тело).

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

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

Original: What the hell are requirements?