Как стать автором
Обновить
11
0
Алексей Коробков @alex_kor

CI\CD TeamLead + Java Developer

Отправить сообщение

Спасибо за развернутые комментарии и конструктивный диалог. Мы могли бы продолжить, но, кажется, наши рассуждения уже выходят за рамки комментариев Хабра и превращаются в "простыни".

Я уважаю вашу позицию, хотя и не до конца с ней согласен. Как и раньше, никого ни к чему не принуждаю - каждый читатель Хабра сам решит как ему поступать.

А давайте рассмотрим, под что именно подписывается наемный работник, аккуратно рассмотрим.

Работник подписывается под выполнение определенных задач, которые, по идее, должны быть отображены в его должностной инструкции. Формулировки в ДИ чаще всего довольно широкие и подразумевают разные трактовки. Обязанность о передаче результатов своих трудов описывается в трудовом договоре (или еще где-то, не помню точно).

Если вы здесь хотите подвести под идею "Не написано в ДИ - идите нафиг", то я отвечу так: на мой взгляд, исчерпывающей ДИ не может быть в природе (либо ее придется постоянно править). Это как с законом - описаны общие принципы, но нет детализации до винтика. Хорошо это или нет - спорный вопрос. Я бы перевел это больше в область доверия и соблюдения данных слов. Если вы о чем-то договорились и это соблюдается, то формальное оформление уходит на второй план.

Есть ли у такого доверия риски - безусловно есть. Мой подход больше основан на том, что если вы не держите слово, то мы вряд ли будем работать вместе дальше.

программу — известно, что она на практике всегда содержит ошибки, а потому наличие ошибок — это не результат работы ненадлежащего качества («спустя рукава»), а нормальный результат.

Соглашусь, что наличие ошибок возможно, но наличие критических ошибок на Проде говорит о некачественном процессе разработки, не обязательно виноват программист (мог накосячить QA). Тем не менее, я считаю, что исправлять крит ночью все равно надо, тем более, что кроме разработчика никто другой может эту часть не знать так же хорошо.

Про ненормированный или обычный график

Да, есть такая история, что у разработчиков делают ненормированный график. Но на мой взгляд тут надо руководствоваться принципами разумности. Если у вас эта история ночного фикса раз в квартал, то может и не стоит "лезть в бутылку" и просто починить? А заодно провести ревью всего процесса и выработать меры по предотвращению этого в будущем?

Любой график позволит допускает перекосы, адекватной руководство и нормальные отношения кмк более важны, чем документально оформление режима работы.

По сути, этот «классный продукт» — он не наемного программиста. Если наемному работнику это зачем-то нужно ... он имеет право заниматься этим, не требуя дополнительной оплаты. Если не нужно — имеет право забить, и это — совершенно нормально, что бы ни говорил менеджер, подначивая наемного работника «на слабо».

Согласен, это выбор каждого ради чего он каждый день ходит на работу (ради денег, классного продукта, команды, принадлежности чему-то большому и т.д.). Главное, чтобы за этим "мне не интересно" не скрывалась идея, что теперь можно не следить за результатом.

при заключении трудового договора наемный работник является слабой стороной, и несколько ограничило нанимателя в том, что он вообще от работника может требовать.

Не понял эту мысль, у нас наоборот работник очень даже хорошо защищен и уволить за некачественную работу иногда очень нетривальная задача с риском пойти под суд и восстановить работника.

предлагаю вам учитывать, что куда большее число посетителей Хабра являются наемными работниками, а потому будут оценивать написанное вами со своей классовой позиции.

Я это понимаю, более того, я выражаю свою точки зрения и любой читатель Хабра может согласиться или нет с ней. Я не заставляю вас думать и действовать также.

Я видел разные команды и людей, где-то работали ради идеи/продукта (как с хорошей оплатой, так и без), где-то ради денег или чего-то еще. Есть люди, которым нравится продуктовая разработка, кому-то нравится заказная (аутсорс, аутстафф и т.д.).

Каждый из нас сам выбирает где, зачем и на каких условиях он будет работать, а также все ли фиксировать на бумаге или хватит лишь слова.

