Требования и backend

При разработке требований к продукту с большим объемом интерфейсов можно натолкнуться на такую сложность, что backend не делает возможности по одной. Берется сразу пачка. То есть там где у дизайна и у фронта 4 задачи , то у бэкенда всего одна и рассматривать их нужно вкупе или придется опять переделывать. Как так получается и что с этим делать? По крайней мере как мы с этим справляемся. Делитесь что у вас)

Вот возьмем пример. Есть таблица с данными поступлений, в которую выводим данные. У таблицы есть сортировка, фильтрация и поиск. Нам нужно сформулировать требования к четырем возможностям: вывод данных, фильтрация, сортировка, поиск. Это 4 разные процедуры для пользователя, его 4 самостоятельные потребности, которые имеют свой маршрут из действий. А поэтому могут иметь особые требования, которые продакт должен рассмотреть отдельно. Дизайнер, в свою очередь, будет рассматривать отдельно каждую процедуру, разложит состояния, покажет что происходит и на чем все закончится. Фронт тоже будет собирать весь процесс отдельно для каждой возможности. Но вот для бэкэнда - это все один GET запрос с разными параметрами в URL.

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

Поэтому задача аналитика разбить процедуры на такие крупные блоки:
— GET. Получить данные конкретной сущности. Например, данные карточки товара.
— GET. Данные в таблицу с пагинацией, поиском, контекстным меню и т.д.
— POST. Создание, редактирование сущности.
— DELETE. Удаление, архивация сущности.
Есть еще кастомные сложные эндпоинты, хабы, загрузка файлов. Они как правило рассматриваются уже в тех. анализе отдельно.

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

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

Продуктивная продуктивность

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

Начнем. Вечером мотивашка на всю: "Ух я завтра как дам, как всё успею". И тут, утро. Орет будильник, айфоновская мелодия "Радар". Вы ненавидите этот мир, что делать:

🌃 Спускайся на пол
Я с вечера стелю покрывало на пол или коврик для спорта. Единственное усилие, которое нужно сделать - это вывалиться из кровати на твердую поверхность. Почему? Внутренний диалог. Лежа в мякотке в сладкой темноте побороть железобетонные аргументы о дополнительных 10 минутах нереально. Можно вывалиться прям с одеялом, главное, чтобы было твердо. Это правильный мув. А вот неправильный мув - это врубить свет на всю, чтобы из глаз искры посыпались.
🌃 Бутылочку 0.3 животворящей
Также с вечера просто налить себе воды и поставить на тот же коврик. Когда ты доползешь до коврика, единственное что не будет вызывать отторжение - это вода. Можно с лимончиком. Это вторая хитрость, которая начинает вышибать из сна на уровне с твердым полом.
🌃 Дайте себе охренеть
Вы же проснулись, чтобы у вас было много времени. Вот у вас его навалом, дайте 10-15 минут потупить в темноту, приходит много разных интересных мыслей, а иногда вообще ничего не приходит и это тоже кайф. К этому моменту уже становится нормально и можно двигаться.

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

Есть отягчающие обстоятельства:
✏️ желательно иметь 7 часов, т.е в 22:00 быть в постели, но если не получилось - встать все равно возможно;
✏️ холодно в квартире/доме. Спасает выползание вместе с одеялом, а рядом заготовить теплые вещи;
✏️ нет плана. Если делать нечего, то почти точно можно залипнуть в телефоне или уснуть, уткнувшись носом в коврик в позе младенца и пофиг, что твердо.
✏️ сопящая рядом вторая половинка. Увеличивает дальность до коврика вдвое, а значит и количество усилий. Также, увеличивает количество исторгаемого кайфового тепла. В студии на 38 кв.м. все, что написано выше - не работает либо нужно вставать в темень вместе)

Я пишу не про первый день, а про 14, 23, 35. То есть, не про мотивацию, а про дисциплину. Есть еще один важный лайфхак — на выходных дать себе выспаться. Чтобы пружина привыкла к натянутому состоянию, нужно много времени, поэтому нужно давать себе передышку.

