Статьи

Авторы: Алексей Янчук, Константин Кондратюк

Х Driven Development, Часть 1

Выпуски новостей последний год пестрят перемалыванием потрясений разного толка на финансовом рынке. Слушая эти новости, нам все чаще стали бросаться в глаза параллели между 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-а и позитивных изменений корпоративной средой. Часто объяснение этом явлению пытаются найти там, где его нет. Но об этом в следующем блоге.

А что Вы думаете?

Источник