«Трудно заставить человека понять что-то, если от его непонимания зависит его зарплата», — Эптон Синклер, американский писатель.

Когда внутреннее программное приложение достигает критической массы, оно может превратиться в самодостаточную вотчину, которая генерирует работу намного дольше своего естественного срока службы, пишет на портале TechBeacon Стивен Фрейн, старший директор по разработке ПО компании Comcast.

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

Измерение истинной ценности внутреннего ПО

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

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

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

Конфликт интересов

Кто лучше всего подходит для вынесения таких экспертных суждений, учитывающих специфику области? Конечно, эксперты — это те, кто ближе всего к делу, это люди, которые ежедневно работают над приложением и его проблемами. Однако именно у этих людей возникает наибольший конфликт интересов при принятии таких решений, они также демонстрируют ограниченную способность учитывать альтернативные варианты. Команда, работающая над приложением, получает выгоду от своей связи с ним и, естественно, может задаться вопросом, что с ними будет, если дальнейшее развитие не понадобится. И потенциальный дискомфорт, и когнитивный диссонанс мешают им понять, что объект их усердных трудов, возможно, не стоит того, чтобы поддерживать его дальше, а поскольку они посвятили себя этому единственному приложению, им, вероятно, не хватает широты зрения, чтобы оценить достоинства других областей, в которых их время было бы потрачено лучше.

Эта касается не только технического персонала, работающего над приложением, но и владельцев продукта, бизнес-аналитиков и всех остальных, кто живет в этой вотчине. Более того, поскольку бóльшая часть инвестиций в разработку поступает от технической стороны, маловероятно, что призыв остановить разработку будет исходить от бизнес-стороны, если только у нее нет более приоритетных вещей, которыми должна заняться техническая команда. Легко найти разумное объяснение продолжения разработки, которая приносит мне пользу и финансируется из чужого бюджета.

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

Как избавиться от вотчин

Вотчины приложений увековечивают расточительный самоподдерживающийся цикл. Чем дольше команда работает над продуктом, тем более крепким и непримиримым становится ее противодействие прекращению его использования. Поэтому руководство должно разработать надежные способы выявления и разрушения вотчин приложений. Следующие четыре метода являются полезными вариантами для изучения.

1. Использовать модель возмещения затрат (chargeback model). Ее применение для финансирования разработки внутренних приложений изменяет экономику внутренней разработки, делая ее похожей на ту, которая регулирует разработку внешнего ПО. Когда бизнес-подразделения должны будут финансировать создание внутренних приложений, они будут более осмотрительны в отношении альтернативных затрат и более консервативны в оценке возврата инвестиций в разработку. Однако лишь немногие организации используют модель возмещения затрат для внутренней разработки, и ее внедрение является радикальным изменением. В зависимости от вашей ситуации, другие варианты могут быть более практичными.

2. Внедрить формальное управление портфелем. Формальный процесс управления портфелем внутренних приложений позволит установить четкие критерии отбора и рассмотрения проектов. Вначале приложение должно продемонстрировать, что оно может принести значимую отдачу, превышающую ту, которую можно получить от другой работы. В дальнейшем приложение должно регулярно проходить проверку, в ходе которой оно демонстрирует свою дальнейшую состоятельность. Формальный процесс управления портфелем позволяет поднять решения о разработке над ситуативным уровнем и превратить их в последовательный, дисциплинированный процесс, в котором критерии отбора проектов являются открытыми, и в ходе которого можно открыто обсуждать и сравнивать относительные достоинства различных инициатив. Хотя формальное управление портфелем целесообразно, для его эффективности требуется широкая организационная приверженность.

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

4. Запланированные перерывы в развитии. Если ни один из вышеперечисленных способов не сработал, может быть полезно установить организационную политику, которая ставит разработку приложений на паузу через регулярные промежутки времени. Например, за шестью месяцами разработки может следовать двухмесячная пауза, или за годом разработки может следовать квартал простоя. Такие паузы разрушают инерцию текущих усилий и гарантируют, что разработка начнется снова только при наличии спроса, достаточного чтобы преодолеть инерцию остановки. Из-за высокого уровня неопределенности этот метод следует использовать редко и только до тех пор, пока организация не сможет создать такую культуру, которая сделает его ненужным.

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