Можно просто создать невыносимые условия чтобы сам ушел
Можно. Но оно вам надо?
Работники бывают разные. Я наблюдал, как из соседнено отдела 2 года не могли выпихнуть итальянского забастовщика . Чуваку все было по барабану. По факту, невыносимые условия начальник создал сам себе. Да еще и весь отдел демотивировал.
Да, разговор с позиции силы может принести быстрый результат. Но, если не принесет - обе стороны окажутся в дурацкой ситуации, из которой не так легко найти выход без существенных потерь.
Бюджет - это дело бизнеса. Хотят пилить - их право.
Другое дело, что редко когда распил монолита дает в итоге микросервисы.
Обычно он заканчивается монолитом с частично мертвым кодом в окружении сервисов. Как работает монолит уже никто не знает. Сервисы оказываются не атомарны и зачастую используют общиую базу.
В общем, закономерный конец распила монолита - распределенный монолит.
Ну как вам сказать, в работе девопса и не такое бывает.
Хоть я не девопс, я тимлид. Но даже у меня бывало, когда с девопсом вместе сидишь и придумываешь, как бы поднять прод. А он зараза сразу падает, не успев запустится. А над душей стоит начальник. И начальник начальника. И 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?
Бывает, что это не заблуждение. Проект загибается. Ну или не загибается, просто компания теряет полгода-год, пока снова не наработает экспертизу.
Заблуждение в самой постановке: мол, мой проект, моя команда, моя компания. Как же они без меня?
Синьор понимает, что это - не его проект, не его команда, ни его компания. Проект могут закрыть, команду расформировать, его самого - уволить. Синьор готов и к такому повороту событий, он умеет управлять рисками.
Мне кажется, теперь я понимаю вашу мысль: "Но как читаю про тимлидов в ИТ - чуть ли не Манхэттенский проект каждый раз"
Ваш путь нетипичен. В большинстве своем тимлиды в айти - это бывшие синьоры. Они эксперты в своей области, но новички в управлении.
Вы, наверное, находитесь на уровне неосознанного знания. И вы уже забыли, каково выкарабкиваться из ямы осознанного незнания. Для вас эти все переживания и топтание по граблям выглядят как нытье. Приблизительно как для синьора выглядят жалобы джуна на ошибки в системе. Типа, ну на стектрейс посмотри, там же все написано.
Проблема болезней еще хуже. Потому что если с переработками сотрудников защищает ТК (хотя бы в теории), то с болезнями - наоборот.
Сидеть на больничном настолько финансово невыгодно, что люди сами всеми правдами и неправдами стремятся оставаться в строю. Ну, и работодатели этим, конечно, пользуются.
Поделитесь опытом, что делаете, чтобы команда не скатилась в шторминг (по Такману)? Были ли у вас ситуации, когда кто-то в команде метил на место лида, а назначили вас?
Ну, если вы менеджер среднего звена - то меняйте тимлидов, как хотите. Никаких проблем нет. Разве кто-то говорит обратное?
Я говорил, что если вы - тимлид, то вам тяжело. Именно вам, как новому лиду, а не хозяину конторы, ни программисту, который как переливал Жсоны, так и будет переливать.
Я не знаю, как оно там в полиции. Подозреваю, что там приказы надо исполнять, и точка.
А в программировании если вы, как линейный руководитель не сможете заработать авторитет в глазах команды, не сможете найти общий язык с командой - то лучше сразу ищите новую работу.
Если вы с разработчиками начнете применять полицейские методы... ну, удачи. Когда (не если, а когда) останетесь без команды - вас попросят на выход.
Я отвечаю не за них, а за выстраивание процессов взаимодействия с ними. Чтобы прозрачно и эффективно.
Например, с одной стороны, для поддержки на каждый чих нужен регламент. Если не по регламенту - то есть повышенный риск что-то сломать. А потом получить по шапке и за поломку и за отсутствие регламента.
А с другой стороны нужно выстроить человеческие отношения.
Одно с другим трудно связать, и вот нужны прокачанные софты и желание сделать мир лучше.
А это ваша головная боль, как директора и (или) владельца бизнеса.
Если вы не в сострянии увеличивать ЕБИДТу - вы скоро закроетесь. Извините. И это произойдет вовсе не из-за программиста, который захотел больше денег.
Можно. Но оно вам надо?
Работники бывают разные. Я наблюдал, как из соседнено отдела 2 года не могли выпихнуть итальянского забастовщика . Чуваку все было по барабану. По факту, невыносимые условия начальник создал сам себе. Да еще и весь отдел демотивировал.
Да, разговор с позиции силы может принести быстрый результат. Но, если не принесет - обе стороны окажутся в дурацкой ситуации, из которой не так легко найти выход без существенных потерь.
Боюсь, вы давно не мониторили рынок.
Те же банки берут на 300-400 рядовых разрабов. Не рок-звезд.
ВлП получают сравнимо.
Топовый синьор может претендовать на 400+
Да, это МСК. Но срнди этих вакансий много на удаленку.
И на какую зп вы его взяли?
На ту, что просил, или подтянули до средней джуновской?
Оставив моральную сторону ситуации, мне вот интересно, неужели модель такого трудоустройства работает?
То есть находятся люди, которые идут на зп в 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 оклада.
Пишу, и сам себе завидую )
Спасибо за развернутый ответ!
Мне кажется, теперь я понимаю вашу мысль: "Но как читаю про тимлидов в ИТ - чуть ли не Манхэттенский проект каждый раз"
Ваш путь нетипичен. В большинстве своем тимлиды в айти - это бывшие синьоры. Они эксперты в своей области, но новички в управлении.
Вы, наверное, находитесь на уровне неосознанного знания. И вы уже забыли, каково выкарабкиваться из ямы осознанного незнания. Для вас эти все переживания и топтание по граблям выглядят как нытье. Приблизительно как для синьора выглядят жалобы джуна на ошибки в системе. Типа, ну на стектрейс посмотри, там же все написано.
Проблема болезней еще хуже. Потому что если с переработками сотрудников защищает ТК (хотя бы в теории), то с болезнями - наоборот.
Сидеть на больничном настолько финансово невыгодно, что люди сами всеми правдами и неправдами стремятся оставаться в строю. Ну, и работодатели этим, конечно, пользуются.
Поделитесь опытом, что делаете, чтобы команда не скатилась в шторминг (по Такману)? Были ли у вас ситуации, когда кто-то в команде метил на место лида, а назначили вас?
Как зарабатываете авторитет?
Как налаживаете взаимодействие в команде?
Ну, если вы менеджер среднего звена - то меняйте тимлидов, как хотите. Никаких проблем нет. Разве кто-то говорит обратное?
Я говорил, что если вы - тимлид, то вам тяжело. Именно вам, как новому лиду, а не хозяину конторы, ни программисту, который как переливал Жсоны, так и будет переливать.
Я не знаю, как оно там в полиции. Подозреваю, что там приказы надо исполнять, и точка.
А в программировании если вы, как линейный руководитель не сможете заработать авторитет в глазах команды, не сможете найти общий язык с командой - то лучше сразу ищите новую работу.
Если вы с разработчиками начнете применять полицейские методы... ну, удачи. Когда (не если, а когда) останетесь без команды - вас попросят на выход.
Я отвечаю не за них, а за выстраивание процессов взаимодействия с ними. Чтобы прозрачно и эффективно.
Например, с одной стороны, для поддержки на каждый чих нужен регламент. Если не по регламенту - то есть повышенный риск что-то сломать. А потом получить по шапке и за поломку и за отсутствие регламента.
А с другой стороны нужно выстроить человеческие отношения.
Одно с другим трудно связать, и вот нужны прокачанные софты и желание сделать мир лучше.