А можете более детально раскрыть вашу позицию относительно работы наемным работником?

Вопросы, например:

1) ради чего работаете?

2) за что вам платят деньги по вашему мнению? что является результатом вашей работы?

3) что вы должны и не должны работодателю?

4) что работодатель должен/не должен вам?

Давайте начнем с главного - вы, устраиваясь на работу, изначально подписываетесь под то, что результат ваших трудов принадлежит работодателю (хотя ваше авторство никто не оспаривает). Вы изначально подписываетесь под то, что на вас будут "ездить" и вы будете получать за это деньги.

Значит ли это, что теперь свою работу надо делать спустя рукава? Я считаю, что нет и если я накосячил, то моя обязанность встать посреди ночи и починить свой косяк. Это, в том числе, часть вашего контракта с работодателем (делать свою работу хорошо и отвечать за результат). Бывают ли спорные ситуации, где косяк роде бы не твой - да бывают, но мы работаем командой и иногда нужно помогать коллегам.

Попутно у некоторых людей возникает вполне логичное желание - сделать классный продукт, да он формально не твой, но по сути своей он был создан тобой лично (или твоей командой). Не вижу ничего плохого в том, что люди хотят достигнуть каких-то вершин на работе, выполнить свой challenge.

Возвращаясь к вопросу "Где быть личности человека/автора?" - да везде, вы никогда не перестаете быть личностью, что на работе, что вне ее. Вы можете быть согласны/не согласны с чем-то, можете соглашаться или сопротивляться решениям. Да вы каждую секунду личность, принимающая те или иные решения.

Если вам не нравятся правила найма - работайте на себя на своих условиях или найдите компанию под ваши запросы.

P.S. я сам сейчас менеджер, периодически что-то делаю руками сам (помогаю команде) и за время роста с начальной позиции в ИТ до текущей каких-то принципиальных изменений не было. Как старался делать свою работу хорошо, так и делаю и не вижу тут поинтов про эксплуатацию (мне за это платят и я соглашаюсь на такие условия). Когда мне что-то категорически не нравилось и я не мог это поменять - менял работу и находил более адекватные (под свои запросы) места.

По моему опыту нет ничего ужаснее чем работать с тех лидом который не понимает тебя из-за нехватки скиллов.

В большинстве случаев всегда найдется человек умнее вас. Стоит ли его нанимать к себе в команду - кмк стоит, если он вам подходит по софт/хард скиллам. Никогда не поздно учиться, в том числе техлидам.

Такие идеи о "своем детище" на практике быстро разваливаются

Еще вопрос, что понимать под своим детищем, например, это может быть challenge-история в духе "смогу ли сделать с учетом таких ограничений". Ну т.е. человек вполне понимает, что продукт (внутри которого challenge) не его, а компании. Но мотивация не в самом создании продукта (и владении им) - конечная цель в достижении результата (крут, смог и т.д.). Более того в ряде ситуаций вообще создается продукт под конкретные условия и кроме как в этом месте применить его нельзя. Вернее можно, но тогда придется условия другого места привести к необходимым для внедрения, что не всегда допускается.

Роль техлида - наилучшим образом удовлетворить потребности бизнеса с помощью своей технической экспертизы. И с этой точки зрения это просто рутинная должность: переводить требования с языка бизнеса на язык технологий.

Кмк зависит от ситуации - роли могут совмещаться (техлид + еще какая-то) и степени влияния на продукт также зависят от команды. Не везде и не всегда вы будете просто прослойкой. Более того, правильным решением будет команда, которая слушает своих участников, а не реализует задачи сверху вниз. Это не всегда и не везде может работать, но дает очень хорошие плоды

Не все из перечисленного есть у любого руководителя. Например, бюджеты могут быть у вашего начальника на вашу команду, но вы ими напрямую не управляете (скорее рекомендуете ему что-то включить). Служебные записки писал пару раз в жизни и в ИТ особо не встречал.

