Size: a a a

2021 January 30

A

Alex in Data Engineers
Anton Zadorozhniy
это две разные модели: горизонтальная, когда у вас есть инфра команда, платформенные команды, и команды приклада; вертикальная, где внутри сервиса есть и платформенные люди и приклад, а тулинг они через какие-нибудь трайбы делят между собой (но там всегда много велосипедизма)
К нас что-то такое, но в пределах вертикали ещё и подкоманды
источник

AZ

Anton Zadorozhniy in Data Engineers
в крупных компаниях есть и оба подхода, часто вертикальная команда появляется из shadow IT (когда их решают легализовать)
источник

AZ

Anton Zadorozhniy in Data Engineers
хадуп в начале десятых часто рос в компаниях из shadow IT и какие-нибудь ML сервисы стали вертикальными командами
источник

AZ

Anton Zadorozhniy in Data Engineers
также и с облаками у ранних пользователей
источник

K

KrivdaTheTriewe in Data Engineers
плюс быть консалтером канеш, видишь много разного и интересного
источник

A

Alex in Data Engineers
Не обязательно консалтером, достаточно менять работу каждые 2-3 года
источник

K

KrivdaTheTriewe in Data Engineers
Alex
Не обязательно консалтером, достаточно менять работу каждые 2-3 года
источник

AZ

Anton Zadorozhniy in Data Engineers
с 2011 до 2016 я был как раз кофаундером вертикальной команды (а потом компании), мне это известно из общения в тусовке
источник

A

Alex in Data Engineers
Проблемы тусовки что могут как преувеличивать, так и приуменьшать
источник

A

Alex in Data Engineers
А потом приходишь... И хочется выйти
источник

AZ

Anton Zadorozhniy in Data Engineers
поэтому надо много общаться, поить людей на конференциях )
источник

AZ

Anton Zadorozhniy in Data Engineers
работа энтерпрайз архитектора и СТО во многом состоит в таком общении, тестировании идей на других умных людях, отсюда все эти секретные чатики
источник

A

Alex in Data Engineers
Anton Zadorozhniy
с 2011 до 2016 я был как раз кофаундером вертикальной команды (а потом компании), мне это известно из общения в тусовке
О, есть вопрос:

Если ты инженер команды тулинга, как правильно собирать фидбек и требования со своих пользователей?

Чтобы понимать чего им не хватает и не давать творить содомию поверх твоих тулов
источник

A

Alex in Data Engineers
Уж слишком часто это скатывается к НИКАК
источник

AZ

Anton Zadorozhniy in Data Engineers
Alex
О, есть вопрос:

Если ты инженер команды тулинга, как правильно собирать фидбек и требования со своих пользователей?

Чтобы понимать чего им не хватает и не давать творить содомию поверх твоих тулов
у платформенной команды есть владелец продукта, это его головная боль; в очень крупных есть DR (developer relationship) которые больше в полях работают, чем в самой платформенной команде
источник

AZ

Anton Zadorozhniy in Data Engineers
механизмы разные: Engagement Group когда все собираются и ругают платформу 🙂 персональные отношения PO/DR с разработчиками, когда DR обходит этаж пользователей платформы, здоровается с каждым за руку и спрашивает за семью и детей, и между делом какие проблемы с платформой; конечно все виды трекеров и сборщиков идей с голосовалками...
источник

AZ

Anton Zadorozhniy in Data Engineers
как с любой историей "про людей" тут трудно защитить какой-то подход как "правильный", очень много зависит от конкретной компании, культуры, людей в руководстве платформой
источник

AZ

Anton Zadorozhniy in Data Engineers
я пропагандирую подход построенный на эмпатии DR по отношению к пользователям (у меня есть две презентации который я читал у клиентов, Empathy Driven Development и Responsible Data Management), когда DR пытается понять пользователей "как людей"... но я ни разу не настаиваю что это "правильный подход"
источник

GP

Grigory Pomadchin in Data Engineers
KrivdaTheTriewe
Оч хочу чтобы полинот развивался
+
источник

A

Alex in Data Engineers
в тему полинота

https://github.com/ninia/jep

он дергает питон через вот это
источник