К вчерашнему посту был комментарий от Кнарик (мы с ней работали над Локео, оч. крутой дизайнер) закинула вопрос - почему исследования делает systems analyst , а не UX.

Я ответил ей и размышления вывели меня на вопрос, а кто в команде архитектор системы. Давайте подискутируем, присоединяйтесь. Вот мысли)

5АМ | #разработка

Кто в итоге должен проводить интервью: 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/UI дизайнеры. Все максимально непонятное вешают на них. Вроде бы учился рисовать макеты, компоненты, понимать композицию, ритм, шрифты и пр, а потом вдруг и требования нужно проанализировать, пользователей заинтервьювить, схемки нарисовать, в метрику посмотреть, чтобы фичу предложить, а потом еще "можешь логотип там чуть поправить на пару пикселей, ты ж дизайнер" и фронт нужно понимать как работает, и типы данных от аналитика нужно разбирать и так далее. Пааанимааааю.

Главная сложность UX/UI дизайна в танце логики и творчества.

Какие важные качества должны быть у UX/UI дизайнера:

🟣 Композиция, ритм
Поставил на первое место, потому что здесь кроется тот самый талант. Это как слух в музыке. Медведь на ухо наступил. Натренировать сложно, но можно. То самое восприятие всех элементов дизайна как целого на интуитивном уровне.
🟣 Чувство связи направлений
Дизайнер не находится в вакууме. Его влияние очень велико. Его работа - это оцифрованные требования. Дизайнер должен понимать почему продакт бесится за деньги, как его дизайн повлияет на стоимость разработки фронта. Мы с ребятами постоянно поднимаем этот момент. В этом главный ключ адекватности - восприятие себя в цепочке производства. То есть кто стоит за тобой и после тебя. Кто принимает твой результат и чей принимаешь ты. Отсюда взаимопомощь - аналитик думает как проще и быстрее будет дизайнеру, дизайнер как проще будет фронту. Гипертрофированность эго в IT повсеместно, умение его чувствовать и управлять им - ключ к взаимопониманию в команде.
🟣 Поколено в аналитике
Как ни крути, но дизайнер участвует в выявлении требований к продкту на своем уровне, но не вместо бизнес-, системного- аналитика, а вместе. CJM должен делать член команды с опытом в маркетинге, классы пользователей, модели и потоки данных, переходы состояний, контексты должен вывести аналитик, вывести конкурентов - продакт, но да, конечно, дизайнер должен создать и проанализировать карту диалоговых окон, собрать рефы дизайна по конкуретнов или похожих продуктов, взять интервью у пользователей в контексте пожеланий удобства и красоты. Это его участие в аналитике.
🟣 Инструменты
Естественно дизайнер должен быть гуру в создании компонентов, блоков, макетов в Figma. Глубоко понимать свой инструмент. Уметь в написании текста на уровне сформулировать предложение без ошибок в пунктуации и грамматики.

Сложно быть дизайнером, короче)

5AM | #разработка

Проклятие смотрящего

Каждый продакт знает про эту бесовщину.

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

Было?)

5АМ | #разработка

Мне нравится сравнение результатов методик проектирования. Становится ясно, что все это, так или иначе, просто задача, но рассматриваемая с определенной стороны.

🟣 Бизнес требование: "Нужно сделать мобильное приложение для оплаты счетов клиентами".

🟣 Продуктовая гипотеза: "Если у клиента будет личный кабинет, то он будет реже забывать оплачивать счет, что приведет к снижению краткосрочных долгов на... в течение..."

🟣 User Story: "Я как собственник недвижимости хочу оплатить счет за услуги через личный кабинет, чтобы у меня не образовался долг"

