Когда мы свою маленькую сплочённую команду продаём на время заказчику, ненадолго, для решения его плохо сфорумлированных задач
Огонь! Я для такого кейса несколько рисков могу озвучить, по идее которые должны перекрываться контрактом. Расскажу историю из своей работы, может будет вам полезна. Один крупный заказчик имея продукт в комплексной среде решил разработать его с использованием Scrum, там было три команды, в которых часть разработчиков и все тестировщики были взяты у субподрядчика на аутстафф. Лучшим решением было посадить их к себе в офис, что заказчик и сделал, процесс бы шикарный и все работало, ровно до момента выхода продукта в реальный прод. Выяснилось, что интеграционные и регрессионные тесты делать долго... реальзо заказчик сделал глупость, цикл регресса занимал 2 недели (и спринт был 2 недели), заказчик позволил сделать так: тестировщики из 3-х скрам команд просто встали и ушли делать регресс... через спринт они вернулись с пачкой багов, которые разрабы смогли за день поправить... тестировщики встали и ушли опять на регресс. Благодаря сложной инфраструктуре заказчика было 6 циклов регресса (были проблемы еще с интеграцией с другими подрядчиками и с работой инфраструктурных команд). Оказавшись без тестировщиков остатки скрам команд (аналитики и разработчики) подумали, что неплохо бы чем то заняться и они стали делать версию продукта 1.1 (а на регрессе была версия 1.0), когда меня пригласили покоучить ребят, уже шел 5ый цикл регресса, команды уже доделали все что хотелось сделать для версии 1.1 и начали делать версию 2,0 (к которым еще ни один тестировщик не притронулся). Это был лютый треш... я пошел к тестировщикам и спросил:
- Сколько у вас тест-кейсов?
- Около 800
- Сколько из них проверяют критичные для бизнеса процессы?
- Около 75
- Вы можете поправить тест-кейсы так, чтобы в них могли разобраться разработчики и попытаться их автоматизировать?
- Да, можем
Пошел к разрабочикам:
- Ребята, вы на чем пишете?
- На JAVA
- А вам не в падлу будет изучить Selenium и закодить тест-кейсы на нем, чтобы автоматизировать регресс?
- Не в падлу, это то же программирование
- А вам не в падлу будет потом тестировщиков обучить тому как вы это сделали?
- Конечно не в падлу, это же наши ребята, мы с ними сдружились
По сути я хотел, чтобы разработка версии 2.0 остановилась и мы постарались как можно быстрее автоматизировать регресс, чтобы он занимал 2-3 дня и могли дальше работать командами в спринтах. С этой инициативой я пошел к руководству. Руководству понравилось, оно пошло к еще большему руководству (это был очень большой энтерпрайз) и то руководство инициативу зарубило. Вердикт такой: прграммисты пусть продукт пишут, а если мы тестировщиков обучим автотестированию, то компания аутстаффер поднимет цену на услуги тестировщиков - автотестер стоит дороже! Пообещали, что выдадут в команды 3-х автотестеров из внутреннего центра компетенций, но мы то знаем, что это проблему не решит и они никогда не нагонят автотестами всю текущую разработку. Из этого кейса можно вытащить много разных вещей... что полезно компании аутстафферу - заказчик может не хотеть платить за время, в которое команда будет совершенствовать свои навыки и процессы работы ибо эта команда может начать стоить дороже. Постарайтесь такого не допускать при составлении контракта