Менеджмент

Я уже рассказывал здесь, как мы объединяли 14 сайтов в один, связывали Flask и Bitrix в одну систему, защищали контур рассылки и как после 5 лет работы попрощались с большим проектом. Все эти истории были о том, что происходило после того, как проект уже оказался у нас.

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

Мы это проходили на собственных конкурсах. В одном показали frontend-приложение на WebGL, которое можно было запустить и проверить. В другом подтвердили квалификацию 27 исполненными контрактами примерно на 168 млн рублей. Казалось бы, обе части заявки должны были играть в нашу пользу. Вместо этого в обоих случаях получили 0 баллов именно там, где рассчитывали на сильную позицию.

Меня зовут Алексей Постригайло, я управляющий партнер IT-компании Энсайн. В государственных и коммерческих тендерах мы участвуем больше 15 лет. Ниже — два наших проигрыша, которые хорошо показали разницу между тем, что компания реально умеет и делает, и тем, что она способна доказать конкретной конкурсной заявкой.

27 контрактов на 168 млн рублей: почему мы считали этот опыт подходящим

В этом конкурсе цена имела вес 30%, а квалификация участника — 70%. Для оценки квалификации заказчик требовал подтвердить опыт работ с информационными или автоматизированными информационными системами, используемыми для предоставления государственных услуг в электронной форме. 

Тема искусственного интеллекта сегодня звучит в двух крайностях: либо «скоро он заменит всех», либо обсуждаются сложные мультиагентные системы. Меня зовут Евгений, я руководитель отдела проектов ЮMoney. Недавно я выступал с этой темой на нашем митапе, где рассказал о третьем пути, который мне показался интересным: что проектный менеджер может делегировать ИИ прямо сейчас? Просто взять конкретную операцию и проверить, справится ли машина быстрее.

Я протестировал несколько сценариев. Часть задач действительно ускорилась, а заодно стало понятнее, что автоматизировать дальше. Если вы тоже управляете проектами и думаете, с чего начать, возможно, мой опыт поможет не экспериментировать вслепую. Расскажу, что удалось ускорить и где пока ничего не вышло.

Привет! Меня зовут Игорь, я отвечаю за развитие Naumen Project Ruler. Много общаюсь с заказчиками, изучаю их задачи и практики проектного управления и вместе с командой определяю, куда продукт будет двигаться дальше.

Когда при реализации портфеля проектов выявляется дефицит ресурса исполнителей (на языке специалистов, «переподписка»), чаще всего говорят о некачественном планировании. По моему убеждению, в большинстве случаев дело не в этом. Руководители проектов прекрасно ориентируются в оценке того, сколько ресурсов потребуется для достижение целей. Так что, портфель с заведомым дефицитом согласовывается «с открытыми глазами». Причины — в человеческом и организационных факторах. Объясню подробнее, почему так происходит.

В любой компании нужно решать, над чем и как работать. Одна из широко распространённых методологий для принятия таких решений в IT — lean startup, то есть небольшие итерации с тестированием гипотез. Проблема в том, что методология не работает «в лоб», если вы не стартап.

Привет! Это Арсений Проценко, я лидирую AI‑команду в продажах в Точка Банк. В статье поделюсь опытом, который пришёл нашей команде за последние годы. Обсудим, что не так с lean в больших компаниях и как можно изменить метод под ваши реалии.

Я, Максим Поклонский, занимаюсь разработкой стратегий и проведением стратегических сессий для бизнеса. Более 18 лет помогаю собственникам и руководителям находить точки роста, принимать стратегические решения и превращать их в конкретный план действий. За это время реализовал более 280 стратегических проектов в компаниях из разных отраслей.

Один из вопросов, который регулярно возникает в работе с собственниками и управленческими командами: почему компания много делает в маркетинге, но это не всегда превращается в понятный рост бизнеса?

Реклама запущена. Социальные сети ведутся. Сайт обновляется. Компания участвует в выставках, производит контент, тестирует новые инструменты продвижения.

Активностей становится всё больше, а через несколько месяцев собственник снова задаёт вопрос: что именно из этого двигает бизнес вперёд?

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

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

Компания EvaTeam представила обновление ИТ-конвейера разработки полного цикла EvaDev до версии 2.33 «Воронеж». В новой версии EvaProject можно тиражировать уже настроенные доски между проектами, без помощи администратора импортировать задачи из CSV, подключать к задачам данные напрямую из PostgreSQL, MS SQL, MySQL и Oracle. В EvaGant улучшены быстрые трансформации задач на графике, гибкие группировки, смена видов представления. В EvaTest стало возможным группировать тест-кейсы в планах и прогонах и переносить тестовую библиотеку из Zephyr вместе со структурой и историей прогонов. В EvaWiki появились Центр шаблонов, SQL- и BPMN-плагины, а в EvaServiceDesk — новые возможности для форм, согласований и сбора обратной связи.

Разбираем главные изменения нового релиза экосистемы EvaDev 2.33 «Воронеж».

Всем привет! На связи Елизавета, я agile-коуч продуктовых стримов корпоративного бизнеса — транзакционных сервисов, продуктов для малого бизнеса, страхования. Внедряю Discovery и проверку гипотез, а ещё веду курс по CJM для топ-менеджмента и продуктовых лидеров. Отсюда и тема статьи: расскажу о том, как выстроить карту клиентского пути для ИТ-продуктов.

