Чтобы изначально понять компетенции, зададим 6 вступительных вопросов.
1. Расскажите о последнем опыте руководства командой? Какие основные вызовы пришлось преодолевать в этой роли?
а) разработка согласно KPI, OKR, 4DModel (4 Disciplines of Execution)
б) внедрение нового подхода Data Driven Scrum (это скрам с акцентом на аналитику и информационным табло метрик работы команды)
в) управление кросс-функциональной командой (выполнение командой задач не только в рамках своих проектов)
г) достижение высоких уровней Team Maturity Model
д) улучшение кроссплатформенных решений
2. По каким признакам вы определяете, что ваша команда успешна?
В ряде компаний использовалась оценка задач в JIRA/YouTrack и отслеживание успешности с помощью всяких отчетов вроде Burndown/Velocity.
Но, на последнем месте работы мы использовали DDS подход (Data Driven Scrum), который говорит о том, чтобы совместно оценивать задачи, выполнять задачи в соответствии с оценкой и коэффициентом производительности отдельно каждого сотрудника, и отслеживать выполнение как команды целиком, так и каждого участника в отдельности, деталей там много, но коротко как-то так.
3. Приходилось ли вам проектировать архитектуру сложного сервиса? Какие этапы проходили при проектировании и какие документы/артефакты создавали?
Сложность сервиса величина относительная, но проектировать архитектуры на мой взгляд небольших приложений приходилось, например: реализации нового сервиса управления промо-акциями проекта shop.mts.ru
Обычно этапы выглядели приблизительно так: проектирование в соответствии с ожидаемой нагрузкой и запланированного бюджета (сервера, ПО) + с учетом SLI, SLO, SLA + документирование (ADR, C4Model, roadmap), обсуждение, внесение правок, согласование, реализация, улучшение (все как пишут в ITIL).
4. Были ли в практике случаи, когда от бизнеса приходила задача с которой вы категорически не согласны (по содержанию или по приоритету)? Как действовали в такой ситуации?
Категоричных моментов не было, но бывали моменты, по которым предлагал более универсальные или с заделом на будущее решения. Поэтому обсуждали, приходили к консенсусу, начинали реализацию. Я придерживаюсь такой же политики в команде, т. е. должна быть демократия, а не тоталитаризм, все должно быть гибко и потому что бывает экспертиза/мнение кого-то в команде в каком-то вопросе оказывается лучше чем руководителя.
5. Часто бывает такая ситуация что нужно и доставлять фичи и устранять техдолг. Приходилось ли когда-нибудь решать проблему приоритезации техдолга? Можете привести пример успешной стратегии?
Да, в ряде компаний изначально отдавалось 20% времени на тех. Долг, а в некоторых приходилось самостоятельно закладывать в бизнес-задачи ряд времени на тех. долг, но обычно в согласовании с бизнесом, например делаем бизнес-фичи, а в конце спринта/месяца/полугодия делаем задачи тех. долга.
6. Как вы поддерживаете свои технические навыки в актуальном состоянии? Если бы я был junior инженером в вашей команде, посоветуйте мне книги/блоги/другие ресурсы чтобы постоянно иметь актуальные знания и расти как инженеру?
Актуальность навыков поддерживаю практикой (пишу часть кода), обсуждаю мини-архитектурные детали с разработчиками, код-ревью, читаю тех. литературу. Джуниору посоветую базу: Мартин Фаулер - Шаблоны корпоративных приложений, Роберт Мартин - чистая архитектура, Бек - Экстремальное программирование, Крис Ричардсон - Микросервисы, паттерны разработки, SRE (Site Reliability Engineering) от сотрудников Гугла.
Продолжение следует ;)
Комментарии
Комментариев пока нет.