Обновить

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

Изображение создано с помощью нейросети
Изображение создано с помощью нейросети

Дано: технологический стартап, создающий продукт, состоящий из нескольких систем. Для каждой системы требуются специалисты, которые имеют знания, необходимые для создания этой системы (электротехника, термодинамика, передача данных, прочность материалов и далее по списку). Глава стартапа имеет опыт в одной из отраслей, с остальными знаком в меру необходимых знаний, связанных с его отраслью.

Вопросы:

  1. Должен ли глава стартапа проталкивать те или иные решения по системам, принцип работы которых он понимает лишь поверхностно?

  2. Как сотруднику относится к тому, что его задачи не могут быть выполнены до дедлайна, так как глава стартапа пытается сэкономить на тех или иных решениях и затягивает этим закупку материалов или подписание договоров с поставщиками, а после явно намекает, что это сотрудник виноват в просроченных дедлайнах, хотя варианты были представлены и обговорены заранее с запасом по времени для форс-мажоров со стороны поставщика/подрядчика?

  3. Какой на ваш взгляд необходимый объем человекочасов на изучение рынка и потребностей потенциальных клиентов на стадии прототипирования продукта, если процесс разработки продукта построен на постепенном масштабировании прототипов (25% и 50% от планируемого размера MVP)?

  4. На рынке одномоментно появляется большое количество специалистов во всех отраслях, так как ваш непосредственный конкурент обанкротился. Станете ли вы менять полностью команду? Если да, то почему? Будете ли вы выборочно кого-то менять в команде? Если да, то по какому принципу вы будете определять кого?

Будет очень хорошо, если вы укажите с какой точки зрения вы отвечаете на вопросы: как рядовой сотрудник или как менеджер проекта.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Путь к ИИ‑сингулярности

У нас было два репозитория неоттестированного вайб‑кода, семьдесят пять тяжеловесных SDD‑спецификаций, пять обмазанных смазкой харнессов, солонка, наполовину полная кастомных скиллов и забитых капслоком правил, с десяток дырявых MCP‑серверов, RAG‑база со свежевекторизованным Confluence, самодельная дощечка имаго‑кодинга и целая россыпь автономных агентов всех мастей, от безобидных автодополнялок до галлюцинирующих субагентов, ставящих пакеты со slopsquatting и втихаря сносящих боевые базы.

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

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

Нет ничего более беспомощного, безответственного и испорченного, чем IT‑команда, запустившая мультиагентный оркестр в режиме allow all.

Это критический (и слегка ехидный) обзор того, что произошло с разработкой последние пару лет.

Путь к ИИ‑сингулярности

Публикации