Требования и 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АМ | #разработка