Какой из продуктов можно передать на стороннее обслуживание или доработку? Ответ, на наш взгляд, имеет два аспекта: технический и стратегический.
Рассмотрим подробнее технический аспект. На первый взгляд кажется, что далеко не каждый проект можно передать на аутсорсинг. Некоторые продукты написаны на скорую руку, без документации. Другие сделаны непрофессионально и работают с трудом: исправление одной ошибки добавляет две новые. Очень часто в проекте есть незаменимые люди, без которых работа остановится. Или, по крайней мере, они так говорят, создавая миф о своей незаменимости, — ведь принадлежность к «клану избранных» дает больше возможностей совершать разного рода оплошности.
Что обуславливает возможность аутсорсинга?
| 01 |  |
На первом месте стоит качество кода: его архитектура, объектная модель, грамотное разделение на модули. Опытному программисту, чтобы во всем разобраться, достаточно лишь хорошего кода. | ||
| 02 |  |
Хороший код уже сам по себе прокомментирован правильными наименованиями объектов и методов. Но дополнительные комментарии не помешают. | ||
| 03 |  |
Затем идет качество тестирования и сборки. Как правило, написанные на скорую руку приложения собираются и работают только на нескольких компьютерах или под определенной версией ОС. Хорошо покрытый тестами код без проблем соберется и заработает как положено. | ||
| 04 |  |
Наличие документации для пользователя и для программиста позволит даже не посвященному в технологию специалисту очень быстро освоить предметную область. |
Так чего же хотим мы, менеджеры и владельцы интеллектуальной собственности? Хотим контролировать продукт. И не хотим, чтобы внезапная болезнь или увольнение «того парня» вызвали полный паралич деятельности компании, разрыв партнерских связей, потерю аудитории, негативную реакцию рынка и попадание в заголовки новостей. Следовательно, ключевой продукт должен быть настолько качественным, чтобы в любой момент он мог быть передан другой команде разработчиков.
Поэтому для ключевых продуктов необходимо следующее.
| 01 |  |
Гарантировать возможность замены всех разработчиков. | ||
| 02 |  |
Организовывать групповую разработку. | ||
| 03 | |
Регулярно проводить рефакторинг кода. | ||
| 04 |  |
Проводить регулярный аудит продукта, качества кода и документации, с привлечением независимых экспертов. | ||
| 05 |  |
Ответственно относиться к документации — именно она является залогом стабильности при обслуживании. |
Так какой продукт можно передать на аутсорсинг? Эффективный собственник на стороннее обслуживание может передать любой программный продукт. И это ответ на технический аспект вопроса.
Стратегические предпосылки аутсорсинга
- Не хватает ресурсов.
- Не получается привлечь достаточно хороших программистов.
- Нанять новых людей не позволяют корпоративные стандарты.
- Штатных специалистов хватает только на то, чтобы обслуживать систему.
- Есть потребность расширить команду специалистами из другого региона.
- Необходимо устроить конкуренцию в коллективе.
- Возникла потребность освежить продукт новыми идеями.
- Требуется провести стороннее тестирование.
- Нет желания организовывать работу большого офиса, вместо этого удобнее купить организованную рабочую силу.
Отдавая проект на аутсорсинг в EDISON, партнер решает стратегические задачи.
2002–2024