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

В особенности касательно функционирования механизмов мотивации. Сегодня вряд ли уже кто-то вспомнит, что лет 10ть назад наша индустрия свято верила в то, что Rational Unified Process спасет мир. В то время прикидываться, что умеешь делать проекты по RUP, было не просто модно.

Умение жонглировать многотонными папками с документами и темплейтами a-la «Rational букварь» было просто необходимо во время контрактных переговоров. В нашем опыте, ближе к концу переговоров клиент впадал в ступор, когда с удивлением обнаруживал, что RUP описывает процесс взаимодействие двух сторон – поставщика и заказчика. А когда клиент начинал понимать, что Requirements Engineering и Change Request Management это не просто красивые слова, а весьма формализованная схема работы – с ним, – начиналась паника. Весь процесс выглядел приблизительно так:

• (Клиент): Для нас этот проект критичен. Это очень важный стратегический проект. Поэтому надо, чтобы все было сделано по последним-распоследним стандартам. Делать будем строго по RUP!
• (Подрядчик): Мы подготовили в полном соответствии с RUP и RUP темплейтами комплект документации и план проекта.
• (Клиент): Что, правда тут все по RUP?
• (Подрядчик): Конечно, не сомневайтесь!
• (Клиент): Супер. Вам неделя на то, чтобы убрать из документации все ссылки на RUP, и после того, как пришлете нам подправленную документацию, начинайте работать.

В экономической теории есть такой термин – «экономический пузырь».  Это состояние рынка, при котором товары продаются за цену, существенно превышающую сколько-либо разумную. Характеризуется быстрым нарастанием цен, резким спадом и post-mortem комментариями многочисленных экспертов в новостях.

Хотя современная наука, если верить Википедии, не определилась с причинами возникновения пузырей, по нашему скромному мнению их происхождение сводится к следующему: часть игроков рынка охватывает заразное самоутверждающееся побуждение (self-reinforcing motivation по-английски), сочетающие в себе как внутренние, так и внешние «стимулы». В начале 2000х на голландском рынке мобильной связи на руках было достаточное количество телефонов, поддерживающих WAP протокол, чтобы на WAP обратили внимание большие игроки. Со слов моего коллеги, работавшего в то время в телекоме, дискуссии относительно разработки и развертывания WAP-сервисов проходили по следующей схеме:

• (Технический отдел): WAP – это круто! У нас есть инфраструктура, у пользователей на руках достаточно телефонов с поддержкой WAP!
• (Бизнес): Надо как можно скорее развернуть WAP, иначе нас опередят наши конкуренты!
• (Маркетинг): Знаете, я не могу себе представить, чего такого пользователи могут вычитать на экране телефона. Мы все здесь теряем время.

Как все это относится к сегодняшнему IT? В последние несколько лет мы наблюдаем тревожную тенденцию, что аргументация применения xDD, Agile, Lean, и прочих новых веяний в конкретном проекте стала «пузыриться»: внутренняя уверенности технических специалистов в полезности xDD методов складывается с достаточно убедительным buzz-ом о достигаемых успехах для менеджмента и входит в резонанс с уроками, извлеченных из предыдущих проектах.

Как результат: ожидания как первых, так и вторых часто отрываются от реальности – того, что senior менеджмент понятия не имеет, как работает IT, кроме его отражения в финансовой отчетности. Согласитесь, трудно отказать спецу, переполненного оптимизмом, высказывающий предложение вроде этого: «Следующий проект надо делать непременно на Spring, потому что благодаря его DI мы облегчим внедрение Test-Driven Development, что даст нам покрытие кода тестами 80%. И мы получим более качественный софт быстрее и дешевле!» И если Вы подумали, что «а вдруг получится…» – наши поздравления, Вы заразились. Дело ведь не в Spring, не в TDD, и не в покрытии тестами, а в том, что пузыри рано или поздно сдуваются или лопаются. Энтузиасту, описанному выше, ворчун вроде нас задаст пару простых вопросов:

• Имеете ли вы прямой доступ к клиенту, который распоряжается бюджетом? Готов ли он работать по такой схеме?
• Можем ли мы дать распорядителю бюджета гарантии, что через X дней и Y денег его проблемы будут решены?
• Что клиент понимает сейчас под качеством продукта?
• Как это качество меряется и сколько его он хочет получить?
• Что клиент будет понимать под качеством к концу проекта?
• Каким образом будет осуществляться управляться рисками?
• Какие альтернативные варианты, с которыми идет сравнение, рассматривались в анализе?
• Есть ли готовая финансовая выкладка, обосновывающую сокращения издержек?

И самый убийственный: зачем нам нужно покрытие именно в 80%? Почему не в 60%? Почему не в 40% Почему не в 90,1%? Ведь с точки зрения глупого менеджмента мы имеем дело с изначально «надутыми» ожиданиями того, что итоговый продукт будет:

• качественным – без чёткого понимания, что же такое качество в глазах клиента и сколько именно этого качества он хочет получить;
• сделан быстрее – не указывая, по сравнению с чем именно;
• дешевле – не делая финансовых расчетов.

На этом месте неуравновешенные уходят, хлопая дверью, бормоча что-то неразборчивое про непонимание передовых технологий. Уравновешенным и вменяемым объясняется, что успех проекта зависит в первую очередь от того, насколько хорошо менеджмент ведет работу с заинтересованными сторонами (stakeholders), а не от того, используется ли в проекте xDD на полную катушку или нет. Сегодня SCRUM сообщества активно обсуждают вопросы, связанные с непринятием SCRUM-а и позитивных изменений корпоративной средой.

Часто объяснение этом явлению пытаются найти там, где его нет. Но об этом в следующем блоге. А что Вы думаете?