Agaltsov Anton | TeamLead-блог

🚀 MVP — это не сырой продукт, а самый дешёвый способ проверить гипотезу Классическое определение Эрика Риса звучит несимметрично: минимум усилий — максимум проверенных знаний о клиентах. Качество MVP измеряется не полнотой функциональности, а отношением полученного знания к затраченным усилиям. Главная ошибка — считать MVP «маленькой версией большого продукта». Это самый дешёвый эксперимент, способный опровергнуть главную гипотезу о ценности. Если гипотезу можно проверить без кода — кода в MVP быть не должно: Dropbox начал с видеоролика, Zappos — с ручной покупки обуви в соседнем магазине. Цель MVP — обучение, а не выручка. До запуска фиксируются гипотеза, метрика решения и порог: после эксперимента команда решает — развивать, развернуться или закрыть направление. Без метрик минимальная версия превращается в релиз без плана. От прототипа MVP отличает реальность проверки: не респондент оценивает макет, а реальный человек решает свою задачу — тратит время, а иногда и деньги. Поведение в этих режимах различается радикально. 🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/mvp/

⬆️ Повышение — следствие роста, а не его причина Промо — это формальное признание того, что сотрудник уже устойчиво работает на уровне следующего грейда. Логика «повысим — и человек дорастёт до роли» переносит риск неподтверждённого уровня на команду и на бизнес. Повышения бывают двух типов: вертикальное — следующий грейд в своём треке, и трековое — переход в управление или смежную роль. Оцениваются они по-разному: соответствие описанию грейда против готовности к новой роли. Решение опирается на четыре критерия: соответствие следующему грейду, устойчивость результатов, подтверждение от окружения и бизнес-необходимость. В зрелых компаниях решения принимает промо-комитет с калибровкой между командами. ⚠️ Главные антипаттерны — повышение за выслугу или за разовый успех. Но и задержанное признание уровня работает против компании: сильный сотрудник получает его на внешнем рынке. 🔗 Подробнее: https://agaltsovav.ru/docs/people-managment/promotion/

🔌 REST, RPC или GraphQL — как выбрать стиль API? REST описывает мир как набор ресурсов с адресами: клиент выбирает HTTP-метод, сервер возвращает представление. RPC — как набор операций: клиент вызывает процедуру с аргументами. GraphQL — как граф типизированных данных: клиент сам перечисляет нужные поля, и сервер собирает ответ в этой форме. Практический выбор сводится к характеру доминирующих операций. CRUD над сущностями — родная стихия REST, действия-команды — RPC и gRPC со стримингом, сложные выборки для разнородных клиентов — GraphQL, который убирает overfetching и лишние эндпоинты под каждый экран. 💡 Зрелые системы редко живут на одном стиле: типичная схема — REST на периметре, gRPC внутри и GraphQL в BFF для мобильных клиентов. Вопрос не «какой стиль лучше», а где какая граница и кто её потребитель. 🔗 Подробнее: https://agaltsovav.ru/docs/architecture/api-styles/