На прошлой неделе собрал первую часть цитат канала) Публикую вторую мякотку) Часть №2. Поехали)

- "Акты выполненных работ — это деньги, конвертированные в бумажку с подписями" (тут)
- "Есть два библейских вопроса от стейкхолдера к продакту: Сколько и Когда?" (тут)
- "Разрабам все равно на задачи, положа руку на сердце, им важно делать дизайн, код, документацию" (тут)
- "Если хочешь что-то поменять в системе управления — обсуди с командой!" (тут)
- "HR — для стартапа или студии - это основа того, что ты сможешь выполнять обязательства" (тут)
- "Хороший продакт не ставит задачу вне системы управления, но информацию собирает неформально" (тут)
- "А не херню ли мы делаем?" (тут)
- "Чем глубже и больше шагов опущено в логической цепи в коммуникации команды, тем стоимость её выше" (тут)
- "Границы возможностей... Вот где оно? То, что будет тем что нас придавит и будет прям неподъемным" (тут)
- "Отсутствие конкретики худшее для определения приоритетов. Пуште конкретику" (тут)
- "Состояния — это и есть данные" (тут)
- "...Когда выходишь на прогулку в это время, цивилизация как-будто отсутствует. Есть только эта тишина, которая передается в сознание..." (тут)
- "Для бизнеса важно не только то, что вы им сэкономите, а еще и что не уроните их текущий заработок" (тут)
- "Отталкиваться от имеющегося. Не прыгай. Имей стратегию. Двигайся ровно и используй то, что у тебя есть."(тут)
- "С точки зрения бизнеса самое сложное кроется в синхронизации направлений по проектам, то есть - каждое направление должно работать внахлёст". (тут)

5АМ | #цитаты

А ну-ка, кто сможет сходу сказать чем отличаются задачи product manager-а от product owner-a?)

Чур не гуглить) И не молчать😝

"Отец" и "Сын" продукта

Раньше, когда люди делали реально крутые вещи: ракеты, интернет и марсоходы, роль продакта была у главного инженера) Его видение охватывало весь продукт, поэтому их называли отцами продукта😁 20-30 лет назад продакты начали рождаться из профессии инженера, маркетолога, дизайнера. Был бэкграунд, опыт, а сейчас продакты ныряют в профессии после института и курсов. Мои преподаватели из Академии ФСБ тоже сетовали, что во времена КГБ в академию поступали после опыта армии и пары заводов.

Именно это приводит к тому, что у product-ов все никак не очертится их роль и в зависимости от размера компании продакт выполняет свои задачи по-разному. А когда корпоративный мир всем остальным сказал, что нам еще и owner-ы нужны оказывается — путаница увеличилась)

Масштаб - вот отличие между ними

Допустим большая картина, к примеру, "Явление Христа народу" А. Иванова. (Оффтоп эмоции - вы её видели вообще эту махину, 5х7 м? вот он - продакт менеджер "отец"😂).

Продакт думает за масштаб: какой должна быть картина, почему именно такой, почему понравится зрителям, что на ней должно быть, в какой позе должны быть персонажи, кто заказчик, как деньги платит, кому продать её потом?) Он смотрит на все без кадрирования (кроп-а), даже за рамками картины. Оwner же общается с поставщиками красок, контролирует наброски каждого эскиза(фичи) картины (Иванов сделал более 600-т эскизов), строит роадмапы, пинает Иванова "когда"!?, говорит что "вот должен быть Христос, должен быть народ")) Ну вы поняли)

Продакт и овнер - это два альтер эго Иванова))

Продакт - общается с князем Александром (тот, что потом станет императором). Овнер - пинает Иванова делать картину (20 лет делал) и говорит как надо.
Продакт - мыслитель. Овнер - реализатор.
Продакт - комбинатор. Овнер - соединитель.
Продакт - в медитации. Овнер - в суете.
Продакт - Отец. Овнер - сын😄

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

Используем ли мы HADI циклы в разработке Локео?

✏️Напомню, что это методика для тестирования гипотез. HADI - акроним: Гипотеза (H), Действие (А), Данные (D), Вывод (I-insight). В этом методе есть еще две вещи - это вера в гипотезу (F-faith) и сложность (C-complexity). Кто не знал, вот, а кто знал - повторил)) Скучная часть закончилась)

Мы используем гипотезу как связующее звено между запросом и требованием.

📌В b2b - запрос всегда сводится к деньгам.
Например, у нас ключевой запрос - это "хочу повлиять на долг клиента".
📌Гипотеза - «Если будет автоплатеж по лицевому счету, то количество долгов категории "потому что забыл пополнить" сократиться».
📌Как раз Action здесь будет требование "необходимо реализовать автоплатеж в личном кабинете сотрудника, чтобы он мог предложить его настроить в момент прихода клиента в офис".
📌Метрикой же здесь будет коэффициент долговых начислений из месяца в месяц (сумма_начислений_долг/сумма_начислений_без долга). Например, 1000 начислений, из них 100 долг. Метрика 10%, стараемся в следующем месяце на неё повлиять (снизить).

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

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

