На заре развития компании тоже сталкивались с проблемой, что дизайнер что-то там напридумывал, а разработчикам расхлебывать...
Поэтому сейчас все макеты от дизайнеров у нас отсматривает аналитик вместе с разработкой и на корню зарубает какие-то ненужные сложности, которые не сильно добавляют ценности продукту, но сильно увеличивают стоимость его разработки
К счастью, у нас был заказчик очень адекватный и погруженный в продукт и в разработку.
Поэтому что-то изобретать не надо было, а было достаточно только правильно расставить приоритеты и в первую очередь доделывать начатые фичи, даже если они были небольшими, а потом уже браться за новые крупные
То что касается прям глубокого системного-системного анализа берут на себя техлиды, а глубокий бизнес анализ обычно берут на себя бизнес аналитики на стороне клиента
Поэтому мы пришли к тому, что целевая позиция аналитиков по мере роста - менеджер проектов, в которых проектирования больше чем коммуникации с кучей стейкхолдеров
А если брать синьеров аналитиков, то им негде будет разгуляться - технику взяли на себя наши техлиды, продуктовую часть продакты на стороне заказчиков, а управление проектом и принятие основных решений менеджеры
В основном мы занимаемся заказной разработкой, поэтому многие выводы пришли именно из "заказного" опыта. Но если говорить про самостоятельного проджект менеджера в продуктовой компании, то думаю большинство пунктов будут актуальными, просто заказчиком будет продакт менеджер
Но насчет того, что важно думать что нужно пользователю соглашусь, как и с остальными двумя пунктами
На заре развития компании тоже сталкивались с проблемой, что дизайнер что-то там напридумывал, а разработчикам расхлебывать...
Поэтому сейчас все макеты от дизайнеров у нас отсматривает аналитик вместе с разработкой и на корню зарубает какие-то ненужные сложности, которые не сильно добавляют ценности продукту, но сильно увеличивают стоимость его разработки
К счастью, у нас был заказчик очень адекватный и погруженный в продукт и в разработку.
Поэтому что-то изобретать не надо было, а было достаточно только правильно расставить приоритеты и в первую очередь доделывать начатые фичи, даже если они были небольшими, а потом уже браться за новые крупные
Такая жизнь, такая жизнь, такая жизнь...
Хорошее дополнение, спасибо!
Хорошее дополнение!)
У себя мы это пофиксили на уровне контрактования - работаем по T&M с бэклогом, а не с жестким ТЗ
Из-за специфики нашей деятельности
То что касается прям глубокого системного-системного анализа берут на себя техлиды, а глубокий бизнес анализ обычно берут на себя бизнес аналитики на стороне клиента
Поэтому мы пришли к тому, что целевая позиция аналитиков по мере роста - менеджер проектов, в которых проектирования больше чем коммуникации с кучей стейкхолдеров
А если брать синьеров аналитиков, то им негде будет разгуляться - технику взяли на себя наши техлиды, продуктовую часть продакты на стороне заказчиков, а управление проектом и принятие основных решений менеджеры
Спасибо за дополнение!
В основном мы занимаемся заказной разработкой, поэтому многие выводы пришли именно из "заказного" опыта. Но если говорить про самостоятельного проджект менеджера в продуктовой компании, то думаю большинство пунктов будут актуальными, просто заказчиком будет продакт менеджер
Но насчет того, что важно думать что нужно пользователю соглашусь, как и с остальными двумя пунктами