Добрый день. В разделе с примером про «Рекламное агенство» вы пишете, что можно хранить данные на зарубежных облаках если первоначальный сбор выполняется на территории РФ. В разъяснениях Минцфиры digital.gov.ru/ru/personaldata/#1438174494141 в разделе «Трансграничность» (5-й вопрос) написано, что понятия «первичный сбор» не существует и, как следствие, сбор, обработка и хранение должны выполняться в базах данных, расположенных на территории РФ. Получается, что передавать за границу можно только обезличенные данные, либо передавать, обрабатывать, но не хранить (приложение в зарубежном облаке, СУБД с данным в РФ). Можете поделиться ссылкой на норму, которая позволяет утверждать, что допускается передача ПДн для хранения и обработки в зарубежных облаках которая подтверждает валидность вашего примера с агентством?
Я пару месяцев назад заказывал себе yubikey 4 nano в одном крупном российской интернет магазине, который торгует лицензиями на ПО (думаю, найдете). Все привезли. Правда, порадовал комплект доставки – чек и приклеенный к нему скотчем токен :)
6. Если продолжить вашу аналогию, то нужно писать код без ошибок, нужно на тестировании не пропускать ошибки, нужно писать только идеальные постановки на разработку и т.д. Работает только в идеальном вакууме. Если серьезно, что за 2-3 часа собеседований не всегда можно определить в достаточной мере уровень адекватности и квалификации человека, хотя, обычно бывает достаточно. Для всего остального существует испытательный срок.
11. Никто не обещал откровений. Автор собрал «лучшие практики» с его точки зрения. То, что в них вошли тривиальные вещи вполне нормально. Больше скажу. Если для вас это тривиально – вы молодец!
Допускаю, что вы могли читать с автором оригинальной статьи одни и те же книги…
Или, второй вариант, который нельзя не исключить, что идеи уроков пришли в голову автору просто на основе его опыта и его наблюдений. Если допустить, что выводы, которые сделал автор исходя из своего опыта, логичные и разумные, то другой человек, обладающий разумом и логикой, находясь в тех же условиях, сделает аналогичные выводы. Примером может служить история, когда в разных концах мира ученые делали схожие открытия практически одновременно.
Каждый из вас (@naething, sshmakov) прав в рамках своего контекста. Пример, приведенный naething, на мой взгляд, подходит для контекста, когда речь идет про тимлида небольшой команды в 5-6 человек. Когда можно успевать и код писать, и задачи раздавать и на митингах уровня +1 участвовать пару раз в неделю. Если же мы увеличиваем размер команды до 10 человек и далее, то одному тимлиду становится сложно держать в фокусе, все, что я описал выше. И, если тимлид хочет сохранять техническую компетенцию, то возможны, как мне кажется, такие варианты: А) тимлид начинает работать 24 часа в сутки и быстро перегорает Б) тимлид повышает уровень абстракции по задачам, над которыми работает и переходит на уровень тимлида +1, команде при этом придется повысить эффективность и распределить между собой задачи тимлида В) в иерархию вводится еще один тимлид уровня -1 и часть задач с нашего тимлида уходят туда Г) увеличиваются сроки выполнения по каждой задаче.
Вот! Именно этого комментария я ждал. Это тот самый «контекст», от которого сильно зависит применимость или неприменимость тех или иных правил из списка уроков. Я абсолютно с вами согласен, что одним из критериев применимости этих правил является размер команды. К сожалению, я не нашел в открытых источниках информацию о размерах технической команды RethinkDB, но думаю, что это была команда больше 5-6 разработчиков.
Под конвейером в разработке я понимаю не монотонный типовой труд отдельного специалиста, а некоторый процесс, который для каждого отдельного сотрудника является интеллектуальной творческой активностью (постарался суть вашей мысли передать), но на более высоком уровне абстракции представляет собой механизм по выдаче результата (я сейчас не говорю про эффективность) для зарабатывания денег.
Команда общая. Уроки выше только для технарей. Так решил автор «уроков».
Как мне кажется, эти уроки применимы, отчасти и для команды бизнес-аналитиков, бизнес-архитекторов и пр., но чтобы об этом заявлять, надо на каждый пункт посмотреть под призмой «бизнес» команды.
Если научные работники, физики (на самом деле, здесь можно перечислять профессии и дальше) и т.д. непосредственно заняты в работе по созданию некоторой информационной системы или программного продукта (пишут алгоритмы, код, создают железо, на котором все это будет работать), то они тоже входят в это понятие в том его значении, которое имелось в виду в «уроках». Хотя, в общем виде, на мой взгляд, они больше относятся к другой важной группе людей, которые принимают участие в создании систем и ПО: консультантов, бизнес аналитиков, бизнес архитекторов и др. – людей, которые задают функциональные характеристики продукта.
1) Я спорил не с фразой про контроль, а с тем, что «Процесс разработки – не конвейер». С вашими предложениями абсолютно согласен. Code review и наличие в команде более опытных товарищей, которые помогают молодым специалистам – это важные критерии зрелости проекта и уровня команды соответственно.
2) Думаю, что автор уроков имел в виду скорее то, что не все сотрудники осознают важность роли руководителя в команде, особенно тех руководителей, которые стоят по вертикали на уровне выше, чем +1 от сотрудника. Отсюда возникает ощущение, что все делают они, а там «наверху» непонятно, чем занимаются, но приходят и что-то требуют. При этом, согласен с вами, зачастую этому способствуют и те сценарии поведения руководителей, о которых вы написали.
Под «технарями» я понимаю людей, которые участвуют в работе с программным обеспечением и/или информационными системами на всех этапах от создания до эксплуатации, и всего, что с этим связано. Например, к «технарям» я отношу инженеров, разработчиков, архитекторов, системных аналитиков, системных администраторов, специалистов по информационной безопасности, тестировщиков и т.д.
Думаю, что уровень эмоциональности, который можно позволить себе в резюме, зависит от того, в какую компанию и на какую позицию рассчитывает попасть кандидат. Поэтому, все должно быть в меру и к месту. Не стоит в резюме рассказывать историю о том, что основным вашим принципом на предыдущей работе был «Раз-два и в продакшн», потому что вы считаете, что быстрый TTM — это единственный критерий успеха продукта. Лучше рассказ историй про успехи, неудачи и вашу жизненную позицию оставить на очную встречу, а резюме составить в форме сухого формального документа. Это если про формат.
Из общих рекоментаций, чтобы не было двояких толкований могу посоветовать следуюшее.
Первое — для публикации резюме зведите отдельный почтовый ящик вида имя.фамилия@суперпочта.где-угодно, так как часто встречаются резюме с контактами вида kulxakep14@что-то-там.где-то-там. Для студента это нормально, а для взрослого дяди 30+ это выглядит уже немного странно.
Второе. Если у вас есть сайт-визитка, блог, профиль на гитхабе или посты на Хабре, то лучше их указать. Если такие есть, я всегда иду и смотрю, что там — это всегда плюс кандидату за открытость.
Третий момент, как я написал выше, резюме — это не сочинение и в общем виде оно просто должно содержать набор ключевых слов (тегов), которые идентифицируют вас через ваш опыт работы (компании, проекты), уровень квалификации (технологии, сертификаты, если есть, курсы). При большом потоке резюме просто нет времени читать про коммуникабельность, знание английского со словарем и прочие вещи. Я трачу на просмотр одного резюме в среднем секунд 20, просматривая «теги», чтобы понять, звать человека на первую встречу или нет. Все истории, если они есть в резюме, я просто пропускаю или «дочитываю» уже на первой встрече.
Пока до конца ваш комментарий не дочитал, сильно удивлялся, где вы это все нашли про нас? :)
Давайте попытаюсь прокомментировать, основываясь на том, как собеседование проходит у нас в отдел.
1. Проверка технических задач и тестов, которые написал кандидат, проходят в формате диалога с нашим инженером. Естественное, вопросы сочиняются не на ходу, все готовится заранее. Технические вопросы HR у нас не задают и не проверяют ответы на них. Даже на тесты. Технические интервью всегда проводит технический специалист. По времени это занимает обычно до 2 часов. За это время, как правило, уже понятно, подходит с технической точки зрения нам человек или нет и можно ли его рекомендовать на финальное интервью. На финале технические вопросы я тоже задаю, но уже без тестов. Беседа проходит в формате обычного диалога. Мне, кстати, тоже вопросы можно задавать :)
2. Вопрос встраивания в коллектив не такой простой, как вам кажется. Возможно, вы можете сработаться с любой командой, но таких людей, как вы, не много. В любом случае, “психологические” показатели всегда идут как дополнение к техническим и исключительно для информации руководителю, который принимает окончательное решение. Если первое техническое интервью кандидат подходит – он попадет на финал, даже, если “не понравился” HR-у.
3. Статистику собираем. Не далее, как на прошлой неделе смотрел актуальный отчет по своим вакансиям. В тексте интервью вы можете найти информацию о том, что мы активно нанимаем и студентов тоже. На текущий момент только в нашем отделе 6 студентов, которые совмещают работу и учебу.
Не очень понял вашу мысль. Вы предлагаете нанять специального отдельного разработчика, чтобы он фултайм сидел на hh.ru, искал резюме, обзванивал людей и собеседования проводил вместо написания кода? Поясните, пожалуйста.
Интересы… :) Попросили фотку для интервью. Нашел первую попавшуюся, из того, что было нормального. Оказалась фотка из отпуска. Ездили пару лет назад с женой в Европу: Париж, Люксембург, Вена.
Вы верно подметили, что она требуется редко. Я бы сказал, что можно со 100% уверенностью определить, когда она требуется – когда промышленная система ночью лежит и устранить причину команда SRE не может, так как нужен экстренный хотфикс кода или корректировка структуры бизнес-данных. Просто так такие ошибки на проме, как правило, не возникают.
Основной кейс, когда что-то подобное можно в теории ожидать – первые дни после выпуска новой версии системы в прод. Здесь версия, которая до этого прошла все этапы тестирования, в том числе нагрузочное, может дать сбой на каком-нибудь особенном наборе промышленных данных, которые не было возможности сгенерировать или предусмотреть заранее. Для этих случаев в помощь команде SRE есть дежурный разработчик, который может “нырнуть” в код и помочь разобраться с проблемой. Но, такой режим работы, когда тебе могут ночью позвонить для консультаций или разбора проблемы – это режим работы специальных “дежурных групп”, в которые входят добровольцы, которые получают за это отдельную плату.
На отпусках при правильной организации это никак не сказывается. Всегда есть больше одного человека, которые могут разобраться в ситуации. В отпуск они ходят по-очереди – за этим следит лид команды и административный руководитель.
11. Никто не обещал откровений. Автор собрал «лучшие практики» с его точки зрения. То, что в них вошли тривиальные вещи вполне нормально. Больше скажу. Если для вас это тривиально – вы молодец!
Или, второй вариант, который нельзя не исключить, что идеи уроков пришли в голову автору просто на основе его опыта и его наблюдений. Если допустить, что выводы, которые сделал автор исходя из своего опыта, логичные и разумные, то другой человек, обладающий разумом и логикой, находясь в тех же условиях, сделает аналогичные выводы. Примером может служить история, когда в разных концах мира ученые делали схожие открытия практически одновременно.
Как мне кажется, эти уроки применимы, отчасти и для команды бизнес-аналитиков, бизнес-архитекторов и пр., но чтобы об этом заявлять, надо на каждый пункт посмотреть под призмой «бизнес» команды.
2) Думаю, что автор уроков имел в виду скорее то, что не все сотрудники осознают важность роли руководителя в команде, особенно тех руководителей, которые стоят по вертикали на уровне выше, чем +1 от сотрудника. Отсюда возникает ощущение, что все делают они, а там «наверху» непонятно, чем занимаются, но приходят и что-то требуют. При этом, согласен с вами, зачастую этому способствуют и те сценарии поведения руководителей, о которых вы написали.
Думаю, что уровень эмоциональности, который можно позволить себе в резюме, зависит от того, в какую компанию и на какую позицию рассчитывает попасть кандидат. Поэтому, все должно быть в меру и к месту. Не стоит в резюме рассказывать историю о том, что основным вашим принципом на предыдущей работе был «Раз-два и в продакшн», потому что вы считаете, что быстрый TTM — это единственный критерий успеха продукта. Лучше рассказ историй про успехи, неудачи и вашу жизненную позицию оставить на очную встречу, а резюме составить в форме сухого формального документа. Это если про формат.
Из общих рекоментаций, чтобы не было двояких толкований могу посоветовать следуюшее.
Первое — для публикации резюме зведите отдельный почтовый ящик вида имя.фамилия@суперпочта.где-угодно, так как часто встречаются резюме с контактами вида kulxakep14@что-то-там.где-то-там. Для студента это нормально, а для взрослого дяди 30+ это выглядит уже немного странно.
Второе. Если у вас есть сайт-визитка, блог, профиль на гитхабе или посты на Хабре, то лучше их указать. Если такие есть, я всегда иду и смотрю, что там — это всегда плюс кандидату за открытость.
Третий момент, как я написал выше, резюме — это не сочинение и в общем виде оно просто должно содержать набор ключевых слов (тегов), которые идентифицируют вас через ваш опыт работы (компании, проекты), уровень квалификации (технологии, сертификаты, если есть, курсы). При большом потоке резюме просто нет времени читать про коммуникабельность, знание английского со словарем и прочие вещи. Я трачу на просмотр одного резюме в среднем секунд 20, просматривая «теги», чтобы понять, звать человека на первую встречу или нет. Все истории, если они есть в резюме, я просто пропускаю или «дочитываю» уже на первой встрече.
Давайте попытаюсь прокомментировать, основываясь на том, как собеседование проходит у нас в отдел.
1. Проверка технических задач и тестов, которые написал кандидат, проходят в формате диалога с нашим инженером. Естественное, вопросы сочиняются не на ходу, все готовится заранее. Технические вопросы HR у нас не задают и не проверяют ответы на них. Даже на тесты. Технические интервью всегда проводит технический специалист. По времени это занимает обычно до 2 часов. За это время, как правило, уже понятно, подходит с технической точки зрения нам человек или нет и можно ли его рекомендовать на финальное интервью. На финале технические вопросы я тоже задаю, но уже без тестов. Беседа проходит в формате обычного диалога. Мне, кстати, тоже вопросы можно задавать :)
2. Вопрос встраивания в коллектив не такой простой, как вам кажется. Возможно, вы можете сработаться с любой командой, но таких людей, как вы, не много. В любом случае, “психологические” показатели всегда идут как дополнение к техническим и исключительно для информации руководителю, который принимает окончательное решение. Если первое техническое интервью кандидат подходит – он попадет на финал, даже, если “не понравился” HR-у.
3. Статистику собираем. Не далее, как на прошлой неделе смотрел актуальный отчет по своим вакансиям. В тексте интервью вы можете найти информацию о том, что мы активно нанимаем и студентов тоже. На текущий момент только в нашем отделе 6 студентов, которые совмещают работу и учебу.
Основной кейс, когда что-то подобное можно в теории ожидать – первые дни после выпуска новой версии системы в прод. Здесь версия, которая до этого прошла все этапы тестирования, в том числе нагрузочное, может дать сбой на каком-нибудь особенном наборе промышленных данных, которые не было возможности сгенерировать или предусмотреть заранее. Для этих случаев в помощь команде SRE есть дежурный разработчик, который может “нырнуть” в код и помочь разобраться с проблемой. Но, такой режим работы, когда тебе могут ночью позвонить для консультаций или разбора проблемы – это режим работы специальных “дежурных групп”, в которые входят добровольцы, которые получают за это отдельную плату.
На отпусках при правильной организации это никак не сказывается. Всегда есть больше одного человека, которые могут разобраться в ситуации. В отпуск они ходят по-очереди – за этим следит лид команды и административный руководитель.