В тему "настоящего" начальника предложил бы меньше на эту тему рефлексировать. Если вы управляете людьми, процессами - то вы вероятно уже начальник. На сколько хороший - другой вопрос, но сами регалии в духе

 служебных записок, отчетов, согласований, разработки/защиты бюджета и прочего подобного.

тут имхо малозначимы. Они могут быть как у хорошего, так и у плохого руководителя. Развивайтесь, достигайте новых целей и поувереннее в себе :)

Спасибо. Дельные советы, что-то уже делаю, часть заберу в копилку)

Рад, что статья оказалось полезной :)

Переключения контекстов это прямо часть жизни играющего тренера. С одной стороны - развивает многозадачность, с другой - получаешь расфокус со всеми вытекающими.

К слову, это хороший показатель, что, возможно, менеджмента уже слишком много и "пора выбирать". Если вы один 15 человек напрямую менеджите (без подчиненных лидов), то кмк это прям достижение, либо команда хорошая. Столько в прямом подчинении имхо сильно тяжеловато.

Одна из целей бизнеса - развитие сотрудников внутри компании, вместо найма извне.

Плюсы я описывал в блоке плюсы/минусы - детально смотрите там. Немного дополню/обобщу именно будущего играющего тренера (еще никогда не был лидом). Но это тоже зависит от зрелости процессов:

  • вам дают возможность роста в управление/менеджмент, не требуют экспертных знаний в управлении;

  • хорошая возможность понять нравится/не нравится менеджмент. Может это вообще не ваше и в мечтах было по-другому

  • рост постепенный с менторством от опытных коллег;

  • развивается многозадачность и улучшается взаимодействие с командой

Ничего особенного на них не навешивали, где-то не доглядели (процессы еще не были отлажены), где-то человек сам понял, что управление не его (и это отчасти даже плюс - вовремя понять, что это "не твое"). В общем причины были разные.

Если вам проще считать, что компания всегда хочет вас "поиспользовать" (без какой-либо компенсации) - ваше право. Такое часто встречается, но бывают и исключения.

Поделюсь своим опытом, у меня опыт из QA, DevOps, разработки. Есть вещи, которые я знаю хуже чем мои подчиненные, но мой общий бекграунд и разностороннее понимание одной и той же проблемы дает ощутимые преимущества при решении сложный кейсов. Я это не ради похвалы себя пишу, а чтобы показать, что это работает. Конкретно в играющем тренерстве: если вы не были разработчиком, то вам будет сложнее ими управлять, т.к. вы не знаете специфики. Научиться этому можно, но потребуется время.

Такой вариант вполне возможен. Но это не означает, что играющее тренерство не работает в 100% случаев.

Соглашусь, за этот опыт придется заплатить (возможно даже обеим сторонам). Выбор должен быть осознанным как со стороны компании, так и сотрудника. И, повторюсь, крайне желательно иметь опытного ментора/наставника, чтобы он помог без потерь пройти этот этап роста в руководители.

Рост в лидов через играющее тренерство практикуется в ЦИАН достаточно давно, накоплен большой опыт, набиты шишки. Сейчас процесс уже отлажен, за каждым тренером закреплен ментор, который следит за ростом и проблемами + предлагает решения. Если нужно больше деталей - скажите.

Я явно обозначил, что работа играющим тренером это компромисс

Итогом работы в качестве играющего тренера будут компромиссы и допущения. Периодически будет требоваться корректировка в моменте. Рассматривайте роль играющего тренера как временную – для набора управленческого опыта или срочного решения возникшей ситуации

Как долго человек будет работать в таком формате (и ради чего) решается ситуационно, это зависит от ряда факторов. Причем решение принимает как компания, так и человек.

Я знаю кейсы, когда такой формат помогал растить руководителей, но знаю истории, когда он же их окончательно выжигал и люди уходили из профессии. Здесь нельзя четко сказать "это плохо или хорошо", в разных ситуациях ответ будет разным.

В последнем абзаце вы фактически спрашиваете стоит ли растить лидов или брать их всегда снаружи. Тут каждая компания сама решает хочет ли она вкладывать деньги в человека. У обоих вариантов (растить или брать снаружи) есть свои плюсы и минусы.