🟣 Job Story: "Когда я сижу в баре с друганами в Москве в пятницу, получаю уведомление о необходимости оплаты, зная, что из-за загруза на работе не поеду в Тверскую область на дачу еще 2 недели, соответственно не попаду в офис к моей УК для оплаты у кассира, вбивать 20 цифр расчетного счета и назначения платежа в сбере мне лень, а значит я забуду и меня будут пинать по поводу долга, я хочу, как собственник недвижимости оплатить счет за услуги через личный кабинет, а лучше вообще автоплатежом, чтобы не мешали мне квасить."

🟣 UserCase: "Собственник, получивший уведомление о создании начисления, входит в приложение на своем смартфоне, переходит в раздел счета и производит пополнение лицевого счета...".

🟣 Возможность: "Оплатить лицевой счет."

🟣 Функциональные требования: "Система должна создать заказ для шлюза интернет-эквайринга банка и передать в него данные для проведения оплаты".

🟣 Задача: "Жек, мля, запили пж фичу, чтобы бабки на счет падали, только тот баг сначала поправь, а то глаз мазолит жуть..."

В этом посте я закинул визуализацию задач с разной стороны на примере метафоры из физики на эту же тему))

5АМ | #разработка

Реверсивные операции

Есть такая сложная фигня в проектировании архитектуры. Я назвал это реверсивными операциями, может кто знает как это называется общепринятым термином.

Суть, допустим есть сущность Смета и сущность Контрагент. У обоих сущностей есть полный набор CRUD операций. И вот допустим, пользователю нужно, чтобы на странице контрагента отображался список смет контрагента (при создании сметы выбирается контрагент).

Проблема в том, что возникает соблазн продублировать весь набор операций в списке смет на странице контрагентов, потому что это кажется логичным с точки зрения UX. Допустим, пользователь прошел по ссылке на котрагента из какой-то части приложения и возникает потребность создать смету, потому что он видит список его смет. Вроде логично, но опасно, потому что может возникнуть дополнительная пачка неучтенных требований и просто пойти по легкому пути типа "да сделай просто как в том разделе, только на этой странице и все". Не, фильтрация может измениться, в форме могут не понадобиться какие-то данные или валидация может быть другая, а таблица может содержать другие колонки. Во-первых, это дорого, а во-вторых, это может быть не нужно.

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

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

Встречали такие сущности? Как решали?))

5АМ | #разработка

Не заморачивайся со схемками

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

В проектировании вот уже кажется 3-й год я использую альбом для рисования с листами А4. Он всегда лежит передо мной. Кажется у меня их уже с десяток скопилось. Когда возникает мысль и потребность завизуализировать переходы состояний, переходы между процедурами или движение данных, я накидываю в альбоме карандашом за 10-20 сек, все остальное время сижу с закрытыми глазами и компилирию, чтобы обернуть в требования и дальше в текст.

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

Из этого выходит, что схема - это расходник. Сделал - выбросил. Схема не есть продукт, не надо за неё платить. Главное вывод, что человек или система должны или не должны работать в этом состоянии таким образом.

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

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

5АМ | #разработка

Таблица и дерево решений

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

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

Допустим у вас 3 таких условия, логических значения всего 2: true или false, значит количество значений 2 в 3 степени или 8 возможных вариантов состояний системы. Возле каждого условия ставим галку да/нет и проверяем, реально ли следующее условие в списке условий, если у текущего стоит это значение. Так мы шаг за шагом находим реально возможные состояния системы. Их может быть 3-5. Для каждого такого состояния принимаем решение, что будет делать система или человек (какая процедура запускается) и ставим галку возле процедуры. Далее это легко переводится в самостоятельное требование, которое можно легко перевести в текст. Например, "система должна заблокировать операцию пополнения счета, если статус лицевого счета "закрыт".

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

5АМ | #разработка

Фича или сценарий

Пост для продактов через дизайнерскую призму. Сейчас расскажу вам ведьмины секреты квантового UX-а 😁

До меня очень долго доходил один момент, тонкий момент. То, что пользователь согласен купить, не является сценарием использования.

Нам с макро UX помогает Кнарик (я писал о ней, она мега крутой UX архитектор, ведет группу spb-designers). Я ей говорю: "вот у меня есть такие фичи, за них нам готовы платить, вот молят нас, чтобы у нас было вот это и вот это". А она, как крутой спец, меня - назойливого продакта, за шкирвотник тормозит и говорит: "отвали ты от меня со своими фичами, сценарии мне дай, сценарии☝️". И блииин, это круто, профессионал не спорит, он делает по-своему, зная какой нужен результат!

В чем вся проблема: бизнесу, выстраивая отдел проектирования ПО, невероятно легко запутаться в ролях команды проектирования, т.е. продакта, ux/ui дизайнера, аналитика и прод. дизайнера(ux архитектора), поэтому часто возникает так "пусть все это делает продакт Вася и дизайнер Анатолий" и у обоих образуется раздвоение личностей и нервный тик. Все это до кучи усложняется тем, что в BPM системах важен не только микро UX, т.е. где должна стоять кнопочка функции, чтобы было удобно пройти/выполнить действие, но и макро UX, т.е. какие сценарии есть и какие у них точки входа, глубина вложений, движения по ссылкам, глобальное преобразование данных пользователя.

Я не знаю только у меня ли это как у продакта (поделитесь), но думать фичами - это проф. деформация. Фичи покупают, но пользуются сценариями. На сценарии говорят "говно дизайн, не удобно".

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

5АМ | #разработка

1️⃣ Дерево непрямых зависимостей
Вместо набора независимых микросервисов вы, скорее всего, получите дерево непрямых зависимостей между микросервисами. С высокой долей вероятности потребуется, чтобы микросервисы коммуницировали между собой. Для такой коммуникации придётся определять контракты и периодически их поддерживать, если что-то изменилось в одном из микросервисов.

2️⃣ Можно забыть об ACID
Атомарность и подлинная целостность данных не дружат с микросервисами. Условно, если у вас идёт распределенная транзакция на заказ товара, которая должна пробежаться по микросервисам заказов, оплаты, отгрузки и т.д., то при возникновении ошибки на каком-то этапе транзакция будет частично выполненной и нужен будет программно реализуемый откат. С ACID - у вас либо транзакция выполняется, либо нет;

3️⃣ Прочесть дорого
Многочастотные операции чтения для иерархических данных, которые должны собираться со многих микросервисов, могут сделать вам очень больно, особенно если микросервисы реализованы канонично с отдельными приватными БД;

4️⃣ Очень высокие требования к экспертизе предметной области
Особенно в плане разделения приложения на ограниченные контексты (bounded contexts). Если продукт сложный, то у вас по сути не будет права на ошибку, поскольку её стоимость будет чрезвычайно высокой. Соответственно, новый сложный продукт + недостаточная степень экспертизы в предметной области или размытость этой области = практически 100% вероятность возникновения такой ошибки;

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

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

Вместо предполагаемого ускорения разработки ("у нас же параллельные команды!") - получаем замедление и удорожание;

6️⃣ Тестирование
Интеграционное тестирование микросервисов, т.е. такое тестирование, которое затрагивает функциональность приложения в целом, чрезвычайно сложно реализуемо.

Вместо запуска такого тестирования по одной кнопке, вам придётся собирать космический корабль😁;

7️⃣Деплой
Затем вы переходите к деплою и тут вы поймете, почему при микросервисном подходе зачастую существуют отдельные и дорогие devops-команды.

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

Это очень даже возможно разрешить все вышеперечисленные проблемы в достаточной мере, но скорее всего вы не Netflix, не Amazon и не Instagram, чтобы а) иметь достаточные ресурсы для этого; б) иметь в целом высокую потребность в микросервисной архитектуре.😎

Тогда что вместо этого?

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

И только потом полноценную модульную архитектуру (модулит), которую со временем можно отмасштабировать.

