Аналитик может не разбираться в кодовой базе, может не искать плавающий баг. В предметной, области, безусловно, должен разбираться.
Если ваши разработчики не общаются с заказчиком напрямую и не ведет требования (в любом виде), при этом не отдельно, а согласуя их со всеми участниками процесса, то они не могут считаться аналитиками.
То есть у вас разрабочики прямо пишут документ требований, общаются с заказчиком напрямую, согласуют изменения с командой, определяют стейкхолдеров со стороны заказчика с кем общаться? Это именно то, что должен делать аналитик.
Будучи в курсе потребностей пользователя и нюансов поддержки
Смотрите, деньги которые выделяются на создание нового функционала это прямые расходы бюджета. То есть я плачу деньги и получаю то, что я попросил. А затраты на поддержку косвенные, то есть я не понимаю сколько я должен заплатить за поддержку и главное зачем. Поддержка проекта идет по убыточной статье, причем ее крайне сложно прогназировать и планировать. В итоге нужно деньги выводить в более прогнозируемые статьи расходов, а непрогнозируемые, или плохо прогнозируемы, уменьшать насколько возможно, IMHO.
Есть исключения: в частности, если вы выбрали бизнес подель для компании как продажу поддержки, то чем сложнее и запутаннее ваш проект, тем лучше. В этом случае, действительно, эта методология будет сложна в использовании. В этом случае усложнение поддержки проекта придется прямо планировать.
Имел в практике случаи выполнения задач за минуты против нескольких дней, пройди они через аналитика.
Мне кажется это, скорее, «ошибка выжившего». Вам порсто повезло один раз в маленьком случае, но если брать множество кейсов, то такой подход будет разрушать проект.
И тут вопрос, если ваши разработчики брали на себя роль аналитиков, фиксировали ли они эти изменения в проекте согласовывали ли их с командой, проводили ли анализ того, что эта фича может быть реализована в рамках другого функционала. Если нет, то можно поработать в таком проекте первый год, а потом бежать с него, оставив компанию разбираться с тем что получилось.
По моим наблюдениям, в 99% случаев аналитик выполняет роль испорченного телефона. Это не значит, что он не нужен. Это значит, что он нужен крайне редко
Это также может значить, например:
Вы наняли на роль аналитика некомпетентного человека (не читал книжки по аналитике, нет реального опыта и т. п.)
Аналитик нормальный, но его заставляют заниматься не его работой или он перегружен, что ведет к медленной и неэффективнйо работе. Это исправляется, в том числе, введением нормальной методологии работы
можно спросить в подразделении внедрения/техподдержки
Обычно так и делают. Я отразил в этой статье, что необезательно так делать, это может быть дорого.
Также часть задач по аналитике может быть размазана по подразделению разработки. (И это не умозрительный пример, а вполне существующий, живой и работоспособный, наблюдал своими глазами)
Я тоже это постоянно наболюдаю. Беда в том, что у этого своя цена, и цена эта — меньше времени разработки нового функционала. Часто разработка смещена на поддержку в большую сторону, что совсем печально.
Нет, в agile принципах про это не сказано. В существующих agile методологиях и их производных (XP, SCRUM, CRISTAL, Kanban) нет подробностей про аналитику и тестирование.
В реальности аналитиков просто нет в 60% софтверных компании, в частности в Москве. Нормальное тестирование я видел только в одной крупной известной компании.
Можно порассуждать какие программы можно выпускать про это методологии.
Подойдет ли эта методология, чтобы создать операционную систему, аналог Windows? Да. Она как раз и предназначена для уменьшения сложности разработки и увеличения времени поддержки проекта.
Касательно своих идей проектов, этим мало кто будет делиться.
Продуктовая команад, по моему опыту, всегда организована плохо. Существует куча хороших книжек как ее надо организовывать, но я ни разу не видел ни одного грамотного управленца. Никогда. А я их видел много.
Эта методология не про то как сделать все технически правильно. Она про предсказуемость реализации идей и прозрачность работ.
Просто для уточнения agile — это набор принципов. Наиболее распространенная agile методология у нас это SRCUM. Я собеседовался в команду, которая следовала все его канонам буквально и я к ним не пошел, так как теперь поддержка их проекта это ад.
Вы правы что работа технических специалистов состоит в том, чтобы дать бизнесу опции. не вижу в чем бы эта методология не давала бизнесу эти опции. Сорее наоборот тут бизнес сразу работает с командой и в любой момент видит как реализуется идея и успешна ли она.
Я работал во многих компаниях в роли сотрудника или руководителя, каждый раз проводя полную ретроспективу работы компании. Кроме того, я ознакомился с источниками по известным методологиям. Лично мне удалось поработать по RUP, MSF, SCRUM, Project Management (PMBOK), ITIL, разных гибридах и без методологий, в принципе.
Конкретно тут решалась задача создать систему в которую можно вложить деньги и/или силы и получить предсказуемый результат.
Безусловно, у меня есть своя специфика проектов разработки и именно под нее все это и делалось ))
Но, думаю, этот документ все же может принести некоторые полезные идеи и другим разработчикам.
Если ваши разработчики не общаются с заказчиком напрямую и не ведет требования (в любом виде), при этом не отдельно, а согласуя их со всеми участниками процесса, то они не могут считаться аналитиками.
Смотрите, деньги которые выделяются на создание нового функционала это прямые расходы бюджета. То есть я плачу деньги и получаю то, что я попросил. А затраты на поддержку косвенные, то есть я не понимаю сколько я должен заплатить за поддержку и главное зачем. Поддержка проекта идет по убыточной статье, причем ее крайне сложно прогназировать и планировать. В итоге нужно деньги выводить в более прогнозируемые статьи расходов, а непрогнозируемые, или плохо прогнозируемы, уменьшать насколько возможно, IMHO.
Есть исключения: в частности, если вы выбрали бизнес подель для компании как продажу поддержки, то чем сложнее и запутаннее ваш проект, тем лучше. В этом случае, действительно, эта методология будет сложна в использовании. В этом случае усложнение поддержки проекта придется прямо планировать.
Мне кажется это, скорее, «ошибка выжившего». Вам порсто повезло один раз в маленьком случае, но если брать множество кейсов, то такой подход будет разрушать проект.
И тут вопрос, если ваши разработчики брали на себя роль аналитиков, фиксировали ли они эти изменения в проекте согласовывали ли их с командой, проводили ли анализ того, что эта фича может быть реализована в рамках другого функционала. Если нет, то можно поработать в таком проекте первый год, а потом бежать с него, оставив компанию разбираться с тем что получилось.
Это также может значить, например:
Но если ваш выбор методологий будет расширен еще потенциально одной, мне кажется, это даст вам больше информации для принятия правильных решений.
На самом деле эта идея прорабатывалась очень долго и количество разных ситуаций прогнанных через нее было огромно.
Если повезет, то проверим ее на практике ))
Обычно так и делают. Я отразил в этой статье, что необезательно так делать, это может быть дорого.
Я тоже это постоянно наболюдаю. Беда в том, что у этого своя цена, и цена эта — меньше времени разработки нового функционала. Часто разработка смещена на поддержку в большую сторону, что совсем печально.
В реальности аналитиков просто нет в 60% софтверных компании, в частности в Москве. Нормальное тестирование я видел только в одной крупной известной компании.
Подойдет ли эта методология, чтобы создать операционную систему, аналог Windows? Да. Она как раз и предназначена для уменьшения сложности разработки и увеличения времени поддержки проекта.
Касательно своих идей проектов, этим мало кто будет делиться.
Эта методология не про то как сделать все технически правильно. Она про предсказуемость реализации идей и прозрачность работ.
Просто для уточнения agile — это набор принципов. Наиболее распространенная agile методология у нас это SRCUM. Я собеседовался в команду, которая следовала все его канонам буквально и я к ним не пошел, так как теперь поддержка их проекта это ад.
Вы правы что работа технических специалистов состоит в том, чтобы дать бизнесу опции. не вижу в чем бы эта методология не давала бизнесу эти опции. Сорее наоборот тут бизнес сразу работает с командой и в любой момент видит как реализуется идея и успешна ли она.
Конкретно тут решалась задача создать систему в которую можно вложить деньги и/или силы и получить предсказуемый результат.
Безусловно, у меня есть своя специфика проектов разработки и именно под нее все это и делалось ))
Но, думаю, этот документ все же может принести некоторые полезные идеи и другим разработчикам.