People Management
- Приходилось ли вам лично стафить команду под проект?
- Проектировали ли вы стафинг план и синьорити пирамиду для проекта (на основании чего?)
- Да. Сениорити на основании:
- уровня сложности проекта
- объема работы и длительности
- тех-стека
- уровня неопределенности
- нормативной прибыльности проекта по компании
- общепринятых соотношений по компетенциям (например, на 3 пишущих код разработчиков 1 QA)
- стаффинг именно спецов по тестированию согласовывался с QA Lead, т.к. многое зависит от стратегии тестирования, тест плана, уровня качества (на основе ожиданий клиента) и др.
- Участвовали ли вы в подборе персонала, в каком качестве, каких специалистов – по специализации, позициям?
- Да, занимался, такие специалисты:
- QA manual
- BE, FE
- Team Lead
- PM
- Какие методы фасилитации команды использовали?
- Brainstroming
- Bodystorming
- Flip-chart
- Icebreakers
- Group decision-making with voting
- Retrospectives (if count)
- Как методы применяли для управления рисками и минимизации рисков по ресурсам?
- Avoidance
- undercompetent staff - избегать найма слабых инженеров на новый проект (помощь инженеру-интервьюэру в беседах, также в составлении более развернутых фидбеков после собеса). Найм РМов - на входе проводить подробный теор. экзамен + давать тестовое
- overallocation - не стафить один ресурс на >1 проект
- Sharing
- health issues - страховка
- Retention
- workload - планировать ≤ 5 эффективных часов работы в день на инженера
- Transferring
- work beyond our expertise - чтоб не нанимать новые компетенции в компанию ради одного проекта, передаем вопрос найма на команду (организацию) клиента: был случай с девопсом и с нейросетями, таких спецов в штате не было, нанимать невыгодно и не пойдут, а на субподряде еще рисковее
- Prevention (Reduction)
- attrition and leaves - чтобы смена людей на проекте не вызывала провалов по срокам деливери, ведется подробная документация (в коде и в конфлуенсе) и также есть процесс онбординга в команду (рассказывают про клиента, приложение, что оно делает и зачем, какие цели, какой сейчас скоуп релиза и тд)
- Определяли ли вы размеры компенсации, райзов для специалистов и на основании чего?
- Да. На основании Performance Review + Personal Development Plan + 360 Review + Customer Feedback. One-to-one встречи использовали для контроля и синхронизации с сотрудником по его прогрессу в развитии, уровню удовлетворенности на проекте и другим рабочим вопросам
- Разрабатывали и применяли ли вы KPI по позициям в оценке эффективности команды в целом и отдельных специалистов (какие именно метрики, как рассчитывали, как проводили оценку)?
- Для разработчиков - кэоффициент попадания в эстимейт: 1 - оценил на 5 часов, сделал за 5 часов, 1.3 - оценил на 5, сделал за 6.2. Этот коэфф потом применялся как мультипликатор в бюджете: если в эстимейте разработчик John Doe оценил работ всего на 300 часов, а коэфф у него 1.3, то 300*1.3 = 390 часов закладываюся в бюджет.
- Для РМов
- Planned Hours vs Time Spent (whole team)
- Resource Daily Allocation (≤5 hours)
- Spend vs Paid hours (always must be equal)
- Velocity
- Budget Variance
- Cost Performance Index
- Net Promoter Score (Customer Satisfaction)
- Number of Change Requests
- Milestones reached
Account management
- Приходилось ли вам делать расчеты рентабельности и управлять финансовыми проектными показателями? какими именно?
- Да, базовый ROI, все более сложное (P&L и прочее) либо рассчитывалось отдельным софтом, либо бухгалтерами.
- Финансовые показатели
- Прибыльность всего проекта
- Прибыльность каждого ресурса
- Burnrate
- Cost Variance
- Перечислите основные показатели финансовой эффективности проекта, которые вы использовали
- Blended rate - средний рейт на команду, должен быть на таком уровне, чтобы обеспечивать норму прибыли
- Cost Variance
- Profitability %
- Приходилось ли рассчитывать нормативы для основных показателей финансовой эффективности проекта, если да, то на основании чего именно?
- Обычно, нормы задавались руководством компании. Некоторые проекты, в исключительных случаях, приходилось делать с пониженной прибыльностью, что тоже наперед рассчитывалось и далее отслеживалось РМом по ходу проекта, насколько мы попадаем в ожидаемую прибыльность.
- Приходилось ли составлять, обрабатывать инвойсы, контракты – вести переговоры с партнерами по легал, финансовым вопросам - выступать в роли аккаунт менеджера?
- Да, работал с инвойсами и контрактами, сам их составлял (с консультацией юристов, естественно, сам не юрист).
- Типы контрактов - Fixed Bid, T&M
- Какие ключевые пункты обеспечивающие защиту ваших интересов в них прописывали
- Non-compete - и в смысле создания похожих продуктов другим компаниям в этом рынке, и в смысле рабочей силы, то есть не хантить и не переманивать сотрудников
- Scope - условия по внесению изменений и какой будет процесс их обработки и дополнения оригинального объема работ
- Time - какие условия изменения сроков и в каких случаях
- Cost - кто отвечает за изменение бюджета, какой процесс пересогласования нового бюджета
- SLA - скорость ответа, скорость фикса, отдельные условия для праздников и выходных
Process Management
- Как вы определяете какая методология по разработке будет оптимальной для проекта?
- По степени неопределенности требований - от и до понятно, как и что делать; понятно только, как начать, но изменений будет так много и так часто, что требования будут устаревать за 1-2 недели
- По стадии - новый софт с нуля, развитие работающего софта, переход от легаси на новый софт, интеграция готового решения в ИТ эко-систему
- По типу бизнеса - стартап, средний бизнес, корпорация, ентерпрайз
- С какими видами не функциональных требований вы персонально работали?
- Ограничения - например, один клиент требовал сделать авторизацию не просто по емеил, но также с проверкой личности через распознавание фото; другой клиент требовал, чтобы UAT находился только на их инфраструктуре, что сильно усложнило весь CI/CD процесс на проекте
- Бизнес-политики (правила) - чаще всего сюда относились любые требования отдела безопасности на стороне клиента по доступу к серверам организации
- Внешние интерфейсы - любые интеграции с API третьих поставщиков и требования к формату и структуре передаваемых данных
- Юридические требования - на одном проекте требовалось получить лицензию Foods&Drugs Association в США, прежде чем запускать продукт в продажу
- Тестирование - бывали клиенты, которым нужен был уровень тестирования выше, чем ручное + юнит, поэтому добавлялся пласт работы по автоматизации на Selenium
- Составляли ли эстимейты – на основании чего, по какой методике, какие основные разделы в них включали
- Да.
- На основании экспертной оценки: бизнес (системный) - аналитик и архитеткор\техлид
- Эстимейт всегда представлял собой стандартный WBS с часовыми оценками. Структура: 1. Milestone, 1.1 Function, 1.1.1 Feature, Decription (Assumptions), Opt Est, Most Likely, Pess Est. Triangular Distribution метод оценки.
- Составляли ли матрицу рисками, как осуществляли процесс управления рисками (описать примеры рисков и митигейшенов к нему)
- Использовалась матрица. В компании велся общий реестр типовых рисков для проектов разработки софта, который пополнялся по опыту каждого нового проекта.
- На уровне одного проекта процесс управления выглядел так:
- Выявление - основные риски закладываются еще в эстимейт проекта на этапе продажи и определяются при участии аналитика, архитектора\техлида и СПМа. Часть закладывается в эстимейт как буффер, часть вносится в реестр.
- Анализ - проработка каждого риска по зоне воздействия, уровню воздействия, и определяется вероятность появления
- Оценка - проставляется приоритет каждому риску
- Обработка - продумывается план ослабления (mitigation) и реагирования (contingency)
- Мониторинг\контроль - каждую неделю собирается отдельная встреча по пересмотру реестра рисков, на которой владелец каждого риска сообщает, насколько его вероятность выросла\понизилась за предыдущий период. В результате встречи, реестр обновляется и в работу отдаются задачи по ослаблению или реагированию на выбранные риски
- Как работали с обеспечением качества и выполнения сроков поставки (перечислить мероприятия, направленные на контроль качества и сроков)
- Тест репортинг - предоставление РМу (себе) и клиенту прозрачного статуса об уровне качества на отчетный период по его проекту. Содержал в себе список найденных, закрытых, открытых багов, также их severity, reproducability, impact area (component), и приоритет (место в очереди на фикс), который выставлял РО.
- Project Status Report - отчет за спринт, отчет по велосити, version report, cumulative flow, обновленный Gantt Chart с майлстоунами