А швах как мне кажется в вашей компании. Судя по вашему описанию у вас диктатура в стиле менеджер сам решает что копать нужно отсюда и до обеда. Ничего плохово в этом нет но это довольно низкая ступень развития организации и тим лида, и до бирюзовости вам далеко. Наш подход все таки ближе.
На доске представлен спринт(как временной отрезок, это не скрам с его ритуалами) а не общий бэклог и все задачи на ней важные для бизнеса, неважных на которые сливается время там нет, если такая и попадается то это проблема менеджера которые её туда поместил, и расходует ресурсы компании. Дальше эти задачи если спринт пройдёт нормально должны запилить. Но спринт может пойти не нормально и могут не запилить и вот тут сильно влияет приоритет задач а он обычно в пользу давайте восстановим работоспособность старого функционала(исправим баги) или добавим какую то критическую функциональность которой нет сейчас(допилить не до конца реализованую фичу), а потом уже идут фичи с мидл или лов приоритетом которые надо реализовать и которые могут растянутся на 2-3 спринта. Но для разработчика фича в приоритете, так как это возможность много покодить и поковырятся с интересной задачей с нуля. Допиливать за кем то кусок фичи(привет чужой код) или искать баг не интересно но иногда это важнее новой фичи.
Лучшим быть вообще не обязательно это бред, сравнивать себя с кем то прямой путь к выгоранию, только с самим сабой на определённом временном промежутке времени . Вы просто закрывает задачи важные для бизнеса и все, чаще всего это баги а не фичи они не сильно интересны для остальных и конкуренции за них практически нет.
Вообще не обязательно. В этом подходе не нужно думать о бизнесе, менеджер подумал за разработчика и сам отмаркировал задачи по приоритету для бизнеса. Не нужно никому ничего говорить достаточно просто молча снимать с доски задачи. В конце статистика на промоушене скажет все за вас. Сдесь ценность максимальная и очевидна.
Если у вас канбан то разработчик может сам снять задачу с доски с любым приоритетом. А насчёт промоушена вы сами ответили на свой вопрос, как приводили в статье промоушен получает тот кто виден для бизнеса и решает самые ценные для него задачи а это критикал. При этом умение решить сложную задачу или написать сложный код скорее минус для промоушена он вас превращает в звезду и незаменимого специалиста а таких на верху не любят, слишком высокий риск иметь таких людей в команде. Вообщем хотите промоушена будьте на виду и решайте критические для бизнеса задачи. Сложность и трудность задачи здесь вообще не главное - в колхозе лошадь работала больше всех но председателем так и не стала 😀
Ну тогда ваша статья несёт сугубо рекламный характер. Все круто и классно за кучу денег. Из профита пока только удовольствие от учёбы + бренд Сколково в дипломе. Объективно сравнить по уровню материала с кем то ещё не выйдет. Тот же oxford свои материалы в части литературы не прячет. Главное кейсы и практика. А теория можно просто купить учебник и пропустить через себя важнее в данном случае обратная связь от преподователя правильно ли все усвоил, а не смотрю в книгу вижу...
А если не за знаниями то за чем ещё? Базу и в интернетике почитать можно. Нетворкинг очень спорный момент, можно попасть как удачно так и не очень когда по вашему направлению вы один и 2 из направлений хоть немного полезных вам. А остальные будут из направления в которые вам при всем желании не влезть.
В моем понимании МБА это в первую очередь крутой обзор на острие менеджерской науки и подходов + по каждому предмету в довесок неплохой такой скоуп куда рыть дальше если надо + множество практики и кейсов о которых в реальной жизни не задумывался в силу ограничения своей сферы и кругозора. После МБА должен быть большой кругозор в менеджменте или финансах + возможный нетворк если повезло с группой.
А кто тогда соглашается работать на проектах с которых не возможно продвижение? Зачем это делать? Опыта там никакого а боль и страдание как от задач так и от отсутствия какого либо роста гарантирована. Если у вас в касперском тоже так и нет возможности выбраться из этого то бедные ребята. Я сам работал в болоте в другой компании долгое время и не кому не пожелаю.
А на что тогда опираться? Все остальное уже сильно субъективно и у собственника и разработчика может быть разный взгляд на бизнес модель компании и понимание того что приносит деньги(как уже писали и не раз любой разработчик на балансе компании это убыток, а продажник это прибыль). А метрика приведённая мной это не интересный подход а аварийная лампочка о том что давно пора. Дальше я рассматриваю ситуацию что человека выдвинули и комитет по промоушену отказал. Если не повысили человека по каким то субъективны причинам (луна не в той фазе, нет бюджета, ещё что то) то считаем последствия: от 2 недель до месяца человек крайне демотивирован и производительность снижена очень сильно, в это же время начинается на волне эмоций попытка оценить себя со стороны и походы по собесам. Если поход успешен контр офер этому человеку уже не нужен, уйдёт на эмоциях чисто из принципа. Что теряем в этоге: месяц производительности хорошего разработчика если останется то переодически как волк будет смотреть на сторону и общий перфоманс будет все равно снижен, или полностью разработчика в случае успешного прохождения им собеса в другой компании. Если отказывают в продвижении на грейд то хотя бы дают повышение зарплаты на текущей позиции за пользу и старания. Но все равно это мало кого мотивирует и чаще всего после неудавшегося промоушена люди уходят.
У вас какое то неправильное понимание синьора. Задумываться о ценности для бизнеса это вообще-то задача менеджера а не сеньора. Если вы с мидла делаете промоушен человеку в лиды то да необходимо чтобы он это понимал. Ну а понять что человек дорос до сеньера очень просто что менеджменту что работнику. Открываем статистику в git lab и смотрим количество решенных задач с тегом 'high' и 'critical' если их сумма привалирует над 'low' и примерно эквивалентна 'medium' поздравляю у вас созрел сеньер-помидор и пора повышать. И созрел он не по абстрактным знаниям фреймворков и технологий а по общей пользе для вашего продукта. Найти ему замену будет уже очень дорого.
А реальный это как? Если в сантиметрах то после 25 люди не растут, а только уменьшаются, если в килограммах, то довольно печальный способ роста, если же в экспертизе то это вообще не рост в моем понимании, ибо там график экспертиза-зарплата быстро переходит в логарифм(качай экспертизу, не качай денег больше не будет, а если будет то не пропорционально затрачиваемым усилиям и имеющейся экспертизе, ибо работодателю нужно решать задачи и он оплачивает именно их а не вашу способность их решить, а количество решаемых задач в единицу времени всегда ограничено поэтому и доплата за экспертность всегда конечная и от её повышения не масштабируется).
То есть вы забили на рост и просто наслаждается работой и задачами? Смотрите не пожалейте об этом. Судя по вам у вас были амбиции но вы нашли им замену, интересно на что? Просто когда накроет кризис среднего возраста и все вокруг вас окажутся начальниками и бизнесменами а вы все ещё будете аналитиком или менеджером нижнего звена они снова вылезут наружу и сожрут вас.
как внутри устроены стандартные контейнеры std::vector, std::string, std::list, std::map;
как работают исключения, какие у них есть преимущества и недостатки;
современные стандарты C++ — 17 и 20. Необходимо не только знать их, но и уметь обоснованно применять на практике нововведения языка. То есть там, где это действительно необходимо и помогает сделать код лучше;
разницу между design-, compile- и runtime — а также не боится шаблонов.
А вы классический си не используете, только си++? Используя си могли бы расширить окно поиска кандидатов на программистов встроенного программного обеспечения, там знания архитектуры и многопотосности у людей довольно приличное.
Подходят два человека. Оба хорошие. Оба имеют проектный опыт. Оба хорошие технические специалисты и хотят расти в руководителей, но при этом можно предположить, что многое для них будет новым и незнакомым.
Было сложно сравнить их между собой. Один был хорош в чём-то одном, другой — в чём-то другом.
Надо сказать изначально скверная ситуация. Большой шанс потерять 2х отличных специалистов. 1й уйдёт потому что выбрали не его и дальнейшее продвижение карьеры в этой компании будет возможно теперь непонятно когда. А 2й может не справиться и демотивированный, уйдёт искать себя в другой компании.
Я читал все ваши статьи, с чем то согласен с чем то нет ибо имею другой опыт в embedded области связанный в основном с реалтаймом. Вас же я призываю не зацикливаться на opensource и uart с cli а смотреть шире на применение как интерфейсов для отладки так и различных сред ide.
Зачем отлаживать один отладочный интерфейс с помощью другого отладочного интерфейса. Запустили отладочный интерфейс с jtag, а дальше запускаем неостанавливаемое приложение и собираем логи.
А швах как мне кажется в вашей компании. Судя по вашему описанию у вас диктатура в стиле менеджер сам решает что копать нужно отсюда и до обеда. Ничего плохово в этом нет но это довольно низкая ступень развития организации и тим лида, и до бирюзовости вам далеко. Наш подход все таки ближе.
На доске представлен спринт(как временной отрезок, это не скрам с его ритуалами) а не общий бэклог и все задачи на ней важные для бизнеса, неважных на которые сливается время там нет, если такая и попадается то это проблема менеджера которые её туда поместил, и расходует ресурсы компании. Дальше эти задачи если спринт пройдёт нормально должны запилить. Но спринт может пойти не нормально и могут не запилить и вот тут сильно влияет приоритет задач а он обычно в пользу давайте восстановим работоспособность старого функционала(исправим баги) или добавим какую то критическую функциональность которой нет сейчас(допилить не до конца реализованую фичу), а потом уже идут фичи с мидл или лов приоритетом которые надо реализовать и которые могут растянутся на 2-3 спринта. Но для разработчика фича в приоритете, так как это возможность много покодить и поковырятся с интересной задачей с нуля. Допиливать за кем то кусок фичи(привет чужой код) или искать баг не интересно но иногда это важнее новой фичи.
Лучшим быть вообще не обязательно это бред, сравнивать себя с кем то прямой путь к выгоранию, только с самим сабой на определённом временном промежутке времени . Вы просто закрывает задачи важные для бизнеса и все, чаще всего это баги а не фичи они не сильно интересны для остальных и конкуренции за них практически нет.
Вообще не обязательно. В этом подходе не нужно думать о бизнесе, менеджер подумал за разработчика и сам отмаркировал задачи по приоритету для бизнеса. Не нужно никому ничего говорить достаточно просто молча снимать с доски задачи. В конце статистика на промоушене скажет все за вас. Сдесь ценность максимальная и очевидна.
Если у вас канбан то разработчик может сам снять задачу с доски с любым приоритетом. А насчёт промоушена вы сами ответили на свой вопрос, как приводили в статье промоушен получает тот кто виден для бизнеса и решает самые ценные для него задачи а это критикал. При этом умение решить сложную задачу или написать сложный код скорее минус для промоушена он вас превращает в звезду и незаменимого специалиста а таких на верху не любят, слишком высокий риск иметь таких людей в команде. Вообщем хотите промоушена будьте на виду и решайте критические для бизнеса задачи. Сложность и трудность задачи здесь вообще не главное - в колхозе лошадь работала больше всех но председателем так и не стала 😀
А вы подписали NDA?
Ну тогда ваша статья несёт сугубо рекламный характер. Все круто и классно за кучу денег. Из профита пока только удовольствие от учёбы + бренд Сколково в дипломе. Объективно сравнить по уровню материала с кем то ещё не выйдет. Тот же oxford свои материалы в части литературы не прячет. Главное кейсы и практика. А теория можно просто купить учебник и пропустить через себя важнее в данном случае обратная связь от преподователя правильно ли все усвоил, а не смотрю в книгу вижу...
А если не за знаниями то за чем ещё? Базу и в интернетике почитать можно. Нетворкинг очень спорный момент, можно попасть как удачно так и не очень когда по вашему направлению вы один и 2 из направлений хоть немного полезных вам. А остальные будут из направления в которые вам при всем желании не влезть.
В моем понимании МБА это в первую очередь крутой обзор на острие менеджерской науки и подходов + по каждому предмету в довесок неплохой такой скоуп куда рыть дальше если надо + множество практики и кейсов о которых в реальной жизни не задумывался в силу ограничения своей сферы и кругозора. После МБА должен быть большой кругозор в менеджменте или финансах + возможный нетворк если повезло с группой.
А можете поделится ссылками на pre-reading и рекомендованную литературу по каждому модулю.
MBA в Воронеже стоит 250 тыс руб. Если не нужно Сколково добро пожаловать.
А кто тогда соглашается работать на проектах с которых не возможно продвижение? Зачем это делать? Опыта там никакого а боль и страдание как от задач так и от отсутствия какого либо роста гарантирована. Если у вас в касперском тоже так и нет возможности выбраться из этого то бедные ребята. Я сам работал в болоте в другой компании долгое время и не кому не пожелаю.
А на что тогда опираться? Все остальное уже сильно субъективно и у собственника и разработчика может быть разный взгляд на бизнес модель компании и понимание того что приносит деньги(как уже писали и не раз любой разработчик на балансе компании это убыток, а продажник это прибыль). А метрика приведённая мной это не интересный подход а аварийная лампочка о том что давно пора. Дальше я рассматриваю ситуацию что человека выдвинули и комитет по промоушену отказал. Если не повысили человека по каким то субъективны причинам (луна не в той фазе, нет бюджета, ещё что то) то считаем последствия: от 2 недель до месяца человек крайне демотивирован и производительность снижена очень сильно, в это же время начинается на волне эмоций попытка оценить себя со стороны и походы по собесам. Если поход успешен контр офер этому человеку уже не нужен, уйдёт на эмоциях чисто из принципа. Что теряем в этоге: месяц производительности хорошего разработчика если останется то переодически как волк будет смотреть на сторону и общий перфоманс будет все равно снижен, или полностью разработчика в случае успешного прохождения им собеса в другой компании. Если отказывают в продвижении на грейд то хотя бы дают повышение зарплаты на текущей позиции за пользу и старания. Но все равно это мало кого мотивирует и чаще всего после неудавшегося промоушена люди уходят.
У вас какое то неправильное понимание синьора. Задумываться о ценности для бизнеса это вообще-то задача менеджера а не сеньора. Если вы с мидла делаете промоушен человеку в лиды то да необходимо чтобы он это понимал. Ну а понять что человек дорос до сеньера очень просто что менеджменту что работнику. Открываем статистику в git lab и смотрим количество решенных задач с тегом 'high' и 'critical' если их сумма привалирует над 'low' и примерно эквивалентна 'medium' поздравляю у вас созрел сеньер-помидор и пора повышать. И созрел он не по абстрактным знаниям фреймворков и технологий а по общей пользе для вашего продукта. Найти ему замену будет уже очень дорого.
Спасибо за совет, обязательно посмотрю.
А реальный это как? Если в сантиметрах то после 25 люди не растут, а только уменьшаются, если в килограммах, то довольно печальный способ роста, если же в экспертизе то это вообще не рост в моем понимании, ибо там график экспертиза-зарплата быстро переходит в логарифм(качай экспертизу, не качай денег больше не будет, а если будет то не пропорционально затрачиваемым усилиям и имеющейся экспертизе, ибо работодателю нужно решать задачи и он оплачивает именно их а не вашу способность их решить, а количество решаемых задач в единицу времени всегда ограничено поэтому и доплата за экспертность всегда конечная и от её повышения не масштабируется).
То есть вы забили на рост и просто наслаждается работой и задачами? Смотрите не пожалейте об этом. Судя по вам у вас были амбиции но вы нашли им замену, интересно на что? Просто когда накроет кризис среднего возраста и все вокруг вас окажутся начальниками и бизнесменами а вы все ещё будете аналитиком или менеджером нижнего звена они снова вылезут наружу и сожрут вас.
как внутри устроены стандартные контейнеры std::vector, std::string, std::list, std::map;
как работают исключения, какие у них есть преимущества и недостатки;
современные стандарты C++ — 17 и 20. Необходимо не только знать их, но и уметь обоснованно применять на практике нововведения языка. То есть там, где это действительно необходимо и помогает сделать код лучше;
разницу между design-, compile- и runtime — а также не боится шаблонов.
А вы классический си не используете, только си++? Используя си могли бы расширить окно поиска кандидатов на программистов встроенного программного обеспечения, там знания архитектуры и многопотосности у людей довольно приличное.
Надо сказать изначально скверная ситуация. Большой шанс потерять 2х отличных специалистов. 1й уйдёт потому что выбрали не его и дальнейшее продвижение карьеры в этой компании будет возможно теперь непонятно когда. А 2й может не справиться и демотивированный, уйдёт искать себя в другой компании.
А зачем если есть netcat. https://habr.com/ru/articles/657613/
Цепляетесь по udp и получаете такой же cli. Вопрос не в самих инструментах а в их необходимости.
Я читал все ваши статьи, с чем то согласен с чем то нет ибо имею другой опыт в embedded области связанный в основном с реалтаймом. Вас же я призываю не зацикливаться на opensource и uart с cli а смотреть шире на применение как интерфейсов для отладки так и различных сред ide.
Зачем отлаживать один отладочный интерфейс с помощью другого отладочного интерфейса. Запустили отладочный интерфейс с jtag, а дальше запускаем неостанавливаемое приложение и собираем логи.