Как управлять командой без техлида

Исследования bigtech-компаний постоянно подтверждают, что команды с техническими лидерами показывают значительно лучшие результаты:
- Существенно меньше багов в продакшене
- Быстрее принимают технические решения
- Реже сталкиваются с архитектурными проблемами

Но что делать, если техлида в команде нет, а найти его прямо сейчас невозможно?

Типичный сценарий
PM без технического бэкграунда получает команду из 5+ разработчиков. Что происходит дальше:
- Разработчики часами спорят о простых задачах
- Обсуждают масштабирование для проекта с 10 пользователями
- Придумывают корнер-кейсы, которые никогда не случатся
- Задачи обсуждаются, но не делаются

Главная ошибка, которую совершает большинство PM
Попытка изобразить из себя техлида. Лезть в технические обсуждения, пытаться принимать архитектурные решения :)

В результате разработчики бесятся от некомпетентности, падает доверие, управлять процессом становится ещё сложнее.

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

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

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

4. Декомпозируйте. Любая задача должна укладываться в 1-2 дня. Маленькие задачи сложнее переусложнить и проще контролировать. Аналитик может ставить функциональные куски в виде пользовательских историй, а до задач в 1-2 дня декомпозировать может уже сам разработчик.

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

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

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

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

В LinkedIn после публикации кейса про БЗ с ЛЛМкой спрашивали, какие метрики мы используем для того, чтобы убедиться, что внедряемое ИИ-решение соответствует ожидаемым результатам, решил написать об этом и поделиться метриками, которые использовали на старте и сейчас.

Я уже рассказывал, что у моей команды основные силы сейчас сосредоточены на платформе, которая закрыла бы все внутренние задачи сотрудников ВВ, в том числе управление знаниями. Я вообще убеждён, что все, кто работает внутри компаний и как-то связан с knowledge management’ом, будут прикручивать к своим базам RAG-системы, чтобы получить возможность общаться с ними в виде чата. Мы такой проект уже реализовали — сейчас в него постепенно перетекает основная группа пользователей. Чуть позже напишу статью про экономический эффект от внедрения такого инструмента, но спойлер: на масштабе экономит он много.

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

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

Ну и как всегда это бывает, после того как к нам пришло 20+ команд и загрузили свои знания, обрабатывать все вопросы одинаково хорошо через 1 модель не получилось, некоторые команды из-за размеров и особенностей чуть ли не в отдельный продукт сейчас выделяем, об эволюции в области управления знаний у нас тоже расскажу позже, с этим сильно помог Ваня Замесин, когда у нас воркшоп в ВВ проводил :)

Нанимаю в команду

Сейчас 2 открытые позиции, ML-инженер и Техлид.

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

У нас классная кросс-функциональная команда, с бизнес и системными аналитиками, backend, frontend и ML разработчиками, своим дизайном.

Очень важно иметь опыт реализованных коммерческих проектов с использованием RAG-систем.

Подробности смотрите тут:
1. https://perm.hh.ru/vacancy/127597188?hhtmFrom=employer_vacancies
2. https://perm.hh.ru/vacancy/127595268?hhtmFrom=employer_vacancies

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

Читайте, что получилось: https://t.me/news_vkusvill/1156