Разрушаем миф о незаменимости программистов

 

Какой из продуктов можно передать на стороннее обслуживание или доработку? Этот вопрос задает себе любой менеджер проектов по разработке программного обеспечения. Ответ, на наш взгляд, имеет два аспекта: технический и стратегический.

 

Рассмотрим подробнее технический аспект. На первый взгляд кажется, что далеко не каждый проект можно передать на аутсорсинг. Некоторые продукты написаны на скорую руку, без документации. Другие сделаны непрофессионально и работают с трудом: исправление одной ошибки добавляет две новые. Очень часто в проекте есть незаменимые люди, без которых работа остановится. Или, по крайней мере, они так говорят, создавая миф о своей незаменимости, — ведь принадлежность к «клану избранных» дает больше возможностей совершать разного рода оплошности.

 

Что же обуславливает возможность аутсорсинга?

1. На первом месте стоит качество кода: его архитектура, объектная модель, грамотное разделение на модули. Опытному программисту, чтобы во всем разобраться, достаточно лишь хорошего кода.
2. Хороший код уже сам по себе прокомментирован правильными наименованиями объектов и методов. Но дополнительные комментарии не помешают.
3. Затем идет качество тестирования и сборки. Как правило, написанные на скорую руку приложения собираются и работают только на нескольких компьютерах или под определенной версией ОС. Хорошо покрытый тестами код без проблем соберется и заработает как положено.
4. Наличие документации для пользователя и для программиста позволит даже не посвященному в технологию специалисту очень быстро освоить предметную область.

 

Так чего же хотим мы, менеджеры и владельцы интеллектуальной собственности? Мы хотим контролировать продукт. И мы не хотим, чтобы внезапная болезнь или увольнение «того парня» вызвали полный паралич деятельности компании, разрыв партнерских связей, потерю аудитории, негативную реакцию рынка и попадание в заголовки новостей. Следовательно, ключевой продукт должен быть настолько качественным, чтобы в любой момент он мог быть передан другой команде разработчиков.

 

Поэтому для ключевых продуктов необходимо:

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

 

Так какой продукт можно передать на аутсорсинг? Эффективный собственник на стороннее обслуживание может передать любой программный продукт. И это ответ на технический аспект вопроса.

 

А какие стратегические предпосылки заставляют отдавать проект на аутсорсинг?

• Не хватает ресурсов.
• Не получается привлечь достаточно хороших программистов.
• Нанять новых людей не позволяют корпоративные стандарты.
• Штатных специалистов хватает только на то, чтобы обслуживать систему.
• Есть потребность расширить команду специалистами из другого региона.
• Необходимо устроить конкуренцию в коллективе.
• Возникла потребность освежить продукт новыми идеями.
• Требуется провести стороннее тестирование.
• Нет желания организовывать работу большого офиса, вместо этого удобнее купить организованную рабочую силу.

 

Отдавая проект на аутсорсинг в EDISON, партнер решает стратегические задачи, получая взамен высокое качество своего программного продукта.