Чудеса категоризации
Отойду чуть от IT-ой тематики . Рассмотрим кусочек философии сознания. Как-то три года назад я иду по улице и задумываюсь о том, чем отличается собственно ум, разум, сознание, интеллект друг от друга) Выглядит как мешанина понятий и все они описывают что-то что происходит в черепной коробке)
Помню я тогда нарыл просто идеальнейшую метафору. Называется колесница тела. Если не знали, вот вам порция крутого порядка в голову, чтобы круче структурировать себя, продукты и бизнесы)
Суть следующая: на картине пять буйных и мощных коней. Возница (человек, который держит поводья и управляет лошадьми) с трудом пытается удержать поводья, а в колеснице седок. Посмотрите на крутизну этой многоуровневой метафоры: Кони - это 5 органов чувств (слух, зрение, вкус и т.д.), поводья - это ум, возница - это разум, а седок в колеснице - это душа, настоящие мы) Если плющит чувства — плющит всех)
5АМ | #философия
Отойду чуть от IT-ой тематики . Рассмотрим кусочек философии сознания. Как-то три года назад я иду по улице и задумываюсь о том, чем отличается собственно ум, разум, сознание, интеллект друг от друга) Выглядит как мешанина понятий и все они описывают что-то что происходит в черепной коробке)
Помню я тогда нарыл просто идеальнейшую метафору. Называется колесница тела. Если не знали, вот вам порция крутого порядка в голову, чтобы круче структурировать себя, продукты и бизнесы)
Суть следующая: на картине пять буйных и мощных коней. Возница (человек, который держит поводья и управляет лошадьми) с трудом пытается удержать поводья, а в колеснице седок. Посмотрите на крутизну этой многоуровневой метафоры: Кони - это 5 органов чувств (слух, зрение, вкус и т.д.), поводья - это ум, возница - это разум, а седок в колеснице - это душа, настоящие мы) Если плющит чувства — плющит всех)
5АМ | #философия
Переведем все на язык обработки данных:
Органы чувств
Интерфейс программы. Механизм сбора данных, своего рода био-реле) Слух - сбор звуковых волн, вкус и обоняние - сбор химического состава веществ, зрение - сбор электромагнитного излучения светового диапазона (потока фотонов), осязание - пачка реле (давление есть/нет, холод есть/нет и т.д.) Они напрямую связаны на запись в био-БД) Но если есть интерфейс, есть база данных, то должны быть и интерпретаторы, обработчики. Добро пожаловать в био-бэкэнд, который мучает нас на ежедневной основе, и от которого мы все так пытаемся убежать)
Ум и Разум
Первая ступень категоризации - это ум. Распределяет все на приятно — не приятно. Ом-ном-ном кофе на кокосовом молоке - какой кайф, или непонятная задача незакрытая еще с пятницы в приоритете high - боль, уйди, не хочу😭 Ну вы поняли.
Вторая ступень категоризации - это разум. Распределяет все на хорошо — плохо. Кофе на кокосовом конечно кайф, но я не сплю и у меня мешки под глазами, или непонятная задача, но за ипотеку то платить нужно)
Распределение категорий этими двумя ребятами не могут работать без БД (его еще опытом называют). Они получают данные из внешнего мира и начинают сопоставлять: "так я задеплоил в пятницу, прод рухнул в субботу, выходные я с женой не провел, мне дали в тык". Наступает следующая пятница, рука тянется залить, и ты такой оп - "деплоить в пятницу не буду") Сопоставляет такие логически цепи, кстати интеллект, поэтому есть те, до которых не доходит)) Ум и Разум выносят суждение, вывод. Делать — не делать. И тут следующий уровень.
Тело - Душа
Эти ребята самые бедные в этой цепи. Они вообще не вдупляют что происходит. Им просто говорят — делай. И тело начинает вытворять дичь: работать до 12, есть и пить ерудну до отвала и другие виды наркомании. Про душу молчу, потому что это тяжелая структура, состоящая из нескольких уровней Я. Мы просто в потоке обработки данных её не видим.
И тут самое интересное - весь этот процесс не прекращается ни-ко-гда. Мы постоянно собираем информацию, постоянно её обрабатываем и нас постоянно плющит куда-то бежать и что-то делать)) Поэтому кони в метафоре безумны, поводья еле удерживаются, а душа и тело постоянно на измене вообще)
У потрясающего поэта нашего времени - Веры Полозковой есть такие крутые строки, которые не выходят у меня из головы:
...
Что, смиренная моя плоть,
Тесная моя клеть -
Я хотел тебя расколоть,
Свергнуть, преодолеть
... (тут весь стих)
Выход один. Всякие буддисты и Гай Ричи говорят заткнитесь, молчите) Смысл какой: нужно заткнуть интерфейс. Грубо говоря в органы чувств постоянно поступают данные потоком - 11111. Вот так. Нужно вырубить его - 00000. Вот так. Тогда не будет работать ум и разум, тогда тело расслабится и можно будет увидеть душу. Это очень сложно, но опыт безумно интересный, у меня лично не получается)) Получалось у единиц, они обычно прораками религии становились) Кхэм-кхэм)
5АМ | #философия
Органы чувств
Интерфейс программы. Механизм сбора данных, своего рода био-реле) Слух - сбор звуковых волн, вкус и обоняние - сбор химического состава веществ, зрение - сбор электромагнитного излучения светового диапазона (потока фотонов), осязание - пачка реле (давление есть/нет, холод есть/нет и т.д.) Они напрямую связаны на запись в био-БД) Но если есть интерфейс, есть база данных, то должны быть и интерпретаторы, обработчики. Добро пожаловать в био-бэкэнд, который мучает нас на ежедневной основе, и от которого мы все так пытаемся убежать)
Ум и Разум
Первая ступень категоризации - это ум. Распределяет все на приятно — не приятно. Ом-ном-ном кофе на кокосовом молоке - какой кайф, или непонятная задача незакрытая еще с пятницы в приоритете high - боль, уйди, не хочу😭 Ну вы поняли.
Вторая ступень категоризации - это разум. Распределяет все на хорошо — плохо. Кофе на кокосовом конечно кайф, но я не сплю и у меня мешки под глазами, или непонятная задача, но за ипотеку то платить нужно)
Распределение категорий этими двумя ребятами не могут работать без БД (его еще опытом называют). Они получают данные из внешнего мира и начинают сопоставлять: "так я задеплоил в пятницу, прод рухнул в субботу, выходные я с женой не провел, мне дали в тык". Наступает следующая пятница, рука тянется залить, и ты такой оп - "деплоить в пятницу не буду") Сопоставляет такие логически цепи, кстати интеллект, поэтому есть те, до которых не доходит)) Ум и Разум выносят суждение, вывод. Делать — не делать. И тут следующий уровень.
Тело - Душа
Эти ребята самые бедные в этой цепи. Они вообще не вдупляют что происходит. Им просто говорят — делай. И тело начинает вытворять дичь: работать до 12, есть и пить ерудну до отвала и другие виды наркомании. Про душу молчу, потому что это тяжелая структура, состоящая из нескольких уровней Я. Мы просто в потоке обработки данных её не видим.
И тут самое интересное - весь этот процесс не прекращается ни-ко-гда. Мы постоянно собираем информацию, постоянно её обрабатываем и нас постоянно плющит куда-то бежать и что-то делать)) Поэтому кони в метафоре безумны, поводья еле удерживаются, а душа и тело постоянно на измене вообще)
У потрясающего поэта нашего времени - Веры Полозковой есть такие крутые строки, которые не выходят у меня из головы:
...
Что, смиренная моя плоть,
Тесная моя клеть -
Я хотел тебя расколоть,
Свергнуть, преодолеть
... (тут весь стих)
Выход один. Всякие буддисты и Гай Ричи говорят заткнитесь, молчите) Смысл какой: нужно заткнуть интерфейс. Грубо говоря в органы чувств постоянно поступают данные потоком - 11111. Вот так. Нужно вырубить его - 00000. Вот так. Тогда не будет работать ум и разум, тогда тело расслабится и можно будет увидеть душу. Это очень сложно, но опыт безумно интересный, у меня лично не получается)) Получалось у единиц, они обычно прораками религии становились) Кхэм-кхэм)
5АМ | #философия
Как вы думаете отличается ли работа продакта, когда у продакта есть продукт, и когда продукта еще нет? И можно ли вообще назвать его продактом в таком случае?Присоединяйтесь к обсуждению. Вот мои мысли по этому поводу.
Думаю, что главное отличие - это наличие или отсутствие пользовательских данных.
Продукта нет. Что делает продакт:
— Делает большой упор на анализ рынка: конкурентов, спроса, объема, чтобы понять и ориентироваться в каком поле он будет работать.
— Находится в прямом контакте с пользователями. Проводит интервью для точного формулирования запросов и согласования гипотез, чтобы вывести модели монетизации и суть продукта как можно быстрее. Исследует продукты конкурентов и похожих систем.
— Плотно работает с аналитиком/ми (бизнес процесс для гипотез, анализ данных сущностей для интерфейса и БД, взаимодействие с тех. анализом и анализом ux). Если их нет, то проводит эту аналитику. Результатом является пачка требований с оценкой сроков и стоимостью, распределенная по вехам и переданная в проектное управление. Если нет ПМ-а, то и управляет проектом)
— Формирует команду разработки, требования к компетенции участников. Участвует в найме. Инжинирит продукт вместе с ними, постоянно консультирует по требованиям и образу продукта, не мешает креативить идеи для решений поставленных им гипотез.
— Ищет кратчайшие способы вывода продукта на рынок.
— Готовит продукт к управлению им. Покрывает код методами сбора данных для расчета метрик продукта. Также, готовит продукт для подключения его к договорным отношениям: включение/отключение функций, лицензионные соглашения, выставление счетов, процесс оплаты и актирования.
Продукт есть. Что делает продакт:
— Регулярно собирает данные продукта для формирования отчетов по метрикам. Делает расчеты, а из них делает выводы, что такая-то функция не отрабатывает правильно, такая-то работает хорошо, но могла бы лучше, тем самым запуская в работу котел разработки. Некоторые продукты настолько сложные и имеют настолько много данных, что потребность в написания SQL запросов и элементарных классов обработки на Python становятся необходимостью. Иначе данные для принятия решения об изменения будут некорректными.
— Все, что не получается вытащить из данных собирается в интервью с пользователями, чтобы узнать их проблемы, в особенности почему они перестали платить или не хотят платить больше. Часть обнаруженных проблем можно передать на интервью UX-еру. Кстати, именно тут возникает стык и появляется такая роль, как продуктовый дизайнер.
— Актуализировать данные рынка, делать переоценку спроса, изучать новые фичи конкурентов, быть в курсе трендов рынка своего продукта.
- Глубоко взаимодействовать с командой разработки, чтобы понять технические проблемы, которые могут положить продукт, что приведет к убыткам.
— Взаимодействовать с командой маркетинга и сейлзами. Решать их проблемы, изучать метрики рекламных носителей, продаж и пытаться на них повлиять через знания о продукте. Участвовать в построении или строить самому CJM-ки, чтобы понять узкие места отвала процесса не только в самом приложении, но и вне его. Писать стратегию развития продукта в конце концов, чтобы заработать больше деняк.
Итого. Первый больше в архитектуре, больше в подготовке продукта. Второй больше в данных, в подкрутке и докрутке, выводе новых фичей, чтобы повлиять на имеющиеся метрики, держать руку на пульсе каждый день. Открыл глаза - что там с моим малышом, все ли работает.
На самом деле их формат работы настолько отличается друг от друга, что если долго засидеться в одном формате, можно напрочь отбить навыки для второго и наоборот. Это как оперуполномоченный и следователь. Вроде их процессы похожи, но методы отличаются.
Что думаете?
5АМ | #управление
Думаю, что главное отличие - это наличие или отсутствие пользовательских данных.
Продукта нет. Что делает продакт:
— Делает большой упор на анализ рынка: конкурентов, спроса, объема, чтобы понять и ориентироваться в каком поле он будет работать.
— Находится в прямом контакте с пользователями. Проводит интервью для точного формулирования запросов и согласования гипотез, чтобы вывести модели монетизации и суть продукта как можно быстрее. Исследует продукты конкурентов и похожих систем.
— Плотно работает с аналитиком/ми (бизнес процесс для гипотез, анализ данных сущностей для интерфейса и БД, взаимодействие с тех. анализом и анализом ux). Если их нет, то проводит эту аналитику. Результатом является пачка требований с оценкой сроков и стоимостью, распределенная по вехам и переданная в проектное управление. Если нет ПМ-а, то и управляет проектом)
— Формирует команду разработки, требования к компетенции участников. Участвует в найме. Инжинирит продукт вместе с ними, постоянно консультирует по требованиям и образу продукта, не мешает креативить идеи для решений поставленных им гипотез.
— Ищет кратчайшие способы вывода продукта на рынок.
— Готовит продукт к управлению им. Покрывает код методами сбора данных для расчета метрик продукта. Также, готовит продукт для подключения его к договорным отношениям: включение/отключение функций, лицензионные соглашения, выставление счетов, процесс оплаты и актирования.
Продукт есть. Что делает продакт:
— Регулярно собирает данные продукта для формирования отчетов по метрикам. Делает расчеты, а из них делает выводы, что такая-то функция не отрабатывает правильно, такая-то работает хорошо, но могла бы лучше, тем самым запуская в работу котел разработки. Некоторые продукты настолько сложные и имеют настолько много данных, что потребность в написания SQL запросов и элементарных классов обработки на Python становятся необходимостью. Иначе данные для принятия решения об изменения будут некорректными.
— Все, что не получается вытащить из данных собирается в интервью с пользователями, чтобы узнать их проблемы, в особенности почему они перестали платить или не хотят платить больше. Часть обнаруженных проблем можно передать на интервью UX-еру. Кстати, именно тут возникает стык и появляется такая роль, как продуктовый дизайнер.
— Актуализировать данные рынка, делать переоценку спроса, изучать новые фичи конкурентов, быть в курсе трендов рынка своего продукта.
- Глубоко взаимодействовать с командой разработки, чтобы понять технические проблемы, которые могут положить продукт, что приведет к убыткам.
— Взаимодействовать с командой маркетинга и сейлзами. Решать их проблемы, изучать метрики рекламных носителей, продаж и пытаться на них повлиять через знания о продукте. Участвовать в построении или строить самому CJM-ки, чтобы понять узкие места отвала процесса не только в самом приложении, но и вне его. Писать стратегию развития продукта в конце концов, чтобы заработать больше деняк.
Итого. Первый больше в архитектуре, больше в подготовке продукта. Второй больше в данных, в подкрутке и докрутке, выводе новых фичей, чтобы повлиять на имеющиеся метрики, держать руку на пульсе каждый день. Открыл глаза - что там с моим малышом, все ли работает.
На самом деле их формат работы настолько отличается друг от друга, что если долго засидеться в одном формате, можно напрочь отбить навыки для второго и наоборот. Это как оперуполномоченный и следователь. Вроде их процессы похожи, но методы отличаются.
Что думаете?
5АМ | #управление
Требования и backend
При разработке требований к продукту с большим объемом интерфейсов можно натолкнуться на такую сложность, что backend не делает возможности по одной. Берется сразу пачка. То есть там где у дизайна и у фронта 4 задачи , то у бэкенда всего одна и рассматривать их нужно вкупе или придется опять переделывать. Как так получается и что с этим делать? По крайней мере как мы с этим справляемся. Делитесь что у вас)
Вот возьмем пример. Есть таблица с данными поступлений, в которую выводим данные. У таблицы есть сортировка, фильтрация и поиск. Нам нужно сформулировать требования к четырем возможностям: вывод данных, фильтрация, сортировка, поиск. Это 4 разные процедуры для пользователя, его 4 самостоятельные потребности, которые имеют свой маршрут из действий. А поэтому могут иметь особые требования, которые продакт должен рассмотреть отдельно. Дизайнер, в свою очередь, будет рассматривать отдельно каждую процедуру, разложит состояния, покажет что происходит и на чем все закончится. Фронт тоже будет собирать весь процесс отдельно для каждой возможности. Но вот для бэкэнда - это все один GET запрос с разными параметрами в URL.
Поэтому в документации у нас есть отдельный tech block (раздел с табличкой), который составляется после подготовки документации возможностей. А их может быть и 15-30 шт. для раздела. В этом блоке по типам запросов разбиваются возможности раздела, чтобы далее передать в разработку пачками. Это ускоряет разработку и дает понимание общей картины для бэкенда.
Поэтому задача аналитика разбить процедуры на такие крупные блоки:
— GET. Получить данные конкретной сущности. Например, данные карточки товара.
— GET. Данные в таблицу с пагинацией, поиском, контекстным меню и т.д.
— POST. Создание, редактирование сущности.
— DELETE. Удаление, архивация сущности.
Есть еще кастомные сложные эндпоинты, хабы, загрузка файлов. Они как правило рассматриваются уже в тех. анализе отдельно.
И уже на тактическом уровне планирования в Notion бэкенд логично для себя ведет работу, чтобы поставить те эндпоинты, которые нужны фронту. Фронт же получит требования, дизайн и API запрос, который позволит ему потоково без переключений делать пачку возможностей без нервов и также плавно передать это тестировщику. 🎩
5АМ | #разработка
При разработке требований к продукту с большим объемом интерфейсов можно натолкнуться на такую сложность, что 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АМ | #мотивация
Как-то я писал почему компания называется пять утра. В дни пиковой нагрузки по задачам я переключаюсь в график в 5:00-22:00. Сегодня речь пойдет про ранний подъем, а именно про то как
Начнем. Вечером мотивашка на всю: "Ух я завтра как дам, как всё успею". И тут, утро. Орет будильник, айфоновская мелодия "Радар". Вы ненавидите этот мир, что делать:
🌃 Спускайся на пол
Я с вечера стелю покрывало на пол или коврик для спорта. Единственное усилие, которое нужно сделать - это вывалиться из кровати на твердую поверхность. Почему? Внутренний диалог. Лежа в мякотке в сладкой темноте побороть железобетонные аргументы о дополнительных 10 минутах нереально. Можно вывалиться прям с одеялом, главное, чтобы было твердо. Это правильный мув. А вот неправильный мув - это врубить свет на всю, чтобы из глаз искры посыпались.
🌃 Бутылочку 0.3 животворящей
Также с вечера просто налить себе воды и поставить на тот же коврик. Когда ты доползешь до коврика, единственное что не будет вызывать отторжение - это вода. Можно с лимончиком. Это вторая хитрость, которая начинает вышибать из сна на уровне с твердым полом.
🌃 Дайте себе охренеть
Вы же проснулись, чтобы у вас было много времени. Вот у вас его навалом, дайте 10-15 минут потупить в темноту, приходит много разных интересных мыслей, а иногда вообще ничего не приходит и это тоже кайф. К этому моменту уже становится нормально и можно двигаться.
И окончательный гвоздь, но не обязательный — это прогулка. Вот тут наступает кайф, тишина, спокойствие, свобода, особенно летом. Но в зиму не работает, я проверял. Нет там кайфа в мороз)
Есть отягчающие обстоятельства:
✏️ желательно иметь 7 часов, т.е в 22:00 быть в постели, но если не получилось - встать все равно возможно;
✏️ холодно в квартире/доме. Спасает выползание вместе с одеялом, а рядом заготовить теплые вещи;
✏️ нет плана. Если делать нечего, то почти точно можно залипнуть в телефоне или уснуть, уткнувшись носом в коврик в позе младенца и пофиг, что твердо.
✏️ сопящая рядом вторая половинка. Увеличивает дальность до коврика вдвое, а значит и количество усилий. Также, увеличивает количество исторгаемого кайфового тепла. В студии на 38 кв.м. все, что написано выше - не работает либо нужно вставать в темень вместе)
Я пишу не про первый день, а про 14, 23, 35. То есть, не про мотивацию, а про дисциплину. Есть еще один важный лайфхак — на выходных дать себе выспаться. Чтобы пружина привыкла к натянутому состоянию, нужно много времени, поэтому нужно давать себе передышку.
5АМ | #мотивация
Какая база помогает тащить роль системного аналитика в проектах Локео (о проекте)
Я не был системным аналитиком раньше. Занять данную роль мне пришлось, чтобы поставлять продуманные требования ребятам в разработку. Более того, до недавнего времени я не думал, что то, что я делаю, на рынке называют системной аналитикой.
Мы делали компанию и было понятно, что если кто-то не продумает, то все дальнейшие звенья разработки будут делать херню. В интернете много курсов и умных статьей описывающих "что" нужно делать, но не "как". Процесс проектирования ПО мы разрабатывали без малого 4 года, совершая очень грубые ошибки.
Недавно, когда спрос на Локео подтвердился, мы начали приводить приложения в порядок, а я за долго до этого начал собирать выводы по всем нашим наработками и ошибкам, чтобы превратить процесс в прозрачную ценность. И вот текущая версия процесса позволяет нам прокручивать большой объем требований очень быстро, без путаницы, сохраняя версионирование, при очень низких издержках.
Если интересна тема, то дайте огонек, я пойму, что нужно показать и раскрыть наш процесс. Думаю, что это будет цикл постов)
Сегодня хочу разобрать базу: какие знания и в каких областях нужно иметь, чтобы уметь в системный анализ и строить крутые архитектуры систем.
5АМ | #мотивация
Я не был системным аналитиком раньше. Занять данную роль мне пришлось, чтобы поставлять продуманные требования ребятам в разработку. Более того, до недавнего времени я не думал, что то, что я делаю, на рынке называют системной аналитикой.
Мы делали компанию и было понятно, что если кто-то не продумает, то все дальнейшие звенья разработки будут делать херню. В интернете много курсов и умных статьей описывающих "что" нужно делать, но не "как". Процесс проектирования ПО мы разрабатывали без малого 4 года, совершая очень грубые ошибки.
Недавно, когда спрос на Локео подтвердился, мы начали приводить приложения в порядок, а я за долго до этого начал собирать выводы по всем нашим наработками и ошибкам, чтобы превратить процесс в прозрачную ценность. И вот текущая версия процесса позволяет нам прокручивать большой объем требований очень быстро, без путаницы, сохраняя версионирование, при очень низких издержках.
Если интересна тема, то дайте огонек, я пойму, что нужно показать и раскрыть наш процесс. Думаю, что это будет цикл постов)
Сегодня хочу разобрать базу: какие знания и в каких областях нужно иметь, чтобы уметь в системный анализ и строить крутые архитектуры систем.
5АМ | #мотивация
Вот такой состав базы я выделил:
📌Философия
Поставил на первое место именно философию. С вышки она стала моим хобби: глубокая рефлексия, желание разобрать вещи на атомы, докопаться до причины, до сути: такой кайф, жвачка для мозга. Разные философы пытаются найти решения, выстроив логичную архитектуру мироздания. Удивительно, но это неосознанный тренажер очень многое дал для понимания построения архитектуры ПО.
📌Знание кода
Начинали с Серегой вместе с написания кода на C#. C ним я конечно не тягался и пять лет назад, но осталось понимание ООП, паттернов проектирования, абстрактных классов, движение кода в дебаг режиме по методам и свойствам в рамках разных классов с обработкой переменных разной типизации. Это понимание дало тот самый образ, когда ты можешь продумывать от бизнеса и интерфейса вплоть до движения кода по строчкам, каждая из которых - операция, преобразующая данные. Ты можешь думать на этом уровне. Это важно и круто.
📌Знание устройства БД
Продумывая как данные бизнеса обернуть в систему, в голове уже строится образ ER-диаграммы c данными по сущностям и видами связей (один к одному, многие ко многим и т.д.).
📌Знание компьютерных сетей и запросов
Понимание работы протокола http, его запросов с конкретным методом, портов, получения фронтом нужных данных из БД по методам API, дает еще один образ движения данных в рамках системы.
📌Знание интерфейсов
Необходимо хотя бы базовое понимание устройства и работы компонентов, типовых элементов UI kit и подготовки прототипов, макетов в Figma, а также типов страниц, стандартных UX сценариев использования элементов и страниц. Системный аналитик в одном из слоев думает о приложении с позиции интерфейсов, поэтому необходимо иметь образы процессов разработки UX/UI.
📌Написание текстов
Все таки основная рутинная задача - это написание текста. Важно уметь и хотеть его писать, чтобы другие могли понять требования к системе. Текст в Docs - это IDE системного аналитика.
Весь этот суп из образов преобразования, отображения и движения данных должен вариться в голове. Когда аналитик получает данные от продакта или заказчика, то может параллельно беседе выстраивать в голове архитектуру в рамках контекстов-слоев ПО. Думаю именно в этом сложность данной роли.
5АМ | #мотивация
📌Философия
Поставил на первое место именно философию. С вышки она стала моим хобби: глубокая рефлексия, желание разобрать вещи на атомы, докопаться до причины, до сути: такой кайф, жвачка для мозга. Разные философы пытаются найти решения, выстроив логичную архитектуру мироздания. Удивительно, но это неосознанный тренажер очень многое дал для понимания построения архитектуры ПО.
📌Знание кода
Начинали с Серегой вместе с написания кода на C#. C ним я конечно не тягался и пять лет назад, но осталось понимание ООП, паттернов проектирования, абстрактных классов, движение кода в дебаг режиме по методам и свойствам в рамках разных классов с обработкой переменных разной типизации. Это понимание дало тот самый образ, когда ты можешь продумывать от бизнеса и интерфейса вплоть до движения кода по строчкам, каждая из которых - операция, преобразующая данные. Ты можешь думать на этом уровне. Это важно и круто.
📌Знание устройства БД
Продумывая как данные бизнеса обернуть в систему, в голове уже строится образ ER-диаграммы c данными по сущностям и видами связей (один к одному, многие ко многим и т.д.).
📌Знание компьютерных сетей и запросов
Понимание работы протокола http, его запросов с конкретным методом, портов, получения фронтом нужных данных из БД по методам API, дает еще один образ движения данных в рамках системы.
📌Знание интерфейсов
Необходимо хотя бы базовое понимание устройства и работы компонентов, типовых элементов UI kit и подготовки прототипов, макетов в Figma, а также типов страниц, стандартных UX сценариев использования элементов и страниц. Системный аналитик в одном из слоев думает о приложении с позиции интерфейсов, поэтому необходимо иметь образы процессов разработки UX/UI.
📌Написание текстов
Все таки основная рутинная задача - это написание текста. Важно уметь и хотеть его писать, чтобы другие могли понять требования к системе. Текст в Docs - это IDE системного аналитика.
Весь этот суп из образов преобразования, отображения и движения данных должен вариться в голове. Когда аналитик получает данные от продакта или заказчика, то может параллельно беседе выстраивать в голове архитектуру в рамках контекстов-слоев ПО. Думаю именно в этом сложность данной роли.
5АМ | #мотивация
Ребят, вижу, что некоторым интересно посмотреть как устроен процесс системного анализа и работы с требованиями, оставили огонечки. Охват пока что небольшой, думаю за формат, как лучше сделать. Кину голосовалку) ⬇️
Как лучше расскрыть тему процессов системного анализа?
Anonymous Poll
10%
Провести стрим. Зайду.
20%
Записать скринкаст. Посмотрю.
6%
Пояснить в кружках. Посмотрю.
62%
Цикл постов. Почитаю.
2%
Свой вариант. В комменты.
Пятничная честность ❤️
Я поставил цель дорастить наш канал до 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АМ | #мысли
Я поставил цель дорастить наш канал до 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АМ | #мысли