Менеджмент

В книге Алестаэра Нэрна Engines that Move Markets — Technology Investing from Railroads to Internet and Beyond исследуется как важнейшие технологические изобретения последних 200 лет — от железных дорог до интернета — влияли на финансовые рынки и состояние инвесторов. Предисловие к книге написал сэр Джон Темплтон в 2000 году, на пике дотком-мании:

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

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

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

В данном посте я постараюсь не делать выводов, а лишь хочу подсветить и обсудить моменты, требующие внимания.

Начну с проблемы: мой опыт работы в разных отраслях, от небольших геймдев компаний до крупных IT-гигантов, показал, что продуктовые аналитики (далее - аналитик(и)), работая в команде, подвержены когнитивному искажению, когда хотят выдать желаемое за действительное. В таком случае статистика превращается в одну из форм лжи. Особенно это усугубляется, если премия (или карьерный рост) завязаны на KR команды. И вот вопрос: как защититься от этого «натягивания совы на глобус»? Можно поставить над аналитиком валидатора в виде лида, но, по сути, это выглядит так, будто одну и ту же работу выполняют два человека, причем тот, кто валидирует, обычно делает это поверхностно - из-за нехватки времени и тому подобного.

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

Далее затрону тему эксклюзивных знаний о конкретной части продукта, в которой работает аналитик. Или, как еще говорят, что аналитик обладает глубокими доменными знаниями. На самом деле это очень похоже на создание информационной асимметрии (bus factor). В таком случае я задаю встречный вопрос: «Если нюансы твоей работы задокументировать, останется ли актуальным утверждение о глубоких доменных знаниях?» К чему я это веду? SQL и Python (или любой другой ЯП) ведь останутся прежними; скорее всего, поменяется лишь метрика. А что такое метрика? Это некая математическая формула, зная которую, любой аналитик (почти любой) сможет ее рассчитать. От подобного, опять же, защищает концепция консультантов для бизнеса, которые для удобства своей работы будут создавать и поддерживать подробную документацию. Дополнительный плюс такого подхода — это отказ от изобретения велосипедов, а также обмен экспертизой между аналитиками.

В октябре 2022 года The Open Group официально выпустил Open Agile Architecture™ (O-AA) — новую версию стандарта, призванного соединить мир «классической» корпоративной архитектуры с реалиями Agile, DevOps и цифровой трансформации. Первая версия документа была опубликована Open Group еще в 2020 году.

Если вы корпоративный архитектор, архитектор решения, бизнес- или системный аналитик, и до сих пор считали, что Agile — это «про разработчиков», а архитектура это «про рисунки и бумажки», эта статья для вас. Задача этой статьи — дать краткое содержание стандарта Open Agile Architecture, чтобы вы могли сами решить, нужно ли его вам изучить подробнее или нет.

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

И вот что я заметил: почти все, кто пытается выстроить систему управления, начинают с одного и того же вопроса — «Какой инструмент мне взять?» Notion? Jira? Obsidian? Linear? Асана?

Тут я всегда отвечаю одно: выбор инструмента — это последний вопрос, а не первый.

«А если мы просто возьмём больше разработчиков, уложимся к концу месяца?»

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

10 факторов нематериальной мотивации. Как простая шкала или счётчик могут менять поведение сильнее, чем деньги и бонусы.

Один мой товарищ буквально за год сбросил около 20 кг веса.

— Ты так сильно похудел. Как у тебя это получилось? — удалось как-то задать ему вопрос.
— Да на самом деле ничего сложного. Скачал приложение для подсчета калорий. В него надо просто фотографировать всю еду. А ИИ по фотографии считает калории.
— И все?
— Ну да. Там у тебя каждый день есть шкала – сколько калорий у тебя осталось на сегодня. Вот я и втянулся как-то в эту игру с шкалой. Соревноваться с ней начал. Она мне 2000 калорий на день разрешает, а я стараюсь еще меньше съесть. Чтобы хоть 100, а лучше 200-300 осталось недоиспользованных. Ну и взвешиваешься через умные весы – график прогресса показывает. Тоже очень приятно.
— А раньше ты так не мог?
— Да чего только не пробовал, интервальные голодания всякие, диеты. А тут все само как-то заиграло. Фоткаешь, играешь, худеешь.

Поменять РП… А если без шуток, то у нас есть два стула, два пути:
1) Действительно поменять РП на проекте
2) Провести работу над ошибками и (или) ожиданиями.

Меня зовут Алина Прасковина, я руководитель проектов в MONS, «КОРУС Консалтинг». И за свою РП-шную карьеру я успела побывать в обоих сценариях. Давайте их рассмотрим чуть подробнее, и разберем, как выйти победителем в наступившем кризисе.

Всем привет!

Меня зовут Владимир Павлов, я продакт‑менеджер. Недавно я проходил кейс‑интервью и получил отказ со следующим комментарием:

«Правильно выбираешь ключевые метрики, но не хватает измеримости, структуры, прокси‑ и контр‑метрик.»

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

Оплатив платный доступ к GPT, приступил к Vibe Coding.

Год ушёл на то, чтобы навести порядок в процессах: выстроили скоринг задач по RICH, ввели требования, ограничили загрузку команд и формализовали тестирование. Хаос превратился в поток, появился контроль сроков, а time-to-market снизился на 30%. Но нагрузки на PO всё ещё остаются.

Когда в продуктовой компании растёт база клиентов, первая линия поддержки всё чаще решает не «где найти кнопку», а «почему сломалась интеграция с CRM» или «как правильно вызвать API, чтобы не уронить биллинг». В этот момент становится очевидно, что старый добрый «скрипт для колл-центра» из двух страниц в Word не работает: оператору нужно держать в голове архитектуру сервиса, бизнес-правила и десятки edge‑кейсов. 