Например, если у вас SaaS-ориентированное приложение, то можно создать нескольких инстанций приложения на каждого тенанта или группу тенантов, возможно с распределенной физически и логически БД на каждую инстанцию.

В 90% случаев плохая отзывчивость приложения и его медленная работа будет сводиться к тому, как приложение взаимодействует с БД, насколько оптимизированы как сама БД, так и запросы к ней.

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

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

Хуже и сложнее плохого монолита может быть только плохая распределенная архитектура. 🎩

5АМ | #разработка

Привет, на связи Стас!

Сегодня поговорим о UI ките.

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

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

UI кит часто путают с дизайн-системой.

Дизайн система - это комплексный подход, содержащий всю информацию о проекте: набор стандартов, компоненты, анимация и даже редполитика.

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

Так зачем он нужен? Рассмотрим ниже)

5АМ | #разработка

UI кит - это то, что гарантирует согласованность в интерфейсе.

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

🟣 Согласованность и системность
Хороший совет, который мне дала моя бабушка 🥰: «Не полагайся на свою память - фиксируй на бумаге». Переношу смысл - прописав (отрисовав) все отступы, размеры, цвета и т.д., вам не придется держать все эти значения в голове. В качестве бонуса вы получите чистый и системный дизайн.

🟣 Разработка
Разработчики скажут вам спасибо, что им не пришлось ломать голову над «почему здесь так? а там по другому?» И главное - они смогут увидеть все состояния и поведение элементов и не будут выдумывать что-то свое, о чем дизайнер не подумал.

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

Какие есть этапы создания кита:

1️⃣Сначала стоит определиться с концептом, накидав главную и пару второстепенных страниц. Покажите максимум деталей, чтобы понять каким будет проект.

2️⃣ Затем цвета, типографика, иконки, сетка и система отступов.

3️⃣ Все слышали про атомарный подход? Если нет - ставьте пальцы вверх, раскроем эту тему в следующей статье. Коротко - дизайн состоит из атомов, молекул, организмов, блоков, страниц. Сейчас затронем первые три.

4️⃣Атомы))
Это кнопки (основные, второстепенные, текстовые, кнопка-иконка) и контролы (чекбоксы, ради баттоны, переключатели, табы, ссылки), а также инпуты и дропдауны.

5️⃣ Далее молекулы - совокупность атомов, например карточка, состоящая из текста, инпутов и кнопок. При работе с ними важно учитывать принцип универсальности и гибкости. Например, если карточка растягивается, то текст должен растягиваться вместе с ней, а кнопки должны передвигаться к левому краю, как это было изначально, а не оставаться где-то в центре. Автолейауты в Figma вам в помощь (еще одна интересная тема и повод поставить палец вверх 😉).

6️⃣ Организмы - совокупность молекул, кэп. Например, таблица, состоящая из молекул - колонок и хедера, а те в свою очередь состоят из атомов - текста, кнопок, тегов, иконок и т.д. Правило гибкости и универсальности здесь также применимо. Это касается ни только расширения, но и замены атомов внутри компонента. Для этого в Figma есть сеты компонентов (даю слово - я не хотел, но это еще одна статейка 🙈).

7️⃣ UI кит - это череда бесконечных итераций. Его всегда нужно дополнять или чистить до тех пор, пока проект в процессе разработки. Это нормально и боятся этого не стоит. Но чем больше вы предусмотрите на начальном этапе, тем меньше времени у вас будет уходить в итоге.

8️⃣ Передача в разработку. Необходимо правильно называть компоненты и стили. У каждого компонента есть свое название, которое используется дизайнерами и разработчикам.

Если вам повезло работать в продуктовой команде, то всегда можно договориться на берегу и определиться с терминологией - «дропдаун» это или «выпадашка» 🤷. Но всё же рекомендую называть элементы по-английски. Разработчики используют в коде англоязычные названия, поэтому так будет проще всем вам.
Не забывайте про комментарии с описанием того или иного компонента. Экономьте время и нервы друг друга 🙌.

