Ad informandum
Давно не было постов о реальных собеседованиях. Сараффан Радио — это такой стартап, который создали два человека, шарящие в эвент-индустрии. Представляет собой платформу, на которой можно будет планировать эвенты.
Нашёл эту вакансию на канале @projects_jobs_feed, написал рекрутерше. Она усомнилась, что я сумею управлять командой в 13 человек, ведь до этого управлял бóльшими командами. Заверил, что нужно научиться управлять тремя, потом количество не имеет значения. Провели скрининг, потом был техсобес, потом они долго тупили, после чего сообщили, что выбрали более профильного кандидата.
Разберём вопросы с технического собеседования, это четвёртый такой пост в моём блоге. Комментарии о том, где я обосрался, приветствуются.
Расскажи, как с твоей точки зрения должен выглядеть скрам
По ролям. Должны быть три роли. Продукт овнер, скраммастер, кроссфункциональная команда.
Должны быть скрам-ритуалы:
- Дейли митинг.
- Планирование спринта.
- Обзор спринта.
- Ретроспектива.
- Демо.
- Планинг покер.
Должны быть бэклог продукта и бэклог спринта. В бэклоге продукта все стори, в бэклоге спринта только то, что идёт в спринт.
По итогам каждого спринта мы получаем инкремент продукта, который поставляется заказчику и мы получаем ОС.
По итогам каждого спринта проводится ретроспектива.
Продукт-овнер периодически реприоритизирует стори в бэклоге так, чтобы продукт соответствовал рынку.
Проводятся различные измеряшки. Например, велосити команды.
В скрам тесно интегрированы стори поинты.
Дейли синки для команды в 4 фронта, 2 бэка, тестирование, тимлид. Сколько должны занимать?
Минут 15-20
А если ребята систематически выходят за это время, есть способы его сократить?
Чаще всего это происходит из-за того, что ребята начинают углубляться в обсуждение технических проблем. Тут должен подключиться скраммастер и выносить детальные обсуждения этих проблем в отдельные встречи. На дейлике обсуждаем три скрамовские вопроса:
- Что делал?
- Что собираюсь делать?
- Какие есть стопы?
Но детали стопов обсуждаем на отдельных встречах только с теми, кого это затрагивает.
За что должен отвечать ПМ?
Если совсем верхнеуровнево, то он отвечает за то, чтобы заказчик, внутренний или внешний, был удовлетворён. Это самая корневая вещь. Если заказчик удовлетворён, пиэм работает нормально.
Если начать спускаться, то пиэм отвечает за треугольник, сроки, деньги, содержание.
Сфера ответственности пиэма различается от того, какая схема управления применяется в подразделении, операционная или функциональная.
В операционной он напрямую управляет членами команды, ставит задачи, планирует, даёт обратную связь, разруливает любые конфликты, решает оргвопросы.
В функциональной схеме работа чуть усложняется, там он уже не двигает фигуры по доске напрямую, он управляет через лидов, выстраивает систему.
Пиэм практически всегда отвечает за финансовый успех проекта, ведёт его бюджет. В продуктовой он делит эту ответственность с продактом, в аутсорсной ответственен напрямую.
Пиэм организует взаимодействие с заказчиком, внутренним или внешним. Присутствует на всех созвонах, модерирует и фасилитирует их. Необязательно лично ведёт.
Каким образом пиэм может влиять на качество?
Пиэм взаимодействует с лидом тестирования или рядовыми тестировщиками в операционной схеме и они вместе разрабатывают и применяют политику качества. Какие будут артефакты, какой будет процесс, какая численность команды тестирования, какие ритуалы, какие виды тестирования.
Будут ли и как именно тестировщики участвовать превентивно. В нормальной схеме куа подключается к проработке требований на ранней стадии.
Как правило, определяющую роль в качестве играет лид QA. Пиэм с ним взаимодействует и всячески дружит.
В плане качества пиэм может сильно повлиять через работу с требованиями. Если требования плохо расписаны, качества не будет.
Хватает у пиэма компетенций нанимать и назначать лидов?
В большой компании собеседование на лида QA или аналитики проводит соответствующий лид компании. Пиэм в собеседовании участвует, задаёт общечеловеческие вопросы и имеет голос.
Если компания поменьше, пиэм может нанять Лида самостоятельно. Для этого должен иметь t-shape в сторону тестирования и аналитики.
Тебе часто доводилось писать ТЗ самостоятельно?
Часто. Особенно в небольших компаниях руководство часто на БА экономит. Мне кажется, что если проект маленький или средний, совмещение возможно. На маленьком без проблем, на среднем с оговорками. На сложном так лучше не делать, у пиэма будет много оргвопросов, не будет хватать времени.
Достаточно ли статьи на бизнес-языке для старта разработки?
Зависит от технической сложности проекта и квалификации разработчиков. Если у нас прям сеньоры, может быть и хватит. Если менее квалифицированная команда, то скорее всего, нет, нужна более низкоуровневая проработка. Разбиение на бизнес-функциональные, трассировки с дизайном и всё такое.
Вопрос дискуссионный. Не стоит превращать разработчиков в кодеров.
Если бы тебе пришлось начинать с начала в стартапе, как бы организовал разработку?
Надо много всего сделать. Самое главное — это кадры. Чтобы хватало квалифицированных сотрудников. Я бы участвовал, как минимум, по софтам.
Использование хороших инструментов. Таск трекер, система ведения требований.
Грамотно выстроить пайплайн, как будет происходить разработка.
Определить порядок взаимодействия со стейкхолдерами. Это больше прерогатива продуктовнера, но надо проговорить, как нам будут поступать задачи, насколько глубоко они будут прорабатываться, как будет происходить приоритизация, как часто мы будем отчитываться по статусу.
По аналитике, проговорить, как будем работать, пиэм тут тоже имеет право голоса.
Проговорить с тимлидом и разработчиками меры по уменьшению бас-фактора. Выстроить систему код-ревью.
Выстроить работу с качеством, проговорить, как будем тестировать.
В итоге у нас прорисуется более-менее сформированный пайплайн разработки.
Далее надо строить отношения со стейкхолдерами. Как сделать так, чтобы воля стейкхолдеров доносилась до нас наиболее адекватно.
Выстроить систему обратной связи и 1-2-1 для всех сотрудников.
Организовать систему сбора метрик и измерений разных параметров команды. Желательно малоинвазивно, чтобы всё измерялось автоматически.
Наладить работу в таск-трекере.
Как должен выглядеть процесс декомпозиции и оценки
Надо определиться, в каком виде будут поступать задачи от заказчиков. Обычно они приходят в виде описаний на бизнес-языке. Дальше аналитик это бизнес-описание декомпозирует, разбивая на бизнес и функциональные требования. Как правило, аналитики сочетают роль бизнесового и системного в одном лице.
В декомпозиции функциональных требований до отдельных тасков участвуют лид разработки и программист, который будет это реализовывать.
Оценка возможна на уровне аналитика и разработчика. На моих проектах декомпозицию до тасков обычно делал кто-то из технических чувачков.
Что касается методов оценки, как правило применяется либо оценка экспертная, либо по трём точкам. Всего их порядка восьми штук. На деле обычно применяются эти два. Если оценивать надо много всего, применяется планинг-покер.
В Девелонике мы называли грумингом встречи, на которых аналитик презентует требования разрабам, те задают вопросы, требования уточняются и оцениваются.
Как правильно организовать процесс ретро?
Не буду дублировать две статьи:
Что будешь делать, если разработчик не будет делать того, что планирует на утренних синках?
Выясню причину. Чаще всего причина в прокрастинации. С этим можно бороться, временно установив за разрабом наблюдение. В начале дня он говорит мне: «Собираюсь делать структуру классов, нужно два часа». Я отвечаю: «Отлично, через два часа покажешь диаграмму классов». Через два часа его пингую. В таком режиме можно проработать несколько дней, обычно это прокрастинацию лечит.
Если не хватает квалификации — подтягиваем. Если не хватает мотивации — работаем с мотивацией. Если устал — отправляем на дей офф или в отпуск.
Команда дала оценку работам на спринт и эти работы в спринт не влезают. Что делать?
Спросить у продакта приоритеты и выкинуть из спринта лишнее.
Добавить комментарий