Понимать предметную область

·

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

Этот подход можно увидеть в реалзации domain driven design, при котором мы создаём общий словарь между разработкой и бизнесом. Но кроме словаря ещё происходит полный бизнес процесс, если в случае него появляется какой-то конкретный предмет: взяли тесто, сыр и начинку и приготовили пиццу, то это одно. В случае же сфер услуг всё гораздо сложнее. Что является конечным продуктом услуги? За что мы готовы отдавать свои деньги? Частично, данная вещь пересекается с подходом [[customer development]], в котором рассматривается устранение боли клиента как первоочередной задачи.

Как разобраться в области

  1. Кто наши клиенты?
  2. Какую боль мы решаем?
  3. Кто участники процессы?
  4. Что меняется в ходе процесса?
  5. Какая последовательно действий совершается явно с людьми? Какие вычисления идут при этом под капотом?

Обратные ссылки