🎯 Резюмируем:

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


P.S. Если интересен разбор самых распространенных компонентов UI кита, их состояния, а также настройка стилей ставьте реакцию 🔥, а я накидаю статью или даже цикл статей на эту тему.

5АМ | #разработка

Цепочка производства

В юности, когда учился в Академии, я занимался предпринимательским онанизмом 😁 Делал услуги обработки фотографий для фотографов, собирал подарки дамам к 8 марта и бегал продавал их по площади, продавали pdf книги на амазон, у которых срок авторства истек ахах (схемки-кабанчики), сделал пачку футболок с прикольным, как мне казалось, принтом и шуршал продавал их по шоурумам. Как сейчас помню - тащу этот огромный рулон вискозно-хлопковой ткани на плече и думаю, что "ну ни хера я - дядя". В футболках было первое ощущение цепочки производства: закуп, пошив, принт и упаковка.

А потом случился кнек (knaek). Это приколюха из Амстердама, суть которой заключается в том, что между двумя магнитами размером с дебетовую карту размещается сложенный гармошкой буклет со скидками и купонами всяких магазинов, пиццерий и кафешек. Я загорелся и это был мой первый проект, в котором я начал считать экономику и разговаривать с производством: печать, магниты, упаковка и так далее. Тут был второй опыт цепочки производства.

И на этом мой онанизм не закончился. Я сделал продукт для продажи на Амазон. Это были эластичные бинты в упаковках в виде картонных тубусов. Бизнес план на 85 страниц, сайт, бренд, поставки 2к бинтов в Америку после сборки их в трех заводах в Китае, короче... Заморочь. Это третий опыт понимания цепи производства, которая была уже гораздо длиннее.

При разработке 3D проектов цепочка чувствовалась, но не так сильно, т.к. команда была не большая 3-4 человека и аутсорс. Но вот с Локео все поменялось... Тут стало понятно, что для производства ПО цепочка производства тоже длинная и связи/швы между направлениями сильно страдают, если их не смазывать своим/нанятым менеджментом. Благо уже 6 лет опыта в ИТ и столько же в загородке.

Цепочка производства крупного ПО:

1. Разработка продукта, видения, экономики.
2. Бизнес анализ существующих процессов клиентов
3. Разработка требований и системный анализ разных направлений: бэк, бд, фронт.
4. Продуктовый дизайн: сценарии, точки входа, глобальные компоненты.
5. UX/UI дизайн: разработка вайерфреймов, макетов, кита.
6. Разработка фронта
7. Тестирование
8. Деплой

Сложности:
- Фронт веб и мобильный различается, поэтому это фактически разветвление процесса производства
- Красной нитью идет управление: планирование, приоритизация, синкование, расчет и прочее "смазывание".
- Каждый пункт может быть расщеплен на такие вещи как тех. писатель, ux писатель, скрам мастера и т.д.
- Чтобы команда могла отвечать за сроки должен быть хоть один участник команды "у виртуального станка" иначе отвечать за сроки не выйдет.

🔥- Рассказать нюансы про цепочку производства в ИТ
👍- Давай другие темы

5АМ | #разработка

Фрактальное проектирование

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

Ранее я писал про процесс проектирования:

запрос → гипотеза → процесс → данные → процедуры → требования

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

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

Большая проблема проектирования - это проблема "спуска".

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

Фрактал - это объект, имеющий свойство самаподобия, то есть в точности похож на свою часть.

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

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

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

5АМ | #разработка

Однополостной гиперболоид или пересборка

Мне понравился образ из геометрии, который хорошо показывает как бизнес и системный анализ связаны друг с другом. Разберем.

Анализ - мы смотрим на что-то и разделяем это что-то на мелкие части, чтобы их изучить. Зачем? - Сделать вывод.

Синтез - исходя из сделанных выводов мы собираем из этих частей что-то новое.

