Евгений Васёв

Отличная история и вдохновляющий опыт! Желаю успехов в развитии и росте!

Александр, что значит "вин", в этом предложении?

"Но у команды, у которой есть идеология, у которой есть 'вин', всегда есть шанс." ©

Спасибо за мнение!

Концептуально согласен: пока есть возможность "немного схитрить", ей будут пользоваться — внезапное повсеместное "прозрение" маловероятно.

>> Слова не нужны <<<

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

Вы уже упомянули стандартизированные протоколы общения (API, наборы чётких характеристик и критериев) как идеальное состояние. Но ведь человеческие слова — это тоже своего рода характеристики, просто их сложнее интерпретировать. "Между тем, что я подумал, что сказал и что вы поняли — может быть три большие разницы" ©. ИИ может помочь сократить эту разницу и улучшить взаимопонимание, когда мы всё же решим встретиться.

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

Я как frontend-разработчик в прошлом, мог работать с любой стадии, хоть "с идеи", хоть "доделать чей-то todo-лист". Вопрос цены (время/усилия).

Менеджер, который ставит слабо-детализированные задачи - негативно влияет на оценку, потому что многое неизвестно: какой CJM ожидается? все ли состояния пользователя предусмотрены? есть ли API-контракт и документация? вординг подготовлен? переводы на другие языки предоставлены? все аналитические данные собираются? итоги после реализации этого функционала можно будет подвести? с бэкендом согласован такой сценарий использования приложения? это возможно в принципе реализовать?

Моя мысль, что хороший менеджер - делает максимально-возможное, чтобы сократить количество возможных вопросов (тут наверное половина успеха в технической подкованности менеджера, а вторая половина сам вклад как менеджера продукта: CJM + макеты + вординг + решение проблематики).

Что такое "требуемый уровень детализации"? Одному хочется как можно проще, другому - чем подробнее, тем лучше. Мой вопрос про опыт автора, как он выдерживал этот баланс.

Спасибо за ответ! А что насчёт деталей? Есть две крайности - первая: технарь, который не берёт в работу задачу, пока её не разжуют, вторая: менеджер поставил задачу "сделайте мне красиво!" (т.е. без минимальных деталей). Как эту проблему отбалансировать? Увольнять людей, пока не найдётся идеальный состав, который может делать свою работу, на которую их наняли?
Кажется, что должно быть понимание, что в конечном счёте все в одной лодке, но эти трения возникают очень часто.

Крутая мысль: знаем, но не делаем.
А как считаешь, кто должен заниматься администрированием, если больше некому?
Кажется, что тут нужен баланс, но как его держать?

Мы в нашей команде используем Slack. Да, мы распределённая команда, правда не проектная, а продуктовая, возможно поэтому нам не так больно, как автору. Но, концептуально и слак можно настроить должным образом, при этом не отвлекая всех и вся. И да, в слаке тоже можно работать в асинхронном режиме, не обязательно следить за лентой. Но, это уже скорее вопрос культуры, а не инструментов.
Что до задач, то задачи дерьмового качества, можно получить как по почте, так и в джире, так и в слаке. Тут опять про культуру и принцип "shit in - shit out" и возможность Исполнителя не брать непонятные задачи, до момента пока по ним не будет полной проработки.
Но, кажется, что проектная работа, это всё-таки не тоже самое, что строительство продукта, поэтому и цели, и подходы отличаются.

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

Можно торговать вниманием, зарабатывать на B2B.