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

Думаю, что главное отличие - это наличие или отсутствие пользовательских данных.

Продукта нет. Что делает продакт:
— Делает большой упор на анализ рынка: конкурентов, спроса, объема, чтобы понять и ориентироваться в каком поле он будет работать.
— Находится в прямом контакте с пользователями. Проводит интервью для точного формулирования запросов и согласования гипотез, чтобы вывести модели монетизации и суть продукта как можно быстрее. Исследует продукты конкурентов и похожих систем.
— Плотно работает с аналитиком/ми (бизнес процесс для гипотез, анализ данных сущностей для интерфейса и БД, взаимодействие с тех. анализом и анализом ux). Если их нет, то проводит эту аналитику. Результатом является пачка требований с оценкой сроков и стоимостью, распределенная по вехам и переданная в проектное управление. Если нет ПМ-а, то и управляет проектом)
— Формирует команду разработки, требования к компетенции участников. Участвует в найме. Инжинирит продукт вместе с ними, постоянно консультирует по требованиям и образу продукта, не мешает креативить идеи для решений поставленных им гипотез.
— Ищет кратчайшие способы вывода продукта на рынок.
— Готовит продукт к управлению им. Покрывает код методами сбора данных для расчета метрик продукта. Также, готовит продукт для подключения его к договорным отношениям: включение/отключение функций, лицензионные соглашения, выставление счетов, процесс оплаты и актирования.

Продукт есть. Что делает продакт:
— Регулярно собирает данные продукта для формирования отчетов по метрикам. Делает расчеты, а из них делает выводы, что такая-то функция не отрабатывает правильно, такая-то работает хорошо, но могла бы лучше, тем самым запуская в работу котел разработки. Некоторые продукты настолько сложные и имеют настолько много данных, что потребность в написания SQL запросов и элементарных классов обработки на Python становятся необходимостью. Иначе данные для принятия решения об изменения будут некорректными.
— Все, что не получается вытащить из данных собирается в интервью с пользователями, чтобы узнать их проблемы, в особенности почему они перестали платить или не хотят платить больше. Часть обнаруженных проблем можно передать на интервью UX-еру. Кстати, именно тут возникает стык и появляется такая роль, как продуктовый дизайнер.
— Актуализировать данные рынка, делать переоценку спроса, изучать новые фичи конкурентов, быть в курсе трендов рынка своего продукта.
- Глубоко взаимодействовать с командой разработки, чтобы понять технические проблемы, которые могут положить продукт, что приведет к убыткам.
— Взаимодействовать с командой маркетинга и сейлзами. Решать их проблемы, изучать метрики рекламных носителей, продаж и пытаться на них повлиять через знания о продукте. Участвовать в построении или строить самому CJM-ки, чтобы понять узкие места отвала процесса не только в самом приложении, но и вне его. Писать стратегию развития продукта в конце концов, чтобы заработать больше деняк.

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

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

Что думаете?

5АМ | #управление

Требования и 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АМ | #философия