
Anima vilis
В качестве эксперимента публикую разбор ещё одного собеседования, на этот раз технического, в компанию Twinby, это дейтинговый сервис. Про сам сервис ничего сказать не могу, я попытался им воспользоваться, но он потребовал с меня деньги за подписку. Рекрутерша сказала, что так не должно быть, основная функциональность доступна бесплатно. Ну да ладно. В отзывах пишут, что на сервисе практически нет модерации и он заполнен скамерами всех сортов. Проверить эту информацию возможности не представляется.
Порядок общения был стандартным — 15 января написал рекрутерше, что увидел на канале Прожект Джобс эту самую вакансию, 16 пинганул, 17 она ответила, что рассмотрит обращение. 21 января договорились о скрининге, 23 января провели скрининг. 24 января запланировали техсобес, 27 января он состоялся и 31 я получил ответ, что компания выбрала другого кандидата. На мой вопрос, каких навыков не хватило, получил ответ, что всего хватило, просто выбрали другого кандидата. На что я ответил, что сделаю из этого собеса кейс в блоге, чтобы как-то отбить столько потраченного впустую времени.
Давайте разбираться. Напоминаю, что в постах такого типа всячески приветствуются комментарии о том, на какой вопрос я ответил неправильно и что на него стоило ответить по вашему мнению. Опущу неинтересные вопросы про мой фактический опыт, оставлю, по большей части кейсы, которые могут прилететь на интервью и вам.
UPD: Добавил комментарии Дениса Пешехонова о том, как выглядели бы ответы в реальной практике. Забавно и близко к правде :-)
Предположим, у нас есть штук пятьдесят задач в бэклоге. Кто с продуктовой точки зрения ими занимается?
В моей картине мира должен быть либо продакт, определяющий приоритеты, либо ответственное лицо со стороны заказчика, который нам эти приоритеты поставит. В то же время я, как руководитель команды, могу вносить в планы итераций тактические изменения. Брать не самые приоритетные с точки зрения продакта задачи и отправлять в работу.
Сюда относятся технические задачи, не слишком очевидные продакту, но которые реально нужны разработки. Например, задачи, если которые не реализовать, вылезает некий технический риск.
— В бэклоге 50 задач, кто их приоритизирует?
— Продакт или представитель заказчика
— Заказчик говорит, что задачи одинаково важны без исключений
— Так не бывает, нужно определить приоритет
— Заказчик настаивает
— Хорошо, зададим очередь сами
... через два спринта
— Где задача номер 10? Почему ещё не сделано?
— Потому что очередь мы задали сами, и 10-я задача в конце очереди
— Заказчику нужно было уже сейчас, вы плохо справились, чем вы там занимаетесь вообще вместо работы
Как сматчить продуктовые хотелки и пожелания команды?
Разделять время итерации в пропорциях, например, 70-30 %. Мы знаем велосити команды, сколько стори поинтов она может сделать за спринт. И исходя из этого берём продуктовые и технические хотелки.
Например, у меня в практике была история, когда руководство очень хотело делать А/Б тесты, которые было сделать невозможно из-за того, что никак не могли забороть одну техническую задачу. Пришлось её вставлять в эти самые 30 % и пилить в течение нескольких итераций.
Я реально, на практике реализовывал такое разделение.
— Как учесть пожелания команды?
— Дать команде 30 % на разбор техдолга
...
— Руководитель звена узнал, что 30 % времени разработчики не делают бизнесовые фичи для заказчика, срочно переключаемся на фичи
— Но ведь техдолг...
— Техдолг и архитектура это задротство для гиков, а нужно дело делать
...
Какие метрики использовал, что собирал, на что опираешься?
Читайте тут, я там перечислил все основные метрики для разных подходов к организации работ.
Помимо перечисленных метрик, я практически во всех компаниях считал план/факт. Во сколько оценили задачи, сколько они реально заняли.
Пообещали продактам, что сделаете фичу за итерацию, но в середине итерации поняли, что не успеваете. Что делать?
Выяснить причины, почему не укладываемся. Самая частая причина — легаси. В одном месте правим, в другом расползается. Иногда недооценивается сложность задачи.
Пояснить продактам, какие меры мы принимаем для того, чтобы легаси так не влиял. Извиниться, назвать новые сроки, закоммититься на новые сроки. Постараться в эти сроки уложиться.
Разработчики могут назвать внутренние причины мне, может у них какой-то внутрикомандный конфликт, который я могу разрулить. Поработать с командой. Чаще всего это делается в рамках ретроспективы. Не реже двух раз в неделю собираюсь с техническими руководителями команды — тимлидом, техлидом.
— Почему не сделали фичу за итерацию?
— Потому что сроки, названные разработкой, не устроили руководство, и оно само задало втрое меньше
Расскажи о конфликте с сотрудниками. Какой был самый интересный, как решил?
У меня был младший пиэм, который плохо себя вёл, токсичил, оскорблял коллег из соседних департаментом, а кроме того, давал отрицательные результаты по план-факту. Однако руководство стояло на том, что уволить его мне не даст, он очень хорошо знает нашу линейку продуктов и поэтому ценен.
Я рекомендовал ему поработать на соседний продукт, в котором была не продуктово-заказная, а чисто продуктовая разработка, продукт зарабатывал, преимущественно, на продаже коробок и требования к план-факту не были такими серьёзными. Пиэм ушёл в соседний продукт, поработал там какое-то время, а потом сам уволился и проблема решилась сама собой.
У тебя есть команда бэкенда. Она делает бэкенд-часть, отдаёт в другие команды, и в какой-то момент ты обнаруживаешь, что копятся задачи на ревью. Что будешь делать?
— А правда, что ревью занимается один тимлид или техлид?
— Нет, неправда, сотрудники ревьюят друг друга по кругу.
— Возможно, проблема в технологии ревью, надо разобраться, как они ревьюят. Может быть, много времени занимает проверка и исправление оформления кода? Может быть, стоит внедрить линтеры? Выяснять, на что тратят время.
— Команда говорит, что с ревью всё в порядке, задачи просто не отдаются дальше, потому что тестирование загружено. Несколько тестировщиков прикреплены к команде бэкенда, Они всегда с ней.
— Идём к тестировщикам, выясняем, что с ними, хватает ли рук, хватает ли квалификации. Может быть, стоит добавить пару тестировщиков.
— Тестировщики говорят, что много возвратов. Мы делаем сборку, там 20 задач, 19 проверены, готовы, последняя на возврате. Не может продолжить тестирование. Возвратом называем ситуацию, когда проверили, там недоработка, вернули.
— Мысль такая. Самотестирование задач разработчиками. Ещё может быть такая история как несовпадение среды. Решается внедрением докера. Возможно, стоит подумать о том, как реализовать частичную передачу оттестированного кода, чтобы не ждать последнюю задачу.
— Почему ревью долгое?
— Задачи не идут дальше из-за задержки тестирования
— Почему тестирование долгое?
— Много возвратов
— Почему много возвратов? Может пусть разработчики сами себя тестируют?
— Им на это времени не дадут
— Тогда может автотесты?
— Некому писать
Веб и мобилка постоянно дожидаются бэка, чтобы получить от них свою часть работы. Как можно оптимизировать, какие мысли?
Мысль в том, что мобильщики и фронтендеры не должны дожидаться реализации бэками ручек. Они должны иметь возможность кодить на моковых данных. Предварительная договорённость о формате обмена, моковый сервер, кодим одновременно. Как только бэки заканчивают работу, нам останется только интегрировать. Это улучшит ТТМ.
— А что если бэки сначала обещают один формат обмена данными, а потом предоставляют всё совсем по-другому?
— Для того, чтобы таких ситуаций не возникало, нужен один толковый системный аналитик, который сможет нормально проектировать и синхронизировать этих ребят.
— Наняли системного аналитика, но бэк всё равно, пилит всё по своему.
— Есть подозрение, что системный аналитик просто молча пуляет в разрабов спецификацию. Реализовать демо требований и разбор их на очной встрече.
— Фронт ждёт бэк
— Делайте контракты заранее
— Техлида и архитектора нет, руководство считает, что он слишком дорогой и не особо нужный