Для ответа на пост Андрея мне придется смешать проектную и продуктовую школу мысли.

🎯 Дешифруем проблемы продуктово: 1. Продукт находится в минусе - его операционные затраты не покрываются прибылью; 2. Фаундер хочет денег, но не понимает как достичь их через продукт; 3. Аналитик хочет понимать, зачем он описывает фичи, потому что видит их несвязность с ценностью продукта; 4. Дизайнеру не нравится отсутствие вызова в рамках создания продукта: менторство он видит как способ этот вызов получить; 5. Разработчики непродуктивно используются и видят повышение объёма работы как крит;

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

По условиям задачи мы не знаем, как этот продукт продается/маркетуется и так далее. Мы также не знаем, как обстоят дела с инвестициями - возможно, у компании осталось больше пяти месяцев. Но мы это не будем учитывать в решении (хотя в реальности надо).

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

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

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

Проблема 5, как ни странно, может быть фантомной. Если разработчики не стоят бизнесу баснословных денег, при этом успевают делать свою работу в срок и с нужным качеством - можно не делать ничего. Скорее всего, с развитием бизнеса поток задач естественным образом вырастет, и можно будет предлагать решать больше задач за больше денег, но это будет в будущем. Надо помнить, что даже поездки на конференции - это польза для HR-бренда компании, что может положительно сказаться при её росте. Вместе с тем, если разработчики стоят дорого, а выхлоп ниже ожидаемого - можно дать им поджопник, уволить недовольных и нанять новых. Как славно, что условия задачи дают нам эту дихотомию 🙃