Привет, Хабр! Меня зовут Денис Улизко, я CPO CRM-системы Automation of Sales (AoS) в B2B-блоке МТС. Это тот самый продукт, вокруг которого крутится большая часть моего дня. Я уже не первый год в этой роли, но каждый раз убеждаюсь: она про баланс между хаосом и структурой, а не про красивые концепции. В один день — архитектура, в другой — инцидент на проде, вечером — охота за фокусом. Сегодня расскажу, как эта роль выглядит изнутри на примере AoS, как проходит мой рабочий день, какие решения приходится принимать и как удерживать баланс между операционкой и фокусом на ценность для бизнеса и пользователей. Погнали! 

Эта статья написана для владельцев бизнеса, генеральных и операционных директоров. Мы намеренно упрощаем технические термины, чтобы сфокусироваться на главном — управленческих рисках и деньгах.

Ранее мы уже выпустили фундаментальный разбор Disaster Recovery (DR): что это такое, чем RTO отличается от RPO и какие стратегии защиты существуют. Если вы еще не посчитали, во сколько миллионов обойдется вашей компании день простоя — рекомендуем начать с первой части.

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

Меня зовут  Ярослав, я data pre-sale в MWS. За долгие годы работы я совершил массу ошибок и однажды чуть не похоронил проект, потому что послушал заказчика и не поговорил с бухгалтером, которому в итоге предстояло пользоваться продуктом. Оказалось, их боли — две огромные разницы. В итоге я вывел для себя два главных правила:

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

— Твоя главная суперсила — не техстек, а синергия. Умение переводить с языка бизнес-хотелок на язык Python и обратно, а потом и на диалект «бухгалтера Галины Ивановны» — вот что определяет успех твоего проекта. 

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

Если вы до сих пор пытаетесь выстроить нормальную работу в таск-трекере — расслабьтесь. Это скучно и неблагодарно. Гораздо интереснее использовать эти 11 вредных советов.

Работаю в ИТ с 2004 года. Пришёл осознанно в индустрию не за деньгами - по любви к технологиям и тишине, когда можно заставить машину делать нужные вещи. Начинал с настольных приложений на Delphi, бэкенд на Python, немного React. Сейчас Финтех.

История о том, как, работая тимлидом Python-команды, решился принять вызов на переход в сферу 1С и что из этого вышло.

Недавно я тут на Хабре написал цикл статей про «Запрещенные фразы для ИТ-менеджера». Это фразы которыми неопытные менеджеры пытаются отбиться от неожиданных задач, и это же фразы, от которых почему то плохо заказчикам, бизнесу и начальству.

Там я разбирался почему плохо, и почему фразы:

— Этого нет в ТЗ!

— Этого нет в должностной инструкции!

— У меня нет на это ресурсов!

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

Каждая статья собрала больше 10 000 прочтений, и в каментах к каждой был вопрос: «Окей, чел, если так говорить нельзя, то как можно? Расскажи и покажи на примерах, раз такой умный!»

Это — мой ответ на вопрос, а заодно — легкая шпаргалка, которую можно сохранить и применять постоянно, отправляя тем, кто этого подхода еще не знает.

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

Основана она на моем личном опыте (см профиль), на опыте менеджеров, у которых я этому учился и на опыте менеджеров, которых я этому учил сам, как РПО и ментор.

Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь, там уже почти 4000 манагеров, также читайте мои статьи тут, на Хабре.

Итак, поехали.

Сравниваю, что изменилось в генерации изображений с выходом Nano Banana 2

Полгода назад OpenAI выкатил прорывную генеративную модель. Но она страдала от 5 больших проблем: консистентность, кириллица, сложные сцены, мелкие доработки и кадрирование.

С тех пор вышли два релиза, которые наконец-то решают эти проблемы: Nano Banana в августе и Nano Banana 2 в ноябре.

Сравниваю на реальных примерах — что изменилось и что теперь можно пускать в продакшен ⤵️

Привет, Хабр! Меня зовут Евгений Морогов, я руководитель центра продуктовой акселерации в «Газпром ЦПС». Я работаю в проекте по внедрению VR-технологий, и сегодня я расскажу о том, как мы создавали VR-тренажер по ликвидации инцидента газоводонефтепроявления (ГПНВ) на буровой.

ГНВП — один из самых опасных инцидентов на буровой. Отработка подобных ситуаций на полигонах и на физических тренажерах «вживую» осложняется рядом факторов, которые не позволяют закрыть все потребности в практической подготовке cпециалистов. Среди них высокая стоимость, сложное масштабирование, отсутствие обновлений и возможностей для совместной подготовки, высокие логистические затраты и ограниченность сценариев. Мы решили эти проблемы с помощью VR-тренажера, создав детальную цифровую копию буровой установки.

Если у вас есть похожие задачи, вам интересно, как VR-технологии могут помочь бизнесу или в обучении — этот материал для вас. В статье подробно расскажу, как устроен наш VR-тренажер, как он создавался, какие технические решения мы использовали и как работает наша математическая модель. А также поделюсь, какими были наши первые успехи «в полях».

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

Конкурентное преимущество критически важно в любой сфере, от промышленности до диджитала. На любом рынке довольно быстро появляется один и тот же вопрос, что даёт устойчивый отрыв и как его удержать.

Эта статья написана в попытке собрать в одном месте материал о появлении и эволюции взглядов на First-mover Advantage (FMA) и разложить разницу между первопроходцами, ранними последователями и поздними входящими.

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

Если лонгрид не близок по формату, ниже есть блок с кратким содержанием.