У меня завтра собеседование на работу мечты, и мне нужно провести 45-минутную встречу по сбору требований и планированию программного приложения, которое они придумают. Это я буду стоять в комнате с «заказчиком» и разработчиком. К концу они ожидают пользовательских историй, требований и т. д.
Я очень хорошо разбираюсь в Scrum, но никогда раньше не проводил запуск проекта или планерку. Любые ссылки, YouTube, шаги или советы, которые вы могли бы мне дать? Я пытался изо всех сил использовать Google-фу, чтобы найти фиктивную встречу «запуск проекта», чтобы посмотреть или прочитать о ней, но я потерпел неудачу. Я ценю его! <3
Интересная проблема. Я был бы немного обеспокоен тем, что обстановка интервью не обязательно является реалистичным микрокосмом реального проекта. Вы начнете с гораздо меньшим пониманием проблемы и «клиента», чем вы могли бы ожидать от обычного профессионального взаимодействия. Однако, поскольку вы, кажется, имеете некоторое представление о том, как будет выглядеть успешный результат, это должно быть управляемым.
У каждого есть свое представление о том, как выглядит хороший старт, поэтому, если вы можете сформулировать свое в контексте, подходящем для компании, к которой вы хотите присоединиться, это, вероятно, лучше. Все, что я могу предложить, это мой опыт работы подрядчиком в Carbon Five .
Ваш вопрос относится к нескольким различным видам деятельности; сбор требований, запуск проекта, планирование истории. Я часто трачу по 45 минут на каждую из них, поэтому я хотел бы расставить приоритеты, какие из них вам действительно нужно осветить.
Обычно я начинаю с введения, чтобы объяснить процесс, который использует моя команда, как он работает и что ожидается/требуется от всех участников, особенно от заказчика/владельца проекта. Это, вероятно, не даст вам хорошего шанса подчеркнуть свои способности на собеседовании, поэтому вам, возможно, придется надеяться, что это может быть воспринято как предполагаемое знание или под расплывчатым описанием: «Эта команда будет использовать гибкий итеративный процесс для создания вашего продукта, мы не собираемся планировать все сегодня, но у нас должна быть хорошая возможность спланировать каждую функцию по мере ее появления».
Я бы сосредоточился на деятельности по сбору требований. Поскольку у вас будут присутствовать клиент и разработчик, вы можете стремиться создать несколько практических историй, но я хотел бы четко указать, что на первой встрече многие из них, вероятно, будут эпическими и должны быть разбиты на части в будущих разговорах, если только проблема не будет решена. очень простой. Вы должны быть в состоянии привлечь всех к участию в планировании и предоставить себе хорошую возможность продемонстрировать свою способность вести интерактивную дискуссию и открывать продукт, который нужен клиенту.
Я бы попытался начать с набросков некоторых очень легких персонажей, пока клиент объясняет проблему. Достаточно иметь представление о том, для кого вы это строите и какие ограничения, как вы понимаете, у них есть. Обычно это то, что я хотел бы сделать заранее, но я думаю, что стоит потратить 5 минут, чтобы показать общее понимание того, для кого предназначен этот продукт, и если есть несколько персонажей, чтобы согласиться сосредоточиться на одном. (Мне показался полезным стиль, описанный Лейном Халли в «Персонах для программистов» .)
Имея некоторое представление о том, кто ваш пользователь, я бы попытался построить простую карту опыта . Через 15 минут вы должны быть в состоянии набросать действия вашего пользователя, которые взаимодействуют с продуктом, и различные задействованные точки соприкосновения. Это должно быть хорошим шансом для разработчика помочь определить внешние системы, с которыми вам нужно будет интегрироваться, а для клиента — выявить взаимодействия, выходящие за рамки продукта, которым вы управляете (например, пересылка электронной почты другим людям).
Наконец, я бы использовал действия, указанные в этой карте опыта, чтобы начать писать несколько историй высокого уровня и определять некоторые начальные вехи для проекта. Я считаю, что карта историй — это хороший способ начать организовывать такие истории и распределять их по функциональным (а не временным) вехам. Это также шанс для вас продемонстрировать написание хороших историй INVEST с заказчиком и разработчиком.
На данный момент у меня, конечно, нет времени, но, надеюсь, вы сможете выделить несколько минут, чтобы обсудить следующие шаги, такие как подробная оценка первого спринта или вехи, и спросить о процессе, который обычно используют интервьюеры.
Удачи.
Трудно точно знать, что они намерены делать с этим макетом интервью, но если бы я сделал что-то подобное (как интервьюер), я бы в первую очередь хотел увидеть стратегию кандидата, чтобы убедиться, что у него есть точное понимание проблемы клиента. и приоритеты. В качестве вторичного преимущества я мог бы увидеть, как кандидат общается с клиентом: фразы, тон, предположения и непредвзятые вопросы.
Поскольку отсутствие определения проблемы или первоначальное решение неправильной проблемы, ведущее к переделке, являются такими распространенными проблемами, я бы искал кандидата, который может избежать этих проблем, но это всего лишь моя предвзятость.
В связи с этим я бы посоветовал вам сосредоточиться на том, что вы уже знаете и умеете делать. По моему мнению, «зубрежка» и попытки запомнить новые навыки во время собеседования приведут к стрессу и нервозности, что, вероятно, повлияет на вашу способность свободно отвечать во время собеседования. Я думаю, что более важно выглядеть непринужденно во время интервью, так как это демонстрирует глубокую компетентность в том, что вы обсуждаете; при необходимости вы можете открыто рассказать о том, в каких областях у вас нет достаточного опыта, но заявить, что вы с нетерпением ждете возможности получить больше опыта в этих областях.