Мировой рынок аутсорсинга составил 85,6 млрд долларов США. Экономия средств, доступ к глобальным талантам, более быстрое время выхода на рынок, определение приоритетов основной деятельности и т. д. являются наиболее популярными причинами для этого. Но когда аутсорсинг программного обеспечения терпит неудачу, в большинстве случаев вышеупомянутые причины не имеют ничего общего с его неудачей.
Работа с командой оффшорного программного обеспечения требует внимания, общения и эффективного управления. Важно помнить, что аутсорсинг — это больше отношения, чем процесс.
Находясь в индустрии аутсорсинга программного обеспечения уже почти 8 лет, я составил список из пяти пунктов ошибок, которых следует избегать при аутсорсинге разработки программного обеспечения.
Ошибка № 1: Отсутствие исследований
Отсутствие исследований и должной осмотрительности в отношении ваших потенциальных поставщиков программного обеспечения увеличивает процент неудач вашего программного проекта в геометрической прогрессии. Давайте будем честными — вы ничего не знаете об аутсорсинговых фирмах, и есть большая вероятность, что вы не будете пить с ними кофе в долгосрочной перспективе.
Вот почему так важна надлежащая осмотрительность! Изучите своих поставщиков, так как аутсорсинг программного обеспечения имеет значительную ценность как с точки зрения времени, так и денег. Начните с поиска в Google ваших потенциальных фирм. См. их обзоры на независимых сторонних форумах. Взгляните на отзывы, которые они имеют на своем
Кроме того, внимательно изучите, знают ли они вашу отрасль. Если вы пионер в области медицины, вы не захотите нанимать человека, который понятия не имеет, что такое медицинская индустрия. Благодаря обзору отрасли и опыту работы как вашей компании, занимающейся аутсорсингом программного обеспечения, так и вам будет легче найти общий язык.
Ошибка № 2: Неясные требования к проекту
Из всех распространенных причин отказа от аутсорсинга программного обеспечения «У клиента неясные требования» на сегодняшний день является самой распространенной проблемой аутсорсинга. Для идеального анализа требований крайне важно, чтобы лицо, ответственное за проект, имело четкое представление о конечной цели и требованиях к программному обеспечению.
Анализ требований напрямую показывает, какие функции, атрибуты, функциональные возможности и свойства программного обеспечения необходимо реализовать. Это самый ответственный этап любого проекта. Если вы создаете приложение, перечислите все функции, которые вы хотели бы иметь в своем приложении, а также цель этих функций. Обсудите с вашей командой разработчиков программного обеспечения и поймите весь процесс. Если есть две конечные точки A и B, убедитесь, что и вы, и ваша команда знаете весь поток от A до B и документируете его.
Документирование требований помогает разработчикам работать лучше и быстрее, а также служит святым Граалем для вас и команды разработчиков, к которому можно прибегнуть в случае возникновения спора. Если этап анализа требований пойдет не так, окончательная оценка стоимости и сроков будут сильно отличаться от тех, которые были предоставлены вам изначально.
Ошибка № 3: недооценка обеспечения качества
Цель вложения огромных денег в разработку программного обеспечения состоит в том, чтобы в первую очередь обеспечить качество программного обеспечения. Хорошее программное обеспечение означает меньшее количество ошибок, интуитивно понятный пользовательский интерфейс и надежную логику в серверной части, учитывающую все варианты использования.
Качество программного обеспечения может быть обеспечено тщательным тестированием программного обеспечения с первого дня. Ваше программное обеспечение состоит из сотни компонентов и даже больше пользовательских потоков. Важно убедиться, что каждый из них работает до запуска программного обеспечения.
Пренебрежение контролем качества на начальном этапе означает осознанный огромный риск. Если ошибки появляются, когда ваше программное обеспечение работает, и над ним работают реальные пользователи, тестирование и отладка становятся сложными, трудоемкими, дорогостоящими и, что еще хуже, это ставит вас в невыгодное положение перед вашими конечными клиентами.
Обеспечение качества программного обеспечения экономит как ваши деньги, так и клиентов. Это предотвращает катастрофические корпоративные чрезвычайные ситуации, обеспечивает отличный пользовательский опыт и, наконец, способствует развитию организации, ее производительности и эффективности.
Ошибка № 4: Плохая коммуникация
Четкое общение между аутсорсером и аутсорсером имеет решающее значение. От описания ваших требований до получения программного обеспечения сделайте общение приоритетным и не позволяйте ему потеряться
Всегда находите единую точку контакта, устанавливайте несколько каналов связи, проявляйте инициативу и запрашивайте обновления. Когда вы получаете обновления, просматривайте их неукоснительно и оставляйте отзывы с предложениями.
Не вините в неудачах общения культурные различия или разницу часовых поясов. Если вы не общались в течение нескольких дней и ожидали, что будете молчаливы в своих требованиях, вы являетесь причиной того, что общение не удалось.
Ошибка № 5: Микроменеджмент
В то время как полная тишина не помогает, диктовать все тоже не помогает. Диктовка и микроуправление каждым процессом заставляет вашу команду разработчиков чувствовать себя неэффективной и некомпетентной. Кроме того, это мешает команде проводить мозговой штурм новых идей, следить за последними тенденциями и технологиями и включать их в ваше программное обеспечение.
Не поймите меня неправильно: прозрачность в процессе разработки программного обеспечения — это хорошо, микроуправление — это плохо. Необходимо следить за тем, на каком этапе находится ваш проект и какие функции еще предстоит сделать. Но спрашивать разработчиков, почему тот или иной компонент занимает так много времени или каждый час пинговать обновления, демотивирует и деморализует команду. Это, в свою очередь, оттолкнет вашу команду от принятия решений и приведет к провалу вашего программного проекта.
Вывод
В среднем 33% программных проектов превышают прогнозируемый график, и почти 66% программных проектов превышают прогнозируемую стоимость
