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