Выходной оффтоп)

Мне нравится читать фантастику. Сейчас читаю «Туманность Андромеды» Ивана Ефремова) Он, как и Герберт Уэльс в книге «Люди как Боги», показывает утопическое общество, в котором во главу угла ставится контроль над природой и воспитание человека.

Я уже не раз писал про диалектику: как она важна для правильного анализа и построения систем, для написания кода.

Смотрите какие строчки нашел 🔥

5АМ | #цитаты

Пирамида развития монетизации крупного продукта

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

На схемке показал эти уровни:
- Вершина: создается база, без которой не может существовать приложение.
- Второй уровень: продаем все что есть за одну цену.
- Третий уровень: продаем каждую часть по отдельности.
- Четвертый: разбиваем каждый блок и продаем (допродаем) отдельные возможности для конкретных блоков
- Пятый: тарифицируем возможности. Считаем сколько было затрачено данных, в конкретной сущности (не более 1000 заказов или 10000 запросов).

С каждым уровнем растет точность расчета и гибкость внедрения новых платных продуктов. Одно но: растет и сложность такого расчета. Растут именно административные затраты на монетизацию и её поддержку. Чем ближе к основанию пирамиды, тем глубже монетизация внедряется в сам продукт - бэкенд должен быть покрыт точками сбора данных, выключением/включением функций, подсчета затраченных купленных «баллов».

В случае с B2B очень важно актирование. С ростом сложности у продукта должна быть своя автоматизация быстрого формирорвания счета и акта (как и какие данные в них попадут). Чем сложнее и мелочнее становится монетизация, тем дороже поддерживать её не только административно, но и системно.

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

5АМ | #компания

Февраль, 2001-й год. Горнолыжный курорт Snowbird в США. Встретились как-то 17 мужиков из сферы разработки ПО, которых задолбало описывать работу кода и рисовать UML диаграмки, которые будут пылиться на полках в папках и не обновляться, при этом не написав ни строчки кода. И договорились, что весь мир будет дальше болтать по Zoom, пить латте на кокосовом и обсуждать "прибить или приклеить". Ну а если серьезно: написали они 12-ть принципов Agile)

Поговорим о том, почему Agile - это, блин, дорого 😭

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

Вообще, тема стара как мир. Сократ, Зенон, Диоген, софисты развлекались в древности с инфой как могли) В основе всего лежит научный метод, который дает способы исследования и формулирования выводов на базе данных, которые мы добываем эмпирически. Еще стоики определили: хорош теоретизировать - подтверди практикой.

В конце концов вывели гипотетико-дедуктивную модель из 4-х шагов: исследуй для формирования опыта, выведи гипотезы, доведи до результата, проверь на фактах. Ни на что не похоже? Scrum кажется)

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

Соответственно от этого выходит базовый метод, от которого плюются последователи Agile: Waterfall. Пока не будет сделан прошлый этап к следующему ни-ни. Очень хорошо подходит, когда все понятно, но не всегда бывает все понятно. Нужны идеи.

Вот тут-то и кроется главная цель у Agile и его фреймворков (еще по научному методу) - это проверить идею (гипотезу). Поэтому появился Scrum - "А давайте накидывать идеи и быстро-быстро все вместе делать и обсуждать все постоянно". А потом Альфа банк такой - Scrum Master 250 000 руб. ваша задача (цитата): "Организовать работу коллектива так, чтобы они вместе генерили идеи". А скрам мастер помогает продакт оунеру еще, который тоже за 250к. Scrum - это высшая точка усложнения методики, поэтому смотрю на него. Kanban хотя бы просто про воронку и стикеры на досочке)

