Первое что хотелось бы сказать - это заказчик не всегда знает чего он хочет. Поэтому этого не узнает и аналитик. Соответственно интеграция не покроет все бизнес-требования.
А разработчик как узнает?
На мой взгляд задача аналитика, в том числе, заключается в определении того что хочет заказчик, а так же в анализе возможной реализации (не с точки зрения кода и выбора тулов, а с точки зрения бизнеса, для примера можно использовать чат в приложении из статьи) и, соответственно, предложении разных вариантов реализации заказчику.
И как правило, разработчику обсуждать подобное с заказчиком - не очень хочется (задача разработчика - писать качественный код, а не обсуждать с заказчиком бизнес-требования). Так что при кейсе, когда заказчик в чем-то не уверен и говорит "общими фразами" - точно потребуется лид/аналитик (роль может меняться в зависимости от структуры команды), который будет общаться с бизнес-заказчиком и таки определять требования.
Аналитик не всегда может оценить реализуемость собранных бизнес-требований в рамках проекта (время, стоимость). Когда как разработчик будет исходить именно из этих реалий.
Согласен с Вами в части возможности более корректной оценки реализации с точки зрения разработки (опять же выбор инструментов, процесс разработки и пр.), но далеко не всегда если заказчик хочет закрыть какую-то потребность - все упирается в сроки. Вернее чаще конечно упирается, но это надо исправлять.
Опять же если аналитик оценивает реализацию (пусть с использованием мощностей разработки) на "околоподходящих" инструментах и понимает (или понимают), что реализуемое решение будет "ну такое себе, но бт закроет", то возможно лучше провести анализ возможной реализации (безусловно с привлечением членов команды, втч - разработчика/-ов) и сделать контрпредложение для:
1. Реализации чего-то, с чем в будущем будет лучше и проще работать как разработке, так и заказчику
2. Сдвига сроков (понятное дело, если заказчика получится убедить, что предложенное им решение - "ну такое себе", а наше - лучше и правильнее)
И боюсь, что при таком кейсе без аналитика/лида (роль может меняться в зависимости от структуры команды) - не обойтись. Исключительно потому, что разработке не очень интересно обсуждать бизнесовые требования и думать над тем, а как же лучше реализовать с точки зрения бизнеса (я не разработчик, но работал со многими разработчиками и зачастую разработчик хочет код писать, а не болтать).
Безусловно подход "через разработчика" - имеет свои плюсы. Но конкретно в описанных кейсах, на мой взгляд (сугубо на мой личный взгляд) - без аналитика никуда.
Вполне возможно, что я чуть иначе трактовал то, что Вы имели ввиду, так что прошу помидоры попридержать :D
На самом деле в защиту тех. поддержки могу сказать, что они работают по четко обозначенным скриптам. За то, что ты не придерживаешься скриптов, к сожалению, на тебя будут распространяться «санкции» (вплоть до понижения ЗП, так как есть KPI для оценки «качества» работы). Либо придется отстаивать свое решение до посинения, а это — никому не надо, потому что кроме работы у этих людей, есть свои проблемы и тратить время ЕЖЕДНЕВНО еще и на разборки с тимлидом — ну такое.
По правильному, конечно, нужно действовать индивидуально почти в каждом запросе, но увы…
Я согласен, что это не правильный подход, но он «простой» для руководства. То, решишь ты проблему или нет — их волнует меньше всего, на мой, сугубо личный взгляд.
Причем, я повторюсь, те люди, с которыми Вы говорите по телефону — отвечают Вам по скриптам, которые четко прописаны. Да, может разными словами, если фантазия позволяет, но скрипт один.
Аналогично и с сотрудниками, с которыми Вы переписываетесь. Они так же работают по скриптам, но у них не только «словесные» скрипты, но и технические (как раз в плане «Соберите AIDA64», сбросьте тел. до заводских настроек и пр.).
Решают и что-то делают в продукте — только сотрудники, на которых эскалируют запросы со второй линии. А вот что там происходит — я боюсь представить)
Я начал писать об этом продукте (Safe Kids), так как сам работал в технической поддержке этого продукта в далеких 2016-ых. Написал уже половину комментария и… что-то заставило меня поднять глаза выше того окна в котором я пишу. После этого — я увидел Ваш комментарий :)
Что касательно Safe Kids — полностью согласен и судя по тому, что этот комментарий оставлен не в 2016 году, а в наше время — ситуация лучше не стала. Дыра на дыре.
Радует лишь то, что с этим продуктом более я НИКАК не взаимодействую.
А разработчик как узнает?
На мой взгляд задача аналитика, в том числе, заключается в определении того что хочет заказчик, а так же в анализе возможной реализации (не с точки зрения кода и выбора тулов, а с точки зрения бизнеса, для примера можно использовать чат в приложении из статьи) и, соответственно, предложении разных вариантов реализации заказчику.
И как правило, разработчику обсуждать подобное с заказчиком - не очень хочется (задача разработчика - писать качественный код, а не обсуждать с заказчиком бизнес-требования). Так что при кейсе, когда заказчик в чем-то не уверен и говорит "общими фразами" - точно потребуется лид/аналитик (роль может меняться в зависимости от структуры команды), который будет общаться с бизнес-заказчиком и таки определять требования.
Согласен с Вами в части возможности более корректной оценки реализации с точки зрения разработки (опять же выбор инструментов, процесс разработки и пр.), но далеко не всегда если заказчик хочет закрыть какую-то потребность - все упирается в сроки. Вернее чаще конечно упирается, но это надо исправлять.
Опять же если аналитик оценивает реализацию (пусть с использованием мощностей разработки) на "околоподходящих" инструментах и понимает (или понимают), что реализуемое решение будет "ну такое себе, но бт закроет", то возможно лучше провести анализ возможной реализации (безусловно с привлечением членов команды, втч - разработчика/-ов) и сделать контрпредложение для:
1. Реализации чего-то, с чем в будущем будет лучше и проще работать как разработке, так и заказчику
2. Сдвига сроков (понятное дело, если заказчика получится убедить, что предложенное им решение - "ну такое себе", а наше - лучше и правильнее)
И боюсь, что при таком кейсе без аналитика/лида (роль может меняться в зависимости от структуры команды) - не обойтись. Исключительно потому, что разработке не очень интересно обсуждать бизнесовые требования и думать над тем, а как же лучше реализовать с точки зрения бизнеса (я не разработчик, но работал со многими разработчиками и зачастую разработчик хочет код писать, а не болтать).
Безусловно подход "через разработчика" - имеет свои плюсы. Но конкретно в описанных кейсах, на мой взгляд (сугубо на мой личный взгляд) - без аналитика никуда.
Вполне возможно, что я чуть иначе трактовал то, что Вы имели ввиду, так что прошу помидоры попридержать :D
По правильному, конечно, нужно действовать индивидуально почти в каждом запросе, но увы…
Я согласен, что это не правильный подход, но он «простой» для руководства. То, решишь ты проблему или нет — их волнует меньше всего, на мой, сугубо личный взгляд.
Причем, я повторюсь, те люди, с которыми Вы говорите по телефону — отвечают Вам по скриптам, которые четко прописаны. Да, может разными словами, если фантазия позволяет, но скрипт один.
Аналогично и с сотрудниками, с которыми Вы переписываетесь. Они так же работают по скриптам, но у них не только «словесные» скрипты, но и технические (как раз в плане «Соберите AIDA64», сбросьте тел. до заводских настроек и пр.).
Решают и что-то делают в продукте — только сотрудники, на которых эскалируют запросы со второй линии. А вот что там происходит — я боюсь представить)
Что касательно Safe Kids — полностью согласен и судя по тому, что этот комментарий оставлен не в 2016 году, а в наше время — ситуация лучше не стала. Дыра на дыре.
Радует лишь то, что с этим продуктом более я НИКАК не взаимодействую.
В ближайшее время она точно мне не понадобится, но для общего понимания — годно!