5АМ | #мотивация

Какая база помогает тащить роль системного аналитика в проектах Локео (о проекте)

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

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

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

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

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

5АМ | #мотивация

Вот такой состав базы я выделил:

📌Философия
Поставил на первое место именно философию. С вышки она стала моим хобби: глубокая рефлексия, желание разобрать вещи на атомы, докопаться до причины, до сути: такой кайф, жвачка для мозга. Разные философы пытаются найти решения, выстроив логичную архитектуру мироздания. Удивительно, но это неосознанный тренажер очень многое дал для понимания построения архитектуры ПО.

📌Знание кода
Начинали с Серегой вместе с написания кода на C#. C ним я конечно не тягался и пять лет назад, но осталось понимание ООП, паттернов проектирования, абстрактных классов, движение кода в дебаг режиме по методам и свойствам в рамках разных классов с обработкой переменных разной типизации. Это понимание дало тот самый образ, когда ты можешь продумывать от бизнеса и интерфейса вплоть до движения кода по строчкам, каждая из которых - операция, преобразующая данные. Ты можешь думать на этом уровне. Это важно и круто.

📌Знание устройства БД
Продумывая как данные бизнеса обернуть в систему, в голове уже строится образ ER-диаграммы c данными по сущностям и видами связей (один к одному, многие ко многим и т.д.).

📌Знание компьютерных сетей и запросов
Понимание работы протокола http, его запросов с конкретным методом, портов, получения фронтом нужных данных из БД по методам API, дает еще один образ движения данных в рамках системы.

📌Знание интерфейсов
Необходимо хотя бы базовое понимание устройства и работы компонентов, типовых элементов UI kit и подготовки прототипов, макетов в Figma, а также типов страниц, стандартных UX сценариев использования элементов и страниц. Системный аналитик в одном из слоев думает о приложении с позиции интерфейсов, поэтому необходимо иметь образы процессов разработки UX/UI.

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

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

5АМ | #мотивация

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

А пока те самые три библейских вопроса любой разработки😝

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

5АМ | #мемы

Пятничная честность ❤️

Я поставил цель дорастить наш канал до 1000 крутых ребят до конца года. Сейчас мы приближаемся к 500(!!!) и возникла потребность четче сформулировать кто мы, кто я, зачем это все. Я веду канал уже полгода параллельно управлению компанией и разработке. За полгода не пропустил ни дня, сделав около 130 постов, по 5 дней, предоставляя вам контент с душой, лично пропущенный через меня, через мой опыт.

За полгода мне удалось плотно влиться в информационный поток телеграм каналов IT тематики. И понял, что есть три ниши для этого канала - это тусовка студий, стартаперская тусовка и продактовская тусовка. Этот канал где-то посередине.

Канал для продактов? И да и нет
У меня уже накопилось 7 лет коммерческого опыта продуктового управления, 6 из них в IT. Но управление продуктом, проектами, бизнес и системным анализом я занимался параллельно развитию бизнеса, т.е. объединяя с административными процессами.

Продактовская тусовка в основном из корпораций: Сбер, Яндекс, Ozon и т.д. (привет, ребят, если кто читает киньте 👋, вы крутые)) Ваши функции не так сильно смешаны, у корпораций есть деньги нанимать большой штат специалистов на каждый подпроцесс проектирования и развития.

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

Канал для стартаперов. И да и нет
Тут меня бомбанет)) Я читаю стартаперов. Весь нарратив постов как будто списан с сериала «Кремниевая долина». Экзиты-хуекзиты, питч-деки, фин. модели, единороги и прочие лошади. Я на опыте ощутил и понимаю, что устойчивую компанию построить очень сложно, собрать крутую команду еще сложне, эффективно разрабатывать ПО невероятно сложно, построить маркетинг и систему продаж - пфффф. Или мне одному так тяжело?))) (ну вот начал жаловаться)

