Перейти к основному содержимому

О понимании потребностей и о формулировке задач

— Не получается сформулировать цель, которую будет решать новая фича? А может проблема в том, что сама задача не сформулирована? Смысл ещё и в том, чтобы методология помогла вытащить наружу проблемное определение задач и целей

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

Зачем?

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

@sergeysova: Во время разработки, мы пытаемся каждой сущности или функции дать имя, которое четко отражает намерения и смысл выполняемого кода.

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

О каких задачах речь?

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

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

Задача менеджеров и аналитиков - сформулировать эту потребность, а разработчиков реализовать с учетом особенностей веб-разработки (потеря связи, ошибка бэкенда, опечатка, промазал курсором или пальцем).

Эта самая цель, с которой пришёл пользователь и есть задача разработчиков.

Одна маленькая решенная задача и есть feature в методологии Feature-Sliced Design — нужно нарезать весь скоуп задач проекта на маленькие цели.

Как это влияет на разработку?

Декомпозиция задачи

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

  • сначала разбить на верхнеуровневые сущности и реализовать их,
  • затем эти сущности разбить на более мелкие
  • и так далее

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

При этом не забываем, что пытаемся помочь пользователю уменьшить боль или реализовать потребности

Понимание сути задачи

Но чтобы дать четкое название сущности, разработчик должен знать предостаточно о ее назначении

  • как он собирается использовать эту сущность,
  • какую часть задачи пользователя она реализует, где ещё эту сущность можно применить,
  • в каких ещё задачах она может поучаствовать,
  • и так далее

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

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

Как сформулировать?

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

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

@sergeysova: Весь frontend это в первую очередь отображение информации, любой компонент в первую очередь что-то отображает, а значит задача "показать пользователю что-то" не имеет практической ценности.

Даже без учета специфики frontend можно спросить "а зачем это нужно показывать", так можно продолжать спрашивать до тех пор пока не вылезет боль или потребность потребителя.

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

Любая новая задача в вашем трекере направлена на решение задач бизнеса, а бизнес пытается решить задачи пользователя одновременно заработав на нём. А значит, каждая задача несёт в себе определенные цели, даже если они не прописаны в тексте описания.

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

А в чем выгода?

Посмотрим теперь на весь процесс от начала до конца.

1. Понимание задач пользователей

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

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

2. Структуризация и упорядочивание

С пониманием задач приходит четкая структура как в голове, так и в задачах вместе с кодом

3. Понимание фичи и ее составляющих

Одна фича - это одна полезная функциональность для пользователя

  • Когда в одной фиче - реализуется несколько - это и есть нарушение границ
  • Фича может быть неделимой и разрастающейся - и это неплохо
  • Плохо - когда фича не отвечает на вопрос "А в чем бизнес-ценность для пользователя?"
    • Не может быть фичи карта-офиса
    • А вот бронирование-переговорки-на-карте, поиск-сотрудника, смена-рабочего-места - да

@sergeysova: Смысл в том, чтобы в фиче лежал только код, реализующий непосредственно саму функциональность, без лишних подробностей и внутренних решений (в идеале)

Открываешь код фичи и видишь только то, что относится к задаче - не больше

4. Profit

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

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

То, что называется "Язык бизнеса" в Domain Driven Development

Вернемся к реальности

Если бизнес-процессы осмыслены и на стадии дизайна даны хорошие имена - то перенести это понимание и логику в код не особо проблемно.

Однако на деле, задачи и функциональность обычно развиваются "слишком" итеративно и (или) нет времени продумывать дизайн.

В итоге фича сегодня имеет смысл, а при расширении этой фичи через месяц можно переписать пол проекта.

[Из обсуждения]: Разработчик пытается думать на 2-3 шага вперед, учитывая будущие хотелки, но тут упирается в собственный опыт

Прожженный опытом инженер обычно сразу смотрит на 10 шагов вперед, и понимает где одну фичу разделить, а где объединить с другой

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

Роль методологии

Методология помогает решить проблемы разработчиков, чтобы тем было проще решать проблемы пользователей.

Нет решения задач разработчиков только ради разработчиков

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

Требования к методологии

Становится ясно, что нужно выделить как минимум два требования для Feature-Sliced Design:

  1. Методология должна рассказывать как создавать фичи, процессы и сущности
    • А значит должна четко объяснять как разделять код между ними, из чего следует, что именование этих сущностей также должно быть заложено в спецификации.
  2. Методология должна помогать архитектуре легко адаптироваться под изменяющиеся требования проекта

См. также