с детства сломана дофаминовая система. Её методично 10 лет уничтожают в школе
Довольно громкое заявление. И уводящая от другой причины. Дофаминовую систему детей сейчас методично уничтожают смартфонами. Школа как раз остается одним из немногих шансов освоить дисциплину обучения. Вы привели пример с обучением игры на гитаре. Попробуйте подумать, в каких условиях дети могут научиться дисциплине? Которую в сознательной жизни начнут применять к изучению гитары, изучению C++ или изучению философии.
стратегическому видению соответствовали вопросы о том, кем человек видит себя через 5 лет;
Это правда. Но можно придумать еще сотню вопросов направленные на то, чтобы выявить стратегическое видение. Придумываю навскидку:
Расскажите, как вы выбирали Вуз
Расскажите, как вы вибираете работодателей
Расскажите, как вы делаете покупки
Проблема с этими вопросами в том, что они требуют от рекрутера услышать речь кандидата, вычленить из нее смысл, обработать его, соотнести с остальными ответами кандидата и после этого сделать оценку насколько кандидат мысли стратегически. А еще сделать аналогичное по другим 10-20 показателям (мы же не только этот аспект оцениваем?)
Мне задавали такой вопрос много раз. Я пробовал разные стратегии ответов. Ни разу разговор не был о стратегическом видение. Ожидания рекрутеров были в получении одного из шаблонных ответов. Поэтому если я попаду на думающего рекрутера и он задаст мне этот шаблонный вопрос, то он получит шаблонный ответ. Cest la vie
Хорошие специалисты нарасхват и получают десяток предложений
По моим наблюдениям, это не так. Нарасхват специалисты, которые умеют хорошо проходить шаблонные интервью. Они натренировались взламывать скрипты рекрутеров и пользуются этим для продвижения по карьере и повышения зп. И это не осуждение, это констатация того, как разработчики подстраиваются под процесс найма.
При этом я знаю много очень хороших, топовых программистов, которые в ужасе от мысли, что им нужно будет выходить на рынок и проходить эти многоуровневые интервью аля-Гугл. Они с удовольствием расскажут о своих проектах и покажут решения. Но кто же их об этом спросит и при каких обстоятельствах?
Дальше вы рассказываете о человеческом подходе в интервью. Рад за вашу компанию, если у вас это действительно так. Но по моим, наблюдениям, подход, который вы описываете практикуют 3 из 100 рекрутеров. А это значит, что любой уважающий себя специалист будет учиться взламывать скрипты рекрутеров, чтобы повысить свои шансы.
Вот для этого авторы и предполагают использовать Монте-Карло. При условии стабильности среды, когда на всех ваших уникальных командах и проектах начинает хоть как то работать закон больших чисел, why not?
В вашем посте содержится хороший рецепт приведения системы в состояние, пригодное для анализа методом Монте-Карло.
Что повлияет на точность прогноза? Стабильность системы.
Именно. Метод будет давать хоть что-то полезное только при условии стабильности наблюдаемого процесса.
Однако, в IT-организациях часто возникают ситуации, в которых невозможно заранее предсказать будущую продуктивность. Вот у вас новая команда. Одному Богу известно, сможет ли она сыграться и выйти на некое плато продуктивности в рамках вверенного ей функционала. Или у вас стабильная команда, но ей передали в ответственность новые подсистемы, после того как на этом участке не справились другие команды. Или команда стабильная, и функционал ее, но внезапно изменилась внешняя среда, невозможно больше пользоваться Jira, Miro, Idea и AWS. В этих ситуациях Монте-Карло не поможет, скорее навредит, создав ложные ожидания.
И такие ситуации возникают в большой IT-организации постоянно. Они влияют на общую стабильность и с ними необходимо работать. В этом суть менеджмента, приводить систему к стабильности каждый день, неделю и месяц. Иначе никакого менеджмента не будет.
Поэтому давайте не впадать в иллюзии и писать такие утверждения:
Чем такие прогнозы отличаются от экспертных прогнозов аналитиков? Они учитывают всю неопределенность, с которой встречалась команда,
Конечно же Монте-Карло не учитывает всей неопределенности. Более того, он не учитывает главной составляющей этой неопределенности, именно той, которую при планировании больших задач мы хотим избежать. Поэтому решить за нас проблемы оценки сложных проектов он не сможет. Хотя инструмент красивый.
Их вопросы всегда были про то, как я буду решать их проблемы.
Боже, где найти такие интервью?)
Недавно собеседовался на лидовую позицию, спрашивал у будущего моего руководителя, какие задачи стоят перед командой сейчас и какие главные проблемы на пути этих задач. Не прямо, но около того. Получил ответ - "Это не публичная информация".
Вы знаете, перечитал ваш пост и не нашел там особой драматичности как в первый раз. Ну да, только с опытом приходит понимание того, что с первого раза конфетка не получится. А молодым инженерам зачастую кажется, что они сразу сделают революционную суперсистему с кучей инноваций.
Понимание приходит с возрастом. Поэтому важно иметь в коллективе опытных инженеров, присматривающих за молодежью. За этим балансом необходимо следить, но это уже тема для другого поста.
Если этот "титаник" еще и "очередной", я бы посоветовал вашему менеджменту от бизнеса и теха сесть и честно разобрать подходы к оценке и запуску проектов. Возможно, их будет ждать очень неприятный сюрприз. А именно, что они вместо реальных оценок и попыток вписаться в эти оценки ( с дальнейшими разборками, почему не вышло и как сделать, чтобы вышло) практикуют wishful thinking с последующими "пускай в следующий раз повезет".
Но этого, конечно, не произойдет пока компания будет расти. Вот когда вы попадете в кризис, возможно и мотивации на изменение появится.
сменились тимлид и проджект. Бизнес считал, что проект нормально работает с жёстким дедлайном в три месяца,
Не выстроен рабочий баланс между тимлидами и бизнесом.
Вангую причины:
Бизнес считает, что лучше знает, сколько длится разработка
Бизнес не верит оценкам тимлидов
Тимлиды "плывут по течению", собирают космолеты на принятом в компании стеке с самого начала, а не предлагают реальные mvp с очень быстрой проверкой гипотез
Тимлиды слишком мягкие, чтобы докладывать бизнесу реальное положение дел
Тимлиды боятся говорить "нет"
В компании нет культуры реального планирования (это когда реально все учатся оценивать, а не делают вид. Это больно и страшно вначале)
А вы уже отработали эту технологию в масштабах своей семьи, коллектива, которым руководите? Вы же имеете опыт управления, раз считаете, что знаете что в управлении работает, а что нет?
Один. Pationtkeeper Собственно, после этого он привязал использованные там принципы разработки к тойотовскому scrumу (а в те времена в Америке молились на японские способы организации производства в автопроме) и начал его пиарить. Пипл схавал.
Игра моего детства.
А что, в наше время профессионализм измеряется только по открытым публикациям? Нет публикаций = не профессионал?
Довольно громкое заявление. И уводящая от другой причины. Дофаминовую систему детей сейчас методично уничтожают смартфонами. Школа как раз остается одним из немногих шансов освоить дисциплину обучения. Вы привели пример с обучением игры на гитаре. Попробуйте подумать, в каких условиях дети могут научиться дисциплине? Которую в сознательной жизни начнут применять к изучению гитары, изучению C++ или изучению философии.
Это правда. Но можно придумать еще сотню вопросов направленные на то, чтобы выявить стратегическое видение. Придумываю навскидку:
Расскажите, как вы выбирали Вуз
Расскажите, как вы вибираете работодателей
Расскажите, как вы делаете покупки
Проблема с этими вопросами в том, что они требуют от рекрутера услышать речь кандидата, вычленить из нее смысл, обработать его, соотнести с остальными ответами кандидата и после этого сделать оценку насколько кандидат мысли стратегически. А еще сделать аналогичное по другим 10-20 показателям (мы же не только этот аспект оцениваем?)
Мне задавали такой вопрос много раз. Я пробовал разные стратегии ответов. Ни разу разговор не был о стратегическом видение. Ожидания рекрутеров были в получении одного из шаблонных ответов. Поэтому если я попаду на думающего рекрутера и он задаст мне этот шаблонный вопрос, то он получит шаблонный ответ. Cest la vie
По моим наблюдениям, это не так. Нарасхват специалисты, которые умеют хорошо проходить шаблонные интервью. Они натренировались взламывать скрипты рекрутеров и пользуются этим для продвижения по карьере и повышения зп. И это не осуждение, это констатация того, как разработчики подстраиваются под процесс найма.
При этом я знаю много очень хороших, топовых программистов, которые в ужасе от мысли, что им нужно будет выходить на рынок и проходить эти многоуровневые интервью аля-Гугл. Они с удовольствием расскажут о своих проектах и покажут решения. Но кто же их об этом спросит и при каких обстоятельствах?
Дальше вы рассказываете о человеческом подходе в интервью. Рад за вашу компанию, если у вас это действительно так. Но по моим, наблюдениям, подход, который вы описываете практикуют 3 из 100 рекрутеров. А это значит, что любой уважающий себя специалист будет учиться взламывать скрипты рекрутеров, чтобы повысить свои шансы.
Ну даже не знаю... может быть я подумал об этом перед тем как делать ставку в 18 долларов (а также в 17,16,15,14,13,12,11,10)?
Вот для этого авторы и предполагают использовать Монте-Карло. При условии стабильности среды, когда на всех ваших уникальных командах и проектах начинает хоть как то работать закон больших чисел, why not?
Как человек, когда то давно применявший Монте-Карло при разработке торговых систем, давайте сразу перейду к сути критики этого метода.
Основная проблема в том, что вероятностные распределения компонентов процесса IT-разработки неизвестны и процесс нестационарен. В этих условиях метод Монте-Карло порождает явление ложной регрессии. Более подробно можно почитать, например, в этой статье
"Кирилюк, Сенько. Исследования соотношений между нестационарными временными рядами на примере производственных функций" )
В вашем посте содержится хороший рецепт приведения системы в состояние, пригодное для анализа методом Монте-Карло.
Именно. Метод будет давать хоть что-то полезное только при условии стабильности наблюдаемого процесса.
Однако, в IT-организациях часто возникают ситуации, в которых невозможно заранее предсказать будущую продуктивность. Вот у вас новая команда. Одному Богу известно, сможет ли она сыграться и выйти на некое плато продуктивности в рамках вверенного ей функционала. Или у вас стабильная команда, но ей передали в ответственность новые подсистемы, после того как на этом участке не справились другие команды. Или команда стабильная, и функционал ее, но внезапно изменилась внешняя среда, невозможно больше пользоваться Jira, Miro, Idea и AWS. В этих ситуациях Монте-Карло не поможет, скорее навредит, создав ложные ожидания.
И такие ситуации возникают в большой IT-организации постоянно. Они влияют на общую стабильность и с ними необходимо работать. В этом суть менеджмента, приводить систему к стабильности каждый день, неделю и месяц. Иначе никакого менеджмента не будет.
Поэтому давайте не впадать в иллюзии и писать такие утверждения:
Конечно же Монте-Карло не учитывает всей неопределенности. Более того, он не учитывает главной составляющей этой неопределенности, именно той, которую при планировании больших задач мы хотим избежать. Поэтому решить за нас проблемы оценки сложных проектов он не сможет. Хотя инструмент красивый.
Боже, где найти такие интервью?)
Недавно собеседовался на лидовую позицию, спрашивал у будущего моего руководителя, какие задачи стоят перед командой сейчас и какие главные проблемы на пути этих задач. Не прямо, но около того. Получил ответ - "Это не публичная информация".
в 10 последних собеседованиях у меня ни разу не спросили про проекты, хотя в резюме указаны довольно вкусные, специально отбирал.
А вы думаете, в гугле и фейсбуке не тоже самое?
Еще отличное упражнение - верстать приложения для сканнера штрихкодов на Windows Mobile.
Мне не нужны рейтинги. Я пожил и там и там, чтобы вполне оценить и составить свое мнение.
А с каких пор это стало некомпрометирующим?
Вы знаете, перечитал ваш пост и не нашел там особой драматичности как в первый раз. Ну да, только с опытом приходит понимание того, что с первого раза конфетка не получится. А молодым инженерам зачастую кажется, что они сразу сделают революционную суперсистему с кучей инноваций.
Понимание приходит с возрастом. Поэтому важно иметь в коллективе опытных инженеров, присматривающих за молодежью. За этим балансом необходимо следить, но это уже тема для другого поста.
Если этот "титаник" еще и "очередной", я бы посоветовал вашему менеджменту от бизнеса и теха сесть и честно разобрать подходы к оценке и запуску проектов. Возможно, их будет ждать очень неприятный сюрприз. А именно, что они вместо реальных оценок и попыток вписаться в эти оценки ( с дальнейшими разборками, почему не вышло и как сделать, чтобы вышло) практикуют wishful thinking с последующими "пускай в следующий раз повезет".
Но этого, конечно, не произойдет пока компания будет расти. Вот когда вы попадете в кризис, возможно и мотивации на изменение появится.
Судя по
Не выстроен рабочий баланс между тимлидами и бизнесом.
Вангую причины:
Бизнес считает, что лучше знает, сколько длится разработка
Бизнес не верит оценкам тимлидов
Тимлиды "плывут по течению", собирают космолеты на принятом в компании стеке с самого начала, а не предлагают реальные mvp с очень быстрой проверкой гипотез
Тимлиды слишком мягкие, чтобы докладывать бизнесу реальное положение дел
Тимлиды боятся говорить "нет"
В компании нет культуры реального планирования (это когда реально все учатся оценивать, а не делают вид. Это больно и страшно вначале)
"Это нормальный режим ограничения технологий двойного назначения"
Что свидетельствует о том, что над либерально-демократическим режимом существует защитная ограничивающая надстройка
Для заинтересовавшийся оставлю линк на хорошую обзорную лекцию Алексея Сафронова
Алексей Сафронов. Шаг в киберкоммунизм: компьютеры и планирование в СССР
А вы уже отработали эту технологию в масштабах своей семьи, коллектива, которым руководите? Вы же имеете опыт управления, раз считаете, что знаете что в управлении работает, а что нет?
Один. Pationtkeeper Собственно, после этого он привязал использованные там принципы разработки к тойотовскому scrumу (а в те времена в Америке молились на японские способы организации производства в автопроме) и начал его пиарить. Пипл схавал.