У профессионала/эксперта нет проблем с предложениями на рынке - вы сами выбираете по своим критериям, точно также у крупных и известных компаний нет проблем с кандидатами. Они стараются сделать процесс универсальным, чтобы сократить расходы и выровнять всех кандидатов под линейку.
Думаю вы знаете что у некоторых компаний есть и "красные флаги", чтобы отсеять сразу некоторую аудиторию, но про это уже и так было много статей. По моему мнению, алгоритмы для проверки умения программировать и дизайнить бизнес-решения не подходят, если только работа не заключается в разработке этих самых алгоритмов, но эту уже куда-то в дата сайенс и математику.
Фигово, ну или может наоборот к лучшему. В таких случаях лучше сразу узнать о коллегах и их принципах. Не придется потом себя ломать под команду. Я тоже "Обожаю" когда по знанию какой-то специфичной библиотеки судят по опыту человека. Раньше сам таким страдал и спрашивал про подкапотные особенности Spring. Если в целом есть дофига кандидатов то можно повыбирать кто в этом шарит больше всех. Но вот сейчас становится слишком много однотипных фреймворков, технологий, поэтому такой подход становится не актуальным.
Где сейчас работаю принято даже брать синьоров без знания конкретного языка, если человек готов переучиться. Потому что синьоров нормальных попробуй найди, а если с такими доп требованиями то искать пол года придется. За это время проще нанять сильного инженера и пусть он выучит тот язык, который нужен.
На всякий случай напишу, что сейчас как раз ищу к себе в отдел Тим Лида кросфункциональной команды. Обещаю рациональный подход к собеседованию, много челленджей и хорошие условия)
Насчёт написания кода я в целом отношусь спокойно. Если люди хотят проверить кодил ли ты вообще когда-то то это тоже неплохой вариант. Просто не надо от Тим Лида или Руководителя уровнем ещё выше требовать идеального исполнения алгоритма или идеального синтаксиса. Недавно проходил собес на руководителя отдела с 100+ сотрудниками и меня все равно по базе прогнали: перевернуть двусвязный список, удалить дубликаты из базы. Так как я сам иногда такие задачи даю, то сразу честно сказал что это не будет показательно. Мне предложили реализовать то же самое но другим путем, не базовым. Так что тут я сам для себя разнообразие устроил)) А то уж больно скучно начали.
А насчёт того что вам сказали что только через пол года можно, это в целом нормальная практика. Проблема в том как это донести до кандидата. Можно экологично сказать, что на конкретную позицию нужен бОльший опыт работы с технологией, так как именно этого опыта не хватает в команде и нужен эксперт чтобы обучать ей других. Но вы как кандидат очень нам понравились и мы с радостью вернёмся к вам с другой подходящей вакансией. Но это в случаях когда реально такой опыт нужен. Но к сожалению некоторые занимающие менеджеры сами не знают кто им нужен.
Вариант с код ревью - универсален. И для разраба и для лида. Тут согласен. Не описывал только потому, что хотел конкретные кейсы описать которые мне давали. На одном из собесов(успешно пройденных кстати) мне дали кусок многопоточного кода. Причем человек который дал задание, хитро улыбнулся и кивнул на другого интервьюера и спросил не узнал ли тот откуда это. Так я понял что ребята готовы показывать и свои фейлы и вообще с юмором подходят к собеседованиям.
Эх, сочувствую. В таких случаях лучше сразу предупредить HR и перенести. Не думаю что кто-то откажется. А насчет наушников, имел ввиду что человек сидит и общается по ноуту но у него в ухе скрытый наушник, в который ему активно наговаривают ответы. Бывает кандидат очень сильно палится с этим.
У меня был как-то блиц опрос от HR. 5 минут, 30 вопросов. Вопросы уровней от "что такое ООП", до "как в Spring реализовать вложенную транзакцию и на что нужно обратить внимание". Вроде прошел, было интересно. Но собес это не 100% гарантия. Я подхожу к этому как к казино, иногда может не повезти (не выспался, забыл, не понял вопрос, не работал с такой технологией). Обычно в таких случаях никто не ставит черную метку, так что будет шанс еще раз попасть в эту же компанию. Но вот на токсичных могут поставить такую метку или тех кто проходил собес с помощью, с наушником или кто активно гуглил))
Вижу в начале статьи, что много требований к системному аналитику пересекаются с требованиями к архитектору. То есть знание того как устроена система, какие есть связи, как сделать оптимальное решение ввиду всего этого. И также состав ваших команд не предполагает наличие архитектора либо вы его оставили за скобками.
Как вы считаете чем бы вам тогда помог архитектор и кто сейчас выполняет его роль?
Если можно заменить письмом или статусом в чате - почему не просите ПМа сделать именно так? Просто вижу несколько причин
Нет доверия у ПМа к команде
ПМ хочет контролировать все и вся
Процессы не настолько автоматизированы/настроены и приходится руками собирать статусы
Или же статус не интересен вам, но интересен и важен остальным присутствующим, кто может задать вопросы в онлайне и почувствовать ответственность за результаты. командный дух и все такое. Но это больше про спринт ревью/демо и тд (которые тоже спокойно можно увести в оффлайн режим и заменить отпиской в чате, но в скраме как-то до этого недодумались)
К сожалению, не все события именовались корректно в этом случае и синк может означать совместно принятие архитектурного решения, проработка стратегии тестирования по проекту и так далее. Бывают онлайн синки, которые носят характер дать статус, но это скорее связано, что не всегда легко понять по джире в чем проблема, почему что-то не двигается и почему одна команда не предупредила другую завершив свою часть работ. Это решает автоматизацией процесса (к этому надо придти на уровне всей компании)
Статусы задач вы можете сами посмотреть в Jira
Тут ответил частично выше. В идеале - да. Стараюсь по максимум делать под сложные проекты отдельный роадмап (джира план) + джира дашборд. Тут видим и все статусы команд, и процент завершения и потенциальные блокеры. Но это не покрывает 100% кейсов.
Асинхронные коммуникации намного дешевле и удобнее.
100% согласен, это используем по максимуму. Но сразу скажу бывают кейсы когда несколько сотрудников общаются уже пару часов в чате и каждый вообще не понимает друг друга, или когда сложно объяснить словами, а проще пошарить экран и показать на практике.
Внедрите в компанию "культуру митингов"
Вот эта часть наверно самая сложная. Можно долго про это рассказывать, но пока нет инструмента для автоматической валидации, это все же будет не правилом, а рекомендацией. Про вариант, когда против каждого пункта указан исполнитель, я по сути упомянул в секции про Постмиты (то что вы мусором назвали), под каждый спойлером там именно такой список с действиями, сроками и исполнителями.
Научитесь уже делегировать задачи
Мы не в идеальном мире живем, не все задачи можно делегировать и не все подчиненные хотят этими задачами заниматься. Что к этому нужно стремиться - согласен.
5 и 6 правило примерно соответствуют решению - нормально делай, нормально будет. Вроде и не поспоришь, но покажите мне где это работает на 100 процентов?
Хорошо писать книжки и статьи на тему эффективного управления, там много можно замести под коврик и не показывать исподнего. Строить процессы лучше всего на примере сферического коня в вакууме, когда нет людей. Как только появляются люди (причем с самыми разными навыками и характерами) все резко становится не таким красивым и не таким простым.
Это тот самый уровень абстракции что отделяет бизнес от разработчиков
Ключевая роль руководителя (например, продукта) быть как раз этим связующим звеном и иметь контекст обеих сторон и давать возможность по минимуму участвовать в различных синках с другими командами (например, с другим отделов разработки, аналитиками, локализаторами и тд)
Другое дело что всё это заменяется бордой в джире
Уверены, что заменяется? Дополняется и облегчает работу - да. Вы пытались когда-нибудь сами организовать работу по проекту в который входит 10+ команд из разных отделов, с 10 разными проектами в джире, разными процессами поставки задач и SLA на их выполнение?
Если да, буду рад выслушать ваш вариант как все сделать правильно и не про...ть сроки и не получить на выходе что-то вообще не похожее на изначальное ТЗ.
Есть правда продукты типа nginx или Μοzilla
Есть стартапы из 10 человек, кто пилит здоровенный продукт сидя в одном подвале, и есть банковское подразделение из 1000+ сотрудников сидящих по всему миру. И цель у обоих продуктов одна - заработать денег. Основатель Nginx кстати заработал, продав это все дело... а теперь опять вышел со своих Free Nginx. Что-то пошло не так?
Выводы как будто chatGPt писал, несогласованность и абстрактность некоторых фраз очень сбивает с толку.
Также бы добавил в статью кейсы с тем как использовать канарейку в случае когда у вас в релизе N сервисов. Подход в статье усложнится раза в три, так как придется настраивать балансировку между версиями на уровне http или что ещё сложнее на уровне Kafka и аналогичных тулов по работе с событиями.
Так что слепо вкрячить деплой через Хелм не поможет в системах чуть сложнее чем пара crud сервисов.
Плюсую за Any.do. Просто, понятно и можно виджет растянуть на весь экран телефона, чтобы просто доп экран был вместо заметок. Еще удобно, что календарь с гугловым дружит в бесплатной версии.
Из рабочих инструментов согласен, выбор не сильно большой ввиду требований безопасности и количеству интеграций. А для личного пользования можно с ума сойти выбирая идеальный инструмент. Для себя пока остановился на Any.do. чисто как ежедневник со списками задач плюс записная книжка.
Последний раз когда анализировал решения подобного рода(канбан доски) часто сталкивался, что не хватает фришного аккаунта. То есть часть функционала идет в корпоративной версии для командной работы, ну и в целом упор больше на командную разработку, чем на индивидуальное использование. В timestripe смотрю очень кто-то вдохновлялся Notion, тут несколько нестандартная визуализация Канбан борды))
Не сочтите аналогией "пойти погуглить", но я бы посоветовал обратиться к chatGPT. В последнее время некоторые мануалы очень просто заменяются парой обращений к ИИ. Главное задать контекст и возможно вкинуть в нее существующий скрипт пайплайна и сказать в какое место воткнуть интеграцию по отправке аннотации (если нет запрета от СБ на работе). А дальше для верности можно попросить проверить ее саму это же решение на ошибки.
Спасибо, в целом понято. У меня в принципе похожая ситуация (платформенные команды, которые еще и между собой зависят от проекта к проекту). Если говорить о таком квартальном планировании, получается к нему уже все проекты должны быть предварительно проработаны технически, чтобы понимать где какая связь возникает? За сколько времени вы начинаете эту проработку и выделяете ли явно в квартале, например, последний спринт, чисто под проработку и ресерч проектов следующего квартала? У меня боль такая, что при планировании не хватает времени на детальную проработку, а так как проекты сложные технически то там может быть 5+ команд спокойно. И вот эти команды потом становятся блокерами. А варианты типа "сделай сам" хорошо работают когда языки одинаковые в командах, что не мой вариант))
У профессионала/эксперта нет проблем с предложениями на рынке - вы сами выбираете по своим критериям, точно также у крупных и известных компаний нет проблем с кандидатами. Они стараются сделать процесс универсальным, чтобы сократить расходы и выровнять всех кандидатов под линейку.
Думаю вы знаете что у некоторых компаний есть и "красные флаги", чтобы отсеять сразу некоторую аудиторию, но про это уже и так было много статей. По моему мнению, алгоритмы для проверки умения программировать и дизайнить бизнес-решения не подходят, если только работа не заключается в разработке этих самых алгоритмов, но эту уже куда-то в дата сайенс и математику.
Фигово, ну или может наоборот к лучшему. В таких случаях лучше сразу узнать о коллегах и их принципах. Не придется потом себя ломать под команду. Я тоже "Обожаю" когда по знанию какой-то специфичной библиотеки судят по опыту человека. Раньше сам таким страдал и спрашивал про подкапотные особенности Spring. Если в целом есть дофига кандидатов то можно повыбирать кто в этом шарит больше всех. Но вот сейчас становится слишком много однотипных фреймворков, технологий, поэтому такой подход становится не актуальным.
Где сейчас работаю принято даже брать синьоров без знания конкретного языка, если человек готов переучиться. Потому что синьоров нормальных попробуй найди, а если с такими доп требованиями то искать пол года придется. За это время проще нанять сильного инженера и пусть он выучит тот язык, который нужен.
На всякий случай напишу, что сейчас как раз ищу к себе в отдел Тим Лида кросфункциональной команды. Обещаю рациональный подход к собеседованию, много челленджей и хорошие условия)
Насчёт написания кода я в целом отношусь спокойно. Если люди хотят проверить кодил ли ты вообще когда-то то это тоже неплохой вариант. Просто не надо от Тим Лида или Руководителя уровнем ещё выше требовать идеального исполнения алгоритма или идеального синтаксиса. Недавно проходил собес на руководителя отдела с 100+ сотрудниками и меня все равно по базе прогнали: перевернуть двусвязный список, удалить дубликаты из базы. Так как я сам иногда такие задачи даю, то сразу честно сказал что это не будет показательно. Мне предложили реализовать то же самое но другим путем, не базовым. Так что тут я сам для себя разнообразие устроил)) А то уж больно скучно начали.
А насчёт того что вам сказали что только через пол года можно, это в целом нормальная практика. Проблема в том как это донести до кандидата. Можно экологично сказать, что на конкретную позицию нужен бОльший опыт работы с технологией, так как именно этого опыта не хватает в команде и нужен эксперт чтобы обучать ей других. Но вы как кандидат очень нам понравились и мы с радостью вернёмся к вам с другой подходящей вакансией. Но это в случаях когда реально такой опыт нужен. Но к сожалению некоторые занимающие менеджеры сами не знают кто им нужен.
Вариант с код ревью - универсален. И для разраба и для лида. Тут согласен.
Не описывал только потому, что хотел конкретные кейсы описать которые мне давали.
На одном из собесов(успешно пройденных кстати) мне дали кусок многопоточного кода. Причем человек который дал задание, хитро улыбнулся и кивнул на другого интервьюера и спросил не узнал ли тот откуда это. Так я понял что ребята готовы показывать и свои фейлы и вообще с юмором подходят к собеседованиям.
Это просто было собеседование на инженера-компилятора. Компания экономила вычислительные ресурсы))
Эх, сочувствую. В таких случаях лучше сразу предупредить HR и перенести. Не думаю что кто-то откажется. А насчет наушников, имел ввиду что человек сидит и общается по ноуту но у него в ухе скрытый наушник, в который ему активно наговаривают ответы. Бывает кандидат очень сильно палится с этим.
У меня был как-то блиц опрос от HR. 5 минут, 30 вопросов.
Вопросы уровней от "что такое ООП", до "как в Spring реализовать вложенную транзакцию и на что нужно обратить внимание".
Вроде прошел, было интересно. Но собес это не 100% гарантия. Я подхожу к этому как к казино, иногда может не повезти (не выспался, забыл, не понял вопрос, не работал с такой технологией).
Обычно в таких случаях никто не ставит черную метку, так что будет шанс еще раз попасть в эту же компанию. Но вот на токсичных могут поставить такую метку или тех кто проходил собес с помощью, с наушником или кто активно гуглил))
Вижу в начале статьи, что много требований к системному аналитику пересекаются с требованиями к архитектору. То есть знание того как устроена система, какие есть связи, как сделать оптимальное решение ввиду всего этого. И также состав ваших команд не предполагает наличие архитектора либо вы его оставили за скобками.
Как вы считаете чем бы вам тогда помог архитектор и кто сейчас выполняет его роль?
Если можно заменить письмом или статусом в чате - почему не просите ПМа сделать именно так? Просто вижу несколько причин
Нет доверия у ПМа к команде
ПМ хочет контролировать все и вся
Процессы не настолько автоматизированы/настроены и приходится руками собирать статусы
Или же статус не интересен вам, но интересен и важен остальным присутствующим, кто может задать вопросы в онлайне и почувствовать ответственность за результаты. командный дух и все такое. Но это больше про спринт ревью/демо и тд (которые тоже спокойно можно увести в оффлайн режим и заменить отпиской в чате, но в скраме как-то до этого недодумались)
Попробую прокомментировать по пунктам.
К сожалению, не все события именовались корректно в этом случае и синк может означать совместно принятие архитектурного решения, проработка стратегии тестирования по проекту и так далее. Бывают онлайн синки, которые носят характер дать статус, но это скорее связано, что не всегда легко понять по джире в чем проблема, почему что-то не двигается и почему одна команда не предупредила другую завершив свою часть работ. Это решает автоматизацией процесса (к этому надо придти на уровне всей компании)
Тут ответил частично выше. В идеале - да. Стараюсь по максимум делать под сложные проекты отдельный роадмап (джира план) + джира дашборд. Тут видим и все статусы команд, и процент завершения и потенциальные блокеры. Но это не покрывает 100% кейсов.
100% согласен, это используем по максимуму. Но сразу скажу бывают кейсы когда несколько сотрудников общаются уже пару часов в чате и каждый вообще не понимает друг друга, или когда сложно объяснить словами, а проще пошарить экран и показать на практике.
Вот эта часть наверно самая сложная. Можно долго про это рассказывать, но пока нет инструмента для автоматической валидации, это все же будет не правилом, а рекомендацией. Про вариант, когда против каждого пункта указан исполнитель, я по сути упомянул в секции про Постмиты (то что вы мусором назвали), под каждый спойлером там именно такой список с действиями, сроками и исполнителями.
Мы не в идеальном мире живем, не все задачи можно делегировать и не все подчиненные хотят этими задачами заниматься. Что к этому нужно стремиться - согласен.
5 и 6 правило примерно соответствуют решению - нормально делай, нормально будет. Вроде и не поспоришь, но покажите мне где это работает на 100 процентов?
Хорошо писать книжки и статьи на тему эффективного управления, там много можно замести под коврик и не показывать исподнего. Строить процессы лучше всего на примере сферического коня в вакууме, когда нет людей. Как только появляются люди (причем с самыми разными навыками и характерами) все резко становится не таким красивым и не таким простым.
Ключевая роль руководителя (например, продукта) быть как раз этим связующим звеном и иметь контекст обеих сторон и давать возможность по минимуму участвовать в различных синках с другими командами (например, с другим отделов разработки, аналитиками, локализаторами и тд)
Уверены, что заменяется? Дополняется и облегчает работу - да. Вы пытались когда-нибудь сами организовать работу по проекту в который входит 10+ команд из разных отделов, с 10 разными проектами в джире, разными процессами поставки задач и SLA на их выполнение?
Если да, буду рад выслушать ваш вариант как все сделать правильно и не про...ть сроки и не получить на выходе что-то вообще не похожее на изначальное ТЗ.
Есть стартапы из 10 человек, кто пилит здоровенный продукт сидя в одном подвале, и есть банковское подразделение из 1000+ сотрудников сидящих по всему миру. И цель у обоих продуктов одна - заработать денег. Основатель Nginx кстати заработал, продав это все дело... а теперь опять вышел со своих Free Nginx. Что-то пошло не так?
Выводы как будто chatGPt писал, несогласованность и абстрактность некоторых фраз очень сбивает с толку.
Также бы добавил в статью кейсы с тем как использовать канарейку в случае когда у вас в релизе N сервисов. Подход в статье усложнится раза в три, так как придется настраивать балансировку между версиями на уровне http или что ещё сложнее на уровне Kafka и аналогичных тулов по работе с событиями.
Так что слепо вкрячить деплой через Хелм не поможет в системах чуть сложнее чем пара crud сервисов.
Плюсую за Any.do. Просто, понятно и можно виджет растянуть на весь экран телефона, чтобы просто доп экран был вместо заметок. Еще удобно, что календарь с гугловым дружит в бесплатной версии.
Из рабочих инструментов согласен, выбор не сильно большой ввиду требований безопасности и количеству интеграций. А для личного пользования можно с ума сойти выбирая идеальный инструмент. Для себя пока остановился на Any.do. чисто как ежедневник со списками задач плюс записная книжка.
Последний раз когда анализировал решения подобного рода(канбан доски) часто сталкивался, что не хватает фришного аккаунта. То есть часть функционала идет в корпоративной версии для командной работы, ну и в целом упор больше на командную разработку, чем на индивидуальное использование. В timestripe смотрю очень кто-то вдохновлялся Notion, тут несколько нестандартная визуализация Канбан борды))
Не сочтите аналогией "пойти погуглить", но я бы посоветовал обратиться к chatGPT. В последнее время некоторые мануалы очень просто заменяются парой обращений к ИИ. Главное задать контекст и возможно вкинуть в нее существующий скрипт пайплайна и сказать в какое место воткнуть интеграцию по отправке аннотации (если нет запрета от СБ на работе). А дальше для верности можно попросить проверить ее саму это же решение на ошибки.
Соглашусь с коментом что Grafana не про это)) Но как говорит "если нельзя, но очень хочется, то можно".
Если у сервака торчит паблик АПИ, то проще вставить HTML со ссылкой. Вот тут пример: https://play.grafana.org/d/k5rL1wH7k/1-new-features-in-v8-2?orgId=1
В целом все логично, спасибо)
Спасибо, в целом понято. У меня в принципе похожая ситуация (платформенные команды, которые еще и между собой зависят от проекта к проекту). Если говорить о таком квартальном планировании, получается к нему уже все проекты должны быть предварительно проработаны технически, чтобы понимать где какая связь возникает? За сколько времени вы начинаете эту проработку и выделяете ли явно в квартале, например, последний спринт, чисто под проработку и ресерч проектов следующего квартала? У меня боль такая, что при планировании не хватает времени на детальную проработку, а так как проекты сложные технически то там может быть 5+ команд спокойно. И вот эти команды потом становятся блокерами. А варианты типа "сделай сам" хорошо работают когда языки одинаковые в командах, что не мой вариант))