Работая в айтишечке

Пятничный мем

#memes

☕️ Почему метрика просела

Дима Некрасов (CEO JetMetrics) в своём канале опубликовал классный гайд, с помощью которого можно "превратить падение метрики в инсайты и действия":
1. Убедитесь, что просадка реальна
2. Разложите метрику на драйверы
3. Изучите динамику драйверов
4. Рассмотрите драйвер в разрезах
5. Сравните сегменты
6. Сформулируйте гипотезы

Этот подход заставляет задавать правильные вопросы:
— Почему метрика упала именно сейчас?
— Где именно произошел сбой?
— Какие изменения могли повлиять?


Если вы из e-commerce, вам точно стоит посмотреть материалы и продукты ребят из Jetmetrics. Более исчерпывающего исследования по метрикам я не видел.

#analytics #ecom #metrics

☕️ Принципы вместо процессов

«Полный контракт» — миф. В институциональной экономике давно доказано: невозможно заранее учесть все условия сотрудничества. То же верно и для процессов. Пытаясь прописать каждую деталь, мы создаем иллюзию контроля. Реальность же полна неожиданностей.

Можно потратить месяцы на «идеальные» чек-листы/bpmn-схемы. Но как только команда столкнётся с ситуацией вне сценария, всё разрушится. Выход? Используйте принципы, например:
— "Решай быстро",
— "Объясняй причину",
— "Бери ответственность".
— "Пиши поддерживаемый код"
— "Тестируй до мержа"

Так даже в хаосе действия будут согласованы.

Принципы — это не замена процессам, а их фундамент. Например, когда перед вами встанет выбор: внедрять новую библиотеку или использовать проверенное решение? Принцип «Поддерживаемый код» сразу даст ответ — даже если библиотека круче, её сложность может затормозить команду в будущем.

Процессы — это карта, которая не учитывает новые дороги. А принципы — компас. Их цель не контролировать, а направлять. И в этом их сила.

#thoughts #processes

☕️ Принцип MECE (Mutually Exclusive, Collectively Exhaustive)

Один из главных принципов, которому учат в консалтинге. При этом в большинстве источников авторство приписывается McKinsey и Барбаре Минто в частности.

В моём арсенале этот метод занимает видное место в ежедневных рутинах. Он помогает систематизировать любую предметную область — создать классификатор чего либо, разбить тикеты на стримы, систему на подсистемы, составить план презентации и т.д.

Я видел множество статей, пытающихся доходчиво объяснить, что это такое и как использовать. Но лучшее, пожалуй, описание встретил на днях в книге 1958 года Уемова Авенира Ивановича "Логические ошибки. Как они мешают правильно мыслить". Очень рекомендую к прочтению.

MECE-принцип можно описать как строгое соблюдение правил деления понятий , которые Уёмов подробно описывает на страницах 69–74.

Если перекладывать MECE на понятия и термины книги получится следующее:

MECE — это правильное логическое деление понятия, при котором:
— Объём членов деления в сумме равен объёму делимого понятия (Collectively Exhaustive).
— Члены деления не пересекаются между собой (Mutually Exclusive).
— Деление ведётся по одному основанию , без смешивания критериев.
— Деление не пропускает ступеней и охватывает всё множество.

Этим постом хочу рассказать не только про классный MECE, но и показать, как иногда можно присвоить авторство чего-то общедоступного, из разряда здравого смысла, просто грамотно упаковав в "фреймворк".😁

Почитать про MECE (рандомная подборка статей):
— MECE: Основы структурного мышления для решения сложных задач
— Наводим порядок в мыслях: структурируем идеи c помощью принципа МЕСЕ
— Принцип MECE в деловых презентациях

#thoughts #logic #mece

☕️ Проблемы детального планирования

Понравился пост Адама Елдарова в его канале "Записки C3PO". В нём он высказывает тезис, что детальное планирование фичей на большом горизонте не просто не имеет смысла (в ситуации с высокой изменчивостью среды мы вынуждены будем постоянно корректировать планы), но и вреднО.

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

Когда детальное планирование всё же работает
Есть конечно ситуации, где детальное планирование оправдано:
— Регулируемые отрасли (медицина, финансы).
— Фиксированные дедлайны (например, запуск продукта к выставке).
— Интеграция с внешними системами , где изменения в одном блоке ломают другие.

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

Как успокоить внутренних заказчиков
Ещё существуют ситуации, когда внутренним заказчикам определённых фичей надо показать, когда их "заказ будет выполнен", а с учетом того, что эти фичи не всегда в первом приоритете им выпадает доля занять место Q5 (условный «далекий горизонт») в ячейке роадмапа.
Делать такое можно, но с оговоркой: «Мы планируем рассмотреть эту задачу в Q5, но финальный приоритет зависит от результатов текущих экспериментов».


Баланс между гибкостью и структурой
Главная мысль:

Фокусируйтесь на проблемах пользователей и целях бизнеса, а не конкретных фичах.

Рекомендации (с дополнениями):
❶ OKR вместо роадмапа
Лучше потратить время на детальные OKR, чем на расписывание фич по неделям. OKR задаёт направление, но не сковывает руки конкретными решениями.

❷ Фокус на 3–5 ключевых направлениях
Ресурсы ограничены — реализовать всё за раз невозможно. Выберите самые важные направления.

❸ Принципы вместо процессов
Вместо пошаговых инструкций определите правила:
— «Всё, что ускоряет time-to-value, приоритетнее».
— «Любое решение должно быть проверено на MVP».

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

❺ Итерации через PDCA: адаптация после каждого цикла
Используйте цикл PDCA (Plan-Do-Check-Act) для постоянной корректировки.

Заключение: «Планируйте, но не фанатейте»

Не отвергайте планы полностью, но делайте их живыми.

Детальное планирование — как карта в тумане: полезно для ближайших поворотов, но бесполезно для всего маршрута. Лучшие команды сочетают стратегическое видение с тактической гибкостью.

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

#pm #thoughts

Пятничный мем

#memes

☕️ Как внедрять изменения в команде: 3 этапа по Коттеру

Внедрение изменений — сложная задача, особенно в IT-командах, где рутина и привычные инструменты кажутся «работающими». Но как заставить команду перейти на новый инструмент или методологию без сопротивления? Джон Коттер, эксперт по управлению изменениями, предлагает проверенный фреймворк. Расскажу, как применить его на практике.

Изменения — это про контекст и эмоции. Вот три этапа, которые позволят воплотить изменения:
— Срочность — покажите, что текущая боль больше, чем усилия на изменения.
— Лидеры — найдите «чемпионов», которые станут вашими амбассадорами.
— Результаты — начните с малого, чтобы создать инерцию.

#change #productivity #teamwork #tools #agile

☕️ Лайфхак: Как найти дубликаты в базе данных с помощью SQL

Дубликаты в данных — частая проблема, которая может привести к некорректным аналитическим выводам, ошибкам в расчетах или ухудшению пользовательского опыта.

Например, дублированные email-адреса в CRM увеличивают расходы на email-рассылки, а повторяющиеся записи о заказах — риск двойного начисления бонусов.

Из прикреплённых к посту карточек вы узнаете, как найти их с помощью SQL.

#sql #data #tips #database #productivity

☕️ Генерация промптов для LLM силами LLM

Да, так тоже можно — LLM (языковые модели) могут не только отвечать на вопросы, но и писать промпты для себя и других моделей.

Итого — сначала просите сгенерировать промпт, потом его же используете для ответов на свои вопросы.

Работает замечательно и лучше чем режим "мышление". Но вот сам промпт лучше генерировать в режиме "мышление"😁

#ai #llm #prompting