Почему угасает вера в распределенную разработку
Результаты нескольких встреч наводят на мысли, что заказчики, попробовавшие воспользоваться услугами распределенной (удаленной) командой разработчиков, разочаровались в этой идее, даже исходя из того, что смогли существенно сэкономить.
Пример №1Заказчик нанимает удаленную команду для того, чтобы разрабатывать новый продукт, который собирается затем продавать на рынке конечным потребителям. Идея понятна: видим потребность в продукте, думаем что мы могли бы предложить клиентам, нанимаем исполнителей, которые идею претворяют в жизнь. Звучит отлично и даже работает, как говорится, проверено на себе.
Продукт развивается и от команды разработчиков требуют уже не просто реализовывать идеи заказчика, но также и активно участвовать в развитии самого продукта. Ну почему бы и нет, однако, причем тут удаленная команда разработчиков?
Развивать продукт, поместить команду в информационное поле всяческих проблем по проекту, хотелок и пыхтелок, ну почему бы и нет. Только кто тогда будет вести разработку? Однако, сложности вовлечения удаленной команды в маркетинг и продуктовый менеджмент воспринимаются как отрицательный опыт работы с удаленной командой разработчиков.
На мой взгляд, в данном случае, от удаленной команды хотят получить больше, чем то, ради чего она существовала.
Пример №2Заказчик нанимает нескольких фрилансеров для того, чтобы разработать специфичный продукт для собственных нужд, который впитает некоторые know how самого заказчика. При этом группой этих фрилансеров руководит бизнес-пользователь, который в процессах разработки особенно ничего не понимает. Проект вяло тянется, ожидаемого эффекта заказчик не получает и понимает, что лучше потратить в пять раз больше денег, но создать свою частную контору, посадить туда разработчиков и все проблемы решатся.
Что естественно, проблемы не решились, ведется по-прежнему вялая разработка, по-прежнему нет руководителя всего этого безобразия, но, что уже хорошо, появился Agile-коуч.
Надеяться, что несколько независимых разработчиков (фрилансеров в данном случае) объединятся в команду и будут производить высокого качества продукт в нужные сроки - крайне рискованное занятие. Конечно бывают иключения, но нанимать в таком случае лучше всего удаленную команду, которая сработалась и уже знает свои основные параметры: скорость и эффективность (подробнее о них читайте в посте "Agile: использование velocity").
Не нужно путать удаленных работников с удаленной командой. Обязательно нужно использовать инструмент для совместной работы, мы рекомендуем DEVPROM как идеальное решение для распределенных команд, реализующее основные практики Agile.
Пример №3Заказчику требуется разработать программное решение для автоматизации деятельности собственных сотрудников, ну то есть тех, кого называют бизнесом. Попробовав воспользоваться услугами аутсорсеров или консультантов, заказчик решает, что для них дешевле и быстрее будет сформировать свой отдел разработчиков, тестировщиков и аналитиков, кормить их высокими зарплатами и социальным пакетом.
Мне понравились причины, побудившие сформировать свой отдел. И это в условиях, когда каждый бизнес старается избавиться от непрофильных активов.
С дорогими консультантами все понятно, но вот отказываться от формализации задачи из-за того, что это долго - звучит несколько странно. Еще более странным кажется преимущество собственных разработчиков, для которых допускается множество поблажек (ну ведь он же наш сотрудник), как-будто ему не важно формализовать требования, а бесчисленное количество итераций в таком случае особенно никого и не пугает.
На мой взгляд, подобный подход в итоге приведет к тому, что компания получит огромный объем самописных решений, по которым нет требований, которые никто не умеет полноценно использовать и тем более страшно менять.
А причина в целом довольно простая:
Если бы они использовали DEVPROM, в котором все эти проблемы решены, то получили бы максимальную выгоду при реализации нужных решений. |
Еще интересные статьи на эту тему: |