Comments 5
У вас при реализации интеграции разработчиком (программистом) одни минусы, в отличии от подхода через аналитика. Это не так.
Первое что хотелось бы сказать - это заказчик не всегда знает чего он хочет. Поэтому этого не узнает и аналитик. Соответственно интеграция не покроет все бизнес-требования.
Аналитик не всегда может оценить реализуемость собранных бизнес-требований в рамках проекта (время, стоимость). Когда как разработчик будет исходить именно из этих реалий.
Первое что хотелось бы сказать - это заказчик не всегда знает чего он хочет. Поэтому этого не узнает и аналитик. Соответственно интеграция не покроет все бизнес-требования.
А разработчик как узнает?
На мой взгляд задача аналитика, в том числе, заключается в определении того что хочет заказчик, а так же в анализе возможной реализации (не с точки зрения кода и выбора тулов, а с точки зрения бизнеса, для примера можно использовать чат в приложении из статьи) и, соответственно, предложении разных вариантов реализации заказчику.
И как правило, разработчику обсуждать подобное с заказчиком - не очень хочется (задача разработчика - писать качественный код, а не обсуждать с заказчиком бизнес-требования). Так что при кейсе, когда заказчик в чем-то не уверен и говорит "общими фразами" - точно потребуется лид/аналитик (роль может меняться в зависимости от структуры команды), который будет общаться с бизнес-заказчиком и таки определять требования.
Аналитик не всегда может оценить реализуемость собранных бизнес-требований в рамках проекта (время, стоимость). Когда как разработчик будет исходить именно из этих реалий.
Согласен с Вами в части возможности более корректной оценки реализации с точки зрения разработки (опять же выбор инструментов, процесс разработки и пр.), но далеко не всегда если заказчик хочет закрыть какую-то потребность - все упирается в сроки. Вернее чаще конечно упирается, но это надо исправлять.
Опять же если аналитик оценивает реализацию (пусть с использованием мощностей разработки) на "околоподходящих" инструментах и понимает (или понимают), что реализуемое решение будет "ну такое себе, но бт закроет", то возможно лучше провести анализ возможной реализации (безусловно с привлечением членов команды, втч - разработчика/-ов) и сделать контрпредложение для:
1. Реализации чего-то, с чем в будущем будет лучше и проще работать как разработке, так и заказчику
2. Сдвига сроков (понятное дело, если заказчика получится убедить, что предложенное им решение - "ну такое себе", а наше - лучше и правильнее)
И боюсь, что при таком кейсе без аналитика/лида (роль может меняться в зависимости от структуры команды) - не обойтись. Исключительно потому, что разработке не очень интересно обсуждать бизнесовые требования и думать над тем, а как же лучше реализовать с точки зрения бизнеса (я не разработчик, но работал со многими разработчиками и зачастую разработчик хочет код писать, а не болтать).
Безусловно подход "через разработчика" - имеет свои плюсы. Но конкретно в описанных кейсах, на мой взгляд (сугубо на мой личный взгляд) - без аналитика никуда.
Вполне возможно, что я чуть иначе трактовал то, что Вы имели ввиду, так что прошу помидоры попридержать :D
А разработчик как узнает?
Никак. Я к тому, что наличие аналитика никак вас не убережет от того, что какое-нибудь бизнес-требование не всплывёт в середине разработки и не поломает выбранную архитектуру/концепцию.
И как правило, разработчику обсуждать подобное с заказчиком - не очень хочется.
Это точно. Особенно когда заказчик находится очень далеко территориально, а к нему обязательно нужно ехать. Да и ко всему прочему персонал, с которым приходится общаться, крайне агрессивен и, порой, даёт ложную или противоречивую информацию.
Ещё крайне тяжелая проблема, что аналитик порой записывает не проблему заказчика, а его предполагаемое решение, не зная откуда оно возникло и какую проблему решает (проблема X-Y).
У нас были случаи когда заказчик хотел реализовать некую функциональность, мы реализовывали, а потом он от неё открещивался словами "мы вас об этом не просили".
Я не считаю, что аналитики не нужны, но реальность такова, что аналитик не может оценить сложность реализации того или иного решения. Просто потому что он аналитик, а не программист. И в любом случае программист будет привлекаться к процессу поиска оптимального решения бизнес-задачи.
У нас были случаи когда заказчик хотел реализовать некую функциональность, мы реализовывали, а потом он от неё открещивался словами "мы вас об этом не просили".
Я не считаю, что аналитики не нужны, но реальность такова, что аналитик не может оценить сложность реализации того или иного решения. Просто потому что он аналитик, а не программист. И в любом случае программист будет привлекаться к процессу поиска оптимального решения бизнес-задачи.
А у нас бывали случаи, когда разработчики делали так, как сами придумали себе в голове (даже не смотря на то, что с ним предварительно обсудили конкретное решение - он просто "забыл"), а потом переделывали, потому что аналитики намного лучше понимал то, как дейстаительно надо делать и прописал ровно то, что нужно было заказчику :)
Предположу, что главная ценность аналитика (естественно, кроме умения сбора и согласования реальных требований) - опыт, который позволяет, если не досконально разбираться в проблеме и возможном решении, то хотя бы закинуть разработчику "на подумать".
С другой стороны, разработчик который сам себе пишет ТЗ, тестирует и внедряет это ценный но исчезающий кадр. В том числе потому, что разделение труда это то, что этот труд делает более эффективным. У нас в компании штат разработчиков за 10 лет вырос в 12 раз, а отношение сеньоров к общему штату упало драматично (было больше 50%, а стало наверное 15%). Как следствие, штат аналитиков вырос в 6 раз. Аналитики, это опыт разработчика отделенный от умения писать код. Опыт, который может быть использован всеми разработчиками сразу.
Ещё крайне тяжелая проблема, что аналитик порой записывает не проблему заказчика, а его предполагаемое решение, не зная откуда оно возникло и какую проблему решает (проблема X-Y).
Таких "аналитиков" надо отстранять от работы, пока не научатся собирать требования, а не записывать за заказчиком.
А у нас бывали случаи, когда разработчики делали так, как сами придумали себе в голове
И у нас такое бывало, своим коллективом программистов ругаем друг друга за неумение читать постановки.
В том числе потому, что разделение труда это то, что этот труд делает более эффективным
Тут с вами не соглашусь. Узкая специализация хоть и может сделать человека профессионалом в своей области, с другой стороны делает его неспособным решать задачи не входящие его сферу деятельности. А так как реальным проблемам всё равно на сферу деятельности, то и оптимальное решение сможет выработать человек только с широким кругозором.
Есть ещё один негативный аспект узкой специализации, он касается социально-политического вопроса. Его я разбирать не буду.
Как аналитику спроектировать интеграцию со сторонними системами