В данном разделе мы рассмотрим набор требований к команде, которую вы ожидаете получить во время исполнения проекта. Состав и качество команды имеет прямое влияние на качество и стоимость проекта. Адекватность команды сути проекта и характеру среды проекта имеет прямое влияние на риски проекта. Поэтому требования к команде – это важная часть вашего “ТЗ”
Краткая версия всего что написано ниже — что вы должны указать в требоваиях к команде:
- Состав команды — сколько и какого типа команды вы ожидаете (разработка, проектирование, внедрение, …)
- Роли в команде — количество, кто обеспечивает. Исключенные роли указать с пояснением
- Требования к ролям — стандартные набор требований к опыту и компетенциям. Подумайте о специфике проекта
- Процесс работы команды — как вы планируете организовывать работу команд (Agile, Scrum, Waterfall)
- Обеспечение команды – какие сертификаты и лицензии должны быть у команды, кто за это платит
В зависимости от сложности проекта у вас может быть разная детализация требований к команде. Далее подробнее разбираем аспекты формирования команды.
Цена команд
Перед тем как написать много деталей о правильном и полном составе команд, обо всех изощренных требованиях – я хочу отметить что очень легко написать правильный состав команд — включить все виды ролей, указать полный состав менеджмента и обеспечения. Но это не значит что эти требования приведут вас к успеху.
Но надо помнить ряд важных моментов:
- Деньги. За каждой ролью стоит FTE (Full Time Employee) с ценой работы. Цена специалиста может варьироваться от 4K$ до 10K$ в месяц (зависит от страны, компетенций, спроса). Привлечение трех дополнительных синьоров могут добавить около четверти миллиона долларов к бюджету проекта на год.
- Сложность коммуникаций. Увеличение размера одной команды создает серьезные риски ухудшения качества и увеличение сложности коммуникаций. Оптимальная команда это 5-7 человек.
- Интерес проекта. Если проект скучный и простой — привлечение overqualified может быть не только неэффективно по деньгам, но и создавать демотивацию для команды. Хотя есть определенная категория специалистов которые ценя шаровые назначения.
- Наличие специалистов. Сейчас наблюдается явный дефицит на качественных специалистов. Вы и ваш проект не пуп земли и не явление Чуда народу — не факт что в момент вашего старта будут свободные эксперты или им будет интересен ваш проект.
Деньги — сильный охлаждающий фактор по всему что будет написано ниже — десяток божественных синьоров и троица сексуальных тестировщиц по вашему же решению превратятся в пару поюзанных гоблинов-свитчеров с жестким мидлом. Перед тем как требовать определенный состав и уровень компетенций — выполните небольшое упражнение по расчету денег:
- Получите информацию по уровню зарплат в стране найма. Информация доступна в виде аналитических отчетов в свободном доступе, есть сайты вакансий.
- Оцените длительность проекта. Будьте пессимистичны.
- Проведите вычисление — по каждой роли выполните расчет: Зарплата x 1,5 x N месяцев проекта x % Загрузки
- Просуммируйте по всем ролям.
- Добавьте риск в процентах — риск на неточность требований, на ошибки планирования
Повторите это упражнение после просмотра ролей и требований к ним. Держите под контролем ожидаемые косты.
Урезание хотелок
Используйте оценку по стоимость роли и команды в целом для подготовки себя к встрече с реальностью. Проведите ряд подготовительных упражнений:
- Формирования своих ожиданий — возможно вам придется смириться с неидеальностью команды, понять объективные факторы
- Формирование бюджета — заранее запланируйте больше денег. Если деньги ограничены (а они всегда ограничены) – рассматривайте далее
- Поиск баланса цена-качество — понизить планку качества или упростить требования.
- Пересмотр целевых технологий — возможно вы измените платформу ради поиска лучшей проектной цены
- Баланс между разработкой и кастомизаций — вы можете заменить разработку с нуля на разработку с использованием платформ. Что может привести к возникновению лицензионных затрат.
- Поиска компенсаций внутри бизнеса — ряд ролей могут быть обеспечены штатными сотрудниками
- Планирования создания у себя дополнительных компетенций — до проекта, параллельно, после (передача)
Не падайте в депрессию от стоимости человека — да, при средней рыночной зарплате хорошего (но не божественного) специалиста в 3500$ вы получите порядка 5500$ затрат в месяц, а для синьоров — это будет уже около 7000$ в месяц. Чтобы не так переживать учтите несколько факторов:
- Это рынок. Спрос и политика работодателей формирует цену.
- Стоимость найма — это не только 1-2 месяца на поиски, но и возможно 1-2 зарплаты как стоимость найма
- Риск найма не того человека — деньги и время ушли, а человек не тот.
- Риск того что вы не сможете мотивировать работой напрямую или только на короткий проект.
- Стоимость налоговых платежей для вашего бизнеса
- Стоимость менеджмента в вашем бизнесе для нового человека.
- Стоимость отпуска, больничного, увольнительных
- Риск потери и повторного найма
Состав команд
Большой проект по разработке программного обеспечения может быть разбит на несколько команд. В сложных проектах структура команд может быть сложной:
- Команда владельцев продуктов — для больших продуктов и программных решений собирается несколько команд разработки. У таких команд могут быть отдельные владельцы продуктов. В свою очередь владельцы продуктов должны синхронизировать свою работу. Отличный повод создать команду.
- Команда анализа и проектирования — для очень больших проектов может быть несколько команд анализа и отдельные команды проектирования.
- Выделенная команда бизнес анализа. Особенно важно когда в проекте большой набор требований к проработке и работа с требованиями будет вестись параллельно разработке ранее согласованных требований.
- Выделенная команда архитекторов. Для проектов сложных архитектурно и технологически может создана отдельная команда из архитекторов (2-3 человека)
- Команды разработки — укажите или общее количество разработчиков и рекомендуемый размер команды или сразу жестко описывайте требуемый состав команд.
- Команды инженерного обеспечения процессов – DevOps. автоматизаторы, поддержка ALM систем
- Команды качества разработки — сюда входят лиды разработчиков которые задают стандарты и проводят периодический внутренний аудит
- Команда внедрения — кто будет заниматься развертыванием, настройкой, обучения
- Команда поддержки — кто должен представлять 1-2-3 линии поддержки решения
Состав команды разработки
- Владелец продукта (Product Owner) – часто является представителем клиента. Главное честно ответить себе на вопрос – а есть ли для этого ресурс времени, мотивация и компетенции
- Заместитель (и.о.) владельца продукта (Proxy Product Owner) – когда основной владелец продукта реально очень занят — стоит создать его “двойника”. Часто эту роль выполняет бизнес аналитик. Но очень важно понимать что БА в роли PPO получает дополнительные управленческие полномочия и влияет на определение как минимум тактики разработки продукта.
- Управление или обеспечение работы команды – Delivery Manager, Scrum Master, Project Manager
- Разработчики (Developer / Software Engineer) – подумайте о составе Front, Back и разработчиков интеграционных частей
- Тестировщики (Quality Assurance) – подумайте о функциональных (часто мануальных) тестировщиков, автоматизаторов, лидов (кто будет управлять группой тестировщиков, планировать тестирование)
- Инженеры DevOps – небольшое DevOPs инженеров создаст очень важную инфраструктуру из сред и автоматических процессов
Роли команды
Проверьте насколько вам необходимы специфические роли. Рекомендуем составить несколько списков:
- Список требуемых ролей
- Список ролей со стороны заказчика
- Список ролей от которых сознательно отказались
- Список ролей которые могут потребоваться или нужны на непостоянной основе (on demand)
Если роль не нужна — укажите почему и как она будет компенсирована. Например — мы отказываемся от роли QA (тестировщика) так как считаем что разработчики должны проверять сами и мы как бизнес также подключимся к тестированию. Убедитесь что вы уверены в отказе от роли.
Очевидные Компетенции команды
Формирование требований к команде — это в некотором смысле объявление вакансии. Так оно и есть — вы определяете требования не только к команде в целом, но и задает требования по найму ее отдельных членов. Для малых проектов вы можете опустить много деталей, но для проектов которые вписываются в существующий поток разработки и для стратегических проектов вы не можете себе позволить что вам обеспечат хорошую команду и должны сознательно сформировать требования к команде:
- Годы опыта в заданной роли — иногда опыт очень важен. Опасайтесь синьоров со стажем 3 года работы после института.
- Непрерывность работы — частые смены проектов и работодателей — очевидный риск того что вы потеряете человека в неподходящий момент по ходу выполнения проекта.
- Уровень компетенций по целевыми технологиями проекта — важно точно написать технологии, опыт в ней и уровень синьорности. Только убедитесь что технология существовала столько лет.
- Опыт работы с целевыми инструментами проекта — укажите инструменты ALM, IDE, другие специальные инструменты
- Опыт работы с прикладным доменом — если вы банк то вряд ли вам сильно поможет человек с опытом работы в медицинских проектах
- Эмоциональный интеллект — подумайте хорошо насколько в вашем болоте нужные про-активные люди или вы ожидаете что команда будет драйвить и челленджить ваш застоявшийся бизнес. Нельзя набрать команду по здоровью, а потом требовать от нее по уму.
Неочевидные компетенции команды
Проекты имеют свои особенности — иногда именно они становятся решающими для выбора специалистов. Ньансы происходят часто из-за страновых и отраслевых специфик проекта:
- График командировок — лучше сразу указать частоту и длительность командировок. Идеал – когда известны даты на несколько месяцев вперед. Вместе с требованиями стоит указать в примечаниях ожидаемое обеспечение.
- Режимы длительной on-site работы — для команды или определенных ее ролей вы можете потребовать исключительность работы в вашей стране или на территории вашего бизнеса. Возможен даже запрет работы в ином другом месте (типичные требования для специфических финансовых инструментов и государственных проектов ряда стран)
- Время работы — время работы команды, как правило, синхронизируется со временем работы клиента. Часовые пояса иногда играют важную роль.
- Расовые, половые, страновые и другие дискриминационные требования — это почти шутка, но не совсем— есть клиенты у которых есть специфические страновые конфликты, есть радикальные религиозные моменты, есть страны где не приветствуются незамужние девушки младше определенного возраста, есть страны куда не стоит в принципе приезжать людям с определенной сексуальной ориентацией (во избежание казни). Давайте будем честно указывать все эти требования.
- Режим локации работы команды — какие требования вы выдвигаете к помещению в котором будет работать команда. Разрешается ли в одном помещении с данной командой работать специалистам из других проектов, какой режим доступа в данную комнату, какая защита на окнах. Вопросы физической защиты команды, помещения команды. Это частые требования для проектов автопрома, финансовых проектов.
- Понимание страновых законодательных ограничений и специальных условий – мне приходилось работать в стране где при вьезде я подписывал бумажку о том что я уведомление о том что в стране действует смертная казнь и она может быть ко мне применена. Об этом вы должны предупреждать до начала проекта.
- Понимание ответственности проекта — сравните проект с запуском электронного магазина и проект управление кардиостимулятора с прямым влиянием на жизнь пациент (баг = минус жизнь). Вы должны убедиться за ранее что сотрудник понимание с какой ответственностью он столкнется в проекте. Далеко не все разработчики в принципе готовы браться за ответственные проекты.
- Риски ответственности — на текущий момент есть проекты где у команды просят подписать документы не только о разглашении, но и о том что они понимают применение к ним определенных санкций и ответственности. Иногда даже в юрисдикции других стран. Если у вас очень-очень ответственный проект (оборона, здравоохранение, безопасность, особо опасные исследования) – возможно это тот самый случай когда вы должны озвучить правила игры.
- Специальные доступы и допуски — ряд проектов могут быть выполнены в режиме допуска и доступа к государственной тайне. Это не только целая процедура, не только большая ответственность, не только дополнительные риски, но и ограничения свобод не только во время, но и после проекта.
- Понимание культурных особенностей клиента — проекты могут встречаться в разных уголках земного шара. Культурный код стран и регионов может очень отличаться и далеко не всегда подходить определенным членам команды. Вам нужно минимизировать конфликты, изначально позаботиться о совместимости культурных кодов. Или спланировать культурную адаптацию команды и заказчика друг к другу.
Процесс работы команды
Самый простой момент в требованиях – но с подвохом. Вы можете быстро выбрать Agile/Scrum, мало кто сегодня сознательно и честно указывает Waterfall. Но постойте не секундочку и попробуйте ответить на пару вопросов:
- Как работают ваши коллеги? Все другие проекты по Agile?
- Понимает ли выбранный подход другие подразделения вашего бизнеса? Что думает об Agile ваш финансовый директор?
- Вы готовы работать с командой без того что она отвечает за срок и бюджет проект по Agile?
- Вы ожидаете сначала полный анализ требований потом полную разработку?
- Какие у вас как у клиента внедрены инструменты управления проектом по выбранной вами методике? У вас есть Azure DevOps / TFS, Jira, Project Online?
- Какие конкретно процессы внедрены у вас? Как они описаны?
- Какой опыт у вас лично в роли менеджера по указанной методике работы? Или вы книжку прочитали?
- Кто с вашей стороны будет отвечать за налаживание ваших процессов,
- Кто с вашей стороны будет отвечать за управление проектом/продуктов
Бизнесу очень легко потребовать Agile и очень тяжело быть Agile. Процесс подразумевает не только определенный порядок работы — но и изменений мышления (мыслить в рамках итерации, перестроиться на фичи и пользовательские истории), использование других инструментов и оценок (вместо часов и дней — попугаи), участия (бизнес должен тратить свое время ежедневно). Вам будет как минимум некомфортно работать при разном mindset.
Выбранный процесс для работы команды — палка о двух концах. И самая острая часть смотрит как раз в вашу же сторону — насколько вы готовы работать в данном процессе? Хороший вопрос – и у вас может быть время до начала проекта подготовиться к этому. Не оставляйте на потом внедрение Agile!
Обеспечение работы команды
В обеспечении работы команды есть не очевидные моменты:
- Компьютер — кто предоставляет, какие требования к железу
- Рабочее место – у вас когда человек будет работать on-site.
- Лицензии — какие лицензии и на какие продукты должны быть. Кто платит. Это касается лицензий на средства разработки, на библиотеки разработки. Лицензии могут быть на платные версии Microsoft Visual Studio, на дополнительные инструменты повышения качества кодирования, на инструменты проектирования.
- Сертификаты — какие обязательные сертификаты должны быть у разработчика. Для определенных платформ это может быть критически важным требованием.
- Инфраструктура — сервера для разработки, тестовые стенды. Стоимость дополнительных учетных записей в вашем домене.
- Система ALM – Azure DevOps / TFS, Jira
- Система хранения артефактов и кода – Wiki, Git
Крайне внимательно отнеситесь к пункту 6 и 7. Если вы хотите действительно контролировать проект — обеспечьте запуск у себя сервисов 6 и 7. Это не так сложно как кажется — но очень важно для контроля работы. При наличии собственной системы ALM вы действительно будете видеть что и как делает команда. Внедрение своих систем контроля версий обеспечит вас больше уверенностью в том что вы контролируете код.
Каждый из пунктов содержит в себе дополнительные затраты и требует подготовки. Учтите это в своем плане подготовки к проекту.