Чтобы скрам работал:
- Нужно, чтобы PM и PO хорошо поработали над требованиями, чтобы хорошо поработать нужно провести исследование и написать аналитику с выводами, поэтому нужны аналитики. (750-900к руб. + полис ДМС)
- Нужен скрам мастер, который будет бегать и пинать всех, писать и обновлять цели, постоянно совещаться, травить шутеечки и решать кто все таки обидел Коляна? Ирина или Петя. Колян же выгорел, он потерял мотивацию) (200к + скинуться на кофе Коляну)
- Скрам команда должна состоять из фулл стака спецов, которые могут решить проблемы, связанные с идеей. Команда должна быть самодостаточна. PO только поставляет требования, а ребятки сами все решают. Это горизонтальная или даже матричная структура компании с самостоятельными юнитами, а значит в ней должны быть лиды по направлениям, у каждого должно быть по миду и еще подметала джун: т.е. backend, frontend, tester: 9 человек минимум, в отпуска то нужно ходить. (2-3 мульта по рынку)

Итого один юнит будет кушать 3-4 млн р. в месяц или 50 в год. 🎩

Я конечно гиперболизировал, но вопрос именно в своевременности внедрения тех или иных методик и адекватности затрат для текущего уровня развития компании. На маленькой команде можно комбинировать решения. Тема жирная, киньте 🔥 и я напишу как можно комбинировать для небольших команд)

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

Ну огонечков слишком много, чтобы игнорировать😝 Разберем тему своевременности через Agile)

Компания на каждом этапе развития имеет разную орг. структуру. Масштабирование влияет на выбор модели управления от простой иерархии до матричной структуры с двойным подчинением, где один менеджер говорит "сколько", а второй "когда". В этом есть большая проблема найма. Ребятки приходят работать из разных компаний. Переход из стартапа в корпорацию или из корпорации в стартап должен иметь у спеца внутреннюю установку на переключение моделей управления, иначе будет груститься и вздыхаться. Крупными мазками можно выделить три группы: маленькая компания (до 15-ти чел., справится один менеджер в поте лица), средняя до 50-60-ти (отдел управления), крупные и корпорации все остальное.

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

Разберём комбинации для маленьких компаний. Какие части Agile и как можно применять на этом уровне:

Важно разделить разработку на две части: отработка идей (20%) и потоковая выдача обычного результата (80%). Это основа для комбинирования подходов. Для части плана разработки используем scrum, для другой kanban.

В Agile исследования, аналитика и документация продукта никуда не уходят. Теоретический scrum не может работать без двух вещей: без переданных по шаблону требований и без полного набора спецов для поставки гипотезы. Но, также, что не менее важно - scrum не может работать с командой большей, чем нужно для отработки гипотезы. Почему? Будет простой: зачем дизайнеру Стасу быть в scrum команде пока не появится техническое решение. Будет сидеть куковать, пока Женя будет пилить прототип редактора документов.

В моем опыте есть две ситуации:
- когда кодеры не знают что нужно делать
- и когда продакт и дизайнер не знают какие есть технические решения их гипотезы.
Эти две ситуации как раз таки те 20% всей разработки. Поиск решений.

В первом варианте: Формируем scrum команду из продакта, аналитика, дизайнера. Остальные консультируют на подхвате. Результат требования, процесс, набор данных и прототипы. Можно запилить за пару спринтов. Показали команде разработки, они уже потоково начинаю пилить.

Во втором варианте: Формируем scrum команду из продакта, backend-а, frontend-а, тестера. Пример: найти решение для редактора документа.

Все остальное это kanban. Что генерировать то, если просто табличку с данными нужно запилить да побыстрее. Так что выстраиваем поточный процесс по kanban: нашли по scrum решение гипотезы и начали отрабатывать в потоке. По пятницам синкуемся. Переключение режима просто, тумблер, чик-чик)

Scrum - это бег на короткую дистанцию (спринт собственно), он может расхолаживать. Работа в потоковом процессе в kanban - это марафон. Крупные приложения - это про 20% найти решение и 80% пробежать марафон, где НЕ нужно экспериментировать, где нужно просто сделать 200 возможностей, ёмае, без болтовни.

Если нужно забить гвоздь - зачем ты схватился за кувалду, Иннокентий? 😎

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

