Обсуждение блога:Максима Цепкова/2022-06-08: AnalystDays - стабильно хорошая конференция/c000222 — различия между версиями
Материал из MaksWiki
(Новый комментарий от MaksTsepkov: В развитие тезиса о понимании аналитиками архитектуры, из обсуждения на [https://t.me/analy…) |
м |
||
Строка 2: | Строка 2: | ||
: [https://t.me/analystdays/10539 Dr. Raznomazov Valeriy] Все же мне кажется, что в микросервисах аналитики в старом смысле просто не нужны. И все эти доклады про "софт-скилс" попытка уцепиться за соломинку, а не отправиться на свалку истории ИТ, как когда-то туда отправились алхимики. | : [https://t.me/analystdays/10539 Dr. Raznomazov Valeriy] Все же мне кажется, что в микросервисах аналитики в старом смысле просто не нужны. И все эти доклады про "софт-скилс" попытка уцепиться за соломинку, а не отправиться на свалку истории ИТ, как когда-то туда отправились алхимики. | ||
− | : [https://t.me/analystdays/10543 | + | : [https://t.me/analystdays/10543 Мой ответ] Я бы не сказал, что совсем не нужны. Ниша проектирования GUI и снятия требований с заказчика там, где он есть для аналитиков остается. Она сократилась за счет появления сервисов без GUI и за счет продуктовых команд, которые сами придумывают фичи без заказчика, или по его пунктирному описанию, но все равно остается. |
: Но была еще одна ниша, помимо проектирования - коммуникации с заказчиком по поводу доработок. Раньше аналитик понимал, что вот эта хотелка - это просто добавить поле в БД и на интерфейсе, это недорого, а вот эта - по-хорошему надо делать подчиненную сущность вместо пары полей в основной, и интерфейс делать в расчете, что будет на две оплаты или промоакции (о чем говорит заказчик), а много, и это - дорого. И мог объяснить это заказчику, согласовать частное решение, что только две, да еще защитить перед разработчиками эти костыли. А тут получается, что эта ниша - провалена. Потому что аналитик не знает внутреннего устройства и потому не понимает, что вот сюда поле добавить дешево, это один микросервис, а вот сюда - дорого, потому что надо добавить на интерфейсе в первом, а для использования протащить через три промежуточных до пятого, расширив API, или проковыряв прямую дырочку 1-5 для запроса. А разработчики эту нишу коммуникации с бизнесом не очень готовы занимать. А есть еще коммуникация по поводу развертывания, масштабирования и устойчивости, когда бизнес фигеет от количества и стоимости узлов датацентрах. | : Но была еще одна ниша, помимо проектирования - коммуникации с заказчиком по поводу доработок. Раньше аналитик понимал, что вот эта хотелка - это просто добавить поле в БД и на интерфейсе, это недорого, а вот эта - по-хорошему надо делать подчиненную сущность вместо пары полей в основной, и интерфейс делать в расчете, что будет на две оплаты или промоакции (о чем говорит заказчик), а много, и это - дорого. И мог объяснить это заказчику, согласовать частное решение, что только две, да еще защитить перед разработчиками эти костыли. А тут получается, что эта ниша - провалена. Потому что аналитик не знает внутреннего устройства и потому не понимает, что вот сюда поле добавить дешево, это один микросервис, а вот сюда - дорого, потому что надо добавить на интерфейсе в первом, а для использования протащить через три промежуточных до пятого, расширив API, или проковыряв прямую дырочку 1-5 для запроса. А разработчики эту нишу коммуникации с бизнесом не очень готовы занимать. А есть еще коммуникация по поводу развертывания, масштабирования и устойчивости, когда бизнес фигеет от количества и стоимости узлов датацентрах. | ||
: Потенциально эту нишу могут занять аналитики. Или нужно сотрудничество. Для этого надо понимать устройство микросервисов. Или должны занять разработчики. Ну или можно мучиться как сейчас, когда коммуникация налажена плохо и есть взаимное недовольство бизнеса и команды разработки. | : Потенциально эту нишу могут занять аналитики. Или нужно сотрудничество. Для этого надо понимать устройство микросервисов. Или должны занять разработчики. Ну или можно мучиться как сейчас, когда коммуникация налажена плохо и есть взаимное недовольство бизнеса и команды разработки. | ||
: [https://t.me/analystdays/10544 Dr. Raznomazov Valeriy] Ну согласен. На счет коммуникации. Ну тогда надо по другому к аналитикам относиться. Это "менеджер по донесению семантики". Вы возбудили меня на написание собственного текста. Вернусь через 3 дня. | : [https://t.me/analystdays/10544 Dr. Raznomazov Valeriy] Ну согласен. На счет коммуникации. Ну тогда надо по другому к аналитикам относиться. Это "менеджер по донесению семантики". Вы возбудили меня на написание собственного текста. Вернусь через 3 дня. | ||
{{wl-comment: }} | {{wl-comment: }} |
Текущая версия на 14:35, 12 июня 2022
В развитие тезиса о понимании аналитиками архитектуры, из обсуждения на телеграм-канале AnalystDays
- Dr. Raznomazov Valeriy Все же мне кажется, что в микросервисах аналитики в старом смысле просто не нужны. И все эти доклады про "софт-скилс" попытка уцепиться за соломинку, а не отправиться на свалку истории ИТ, как когда-то туда отправились алхимики.
- Мой ответ Я бы не сказал, что совсем не нужны. Ниша проектирования GUI и снятия требований с заказчика там, где он есть для аналитиков остается. Она сократилась за счет появления сервисов без GUI и за счет продуктовых команд, которые сами придумывают фичи без заказчика, или по его пунктирному описанию, но все равно остается.
- Но была еще одна ниша, помимо проектирования - коммуникации с заказчиком по поводу доработок. Раньше аналитик понимал, что вот эта хотелка - это просто добавить поле в БД и на интерфейсе, это недорого, а вот эта - по-хорошему надо делать подчиненную сущность вместо пары полей в основной, и интерфейс делать в расчете, что будет на две оплаты или промоакции (о чем говорит заказчик), а много, и это - дорого. И мог объяснить это заказчику, согласовать частное решение, что только две, да еще защитить перед разработчиками эти костыли. А тут получается, что эта ниша - провалена. Потому что аналитик не знает внутреннего устройства и потому не понимает, что вот сюда поле добавить дешево, это один микросервис, а вот сюда - дорого, потому что надо добавить на интерфейсе в первом, а для использования протащить через три промежуточных до пятого, расширив API, или проковыряв прямую дырочку 1-5 для запроса. А разработчики эту нишу коммуникации с бизнесом не очень готовы занимать. А есть еще коммуникация по поводу развертывания, масштабирования и устойчивости, когда бизнес фигеет от количества и стоимости узлов датацентрах.
- Потенциально эту нишу могут занять аналитики. Или нужно сотрудничество. Для этого надо понимать устройство микросервисов. Или должны занять разработчики. Ну или можно мучиться как сейчас, когда коммуникация налажена плохо и есть взаимное недовольство бизнеса и команды разработки.
- Dr. Raznomazov Valeriy Ну согласен. На счет коммуникации. Ну тогда надо по другому к аналитикам относиться. Это "менеджер по донесению семантики". Вы возбудили меня на написание собственного текста. Вернусь через 3 дня.