|
|
  |
Главная страница / Архитектура отрасли a + b ≠ с, или сеять или жать корпоративное знание?Информационные технологии как интеллектоемкая отрасль первой оценила значимость знаний, опыта, компетенций для эффективного бизнеса. Поэтому при обсуждении аутсорсингового договора или заявки на тендер обычными стали вопросы типа «У нас есть компетенции в этой области?» «Ну, прибыли в этом проекте будет немного, практически в ноль, но для референсов проект просто необходим!» Чем же таким специфическим должна располагать компания, чтобы успешно реализовать тот или иной ИТ-проект? Первый ответ очевиден: специалистами, людьми – носителями компетенций. Но как заказчик может определить, есть необходимые знания или нет? Достаточно ли подтвердить информацией об успешно реализованных проектах, рекомендациями (референсами) от крупных заказчиков-брендов? Информационный проект требует, с одной стороны, определенных (разного уровня) инноваций при сложности задач, обычно превышающих возможности отдельного эксперта, а с другой – эффективности в реализации требований заказчика и соблюдении бюджетов и сроков. Поэтому к первому ответу добавляется второй – взаимодействие экспертов, порождающее новый продукт или услугу. Повышению эффективности процесса разработки программного обеспечения служат отраслевые стандарты. Так, признанной является модель SEI CMMI, которая используется для совершенствования бизнес-процессов при разработке программного обеспечения. Сегодня это de facto стандарт для процессов разработки и сопровождения программной продукции. Соответствие фирмы требованиям CMMI – показатель признания компании как надежного разработчика программного обеспечения и поставщика услуг в области ИТ, налаженной системы взаимодействия квалифицированных специалистов. Модель CMMI выделяет пять уровней зрелости процессов в компании (см. рисунок). Фирма, находящаяся на первом уровне, может достичь успеха в разработке программного продукта, но это скорее случайный, чем закономерный результат: эффективность процесса зависит от конкретных исполнителей, а не поставленной системы их взаимодействия. Второй уровень характерен для компаний, которые могут не только достичь разового успеха, но и обеспечить его повторяемость в аналогичных проектах. Ключевой становится роль менеджера, который осуществляет формализацию процессов на уровне проекта. В компаниях, находящихся на третьем уровне, процессы формализованы и описаны на уровне организации. На четвертом – к шаблонам добавляются метрики, позволяющие количественно отслеживать процессы при разработке ПО и эффективно управлять ими (в том числе модифицируя определенные практики). Пятый, уровень «гуру», связан с внедрением системы инноваций и совершенствованием практик таким образом, чтобы предотвратить возможность возникновения ошибок. Позитивным в данной стандартизации является то, что она достаточно эффективна как при создании нового программного обеспечения, так и при оказании услуг в сфере ИТ (внедрении ПО). Ведь эти две части жизненного цикла продукта все чаще обслуживаются разными специалистами. Сейчас основным классом ИТ-экспертов становятся не чистые программисты, а консультанты, внедренцы решений от крупных вендоров. Классический пример – внедрение ERP-систем: в большинстве случаев внедренцы крайне неохотно идут на дописывание модулей и практик, ограничиваясь адаптацией заложенных в самом программном решении функций на уровне настроек. Уже эти вводные замечания показывают, что решение дилеммы «учить/перекупать» сложнее простого калькулятора затрат: как для специалистов разного профиля, так и для разных компаний в уравнение должны быть включены дополнительные неизвестные. Главная страница / Архитектура отрасли |