[ARCHIVED] Стимуляция к четкой формулировке задач

[sergeysova]

Дискуссия закрыта, см. выводы по #74

---

---

---

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

Зачем?

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

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

Какую задачу?

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

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

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

Эта самая цель, с которой пришёл пользователь и есть задача разработчиков. Одна маленькая решенная задача и есть feature в методологии feature-sliced — нужно нарезать весь скоуп задач проекта на маленькие цели.

Как вынуждает?

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

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

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

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

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

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

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

Какая польза?

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

С пониманием задач приходит четкая структура как в голове, так и в задачах вместе с кодом. Бизнес крайне редко разворачивает свой курс кардинально в другую сторону, а значит отражение задач бизнеса в коде front end приложения это весьма существенный профит. Тогда не придётся объяснять каждому новому члену команды, что делает тот или иной код, и вообще ради чего он добавлялся, все будет объясняться через задачи бизнеса, которые уже отражены в коде.

[azinit]

Лонгрид, но сос мыслом)

[azinit]

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

История дискуссии

[sergeysova]

ref

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

Окей, думаем на 2-3 шага вперед, учитываем будущие хотелки, но тут упираешься в свой опыт. Если ты супер-опытный чел, то смотришь на 10 шагов вперед и понимаешь что вот эту фичу лучше делить на отдельные фичи, но связанные, а эту наоборот объединить. А если такой задачи раньше не решал прилетает фича и ты не знаешь как её лучше разделить, чтобы не поломать об свое же решение в будущем ноги.

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