Все, хватит с лонгридами) Буду мемесы кидать😝

На этой неделе провожу интервью для раздела передачи показаний по счетчикам) Вот один в один чувствую себя как этот котяра😄

5АМ | #мемы

Дайджест #3

Философии сознания:
⭐️ Внимание и философия сознания
📌 Философия в аналитике и управлении
📌 Сценаристика - Конфликтология - Типология

Продуктивность:
⭐️ Куда ты хочешь расти вглубь или в ширь
📌 Тело дня и интуиция
📌 Методики формирования внутреннего стержня

Заказчики и бизнес:
⭐️ Зубрыыыы
📌 Типы заказчиков: Работа с профи
📌 Главная сложность управления студией

Аналитика и документация:
⭐️ Конвертация из запроса в задачу
📌 Как это все версионировать?

Управление:
⭐️ PM и PO: Отец и сын продукта
📌 Тактическое и стратегическое управление
📌 Принять решение на основе данных

5АМ | #дайджест

Честный разговор, рефлексия

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

Самая важная привычка, которая приближает продакта к предпринимателю - это вставать каждый день с мыслью о том, как сделать так, чтобы твой продукт принес деньги. По крайней мере, не меньше чем в прошлый период.

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

Какие у меня есть понимания сейчас на уровне джуна предпринимателя:

Никто никогда не продумает за тебя систему и процесс.
Не нервничать и не быть наивным по этому поводу. Тебе могут в этом помочь за деньги, но это всегда должен быть твой сценарий. Многие будут переубеждать, что нужно доверять, передавать. Нужно передавать по своему сценарию, а передавать по своему сценарию - это уметь разобраться и точно знать, что ты хочешь. Можно украсть, но адаптировать все равно придется, а адаптировать - это значит понимать.
Всегда ищи кандидатов в доверенный круг
Какой бы звездой не был - ты ни кто без крутых и талантливых людей. Искать их и делать так, чтобы им было интересно, комфортно и голодно одновременно — постоянная задача.
Найди зама, который примет эту позицию и глубоко уважай его за это
Тема зама объемная. Всегда нужно иметь плечо. Талант, принятие позиции и доверие как комбинация — невероятная редкость. Разберу если будет интересно. Кидай - 👍
Сделай все, чтобы было чем платить (не было кассового разрыва)
Без комментариев)
Защищай свои деньги и команду
Другие на готове, нужно уметь отбиваться. Не нужно зацикливаться, это игра, все в неё играют, просто нужно быть на готове.
Качать скорость обработки данных в голове
С ростом уровня не становится меньше проблем, обрабатывать нужно огроомное количество сценариев. Я делал пост про то, как качать тут.

Не буду писать типа «развивай себя, продукт, не бойся ответственности» и все такое. Я за глубину. Есть вещи, которые ощущаются тонко. Опыт всегда очень тонкая вещь. Знаю, что нельзя останавливаться, нельзя совершать ошибки, которые совершил. Уметь видеть потоки спроса, понимать, когда ты в нем и не в нем и перегрупировываться, адаптироваться - это основа выживания. Нужна глубокая зрелость.

Я иду по этому пути уже довольно долго, успехи есть, но все кажется что не то и недостаточно. Есть некоторая скромность назвать себя предпринимателем, мне пока сложно это сделать. Хотя оглядываюсь и вижу, что со мной идут такие крутые люди, как я могу их подвести. Что продукты, которые мы запускаем - нужны людям. В общем, страшно. Причем иногда страшно не только от того, что не получится, но и от того что получится. Но делать нечего, зажмурился и двигаюсь, благо есть на кого опереться, команда, ребята, люблю - 💪🫶 ))

5АМ | #мысли

Почему сложно быть айтишником)

Попался мне тут один мужичок, который размышлял на эту тему, просто процитирую) Вот три его пункта:

📌 Ты постоянно должен учиться
Все устаревает. Если не будешь следовать тенденциям, то никому не будешь нужен уже через пару лет)

