Кризис среднего возраста

В последнее время в сфере идеологии ведения ИТ-проектов происходят активные движения на тему распространения модели аутсорсинга и построения выделенных девелоперских центров. Стремясь быть актуальным, я бы тоже хотел высказать пару слов на эту тему. Бестселлером они, эта пара слов, вряд ли станут, но может кому будут интересны и даже полезны.

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

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

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

А что же с проектированием информационных систем? Я думаю, все только начинается. Программная инженерия как наука, как отрасль только-только формируется. О том, как правильно разрабатывать программное обеспечение, человечество всерьез задумалось всего лишь лет тридцать пять назад. Согласитесь, даже со 150 годами эта цифра не идет ни в какое сравнение, а уж о десятках тысячелетий и говорить нет смысла. И если относительно возраста других отраслей 35 лет смотрятся по-юношески задорно, то в абсолютной величине этот возраст соответствует точке кризиса среднего возраста. Мы действительно имеем кризис – кризис идеологии как следствие экономического кризиса. Попытаюсь объяснить.

Те методологии, которые проповедовались в 70-ых – начале 80-ых годов, строились исходя из той предпосылки, что разрабатываемый софт должен быть максимально полезен тем, кто его использует. Жизненный цикл информационной системы должен был быть выстроен таким образом, чтобы реализованная система предельно полно отвечала требованиям (ожиданиям) Заказчика. При этом основную долю разработки необходимого софта организации осуществляли для себя сами, благо техника была слабой, а требования к автоматизации были невысокими.

Затем, в 90-ых годах, произошла некоторая трансформация методологий, предпосылкой для которой стало стремление крупных заказчиков (в первую очередь – федеральные органы США) гарантировать качество разрабатываемого для них программного обеспечения. Вызвано это было, видимо, тем, что прийти на рынок и выбрать такого вендора, который сможет эффективно решить поставленную задачу, стало очень не просто: по лицу программиста сложно сказать, на что он способен в коде. А между тем железо уже было вполне приличным и будоражило аппетиты любимых Заказчиков.

Именно в это время активно продвигаются всякие ISO, федеральные рекомендации, CMM, потом CMMI и прочие разные документы, в которых излагались требования, выполнение которых являлось признаком того, что вендор способен. И почва под ногами разработчиков пошатнулась: мало было уметь грамотно проектировать и писать код, нужно было иметь процесс.ПРОЦЕСС!

На подмогу разработчикам пришли разработчики. Самые известные из спасателей – это Microsoft и Rational со своими MSF и RUP. И вот в этот момент вместе с насаждением продуманных и по-большему счету грамотных методологий насаждается первый миф, который успешно прожил более десяти лет (точнее – до последнего кризиса): хочешь качественный продукт – плати много. И плюсом к нему – второй, как явное следствие CMMI: в условиях грамотно организованного процесса разработки успех проекта минимально зависит от квалификации привлекаемого персонала. Согласитесь, интересная позиция в результате получается: хочешь качественный продукт – плати много, а мы за эти деньги организуем процесс и будем делать проект с тем, кто под руку подвернется. Я утрирую конечно, но занятный вывод.

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

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

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

Сделать это оказалось крайне просто – достаточно было вывести свою ИТ-службу из состояния потребления в режим управления.

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

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

Но об этом – в следующий раз.

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы аналитика – а чем он занимается и чего можно померить?

Оценка эффективности работы руководителя проектов