Конвертация
Знаете конверторы из png в jpg и так далее. Вот продакт - это конвертер😄
Продакт конвертирует:
- Запрос в гипотезу
- Гипотезу в процесс
- Процесс в данные
- Данные в процедуру
- Процедуру в возможность
- Возможность в требование
- Требование в задачу
- Задачу в результат
♻️Запрос в гипотезу
Бизнес или клиент говорит "у меня болит". Мы ставим "диагноз" и предполагаем, что это решит проблему, выводя гипотезу.
♻️Гипотезу в процесс
У каждой гипотезы есть результат, который нужно добиться, чтобы перестало болеть. А чтобы его добиться, нужно выполнить набор шагов, возможно даже разным людям и системам.
♻️Процесс в данные
Зная каждый шаг, мы можем вывести крупные категории данных и общие данные обработки. Любой процесс и вся человеческая деятельность (если убрать всю лирику) направлена на преобразование данных из 1 в 0 и обратно.
♻️Данные в процедуру
Имея данные для каждого типа или сущности данных, мы можем вывести набор процедур их обработки. В этой точке происходит идентификация состояний, что позволяет вывести большое количество процедур. Например, создание, редактирование, удаление, архивирование и т.д.
♻️Процедуру в возможность
Процедур может быть огромное количество, но они всегда конечны и легко поддаются приоритезации. Это тот самый тонкий слой, когда процедура - это все еще бизнес, но уже легко переводится в возможность, понятная для разработки. Это точка перехода, где сталкиваются два мира: бизнеса и разработки.
♻️Возможность в требование
Для каждой возможности уже просто выдать требования к дизайну, обработке (бэку) и выводу (фронту).
♻️Требование в задачу
Пачку требований уже можно выводить в проектное управление. Выводить в проекты, в эпики, оценивать по направлениям. Строить роадмапы. Формировать спринты с точной привязкой ко времени.
♻️Задачу в результат
Стандартная разработка, где каждый специалист выполняет свою работу и реализует свою часть, кирпичек за кирпичиком строит процесс, так необходимый для гипотезы, которая так нужна для ответа на запрос)
5АМ | #разработка
Знаете конверторы из png в jpg и так далее. Вот продакт - это конвертер😄
Продакт конвертирует:
- Запрос в гипотезу
- Гипотезу в процесс
- Процесс в данные
- Данные в процедуру
- Процедуру в возможность
- Возможность в требование
- Требование в задачу
- Задачу в результат
♻️Запрос в гипотезу
Бизнес или клиент говорит "у меня болит". Мы ставим "диагноз" и предполагаем, что это решит проблему, выводя гипотезу.
♻️Гипотезу в процесс
У каждой гипотезы есть результат, который нужно добиться, чтобы перестало болеть. А чтобы его добиться, нужно выполнить набор шагов, возможно даже разным людям и системам.
♻️Процесс в данные
Зная каждый шаг, мы можем вывести крупные категории данных и общие данные обработки. Любой процесс и вся человеческая деятельность (если убрать всю лирику) направлена на преобразование данных из 1 в 0 и обратно.
♻️Данные в процедуру
Имея данные для каждого типа или сущности данных, мы можем вывести набор процедур их обработки. В этой точке происходит идентификация состояний, что позволяет вывести большое количество процедур. Например, создание, редактирование, удаление, архивирование и т.д.
♻️Процедуру в возможность
Процедур может быть огромное количество, но они всегда конечны и легко поддаются приоритезации. Это тот самый тонкий слой, когда процедура - это все еще бизнес, но уже легко переводится в возможность, понятная для разработки. Это точка перехода, где сталкиваются два мира: бизнеса и разработки.
♻️Возможность в требование
Для каждой возможности уже просто выдать требования к дизайну, обработке (бэку) и выводу (фронту).
♻️Требование в задачу
Пачку требований уже можно выводить в проектное управление. Выводить в проекты, в эпики, оценивать по направлениям. Строить роадмапы. Формировать спринты с точной привязкой ко времени.
♻️Задачу в результат
Стандартная разработка, где каждый специалист выполняет свою работу и реализует свою часть, кирпичек за кирпичиком строит процесс, так необходимый для гипотезы, которая так нужна для ответа на запрос)
5АМ | #разработка
August 22, 2023
Ну огонечков слишком много, чтобы игнорировать😝 Разберем тему своевременности через Agile)
Компания на каждом этапе развития имеет разную орг. структуру. Масштабирование влияет на выбор модели управления от простой иерархии до матричной структуры с двойным подчинением, где один менеджер говорит "сколько", а второй "когда". В этом есть большая проблема найма. Ребятки приходят работать из разных компаний. Переход из стартапа в корпорацию или из корпорации в стартап должен иметь у спеца внутреннюю установку на переключение моделей управления, иначе будет груститься и вздыхаться. Крупными мазками можно выделить три группы: маленькая компания (до 15-ти чел., справится один менеджер в поте лица), средняя до 50-60-ти (отдел управления), крупные и корпорации все остальное.
В стартапах есть проблема оголтелого копирования методик корпоративного уровня. Важное правило любого процесса - если выход из процесса не становится входом для следующего, то это мертвый процесс. Простым языком: если ты что-то сделал и это ни хрена никому не нужно - не нужно это делать. Зачем оформлять заметки ретро и отчет по спринту, если кроме тебя и твоей второй личности это проверять и читать никто не будет. Собрал инфу, тут же принял решение, двигаешься дальше.
Разберём комбинации для маленьких компаний. Какие части Agile и как можно применять на этом уровне:
Важно разделить разработку на две части: отработка идей (20%) и потоковая выдача обычного результата (80%). Это основа для комбинирования подходов. Для части плана разработки используем scrum, для другой kanban.
В Agile исследования, аналитика и документация продукта никуда не уходят. Теоретический scrum не может работать без двух вещей: без переданных по шаблону требований и без полного набора спецов для поставки гипотезы. Но, также, что не менее важно - scrum не может работать с командой большей, чем нужно для отработки гипотезы. Почему? Будет простой: зачем дизайнеру Стасу быть в scrum команде пока не появится техническое решение. Будет сидеть куковать, пока Женя будет пилить прототип редактора документов.
В моем опыте есть две ситуации:
- когда кодеры не знают что нужно делать
- и когда продакт и дизайнер не знают какие есть технические решения их гипотезы.
Эти две ситуации как раз таки те 20% всей разработки. Поиск решений.
В первом варианте: Формируем scrum команду из продакта, аналитика, дизайнера. Остальные консультируют на подхвате. Результат требования, процесс, набор данных и прототипы. Можно запилить за пару спринтов. Показали команде разработки, они уже потоково начинаю пилить.
Во втором варианте: Формируем scrum команду из продакта, backend-а, frontend-а, тестера. Пример: найти решение для редактора документа.
Все остальное это kanban. Что генерировать то, если просто табличку с данными нужно запилить да побыстрее. Так что выстраиваем поточный процесс по kanban: нашли по scrum решение гипотезы и начали отрабатывать в потоке. По пятницам синкуемся. Переключение режима просто, тумблер, чик-чик)
Scrum - это бег на короткую дистанцию (спринт собственно), он может расхолаживать. Работа в потоковом процессе в kanban - это марафон. Крупные приложения - это про 20% найти решение и 80% пробежать марафон, где НЕ нужно экспериментировать, где нужно просто сделать 200 возможностей, ёмае, без болтовни.
Если нужно забить гвоздь - зачем ты схватился за кувалду, Иннокентий? 😎
5АМ | #разработка
Компания на каждом этапе развития имеет разную орг. структуру. Масштабирование влияет на выбор модели управления от простой иерархии до матричной структуры с двойным подчинением, где один менеджер говорит "сколько", а второй "когда". В этом есть большая проблема найма. Ребятки приходят работать из разных компаний. Переход из стартапа в корпорацию или из корпорации в стартап должен иметь у спеца внутреннюю установку на переключение моделей управления, иначе будет груститься и вздыхаться. Крупными мазками можно выделить три группы: маленькая компания (до 15-ти чел., справится один менеджер в поте лица), средняя до 50-60-ти (отдел управления), крупные и корпорации все остальное.
В стартапах есть проблема оголтелого копирования методик корпоративного уровня. Важное правило любого процесса - если выход из процесса не становится входом для следующего, то это мертвый процесс. Простым языком: если ты что-то сделал и это ни хрена никому не нужно - не нужно это делать. Зачем оформлять заметки ретро и отчет по спринту, если кроме тебя и твоей второй личности это проверять и читать никто не будет. Собрал инфу, тут же принял решение, двигаешься дальше.
Разберём комбинации для маленьких компаний. Какие части Agile и как можно применять на этом уровне:
Важно разделить разработку на две части: отработка идей (20%) и потоковая выдача обычного результата (80%). Это основа для комбинирования подходов. Для части плана разработки используем scrum, для другой kanban.
В Agile исследования, аналитика и документация продукта никуда не уходят. Теоретический scrum не может работать без двух вещей: без переданных по шаблону требований и без полного набора спецов для поставки гипотезы. Но, также, что не менее важно - scrum не может работать с командой большей, чем нужно для отработки гипотезы. Почему? Будет простой: зачем дизайнеру Стасу быть в scrum команде пока не появится техническое решение. Будет сидеть куковать, пока Женя будет пилить прототип редактора документов.
В моем опыте есть две ситуации:
- когда кодеры не знают что нужно делать
- и когда продакт и дизайнер не знают какие есть технические решения их гипотезы.
Эти две ситуации как раз таки те 20% всей разработки. Поиск решений.
В первом варианте: Формируем scrum команду из продакта, аналитика, дизайнера. Остальные консультируют на подхвате. Результат требования, процесс, набор данных и прототипы. Можно запилить за пару спринтов. Показали команде разработки, они уже потоково начинаю пилить.
Во втором варианте: Формируем scrum команду из продакта, backend-а, frontend-а, тестера. Пример: найти решение для редактора документа.
Все остальное это kanban. Что генерировать то, если просто табличку с данными нужно запилить да побыстрее. Так что выстраиваем поточный процесс по kanban: нашли по scrum решение гипотезы и начали отрабатывать в потоке. По пятницам синкуемся. Переключение режима просто, тумблер, чик-чик)
Scrum - это бег на короткую дистанцию (спринт собственно), он может расхолаживать. Работа в потоковом процессе в kanban - это марафон. Крупные приложения - это про 20% найти решение и 80% пробежать марафон, где НЕ нужно экспериментировать, где нужно просто сделать 200 возможностей, ёмае, без болтовни.
Если нужно забить гвоздь - зачем ты схватился за кувалду, Иннокентий? 😎
5АМ | #разработка
August 30, 2023
Требования и backend
При разработке требований к продукту с большим объемом интерфейсов можно натолкнуться на такую сложность, что backend не делает возможности по одной. Берется сразу пачка. То есть там где у дизайна и у фронта 4 задачи , то у бэкенда всего одна и рассматривать их нужно вкупе или придется опять переделывать. Как так получается и что с этим делать? По крайней мере как мы с этим справляемся. Делитесь что у вас)
Вот возьмем пример. Есть таблица с данными поступлений, в которую выводим данные. У таблицы есть сортировка, фильтрация и поиск. Нам нужно сформулировать требования к четырем возможностям: вывод данных, фильтрация, сортировка, поиск. Это 4 разные процедуры для пользователя, его 4 самостоятельные потребности, которые имеют свой маршрут из действий. А поэтому могут иметь особые требования, которые продакт должен рассмотреть отдельно. Дизайнер, в свою очередь, будет рассматривать отдельно каждую процедуру, разложит состояния, покажет что происходит и на чем все закончится. Фронт тоже будет собирать весь процесс отдельно для каждой возможности. Но вот для бэкэнда - это все один GET запрос с разными параметрами в URL.
Поэтому в документации у нас есть отдельный tech block (раздел с табличкой), который составляется после подготовки документации возможностей. А их может быть и 15-30 шт. для раздела. В этом блоке по типам запросов разбиваются возможности раздела, чтобы далее передать в разработку пачками. Это ускоряет разработку и дает понимание общей картины для бэкенда.
Поэтому задача аналитика разбить процедуры на такие крупные блоки:
— GET. Получить данные конкретной сущности. Например, данные карточки товара.
— GET. Данные в таблицу с пагинацией, поиском, контекстным меню и т.д.
— POST. Создание, редактирование сущности.
— DELETE. Удаление, архивация сущности.
Есть еще кастомные сложные эндпоинты, хабы, загрузка файлов. Они как правило рассматриваются уже в тех. анализе отдельно.
И уже на тактическом уровне планирования в Notion бэкенд логично для себя ведет работу, чтобы поставить те эндпоинты, которые нужны фронту. Фронт же получит требования, дизайн и API запрос, который позволит ему потоково без переключений делать пачку возможностей без нервов и также плавно передать это тестировщику. 🎩
5АМ | #разработка
При разработке требований к продукту с большим объемом интерфейсов можно натолкнуться на такую сложность, что backend не делает возможности по одной. Берется сразу пачка. То есть там где у дизайна и у фронта 4 задачи , то у бэкенда всего одна и рассматривать их нужно вкупе или придется опять переделывать. Как так получается и что с этим делать? По крайней мере как мы с этим справляемся. Делитесь что у вас)
Вот возьмем пример. Есть таблица с данными поступлений, в которую выводим данные. У таблицы есть сортировка, фильтрация и поиск. Нам нужно сформулировать требования к четырем возможностям: вывод данных, фильтрация, сортировка, поиск. Это 4 разные процедуры для пользователя, его 4 самостоятельные потребности, которые имеют свой маршрут из действий. А поэтому могут иметь особые требования, которые продакт должен рассмотреть отдельно. Дизайнер, в свою очередь, будет рассматривать отдельно каждую процедуру, разложит состояния, покажет что происходит и на чем все закончится. Фронт тоже будет собирать весь процесс отдельно для каждой возможности. Но вот для бэкэнда - это все один GET запрос с разными параметрами в URL.
Поэтому в документации у нас есть отдельный tech block (раздел с табличкой), который составляется после подготовки документации возможностей. А их может быть и 15-30 шт. для раздела. В этом блоке по типам запросов разбиваются возможности раздела, чтобы далее передать в разработку пачками. Это ускоряет разработку и дает понимание общей картины для бэкенда.
Поэтому задача аналитика разбить процедуры на такие крупные блоки:
— GET. Получить данные конкретной сущности. Например, данные карточки товара.
— GET. Данные в таблицу с пагинацией, поиском, контекстным меню и т.д.
— POST. Создание, редактирование сущности.
— DELETE. Удаление, архивация сущности.
Есть еще кастомные сложные эндпоинты, хабы, загрузка файлов. Они как правило рассматриваются уже в тех. анализе отдельно.
И уже на тактическом уровне планирования в Notion бэкенд логично для себя ведет работу, чтобы поставить те эндпоинты, которые нужны фронту. Фронт же получит требования, дизайн и API запрос, который позволит ему потоково без переключений делать пачку возможностей без нервов и также плавно передать это тестировщику. 🎩
5АМ | #разработка
September 11, 2023
К вчерашнему посту был комментарий от Кнарик (мы с ней работали над Локео, оч. крутой дизайнер) закинула вопрос - почему исследования делает systems analyst , а не UX.
Я ответил ей и размышления вывели меня на вопрос, а кто в команде архитектор системы. Давайте подискутируем, присоединяйтесь. Вот мысли)
5АМ | #разработка
Я ответил ей и размышления вывели меня на вопрос, а кто в команде архитектор системы. Давайте подискутируем, присоединяйтесь. Вот мысли)
5АМ | #разработка
September 21, 2023
Кто в итоге должен проводить интервью: SA или UX или BA?
Вообще, все смешалось кони-люди)
Чтобы ответить, нужно понять вот что: кто в итоге - архитектор системы? UX или SA или вообще CTO? Разберемся, а зачем собственно и UX и SA интервью. Попытаемся расщепить обязанности:
— UX не должен анализировать данные, но без них он не сделает свою задачу, ведь проектировать интерфейс без данных пустая трата времени. UX не должен думать за внутрисистемные процессы, но тогда не выполнит свою работу качественно, потому что не поймет что делает программа.
— SA не сделает свою задачу без процесса в интерфейсах, ведь часть данных преобразуется в рамках процесса в интерфейсе, который определяет точки входа в операцию. На выходе косячно заложит требования.
Получается SA и UX должны дважды прийти к одному пользователю и задать почти одинаковые вопросы, но каждый со своей позиции. Ну или спрашивать друг у друга. Как результат: кто-то обязательно будет выдумывать, кто-то будет в пассивной позиции. А вот кто: SA или UX? Сильно зависит от истории развития процессов компании, иногда и продукта. Проведя исследования, кто собирает все воедино, кто комбинирует решение, архитектор?
Так кто в итоге архитектор? Если смастерить круги Эйлера: BA, SA и UX, то архитектор системы будет серединой. Главная проблема: если в одной голове это все еще можно подружить, то при расщеплении на роли "архитектором" является некая эмерджентность у команды как системы. Команда - это архитектор. Это не что иное как мельница Лейбница.
Поэтому, чтобы это уникальное свойство работало, возникает куча созвонов, перепалок, штурмов. Так и выходит, что на одном проекте UX перетянул на себя больше обязанностей, на другом больше SA. А потом на hr рынок вылетают профессии «продуктовый дизайнер», потому что какой-то бизнес просто плюнул и говорит, пусть это все будет называться так.
Из-за масштаба процесса проектирования в компании неизбежно возникает его деление на подпроцессы. Чтобы он работал эффективно, нужна такая тонкая настройка команды, что я в эффективность этого почти не верю. Получается, что бизнесу нужна команда креативщиков в носках с бананами минимум из 5-ти человек: продакт, UX, BA, SA, CTO) Вот и в месяц полтора миллиона бюджета нет) Боль😭
Как вывод, каждый может делать интервью, каждый должен делать интервью. Но считаю, что SA его должен делать первый, так как он может сформулировать процесс системы, который будет компилироваться по данным и без интерфейса. Он сделает предположение, что система вообще может работать так, а не система удобно может работать так. UX же уже идет к пользователю не с абстрактным вопросом «а как вам удобно», а вот смотрите есть вот такая проблема: мы можем их показать вот так, вот так и вот так. SA работает, когда нет интерфейса и БД. Это его стихия, потому что он делает свою работу на табличке с переменными, не спотыкаясь об проблемы интерфейса.
Остается вопрос: как команду превратить в "архитектора"? Вот это уже искусство)
Что думаете? 🎩
5АМ | #разработка
Вообще, все смешалось кони-люди)
Чтобы ответить, нужно понять вот что: кто в итоге - архитектор системы? UX или SA или вообще CTO? Разберемся, а зачем собственно и UX и SA интервью. Попытаемся расщепить обязанности:
— UX не должен анализировать данные, но без них он не сделает свою задачу, ведь проектировать интерфейс без данных пустая трата времени. UX не должен думать за внутрисистемные процессы, но тогда не выполнит свою работу качественно, потому что не поймет что делает программа.
— SA не сделает свою задачу без процесса в интерфейсах, ведь часть данных преобразуется в рамках процесса в интерфейсе, который определяет точки входа в операцию. На выходе косячно заложит требования.
Получается SA и UX должны дважды прийти к одному пользователю и задать почти одинаковые вопросы, но каждый со своей позиции. Ну или спрашивать друг у друга. Как результат: кто-то обязательно будет выдумывать, кто-то будет в пассивной позиции. А вот кто: SA или UX? Сильно зависит от истории развития процессов компании, иногда и продукта. Проведя исследования, кто собирает все воедино, кто комбинирует решение, архитектор?
Так кто в итоге архитектор? Если смастерить круги Эйлера: BA, SA и UX, то архитектор системы будет серединой. Главная проблема: если в одной голове это все еще можно подружить, то при расщеплении на роли "архитектором" является некая эмерджентность у команды как системы. Команда - это архитектор. Это не что иное как мельница Лейбница.
Поэтому, чтобы это уникальное свойство работало, возникает куча созвонов, перепалок, штурмов. Так и выходит, что на одном проекте UX перетянул на себя больше обязанностей, на другом больше SA. А потом на hr рынок вылетают профессии «продуктовый дизайнер», потому что какой-то бизнес просто плюнул и говорит, пусть это все будет называться так.
Из-за масштаба процесса проектирования в компании неизбежно возникает его деление на подпроцессы. Чтобы он работал эффективно, нужна такая тонкая настройка команды, что я в эффективность этого почти не верю. Получается, что бизнесу нужна команда креативщиков в носках с бананами минимум из 5-ти человек: продакт, UX, BA, SA, CTO) Вот и в месяц полтора миллиона бюджета нет) Боль😭
Как вывод, каждый может делать интервью, каждый должен делать интервью. Но считаю, что SA его должен делать первый, так как он может сформулировать процесс системы, который будет компилироваться по данным и без интерфейса. Он сделает предположение, что система вообще может работать так, а не система удобно может работать так. UX же уже идет к пользователю не с абстрактным вопросом «а как вам удобно», а вот смотрите есть вот такая проблема: мы можем их показать вот так, вот так и вот так. SA работает, когда нет интерфейса и БД. Это его стихия, потому что он делает свою работу на табличке с переменными, не спотыкаясь об проблемы интерфейса.
Остается вопрос: как команду превратить в "архитектора"? Вот это уже искусство)
Что думаете? 🎩
5АМ | #разработка
September 21, 2023
Макеты - лицо документации
Я не раз видел в дизайн чатах, что дизайнеры ищут способы организации своих рабочих файлов. Мы в наших проектах прошли все стадии: от абсолютного хаоса к идеальному порядку с минимальным затратам сил.
Наличие документации, а также её системность влияет на то, как будут выглядеть макеты приложения. Макеты могут как запутать всю разработку, так и стать хорошим источником для проверки требований на раннем этапе и удобным инструментом в построении БД, разработки бэка и фронта. Короче рыба с головы.
Какие есть фундаментальные проблемы отображения макетов:
Версии
Требования меняются. Однако, команда разработки уже запущена, возможно, фронт уже допиливает фичу, но дизайнер вносит изменения прям в макет переданный в разработку, не имея другого места для работы. Как итог, команда заходит и видит уже обновленный макет, работа встала. Истории развития - нет.
Процессы
Макеты отражают процесс пользователя, в рамках которого выполняется вариант использования, достигается какой-то результат. Можно спутать и отобразить более масштабный процесс с несколькими юзкейсами и запутать команду, что приведет к неточностям и багам. Это склейка юзкейсов, опасная штука.
Состояния
В юзкейс могут быть заложены требования, которые добавляют состояния процесса. Их тоже нужно отразить, т.к. возможно появление нового компонента для кита или дополнительных требований.
У нас как результат аналитики выходит такая карточка (пользовательские требования), которая имеет ссылки с прострелом от бизнес цели до требований разных уровней, чтобы получить возможность как атомарный «пазл» процесса. Это как конструктор ТЗ, можно в любой момент за 3 минуты собрать ТЗ и передать его в разработку.
В итоге, аналитика и дизайн отражают и дополняют друг друга. Добавилась версия требований, из неё добавляется версия макетов. Если разработка запущена, то она знает какую версию делает, а дизайнер работает, не переживая за изменения.
А как вы организуете файлы фигмы?
5АМ | #разработка
Я не раз видел в дизайн чатах, что дизайнеры ищут способы организации своих рабочих файлов. Мы в наших проектах прошли все стадии: от абсолютного хаоса к идеальному порядку с минимальным затратам сил.
Наличие документации, а также её системность влияет на то, как будут выглядеть макеты приложения. Макеты могут как запутать всю разработку, так и стать хорошим источником для проверки требований на раннем этапе и удобным инструментом в построении БД, разработки бэка и фронта. Короче рыба с головы.
Какие есть фундаментальные проблемы отображения макетов:
Версии
Требования меняются. Однако, команда разработки уже запущена, возможно, фронт уже допиливает фичу, но дизайнер вносит изменения прям в макет переданный в разработку, не имея другого места для работы. Как итог, команда заходит и видит уже обновленный макет, работа встала. Истории развития - нет.
Процессы
Макеты отражают процесс пользователя, в рамках которого выполняется вариант использования, достигается какой-то результат. Можно спутать и отобразить более масштабный процесс с несколькими юзкейсами и запутать команду, что приведет к неточностям и багам. Это склейка юзкейсов, опасная штука.
Состояния
В юзкейс могут быть заложены требования, которые добавляют состояния процесса. Их тоже нужно отразить, т.к. возможно появление нового компонента для кита или дополнительных требований.
У нас как результат аналитики выходит такая карточка (пользовательские требования), которая имеет ссылки с прострелом от бизнес цели до требований разных уровней, чтобы получить возможность как атомарный «пазл» процесса. Это как конструктор ТЗ, можно в любой момент за 3 минуты собрать ТЗ и передать его в разработку.
В итоге, аналитика и дизайн отражают и дополняют друг друга. Добавилась версия требований, из неё добавляется версия макетов. Если разработка запущена, то она знает какую версию делает, а дизайнер работает, не переживая за изменения.
А как вы организуете файлы фигмы?
5АМ | #разработка
October 11, 2023
November 6, 2023
Проклятие смотрящего
Каждый продакт знает про эту бесовщину.
Вот, черт побери, релизнулись. Проверяешь, тыкаешь приложеньку. Все работает. Идешь показывать важному человеку, а оно как заколдованное багует. Ну и стоишь обтекаешь как пацан. Я не знаю, что происходит между. Наверное эльфы брякнули по струнам пространства-времени, а может спин кварка резко решил сменить направление вектора, не знаю)
Было?)
5АМ | #разработка
Каждый продакт знает про эту бесовщину.
Вот, черт побери, релизнулись. Проверяешь, тыкаешь приложеньку. Все работает. Идешь показывать важному человеку, а оно как заколдованное багует. Ну и стоишь обтекаешь как пацан. Я не знаю, что происходит между. Наверное эльфы брякнули по струнам пространства-времени, а может спин кварка резко решил сменить направление вектора, не знаю)
Было?)
5АМ | #разработка
November 10, 2023
Мне нравится сравнение результатов методик проектирования. Становится ясно, что все это, так или иначе, просто задача, но рассматриваемая с определенной стороны.
🟣 Бизнес требование: "Нужно сделать мобильное приложение для оплаты счетов клиентами".
🟣 Продуктовая гипотеза: "Если у клиента будет личный кабинет, то он будет реже забывать оплачивать счет, что приведет к снижению краткосрочных долгов на... в течение..."
🟣 User Story: "Я как собственник недвижимости хочу оплатить счет за услуги через личный кабинет, чтобы у меня не образовался долг"
🟣 Job Story: "Когда я сижу в баре с друганами в Москве в пятницу, получаю уведомление о необходимости оплаты, зная, что из-за загруза на работе не поеду в Тверскую область на дачу еще 2 недели, соответственно не попаду в офис к моей УК для оплаты у кассира, вбивать 20 цифр расчетного счета и назначения платежа в сбере мне лень, а значит я забуду и меня будут пинать по поводу долга, я хочу, как собственник недвижимости оплатить счет за услуги через личный кабинет, а лучше вообще автоплатежом, чтобы не мешали мне квасить."
🟣 UserCase: "Собственник, получивший уведомление о создании начисления, входит в приложение на своем смартфоне, переходит в раздел счета и производит пополнение лицевого счета...".
🟣 Возможность: "Оплатить лицевой счет."
🟣 Функциональные требования: "Система должна создать заказ для шлюза интернет-эквайринга банка и передать в него данные для проведения оплаты".
🟣 Задача: "Жек, мля, запили пж фичу, чтобы бабки на счет падали, только тот баг сначала поправь, а то глаз мазолит жуть..."
В этом посте я закинул визуализацию задач с разной стороны на примере метафоры из физики на эту же тему))
5АМ | #разработка
🟣 Бизнес требование: "Нужно сделать мобильное приложение для оплаты счетов клиентами".
🟣 Продуктовая гипотеза: "Если у клиента будет личный кабинет, то он будет реже забывать оплачивать счет, что приведет к снижению краткосрочных долгов на... в течение..."
🟣 User Story: "Я как собственник недвижимости хочу оплатить счет за услуги через личный кабинет, чтобы у меня не образовался долг"
🟣 Job Story: "Когда я сижу в баре с друганами в Москве в пятницу, получаю уведомление о необходимости оплаты, зная, что из-за загруза на работе не поеду в Тверскую область на дачу еще 2 недели, соответственно не попаду в офис к моей УК для оплаты у кассира, вбивать 20 цифр расчетного счета и назначения платежа в сбере мне лень, а значит я забуду и меня будут пинать по поводу долга, я хочу, как собственник недвижимости оплатить счет за услуги через личный кабинет, а лучше вообще автоплатежом, чтобы не мешали мне квасить."
🟣 UserCase: "Собственник, получивший уведомление о создании начисления, входит в приложение на своем смартфоне, переходит в раздел счета и производит пополнение лицевого счета...".
🟣 Возможность: "Оплатить лицевой счет."
🟣 Функциональные требования: "Система должна создать заказ для шлюза интернет-эквайринга банка и передать в него данные для проведения оплаты".
🟣 Задача: "Жек, мля, запили пж фичу, чтобы бабки на счет падали, только тот баг сначала поправь, а то глаз мазолит жуть..."
В этом посте я закинул визуализацию задач с разной стороны на примере метафоры из физики на эту же тему))
5АМ | #разработка
November 14, 2023
Реверсивные операции
Есть такая сложная фигня в проектировании архитектуры. Я назвал это реверсивными операциями, может кто знает как это называется общепринятым термином.
Суть, допустим есть сущность Смета и сущность Контрагент. У обоих сущностей есть полный набор CRUD операций. И вот допустим, пользователю нужно, чтобы на странице контрагента отображался список смет контрагента (при создании сметы выбирается контрагент).
Проблема в том, что возникает соблазн продублировать весь набор операций в списке смет на странице контрагентов, потому что это кажется логичным с точки зрения UX. Допустим, пользователь прошел по ссылке на котрагента из какой-то части приложения и возникает потребность создать смету, потому что он видит список его смет. Вроде логично, но опасно, потому что может возникнуть дополнительная пачка неучтенных требований и просто пойти по легкому пути типа "да сделай просто как в том разделе, только на этой странице и все". Не, фильтрация может измениться, в форме могут не понадобиться какие-то данные или валидация может быть другая, а таблица может содержать другие колонки. Во-первых, это дорого, а во-вторых, это может быть не нужно.
У нас много реверсивных операций. Мы решили сделать вход в процедуры сущности только с одной стороны во благо пользователя, чтобы не путать его. Да, отображение данных можно сделать в другой сущности, но операции нежелательно. Как вариант, просто сделать ссылки, открывающие новую вкладку с разделом. Плюсы - пользователь знает, что только из этого места он может выполнить эту операцию и не запутается. Минусы - придется увеличивать путь и клики, но думаю это меньшее из зол.
Тут конечно очень помогает разбор job-ов, чтобы уточнить контекст, почему выполнение операции может потребоваться не из основного раздела.
Встречали такие сущности? Как решали?))
5АМ | #разработка
Есть такая сложная фигня в проектировании архитектуры. Я назвал это реверсивными операциями, может кто знает как это называется общепринятым термином.
Суть, допустим есть сущность Смета и сущность Контрагент. У обоих сущностей есть полный набор CRUD операций. И вот допустим, пользователю нужно, чтобы на странице контрагента отображался список смет контрагента (при создании сметы выбирается контрагент).
Проблема в том, что возникает соблазн продублировать весь набор операций в списке смет на странице контрагентов, потому что это кажется логичным с точки зрения UX. Допустим, пользователь прошел по ссылке на котрагента из какой-то части приложения и возникает потребность создать смету, потому что он видит список его смет. Вроде логично, но опасно, потому что может возникнуть дополнительная пачка неучтенных требований и просто пойти по легкому пути типа "да сделай просто как в том разделе, только на этой странице и все". Не, фильтрация может измениться, в форме могут не понадобиться какие-то данные или валидация может быть другая, а таблица может содержать другие колонки. Во-первых, это дорого, а во-вторых, это может быть не нужно.
У нас много реверсивных операций. Мы решили сделать вход в процедуры сущности только с одной стороны во благо пользователя, чтобы не путать его. Да, отображение данных можно сделать в другой сущности, но операции нежелательно. Как вариант, просто сделать ссылки, открывающие новую вкладку с разделом. Плюсы - пользователь знает, что только из этого места он может выполнить эту операцию и не запутается. Минусы - придется увеличивать путь и клики, но думаю это меньшее из зол.
Тут конечно очень помогает разбор job-ов, чтобы уточнить контекст, почему выполнение операции может потребоваться не из основного раздела.
Встречали такие сущности? Как решали?))
5АМ | #разработка
November 17, 2023