А почему вы не воспользовались своими же выводами?
До декабря еще далеко, но до 11 числа можно же подождать. Или, если хочется поделиться результатами именно сегодня, выбрать «правильный» час для публикации.
Скажите, каким образом вы парсите резюме кандидата?
Как, скажем, понять что «Пупкин» — это фамилия, а не должность?
Я понимаю, что можно автоматически вытянуть данные с любого сайта, посвященного поиску работы, или из любой соцсети. Но как анализировать документ, написанный почти в свободной форме?
А на самом деле подобные «специалисты сурового профиля» наоборот тянутся к айфону и прочим аппаратам такого рода
А специалисты интеллектуального профиля — напротив: Ищут, где бы помесить грязь ногами или колесами, едут в места где можно похуже перезимовать лето и тяготеют к брутальным штучкам хотя бы во время отпуска.
Купили бы себе такой «телефоноджип»?
Учитывая, что свои первые 3 телефона я утопил, а последний смартфон гордо отблескивает трещиной через весь экран — я теперь знаю, какой подарок попросить у жены на ближайший праздник!
По-настоящему не страшно и функционально, если использовать телефон в презервативе. Только, увы, презервативов без смазки я давно не видел, так что предварительно его приходится мыть.
То что мы бы не сработались — это понятно, говорю безо всяких эмоций.
Я немного о другом:
1) Кажется сомнительным, что можно оценивать и соблюдать сроки по оценкам задач в рамках 20-30%. Кажется сомнительным, что все разработчики не отличаются от лучшего разработчика на 20-30%. В реальности даже простые мелкие задачи могут занять как в 2 раза больше, так и меньше времени.
Мне видится следующие варианты, когда возможен указанный вами результат попадания в 20-30%:
а) разработчики втихаря перекидывают время с одних задач на другие, чтобы в среднем вписаться в оценки (или хотя бы чтобы запаздывание было равномерным по всем задачам).
б) речь идет не об оценки каждой задачи, а об оценке итерации разработки (спринта), которая включает несколько десятков задач и учитывает коэффициент эффективности (velocity)
в) все ваши задачи типичны и их трудоемкость хорошо известна из опыта.
Возможно, я что-то упустил. Проясните пожалуйста, как вам удается достигнуть таких результатов при планировании.
2) Полностью согласен, что самое важно на проекте — команда. Но, в описанном вами же случае, когда от вас ушла команда целиком (и не важно, что они потом почти все вернулись) — команду вы упустили. Прямо как «Федорино Горе». Рассуждения о командном духе, о гордости нехороших разработчиков, о готовности учиться и исправлять ошибки и т.д — это все лишь слова.
А вот факт ухода команды — это конкретный косяк управления. Просто офигезный косяк. Если руководитель является владельцем — он теряет команду, деньги, в худшем случае — проект и клиентов. Если руководитель работает по найму, то как после потери команды он смог сохранить свое место? (Простите, если чем-то вас задеваю, такой цели нет).
Честно, мне понравилась ваша статья. Вы жестко описали свою жесткую позицию и жесткий стиль управления. И (по крайней мере у вас) этот стиль — работает и приносит прибыль. С точки зрения бизнеса — замечательно. Вызывает уважение.
Но с позиции обычного разработчика то, что вы не пугаете людей, а просто их прессуете — понравится не может.
Эталонная оценка, это оценка за сколько конкретную задачу выполнит ваш лучший разработчик. Затем вы определяете что от эталонной оценки может быть отклонение в рамках +-20(30)%.
У вас действительно настолько высока точность оценки? И действительно производительность разработчиков отличается в рамках 20(30)%?
Позвольте вам не поверить.
Если разработчик выпадает за рамки оговоренных пределов, необходимо чтобы команда провела публичное обсуждение проблем, и на очередной ретроспективе публично разобрала случай данного разработчика, и если он виноват, нагрузила его общественными работами, скажем в виде предоставления доклада на тему где он «плавает». При этом доклад готовится строго во вне рабочее время.
публично… виноват… строго во вне рабочее время…
Мне хватает тех пендалей, которые мне выдает моя совесть и профессиональная гордость. Я сам себя живьем съем, мне стыдно перед коллегами, если накосячу. Не хватало еще чтобы меня публично порол менеджмент.
Вы жесткий — ваше право. Ваши разработчики это терпят — это их право. Но, знаете, не хотел бы работать в таких условиях. И подозреваю, что очень многие разработчики — тоже.
Но, все же, как хорошо, что рынок труда большой.
Основное, чему научили меня в универе — это умению на основании неполных данных эффективно решать задачи.
И 10+ летний стаж программирования только закрепил этот навык.
Я бы ратовал не за отказ от «кеша», а за стратегию с 2 целями:
1) Тренировка мозга на принудительном решении тестовых задачек для развития гибкости и скорости мышления. Чтобы в случае, если реальную задачу не удалось нагуглить, мозг не скрипел бы шестеренками, а быстро решил задачу своими силами. Эта цель сильно кореллирует с рекомендациями в статье.
2) Тренировка мозга использования «кеша», а точнее, тренировка умения вычленять основную информацию, быстро ее обрабатывать, дополнять ее недостающими деталями при помощи допущений и находить решение. По аналогии это как быстро пробежаться по полу заросшей тропинке на пересеченной местности.
Вместе эти 2 цели будут способствовать тому, что мозг сможет быстро решать типичные задачи, используя «кеш», а в случае нетипичной сможет сам эффективно найти решение.
Согласен, распределение людей по этажам оказывает удручающее первое впечатление и заставляет нервничать. Сразу ощущаешь, что не «ты едешь», а «тебя везут», отнимая даже иллюзию контроля над ситуацией.
Увы, HR чаще всего выгружают резюме из HH и аналогичных сервисов. По моим наблюдениям, чтобы заставить их использовать «правильно» сверстанное резюме, т.е. заставить отойти от привычного процесса, требуются значительные усилия.
Скажите, какая обратная связь к вам приходит от HR, когда вы показываете им «свою прелесть»? Как это влияет на результативность поиска?
А можно узнать (в порядке повышения эрудиции) стратегию формирования квайнов? Какие-нибудь шаблонные действия и их комбинации, приводящие к решению, как, скажем, в судоку и других головоломках?
Пускай сеошники для эффективного продвижения пользуются тем, чем им удобно, пусть пишут длинные портянки для поисковиков.
Но ведь деньги им не поисковики приносят, а живые люди. Неужели трудно задвинуть портянку под кат и разместить короткое, внятное, заметное описание для каждой модели на один абзац? А также — преимущество конкретно этой модели перед другими одной фразой.
А если еще где-то рядом будет одна фраза об условиях доставки — я ваш. Вернее, мои деньги — ваши.
В целях повышения эрудиции, можно узнать подробнее, как именно они борются с индексированием порнухи, а также что делают с массой жалоб «а вот у вас там порнушка в выдаче»
Еще, кажется, Фейнман говорил, что понять — это значит привыкнуть и научиться пользоваться.
Если все собеседники обладают достаточными знаниями и опытом в обсуждаемых областях науки, то апелляция к «здравом смыслу» и «естественности» — вполне нормальное явление. Потому что для этих собеседников прохождение одного электрона сквозь два отверстия с последующим интерферированием с самим собой — естественно. А, скажем, создание черной дыры внутри Большого адронного коллайдера — чушь, противоречащая здравому смыслу.
Чтобы новая теория получила общественное признание в качестве теории, а не почила на кладбище гипотез, она обязательно должна предсказать ранее неизвестные явления. В противном случае весьма непонятно, зачем консервативному научному обществу эта теория нужна.
У меня нет аккаунта на stackoverflow — я на нем ничего не спрашиваю, я ищу там уже готовые ответы. Зачем зря терять время, если с вероятностью 95% мой вопрос уже был задан ранее? И ничего не отвечаю, т.к. регистрироваться ради того, чтобы пару раз кому-то что-то посоветовать неохота, а писать постоянно — это время, много времени.
У меня нет аккаунта на github: в рабочее время я работаю (ну, с перерывами на Хабр), а в нерабочее трачу время на семью, хобби и т.д.
Да, я не тру гик, не звезда, а всего лишь обычный девелопер, просто делающий свою работу.
Еще забавнее, что для сохранения «видимой» яркости, придется увеличить на 10% фактическую яркость экрана — то есть ~7% увеличить расход энергии.
Значит, в реальности, (офис с лампами дневного света, где освещение на порядок меньше чем а не солнечной лужайке) расход энергии перекроет все полученное от солнечной батарейки.
До декабря еще далеко, но до 11 числа можно же подождать. Или, если хочется поделиться результатами именно сегодня, выбрать «правильный» час для публикации.
Это даже хуже маячка на ноге заключенного. Маячок, по крайней мере, не сует нос в личную жизнь.
Как, скажем, понять что «Пупкин» — это фамилия, а не должность?
Я понимаю, что можно автоматически вытянуть данные с любого сайта, посвященного поиску работы, или из любой соцсети. Но как анализировать документ, написанный почти в свободной форме?
Учитывая, что свои первые 3 телефона я утопил, а последний смартфон гордо отблескивает трещиной через весь экран — я теперь знаю, какой подарок попросить у жены на ближайший праздник!
Я немного о другом:
1) Кажется сомнительным, что можно оценивать и соблюдать сроки по оценкам задач в рамках 20-30%. Кажется сомнительным, что все разработчики не отличаются от лучшего разработчика на 20-30%. В реальности даже простые мелкие задачи могут занять как в 2 раза больше, так и меньше времени.
Мне видится следующие варианты, когда возможен указанный вами результат попадания в 20-30%:
а) разработчики втихаря перекидывают время с одних задач на другие, чтобы в среднем вписаться в оценки (или хотя бы чтобы запаздывание было равномерным по всем задачам).
б) речь идет не об оценки каждой задачи, а об оценке итерации разработки (спринта), которая включает несколько десятков задач и учитывает коэффициент эффективности (velocity)
в) все ваши задачи типичны и их трудоемкость хорошо известна из опыта.
Возможно, я что-то упустил. Проясните пожалуйста, как вам удается достигнуть таких результатов при планировании.
2) Полностью согласен, что самое важно на проекте — команда. Но, в описанном вами же случае, когда от вас ушла команда целиком (и не важно, что они потом почти все вернулись) — команду вы упустили. Прямо как «Федорино Горе». Рассуждения о командном духе, о гордости нехороших разработчиков, о готовности учиться и исправлять ошибки и т.д — это все лишь слова.
А вот факт ухода команды — это конкретный косяк управления. Просто офигезный косяк. Если руководитель является владельцем — он теряет команду, деньги, в худшем случае — проект и клиентов. Если руководитель работает по найму, то как после потери команды он смог сохранить свое место? (Простите, если чем-то вас задеваю, такой цели нет).
Честно, мне понравилась ваша статья. Вы жестко описали свою жесткую позицию и жесткий стиль управления. И (по крайней мере у вас) этот стиль — работает и приносит прибыль. С точки зрения бизнеса — замечательно. Вызывает уважение.
Но с позиции обычного разработчика то, что вы не пугаете людей, а просто их прессуете — понравится не может.
У вас действительно настолько высока точность оценки? И действительно производительность разработчиков отличается в рамках 20(30)%?
Позвольте вам не поверить.
публично… виноват… строго во вне рабочее время…
Мне хватает тех пендалей, которые мне выдает моя совесть и профессиональная гордость. Я сам себя живьем съем, мне стыдно перед коллегами, если накосячу. Не хватало еще чтобы меня публично порол менеджмент.
Вы жесткий — ваше право. Ваши разработчики это терпят — это их право. Но, знаете, не хотел бы работать в таких условиях. И подозреваю, что очень многие разработчики — тоже.
Но, все же, как хорошо, что рынок труда большой.
И 10+ летний стаж программирования только закрепил этот навык.
Я бы ратовал не за отказ от «кеша», а за стратегию с 2 целями:
1) Тренировка мозга на принудительном решении тестовых задачек для развития гибкости и скорости мышления. Чтобы в случае, если реальную задачу не удалось нагуглить, мозг не скрипел бы шестеренками, а быстро решил задачу своими силами. Эта цель сильно кореллирует с рекомендациями в статье.
2) Тренировка мозга использования «кеша», а точнее, тренировка умения вычленять основную информацию, быстро ее обрабатывать, дополнять ее недостающими деталями при помощи допущений и находить решение. По аналогии это как быстро пробежаться по полу заросшей тропинке на пересеченной местности.
Вместе эти 2 цели будут способствовать тому, что мозг сможет быстро решать типичные задачи, используя «кеш», а в случае нетипичной сможет сам эффективно найти решение.
Скажите, какая обратная связь к вам приходит от HR, когда вы показываете им «свою прелесть»? Как это влияет на результативность поиска?
Но ведь деньги им не поисковики приносят, а живые люди. Неужели трудно задвинуть портянку под кат и разместить короткое, внятное, заметное описание для каждой модели на один абзац? А также — преимущество конкретно этой модели перед другими одной фразой.
А если еще где-то рядом будет одна фраза об условиях доставки — я ваш. Вернее, мои деньги — ваши.
Еще, кажется, Фейнман говорил, что понять — это значит привыкнуть и научиться пользоваться.
Если все собеседники обладают достаточными знаниями и опытом в обсуждаемых областях науки, то апелляция к «здравом смыслу» и «естественности» — вполне нормальное явление. Потому что для этих собеседников прохождение одного электрона сквозь два отверстия с последующим интерферированием с самим собой — естественно. А, скажем, создание черной дыры внутри Большого адронного коллайдера — чушь, противоречащая здравому смыслу.
Чтобы новая теория получила общественное признание в качестве теории, а не почила на кладбище гипотез, она обязательно должна предсказать ранее неизвестные явления. В противном случае весьма непонятно, зачем консервативному научному обществу эта теория нужна.
Неправда ваша, лицемер будет лицемерить в любом случае. Даже с незнакомыми.
Я знаю: перестать общаться с такими людьми.
*пошел заводить себе аккаунт
У меня нет аккаунта на stackoverflow — я на нем ничего не спрашиваю, я ищу там уже готовые ответы. Зачем зря терять время, если с вероятностью 95% мой вопрос уже был задан ранее? И ничего не отвечаю, т.к. регистрироваться ради того, чтобы пару раз кому-то что-то посоветовать неохота, а писать постоянно — это время, много времени.
У меня нет аккаунта на github: в рабочее время я работаю (ну, с перерывами на Хабр), а в нерабочее трачу время на семью, хобби и т.д.
Да, я не тру гик, не звезда, а всего лишь обычный девелопер, просто делающий свою работу.
Значит, в реальности, (офис с лампами дневного света, где освещение на порядок меньше чем а не солнечной лужайке) расход энергии перекроет все полученное от солнечной батарейки.
Это у них там они афро-американцы.
А у нас — негры. Нас так в школе учили. И когда мы так говорим — мы никого обидеть не хотим.