Только исходя из этого я называл бы вакансии аналитиков: бизнес и системный синтезатор 😆 Ибо хер ли ты на анализировал, если не синтезировал.

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

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

Когда БА собрал процесс, который несет деньги, он выводит требования: какие люди и системы должны его выполнять, каким образом и с какими затратами.

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

Системный анализ(СА) имеет разный уклон - СА с уклоном в веб интерфейс, СА с уклоном в хранение данных в БД, СА с уклоном в программные операции.

Главная задача системы - обрабатывать данные. Значит самое главное из анализа - это синтез операций, выполняемые программой или человеком, чтобы эти данные обработать.

БА - формирует крупные сущности данных. СА с уклоном в веб/мобилу - группирует данные в сценарии пользователя. СА с уклоном в БД - расщепляет данные из сценариев на мелкие структуры. СА с уклоном в программные операции преобразует данные из БД в новые данные = польза = деньги.

Однополосный гиперболоид. Почему?
Верхняя часть воронки это БА: мы собираем, разделяем, потом собираем обратно.
Нижняя часть СА: берет из воронки синтез и расщепляет делает анализ под себя на свои слои: пользователский, БД, программный.

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

5АМ | #разработка

Как делать быстро и хорошо?

Читаю канал Леонида Лапидуса, постит крутые адекватные вещи. Поднял извечную тему что нужно делать продукты быстрее. Тема меня трогает каждый раз, т.к. для каждого собственника и продакта это такой смачный лещ всегда: "а ну, черт, че так медленно то, а?".

Не спорю, но я всегда за "как". Мои рекомендации как в логике разработки ИТ продуктов:

1. Считать деньги
Первое и важное, нужно найти границы продукта, за который человек готов ТОЧНО и МИНИМУМ заплатить. Это всегда сложная задача, которая требует навыка отделения мух от котлет, все нужно ставить под сомнение. Каждая фича допустим "темная тема" или "центр уведомлений", должна проходить проверку на "это просто прикольно или пользователю это нужно". Каждая фича стоит часа бэка, диза, фронта, тестера - херак и уже 100к на чушь ушло. Таблица с подсчетом денег - это первое, что нужно видеть каждый гребаный день (в воскресение тоже желательно).

2. Параллельно проектировать
Поставил границы начинаешь проектировать итерировано. Бэк отдельно, фронт отдельно, дизайн отдельно. Каждый дешево обогащает друг друга знание о продукте. Помним и держим в голове: "Я сейчас проектирую, чтобы выпендриться как это сложно или это нужно клиенту?" Убираем все, что не относится к границам, все что их расширяет, даже микро поле для ввода, лишний фильтр, лишний дропдаун может лупануть вам пощечину и уже невозможно откатить - опять затраты, опять долго, опять не хорошо.

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

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

Псих-рекомнедации:
1. Все делают сначала хреново. Просто кто-то на более поздних итерациях и уже имеет бОльшие ресурсы и результаты чем у тебя.
2. Для каждой ниши разное быстро и разное хорошо.
3. Дели, критично и безжалостно отклеивай одно от другого. Разделяй и властвуй.

5АМ | #разработка

Про хештеги канала

Как пользоваться: нажимаете на хештег → в списке нажимаете на мой канал → читаем посты по теме тега.

Рубрика - экспертные
#разработка - как делать ПО
#управление - командой
#предпринимательство - о бизнесе
#загородом - про недвижимость
#компания - и её процессы
#стартап - как их делать

Рубрика - легкое
#цитаты - любимое 🙂
#мемы - поржать
#life - узнать меня поближе

Рубрика - полезное
#философия - сознания и ИИ
#мотивация - и заряд энергией
#рекомендации - как действовать
#развитие - своей личности

Рубрика - от компании
#вакансии - к нам в команду
#кейсы - что делала студия
#дайджест - крутые посты
#ретроспектива - подвожу итоги

5АМ | #дайджест