Бюджет - это дело бизнеса. Хотят пилить - их право.
Другое дело, что редко когда распил монолита дает в итоге микросервисы.
Обычно он заканчивается монолитом с частично мертвым кодом в окружении сервисов. Как работает монолит уже никто не знает. Сервисы оказываются не атомарны и зачастую используют общиую базу.
В общем, закономерный конец распила монолита - распределенный монолит.
Ну как вам сказать, в работе девопса и не такое бывает.
Хоть я не девопс, я тимлид. Но даже у меня бывало, когда с девопсом вместе сидишь и придумываешь, как бы поднять прод. А он зараза сразу падает, не успев запустится. А над душей стоит начальник. И начальник начальника. И CTO периодически забегает на огонек.
И ты отмахиваешь от них граблями, мол "Работаем. Есть рабочая гипотеза как починить. Проверяем. Нет, прогноза нет. Да, все понимаю. Ну все, побежал, при любых изменениях буду докладывать". А они нервничают и бегают по потолку.
Так что, если вам некомфортно расшарить экран... ну, это тоже даст работодателю некоторую информацию)
Нормальная история, если я где-то до этого 10 работал и меня не увольняли)
Утрирую: а зачем вообще говорить с вашим бывшим и с вами? Вот в вашей трудовой записано 10 лет - значит, берем!
Опыт - это хорошо. Рекомендации - это конечно тоже хорошо.
Но как то, что вас "не увольняли", поможет нанимающему менеджеру прийти к мысли "надо брать"? Поможет понять, что вы - то самый специалист, которого они так долго искали? Что именно вы придете и решите их проблемы?
В данной статье предпринимается попытка создать имитацию рабочей обстановки. Ну как livecoding с вращением красно-черных деревьев для разрабов.
Попытка хороша. Ну да, несколько оторванная от реальности (как и livecoding), но это лучше, чем ничего. Вполне может разбавить разговоры "за жизнь"
Стейкхолдерам не нужен хороший код. Плохой код, кстати, тоже.
Им нужно решить бизнес-задачу.
Их интересует "когда" и "как дорого".
К сожалению, в статье нет ни одного упоминания про "софты". И очень зря. После 10+ лет в специальности обычно приходит понимание, что одних хардов - мало. Если понимание не приходит... ну что же, человек продолжает из года в год наступать на одни и те же грабли.
Такой проблемы не возникло бы в монолите, там было легко добавить шарду
В статье несколько раз упоминается, что монолит - проще.
Вы не могли бы раскрыть, а какие тогда вы получили преимущества от микросервисов? Точнее так: что вы можете с микросервисами такого, чего не могли с монолитом?
Возможно, вы вкладываете другой смысл в понятие "универсал".
Посмотрите на первоначальную страничку "hire me" из статьи. Чувак там и на .Net и на Rust и на Java и коуч, и тимлид, и вообще "Whatever else comes to your mind". Такой универсал конечно нужен нечасто. Как правило, ищут спеца на конкретный стек.
То что вы описываете - как раз и есть "специалист". И его нанимают не для вбивания буковок в IDE.
Его нанимают, чтобы эти буковки на определенном языке как-то собирались и выкладывались пайплайном в кубер. Для того, чтобы там, в кубере, решать бизнес-задачу.
А еще эти буковки должны как-то связываться с другими буковками, из бд. Так, чтобы не профукать пользовательские данные. Не упасть под нагрузкой ни по памяти ни по процессору. И корректно отмасштабироваться. И вообще иметь архитектуру, обеспечивающую те атрибуты качества, которые нужны бизнесу.
Это все возможно, если специалист знает свой стек. Например, какой-нибудь .NET + Postgre/Mongo с деплоем в кубер через гитлаб. Свой NET и БД специалист должен знать в совершенстве, понимая, что там под капотом. Ну и немного алгоритмов и структур данных в довесок.
Но Java при этом он знать не обязан. И коучем может не быть.
Даже наоборот: если он так много времени тратит на опенсорс и коучинг, на Java и Rust, вопрос: а так ли он хорош, как специалист, конкретно в .Net?
Бывает, что это не заблуждение. Проект загибается. Ну или не загибается, просто компания теряет полгода-год, пока снова не наработает экспертизу.
Заблуждение в самой постановке: мол, мой проект, моя команда, моя компания. Как же они без меня?
Синьор понимает, что это - не его проект, не его команда, ни его компания. Проект могут закрыть, команду расформировать, его самого - уволить. Синьор готов и к такому повороту событий, он умеет управлять рисками.
Мне кажется, теперь я понимаю вашу мысль: "Но как читаю про тимлидов в ИТ - чуть ли не Манхэттенский проект каждый раз"
Ваш путь нетипичен. В большинстве своем тимлиды в айти - это бывшие синьоры. Они эксперты в своей области, но новички в управлении.
Вы, наверное, находитесь на уровне неосознанного знания. И вы уже забыли, каково выкарабкиваться из ямы осознанного незнания. Для вас эти все переживания и топтание по граблям выглядят как нытье. Приблизительно как для синьора выглядят жалобы джуна на ошибки в системе. Типа, ну на стектрейс посмотри, там же все написано.
Проблема болезней еще хуже. Потому что если с переработками сотрудников защищает ТК (хотя бы в теории), то с болезнями - наоборот.
Сидеть на больничном настолько финансово невыгодно, что люди сами всеми правдами и неправдами стремятся оставаться в строю. Ну, и работодатели этим, конечно, пользуются.
Поделитесь опытом, что делаете, чтобы команда не скатилась в шторминг (по Такману)? Были ли у вас ситуации, когда кто-то в команде метил на место лида, а назначили вас?
Ну, если вы менеджер среднего звена - то меняйте тимлидов, как хотите. Никаких проблем нет. Разве кто-то говорит обратное?
Я говорил, что если вы - тимлид, то вам тяжело. Именно вам, как новому лиду, а не хозяину конторы, ни программисту, который как переливал Жсоны, так и будет переливать.
Я не знаю, как оно там в полиции. Подозреваю, что там приказы надо исполнять, и точка.
А в программировании если вы, как линейный руководитель не сможете заработать авторитет в глазах команды, не сможете найти общий язык с командой - то лучше сразу ищите новую работу.
Если вы с разработчиками начнете применять полицейские методы... ну, удачи. Когда (не если, а когда) останетесь без команды - вас попросят на выход.
Я отвечаю не за них, а за выстраивание процессов взаимодействия с ними. Чтобы прозрачно и эффективно.
Например, с одной стороны, для поддержки на каждый чих нужен регламент. Если не по регламенту - то есть повышенный риск что-то сломать. А потом получить по шапке и за поломку и за отсутствие регламента.
А с другой стороны нужно выстроить человеческие отношения.
Одно с другим трудно связать, и вот нужны прокачанные софты и желание сделать мир лучше.
Вы, похоже, забыли, как пишется тег <sarcasm />. А мы и не поняли.
А так-то конечно в требованиях все есть! От функана до тензана. От полотера до квантовой крипты.
И дня не проходит, чтобы не пришлось поварьировать какой-нибудь Лагранжиан или Гамильтониан!
А уж для тех, кто не шарит за уравнение Блэка-Шоулза в частных производных или не умеет в авторегрессию условной гетероскедастичности вообще путь в разрабы должен быть навсегда закрыт!
У вас в договоре стоит "ненормированный раб. день", то есть +3 дня к отпуску. То есть как бы вас даже не "просто так" просят подключиться к проблеме.
С другой стороны, вам не хочется "подводить ребят", не хочется идти на принцип и забить на падение прода, из-за чего пострадает проект и ребята лишаться премии.
И вообще, корпоративная культура такая, что все "хвастаются", кто сколько перерабатывал. Кто по ночам фигачил, кто без обеда сидит потому что у нас бизнес-критикал система.
Да, это эксплуатация сотрудников. Кто бы спорил.
Проблема в том, что свои права-то все знают. Но толку от этого, если работа так "грамотно" устроена, что никто не хочет быть против коллектива, не хочет выглядеть изгоем и забить на работу вне рабочего времени, даже если имеет на это право.
И вот именно против такой эксплуатации с привкусом стокгольмского синдрома я и выступаю.
Вот с такой (весьма распостраненной) культурой я и хотел бы бороться. Когда все вокруг пашут, и тебе неловко подводить ребят, и ты тоже пашешь сверх нормы.
Бороться с этим - сложно. Но это необходимо намного больше, чем рассуждать по поводу сокращения раб. недели.
Простите, если задел чьи-то чувства. Увы, многие профсоюзные действия выглядят бутафорией. Реальные проблемы, они в том, что я описал. С ними бороться сложнее. Но именно с ними и надо бороться, если вы хотите сделать мир лучше.
"Бырбырбыр двенадцать бырбырбыр успеем бырбырбыр 3 человека бырбырбыр проблема.
Воот, и поэтому нужен толмач. Ну "бырбырбыр 3 человека", ок. 3 человека чтобы что? Ответ "бырбырбыр" - фиговый ответ.
Толмач выдаст ответ в стиле: "для митигации риска бырбырбыр с вероятностью возникновения 50% и уроном около 6млн нужно выделить 3 человека бырбырбыр (ФОТ 1 млн), что приведет к сдвигу задачи бырбырбыр с экономическим эффектом 1.5млн" на 2 недели.
Честно скажу, в гробу видал считать все эти миллионы. Но по-другому они не понимают.
Оставив моральную сторону ситуации, мне вот интересно, неужели модель такого трудоустройства работает?
То есть находятся люди, которые идут на зп в 5 раз ниже рынка?
Бюджет - это дело бизнеса. Хотят пилить - их право.
Другое дело, что редко когда распил монолита дает в итоге микросервисы.
Обычно он заканчивается монолитом с частично мертвым кодом в окружении сервисов. Как работает монолит уже никто не знает. Сервисы оказываются не атомарны и зачастую используют общиую базу.
В общем, закономерный конец распила монолита - распределенный монолит.
Ну как вам сказать, в работе девопса и не такое бывает.
Хоть я не девопс, я тимлид. Но даже у меня бывало, когда с девопсом вместе сидишь и придумываешь, как бы поднять прод. А он зараза сразу падает, не успев запустится. А над душей стоит начальник. И начальник начальника. И CTO периодически забегает на огонек.
И ты отмахиваешь от них граблями, мол "Работаем. Есть рабочая гипотеза как починить. Проверяем. Нет, прогноза нет. Да, все понимаю. Ну все, побежал, при любых изменениях буду докладывать". А они нервничают и бегают по потолку.
Так что, если вам некомфортно расшарить экран... ну, это тоже даст работодателю некоторую информацию)
Утрирую: а зачем вообще говорить с вашим бывшим и с вами? Вот в вашей трудовой записано 10 лет - значит, берем!
Опыт - это хорошо. Рекомендации - это конечно тоже хорошо.
Но как то, что вас "не увольняли", поможет нанимающему менеджеру прийти к мысли "надо брать"? Поможет понять, что вы - то самый специалист, которого они так долго искали? Что именно вы придете и решите их проблемы?
В данной статье предпринимается попытка создать имитацию рабочей обстановки. Ну как livecoding с вращением красно-черных деревьев для разрабов.
Попытка хороша. Ну да, несколько оторванная от реальности (как и livecoding), но это лучше, чем ничего. Вполне может разбавить разговоры "за жизнь"
Зависит от того, к чему человек чувствительнее: к проигрышу или отсутствию выигрыша. И это не зависит от образования и интеллекта.
Кто максимизирует выигрыш - тот игрок. Как Фёдор Михайлович, например.
Стейкхолдерам не нужен хороший код. Плохой код, кстати, тоже.
Им нужно решить бизнес-задачу.
Их интересует "когда" и "как дорого".
К сожалению, в статье нет ни одного упоминания про "софты". И очень зря. После 10+ лет в специальности обычно приходит понимание, что одних хардов - мало. Если понимание не приходит... ну что же, человек продолжает из года в год наступать на одни и те же грабли.
В статье несколько раз упоминается, что монолит - проще.
Вы не могли бы раскрыть, а какие тогда вы получили преимущества от микросервисов? Точнее так: что вы можете с микросервисами такого, чего не могли с монолитом?
Возможно, вы вкладываете другой смысл в понятие "универсал".
Посмотрите на первоначальную страничку "hire me" из статьи. Чувак там и на .Net и на Rust и на Java и коуч, и тимлид, и вообще "Whatever else comes to your mind". Такой универсал конечно нужен нечасто. Как правило, ищут спеца на конкретный стек.
То что вы описываете - как раз и есть "специалист". И его нанимают не для вбивания буковок в IDE.
Его нанимают, чтобы эти буковки на определенном языке как-то собирались и выкладывались пайплайном в кубер. Для того, чтобы там, в кубере, решать бизнес-задачу.
А еще эти буковки должны как-то связываться с другими буковками, из бд. Так, чтобы не профукать пользовательские данные. Не упасть под нагрузкой ни по памяти ни по процессору. И корректно отмасштабироваться. И вообще иметь архитектуру, обеспечивающую те атрибуты качества, которые нужны бизнесу.
Это все возможно, если специалист знает свой стек. Например, какой-нибудь .NET + Postgre/Mongo с деплоем в кубер через гитлаб. Свой NET и БД специалист должен знать в совершенстве, понимая, что там под капотом. Ну и немного алгоритмов и структур данных в довесок.
Но Java при этом он знать не обязан. И коучем может не быть.
Даже наоборот: если он так много времени тратит на опенсорс и коучинг, на Java и Rust, вопрос: а так ли он хорош, как специалист, конкретно в .Net?
Если нужно доделывать работу в субботу, то у кого-то проблемы с
Оценкой
Планированием
Управлением рисками
Управлением ожиданиями
У синьоров, конечно, такое тоже бывает. Но главное, что синьор понимает
что происходит. Не просто "я делаю задачу", а реальную проблематику.
почему он работает в субботу. Истинный мотив, а не просто "начальник сказал"
Какой результат он получит от работы в субботу. Истинный результат, а не просто "я дико устану и пожертвую личной жизнью, зато задача будет доделана"
А потом, порефлексировав, принимает осознанные обоснованные решения.
Бывает, что это не заблуждение. Проект загибается. Ну или не загибается, просто компания теряет полгода-год, пока снова не наработает экспертизу.
Заблуждение в самой постановке: мол, мой проект, моя команда, моя компания. Как же они без меня?
Синьор понимает, что это - не его проект, не его команда, ни его компания. Проект могут закрыть, команду расформировать, его самого - уволить. Синьор готов и к такому повороту событий, он умеет управлять рисками.
У меня однажды эта мечта сбылась.
Ликвидация предприятия. 2 оклада.
Пишу, и сам себе завидую )
Спасибо за развернутый ответ!
Мне кажется, теперь я понимаю вашу мысль: "Но как читаю про тимлидов в ИТ - чуть ли не Манхэттенский проект каждый раз"
Ваш путь нетипичен. В большинстве своем тимлиды в айти - это бывшие синьоры. Они эксперты в своей области, но новички в управлении.
Вы, наверное, находитесь на уровне неосознанного знания. И вы уже забыли, каково выкарабкиваться из ямы осознанного незнания. Для вас эти все переживания и топтание по граблям выглядят как нытье. Приблизительно как для синьора выглядят жалобы джуна на ошибки в системе. Типа, ну на стектрейс посмотри, там же все написано.
Проблема болезней еще хуже. Потому что если с переработками сотрудников защищает ТК (хотя бы в теории), то с болезнями - наоборот.
Сидеть на больничном настолько финансово невыгодно, что люди сами всеми правдами и неправдами стремятся оставаться в строю. Ну, и работодатели этим, конечно, пользуются.
Поделитесь опытом, что делаете, чтобы команда не скатилась в шторминг (по Такману)? Были ли у вас ситуации, когда кто-то в команде метил на место лида, а назначили вас?
Как зарабатываете авторитет?
Как налаживаете взаимодействие в команде?
Ну, если вы менеджер среднего звена - то меняйте тимлидов, как хотите. Никаких проблем нет. Разве кто-то говорит обратное?
Я говорил, что если вы - тимлид, то вам тяжело. Именно вам, как новому лиду, а не хозяину конторы, ни программисту, который как переливал Жсоны, так и будет переливать.
Я не знаю, как оно там в полиции. Подозреваю, что там приказы надо исполнять, и точка.
А в программировании если вы, как линейный руководитель не сможете заработать авторитет в глазах команды, не сможете найти общий язык с командой - то лучше сразу ищите новую работу.
Если вы с разработчиками начнете применять полицейские методы... ну, удачи. Когда (не если, а когда) останетесь без команды - вас попросят на выход.
Я отвечаю не за них, а за выстраивание процессов взаимодействия с ними. Чтобы прозрачно и эффективно.
Например, с одной стороны, для поддержки на каждый чих нужен регламент. Если не по регламенту - то есть повышенный риск что-то сломать. А потом получить по шапке и за поломку и за отсутствие регламента.
А с другой стороны нужно выстроить человеческие отношения.
Одно с другим трудно связать, и вот нужны прокачанные софты и желание сделать мир лучше.
Вы, похоже, забыли, как пишется тег <sarcasm />. А мы и не поняли.
А так-то конечно в требованиях все есть! От функана до тензана. От полотера до квантовой крипты.
И дня не проходит, чтобы не пришлось поварьировать какой-нибудь Лагранжиан или Гамильтониан!
А уж для тех, кто не шарит за уравнение Блэка-Шоулза в частных производных или не умеет в авторегрессию условной гетероскедастичности вообще путь в разрабы должен быть навсегда закрыт!
Ну вы же знаете, как такое обычно происходит?
У вас в договоре стоит "ненормированный раб. день", то есть +3 дня к отпуску. То есть как бы вас даже не "просто так" просят подключиться к проблеме.
С другой стороны, вам не хочется "подводить ребят", не хочется идти на принцип и забить на падение прода, из-за чего пострадает проект и ребята лишаться премии.
И вообще, корпоративная культура такая, что все "хвастаются", кто сколько перерабатывал. Кто по ночам фигачил, кто без обеда сидит потому что у нас бизнес-критикал система.
Да, это эксплуатация сотрудников. Кто бы спорил.
Проблема в том, что свои права-то все знают. Но толку от этого, если работа так "грамотно" устроена, что никто не хочет быть против коллектива, не хочет выглядеть изгоем и забить на работу вне рабочего времени, даже если имеет на это право.
И вот именно против такой эксплуатации с привкусом стокгольмского синдрома я и выступаю.
Вот с такой (весьма распостраненной) культурой я и хотел бы бороться. Когда все вокруг пашут, и тебе неловко подводить ребят, и ты тоже пашешь сверх нормы.
Бороться с этим - сложно. Но это необходимо намного больше, чем рассуждать по поводу сокращения раб. недели.
Простите, если задел чьи-то чувства. Увы, многие профсоюзные действия выглядят бутафорией. Реальные проблемы, они в том, что я описал. С ними бороться сложнее. Но именно с ними и надо бороться, если вы хотите сделать мир лучше.
Воот, и поэтому нужен толмач. Ну "бырбырбыр 3 человека", ок. 3 человека чтобы что? Ответ "бырбырбыр" - фиговый ответ.
Толмач выдаст ответ в стиле: "для митигации риска бырбырбыр с вероятностью возникновения 50% и уроном около 6млн нужно выделить 3 человека бырбырбыр (ФОТ 1 млн), что приведет к сдвигу задачи бырбырбыр с экономическим эффектом 1.5млн" на 2 недели.
Честно скажу, в гробу видал считать все эти миллионы. Но по-другому они не понимают.
Периметр команды - это весь народ, не входящий в команду, с которым так или иначе надо взаимодействовать.
Например, девопсы, поддержка, другие команды, с которыми вы интегрируетесь или с которыми у вас есть кросс-функциональные цели.