📌 Ты не можешь остановиться думать
Работа не останавливается в 18:00. Если не решил какую-то проблему, не достроил архитектуру, не решил баг, то с красными глазами в ночи, лежа в кровати и пялясь в потолок, перебираешь варианты как это решить)

📌 Ты думаешь, что все логичны
В разработке всегда строгая логика, и ты привыкаешь так размышлять, но в окружающем мире не все люди так же логичны: крик души, ну почемууу😭

5АМ | #мысли

Нашел такое высказывание:

«Великие не жертвуют важным ради срочного. Они решают насущные проблемы, чтобы обеспечить будущее...»

5АМ | #цитаты

Чудеса категоризации

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

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

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

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

Переведем все на язык обработки данных:

Органы чувств
Интерфейс программы. Механизм сбора данных, своего рода био-реле) Слух - сбор звуковых волн, вкус и обоняние - сбор химического состава веществ, зрение - сбор электромагнитного излучения светового диапазона (потока фотонов), осязание - пачка реле (давление есть/нет, холод есть/нет и т.д.) Они напрямую связаны на запись в био-БД) Но если есть интерфейс, есть база данных, то должны быть и интерпретаторы, обработчики. Добро пожаловать в био-бэкэнд, который мучает нас на ежедневной основе, и от которого мы все так пытаемся убежать)

Ум и Разум
Первая ступень категоризации - это ум. Распределяет все на приятно — не приятно. Ом-ном-ном кофе на кокосовом молоке - какой кайф, или непонятная задача незакрытая еще с пятницы в приоритете high - боль, уйди, не хочу😭 Ну вы поняли.
Вторая ступень категоризации - это разум. Распределяет все на хорошо — плохо. Кофе на кокосовом конечно кайф, но я не сплю и у меня мешки под глазами, или непонятная задача, но за ипотеку то платить нужно)
Распределение категорий этими двумя ребятами не могут работать без БД (его еще опытом называют). Они получают данные из внешнего мира и начинают сопоставлять: "так я задеплоил в пятницу, прод рухнул в субботу, выходные я с женой не провел, мне дали в тык". Наступает следующая пятница, рука тянется залить, и ты такой оп - "деплоить в пятницу не буду") Сопоставляет такие логически цепи, кстати интеллект, поэтому есть те, до которых не доходит)) Ум и Разум выносят суждение, вывод. Делать — не делать. И тут следующий уровень.

Тело - Душа
Эти ребята самые бедные в этой цепи. Они вообще не вдупляют что происходит. Им просто говорят — делай. И тело начинает вытворять дичь: работать до 12, есть и пить ерудну до отвала и другие виды наркомании. Про душу молчу, потому что это тяжелая структура, состоящая из нескольких уровней Я. Мы просто в потоке обработки данных её не видим.

И тут самое интересное - весь этот процесс не прекращается ни-ко-гда. Мы постоянно собираем информацию, постоянно её обрабатываем и нас постоянно плющит куда-то бежать и что-то делать)) Поэтому кони в метафоре безумны, поводья еле удерживаются, а душа и тело постоянно на измене вообще)

У потрясающего поэта нашего времени - Веры Полозковой есть такие крутые строки, которые не выходят у меня из головы:
...
Что, смиренная моя плоть,
Тесная моя клеть -
Я хотел тебя расколоть,
Свергнуть, преодолеть
... (тут весь стих)

Выход один. Всякие буддисты и Гай Ричи говорят заткнитесь, молчите) Смысл какой: нужно заткнуть интерфейс. Грубо говоря в органы чувств постоянно поступают данные потоком - 11111. Вот так. Нужно вырубить его - 00000. Вот так. Тогда не будет работать ум и разум, тогда тело расслабится и можно будет увидеть душу. Это очень сложно, но опыт безумно интересный, у меня лично не получается)) Получалось у единиц, они обычно прораками религии становились) Кхэм-кхэм)

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

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

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

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

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

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

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

Что думаете?

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