Согласны с этим или думаете, что все-таки гипотезы нужно тестить как можно быстрее?🎩

5АМ | #маркетинг

Конвертация

Знаете конверторы из png в jpg и так далее. Вот продакт - это конвертер😄

Продакт конвертирует:
- Запрос в гипотезу
- Гипотезу в процесс
- Процесс в данные
- Данные в процедуру
- Процедуру в возможность
- Возможность в требование
- Требование в задачу
- Задачу в результат

♻️Запрос в гипотезу
Бизнес или клиент говорит "у меня болит". Мы ставим "диагноз" и предполагаем, что это решит проблему, выводя гипотезу.

♻️Гипотезу в процесс
У каждой гипотезы есть результат, который нужно добиться, чтобы перестало болеть. А чтобы его добиться, нужно выполнить набор шагов, возможно даже разным людям и системам.

♻️Процесс в данные
Зная каждый шаг, мы можем вывести крупные категории данных и общие данные обработки. Любой процесс и вся человеческая деятельность (если убрать всю лирику) направлена на преобразование данных из 1 в 0 и обратно.

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

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

♻️Возможность в требование
Для каждой возможности уже просто выдать требования к дизайну, обработке (бэку) и выводу (фронту).

♻️Требование в задачу
Пачку требований уже можно выводить в проектное управление. Выводить в проекты, в эпики, оценивать по направлениям. Строить роадмапы. Формировать спринты с точной привязкой ко времени.

♻️Задачу в результат
Стандартная разработка, где каждый специалист выполняет свою работу и реализует свою часть, кирпичек за кирпичиком строит процесс, так необходимый для гипотезы, которая так нужна для ответа на запрос)

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

Фича-паразит

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

Допустим, у нас уже есть раздел "клиенты". Он был добавлен для решения проблемы нашего пользователя в рамках гипотезы "А". Чтобы добавить "клиента", пользователь проходит определенные шаги. Набор данных строго обозначен. Фичи поставлены.

Но спустя время мы пытаемся решить другую проблему, которая повлияет на метрики. Формируем гипотезу, строим процесс и видим, что в раздел "клиенты" требуется добавить еще данные, чтобы общий процесс заработал. Допустим требуется, чтобы при добавлении "клиента" пользователь выбрал определенный "тип" клиента в дропдауне и установил чек-бокс.

Что происходит в этот момент:
- возможность "создать клиента" раздваивается на две версии, каждая из которых влияет на разные процессы (job-ы). Значит нужно править документацию, отрезая версию для этой процедуры
- если произошло расщепление на версии, то в макетах тоже нужно развести эти процедуры. На уровне макетов появляются состояния и дизайнеру нужно исправить как базовую версию, чтобы отразить новые дропдаун и чек-бокс и новую версию с прожатыми данными.
- дропдаун и чек-бокс становятся необязательными данными, нам нужно исключить их из валидации, т.е. бэк и фронт должны это учесть.
- если данные необязательны, то их нужно по-особому объяснить клиенту в UX или текстах.
- ситуация осложняется, если для выполнения общего процесса требуется добавить несколько таких фич в разные сущности.

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

Есть помощь. Фича-паразит боится колдовства. Нужно произнести заклинание "АНАХУАЭТОНУЖНО"😄 И чаще смотреть в документацию "книгу Заклинаний".

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

Ребята, а мы прямо сейчас ищем тестировщика тестить наши крутые продукты)

Как выражается наш лид фронт Женя: "Нам нужен такой тестер, которого я буду ненавидеть".😄

Если у вас есть посоветовать крутышей или ты сам такой, то можешь смело писать мне - @limskov

5АМ | #вакансии

Психологический контакт

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

Мой топ методик по установке психологического контакта:

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

✏️Обращаться по имени
Тут все просто. Если вы чаще обращаетесь по имени, то человек быстрее увидит в вас друга и будет расположен. Это переход в ближний круг.

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

✏️Подстраиваться
Мимикрировать - сложный, но интересный навык. Человек серьезный - не нужно вести себя расхлябано, соберись, выправь осанку, поменяй тон. Человек более расслабленный - расслабьтесь, измените манеру поведения. Тут важна методика прощупывания и предыдущий пункт. Можно конечно поговорить и о НЛП, но тут все просто: повторяйте манеры и действия человека.

✏️Будьте приятными, шутите и улыбайтесь
По социальным меркам нужно быть приятным. Нужно следить за собой, особенно мужчине) Если вы не приятны и не опрятны, то это не поможет снять блок. Шутки могут снять барьер, а улыбка расположит к себе. Это базовая вещь.

Вы скажите: "Фу! Это манипуляции". Да, если ты используешь это только ради своей выгоды. Все решает умысел. А вот расположить к себе, чтобы быстрее достигать общего результата или быстрее понять мотивацию человека, чтобы не тратить время и ресурсы - это очень важно.

Важно: все это не работает без одного компонента - искренности. Нет искренности - вам не поверят и псих. контакт не установить)

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

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

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

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

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

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

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АМ | #мысли