Когда-то давно, когда сегодняшние программисты, аналитики, и, наверное, даже менеджеры учились в ВУЗах, им рассказывали про мудрый принцип – сначала определяется задача, потом пишутся требования к продукту, а только потом выбирается технология. Так почему же получилось так, что в огромном количестве крупных проектов, разрабатываемых серьезными компаниями, встречаются технологии и инструменты, которые, мягко говоря, там не к месту? Неужели толпа хороших, высокооплачиваемых специалистов забыла один из основных принципов разработки?
Нет, все это помнят и понимают, но начинают играть роль нюансы, о которых при обучении никто не говорит.
Вендор
Когда серьезная организация ищет решение для своих серьезных проблем, она, как правило, обращается к гигантам вроде IBM или Microsoft. Или устраивает тендер, в котором, с большой долей вероятности, побеждают опять-таки монстры ИТ области. А эти компании давно уже перестали быть группами людей, решающих проблемы заказчика. Теперь это «великие вендоры». Лишь в некоторых случаях они сами что-то разрабатывают или внедряют. Обычно они продают одно из своих «коробочных» решений и передают заказ партнеру поменьше. А партнер уже допиливает решение под конкретного заказчика и внедряет его. Т.е. цель вендора не решить проблемы заказчика, а продать свои продукты.
Более того, партнеры так же стараются продавать как можно больше продуктов своего вендора, т.к. во-первых имеют с этого процент, а во-вторых успешные продажи поднимают их рейтинг и увеличиваю шансы на получение заказов от вендора. Т.е. «мы вам, вы нам, а между делом будем решать проблемы заказчика».
Например, консультант (читай «маркетолог») компании Microsoft убедил заказчика в том, что ему нужен BizTalk и MS CRM. После этого заказ передается одному из партнеров, допустим некоторой компании «А». Специалисты компании «А» изучают поставленные перед ними задачи, формируют требования к системе и понимаю, что проданные продукты – далеко не лучшее решение. Допустим, гораздо лучше было бы просто разработать пару веб-сервисов и чуть-чуть допилить уже имеющийся у заказчика внутренний портал.
Но отказаться от проданных продуктов нельзя! Вот и приходится использовать и «допиливать» их под решение неподходящей задачи. При этом растет стоимость и длительность работ, уменьшается качество конечного продукта, получается чугунная и неповоротливая система.
А ведь суть проблемы в том, что продукты и технологии выбирал не специалист, а продавец. Цель которого не оптимально решить проблему, а продать наиболее дорогостоящее решение.
Навыки
Невозможно знать и уметь все на свете. Особенно это касается ИТ области, где список продуктов и технологий стремится к бесконечности. Поэтому, к кому бы ни обращались за помощью – вендору, партнеру, «независимой» аутсорсинговой компании или студенту Василию Пупкину – каждый будет решать проблему в рамках своих знаний и умений. А потом придет человек с совершенно другими знаниями и будет качать головой: «Ну, как же так? Ну, зачем же это здесь? Можно же было гораздо проще!»
Еще более плохой вариант – когда инструмент выбрали верно, но из-за отсутствия опыта и времени на изучения применили его неправильно. Из собственного опыта могу сказать, что результат гораздо лучше в случае, когда разработчик не к месту использует то, чем он хорошо владеет. В ситуациях, когда пытаются внедрить что-то, что видят первый раз в жизни, ничего хорошего ждать не приходится.
«А у нас уже есть…»
Это тот редкий случай, когда в ошибке виноват не разработчик, а заказчик. Т.е. задача изначально ставится в рамках: «Доработать существующее решение, чтобы оно могло…»
Если имеющийся продукт изначально не разрабатывался для решения этой проблемы, если необходимые доработки противоречат архитектуре или существует средство более подходящее в данном случае, стоит задуматься — а оно того стоит? Может вместо развития существующего решения пришла пора его заменить? Или разделить «зоны ответственности» — под новые задачи применить новое решение, а старое оставить в том виде, в котором оно есть. Варианты всегда есть и иногда приходит время купить новую машину, а не «прокачивать» старую лошадь!
Вот и получается
Что обращаясь к аутсорсерам или консалтерам нужно задуматься над некоторыми вопросами:
- Не загоняют ли подрядчика в ненужные технологические рамки? Лишние ограничения – это сложности, это время и потраченные зря деньги.
- Технологию предлагают потому, что она подходит, или просто очень нужно ее продать?
- Предлагают ли сотрудники компании-разработчика какие-нибудь альтернативы? Они вообще готовы их рассматривать?
- У них есть опыт работы с выбранной технологией?
И ведь опыт должен быть именно в решении похожих задач! Если нужен корпоративный портал, и предлагают сделать его на флеше, то богатый опыт компании в разработке флеш-игр вряд ли будет так уж полезен.
Главное – это понимание того, что проблема требует решения, а решение требует технологии. И попытка сменить эти приоритеты всегда дорого обходится! Жаль, что мы об этом частенько забываем.
P.S.
Все это — мое видение проблемы. Буду очень рад прочитать альтернативную точку зрения.
