58° 31.2885' 0" с.ш. (N), 31° 16.5285' 0" в.г. (E)
радиотехников занимающихся действительно разработками больше чем Сколково,
приезжайте, хотя зп в общем ниже чем в мск, но радиотехники больше ценятся, тк их не хватает
запрос не верный, ищите "радиотехник", в отличие от программистов, радиотехник более широкая профессия, он не имеет право узкоспециализироваться…
нас в городе зп радиотехника выше программиста и вакансий в разы больше…
за жестью менее 0.5мм излучение не фиксируется, склонны думать, что только гамма и бета распады, хранится теперь в свинцовом ящике, спасибо за пояснение =) стало спокойнее =)
о! вовремя вы!
хотел сразу спросить, маленькая антропогенная штуковина (выглядит как кусочек металла) 5х3мм, даёт такие данные
Много паники со стороны датчика внутри
насколько вообще опасны такие вещи (я так понял что-то вроде из датчика дыма извлекли)
и насколько можно доверять таким приборам?
Ведь нашли её вот буквально на улице, явно она не должна быть опасной…
ps: естественный фон 16мкР/ч
я цитирую автора:
«Надо быть уверенным, что Вы вообще хотите контролировать продуктивность каждого конкретного человека. Мы от этого сознательно отказались — мы следим за результатами команд»
Статья посвящена удаленной работе отдельных сотрудников, а не удаленной работе команд (читай обособленных подразделений), сложности в организации работы возникают при работе с отдельными разработчиками как таковыми, а у автора нет опыта организации работы отдельных разработчиков, так как «мы следим за результатами команд»…
это я, конечно, утрирую, как инженер — я за свободный график работы и удаленную работу, а вот как работодатель, я вижу сложности организации, которые можно решить только за счёт большого количества свободных ресурсов (читай денег и разработчиков) и резервирования рисков.
они собираются, и с этим мне проще, так как все работают в одном городе,
но потом приходится с каждым общаться в отдельности и повторять
неоднократно цель и задачи проекта (не смотря на то, что они изложены в ТЗ)
мотивировать на результат и сроки.
В офисе мы это обсуждаем регулярно, хотя бы за кофе и слышат все, а с теми,
кто работает удалённо дополнительные обсуждения приходится проводить дополнительно.
При этом я заметил, что те части задач, которые сложнее всего выполнить у разработчиков
выпадают в раздел — «потом». И очень сложно отследить, работает ли он над решением этой задачи или нет… Даже лично увидеть какие части задачи решает инженер очень сложно.
Это вопрос консенсуса, на своём опыте я могу сказать, что максимально допустимое соотношение это 70%(офис) на 30%(удаленно), при перекосе есть риск самообмана в выполнении работы.
ps: опять же, если есть возможность каждую неделю выдавать инженеру отдельное ЧТЗ размером в два листа и потом самостоятельно собирать весь проект из кусочков — то да, такое работает… Но это почти фриланс…
ээээ…
у вас удалённо работает команда(ы)?
это вообще другой уровень — это то же самое,
что поручить выполнение работы другой фирме
или разбить между несколькими организациями — нормальная практика.
Если задачи сильно дробить, то это большая нагрузка на руководителя…
В идеале — ты поручаешь выполнение работу по техническому заданию — на выходе получаешь результат. Если задача относительно большая делишь её на частные технические задания.
У меня получается следующим образом: удалёнщик может с высокой вероятностью выполнить ЧТЗ, изложение которого помещается на одном-двух листах А4 ворда, с временем выполнения не более 1 месяца.
а инженер, который работает рядом со мной, может выполнить всё ТЗ в 30 страниц без разбивки на ЧТЗ за время выполнения проекта 6-9 месяцев без разжёвывания по кусочкам.
Опять же это не относится напрямую к софту, а к более сложному: аппаратно-программному проекту.
ps: я работаю и с удалёнщиками, и с фрилансерами, а так же исправлял косяки других групп, которые работали удаленно, по этому я знаю о чем говорю.
построение работы на удалёнке возможно только когда финансирование многократно превышает потребности, а времени заложено в выполнение в проект больше чем нужно. В режиме нормальных сроков и с ограниченным финансированием удаленщики могут (а могут и не) подвести, съесть время и часть ресурсов.
если штатный сваливает по причине "не смог" это значит ему руководитель поручил выполнение задачи, которую он не в состоянии решить, при этом штатный всем своим внешним видом сообщает, что есть проблема или руководитель сам видит (есть огромная визуальная разница между счастливым разработчиком, у которого все получается, и разработчиком с хвостами), а удаленщика контролировать сложно, а самое главное, что с ним сделать, если он не справился или не хватило компетенции?
нет, не путаю
в разработке РЭА так же возможна удалёнка, но обычно это кошмар для руководителя…
да — это решается разного рода системами управления проектами, но финальная отладка и поддержка изделий в удалёнке очень затратная, при этом постоянно наблюдаю, что часто разработчику на удалёнке, когда у него «не получилось» или ошибка была совершена более года назад на этапе проектирования, проще уволиться с работы и «бросить» проект, такие проекты потом попадали к нам…
Для руководителя удалёнка, в отличие от фриланса, несёт большие риски, так как удаленщик получает зарплату в течении всего проекта и, когда сваливает по причине невыполнения (зашёл в тупик или ошибся, или не знает как завершить свою задачу) работы, то крадёт не только время (что более важно), но бюджет проекта.
Фриланс в этом отношении выгоден тем, что оплата происходит по факту выполненной работы, что очень мотивирует разработчика, для руководителя, если он хочет сформировать постоянную команду фрилансеров — нужно формировать пакет задач в непрерывном режиме, таким образом фрилансер может почти стать удаленщиком, но при этом быть более эффективным и мотивированным для команды
Это возможно только не с материальными разработками, когда маржинальность покрывает низкую эффективность работы и риски не выполнения задачи удаленщиком. Для, например, в разработке электроники у руководителя удаленка это кошмар, так как цикл разработки длительный. А еще все время тратится на многократное повторение задачи каждому в отдельности, вместо общего совещания.
Так что удаленка только при наличии большого кол-ва средств, низких рисках и нерегулярных задачах.
ps: нашей команде часто передавали проекты заваленные по срокам командами на удаленке с ошибками на этапе проектирования.
мы решали эту проблему установкой в начале программы цикла (задержка) до переопределения ног и вообще конфигурации проца, что бы была возможность остановить проц и перепрошить…
не знали про дефайн…
доброго дня =)
это чисто удача, что нашёлся автор кода «Властелина колец»
«J.R.R. Tolkien's The Lord of the Rings, Vol. I 1989/1990 „ www.old-games.ru/game/1666.html
собственно игра уникальна тем, что фактически не поддаётся локализации из-за
“особенного стиля» у разработчиков =) (того самого само-модифицирующегося кода, скриптового языка и «виртуальной» машины) =)
ps: оставлю комментарий, в первую очередь, что бы другие, кто будет интересоваться данной игрой, мог найти этот интересный материал. =)
pss: изучу предыдущие части — напишу в личку, собственно очень интересует разбор ресурсов игры The Lord of the Rings
с интересом наблюдал ВКД онлайн — выглядело интереснее многих фильмов,
само ВКД показало две вещи:
1. сложность выполнения ВКД там, где нет креплений
фиксация космонавтов была затруднена, один вообще не был зафиксирован,
отсюда сложности при выполнении казалось бы простых операций.
2. что некоторые вещи, которые кажутся относительно простыми и даже проведены тренировки на Земле, оказываются намного сложнее и «грязнее» для воплощения в космосе.
из плюсов вижу то, что это достаточно редкий опыт ремонта на орбите, когда много не известных и требуется принимать решения по ситуации
это что бы емкость в битах от емкости в фарадах не спутать ;)
работаем сейчас с ПЗС — та же проблема только в профиль: огромная емкость выводов, которые подключаются ко всем элементам строки/столбца, десятки нанофарад, для их переключения на частоте 20МГц требуются ватты энергии ) по этому в такой схеме будут проблемы с быстродействием и энергопотреблением)
Я сужу так же по детям, они не умеют фантазировать, они привыкли, что все планы четкие и даже акцента в кадре нет.
Мне более интересно смотреть фильм со сложной режисерской работой, где фокусировкой формируется направление взгляда зрителя. Опять же для некоторых панорамных планов нужна максимальная резкость, но в целом, если нет проблемы с воспроизводящим оборудование — разрешения текущего достаточно. У меня друг проверяет качество настройки аппаратуры в кино по звездам, так вот возможности воспроизводящей аппаратуры в кино далеки от даже fullhd.
Интересно, какого размера и качества оптика нужна, что бы воспроизвести 8к в кинотеатре? -)
одобрям-с)
ps: из осциллов не плох MSO2302A-S, жабу душили, но взяли
радиотехников занимающихся действительно разработками больше чем Сколково,
приезжайте, хотя зп в общем ниже чем в мск, но радиотехники больше ценятся, тк их не хватает
запрос не верный, ищите "радиотехник", в отличие от программистов, радиотехник более широкая профессия, он не имеет право узкоспециализироваться…
нас в городе зп радиотехника выше программиста и вакансий в разы больше…
хотел сразу спросить, маленькая антропогенная штуковина (выглядит как кусочек металла) 5х3мм, даёт такие данные
насколько вообще опасны такие вещи (я так понял что-то вроде из датчика дыма извлекли)
и насколько можно доверять таким приборам?
Ведь нашли её вот буквально на улице, явно она не должна быть опасной…
ps: естественный фон 16мкР/ч
а как отклеивали?)
«Надо быть уверенным, что Вы вообще хотите контролировать продуктивность каждого конкретного человека. Мы от этого сознательно отказались — мы следим за результатами команд»
Статья посвящена удаленной работе отдельных сотрудников, а не удаленной работе команд (читай обособленных подразделений), сложности в организации работы возникают при работе с отдельными разработчиками как таковыми, а у автора нет опыта организации работы отдельных разработчиков, так как «мы следим за результатами команд»…
это я, конечно, утрирую, как инженер — я за свободный график работы и удаленную работу, а вот как работодатель, я вижу сложности организации, которые можно решить только за счёт большого количества свободных ресурсов (читай денег и разработчиков) и резервирования рисков.
но потом приходится с каждым общаться в отдельности и повторять
неоднократно цель и задачи проекта (не смотря на то, что они изложены в ТЗ)
мотивировать на результат и сроки.
В офисе мы это обсуждаем регулярно, хотя бы за кофе и слышат все, а с теми,
кто работает удалённо дополнительные обсуждения приходится проводить дополнительно.
При этом я заметил, что те части задач, которые сложнее всего выполнить у разработчиков
выпадают в раздел — «потом». И очень сложно отследить, работает ли он над решением этой задачи или нет… Даже лично увидеть какие части задачи решает инженер очень сложно.
Это вопрос консенсуса, на своём опыте я могу сказать, что максимально допустимое соотношение это 70%(офис) на 30%(удаленно), при перекосе есть риск самообмана в выполнении работы.
ps: опять же, если есть возможность каждую неделю выдавать инженеру отдельное ЧТЗ размером в два листа и потом самостоятельно собирать весь проект из кусочков — то да, такое работает… Но это почти фриланс…
у вас удалённо работает команда(ы)?
это вообще другой уровень — это то же самое,
что поручить выполнение работы другой фирме
или разбить между несколькими организациями — нормальная практика.
В идеале — ты поручаешь выполнение работу по техническому заданию — на выходе получаешь результат. Если задача относительно большая делишь её на частные технические задания.
У меня получается следующим образом: удалёнщик может с высокой вероятностью выполнить ЧТЗ, изложение которого помещается на одном-двух листах А4 ворда, с временем выполнения не более 1 месяца.
а инженер, который работает рядом со мной, может выполнить всё ТЗ в 30 страниц без разбивки на ЧТЗ за время выполнения проекта 6-9 месяцев без разжёвывания по кусочкам.
Опять же это не относится напрямую к софту, а к более сложному: аппаратно-программному проекту.
ps: я работаю и с удалёнщиками, и с фрилансерами, а так же исправлял косяки других групп, которые работали удаленно, по этому я знаю о чем говорю.
построение работы на удалёнке возможно только когда финансирование многократно превышает потребности, а времени заложено в выполнение в проект больше чем нужно. В режиме нормальных сроков и с ограниченным финансированием удаленщики могут (а могут и не) подвести, съесть время и часть ресурсов.
если штатный сваливает по причине "не смог" это значит ему руководитель поручил выполнение задачи, которую он не в состоянии решить, при этом штатный всем своим внешним видом сообщает, что есть проблема или руководитель сам видит (есть огромная визуальная разница между счастливым разработчиком, у которого все получается, и разработчиком с хвостами), а удаленщика контролировать сложно, а самое главное, что с ним сделать, если он не справился или не хватило компетенции?
в разработке РЭА так же возможна удалёнка, но обычно это кошмар для руководителя…
да — это решается разного рода системами управления проектами, но финальная отладка и поддержка изделий в удалёнке очень затратная, при этом постоянно наблюдаю, что часто разработчику на удалёнке, когда у него «не получилось» или ошибка была совершена более года назад на этапе проектирования, проще уволиться с работы и «бросить» проект, такие проекты потом попадали к нам…
Для руководителя удалёнка, в отличие от фриланса, несёт большие риски, так как удаленщик получает зарплату в течении всего проекта и, когда сваливает по причине невыполнения (зашёл в тупик или ошибся, или не знает как завершить свою задачу) работы, то крадёт не только время (что более важно), но бюджет проекта.
Фриланс в этом отношении выгоден тем, что оплата происходит по факту выполненной работы, что очень мотивирует разработчика, для руководителя, если он хочет сформировать постоянную команду фрилансеров — нужно формировать пакет задач в непрерывном режиме, таким образом фрилансер может почти стать удаленщиком, но при этом быть более эффективным и мотивированным для команды
Это возможно только не с материальными разработками, когда маржинальность покрывает низкую эффективность работы и риски не выполнения задачи удаленщиком. Для, например, в разработке электроники у руководителя удаленка это кошмар, так как цикл разработки длительный. А еще все время тратится на многократное повторение задачи каждому в отдельности, вместо общего совещания.
Так что удаленка только при наличии большого кол-ва средств, низких рисках и нерегулярных задачах.
ps: нашей команде часто передавали проекты заваленные по срокам командами на удаленке с ошибками на этапе проектирования.
термовакуумные испытания держит…
не знали про дефайн…
это чисто удача, что нашёлся автор кода «Властелина колец»
«J.R.R. Tolkien's The Lord of the Rings, Vol. I 1989/1990 „
www.old-games.ru/game/1666.html
собственно игра уникальна тем, что фактически не поддаётся локализации из-за
“особенного стиля» у разработчиков =) (того самого само-модифицирующегося кода, скриптового языка и «виртуальной» машины) =)
ps: оставлю комментарий, в первую очередь, что бы другие, кто будет интересоваться данной игрой, мог найти этот интересный материал. =)
pss: изучу предыдущие части — напишу в личку, собственно очень интересует разбор ресурсов игры The Lord of the Rings
Ждем продолжения ;)
само ВКД показало две вещи:
1. сложность выполнения ВКД там, где нет креплений
фиксация космонавтов была затруднена, один вообще не был зафиксирован,
отсюда сложности при выполнении казалось бы простых операций.
2. что некоторые вещи, которые кажутся относительно простыми и даже проведены тренировки на Земле, оказываются намного сложнее и «грязнее» для воплощения в космосе.
из плюсов вижу то, что это достаточно редкий опыт ремонта на орбите, когда много не известных и требуется принимать решения по ситуации
это что бы емкость в битах от емкости в фарадах не спутать ;)
работаем сейчас с ПЗС — та же проблема только в профиль: огромная емкость выводов, которые подключаются ко всем элементам строки/столбца, десятки нанофарад, для их переключения на частоте 20МГц требуются ватты энергии ) по этому в такой схеме будут проблемы с быстродействием и энергопотреблением)
Я сужу так же по детям, они не умеют фантазировать, они привыкли, что все планы четкие и даже акцента в кадре нет.
Мне более интересно смотреть фильм со сложной режисерской работой, где фокусировкой формируется направление взгляда зрителя. Опять же для некоторых панорамных планов нужна максимальная резкость, но в целом, если нет проблемы с воспроизводящим оборудование — разрешения текущего достаточно. У меня друг проверяет качество настройки аппаратуры в кино по звездам, так вот возможности воспроизводящей аппаратуры в кино далеки от даже fullhd.
Интересно, какого размера и качества оптика нужна, что бы воспроизвести 8к в кинотеатре? -)