Отдельно добавлю, что

компания отряхнётся и дальше пойдет

сильно зависит от компании (ее политик, правил и норм) и совсем не зависит от принятых форм управления, а также вашей конкретной позиции в компании

По поводу размера команды - я об этом писал в последней части

Роль играющего тренера – это хороший старт для руководителя небольшой команды (1-3 подчиненных). С ростом опыта возможно увеличение команды до 7 подчиненных, но минусы постепенно начнут превалировать над плюсами. Если в команде больше 7 человек, на мой взгляд, лучше придерживаться более классических форм управления с разделением ролей руководителя и исполнителя. Опять же, всё зависит от конкретной ситуации и вашего опыта, желания и компетенций.

По фазе продукта - имхо, зависит от ситуации и распределения ролей. Но как дополнительный фактор тоже допускаю.

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

Заходить в это направление нужно осознанно и, крайне желательно, с внешней поддержкой опытного коллеги-руководителя. Со стороны, чаще всего, лучше видно когда что-то идет не так, а опытный коллега может дать дельный совет или вовремя остановить.

Спасибо за рассказ своей истории, было интересно читать. Но сложилось впечатление, как будто бы Ruby — лучший язык программирования, а остальные не очень.

Непонятно что за чудо задача была, которую удалось быстро решить (цитата «Они копали котлован ложками») с помощью Ruby и не получилось на Java/Python за Х месяцев/лет. Можете хотя бы общее представление дать о задаче?

Еще, если не сложно, расскажите, пожалуйста, для каких задач Ruby хорош, а где откровенно бесполезен и нужен какой-то другой язык программирования.

Мы не используем Keycloak на сайте ЦИАН, он используется во внутренних сервисах. Возможно я неправильно понял вопрос, но Keycloak сам не деплоит приложения, он используется для аутентификации/авторизации внутри приложений.


У нас есть два сценария использования:
1) если потеря сессии не важна, то просто ничего не делаем. При входе в сервис пользователь получит редирект, уйдет в Keycloak и там авторизуется (в т.ч. автоматически, если в Keycloak сессия еще не протухла), далее редиректом вернётся обратно в сервис уже аутентифицированным. Этот работает только в случае, когда у вас один инстанс приложения, в противном случае будут постоянные редиректы с разных инстансов и все сломается.
2) если сессия важна, то в этом случае подключается распределенный кеш (в нашем случае Ignite), в котором хранятся все сессии пользователей. В этом случае любая сессия будет известна всем инстансам/сервисам, подключенным к кешу. Для корректной работы этого сценария все сервисы должны использовать куки одного и того же домена.

Мы используем Keycloak для аутентификации и базовой авторизации сервисов и пользователей. Работаем через Open ID Connect (OIDC), синхронизируемся с Active Directory.

Каких-либо серьезных нареканий нет, местами не очень удобный UI, но в целом он нас вполне устраивает. Релизы, кажется, довольно частые (последние 3 релиза с интервалом 1-2 месяца).

Я в целом согласен, что избыточная автоматизация вредна, но считаю, что мы оптимальный предел автоматизации еще не достигли.

Автоматизация с одной стороны помогает, защищая от «человеческого фактора», а с другой иногда сама их создает, запрещая определенные действия с точки зрения конвейера. Примером тому может быть ситуация, когда нужно выкатить изменение одного конфигурационного файла в проекте. Конвейер автоматизации требует прохождения тестов (это не всегда быстро), но если ждать нельзя (Prod лежит, например) и есть 100% уверенность в безопасности изменений, то можно запустить вручную сборку и последующий деплой этих изменений в обход конвейера.

Наша автоматизация это скорее помощник для команд и разработчиков, в одних ситуациях мы просто подсвечиваем проблему, в других ставим запреты на определенные действия. Но всегда есть альтернативный путь, когда мы сознательно можем срезать часть процесса и в ручном режиме выполнить определенные операции (доступно, естественно, только определенным людям). Это позволяет нам поддерживать баланс между автоматизацией и ее ограничениями.
1

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность