People Management

1. Приходилось ли вам лично стафить команду под проект?
   • Да
2. Проектировали ли вы стафинг план и синьорити пирамиду для проекта (на основании чего?)
   • Да. Сениорити на основании:
     • уровня сложности проекта
     • объема работы и длительности
     • тех-стека
     • уровня неопределенности
     • нормативной прибыльности проекта по компании
     • общепринятых соотношений по компетенциям (например, на 3 пишущих код разработчиков 1 QA)
     • стаффинг именно спецов по тестированию согласовывался с QA Lead, т.к. многое зависит от стратегии тестирования, тест плана, уровня качества (на основе ожиданий клиента) и др.
3. Участвовали ли вы в подборе персонала, в каком качестве, каких специалистов – по специализации, позициям?
   1. Да, занимался, такие специалисты:
      1. QA manual
      2. BE, FE
      3. Team Lead
      4. PM
4. Какие методы фасилитации команды использовали?
   1. Brainstroming
   2. Bodystorming
   3. Flip-chart
   4. Icebreakers
   5. Group decision-making with voting
   6. Retrospectives (if count)
5. Как методы применяли для управления рисками и минимизации рисков по ресурсам?
   1. Avoidance
      1. undercompetent staff - избегать найма слабых инженеров на новый проект (помощь инженеру-интервьюэру в беседах, также в составлении более развернутых фидбеков после собеса). Найм РМов - на входе проводить подробный теор. экзамен + давать тестовое
      2. overallocation - не стафить один ресурс на >1 проект
   2. Sharing
      1. health issues - страховка
   3. Retention
      1. workload - планировать ≤ 5 эффективных часов работы в день на инженера
   4. Transferring
      1. work beyond our expertise - чтоб не нанимать новые компетенции в компанию ради одного проекта, передаем вопрос найма на команду (организацию) клиента: был случай с девопсом и с нейросетями, таких спецов в штате не было, нанимать невыгодно и не пойдут, а на субподряде еще рисковее
   5. Prevention (Reduction)
      1. attrition and leaves - чтобы смена людей на проекте не вызывала провалов по срокам деливери, ведется подробная документация (в коде и в конфлуенсе) и также есть процесс онбординга в команду (рассказывают про клиента, приложение, что оно делает и зачем, какие цели, какой сейчас скоуп релиза и тд)
6. Определяли ли вы размеры компенсации, райзов для специалистов и на основании чего?
   1. Да. На основании Performance Review + Personal Development Plan + 360 Review + Customer Feedback. One-to-one встречи использовали для контроля и синхронизации с сотрудником по его прогрессу в развитии, уровню удовлетворенности на проекте и другим рабочим вопросам
7. Разрабатывали и применяли ли вы KPI по позициям в оценке эффективности команды в целом и отдельных специалистов (какие именно метрики, как рассчитывали, как проводили оценку)?
   1. Для разработчиков - кэоффициент попадания в эстимейт: 1 - оценил на 5 часов, сделал за 5 часов, 1.3 - оценил на 5, сделал за 6.2. Этот коэфф потом применялся как мультипликатор в бюджете: если в эстимейте разработчик John Doe оценил работ всего на 300 часов, а коэфф у него 1.3, то 300*1.3 = 390 часов закладываюся в бюджет.
   2. Для РМов
      1. Planned Hours vs Time Spent (whole team)
      2. Resource Daily Allocation (≤5 hours)
      3. Spend vs Paid hours (always must be equal)
      4. Velocity
      5. Budget Variance
      6. Cost Performance Index
      7. Net Promoter Score (Customer Satisfaction)
      8. Number of Change Requests
      9. Milestones reached

Account management

1. Приходилось ли вам делать расчеты рентабельности и управлять финансовыми проектными показателями? какими именно?
   1. Да, базовый ROI, все более сложное (P&L и прочее) либо рассчитывалось отдельным софтом, либо бухгалтерами.
   2. Финансовые показатели
      1. Прибыльность всего проекта
      2. Прибыльность каждого ресурса
      3. Burnrate
      4. Cost Variance
2. Перечислите основные показатели финансовой эффективности проекта, которые вы использовали
   1. Blended rate - средний рейт на команду, должен быть на таком уровне, чтобы обеспечивать норму прибыли
   2. Cost Variance
   3. Profitability %
3. Приходилось ли рассчитывать нормативы для основных показателей финансовой эффективности проекта, если да, то на основании чего именно?
   1. Обычно, нормы задавались руководством компании. Некоторые проекты, в исключительных случаях, приходилось делать с пониженной прибыльностью, что тоже наперед рассчитывалось и далее отслеживалось РМом по ходу проекта, насколько мы попадаем в ожидаемую прибыльность.
4. Приходилось ли составлять, обрабатывать инвойсы, контракты – вести переговоры с партнерами по легал, финансовым вопросам - выступать в роли аккаунт менеджера?
   1. Да, работал с инвойсами и контрактами, сам их составлял (с консультацией юристов, естественно, сам не юрист).
   2. Типы контрактов - Fixed Bid, T&M
5. Какие ключевые пункты обеспечивающие защиту ваших интересов в них прописывали
   1. Non-compete - и в смысле создания похожих продуктов другим компаниям в этом рынке, и в смысле рабочей силы, то есть не хантить и не переманивать сотрудников
   2. Scope - условия по внесению изменений и какой будет процесс их обработки и дополнения оригинального объема работ
   3. Time - какие условия изменения сроков и в каких случаях
   4. Cost - кто отвечает за изменение бюджета, какой процесс пересогласования нового бюджета
   5. SLA - скорость ответа, скорость фикса, отдельные условия для праздников и выходных

Process Management

1. Как вы определяете какая методология по разработке будет оптимальной для проекта?
   1. По степени неопределенности требований - от и до понятно, как и что делать; понятно только, как начать, но изменений будет так много и так часто, что требования будут устаревать за 1-2 недели
   2. По стадии - новый софт с нуля, развитие работающего софта, переход от легаси на новый софт, интеграция готового решения в ИТ эко-систему
   3. По типу бизнеса - стартап, средний бизнес, корпорация, ентерпрайз
2. С какими видами не функциональных требований вы персонально работали?
   1. Ограничения - например, один клиент требовал сделать авторизацию не просто по емеил, но также с проверкой личности через распознавание фото; другой клиент требовал, чтобы UAT находился только на их инфраструктуре, что сильно усложнило весь CI/CD процесс на проекте
   2. Бизнес-политики (правила) - чаще всего сюда относились любые требования отдела безопасности на стороне клиента по доступу к серверам организации
   3. Внешние интерфейсы - любые интеграции с API третьих поставщиков и требования к формату и структуре передаваемых данных
   4. Юридические требования - на одном проекте требовалось получить лицензию Foods&Drugs Association в США, прежде чем запускать продукт в продажу
   5. Тестирование - бывали клиенты, которым нужен был уровень тестирования выше, чем ручное + юнит, поэтому добавлялся пласт работы по автоматизации на Selenium
3. Составляли ли эстимейты – на основании чего, по какой методике, какие основные разделы в них включали
   1. Да.
   2. На основании экспертной оценки: бизнес (системный) - аналитик и архитеткор\техлид
   3. Эстимейт всегда представлял собой стандартный WBS с часовыми оценками. Структура: 1. Milestone, 1.1 Function, 1.1.1 Feature, Decription (Assumptions), Opt Est, Most Likely, Pess Est. Triangular Distribution метод оценки.
4. Составляли ли матрицу рисками, как осуществляли процесс управления рисками (описать примеры рисков и митигейшенов к нему)
   1. Использовалась матрица. В компании велся общий реестр типовых рисков для проектов разработки софта, который пополнялся по опыту каждого нового проекта.
   2. На уровне одного проекта процесс управления выглядел так:
      1. Выявление - основные риски закладываются еще в эстимейт проекта на этапе продажи и определяются при участии аналитика, архитектора\техлида и СПМа. Часть закладывается в эстимейт как буффер, часть вносится в реестр.
      2. Анализ - проработка каждого риска по зоне воздействия, уровню воздействия, и определяется вероятность появления
      3. Оценка - проставляется приоритет каждому риску
      4. Обработка - продумывается план ослабления (mitigation) и реагирования (contingency)
      5. Мониторинг\контроль - каждую неделю собирается отдельная встреча по пересмотру реестра рисков, на которой владелец каждого риска сообщает, насколько его вероятность выросла\понизилась за предыдущий период. В результате встречи, реестр обновляется и в работу отдаются задачи по ослаблению или реагированию на выбранные риски
5. Как работали с обеспечением качества и выполнения сроков поставки (перечислить мероприятия, направленные на контроль качества и сроков)
   1. Тест репортинг - предоставление РМу (себе) и клиенту прозрачного статуса об уровне качества на отчетный период по его проекту. Содержал в себе список найденных, закрытых, открытых багов, также их severity, reproducability, impact area (component), и приоритет (место в очереди на фикс), который выставлял РО.
   2. Project Status Report - отчет за спринт, отчет по велосити, version report, cumulative flow, обновленный Gantt Chart с майлстоунами