Монолитная система прекрасно масштабируется, в том числе и горизонтально. И в разы выгоднее с точки зрения сложности. Не всем же мнить себя Netflix'ом.
Вот вы Конвея привели. Ну так прочитайте внимательно приведенную цитату. "копируя структуры коммуникации," Подумайте какие в компании могут быть структуры коммуникации (кроме хаотических)? От чего эти структуры зависят. Какая структура управления выбрана, функциональная, проектная, матричная? Как происходит масштабирование, по георгафии или по продуктовой линейке? Насколько меняются внешние условия на рынках сбыта? Какой исторический контекст? Из всего этого получается определенная структура коммуникации, к которой подойдет или не подойдет микросервисная архитектура приложений.
Исходя из моего опыта могу сказать, что скорее не подходит. По причине высокой сложности. Особенно, когда у вас прямо по Конвею выстроился монолит, а вы в интернете прочитали, что монолит это зло и начали его в добрые и пушистые микросервисы переписывать.
Для Энга же главный удар пришел со стороны компании MoveTrek Mobility, которая, по договору с 38 Studios, занималась продажей его дома в Массачусетсе. Как выяснилось, дом так и не продали, а в контракте, подписанном Энгом, был пункт мелким шрифтом о том, что, в случае финансовых проблем у 38 Studios, обязательства по оплате ипотеки снова переходят к нему.
Я не понял, почему это удар. Чуваку повезло, легко вернуться обратно в МА, нашел работу.
Фанател по этой парадигме лет 5 назад. Мы ее использовали еще в 2008 году когда HFT-роботов писали. Не зная, что это CQRS/ES)
Советую перед тем как кидаться в омут с головой посмотреть хотя бы это выступление
David Schmitz. Event Sourcing — You are doing it wrong https://www.youtube.com/watch?v=rdB9Q8GouKI
Не без душевных терзаний я сменила работу на более перспективную в плане карьерного роста, и через 9 месяцев стала тимлидом команды разработки, размер которой достигал в пике 12-ти человек, по большей части разработчики — фронт и бэк, а также аналитики, проджекты и QA.
Завидую вам) Я вот был раньше манагером, а потом переехал в другую страну разработчиком. И никак не найду себе "перспективную в плане карьерного роста", чтобы вернуться к тому, к чему у меня больше душа лежит.
"Этот артефакт является единственным источником работы для команды."
Вообще вымыто понятие работы с business-пользователем. Гибкие методологии на то и гибкие, что в их основе лежат 4 простых принципа. Самый первый из них настаивает, чтобы разработчики при анализе требований отдавали предпочтение общению с пользователями и доменными экспертами.
Коэн в User Stories Applied напрямую пишет, что сторя — это только маленькая заметка. Все детали программист получает от прямого общения с пользователем или экспертом. Что кагбэ намекает, что для перехода к гибкой методологии у программиста должен быть доступ к этому пользователю/эксперту.
В вашем опроснике этому не уделено никакого внимания.
А смысл? Ты это все почитаешь, начнешь мечтать о работе своей мечты, а они просто не ответят.
Не знаю как вы, а я когда активно ищу работу рассылаю резюме в 30-50 компаний. И читать авторский креатив довольно быстро надоедает. Вот ответят, тогда и почитаем. А еще лучше, пройдем формальное интервью с HR, доберемся до кого-то технического и тогда сможем узнать подробности о том, как у них там в компании все обстоит.
У вас такие многословные примеры "хорошо", что если их собрать, получится портянка, которую никто не прочитает. В теории я согласен с общей конвой о том, что в вакансии не нужно указывать общие слова, а нужно указывать значимые детали. На практики, кандидаты привыкли, что в вакансии пишут чушь и тратят на ее прочтение столько же времени, сколько рекрутеры на прочтение резюме.
Все было еще хуже:
"But one of his successors, Paul Otellini, missed this lesson. And in part because of a decision he made in 2005, Intel is where they are now, with the whole x86 project at risk. This was the same year that the Mac switched from PPC to Intel, and Steve Jobs went to their new partner to see if they wanted to make the chip to power iPhone.
Otellini recounted what happened next in an exit interview in 2013:
"We ended up not winning it or passing on it, depending on how you want to view it. And the world would have been a lot different if we'd done it… The thing you have to remember is that this was before the iPhone was introduced and no one knew what the iPhone would do… At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn't see it. It wasn't one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought."
Сразу видно, что итальянцы правильно относятся к этим дармоедам)))
А если серьезно, то зп в 2 раза ниже берлинских. Я очень люблю Италию, но больше как турист. Чтобы там жить, нужно либо родиться итальянцем, либо у вас должна быть необъяснимая страсть к этой стране.
Вы еще учтите, что один и тот же руководитель может использовать разные стили управления в разных ситуациях и с разными людьми.
А также то, что во время собеседования никто не покажет своего "истинного" лица. Ни работник, ни руководитель. Как ни крути, все определится в процессе совместной работы. И там нет простых рецептов.
Стиль руководства часто вообще не является определяющим фактором успеха. У людей в целом есть тенденция к преувеличению влияния руководства на процесс. Эффект называется leader attribution error. В добавок к этому, стиль руководства зависит от того как ведут себя работники (и там связь в обе стороны).
Поэтому спасибо вам за обзор стилей, наверняка даст возможность тем, кто вообще не задумывался на тему, наконец, подумать. Но как практический материал статья будет скорее вредить, давая ощущение ложного контроля.
Вот пример.
А.И.Илларионова уволили из "светоча" либертарианской мысли, Института Катона.
https://aillarionov.livejournal.com/1216005.html
Достаточно выразительно?
в jira
Монолитная система прекрасно масштабируется, в том числе и горизонтально. И в разы выгоднее с точки зрения сложности. Не всем же мнить себя Netflix'ом.
Вот вы Конвея привели. Ну так прочитайте внимательно приведенную цитату. "копируя структуры коммуникации," Подумайте какие в компании могут быть структуры коммуникации (кроме хаотических)? От чего эти структуры зависят. Какая структура управления выбрана, функциональная, проектная, матричная? Как происходит масштабирование, по георгафии или по продуктовой линейке? Насколько меняются внешние условия на рынках сбыта? Какой исторический контекст? Из всего этого получается определенная структура коммуникации, к которой подойдет или не подойдет микросервисная архитектура приложений.
Исходя из моего опыта могу сказать, что скорее не подходит. По причине высокой сложности. Особенно, когда у вас прямо по Конвею выстроился монолит, а вы в интернете прочитали, что монолит это зло и начали его в добрые и пушистые микросервисы переписывать.
Я не понял, почему это удар. Чуваку повезло, легко вернуться обратно в МА, нашел работу.
Крутой опыт! Спасибо, что поделились!
Очень поверхностно. Доводы взяты с потолка.
первое и последнее упоминание слова Канбан в статье.
не путайте с российской системой
Вы пропустили это сообщение?
Гениальное решение менеджмента. Избавились от людей, предпочитающих разводить политоту в корпоративных чатах вместо работы.
Фанател по этой парадигме лет 5 назад. Мы ее использовали еще в 2008 году когда HFT-роботов писали. Не зная, что это CQRS/ES)
Советую перед тем как кидаться в омут с головой посмотреть хотя бы это выступление
David Schmitz. Event Sourcing — You are doing it wrong
https://www.youtube.com/watch?v=rdB9Q8GouKI
Завидую вам) Я вот был раньше манагером, а потом переехал в другую страну разработчиком. И никак не найду себе "перспективную в плане карьерного роста", чтобы вернуться к тому, к чему у меня больше душа лежит.
Черити Майорс периодически пишет на тему перехода из разработчиков в менеджеры:
https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/
https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/
https://charity.wtf/2020/09/01/the-official-authorized-list-of-legitimate-reasons-for-deciding-to-become-a-manager/
https://charity.wtf/2020/09/06/if-management-isnt-a-promotion-then-engineering-isnt-a-demotion/
Вообще вымыто понятие работы с business-пользователем. Гибкие методологии на то и гибкие, что в их основе лежат 4 простых принципа. Самый первый из них настаивает, чтобы разработчики при анализе требований отдавали предпочтение общению с пользователями и доменными экспертами.
Коэн в User Stories Applied напрямую пишет, что сторя — это только маленькая заметка. Все детали программист получает от прямого общения с пользователем или экспертом. Что кагбэ намекает, что для перехода к гибкой методологии у программиста должен быть доступ к этому пользователю/эксперту.
В вашем опроснике этому не уделено никакого внимания.
Монолитная архитектура — 0 баллов.
Микросервисный монолит — 1 балл.
Микросервисная архитектура — 3 балла.
С чего вы решили, что монолит — плохо, а микросервисы — хорошо?
Введите лучше метрику, оценивающую насколько сознательно и последовательно команды работают над архитектурой системы.
Все очень похоже на Германию.
А смысл? Ты это все почитаешь, начнешь мечтать о работе своей мечты, а они просто не ответят.
Не знаю как вы, а я когда активно ищу работу рассылаю резюме в 30-50 компаний. И читать авторский креатив довольно быстро надоедает. Вот ответят, тогда и почитаем. А еще лучше, пройдем формальное интервью с HR, доберемся до кого-то технического и тогда сможем узнать подробности о том, как у них там в компании все обстоит.
-
"солидная контора возьмет в аренду дырокол" (с)
У вас такие многословные примеры "хорошо", что если их собрать, получится портянка, которую никто не прочитает. В теории я согласен с общей конвой о том, что в вакансии не нужно указывать общие слова, а нужно указывать значимые детали. На практики, кандидаты привыкли, что в вакансии пишут чушь и тратят на ее прочтение столько же времени, сколько рекрутеры на прочтение резюме.
Все было еще хуже:
"But one of his successors, Paul Otellini, missed this lesson. And in part because of a decision he made in 2005, Intel is where they are now, with the whole x86 project at risk. This was the same year that the Mac switched from PPC to Intel, and Steve Jobs went to their new partner to see if they wanted to make the chip to power iPhone.
Otellini recounted what happened next in an exit interview in 2013:
"We ended up not winning it or passing on it, depending on how you want to view it. And the world would have been a lot different if we'd done it… The thing you have to remember is that this was before the iPhone was introduced and no one knew what the iPhone would do… At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn't see it. It wasn't one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought."
Источник https://seekingalpha.com/article/4400987-intel-and-innovators-dilemma
Сразу видно, что итальянцы правильно относятся к этим дармоедам)))
А если серьезно, то зп в 2 раза ниже берлинских. Я очень люблю Италию, но больше как турист. Чтобы там жить, нужно либо родиться итальянцем, либо у вас должна быть необъяснимая страсть к этой стране.
Вы еще учтите, что один и тот же руководитель может использовать разные стили управления в разных ситуациях и с разными людьми.
А также то, что во время собеседования никто не покажет своего "истинного" лица. Ни работник, ни руководитель. Как ни крути, все определится в процессе совместной работы. И там нет простых рецептов.
Стиль руководства часто вообще не является определяющим фактором успеха. У людей в целом есть тенденция к преувеличению влияния руководства на процесс. Эффект называется leader attribution error. В добавок к этому, стиль руководства зависит от того как ведут себя работники (и там связь в обе стороны).
Поэтому спасибо вам за обзор стилей, наверняка даст возможность тем, кто вообще не задумывался на тему, наконец, подумать. Но как практический материал статья будет скорее вредить, давая ощущение ложного контроля.
Литература для интересующихся:
WHEN AND HOW TEAM LEADERS MATTER Richard Hackman and Ruth Wageman