Свои процессы ИТ-команда знает хорошо: сколько занимает разработка, где стоит согласование, какой сервис отвечает за шаг, сколько проходит от постановки задачи до релиза. Мы считаем сроки и смотрим на продукт через метрики. Внутренние процессы не отвечают на один вопрос: что в этот момент происходит с клиентом?

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

Команды берутся за CJM, чтобы посмотреть на продукт снаружи. Внутри процесс выглядит так:

заявка → проверка → согласование → решение → уведомление клиента.

Клиент не делит банк на приложение, сайт, контактный центр и офис. Если в приложении он прочитал одно, от оператора услышал второе, а в офисе третье, он не станет разбираться, какая система дала сбой. Он скажет, что у банка проблемы. У клиента последовательность другая:

узнал о продукте → попытался разобраться → не понял условия → написал в чат → получил один ответ → пришёл в офис → узнал о дополнительных документах → ушёл → вернулся через несколько дней → снова связался с банком.

Привет! Меня зовут Кирилл Кочнев, я руковожу продуктовой аналитикой в hh.ru и веду «Статзначимый подкаст». Каждый месяц мы в компании запускаем больше сотни A/B-экспериментов, и со временем тесты начали пересекаться: разные команды одновременно меняли связанные части пользовательских сценариев, из-за чего результаты искажались. 

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

Я писала статью о том, почему УТП Twinby не работает, а сегодня хочу поделиться идеями, что можно сделать, чтобы повысить вовлечённость пользователей.

Привет! Меня зовут Маша, я Senior Product Manager и разбираю только те продукты, над которыми сама хотела бы поработать, так как ими пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей. Мои другие разборы: «Рейтинг ни на что не влияет»: Почему Яндекс.такси выбирает газлайтинг вместо честного UX и Кэшбек Шрёдингера и молчаливые проценты: Dark Patterns в банкинге.

Одна из наших крупных функциональностей ехала до пользователей 519 дней.

Мы провели ретроспективу, решили, что проблема в декомпозиции, поменяли процесс и попробовали снова.

Следующий большой кейс занял 666 дней.

То есть после осознанной попытки ускорить разработку мы получили ещё худший результат.

В статье разбираю, почему декомпозиция сначала не помогла, зачем мы постепенно переносили её с этапа разработки на аналитику и продуктовую проработку, как в эту историю вписались MVP и WIP-limit и что в итоге позволило сократить Lead Time похожих больших функциональностей до 90–120 дней.

Без универсального рецепта «сделайте так же» — это разбор конкретного финтех-кейса, включая те решения, которые у нас не сработали.

3 сентября Верховный Суд РФ утвердил Концепцию внедрения технологий искусственного интеллекта в судопроизводство.

К 2030 году более 95% судей должны постоянно использовать ИИ-сервисы в работе. Звучит как фантастика)

Что будет делать ИИ

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

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

Классификация дел. Автоматическая сортировка по категориям и сложности, распределение между судьями с учётом нагрузки и специализации.

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

И самое интересное:

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

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

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

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

Компания когда-то забрала 99% рынка демпингом, а потом шесть лет подряд теряла продажи. Внедрение ИИ за год буксовало, человек, который им занимался, ушёл, кеш закончился. Меня позвали на месяц с оплатой по факту. Рассказываю, что успел: агент проверяет сборку заказов по фото, агент-менеджер закрывает 95% чатов с клиентами, отдельный агент деплоит мелкие правки прямо из рабочего чата, старую логистику на Perl заменил софт на Python, а над всем этим сидит главный агент-погонщик. И почему сотрудники ходили жаловаться на коллег, которых не существовало.

LLM может быстро подготовить postmortem, но убедительный текст ещё не гарантирует точность выводов: модель способна неверно связать события или предложить меры, которые не решают проблему. В статье на примере инцидента Cloudflare разберемся, как проверять такие разборы и превращать их в основу для полезной ретроспективы.

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

И вот ты сидишь такая «насяльника», а от тебя теперь требуется руководить. Тут довольно быстро возникает резонный вопрос: а как, собственно, правильно водить руками?

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

Привет! Меня зовут Олег Игнатов. Сейчас я руковожу продуктовой аналитикой в Garage Eight. До этого я строил продуктовую аналитику в Литрес. Параллельно преподаю продуктовую аналитику в ВШЭ, менторю аналитиков и руководителей и веду свой канал.

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

Часть 1 - ссылка

Опыт управления командами у меня больше 10 лет. Начинала с нагрузочного тестирования в аутсорсе и там исполняла роль тимлида+проджекта. И в роли продакта я работала как с совсем маленькими, так и с командами по 20 человек. В маленьких командах получается быстро договориться, а вот в командах 15+ операционка может перетаскивать на себя огромный временной ресурс и отжирать то, чем я люблю заниматься. В этой статье расскажу, как я подхожу к управлению большими командами, как мы делили обязанности с проджектом и адаптировали Scrumban под наши потребности.

Привет! Меня зовут Маша, я Senior Product Manager и разбираю только те продукты, над которыми сама хотела бы поработать, так как ими пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей. Мои разборы: «Рейтинг ни на что не влияет»: Почему Яндекс.такси выбирает газлайтинг вместо честного UX и Кэшбек Шрёдингера и молчаливые проценты: Dark Patterns в банкинге. Сегодня я поделюсь как работаю с командой и какие лайфхаки нашла для себя для ускорения Time to Market.

Разбор «Одиссеи» Нолана с точки зрения управления командой: решение, принятое из страха, риски без исследования, цена эмоций руководителя и единственный эпизод, где Одиссей поступает правильно.

Осторожно, текст содержит спойлеры