Избежание ловушки "изобретения велосипеда"

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

Проблема многих организаций заключается в том, что они не обладают таким количеством документированной информации об их ИТ-инвентаре, поэтому они не в курсе всей проблемы. Для того чтобы обойти это препятствие, вам стоит учесть три независимые области:

1. Доступность информации
2. Процесс утверждения
3. Культурные изменения

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

Инвентарь приложений

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

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

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

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

Процесс утверждения

Методология на основе процесса «стадия-ворота» (Stage and Gate) является очень эффективным процессом для оценки предложений проекта путем передачи их через серию "ворот" для того, чтобы оценить их значимость для организации. В отличие от многих других методологий, где проект утверждается в самом начале своей жизни и затем беспрепятственно приводится к нужным целям, методология "стадия-ворота" используется для оценки проекта на нескольких этапах его жизненного цикла. Таким образом, организация подтверждает, что ожидаемая выгода до сих пор значительна и что проект значим, и будет иметь положительное влияние. В противном  случае, он может быть остановлен до получения результатов, при этом сохранятся деньги и появится возможность рационально использовать ресурсы в других проектах.

1. Ворота концепции (Concept Gate) предоставляют видимость запланированных проектов и возможность определить области действительного и потенциального дублирования
2. Ворота решения (Decision Gates) представлены в виде устава (Charter), контракта (Contract) и сворачивания проекта (Rollout) - это ворота типа 'проход разрешен/проход запрещен'
3. Ворота качества (Quality Gate) - это ворота запуска (Launch Gate), которое используется для проверки качества и завершенности
4. Не все решения выполняются в "воротах" - есть и исключения

Проверка на существующие приложения должно быть частью процесса одобрения проекта в "воротах" устава (charter) или концепции, поддерживаемого людьми, производящими утверждения, и сотрудниками офиса поддержки проекта.

Культурное изменение

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

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

Преимуществами повторного использования являются:

• Высокое качество (товар опробован и протестирован)
• Меньшее количество работы (все ошибки были замечены и исправлены)
• Меньше затрат (оплачиваются только определенные изменения и корректировка)
• Скорые сроки (большая часть требований клиента уже реализована)
• Выше уровень удовлетворенности клиента (меньше ошибок и быстрое нахождение нужного решения)
• Простота (менее сложное портфолио приложений организации)

Вот несколько шагов, которые может предпринять организация для уменьшения дублирования приложений:

• Создайте инвентарь приложений - документируйте все ваши приложения, бизнес-процессы и технологии
• Сделайте инвентарь доступным в вашей интрасети
• Избегайте синдрома "не нашего изобретения" путем позитивного одобрения и поощрения повторного использования
• Реализуйте процесс утверждения проекта и используйте его для того, чтобы вы могли определить и устранить дублирование
• Используйте ваш офис поддержки и проектов, и людей, производящих утверждения, поддерживайте и берите инициативу в случае необходимости

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

Duncan Haughey