В свете приближающейся конференции SEC(R) 2008, Асхат заставил меня написать небольшую заметку о современных тенденциях в мире разработки софта. Судить о таких вещах я могу только с нашей колокольни, поэтому все сказанное не претендует ни на объективность, ни на уникальность.
Любая компания, не обязательно софтверная, пытается оптимизировать процесс так, чтобы снизить расходы и как можно быстрее вывести продукт на рынок. В дополнение к этому, некоторые стараются вынести как можно больше непрофильных ветвей бизнеса за пределы компании. Как правило, для этого используют услуги аутсорсинговых компаний, эффективность которых последнее время сильно снизилась за счет роста зарплат и глобального финансового кризиса. Вектор географии аутсорсинга зависит от стоимости услуг и направлен из Восточной Европы в Россию, Индию, затем в Китай, Вьетнам и хрен знает куда еще. Более дешевые разработчики производят все менее качественный код и начинает складываться впечатление, что эра аутсорсинга, по крайне мере в России, подходит к концу.
Аутсорсинг предполагает одну, а чаще несколько дешевых, но распределенных в пространстве и времени локаций разработчиков, что практически исключает возможность нахождения заказчика на территории исполнителя. Добавим сюда культурные и языковые барьеры, и плохое знание аутсорсером предметной области. Все это снижает эффективность коммуникаций и приводит к необходимости составления детальных требований, длительным согласованиям и малоэффективным телефонным конференциям.
В большинстве случаев, на помощь обоим сторонам здесь приходят такие процессы, как CMMI, TSP или RUP, которые предусматривают большое количество документации, снижают риски (теоретически) и на выходе дают проект с фиксированной ценой. Но при этом крайне мучительно переносят любые изменения требований, являются достаточно тяжеловесными, затратными и мало приемлемыми для мелких и средних компаний/проектов.
Системы change management в большинстве случаев приводят лишь к новому витку документирования, в результате клиент платит за документы, а не за продукт. Agile, в свою очередь, сильно лихорадит от распределенных команд и удаленного продакт овнера. Agile мало применим для проектов с фиксированной ценой, что зачастую напрочь лишает заказчика психологического комфорта. Похоже, что для Agile процессов нет места в аутсорсинге, но тенденции меняются.
Средние и мелкие компании проявляют все больший интерес к услугам аутсорсинга, при этом их основная цель не экономия, а профессиональный сервис. Другими словами они заинтересованы, чтобы кто-нибудь хорошо и быстро делал за них непрофильную работу, и при этом не задавал лишних вопросов. Поэтому в большинстве случаев, аутсорсер меняет статус в глазах клиента и вместо временно-рабочего становится постоянным партнером, замотивированным на общий успех большого проекта, в создании которого он принимает участие. Но при этом заказчик должен быть уверен, что исполнитель обладает достаточными профессиональными навыками и знаниями в предметной области, чтобы провести необходимую техническую экспертизу, и обеспечить необходимое качество и скорость разработки.
Все это фактически убирает привязку к фиксированной цене и отменяет необходимость нахождения заказчика на территории исполнителя. В этих условиях Agile позволяет разработчику действовать достаточно эффективно, а клиенту не брать на себя дополнительные риски. Это наводит на мысль, что в скором будущем, заказчики аутсорсинга будут предпочитать работать с более дорогими, но профессиональными и стабильными командами...
| Было | Стало | |
| Мотивацая на быстрое завершения своей части работы | > | Мотивация на успех проекта |
| Waterfall | > | Agile |
| eMain и телефонные конференции | > | Web 2.0 |
| Детальные требования и регулярные телефонные конференции | > | Исполнитель хорошо знает предметную область |
| Крупные компании | > | Средние и мелкие компании |
| Снижение расходов, низкая стоимость труда аутсорсера | > | Высокая скорость и качество разработки |
| Временный контракт | > | Аутсорсер – это компания-партнер |
