Результаты нескольких встреч наводят на мысли, что заказчики, попробовавшие воспользоваться услугами распределенной (удаленной) командой разработчиков, разочаровались в этой идее, даже исходя из того, что смогли существенно сэкономить.

Пример №1

Заказчик нанимает удаленную команду для того, чтобы разрабатывать новый продукт, который собирается затем продавать на рынке конечным потребителям. Идея понятна: видим потребность в продукте, думаем что мы могли бы предложить клиентам, нанимаем исполнителей, которые идею претворяют в жизнь. Звучит отлично и даже работает, как говорится, проверено на себе.

Продукт развивается и от команды разработчиков требуют уже не просто реализовывать идеи заказчика, но также и активно участвовать в развитии самого продукта. Ну почему бы и нет, однако, причем тут удаленная команда разработчиков?

Развивать продукт, поместить команду в информационное поле всяческих проблем по проекту, хотелок и пыхтелок, ну почему бы и нет. Только кто тогда будет вести разработку? Однако, сложности вовлечения удаленной команды в маркетинг и продуктовый менеджмент воспринимаются как отрицательный опыт работы с удаленной командой разработчиков.

На мой взгляд, в данном случае, от удаленной команды хотят получить больше, чем то, ради чего она существовала.

Пример №2

Заказчик нанимает нескольких фрилансеров для того, чтобы разработать специфичный продукт для собственных нужд, который впитает некоторые know how самого заказчика. При этом группой этих фрилансеров руководит бизнес-пользователь, который в процессах разработки особенно ничего не понимает. Проект вяло тянется, ожидаемого эффекта заказчик не получает и понимает, что лучше потратить в пять раз больше денег, но создать свою частную контору, посадить туда разработчиков и все проблемы решатся.

Что естественно, проблемы не решились, ведется по-прежнему вялая разработка, по-прежнему нет руководителя всего этого безобразия, но, что уже хорошо, появился Agile-коуч.

Надеяться, что несколько независимых разработчиков (фрилансеров в данном случае) объединятся в команду и будут производить высокого качества продукт в нужные сроки - крайне рискованное занятие. Конечно бывают иключения, но нанимать в таком случае лучше всего удаленную команду, которая сработалась и уже знает свои основные параметры: скорость и эффективность (подробнее о них читайте в посте "Agile: использование velocity").

Не нужно путать удаленных работников с удаленной командой. Обязательно нужно использовать инструмент для совместной работы, мы рекомендуем DEVPROM как идеальное решение для распределенных команд, реализующее основные практики Agile.

Пример №3

Заказчику требуется разработать программное решение для автоматизации деятельности собственных сотрудников, ну то есть тех, кого называют бизнесом. Попробовав воспользоваться услугами аутсорсеров или консультантов, заказчик решает, что для них дешевле и быстрее будет сформировать свой отдел разработчиков, тестировщиков и аналитиков, кормить их высокими зарплатами и социальным пакетом.

Мне понравились причины, побудившие сформировать свой отдел. И это в условиях, когда каждый бизнес старается избавиться от непрофильных активов.

• Дороговизна консалтинговых услуг - суть решения проблемы заказчика заключалась в покупке услуг консультантов одной из крупных софтверных компаний, которые должны были настроить свою систему под указанные нужды. Одни только первоначальные совещания обошлись в кучу денег. Заказчик потратил деньги, понял, что больше не хочет и написал систему самостоятельно.
• Излишняя формализация процесса - решение проблемы заказчика должна была осуществить компания аутсорсер, которая в целом неплохо себя зарекомендовала. Заказчик не захотел с ними работать, поскольку процесс формализации задачи (подготовка и согласование ТЗ) занимает больше времени, чем их собственный сотрудник набросает решение на коленке. А также потому, что заказчик не видит хода процесса и не участвует в принятии важных для конечного продукта решениях.

С дорогими консультантами все понятно, но вот отказываться от формализации задачи из-за того, что это долго - звучит несколько странно. Еще более странным кажется преимущество собственных разработчиков, для которых допускается множество поблажек (ну ведь он же наш сотрудник), как-будто ему не важно формализовать требования, а бесчисленное количество итераций в таком случае особенно никого и не пугает.

На мой взгляд, подобный подход в итоге приведет к тому, что компания получит огромный объем самописных решений, по которым нет требований, которые никто не умеет полноценно использовать и тем более страшно менять.

А причина в целом довольно простая:

• Отсутствие инструмента, который позволит заглянуть в текущий ход проекта.
• Отсутсвтие инструмента, при помощи которого заказчик и испольнитель эффективно могли бы управлять ожиданиями своего бизнеса.
• Отсутствие инструмента, в котором была бы возможность совместной работы над артефактами проекта.

Если бы они использовали DEVPROM, в котором все эти проблемы решены, то получили бы максимальную выгоду при реализации нужных решений.

Еще интересные статьи на эту тему: