Таблица и дерево решений
Думаю, что самой крутой находкой для меня в этом году стал метод таблицы и дерева решений. Система - это состояния данных, а состояния - это условия, в рамках которых система или человек принимают решения.
На листочке можно вывести список возможных условий без слова "Если". Например, "Если лицевой счета активирован". Ниже под условиями даем список возможных процедур системы или человека, например "пополнить лицевой счет".
Допустим у вас 3 таких условия, логических значения всего 2: true или false, значит количество значений 2 в 3 степени или 8 возможных вариантов состояний системы. Возле каждого условия ставим галку да/нет и проверяем, реально ли следующее условие в списке условий, если у текущего стоит это значение. Так мы шаг за шагом находим реально возможные состояния системы. Их может быть 3-5. Для каждого такого состояния принимаем решение, что будет делать система или человек (какая процедура запускается) и ставим галку возле процедуры. Далее это легко переводится в самостоятельное требование, которое можно легко перевести в текст. Например, "система должна заблокировать операцию пополнения счета, если статус лицевого счета "закрыт".
Причем саму табличку не обязательно делать в экселе, можно накидать её в том же альбоме. Кстати, при желании и любви к схемам на основе таблицы можно легко выстроит схему)
5АМ | #разработка
Думаю, что самой крутой находкой для меня в этом году стал метод таблицы и дерева решений. Система - это состояния данных, а состояния - это условия, в рамках которых система или человек принимают решения.
На листочке можно вывести список возможных условий без слова "Если". Например, "Если лицевой счета активирован". Ниже под условиями даем список возможных процедур системы или человека, например "пополнить лицевой счет".
Допустим у вас 3 таких условия, логических значения всего 2: true или false, значит количество значений 2 в 3 степени или 8 возможных вариантов состояний системы. Возле каждого условия ставим галку да/нет и проверяем, реально ли следующее условие в списке условий, если у текущего стоит это значение. Так мы шаг за шагом находим реально возможные состояния системы. Их может быть 3-5. Для каждого такого состояния принимаем решение, что будет делать система или человек (какая процедура запускается) и ставим галку возле процедуры. Далее это легко переводится в самостоятельное требование, которое можно легко перевести в текст. Например, "система должна заблокировать операцию пополнения счета, если статус лицевого счета "закрыт".
Причем саму табличку не обязательно делать в экселе, можно накидать её в том же альбоме. Кстати, при желании и любви к схемам на основе таблицы можно легко выстроит схему)
5АМ | #разработка
👍11🔥4👀3❤2
Фича или сценарий
Пост для продактов через дизайнерскую призму. Сейчас расскажу вам ведьмины секреты квантового UX-а 😁
До меня очень долго доходил один момент, тонкий момент. То, что пользователь согласен купить, не является сценарием использования.
Нам с макро UX помогает Кнарик (я писал о ней, она мега крутой UX архитектор, ведет группу spb-designers). Я ей говорю: "вот у меня есть такие фичи, за них нам готовы платить, вот молят нас, чтобы у нас было вот это и вот это". А она, как крутой спец, меня - назойливого продакта, за шкирвотник тормозит и говорит: "отвали ты от меня со своими фичами, сценарии мне дай, сценарии☝️". И блииин, это круто, профессионал не спорит, он делает по-своему, зная какой нужен результат!
В чем вся проблема: бизнесу, выстраивая отдел проектирования ПО, невероятно легко запутаться в ролях команды проектирования, т.е. продакта, ux/ui дизайнера, аналитика и прод. дизайнера(ux архитектора), поэтому часто возникает так "пусть все это делает продакт Вася и дизайнер Анатолий" и у обоих образуется раздвоение личностей и нервный тик. Все это до кучи усложняется тем, что в BPM системах важен не только микро UX, т.е. где должна стоять кнопочка функции, чтобы было удобно пройти/выполнить действие, но и макро UX, т.е. какие сценарии есть и какие у них точки входа, глубина вложений, движения по ссылкам, глобальное преобразование данных пользователя.
Я не знаю только у меня ли это как у продакта (поделитесь), но думать фичами - это проф. деформация. Фичи покупают, но пользуются сценариями. На сценарии говорят "говно дизайн, не удобно".
Как нужно работать, чтобы было "ммм, удобненько так", загибаем пальцы: раз, почуять, что орут о фиче, два, выслушать пользовательскую околесицу и услышать боль, три, преобразовать околесицу в понятную модель данных с компилирующимся процессом (вход-выход нормально отрабатывает), четыре, превратить околесицу и процесс в логичный сценарий, пять, надеяться, что ты сделал то, что нужно, сидя и трясясь за спиной пользователя на юзабилити тестировании. Первый в цепочке продакт, он слышит боль, пытается через фичу увидеть боль, но проектировать систему уже нужно сценариями. Сначала, к сожалению, придется дергать переключатели ролей в своей голове, пока не получится заработать на проектную команду за дорого))
5АМ | #разработка
Пост для продактов через дизайнерскую призму. Сейчас расскажу вам ведьмины секреты квантового UX-а 😁
До меня очень долго доходил один момент, тонкий момент. То, что пользователь согласен купить, не является сценарием использования.
Нам с макро UX помогает Кнарик (я писал о ней, она мега крутой UX архитектор, ведет группу spb-designers). Я ей говорю: "вот у меня есть такие фичи, за них нам готовы платить, вот молят нас, чтобы у нас было вот это и вот это". А она, как крутой спец, меня - назойливого продакта, за шкирвотник тормозит и говорит: "отвали ты от меня со своими фичами, сценарии мне дай, сценарии☝️". И блииин, это круто, профессионал не спорит, он делает по-своему, зная какой нужен результат!
В чем вся проблема: бизнесу, выстраивая отдел проектирования ПО, невероятно легко запутаться в ролях команды проектирования, т.е. продакта, ux/ui дизайнера, аналитика и прод. дизайнера(ux архитектора), поэтому часто возникает так "пусть все это делает продакт Вася и дизайнер Анатолий" и у обоих образуется раздвоение личностей и нервный тик. Все это до кучи усложняется тем, что в BPM системах важен не только микро UX, т.е. где должна стоять кнопочка функции, чтобы было удобно пройти/выполнить действие, но и макро UX, т.е. какие сценарии есть и какие у них точки входа, глубина вложений, движения по ссылкам, глобальное преобразование данных пользователя.
Я не знаю только у меня ли это как у продакта (поделитесь), но думать фичами - это проф. деформация. Фичи покупают, но пользуются сценариями. На сценарии говорят "говно дизайн, не удобно".
Как нужно работать, чтобы было "ммм, удобненько так", загибаем пальцы: раз, почуять, что орут о фиче, два, выслушать пользовательскую околесицу и услышать боль, три, преобразовать околесицу в понятную модель данных с компилирующимся процессом (вход-выход нормально отрабатывает), четыре, превратить околесицу и процесс в логичный сценарий, пять, надеяться, что ты сделал то, что нужно, сидя и трясясь за спиной пользователя на юзабилити тестировании. Первый в цепочке продакт, он слышит боль, пытается через фичу увидеть боль, но проектировать систему уже нужно сценариями. Сначала, к сожалению, придется дергать переключатели ролей в своей голове, пока не получится заработать на проектную команду за дорого))
5АМ | #разработка
❤8👍7❤🔥5🔥5
Привет, на связи Сергей!
Я тут у нас рулю всей тех. частью. Клим, попросил меня написать мои соображения по теме микросервисов)
Его душность конечно ничего не переплюнет, но я попробую😁 Поехали)
Не реализуйте микросервисы без понимания, какую задачу они призваны решить в вашем приложении
Микросервисная архитектура выглядит очень логично, понятно и соблазнительно. Она может показаться чем-то сродни конструктору лего, где каждая деталь (микросервис) легковесная, независимая, взаимозаменяемая.
Почему так кажется:
🟣 Каждый отдельный микросервис может быть написан на своём языке или использовать свой фреймворк
🟣 Под каждый отдельный микросервис или группу микросервисов можно определить свою полуавтономную команду разработки
🟣 Каждый микросервис может быть отмасштабирован и висеть в любой точке мира
На бумаге это всё выглядит гладко, а на деле скорее всего получится, что усилия по реализации и поддержанию микросервисов совершенно не будут равноценны полученному результату и могут быть даже причиной гибели проекта из-за чрезмерно раздутых издержек.
Так что же может пойти не так?🔽 🔽 🔽
5АМ | #разработка
Я тут у нас рулю всей тех. частью. Клим, попросил меня написать мои соображения по теме микросервисов)
Его душность конечно ничего не переплюнет, но я попробую😁 Поехали)
Не реализуйте микросервисы без понимания, какую задачу они призваны решить в вашем приложении
Микросервисная архитектура выглядит очень логично, понятно и соблазнительно. Она может показаться чем-то сродни конструктору лего, где каждая деталь (микросервис) легковесная, независимая, взаимозаменяемая.
Почему так кажется:
На бумаге это всё выглядит гладко, а на деле скорее всего получится, что усилия по реализации и поддержанию микросервисов совершенно не будут равноценны полученному результату и могут быть даже причиной гибели проекта из-за чрезмерно раздутых издержек.
Так что же может пойти не так?
5АМ | #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤2💯1
1️⃣ Дерево непрямых зависимостей
Вместо набора независимых микросервисов вы, скорее всего, получите дерево непрямых зависимостей между микросервисами. С высокой долей вероятности потребуется, чтобы микросервисы коммуницировали между собой. Для такой коммуникации придётся определять контракты и периодически их поддерживать, если что-то изменилось в одном из микросервисов.
2️⃣ Можно забыть об ACID
Атомарность и подлинная целостность данных не дружат с микросервисами. Условно, если у вас идёт распределенная транзакция на заказ товара, которая должна пробежаться по микросервисам заказов, оплаты, отгрузки и т.д., то при возникновении ошибки на каком-то этапе транзакция будет частично выполненной и нужен будет программно реализуемый откат. С ACID - у вас либо транзакция выполняется, либо нет;
3️⃣ Прочесть дорого
Многочастотные операции чтения для иерархических данных, которые должны собираться со многих микросервисов, могут сделать вам очень больно, особенно если микросервисы реализованы канонично с отдельными приватными БД;
4️⃣ Очень высокие требования к экспертизе предметной области
Особенно в плане разделения приложения на ограниченные контексты (bounded contexts). Если продукт сложный, то у вас по сути не будет права на ошибку, поскольку её стоимость будет чрезвычайно высокой. Соответственно, новый сложный продукт + недостаточная степень экспертизы в предметной области или размытость этой области = практически 100% вероятность возникновения такой ошибки;
5️⃣ Команды - клубы
Команды разработки над отдельным микросервисом или группой микросервисов имеют тенденцию превращаться в полузакрытые клубы, но при этом эти клубы должны в идеале коммуницировать между собой так, чтобы постоянно двигать вперёд продукт в целом.
Зачастую много времени будет уходить на организационные и технические задачи, которые не имеют прямого отношения к продукту.
Вместо предполагаемого ускорения разработки ("у нас же параллельные команды!") - получаем замедление и удорожание;
6️⃣ Тестирование
Интеграционное тестирование микросервисов, т.е. такое тестирование, которое затрагивает функциональность приложения в целом, чрезвычайно сложно реализуемо.
Вместо запуска такого тестирования по одной кнопке, вам придётся собирать космический корабль😁;
7️⃣Деплой
Затем вы переходите к деплою и тут вы поймете, почему при микросервисном подходе зачастую существуют отдельные и дорогие devops-команды.
К абсолютно каждому пункту можно привести разумные и логичные контраргументы, но они будут сводиться к тому, что нужно приложить дополнительные усилия и дополнительное время, чтобы вся эта система работала.
Это очень даже возможно разрешить все вышеперечисленные проблемы в достаточной мере, но скорее всего вы не Netflix, не Amazon и не Instagram, чтобы а) иметь достаточные ресурсы для этого; б) иметь в целом высокую потребность в микросервисной архитектуре.😎
Тогда что вместо этого?
Если начинаете с нуля, то разрабатывайте хорошо скроенный монолит для проверки гипотезы.
И только потом полноценную модульную архитектуру (модулит), которую со временем можно отмасштабировать.
Например, если у вас SaaS-ориентированное приложение, то можно создать нескольких инстанций приложения на каждого тенанта или группу тенантов, возможно с распределенной физически и логически БД на каждую инстанцию.
В 90% случаев плохая отзывчивость приложения и его медленная работа будет сводиться к тому, как приложение взаимодействует с БД, насколько оптимизированы как сама БД, так и запросы к ней.
Могут быть нередки случаи, когда банальная оптимизация SQL-запроса может повысить его производительность в сотни-тысячи раз.
Если ваше узкое место БД - то микросервисы вам не помогут, только навредят. Не убивайте себя сложностью, которую вы сами придумываете. Не переносите бездумно опыт крупных корпоративных продуктов с микросервисной архитектурой на свой продукт.
Хуже и сложнее плохого монолита может быть только плохая распределенная архитектура. 🎩
5АМ | #разработка
Вместо набора независимых микросервисов вы, скорее всего, получите дерево непрямых зависимостей между микросервисами. С высокой долей вероятности потребуется, чтобы микросервисы коммуницировали между собой. Для такой коммуникации придётся определять контракты и периодически их поддерживать, если что-то изменилось в одном из микросервисов.
2️⃣ Можно забыть об ACID
Атомарность и подлинная целостность данных не дружат с микросервисами. Условно, если у вас идёт распределенная транзакция на заказ товара, которая должна пробежаться по микросервисам заказов, оплаты, отгрузки и т.д., то при возникновении ошибки на каком-то этапе транзакция будет частично выполненной и нужен будет программно реализуемый откат. С ACID - у вас либо транзакция выполняется, либо нет;
3️⃣ Прочесть дорого
Многочастотные операции чтения для иерархических данных, которые должны собираться со многих микросервисов, могут сделать вам очень больно, особенно если микросервисы реализованы канонично с отдельными приватными БД;
4️⃣ Очень высокие требования к экспертизе предметной области
Особенно в плане разделения приложения на ограниченные контексты (bounded contexts). Если продукт сложный, то у вас по сути не будет права на ошибку, поскольку её стоимость будет чрезвычайно высокой. Соответственно, новый сложный продукт + недостаточная степень экспертизы в предметной области или размытость этой области = практически 100% вероятность возникновения такой ошибки;
5️⃣ Команды - клубы
Команды разработки над отдельным микросервисом или группой микросервисов имеют тенденцию превращаться в полузакрытые клубы, но при этом эти клубы должны в идеале коммуницировать между собой так, чтобы постоянно двигать вперёд продукт в целом.
Зачастую много времени будет уходить на организационные и технические задачи, которые не имеют прямого отношения к продукту.
Вместо предполагаемого ускорения разработки ("у нас же параллельные команды!") - получаем замедление и удорожание;
6️⃣ Тестирование
Интеграционное тестирование микросервисов, т.е. такое тестирование, которое затрагивает функциональность приложения в целом, чрезвычайно сложно реализуемо.
Вместо запуска такого тестирования по одной кнопке, вам придётся собирать космический корабль😁;
7️⃣Деплой
Затем вы переходите к деплою и тут вы поймете, почему при микросервисном подходе зачастую существуют отдельные и дорогие devops-команды.
К абсолютно каждому пункту можно привести разумные и логичные контраргументы, но они будут сводиться к тому, что нужно приложить дополнительные усилия и дополнительное время, чтобы вся эта система работала.
Это очень даже возможно разрешить все вышеперечисленные проблемы в достаточной мере, но скорее всего вы не Netflix, не Amazon и не Instagram, чтобы а) иметь достаточные ресурсы для этого; б) иметь в целом высокую потребность в микросервисной архитектуре.😎
Тогда что вместо этого?
Если начинаете с нуля, то разрабатывайте хорошо скроенный монолит для проверки гипотезы.
И только потом полноценную модульную архитектуру (модулит), которую со временем можно отмасштабировать.
Например, если у вас SaaS-ориентированное приложение, то можно создать нескольких инстанций приложения на каждого тенанта или группу тенантов, возможно с распределенной физически и логически БД на каждую инстанцию.
В 90% случаев плохая отзывчивость приложения и его медленная работа будет сводиться к тому, как приложение взаимодействует с БД, насколько оптимизированы как сама БД, так и запросы к ней.
Могут быть нередки случаи, когда банальная оптимизация SQL-запроса может повысить его производительность в сотни-тысячи раз.
Если ваше узкое место БД - то микросервисы вам не помогут, только навредят. Не убивайте себя сложностью, которую вы сами придумываете. Не переносите бездумно опыт крупных корпоративных продуктов с микросервисной архитектурой на свой продукт.
Хуже и сложнее плохого монолита может быть только плохая распределенная архитектура. 🎩
5АМ | #разработка
🔥12❤4👍2🌚1
Привет, на связи Стас!
Сегодня поговорим о UI ките.
Вроде все просто, но если посмотреть глубже - это огромная боль дизайнеров и разработчиков.
Для начала предлагаю разобраться что это за зверь такой 🐳 и с чем его едят? (веганы, вегетарианцы, пескетарианцы и т.д., прошу не волноваться - ни одно живое существо не пострадало, наверное.. 🤔).
UI кит часто путают с дизайн-системой.
Дизайн система - это комплексный подход, содержащий всю информацию о проекте: набор стандартов, компоненты, анимация и даже редполитика.
UI кит - набор компонентов, цветов, шрифтов, сеток. Одним словом - то, из чего собирается интерфейс и только интерфейс. Если говорить о крупных проектах со своей дизайн системой, то UI кит есть неотъемлемая часть этой системы.
Так зачем он нужен? Рассмотрим ниже)
5АМ | #разработка
Сегодня поговорим о UI ките.
Вроде все просто, но если посмотреть глубже - это огромная боль дизайнеров и разработчиков.
Для начала предлагаю разобраться что это за зверь такой 🐳 и с чем его едят? (веганы, вегетарианцы, пескетарианцы и т.д., прошу не волноваться - ни одно живое существо не пострадало, наверное.. 🤔).
UI кит часто путают с дизайн-системой.
Дизайн система - это комплексный подход, содержащий всю информацию о проекте: набор стандартов, компоненты, анимация и даже редполитика.
UI кит - набор компонентов, цветов, шрифтов, сеток. Одним словом - то, из чего собирается интерфейс и только интерфейс. Если говорить о крупных проектах со своей дизайн системой, то UI кит есть неотъемлемая часть этой системы.
Так зачем он нужен? Рассмотрим ниже)
5АМ | #разработка
❤7👍2👎2🔥2
UI кит - это то, что гарантирует согласованность в интерфейсе.
🟣 Экономия времени
Повторяющиеся компоненты: кнопки или большие блоки, стоит отрисовать один раз, и далее использовать в интерфейсе, меняя лишь контент. А в случае правок - достаточно произвести изменения лишь в мастер-компоненте и не придется вручную вносить изменения на каждой странице.
🟣 Согласованность и системность
Хороший совет, который мне дала моя бабушка 🥰: «Не полагайся на свою память - фиксируй на бумаге». Переношу смысл - прописав (отрисовав) все отступы, размеры, цвета и т.д., вам не придется держать все эти значения в голове. В качестве бонуса вы получите чистый и системный дизайн.
🟣 Разработка
Разработчики скажут вам спасибо, что им не пришлось ломать голову над «почему здесь так? а там по другому?» И главное - они смогут увидеть все состояния и поведение элементов и не будут выдумывать что-то свое, о чем дизайнер не подумал.
Ходит слушок, что UI кит нужен только крупным проектам. Он может быть небольшим, но на каждом проекте должен быть хотя-бы базовый набор элементов и состояний. Исключением может быть небольшой лендинг, так сказать, на скорую руку и без планов на расширение.
Какие есть этапы создания кита:
1️⃣Сначала стоит определиться с концептом, накидав главную и пару второстепенных страниц. Покажите максимум деталей, чтобы понять каким будет проект.
2️⃣ Затем цвета, типографика, иконки, сетка и система отступов.
3️⃣ Все слышали про атомарный подход? Если нет - ставьте пальцы вверх, раскроем эту тему в следующей статье. Коротко - дизайн состоит из атомов, молекул, организмов, блоков, страниц. Сейчас затронем первые три.
4️⃣Атомы))
Это кнопки (основные, второстепенные, текстовые, кнопка-иконка) и контролы (чекбоксы, ради баттоны, переключатели, табы, ссылки), а также инпуты и дропдауны.
5️⃣ Далее молекулы - совокупность атомов, например карточка, состоящая из текста, инпутов и кнопок. При работе с ними важно учитывать принцип универсальности и гибкости. Например, если карточка растягивается, то текст должен растягиваться вместе с ней, а кнопки должны передвигаться к левому краю, как это было изначально, а не оставаться где-то в центре. Автолейауты в Figma вам в помощь (еще одна интересная тема и повод поставить палец вверх 😉).
6️⃣ Организмы - совокупность молекул, кэп. Например, таблица, состоящая из молекул - колонок и хедера, а те в свою очередь состоят из атомов - текста, кнопок, тегов, иконок и т.д. Правило гибкости и универсальности здесь также применимо. Это касается ни только расширения, но и замены атомов внутри компонента. Для этого в Figma есть сеты компонентов (даю слово - я не хотел, но это еще одна статейка 🙈).
7️⃣ UI кит - это череда бесконечных итераций. Его всегда нужно дополнять или чистить до тех пор, пока проект в процессе разработки. Это нормально и боятся этого не стоит. Но чем больше вы предусмотрите на начальном этапе, тем меньше времени у вас будет уходить в итоге.
8️⃣ Передача в разработку. Необходимо правильно называть компоненты и стили. У каждого компонента есть свое название, которое используется дизайнерами и разработчикам.
Если вам повезло работать в продуктовой команде, то всегда можно договориться на берегу и определиться с терминологией - «дропдаун» это или «выпадашка» 🤷. Но всё же рекомендую называть элементы по-английски. Разработчики используют в коде англоязычные названия, поэтому так будет проще всем вам.
Не забывайте про комментарии с описанием того или иного компонента. Экономьте время и нервы друг друга 🙌.
🎯 Резюмируем:
✅ Любому, даже небольшому проекту нужен UI кит и чем раньше об этом позаботиться, тем лучше будет в конечном итоге.
✅ Всё, что повторяется больше одного раза - это компонент. Чем больше компонентов - тем меньше затраченного времени, сил и нервов.
✅ Гибкость и универсальность - главные составляющие правильного компонента.
P.S. Если интересен разбор самых распространенных компонентов UI кита, их состояния, а также настройка стилей ставьте реакцию 🔥, а я накидаю статью или даже цикл статей на эту тему.
5АМ | #разработка
🟣 Экономия времени
Повторяющиеся компоненты: кнопки или большие блоки, стоит отрисовать один раз, и далее использовать в интерфейсе, меняя лишь контент. А в случае правок - достаточно произвести изменения лишь в мастер-компоненте и не придется вручную вносить изменения на каждой странице.
🟣 Согласованность и системность
Хороший совет, который мне дала моя бабушка 🥰: «Не полагайся на свою память - фиксируй на бумаге». Переношу смысл - прописав (отрисовав) все отступы, размеры, цвета и т.д., вам не придется держать все эти значения в голове. В качестве бонуса вы получите чистый и системный дизайн.
🟣 Разработка
Разработчики скажут вам спасибо, что им не пришлось ломать голову над «почему здесь так? а там по другому?» И главное - они смогут увидеть все состояния и поведение элементов и не будут выдумывать что-то свое, о чем дизайнер не подумал.
Ходит слушок, что UI кит нужен только крупным проектам. Он может быть небольшим, но на каждом проекте должен быть хотя-бы базовый набор элементов и состояний. Исключением может быть небольшой лендинг, так сказать, на скорую руку и без планов на расширение.
Какие есть этапы создания кита:
1️⃣Сначала стоит определиться с концептом, накидав главную и пару второстепенных страниц. Покажите максимум деталей, чтобы понять каким будет проект.
2️⃣ Затем цвета, типографика, иконки, сетка и система отступов.
3️⃣ Все слышали про атомарный подход? Если нет - ставьте пальцы вверх, раскроем эту тему в следующей статье. Коротко - дизайн состоит из атомов, молекул, организмов, блоков, страниц. Сейчас затронем первые три.
4️⃣Атомы))
Это кнопки (основные, второстепенные, текстовые, кнопка-иконка) и контролы (чекбоксы, ради баттоны, переключатели, табы, ссылки), а также инпуты и дропдауны.
5️⃣ Далее молекулы - совокупность атомов, например карточка, состоящая из текста, инпутов и кнопок. При работе с ними важно учитывать принцип универсальности и гибкости. Например, если карточка растягивается, то текст должен растягиваться вместе с ней, а кнопки должны передвигаться к левому краю, как это было изначально, а не оставаться где-то в центре. Автолейауты в Figma вам в помощь (еще одна интересная тема и повод поставить палец вверх 😉).
6️⃣ Организмы - совокупность молекул, кэп. Например, таблица, состоящая из молекул - колонок и хедера, а те в свою очередь состоят из атомов - текста, кнопок, тегов, иконок и т.д. Правило гибкости и универсальности здесь также применимо. Это касается ни только расширения, но и замены атомов внутри компонента. Для этого в Figma есть сеты компонентов (даю слово - я не хотел, но это еще одна статейка 🙈).
7️⃣ UI кит - это череда бесконечных итераций. Его всегда нужно дополнять или чистить до тех пор, пока проект в процессе разработки. Это нормально и боятся этого не стоит. Но чем больше вы предусмотрите на начальном этапе, тем меньше времени у вас будет уходить в итоге.
8️⃣ Передача в разработку. Необходимо правильно называть компоненты и стили. У каждого компонента есть свое название, которое используется дизайнерами и разработчикам.
Если вам повезло работать в продуктовой команде, то всегда можно договориться на берегу и определиться с терминологией - «дропдаун» это или «выпадашка» 🤷. Но всё же рекомендую называть элементы по-английски. Разработчики используют в коде англоязычные названия, поэтому так будет проще всем вам.
Не забывайте про комментарии с описанием того или иного компонента. Экономьте время и нервы друг друга 🙌.
🎯 Резюмируем:
✅ Любому, даже небольшому проекту нужен UI кит и чем раньше об этом позаботиться, тем лучше будет в конечном итоге.
✅ Всё, что повторяется больше одного раза - это компонент. Чем больше компонентов - тем меньше затраченного времени, сил и нервов.
✅ Гибкость и универсальность - главные составляющие правильного компонента.
P.S. Если интересен разбор самых распространенных компонентов UI кита, их состояния, а также настройка стилей ставьте реакцию 🔥, а я накидаю статью или даже цикл статей на эту тему.
5АМ | #разработка
🔥15❤3👍2💩2
Продуктовая команда разработки
Наш первый пост из категории #light.
Мы уже состоявшаяся команда, но так было не всегда. Мы с Серегой прошли все: от "нас двоих хватит" до "давай чтобы было многа-многа людей".
Так кто нужен?
🟣 Owner - собственник стартапа, выполняет функции визионера, распределителя приоритетов, отвечает за связь с клиентом. Он тянет первые продажи и маркетинг, взаимодействует с инвесторами. Главный архитектор с точки зрения бизнеса и пользователей. Он и product manager и product owner и seller и product marketing manager и просто хороший человек, который на всех орёт))
🟣 CTO - архитектор backend-а и баз данных, главный за программную логику приложения, обработку данных. Как правило сособственник компании. Без него никуда)
🟣 BA/SA - бизнес аналитик / системный аналитик. Та, роль, которая структурировано переводит мешанину видения и архитектуры этих двух человек на понятный остальным язык требований.
🟣 Product designer - свяжет предыдущих трех в единую архитектуру продукта с точки зрения сценариев пользователей. Заложит карту точек входа, глобальный и локальный UX приложения.
🟣 Project manager - руководитель проектов, следит за исполнением задачек, ставит таски, организует и коннектит, чтобы все было во время.
🟣 UX/UI Designer - рисует дизайн: UI-kit, макеты, прототипы для фронтов.
🟣 Middle Backend developer - разрабатывает возможности серверной логики, помогает CTO.
🟣 Senior Frontend (web) developer - разрабатывает архитектуру сайта, создает самые тяжелые возможности приложения.
🟣 Middle Frontend (web) developer - создает возможности сайта, разгружает сеньора.
🟣 Senior Frontend (mobile) developer - разрабатывает архитектуру мобильного приложения, создает самые тяжелые возможности приложения.
🟣 Middle Frontend (mobile) developer - создает возможности приложения, разгружает сеньора.
🟣 QA-инженер - тестирует всё это безобразие, отвечает за то, чтобы все поставлялось без багов и чётенько.
Было бы неплохо баристу и массажиста еще, но это жирно😄
5АМ | #разработка
Наш первый пост из категории #light.
Мы уже состоявшаяся команда, но так было не всегда. Мы с Серегой прошли все: от "нас двоих хватит" до "давай чтобы было многа-многа людей".
Так кто нужен?
Было бы неплохо баристу и массажиста еще, но это жирно😄
5АМ | #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14🔥3😁2👏1
Цепочка производства
В юности, когда учился в Академии, я занимался предпринимательским онанизмом 😁 Делал услуги обработки фотографий для фотографов, собирал подарки дамам к 8 марта и бегал продавал их по площади, продавали pdf книги на амазон, у которых срок авторства истек ахах (схемки-кабанчики), сделал пачку футболок с прикольным, как мне казалось, принтом и шуршал продавал их по шоурумам. Как сейчас помню - тащу этот огромный рулон вискозно-хлопковой ткани на плече и думаю, что "ну ни хера я - дядя". В футболках было первое ощущение цепочки производства: закуп, пошив, принт и упаковка.
А потом случился кнек (knaek). Это приколюха из Амстердама, суть которой заключается в том, что между двумя магнитами размером с дебетовую карту размещается сложенный гармошкой буклет со скидками и купонами всяких магазинов, пиццерий и кафешек. Я загорелся и это был мой первый проект, в котором я начал считать экономику и разговаривать с производством: печать, магниты, упаковка и так далее. Тут был второй опыт цепочки производства.
И на этом мой онанизм не закончился. Я сделал продукт для продажи на Амазон. Это были эластичные бинты в упаковках в виде картонных тубусов. Бизнес план на 85 страниц, сайт, бренд, поставки 2к бинтов в Америку после сборки их в трех заводах в Китае, короче... Заморочь. Это третий опыт понимания цепи производства, которая была уже гораздо длиннее.
При разработке 3D проектов цепочка чувствовалась, но не так сильно, т.к. команда была не большая 3-4 человека и аутсорс. Но вот с Локео все поменялось... Тут стало понятно, что для производства ПО цепочка производства тоже длинная и связи/швы между направлениями сильно страдают, если их не смазывать своим/нанятым менеджментом. Благо уже 6 лет опыта в ИТ и столько же в загородке.
Цепочка производства крупного ПО:
1. Разработка продукта, видения, экономики.
2. Бизнес анализ существующих процессов клиентов
3. Разработка требований и системный анализ разных направлений: бэк, бд, фронт.
4. Продуктовый дизайн: сценарии, точки входа, глобальные компоненты.
5. UX/UI дизайн: разработка вайерфреймов, макетов, кита.
6. Разработка фронта
7. Тестирование
8. Деплой
Сложности:
- Фронт веб и мобильный различается, поэтому это фактически разветвление процесса производства
- Красной нитью идет управление: планирование, приоритизация, синкование, расчет и прочее "смазывание".
- Каждый пункт может быть расщеплен на такие вещи как тех. писатель, ux писатель, скрам мастера и т.д.
- Чтобы команда могла отвечать за сроки должен быть хоть один участник команды "у виртуального станка" иначе отвечать за сроки не выйдет.
🔥- Рассказать нюансы про цепочку производства в ИТ
👍- Давай другие темы
5АМ | #разработка
В юности, когда учился в Академии, я занимался предпринимательским онанизмом 😁 Делал услуги обработки фотографий для фотографов, собирал подарки дамам к 8 марта и бегал продавал их по площади, продавали pdf книги на амазон, у которых срок авторства истек ахах (схемки-кабанчики), сделал пачку футболок с прикольным, как мне казалось, принтом и шуршал продавал их по шоурумам. Как сейчас помню - тащу этот огромный рулон вискозно-хлопковой ткани на плече и думаю, что "ну ни хера я - дядя". В футболках было первое ощущение цепочки производства: закуп, пошив, принт и упаковка.
А потом случился кнек (knaek). Это приколюха из Амстердама, суть которой заключается в том, что между двумя магнитами размером с дебетовую карту размещается сложенный гармошкой буклет со скидками и купонами всяких магазинов, пиццерий и кафешек. Я загорелся и это был мой первый проект, в котором я начал считать экономику и разговаривать с производством: печать, магниты, упаковка и так далее. Тут был второй опыт цепочки производства.
И на этом мой онанизм не закончился. Я сделал продукт для продажи на Амазон. Это были эластичные бинты в упаковках в виде картонных тубусов. Бизнес план на 85 страниц, сайт, бренд, поставки 2к бинтов в Америку после сборки их в трех заводах в Китае, короче... Заморочь. Это третий опыт понимания цепи производства, которая была уже гораздо длиннее.
При разработке 3D проектов цепочка чувствовалась, но не так сильно, т.к. команда была не большая 3-4 человека и аутсорс. Но вот с Локео все поменялось... Тут стало понятно, что для производства ПО цепочка производства тоже длинная и связи/швы между направлениями сильно страдают, если их не смазывать своим/нанятым менеджментом. Благо уже 6 лет опыта в ИТ и столько же в загородке.
Цепочка производства крупного ПО:
1. Разработка продукта, видения, экономики.
2. Бизнес анализ существующих процессов клиентов
3. Разработка требований и системный анализ разных направлений: бэк, бд, фронт.
4. Продуктовый дизайн: сценарии, точки входа, глобальные компоненты.
5. UX/UI дизайн: разработка вайерфреймов, макетов, кита.
6. Разработка фронта
7. Тестирование
8. Деплой
Сложности:
- Фронт веб и мобильный различается, поэтому это фактически разветвление процесса производства
- Красной нитью идет управление: планирование, приоритизация, синкование, расчет и прочее "смазывание".
- Каждый пункт может быть расщеплен на такие вещи как тех. писатель, ux писатель, скрам мастера и т.д.
- Чтобы команда могла отвечать за сроки должен быть хоть один участник команды "у виртуального станка" иначе отвечать за сроки не выйдет.
🔥- Рассказать нюансы про цепочку производства в ИТ
👍- Давай другие темы
5АМ | #разработка
🔥21❤2🍓2👍1
Фрактальное проектирование
В больших системах при проектировании очень просто запутаться. Возникает большое количество сценариев и их вариаций. На систему можно смотреть в любой момент с абсолютно разного угла, и она везде будет разной. Как в таком состоянии проектировать систему с учетом последующего её усложнения, если видение продукта распространяется далеко за первую версию "из говна и палок".
Ранее я писал про процесс проектирования:
запрос → гипотеза → процесс → данные → процедуры → требования
Такой способ позволяет изначально заходить сверху и плавно спускаться вниз. Изначально, когда начал применять, получалось так, что я спускался с жестко продуктового запроса до конкретной процедуры в модели данных.
С повторением итераций начал видеть, что такой процесс может применяться на более мелкие части. То есть запрос может быть разным: от получения доп. дохода или снижения расходов, до ускорения процедуры на пару минут. Если меняется запрос, то меняется все остальное и гипотеза и процесс и т.д.
Большая проблема проектирования - это проблема "спуска".
Как плавно спускаться с верхнего продуктового уровня со своей конкретикой в деньгах до уровня специализированных микро требований в разных состояниях, без которых не создать качественный продукт.
Фрактал - это объект, имеющий свойство самаподобия, то есть в точности похож на свою часть.
То есть этот процесс проектирования от запроса до требований может быть запущен фрактальной логикой. Возникает "нить", за которую ты держишься, спускаясь фрактально вниз до определенных требований, там их майнишь, а потом безопасно поднимаешься обратно, не теряя связь с масштабом.
Это как картинка, которую можно бесконечно приближать, а потом опять отдалить, поменять точку и снова приблизить.
Аналитики и дизайнеры, покурите эту мысль, мне кажется она красивой.
5АМ | #разработка
В больших системах при проектировании очень просто запутаться. Возникает большое количество сценариев и их вариаций. На систему можно смотреть в любой момент с абсолютно разного угла, и она везде будет разной. Как в таком состоянии проектировать систему с учетом последующего её усложнения, если видение продукта распространяется далеко за первую версию "из говна и палок".
Ранее я писал про процесс проектирования:
запрос → гипотеза → процесс → данные → процедуры → требования
Такой способ позволяет изначально заходить сверху и плавно спускаться вниз. Изначально, когда начал применять, получалось так, что я спускался с жестко продуктового запроса до конкретной процедуры в модели данных.
С повторением итераций начал видеть, что такой процесс может применяться на более мелкие части. То есть запрос может быть разным: от получения доп. дохода или снижения расходов, до ускорения процедуры на пару минут. Если меняется запрос, то меняется все остальное и гипотеза и процесс и т.д.
Большая проблема проектирования - это проблема "спуска".
Как плавно спускаться с верхнего продуктового уровня со своей конкретикой в деньгах до уровня специализированных микро требований в разных состояниях, без которых не создать качественный продукт.
Фрактал - это объект, имеющий свойство самаподобия, то есть в точности похож на свою часть.
То есть этот процесс проектирования от запроса до требований может быть запущен фрактальной логикой. Возникает "нить", за которую ты держишься, спускаясь фрактально вниз до определенных требований, там их майнишь, а потом безопасно поднимаешься обратно, не теряя связь с масштабом.
Это как картинка, которую можно бесконечно приближать, а потом опять отдалить, поменять точку и снова приблизить.
Аналитики и дизайнеры, покурите эту мысль, мне кажется она красивой.
5АМ | #разработка
👍3❤1🔥1
Однополостной гиперболоид или пересборка
Мне понравился образ из геометрии, который хорошо показывает как бизнес и системный анализ связаны друг с другом. Разберем.
Анализ - мы смотрим на что-то и разделяем это что-то на мелкие части, чтобы их изучить. Зачем? - Сделать вывод.
Синтез - исходя из сделанных выводов мы собираем из этих частей что-то новое.
Только исходя из этого я называл бы вакансии аналитиков: бизнес и системный синтезатор 😆 Ибо хер ли ты на анализировал, если не синтезировал.
Так вот. Бизнес анализ(БА) - это разбор операций, которые выполняют люди или компьютер, чтобы получить денюжку. Операции могут выполнятся плохо. Их нужно оптимизировать или в целом создавать и внедрять.
Тут в целом нет вашего приложения как продукта. Так как выполнять эти операции можно в любой среде, есть всегда только один момент: экономическая целесообразность.
Когда БА собрал процесс, который несет деньги, он выводит требования: какие люди и системы должны его выполнять, каким образом и с какими затратами.
Поэтому в стартапах эту функции в основном забирают основатели, продакты. Потому что требования - это и есть продуктовое видение. Если на этом кто-то зарабатывает, значит это потенциально купят, если заработок будет больше чем цена продукта.
Системный анализ(СА) имеет разный уклон - СА с уклоном в веб интерфейс, СА с уклоном в хранение данных в БД, СА с уклоном в программные операции.
Главная задача системы - обрабатывать данные. Значит самое главное из анализа - это синтез операций, выполняемые программой или человеком, чтобы эти данные обработать.
БА - формирует крупные сущности данных. СА с уклоном в веб/мобилу - группирует данные в сценарии пользователя. СА с уклоном в БД - расщепляет данные из сценариев на мелкие структуры. СА с уклоном в программные операции преобразует данные из БД в новые данные = польза = деньги.
Однополосный гиперболоид. Почему?
Верхняя часть воронки это БА: мы собираем, разделяем, потом собираем обратно.
Нижняя часть СА: берет из воронки синтез и расщепляет делает анализ под себя на свои слои: пользователский, БД, программный.
Самое прикольное, что его можно разложить на плоскость. То есть в действительности мы работаем в одной плоскости, но смотрим на неё по-разному. Поэтому в этой геометрической метафоре видно проблему понимания заказчика и разработчика.
5АМ | #разработка
Мне понравился образ из геометрии, который хорошо показывает как бизнес и системный анализ связаны друг с другом. Разберем.
Анализ - мы смотрим на что-то и разделяем это что-то на мелкие части, чтобы их изучить. Зачем? - Сделать вывод.
Синтез - исходя из сделанных выводов мы собираем из этих частей что-то новое.
Только исходя из этого я называл бы вакансии аналитиков: бизнес и системный синтезатор 😆 Ибо хер ли ты на анализировал, если не синтезировал.
Так вот. Бизнес анализ(БА) - это разбор операций, которые выполняют люди или компьютер, чтобы получить денюжку. Операции могут выполнятся плохо. Их нужно оптимизировать или в целом создавать и внедрять.
Тут в целом нет вашего приложения как продукта. Так как выполнять эти операции можно в любой среде, есть всегда только один момент: экономическая целесообразность.
Когда БА собрал процесс, который несет деньги, он выводит требования: какие люди и системы должны его выполнять, каким образом и с какими затратами.
Поэтому в стартапах эту функции в основном забирают основатели, продакты. Потому что требования - это и есть продуктовое видение. Если на этом кто-то зарабатывает, значит это потенциально купят, если заработок будет больше чем цена продукта.
Системный анализ(СА) имеет разный уклон - СА с уклоном в веб интерфейс, СА с уклоном в хранение данных в БД, СА с уклоном в программные операции.
Главная задача системы - обрабатывать данные. Значит самое главное из анализа - это синтез операций, выполняемые программой или человеком, чтобы эти данные обработать.
БА - формирует крупные сущности данных. СА с уклоном в веб/мобилу - группирует данные в сценарии пользователя. СА с уклоном в БД - расщепляет данные из сценариев на мелкие структуры. СА с уклоном в программные операции преобразует данные из БД в новые данные = польза = деньги.
Однополосный гиперболоид. Почему?
Верхняя часть воронки это БА: мы собираем, разделяем, потом собираем обратно.
Нижняя часть СА: берет из воронки синтез и расщепляет делает анализ под себя на свои слои: пользователский, БД, программный.
Самое прикольное, что его можно разложить на плоскость. То есть в действительности мы работаем в одной плоскости, но смотрим на неё по-разному. Поэтому в этой геометрической метафоре видно проблему понимания заказчика и разработчика.
5АМ | #разработка
🍓3🔥1👏1
Как делать быстро и хорошо?
Читаю канал Леонида Лапидуса, постит крутые адекватные вещи. Поднял извечную тему что нужно делать продукты быстрее. Тема меня трогает каждый раз, т.к. для каждого собственника и продакта это такой смачный лещ всегда: "а ну, черт, че так медленно то, а?".
Не спорю, но я всегда за "как". Мои рекомендации как в логике разработки ИТ продуктов:
1. Считать деньги
Первое и важное, нужно найти границы продукта, за который человек готов ТОЧНО и МИНИМУМ заплатить. Это всегда сложная задача, которая требует навыка отделения мух от котлет, все нужно ставить под сомнение. Каждая фича допустим "темная тема" или "центр уведомлений", должна проходить проверку на "это просто прикольно или пользователю это нужно". Каждая фича стоит часа бэка, диза, фронта, тестера - херак и уже 100к на чушь ушло. Таблица с подсчетом денег - это первое, что нужно видеть каждый гребаный день (в воскресение тоже желательно).
2. Параллельно проектировать
Поставил границы начинаешь проектировать итерировано. Бэк отдельно, фронт отдельно, дизайн отдельно. Каждый дешево обогащает друг друга знание о продукте. Помним и держим в голове: "Я сейчас проектирую, чтобы выпендриться как это сложно или это нужно клиенту?" Убираем все, что не относится к границам, все что их расширяет, даже микро поле для ввода, лишний фильтр, лишний дропдаун может лупануть вам пощечину и уже невозможно откатить - опять затраты, опять долго, опять не хорошо.
3. Параллельно продавать
Получили на фронте "какашку" без бэка и дизайна - идем терроризировать клиента-респондента. Клиенту нужен процесс, процесс, который будет нести удовольствие либо приносить деньги. Процесс можно продать на малую аудиторию даже без логики бэка и без дизайна. Вы сделали быстро, бабуля быстро сказала вам, что "чет непонятно, сынок - делай еще".
4. Параллельно разрабатывать
Проектирование затвердило часть продукта: дальше итерируем, а то что утверждено отправляем печься в разработку: прорабатываем микротребования, прорабатываем дизайн, бэк, фронт. Тестим, выпускаем, продаем.
Псих-рекомнедации:
1. Все делают сначала хреново. Просто кто-то на более поздних итерациях и уже имеет бОльшие ресурсы и результаты чем у тебя.
2. Для каждой ниши разное быстро и разное хорошо.
3. Дели, критично и безжалостно отклеивай одно от другого. Разделяй и властвуй.
5АМ | #разработка
Читаю канал Леонида Лапидуса, постит крутые адекватные вещи. Поднял извечную тему что нужно делать продукты быстрее. Тема меня трогает каждый раз, т.к. для каждого собственника и продакта это такой смачный лещ всегда: "а ну, черт, че так медленно то, а?".
Не спорю, но я всегда за "как". Мои рекомендации как в логике разработки ИТ продуктов:
1. Считать деньги
Первое и важное, нужно найти границы продукта, за который человек готов ТОЧНО и МИНИМУМ заплатить. Это всегда сложная задача, которая требует навыка отделения мух от котлет, все нужно ставить под сомнение. Каждая фича допустим "темная тема" или "центр уведомлений", должна проходить проверку на "это просто прикольно или пользователю это нужно". Каждая фича стоит часа бэка, диза, фронта, тестера - херак и уже 100к на чушь ушло. Таблица с подсчетом денег - это первое, что нужно видеть каждый гребаный день (в воскресение тоже желательно).
2. Параллельно проектировать
Поставил границы начинаешь проектировать итерировано. Бэк отдельно, фронт отдельно, дизайн отдельно. Каждый дешево обогащает друг друга знание о продукте. Помним и держим в голове: "Я сейчас проектирую, чтобы выпендриться как это сложно или это нужно клиенту?" Убираем все, что не относится к границам, все что их расширяет, даже микро поле для ввода, лишний фильтр, лишний дропдаун может лупануть вам пощечину и уже невозможно откатить - опять затраты, опять долго, опять не хорошо.
3. Параллельно продавать
Получили на фронте "какашку" без бэка и дизайна - идем терроризировать клиента-респондента. Клиенту нужен процесс, процесс, который будет нести удовольствие либо приносить деньги. Процесс можно продать на малую аудиторию даже без логики бэка и без дизайна. Вы сделали быстро, бабуля быстро сказала вам, что "чет непонятно, сынок - делай еще".
4. Параллельно разрабатывать
Проектирование затвердило часть продукта: дальше итерируем, а то что утверждено отправляем печься в разработку: прорабатываем микротребования, прорабатываем дизайн, бэк, фронт. Тестим, выпускаем, продаем.
Псих-рекомнедации:
1. Все делают сначала хреново. Просто кто-то на более поздних итерациях и уже имеет бОльшие ресурсы и результаты чем у тебя.
2. Для каждой ниши разное быстро и разное хорошо.
3. Дели, критично и безжалостно отклеивай одно от другого. Разделяй и властвуй.
5АМ | #разработка
👍5🔥5❤4🍓1
Про хештеги канала
Как пользоваться: нажимаете на хештег → в списке нажимаете на мой канал → читаем посты по теме тега.
Рубрика - экспертные
#разработка - как делать ПО
#управление - командой
#предпринимательство - о бизнесе
#загородом - про недвижимость
#компания - и её процессы
#стартап - как их делать
Рубрика - легкое
#цитаты - любимое 🙂
#мемы - поржать
#life - узнать меня поближе
Рубрика - полезное
#философия - сознания и ИИ
#мотивация - и заряд энергией
#рекомендации - как действовать
#развитие - своей личности
Рубрика - от компании
#вакансии - к нам в команду
#кейсы - что делала студия
#дайджест - крутые посты
#ретроспектива - подвожу итоги
5АМ | #дайджест
Как пользоваться: нажимаете на хештег → в списке нажимаете на мой канал → читаем посты по теме тега.
Рубрика - экспертные
#разработка - как делать ПО
#управление - командой
#предпринимательство - о бизнесе
#загородом - про недвижимость
#компания - и её процессы
#стартап - как их делать
Рубрика - легкое
#цитаты - любимое 🙂
#мемы - поржать
#life - узнать меня поближе
Рубрика - полезное
#философия - сознания и ИИ
#мотивация - и заряд энергией
#рекомендации - как действовать
#развитие - своей личности
Рубрика - от компании
#вакансии - к нам в команду
#кейсы - что делала студия
#дайджест - крутые посты
#ретроспектива - подвожу итоги
5АМ | #дайджест
👍4❤2🍓1