а кто сказал что мне стало лучше\легче? это называется - Демагогические приёмы. я тоже могу так сделать: "вы не рады, вы пытаетесь выпутаться из того что вас .... блаблабла". видите, я сказал утверждение, сам объявил его истиной и на нем построил дальше предложение. так делать плохо ;)
как я сделал вывод? ну у вас в профиле написано что вы ментор РПшников в ИТ, канал вон свой ведете. пришли со статьей не реальных кейсов, а скорее со "стратегией". А значит хотите задать вектор для юных умов, т.е. джунов.
почему жестко ... потому что вы в первом же предложении в целом, то обидели разработчиков (ни некрасиво это писать от <должность> до <должность> ... вы поставили сразу себя на ранг выше, хотя это разные профессии вообще-то). Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей, тем что на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму. ну и потому что видимо неделя такая на хабре "стратегов" писать статьи "флаги", прибежали, помахали, думали плюсами закидают? нет, тут иногда и покритиковать могут. вы как говорил один мой друг просто "не в профессии". но увы таких основная масса в мире РП (( вот такая печалька))
имхо, вы видели статьи про докер стратегические?) ну так уместите стратегию свою в пару абзацев и просто поделитесь опытом в статье на конкретном примере что и как делали. как вы выбрали архитектуру когда разраб джун был, откуда у вас был опыт пул или пуш модель передачи данных сделать, как вы конкретную бизнес цель замапили на фичу системы и почему сделали фичу, а не просто какое-то изменение процесса например, покажите описание какое фиче сделали (сиквенсы, датафлоу и т.д.), как тестеры ваши требования протестировали, кто ПРы принимал и за архитектурой следил, как оценку делали, какой методикой следили за прогрессом, с какой дискретой, что дало, какие решения были приняты на основе метрик ... обычную работу короче РП то опишите, а не это вот все блаблаба.
ох, махнул я коммент, извините если обидело. но на обижены воду возят. а то нам хватает ванильных разработчиков)
от разработчика до руководителя! я был никем и стал важным боссом))))
вы и не менеджер и не аналитик и не архитектор, а так, обычный "манагер".
требованиями и в том числе бизнес, пусть занимаются аналитики, архитекторы пусть занимают на чем и как писать код. а вы поймите что руководитель проектов это другое направление деятельности в отличии от разработки и займитесь своими задачами, хотя бы узнайте зачем вообще РП нужен))
сидишь потом на митингах с такими СТО и понимаешь, что самому придется решать что делать, а СТО только флагом помахал и никаких решений не принял. стратеги блин, без практики.
ну для примера мой собственный опыт откликов в 25-27 лет такой же как сейчас. я откликался, ждал реакции, приходил пунктуально, в ответ ждал такой же пунктуальности. мне интересная конкретная работа, работодателю интересен конкретно я. если это не так, зачем тратить время обоих.
просто это не про кейс "к концу февраля закрыть кем то из 150 откликов" с одной стороны и "к концу февраля устроится куда то из 150 откликов" с другой стороны.
разные короче миры, иногда они случайно пересекаются, они отталкиваются. но не стоит делать глобальных выводов из этого количества информации.
статья же не конкретно о вашей команде, с ней все понятно, потому что "формула найма" у вас одна и та же. это не есть опыт вообще то. вы просто довели до совершенства навык конкретно вашего найма. но экстраполируете это на другие возрастные группы, где судя по написанному опыта нет (нет разных опытов работы, нет опыта работы с разными возрастами (костяк до 25))
вам не с чем сравнить и вы не понимаете модели поведения эти как вы их называете "неициативных" людей. поэтому люди юзают HR, ну те которые понимаю хотя бы то, что они вот это (найм) не понимают.
но еще раз, у вас ошибка выжившего, понятно что вы будете сопротивляться думать что вы неправы. так работают когнитивные искажения в нашем мозге, увы для нас (людей). хотя может иначе мы были бы скучным видом))
хм, в статье написано что такую роль нанимают первый раз. а я много "инициативных" ПМов повидал))
ну и, если так нанимали всегда и никогда не брали тех кто "не навязывается", то получается и сравнить не с чем будет, логично же? тогда вам все покажется ок и что наняли кого надо и метод работает. ошибка выжившего же обычная.
ну получит человек, что заслужил при таком подходе к найму, просто "инициативу" от которой устанет и заказчик и устал он сам (а потому и нанял, ведь этот чел ему постоянно писал/звонил и скриншоты присыла, вот он его и нанял, чтобы избавится от этой боли. только не понял, что нанял эту боль себе на работу за свои деньги))))
то есть вы гордитесь и считаете правильным, что вы без аналитики и команды наплодили легаси сразу на старте, которое делало не то что надо и выглядело убожищем, выкатили на прод забив даже на препрод, допинали прод костылями хотфиксов, чтобы ну хоть с костылями, но бизнес-процесс работал, назвали это успехом и… пошли делать следующий «пилот».
я же сильно ничего не забыл?))
ммм… да, есть о чем написать на хабре.
но правильнее было сделать таки аналитику месяца за 3, за это время застафить команду и начать делать контур тестирования, а потом за полгода запилить нормальное решение.
но тут увы нет, как правильно сказали, «слабоумия и отваги»))
«Как стать Engineering Manager и не сойти с ума.»
всю тему можно было раскрыть в одной статье, если понимать о чем говорить.
а вы «прекрасно понимаете», пока «в целом область не до конца определилась».
но кто область, а кто вы))
Вместо темы Engineering написали баянный пролог про то как люди становятся тимлидами и джунами руководителей проекта. Т.е. пролог вообще не ввел нас в тематику жизненного цикла ПО, процессов его создания и зачем там Engineering Manager. Он рассказал нам как двумя путями бездарности стали менеджерами.
Произведение будет что надо, а в эпилоге бездарность станет СЕО? )))
вот в FAANG все правильно и ищут, человека который и прошел саму разаботку, и менеджерскую часть Руководил Проектами (а вы очень странно что не знаете кто это).
потому человеку на этой позиции надо обустроить жизнь процессов разработки.
и да, техлид/архитектор/стаф чего то там, это вообще про другое.
а в вашей статье очень поверхносто описаны функции тимлида.
если нормально управлять, то и жира и аджайл и прочая фигня будут помогать, а вот в противном случае на инструменты и методологии сваливается вся вина, что руки кривые или тупой))
а кто сказал что мне стало лучше\легче? это называется - Демагогические приёмы.
я тоже могу так сделать: "вы не рады, вы пытаетесь выпутаться из того что вас .... блаблабла".
видите, я сказал утверждение, сам объявил его истиной и на нем построил дальше предложение. так делать плохо ;)
как я сделал вывод? ну у вас в профиле написано что вы ментор РПшников в ИТ, канал вон свой ведете. пришли со статьей не реальных кейсов, а скорее со "стратегией". А значит хотите задать вектор для юных умов, т.е. джунов.
почему жестко ... потому что вы в первом же предложении в целом, то обидели разработчиков (ни некрасиво это писать от <должность> до <должность> ... вы поставили сразу себя на ранг выше, хотя это разные профессии вообще-то). Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей, тем что на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму.
ну и потому что видимо неделя такая на хабре "стратегов" писать статьи "флаги", прибежали, помахали, думали плюсами закидают? нет, тут иногда и покритиковать могут. вы как говорил один мой друг просто "не в профессии". но увы таких основная масса в мире РП (( вот такая печалька))
имхо, вы видели статьи про докер стратегические?)
ну так уместите стратегию свою в пару абзацев и просто поделитесь опытом в статье на конкретном примере что и как делали. как вы выбрали архитектуру когда разраб джун был, откуда у вас был опыт пул или пуш модель передачи данных сделать, как вы конкретную бизнес цель замапили на фичу системы и почему сделали фичу, а не просто какое-то изменение процесса например, покажите описание какое фиче сделали (сиквенсы, датафлоу и т.д.), как тестеры ваши требования протестировали, кто ПРы принимал и за архитектурой следил, как оценку делали, какой методикой следили за прогрессом, с какой дискретой, что дало, какие решения были приняты на основе метрик ... обычную работу короче РП то опишите, а не это вот все блаблаба.
ох, махнул я коммент, извините если обидело. но на обижены воду возят. а то нам хватает ванильных разработчиков)
от разработчика до руководителя! я был никем и стал важным боссом))))
вы и не менеджер и не аналитик и не архитектор, а так, обычный "манагер".
требованиями и в том числе бизнес, пусть занимаются аналитики, архитекторы пусть занимают на чем и как писать код. а вы поймите что руководитель проектов это другое направление деятельности в отличии от разработки и займитесь своими задачами, хотя бы узнайте зачем вообще РП нужен))
сидишь потом на митингах с такими СТО и понимаешь, что самому придется решать что делать, а СТО только флагом помахал и никаких решений не принял. стратеги блин, без практики.
блаблабла и ничего конкретного. надо быть хорошим и не быть плохим.
ничего, в следующем семестре узнаете, что бывает 3 вид памяти))
ну для примера мой собственный опыт откликов в 25-27 лет такой же как сейчас. я откликался, ждал реакции, приходил пунктуально, в ответ ждал такой же пунктуальности. мне интересная конкретная работа, работодателю интересен конкретно я. если это не так, зачем тратить время обоих.
просто это не про кейс "к концу февраля закрыть кем то из 150 откликов" с одной стороны и "к концу февраля устроится куда то из 150 откликов" с другой стороны.
разные короче миры, иногда они случайно пересекаются, они отталкиваются. но не стоит делать глобальных выводов из этого количества информации.
ек макарек))
статья же не конкретно о вашей команде, с ней все понятно, потому что "формула найма" у вас одна и та же. это не есть опыт вообще то. вы просто довели до совершенства навык конкретно вашего найма. но экстраполируете это на другие возрастные группы, где судя по написанному опыта нет (нет разных опытов работы, нет опыта работы с разными возрастами (костяк до 25))
вам не с чем сравнить и вы не понимаете модели поведения эти как вы их называете "неициативных" людей. поэтому люди юзают HR, ну те которые понимаю хотя бы то, что они вот это (найм) не понимают.
но еще раз, у вас ошибка выжившего, понятно что вы будете сопротивляться думать что вы неправы. так работают когнитивные искажения в нашем мозге, увы для нас (людей). хотя может иначе мы были бы скучным видом))
хм, в статье написано что такую роль нанимают первый раз. а я много "инициативных" ПМов повидал))
ну и, если так нанимали всегда и никогда не брали тех кто "не навязывается", то получается и сравнить не с чем будет, логично же? тогда вам все покажется ок и что наняли кого надо и метод работает. ошибка выжившего же обычная.
ну получит человек, что заслужил при таком подходе к найму, просто "инициативу" от которой устанет и заказчик и устал он сам (а потому и нанял, ведь этот чел ему постоянно писал/звонил и скриншоты присыла, вот он его и нанял, чтобы избавится от этой боли. только не понял, что нанял эту боль себе на работу за свои деньги))))
ну и программист был не совсем настоящий, а 1С ;)
такая система по классификации попадает в автоматизированную, а не автоматическую.
просто вы не прочитали даже это
https://ru.m.wikipedia.org/wiki/Информационная_система
вот вас и троллят)
я же сильно ничего не забыл?))
ммм… да, есть о чем написать на хабре.
но правильнее было сделать таки аналитику месяца за 3, за это время застафить команду и начать делать контур тестирования, а потом за полгода запилить нормальное решение.
но тут увы нет, как правильно сказали, «слабоумия и отваги»))
а в чем для того кто первым уходит, профит то делать благо для тех кто остается?
всю тему можно было раскрыть в одной статье, если понимать о чем говорить.
а вы «прекрасно понимаете», пока «в целом область не до конца определилась».
но кто область, а кто вы))
Вместо темы Engineering написали баянный пролог про то как люди становятся тимлидами и джунами руководителей проекта. Т.е. пролог вообще не ввел нас в тематику жизненного цикла ПО, процессов его создания и зачем там Engineering Manager. Он рассказал нам как двумя путями бездарности стали менеджерами.
Произведение будет что надо, а в эпилоге бездарность станет СЕО? )))
вот в FAANG все правильно и ищут, человека который и прошел саму разаботку, и менеджерскую часть Руководил Проектами (а вы очень странно что не знаете кто это).
потому человеку на этой позиции надо обустроить жизнь процессов разработки.
и да, техлид/архитектор/стаф чего то там, это вообще про другое.
а в вашей статье очень поверхносто описаны функции тимлида.
а причем тут engineering manager и статья про тимлида, ну максимум РПшника?
вы уверены что вообще понимаете кто из них чем занимается?
не, рассказы про Сергея были лучше. и мораль была и красота. теперь осталась одна ванильная мораль.
че то какие то слишком примитивные статьи пошли, а где аллегории всем так полюбившиеся((
Каша из состояний и событий, которые переводят одно состояние в другое, у вас и в коде и голове))
хочу прозрачность, но нет жире))
если нормально управлять, то и жира и аджайл и прочая фигня будут помогать, а вот в противном случае на инструменты и методологии сваливается вся вина, что руки кривые или тупой))