Но самое важное - капитал не дают просто так. Ни фонд, ни государство, просто так: за бизнес план, красивую картинку в презентации, даже когда у тебя за плечами уже что-то есть, не дают. Никто за тебя процессы не построит, а инвестировать в компанию с плохими процессами - это сливать деньги на ветер. Инвестируют в бизнес. Как сделать бизнес? Не по-книжному, а вот реально, когда минимальная команда стоит 1.5 млн. руб. со всеми оптимизациями. Инвестор - не хочет терять деньги, поэтому процесс DD (проверки компании) растягивается (а платить нужно), а после ты подписываешь неприятные условия. Я честно признаю, что это тяжело и не прячусь за умными словами) Реальный бизнес суров, он не сказочный.

Я уволился из фсб, Серега из первого бита. Мы начали с разработки VR/AR для целей маркетинга как студия, параллельно развивая процессы веб и мобильной enterprise разработки с нуля. Мы простые ребята из народа, «от земли», делаем ошибки (например) и честно, без прекрас и красивых терминов, строим бизнес как студию и как IT продукт, потому что рассчитывам на себя. 6 лет в разработке как команда, 70 млн. привлекли инвестиций, сделали 5 крупных проектов, не считая Локео, который состоит еще из 8, 15-20 млн ежегодный оборот. Мы экспертны в разработке SAAS решений для b2b от проектирования с нуля до релиза, в VR/AR, в интернет-маркетинге. В нас есть огонь, желание и зрелость)

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

Если у вас есть идеи, вы хотите что-то обсудить, даже просто поболтать за решение, или вы думали за разработку, и нет тз, то я готов поделиться опытом и уделить время. 🫶 Пишите - @limskov.

5АМ | #мысли

Сколько у нас точек зрения?

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

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

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

В школе и в ВУЗе мы получаем пачку таких линз - именно она и называется «системное знание». Появляется возможность думать метафорами, объяснять невидимое и абстрактное понятными мысле-образами, имитирующими схожие процессы. Вот из интересного:

— Имея образ иракской паукохвостой гадюки и понимание зачем ей такое строение хвоста, можно не удивляться зачем бизнес и люди столько тратят на системы безопасности.
— знание о том, как размещается один электрон в атоме в разный момент времени дает представление о том, что происходит с одной задачей с разных углов зрения: как проект, как запрос заказчика, как эпик и т.д
— представляя строение восточно-европейской равнины и карпатских гор можно понять причины поступков правителей Российской империи, СССР и РФ, сделав простой логический вывод.
— представляя работу диода и одиночный p-n переход, можно усложнить понимание и узнать о транзисторе, который как выключатель переключается и пропускает ток, а 8 транзисторов поставленные в положение 0000 0011, дают цифру 3, дальше ассемблер, с++, с# и вот уже у нас видос на ютубе работает))

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

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

P.S. завтра поговорим про CJM😝

5АМ | #философия

🔼🔼🔼 Ребят, сегодня произошел случай. Мы с Виктором списались по рабочим вопросам и получилось так, что я его не понял, а он меня и все перешло в эмоцию, мат и поножовщину)) Шутка)

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

Глубинные интервью

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

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

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

Далее начинается интересное. Нужно выявить существующий процесс и существующие среды. BA/SA вступают в бой, ну или продакт в этой роли) Три этапа: подготовка, интервью, оформление.

Подготовка
Как сказал мой дед: я твой дед "Победа любит подготовку". Нужно заранее изучить предметную область, понятийный аппарат, имеющиеся среды обработки данных, участвующих лиц, подготовить список тупых вопросов. Например, узнать, что в цепочке участвуют: HR, кандидат, бухгалтер, курьер. Среды: 1С, excel, doc, может быть CRM hr-a.

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

Понимая весь процесс, идем к пользователю.

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

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

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

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

5АМ | #стартап

К вчерашнему посту был комментарий от Кнарик (мы с ней работали над Локео, оч. крутой дизайнер) закинула вопрос - почему исследования делает 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АМ | #разработка

Завтра мемесы, хорош с лонгридами😝

Сегодня ездили фоткаться для сайта) Серега модный-мощный, испепелял фотографа взглядом😄😄