Вопросы о внутренних заметках о процессе Scrum во время собеседования

Ответ Моники затрагивает вопрос о понимании того, что может быть конфиденциальным и как спросить, но я хотел бы предложить, чтобы вы могли получить полезную информацию, не прося показать документ, который может или не может даже существовать, не говоря уже о том, чтобы иметь дело с его возможной конфиденциальностью. статус.

Вы указываете, что одна из причин желания увидеть эту информацию заключается в том, что, по вашему опыту, артефакт ретроспективы спринта может показать, «что разработчики любят и ненавидят в последние несколько недель». Но не могли бы вы также просто попросить на собеседовании краткое изложение некоторых общих/частых вещей, которые команда разработчиков хочет: а) прекратить делать, б) начать делать или в) продолжать делать хорошо?

Для меня как менеджера по найму вопрос такого типа (а не просто «могу ли я увидеть ваши ретроспективные артефакты») означал бы, что вы уважаете потенциально конфиденциальную внутреннюю информацию (опять же, ответ Моники также описывает способ сделать это), понимать типичные цели ретроспективы спринта и комфортно вести беседу, чтобы получить и обсудить информацию, а не читать и интерпретировать что-то самостоятельно. Последнее может не иметь значения для вас или для них, но это то, что я ценю, и я не думаю, что я такой уж странный: возможность запрашивать информацию и вести непрерывный динамичный/органический разговор об этом, а не просто читать что-то и говоря "хорошо, спасибо" или что-то еще.

Еще одна причина, по которой запрашивается сводка или интерпретация общих ретроспективных результатов, а не артефакт, заключается в том, что не все группы производят артефакты. В моих командах наши публичные артефакты крайне минимальны, если вообще присутствуют, и мы, безусловно, не записываем их, потому что обычно это «безопасные места», где команда обсуждает значимые для них проблемы, сортирует их и предположить, что они находятся в «круге доверия», чтобы быть открытыми и добиться перемен. Если бы мы записывали их или делали подробные заметки, то это было бы просто еще одним публичным мероприятием, и я обнаружил, что это не лучший подход — но опять же, это я и мои команды, и все люди разные.

Другими словами, как менеджер по найму я бы отказался от просьбы увидеть внутренние документы или необработанные данные, но если бы вопрос был сформулирован соответствующим образом, я был бы рад обсудить в общих чертах все, что было бы полезно кандидату для оценки компании. и команда. Итак, я бы порекомендовал подумать об информации, которую вы пытаетесь получить, и о том, как вы могли бы поступить в ходе типичного интервью (особенно во время важного «У вас есть какие-либо вопросы к нам?» ).

Собеседование является двунаправленным, поэтому уместно задавать вопросы об их технологиях, процессах, культуре и обо всем, что может повлиять на ваше решение.

Тем не менее, материал, который вы просите просмотреть, вероятно, является конфиденциальным, поэтому вам следует ожидать подписания соглашения о неразглашении (NDA). Задавая вопрос, вы должны продемонстрировать, что понимаете этот момент. Я использовал следующую формулировку: «Не могли бы вы показать мне X? Я понимаю, что это деликатно, и был бы рад сначала подписать соглашение о неразглашении». В интервью, предшествовавшем моей нынешней должности, я попросил показать API (поскольку я буду помогать создавать SDK) и задал несколько довольно глубоких вопросов об их архитектуре (я хотел оценить, насколько это технически правильно). Это было в контексте небольшой неофициальной компании-разработчика программного обеспечения, и они даже не просили NDA, но с тех пор нас приобрела крупная компания, и я до сих пор отвечаю на такие вопросы, когда даю интервью.

Там, где я работаю, я не думаю, что будет большой проблемой попросить посмотреть недавний ретроспективный отчет. Это даст вам некоторую информацию, но мало что может скомпрометировать команду, если она станет известна. Я уверен, что есть компании, у которых было бы больше оговорок. Если вы собираетесь на однодневное собеседование, я бы сказал первому, с кем вы заговорите, это документ, который вы хотели бы увидеть и обсудить с командой.

Самая большая проблема, которую я вижу, заключается в том, что у интервьюера вряд ли будет документ с собой на собеседовании. Я бы просто спросил, какие области были определены как наиболее нуждающиеся в улучшении в будущем, и какие эксперименты они предприняли и почему. Этот вопрос сам по себе должен сказать вам многое из того, что вы хотите знать. Вы также можете спросить, какие сильные стороны были выявлены. Иногда то, что важные вещи были хорошими, может перевесить опасения по поводу областей, которые нуждаются в улучшении. Если у вас есть несколько интервью с разными людьми, этот вопрос можно задавать снова и снова, что позволит вам увидеть, на чем, по мнению каждой части команды, должно быть сосредоточено внимание.

Если я интервьюер, я считаю любой вопрос честной игрой — может быть, я могу или не буду отвечать, но это нормально.

Этот конкретный вопрос может относиться к моему предыдущему месту работы. Я бы ответил на него правдой, что мы не делаем заметки о ретро, ​​просто говорим и этого достаточно. (Если обсуждение приводит к созданию какой-либо задачи, ее можно ввести, или любой может делать личные заметки, но я думаю, что это не ваша цель.)

Если бы у нас были заметки, не знаю, показал бы я их. Я бы предположил, что это маловероятно, но мы могли бы поговорить о том, как проходит ретро и т. д.

Я бы на вашем месте так не ставил вопрос. Вместо этого спрашивайте о выполнении Scrum, о ретро-событиях, проблемах, решениях и так далее. Это звучало более разумно.

Мне кажется, вас больше интересуют их процессы. Вы должны знать, как они внедряют Scrum. Вместо того, чтобы видеть реальную документацию, рискуя назвать их лжецами, просто спросите, делают ли они это вообще. Может быть, у них есть форма или какая-то обучающая информация о том, как это нужно делать, и они могут показать вам это.

Это та же проблема, если вы просите показать производственный код. Если у них есть стандартный NDA, который распространяется на эти вещи, они могут сделать их доступными для вас. Вы также можете спросить о процессах, которые приводят к коду качества: проверках, тестах, стандартах формата и т. д., не проверяя их.

Если доходит до того, что вы не доверяете тому, как они что-то делают, или они не указали, что ожидают, что кто-то придет и уберет беспорядок, я не думаю, что вам нужно видеть реальные примеры кровавых подробностей. .