Уходящий год - время больших перемен. Команды моих проектов переходят на модель управления “Клиентократия”. В прошлом году часть сотрудников обучалась этому подходу и весь текущий год мы посвятили тому, чтобы осуществить переход.
К чему мы пришли к декабрю?
На самом деле, у нас большие перемены. Во-первых, мы полностью разделили проекты - теперь команда “Можем” существует отдельно (платформа по оказанию бытовых услуг, куда входят проекты “НянЯрядом”, “Гульдог”, “Мурчалкин”), отдельно - экосистема для работы и обучения “StudentTerra” (куда, в частности, входит и стартап-студия, как команда для быстрого тестирования новых бизнес-идей).
Проекты разделены на команды в соответствии с принципами “Клиентократии”. Для части команд - команды продукта, команды маркетинга, мобильного приложения, развития - уже создана новая система мотивации, которая позволяет каждому ощущать свой вклад в развитие общего дела. Остальные команды будут замотивированы уже в декабре-январе.
Параллельно идет работа по созданию полностью прозрачной экономики и четких метрик качества в каждой команде. Все метрики выводятся на понятные и информативные дашборды.
Если говорить в целом, то за этот год мы внедрили “Клиентократию” примерно на 70%, а значит - осталось немного! Какие-то подразделения уже “живут” по новым принципам, какие-то - начнут уже в январе нового года. Главное, чего мы ждем - полной прозрачности процессов, лучшей мотивации ребят, и максимальную полезность для пользователей наших сервисов!
Пирамида Дилтса — это модель, описывающая уровни мышления и изменения человека, от поведения и окружения до глубинных убеждений и миссии. Она помогает понять, на каком уровне находится проблема или ограничение, чтобы эффективно работать с изменениями.
Уровни пирамиды (снизу вверх):
Окружение (где, с кем, условия). Поведение (что делаю/не делаю). Способности (навыки, стратегии). Убеждения/ценности (во что верю). Идентичность (кто я). Миссия (ради чего живу).
Чем выше уровень, тем глубже воздействие на человека. Например, смена убеждений может изменить поведение, а осознание миссии — всю жизнь.
Слабые сигналы — это ранние, едва заметные признаки будущих изменений, кризисов или новых возможностей. В бизнесе их часто игнорируют из-за неочевидности, но именно они позволяют предупредить угрозы и опередить тренды . Почему это важно В бизнес-среде слабые сигналы играют критическую роль. Они помогают предотвращать кризисы: например, рост мелких жалоб клиентов может сигнализировать о будущем массовом оттоке, а уход ключевых сотрудников — о кадровом коллапсе. Одновременно эти сигналы открывают новые возможности— когда нецелевое использование продукта указывает на перспективный рынок, а эксперименты конкурентов становятся индикатором тренда. Как работать с сигналами? Мониторить периферию : соцсети, отзывы, данные сотрудников Анализировать аномалии даже минимальные отклонения Создавать чувствительные каналы : быстрый сбор информации Парадокс : самые слабые сигналы часто несут либо самые серьезные риски , либо самые выгодные возможности.
В Naumen распределенность — обычная история: офисы в разных городах, часть команд работает полностью удаленно. Отдел технического пресейла — один из таких кейсов. Его руководитель, Паша, работает удаленно, как и большая часть команды.
Несмотря на разницу во времени и расстояние, команде удается сохранять четкие процессы, регулярную синхронизацию и общее понимание происходящего.
Паша рассказал, как он управляет командой в таких условиях, какие инструменты и подходы работают, и что он считает самым важным в распределенной команде.
Чем занимается наша команда
Мы помогаем с технической стороны на продажах: участвуем в пилотах, проводим демонстрации, показываем, как наши продукты работают на реальных задачах заказчиков.
В команде 9 человек, почти все работают удаленно и живут в разных городах. Мы разделены на две группы по продуктам: Low Code и NoCode.
У каждой группы свой тимлид, который отвечает за операционку и распределение задач внутри команды. Я курирую все направление, слежу за тем, чтобы процессы работали, а команды были на связи.
Несмотря на удаленную работу, мы регулярно видимся на больших корпоративных мероприятиях. Это помогает поддерживать связь не только по задачам.
В чем была главная сложность
Самая заметная сложность — непрозрачная нагрузка. В основном мы взаимодействуем с менеджерами по продажам: изначально они писали напрямую сотрудникам моей команды. Задачи размазывались, терялись, пересекались.
В такой системе:
невозможно оценить загрузку;
нельзя планировать ресурс;
нет общей картины, кто чем занят.
Мне, как руководителю, это мешало выстраивать базовое управление. Без прозрачности все превращается в хаос. Мы решили, что пора менять подход.
Как мы выстроили систему
В 2022 году мы внедрили следующие изменения:
собрали таск-трекер на базе нашей платформы Naumen SMP;
сделали Telegram-бота и перевели всю коммуникацию с менеджерами туда.
Теперь процесс выглядит так:
Менеджер оставляет запрос в боте.
Тимлид ведет коммуникацию и ставит задачу на одного из сотрудников.
Сотрудник берет задачу в работу, оформляет результат, закрывает.
Мы ушли от личных сообщений и получили понятную нагрузку, удобный контроль и прогресс. Работать стало спокойнее.
Как поддерживаем связь внутри команды
Удаленной команде без постоянного взаимодействия довольно сложно работать. Поэтому у нас есть несколько форматов:
Дэйли внутри каждой группы — тимлид уточняет загрузку, корректирует задачи, если нужно.
Один-на-один со мной — каждый месяц встречаюсь с сотрудниками: обсуждаем годовые цели и путь к ним.
Есть еще «Флеймтайм» — раз в месяц любой может поделиться тем, что его особенно выбило из колеи. Это помогает выговориться и не держать напряжение внутри. Команда слушает и поддерживает.
Что важно в распределенной команде
Для меня как руководителя главное — правильный найм. Когда команда работает удаленно, ты не видишь человека каждый день, поэтому невозможно быть в курсе всего.
Важно, чтобы у человека был внутренний драйв, самостоятельность и вовлеченность. Такой сотрудник сам разбирается, держит фокус и включается в задачи.
Когда такие люди собираются в одной команде — неважно, где они территориально. Все и так работает.
Уходящий год для команд моих проектов был насыщенным: ребята усиленно внедряли позитивные изменения во все сферы нашей работы. Как я уже рассказывал, основным изменением в работе команды стало поэтапное внедрение принципов “Клиентократии”. Это оказало большое влияние и на подход к работе с продуктом.
Продукт, согласно “Клиентократии”, должен оправдывать обещания, данные клиенту в рекламе. Чтобы это происходило не раз от раза, а постоянно, проводятся системные изменения в работе всех подразделений. Итогом стали:
📌Усиление и укрепление аналитики, внедрение сквозной аналитики, которая позволит измерить и сделать прозрачным каждый шаг в рекламе и продвижении. 📌Создание новых метрик, каждая из которых привязана к обещанию. То есть, выполнение обещаний можно будет измерить. 📌Создание новых стандартов клиентского опыта (как быстро команда продукта отвечает клиенту, сколько касаний он делает для получения нужной услуги и т.д.) 📌Углубили аналитику поведения пользователей: это позволяет быстрее реагировать на обратную связь и оптимизировать продукт. 📌Цифровые платформы проектов (сайты, мобильные приложения) изменились к лучшему: стали легче, понятнее, стали выглядеть актуально и стильно.
Все эти изменения станут базой для продуктового рывка в 2026 году.
Vibe coding это кайф. Накидал промпт, получил код. Пачками выпускаем прототипы. Топ-менеджмент в компаниях в шоке от того что умеет Bolt, Lovable и т.д.
Но есть проблема это работает пока проект простой. Как только начинаешь делать что-то серьёзнее, допустим SaaS, начинается боль: в одном месте разрабатываешь, в другом ломается, дебажить становится всё сложнее, а контекстное окно заканчивается и почему-то LLM начинает менять стек на ходу и придумывать новые правила.
Конечно в Cursor или Windsurf можно добавлять правила, но они не всегда работают, можно писать к каждому компоненту комменты, но всё равно по мере роста проекта управлять этим всё сложнее.
Ну а как решать то? Поделюсь своим опытом.
Я и в вайбкодинге придерживаюсь продуктового подхода – это когда на каждом этапе жизненного цикла разработки продукта есть ответственный: Требования пишет продакт, схемы и контракты API описывает аналитик, декомпозирует, дальше разработчик получает техническое описание и начинает работать. Тогда каждый цикл контролируемый и на выходе получаем ожидаемый результат.
В vibe coding такой подход начали называть Spec Driven Development – ну окей, давайте так назовём.
Есть несколько инструментов, которые заменяют мне классический подход
🔹 GitHub Spec Kit по сути копайлот-аналитик. Описываешь что хочешь, он генерит спеку, план, задачи. Агент в IDE понимает что за чем следует. Работает как полноценный воркфлоу: specify – plan – tasks – implement.
🔹 OpenSpec лучше работает, когда уже есть код и надо развивать. Чётко разделяет что уже написано и что меняем. Для существующих проектов удобнее.
У меня качество кода и качество решений выросло в разы. Меньше переделок, меньше "почему оно сломалось". Если пользуетесь чем-то похожим напишите, интересно сравнить.
Как повысить надежность SaaS и сократить расходы на IT-инфраструктуру?
Давайте начнем с хорошего. Представим, что ваш бизнес — это сервис аналитики и автоматизации продаж на маркетплейсах. Поздравляю! Это значит, у вас есть стабильный поток клиентов, а спрос на услуги кратно увеличивается на каждые праздники. Вы подошли к делу серьезно: развернули виртуальные машины, кластеры Kubernetes, PostgreSQL, Redis и ClickHouse на десятки терабайт, S3, 1С — SaaS в лучшем виде.
И вдруг инфраструктура упирается в потолок по хранению, вычислениям и сети: замедляются обновления витрин, возникают таймауты API и срываются ETL-окна. Все это напрямую отражается на доступности аналитики. Вы решаете сменить провайдера IT-инфраструктуры, но тут выясняется, что миграция SaaS — настоящий рокет сайенс, особенно если старый провайдер не хочет с вами расставаться и не дает прямого доступа, скажем, к конфигурациям СУБД. Из-за сложности переезда многие компании мирятся с имеющимися ограничениями, жертвуя производительностью своих сервисов.
На такой случай есть кейс с компанией «Маяк»: бесшовный перенос инфраструктуры, оптимизация хранения данных, делегирование поддержки 1С и бонусом — сокращение расходов на 20%. О решении проблем с производительностью тоже не забыли, так что у «Маяка» теперь 1,5 млн IOPS на дисковой подсистеме серверов PostgreSQL. Кстати, сама миграция для компании была бесплатной.
А детали кейса, включая решение неожиданных проблем, можно узнать в Академии Selectel.
Появился новый термин: A2UI (Agent to UI). И хайпа вокруг него много. Особенно с появлением инструмента от Google – Stitch
Одни считают, что дизайнеры больше не нужны. Другие, что продакты не нужны. Живём во времена, когда “всех уже заменили”.
Ну ок. Давайте разбираться: собрал инструменты, которые реально генерируют интерфейсы в приемлемом качестве.
Для мобильных и веб-интерфейсов:
🔹 Google Stitch — хорошо генерирует мобильные интерфейсы. Можно за секунды собрать кликабельный прототип. Результаты ок, но продуманного UX там не будет. Для быстрых концептов must have.
🔹 BananiAI – на мой взгляд самый недооценённый продукт. Генерирует и мобилку, и веб на хорошем уровне. Сам описывает юз-кейсы. Лично пользуюсь, когда надо быстро накидать концепт для защиты бюджета или сходить на UX-исследования.
Для лендингов:
В Stitch и Banani лендинги генерируются плохо. Но есть два годных инструмента:
🔹 Magic Patterns – AI-инструмент для продуктовых команд. Хорошо делает лендинги, можно подключить свою дизайн-систему.
🔹 Relume – генерирует сайтмапы и вайрфреймы за минуты. 1000+ готовых компонентов, экспорт в Figma и Webflow, куда хотите.
Оба платные, триал есть, но он так себе. Если ваша задача клепать лендинги, смотрите в их сторону.
И так, можно ли заменить дизайнеров? Тех, кто не хочет думать — наверно да. Во всех остальных случаях дизайнеры нужны.
Кстати ценность дизайнера в продукте, не в рисовании картинок….
Telegram канал: "AI-заметки продакта" рассказываю про лайфхаки, полезные инструменты, а еще каждую неделю выходит дайджест с самыми важными новостями в мире AI без инфошума, только все самое важное.
Появился новый термин: A2UI (Agent to UI). И хайпа вокруг него много. Особенно с появлением инструмента от Google – Stitch
Одни считают, что дизайнеры больше не нужны. Другие, что продакты не нужны. Живём во времена, когда “всех уже заменили”.
Ну ок. Давайте разбираться: собрал инструменты, которые реально генерируют интерфейсы в приемлемом качестве.
Для мобильных и веб-интерфейсов:
🔹 Google Stitch — хорошо генерирует мобильные интерфейсы. Можно за секунды собрать кликабельный прототип. Результаты ок, но продуманного UX там не будет. Для быстрых концептов must have.
🔹 BananiAI – на мой взгляд самый недооценённый продукт. Генерирует и мобилку, и веб на хорошем уровне. Сам описывает юз-кейсы. Лично пользуюсь, когда надо быстро накидать концепт для защиты бюджета или сходить на UX-исследования.
Для лендингов:
В Stitch и Banani лендинги генерируются плохо. Но есть два годных инструмента:
🔹 Magic Patterns – AI-инструмент для продуктовых команд. Хорошо делает лендинги, можно подключить свою дизайн-систему.
🔹 Relume – генерирует сайтмапы и вайрфреймы за минуты. 1000+ готовых компонентов, экспорт в Figma и Webflow, куда хотите.
Оба платные, триал есть, но он так себе. Если ваша задача клепать лендинги, смотрите в их сторону.
И так, можно ли заменить дизайнеров? Тех, кто не хочет думать — наверно да. Во всех остальных случаях дизайнеры нужны.
Кстати ценность дизайнера в продукте, не в рисовании картинок….
Привет! Это Владимир Князев, Agile-коуч трайба HR Tech в ОТП, и сегодня я расскажу о том, как мы организовали самое большое демо внутри компании и собрали на него 500 человек — максимум, возможный в Zoom.
Это было демо по продукту OTP Space — единому пространству HR-сервиса, в котором каждый сотрудник может оформить отпуск, поставить цели и посмотреть структуру компании. Поэтому нам важно было рассказать о нём на всю компанию. В этом посте я поделюсь, с помощью каких инструментов мы привлекли 500 человек и как удержали внимание. В прошлой статье я рассказал о приоритизации ICE и как её применять.
Не рассылкой единой
Нашей целью было привлечь как можно больше участников. Поэтому мы обратились к коллегам из внутренней коммуникации и предложили сделать большую рассылку. Договориться удалось не сразу: нужно было доказать, что это будет полезная рассылка, а не очередное приглашение на внутреннюю встречу. Нам помогло то, что до нас в ОТП уже запускали похожие кампании — например, с приглашением на митап по искусственному интеллекту. Мы использовали это как прецедент: «Раз они смогли — почему не сможем мы?».
Мы сделали рассылку на несколько подразделений, и она помогла собрать 300 участников. Тогда кто-то из команды предложил задействовать другой инструмент — наш чат-бот. Мы отправили через него приглашение с датой и временем проведения демо. Чат-бот помог привлечь ещё 200 слушателей — и мы достигли максимума, возможного в Zoom.
Нам удалось собрать столько участников с помощью разных методов коммуникации. Поэтому наш основной совет при организации больших демо — не ограничиваться стандартной рассылкой, а использовать нетипичные методы, идеи, которые могут появиться внутри команды.
Как удержали интерес сотрудников
Демо на сотни человек ≠ просто рассказ. Здесь нужна полноценная фасилитация, с которой самому спикеру не справиться.
Нашу встречу мы организовали так: я выполнял роль модератора, а продакт рассказывал о новых релизах. Пока он вёл презентацию, я удерживал внимание участников и управлял динамикой встречи: следил за таймингом и тишиной, отключал микрофоны, если нужно, читал вопросы в чате.
Самое сложное на таких встречах — не выйти за тайминг. У нас был всего час на демо продукта и ответы на вопросы. Поэтому мы сразу предупредили слушателей: ответим на вопросы в конце встречи в последние 15 минут. Перед тем, как передать вопросы спикеру, я структурировал их, объединял похожие, исключал неконструктивные. На короткие вопросы отвечали в чате, остальные озвучивали по порядку.
Что с обратной связью
ОТП Space — продукт масштабный, вопросов было много. После демо мы выгрузили весь чат, отсортировали вопросы, на которые не успели ответить, и постарались дать индивидуальный ответ каждому участнику. Это заняло время, но оно того стоило — обратная связь от сотрудников стала основой для следующих итераций в развитии продукта.
Кстати, многие комментарии были не в формате «вопрос», а в формате «здесь неудобно», «вот это переделайте» или «как классно сделали, давайте масштабируем этот функционал на другие подразделения». Мы посмотрели на живые боли наших пользователей, это очень ценно.
Советы для демо без лимитов
Вот что нужно учесть при подготовке демо на большую аудиторию:
- заранее продумываем инструменты для привлечения участников;
- приглашаем фасилитатора для модерации встречи;
- очерчиваем структуру демо в начале встречи: поясняем, о чём расскажем, на какие вопросы аудитории ответим сразу, а на какие — после демо;
- планируем демо как диалог с пользователями, чтобы собрать развёрнутую обратную связь у широкого круга сотрудников;
закладываем ресурс на обработку обратной связи.
Для следующего подобного демо мы ищем платформу с более высоким лимитом участников или вообще без него. Более гибкие настройки микрофонов минусом тоже не будут. В комментариях делитесь советами по организации демо продуктов.
Читайте, чем живёт IT в ОТП — в ТГ канале. А ещё я веду личный канал про Agile и изменения.
Как мы встречаем Новый год в SSP SOFT — и зачем вообще об этом писать на Хабре
В наших постах на Хабре мы часто пишем об открытых у нас вакансиях и упоминаем, что в SSP SOFT важны атмосфера в команде и баланс между работой и личной жизнью. Обычно такие формулировки воспринимаются как стандартный HR-шаблон — и мы понимаем скепсис читателей.
Поэтому иногда хочется рассазать, как это выглядит на практике.
В этом году новогоднюю вечеринку мы провели заранее — примерно за две недели до праздников. Формат получился нетипичный: фуршет, мастер-классы и… пижамная вечеринка. Без официоза, без пафоса, без «обязательного корпоратива по расписанию».
В SSP SOFT действительно бывают периоды высокой нагрузки — как и в любой ИТ-компании, работающей с заказной разработкой и сложными проектами. Именно поэтому мы сознательно относимся к нерабочим форматам общения как к части корпоративной культуры, а не как к разовой активности «для галочки».
В этот раз мы собрались в тёплом кругу, пообщались вне рабочих ролей и вместе поучаствовали в кулинарном мастер-классе с шеф-поварами — готовили обед для себя и коллег. Это был не тимбилдинг «по методичке», а живой вечер с разговорами, смехом и ощущением, что работа — не единственное, что нас объединяет.
Мы уже писали раньше и о летнем рок-концерте, и о других форматах встреч. Всё это — продолжение одного и того же подхода: работа важна, но жизнь не заканчивается задачами и дедлайнами.
Если вам близка идея работать в команде, где ценят профессионализм, но при этом помнят про человеческую сторону, — следите за нашими вакансиями на HeadHunter (загляните туда сейчас - есть открытые вакансии). Мы регулярно обновляем список открытых позиций и стараемся честно описывать, кого и зачем ищем. А откликаться можно напрямую в ЛС нашему HR Lead Алине. Не забудьте добавить сопроводительное письмо с ключевой фразой «Нашел(ла) вас на Хабре».
Иногда лучший способ рассказать о культуре компании — просто показать её без лишних слов. Желаем всем успешной карьеры в Новом году 🚀🎄)
Раз уж вчера начали говорить про вайбкодинг(да как говорить, 40 комментов уже), то давайте своими пожеланиями для создания своего первого продукта поделюсь
Пункты ниже в основном подходят для первого продукта, который хочется создать и монетизировать
Создание продукта — это только начало
После релиза MVP начинается стадия шейпинга: сбор фидбека, итерации, баги, улучшение онбординга, поддержка, оплаты. Часто продукт после запуска и продукт через 3 месяца — это разные продукты.
Если думаешь "запущу и пойду делать следующий" — скорее всего, первый не взлетит без постоянных финансовых и временных затрат на его продвижение.
Статистически, первые значимые деньги начнут приходить через 4-5 месяцев
Много микро-проектов = масштабирование ошибок
Есть такой популярный совет — "Делай 1 проект в месяц, что-то выстрелит".
Но проблема в том, что если ты не понимаешь, почему первый не взлетел — второй провалится по той же причине. И третий. И десятый.
Этот совет еще может будет хорош для serial founders, которые уже прошли не один цикл и понимают паттерны. Для первого-второго проекта лучше сфокусироваться и вытащить максимум learnings из одного
Хорошая цель для первого продукта — не юникорн, а 300 платящих клиентов
Найди 300 человек на планете, которые платят $10/мес = $3k MRR. Это уже актив, который позволяет жить практически где угодно. Для подобного продукта сейчас не обязательно искать инвесторов, собирать огромную команду или считать TAM SAM SOM, все можно сделать одному при достаточном усердии
Пивоты — это норма, а не провал
YouTube начинался как дейтинг-сервис. Instagram — как приложение с чек инами и фильтрами. WhatsApp — как статусы для контактов. Первая идея почти никогда не та, что взлетит. Главное — быть в рынке и слушать, что говорят пользователи.
Продвижение также важно, как и продукт
Отличный продукт без дистрибуции умрёт. Средний продукт с хорошим продвижением будет вполне комфортно себя чувствовать. И на продвижение точно придётся тратить не меньше времени, чем на создание и улучшение, поэтому ⤵️
Органика требует времени — поэтому о продвижении надо начинать думать тогда же, когда и о создании продукта
SEO, контент, комьюнити — это всё работает, но с задержкой в 3-6 месяцев. Если начнёшь думать о продвижении после запуска — потеряешь полгода. Пиши, публикуй, собирай аудиторию параллельно с разработкой. Очень хорошо заходит формат Building in Public, где вы делитесь успехами и сложностями на пути к первым клиентам.
И да, похвалите Gemini за инфографику. Он немного накосячил с визуальной последовательностью, но все равно красиво сделал
Раз уж вчера начали говорить про вайбкодинг(да как говорить, 40 комментов уже), то давайте своими пожеланиями для создания своего первого продукта поделюсь
Пункты ниже в основном подходят для первого продукта, который хочется создать и монетизировать
Первый продукт лучше строить на пересечении: "Интересно / Могу / Кто-то за это заплатит"
И именно в таком порядке.
Если вам не интересно, то все остальные пункты уже не так важны.
По поводу Могу / Не могу Сейчас "не смочь" — уже не рабочая отмазка. Разработка была единственной ощутимой проблемой, из-за которой людям приходилось говорить "О нет, это не моё, я гуманитарий".
По поводу "Заплатит / Не заплатит" А если никто за это не заплатит — ну и ладно, хотя бы разберётесь как создать хоть что-то рабочее в первый раз. С текущими технологиями цена ошибки — несколько потраченных вечеров, а не месяцы и тысячи долларов как раньше.
Легче всего для первого продукта решать проблему, которая есть и у тебя
Поиск абстрактных "проблем рынка" через Reddit или Keywords мало чего даст тому, кто не понимает основы Customer Development'a. Если это не твоя проблема — тебе сложно будет понять боль клиентов. Когда делаешь для себя — ты уже понимаешь задачу, лучше понимаешь, где искать таких же людей, и можешь отличить важное от лишнего ☕️
То, что получилось у конкурентов, не обязательно получится у тебя
"У них работает, значит и у меня сработает" — возможно, но нет. Успех часто связан с набором случайностей. Попали в хайп, у CEO огромный социальный нетворк или связи, залетел виральный пост, влили много на рекламу.
Конечно, лучше смотреть на продукт конкурента, чем не смотреть вообще. Но к наличию каждой функции в продукте конкурента лучше относиться скептически, потому что ⤵️
80% фичей конкурентов, скорее всего, не работают
Многие смотрят на конкурентов и думают: "Надо сделать всё это, чтобы быть конкурентным". А по факту — большая часть их фичей не используется или не влияет на метрики. Они сами не знают, что работает. Или знают, но не скажут. Не копируй весь набор. Найди 1-2 вещи, которые реально решают проблему, и сделай их лучше.
Допустим, мне часто нужно вытаскивать аудиодорожки из длинных видео. Видеоряд грузить в интернет, чтобы вытащить аудиодорожку — слишком долго. Мне предлагают скачать всякие сложные сервисы, где эта функция еще и будет под платной подпиской. Следовательно, за пару вечеров я бы мог создать себе сервис с одной функцией — извлечь аудио. И для меня это уже будет ценно. А если будет ценно для меня, то и другие такие найдутся
Отсутствие конкурентов — red flag
Кажется логичным: у моей идеи нет конкурентов = голубой океан = ваукакклас. На практике — если нет конкурентов = либо рынка нет, либо ищешь не там, либо рынок только зарождается и придётся потратить миллионы на создание спроса.
Конкуренты — это всегда хорошо. Они доказали, что рынок существует. Твоя задача — сделать лучше для конкретной ниши.
Prompt engineering людей, как работа руководителя или почему у руководителей отлично получается работать с ИИ 😎
Что есть работа руководителя на практике? — ты постоянно:
Качаешь контекст и понимание того, что делает компания, кто пользователи и чего они хотят, и пр.
Адаптируешь свои промпты делегирование под конкретных людей
Учитываешь опыт ребят в доменной области
Настраиваешь контроль так, чтобы результаты не сбоили
При этом чем дольше сотрудник работает в твоей команде, тем больше он понимает с полуслова и улавливает бизнес‑потребности.
И это ровно то, чем все регулярно занимаются с ИИ‑агентами!
Например, когда разрабатываешь фичу через ИИ‑агента, то работаешь вокруг двух проблем:
Создать именно то, что нужно
Вписать фичу в проект
Но ведь тимлиды и продакты именно это и делают! Только они формулируют словами через рот и Jira то, что хотят получить. А дальше разработчики уже создают это.
🌋 При этом чем выше твоя роль, тем более автономные и смышлёные ребята в твоей команде. Которые за это получают большие деньги.
В этой подборке собрали три курса, которые будут полезны специалистам, стремящимся развиваться как руководители в своих направлениях.
«Lead DevOps» — 5 месяцев Научим быть «играющим тренером» — специалистом, который одинаково уверенно разбирается и в технологиях, и в менеджменте. После курса почувствуете, что к большой ответственности прилагается большая уверенность в своих силах.
«QA Lead» — 5 месяцев Курс поможет вырасти из QA-инженера в руководителя QA-команды. Разберём, как формировать сильную команду, управлять стратегией автоматизации и выстраивать эффективные QA/QC-процессы.
«Технический директор — СТО» — 4 месяца Программа для технических специалистов, которые хотят развиваться как руководители. Наставники и менторы — CTO из Яндекса и других крупных компаний.
Заблокировали карту или счет по 161-ФЗ? Инструкция по снятию блокировки.
Продолжаем тему ограничения банковских операций.
В этом посте я рассказала об основаниях таких ограничений и блокировки.
Теперь разберем первый и один из самых частых сценариев: блокировка из-за подозрений банка в мошенничестве.
Как банк определяет «подозрительную» операцию?
Банк обязан проверять все переводы клиентов на специальные признаки, утвержденные Банком России.
Если операция попадает под хотя бы один из них, банк обязан на 2 дня приостановить перевод денег или отказать клиенту в совершении операции.
Вот ключевые признаки:
⦁ Реквизиты получателя есть в «чёрном списке» ЦБ (базе данных о мошеннических переводах). ⦁ Нетипичная для вас операция: необычно крупная сумма, странное время или место совершения. ⦁ Использование устройства (телефона, компьютера), с которого ранее пытались совершить мошеннический перевод. ⦁ Получатель фигурирует в внутренней базе подозрительных контрагентов вашего банка. ⦁ В отношении получателя возбуждено уголовное дело за мошенничество. ⦁ Поступила информация от сторонних сервисов (например, о всплеске подозрительных звонков или СМС на ваш номер).
Как подтвердить операцию?
У вас есть два варианта:
Дать согласие на приостановленный перевод (в течение следующего дня).
Совершить ту же операцию повторно.
Если вы это сделаете, банк обязан выполнить платёж.
Исключение: если получатель числится в «чёрном списке» ЦБ.
В этом случае банк может приостановить перевод на 2 дня (период охлаждения), либо приостановить использование банковской карты, онлайн-банкинга.
Это происходит, если ваши собственные реквизиты или данные попали в базу ЦБ.
В этом случае необходимо:
Подать заявление об исключении из базы данных ЦБ.
Это можно сделать двумя способами:
⦁ Через любой ваш банк. Банк обязан перенаправить ваше заявление в Банк России не позднее следующего рабочего дня. ⦁ Напрямую в Банк России через интернет-приемную на его сайте, выбрав тему «Информационная безопасность».
Ждать ответа. Банк России обязан рассмотреть ваше заявление и дать ответ в течение 15 рабочих дней с момента получения.
Важно! Если ЦБ откажет в исключении, в ответе будут указаны банки, направившие информацию в ЦБ.
Вам нужно обратиться к ним, чтобы выяснить конкретные причины и способы устранения проблемы.
3 вида метрик, на которые я обращаю внимание команд в конце года
Декабрь - время для подведения итогов. У каждого проекта итоги свои: это зависит от его “возраста”, этапа развития, команды. Но в целом, по моему опыту, важно, подводя итоги, проанализировать три типа метрик.
Метрики “Про деньги” Если проект уже генерирует прибыль, обращаем внимание на показатель чистой прибыли. Если проект - стартап на самой ранней стадии, стоит посмотреть на соотношение вложений и расходов. Как ни крути, но любой бизнес создается для получения дохода, поэтому метрики “про деньги” я ставлю на первое место. У социальных проектов ключевой метрикой может быть охват аудитории. Метрики “Про качество” Здесь мы фокусируем внимание на том, КАК мы достигаем прибыли. В ДНК наших проектов всегда вшит принцип получения прибыли через ценность для клиента. Насколько конечный клиент доволен услугой? Здесь могут применяться разные метрики - конверсии (от знакомства с сервисом/приложением до покупки), NPS (показатель лояльности клиентов), метрики повторных обращений и retention (удержание клиентов). Нужно найти ключевую для каждого проекта. Метрики “про команду” Это внутренние исследования, направленные на понимание того, какой микроклимат царит в команде, насколько сотрудники удовлетворены своей работой, иными словами - поле для деятельности вашего HR. Можно считать процент “текучки”, можно опрашивать людей относительно их настроя и планов. Важно поддерживать позитив в коллективе в целом: люди могут работать много, но когда они знают, что их усилия будут вознаграждены - это придаёт им сил и защищает от выгорания.
Эти три типа метрик - база для анализа и итогов в любом бизнесе.
За последние 2 недели сразу несколько знакомых написали мне, что работа проектным менеджером или продуктовым менеджером, стало найти тяжелее чем обычно. Обычно поиск для грейда выше джуна поиск занимал 1-3 месяца. Сейчас некоторые ищут уже по пол года, но до сих пор продолжают перебирать, а не сразу соглашаться.
На уровне повыше стало тоже хуже, но предложения всё равно периодически прилетают по разным контактам, даже если не в активном поиске.
А за последние 2 года я прошел десяток интервью в топовые компании: Яндекс, Т-банк, Авито, Сбертехнологии и несколько менее именитых. Почти во всех этих компаниях один из этапов это хардскилл грейдирование на продакт-менеджера. Когда тебе нужно порешать определенные продуктовые кейсы.
Все основания строго регламентированы, и Банк России их детально систематизировал в своих методических рекомендациях.
Давайте разберемся, чтобы вы могли быстро диагностировать свою ситуацию.
Причины ограничения проведения операций можно разделить на три крупных блока.
1. Защита от мошенничества (№ 161-ФЗ).
Банк обязан приостановить операцию, если выявлены конкретные признаки, указывающие на возможное отсутствие вашего добровольного согласия на банковскую операцию.
К ним относятся:
• Совершение нетипичной для вас операции (нехарактерная сумма, контрагент, время).
• Наличие реквизитов получателя в базе данных Банка России о переводе денег по мошенническим схемам.
• Использование устройства (телефона, компьютера), которое ранее применялось мошенниками.
• Получение банком информации от правоохранительных органов о возбуждении уголовного дела в отношении получателя средств.
• Данные от сторонних организаций (например, других банков) о возможном обмане.
2. Исполнение требований государственных органов.
В этом случае банк является исполнителем решений уполномоченных органов.
Основания:
• Решение налогового органа о приостановлении операций по счетам (Налоговый кодекс РФ, ст. 76).
Причины: недоимка, непредставление декларации в срок, неуплата штрафа.
• Решение таможенного органа о приостановлении операций (Кодекс об административных правонарушениях РФ, Таможенный кодекс ЕАЭС).
• Решение суда или судебного пристава-исполнителя о наложении ареста на денежные средства (№ 229-ФЗ «Об исполнительном производстве»).
3. Внутренний контроль в рамках ПОД/ФТ (№ 115-ФЗ).
Это самый сложный блок, связанный с противодействием легализации доходов и финансированию терроризма.
ОД - это отмывание денег, полученных преступным путём.
ФТ - это финансирование терроризма.
ПОД/ФТ - это противодействие отмыванию денег и финансированию терроризма.
Банк обязан приостанавливать операции при:
• Возникновении обоснованных подозрений, что операция связана с ОД/ФТ.
• Отнесении клиента к высокой степени риска одновременно и банком, и Банком России.
• Включении клиента или его бенефициаров в перечень лиц, причастных к экстремизму или терроризму.
• Наличии решения Росфинмониторинга или суда о замораживании (блокировании) средств.
При получении уведомления об ограничении немедленно запросите у банка письменное разъяснение с указанием точного правового основания (ссылка на закон и реквизиты документа-основания).
От этого будет зависеть вся дальнейшая стратегия: подтверждение легитимности операции, погашение долга перед ФНС или подготовка документного досье для комиссии банка по 115-ФЗ.
В следующих публикациях мы подробно разберем процедуры обжалования для каждого типа ограничений и меры профилактики.
