Текст ниже - перевод отличной статьи из блога Скотта Фрэнсиса.

 
Нам в BP3 множество раз приходилось идти спасать проекты BPM, которые до этого не удалось запустить большим консалтинговым компаниям широкого профиля. Я решил, что будет полезно объяснить, почему подобные провалы происходят и как нам удается избежать подобных ловушек. Для начала, что мы обычно наблюдаем в таких проектах.

1. Невероятно детальные спецификации софта, игнорирующие собственные возможности используемой платформы.
2. В контракте поименно закреплены ресурсы (исполнители).
3. Контракт охватывает все или большинство спецификаций, связывает поставщика конкретным описанием реализации и устраняет любые сомнения о желаемом продукте.
4. Контракт очень жесткий, с требовательными спецификациями, штрафами за низкую производительность и очень низкими средними ставками исполнителей, участвующих в проекте.

Помимо этого, начав разбираться, мы обнаруживаем:

1. Грязный код пользовательского интерфейса, написанный, чтобы минимально удовлетворить требованиям контракта, без соблюдения каких-либо неявных требований в части качества кода, возможности его дальнейшей поддержки, структуры или комментариев.
2. Отсутствие кого-нибудь на стороне исполнителя, кто мог бы встать и сказать заказчику, что требования плохие и что надо изменить курс. Они не имеют ни понятия о таких вещах, ни опыта. А цепочка менеджеров говорит - не расскачивайте лодку, просто делайте то, что сказано в контракте.
3. Несколько человек просто сидят, не делая буквально ничего полезного. Они пишут код, который потом кому-то придется вычищать из проекта, потому что он не служит выполнению каких-либо требований и только добавляет потенциальные баги. Было бы лучше, если бы они вместо написания кода сидели в фейсбуке.
4. Низкие ставки оказываются очень даже высокими, если один пишет хороший код, а несколько других уравновешивают его плохим кодом и ручным тестированием.
5. Завершение или успех даже не просматриваются.

Основная проблема в том, что невозможно юридически гарантировать компетентность. Вы можете записать в контракт что угодно, и вам станет легче, если в конце вы сможете вернуть деньги или часть или если вы сможете засудить исполнителя. Но ведь цель вашей организации заключается ведь не в том, чтобы спланировать неудачу! Ваша цель - создать условия, приводящие к успеху.

Теперь о нас - чем мы отличаемся?

Наши контракты не пытаются юридически гарантировать компетентность. Мы исходим из того, что любые письменные требования являются ошибочными, устаревшими, неточными, неоднозначными, нереалистичными, неполными, неверно приоритизированными или все перечисленное вместе. Мы так считаем, потому что это так и есть в ста случаях из ста. Единственный способ получить правильные требования - это разработать софт, дать пользователям его попробовать и получить их отзывы.

У нас достаточно смелости, опыта и знаний, чтобы, если надо, встать и сказать заказчику, что проект сбился с курса. Когда клиенты платят нам за консалтинг, они платят именно за это. Не просто за написание кода, а за то, чтобы мы были советчиками и партнерами на пути к успеху.

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

Мы не позволяем людям просто сидеть или писать плохой код и при этом оставаться в нашей команде. Мы понимаем, что успех или есть, или его нет. И от кого-то некомпетентного не просто “мало помощи” - он буквально разрушает то, что другие создают: отвлекает ваших лучших людей, пишет код, который потом надо переписывать (после обнаружения бага, тестирования, отладки).

Мы различаем человеко-часы и результаты. Час трудозатрат - это то, что попадает на вход вашего процесса, и не все человеко-часы равны. Час трудозатрат одного отличается от человеко-часа другого. Вам нужны лучшие человеко-часы, точно так же, как вы выбираете лучшую марку, покупая одежду. Плохая швея не просто шьет медленнее - она буквально разрушает фабрику, на которой работает, напрасно расходуя материалы, время и деньги.

Еще раз: невозможно юридически гарантировать компетентность. Добившись минимальных расценок, скорее всего вы заплатите за софт по-максимуму - если учесть провалы, сорванные запуски в эксплуатацию и затраты на юристов.

Здесь в Штатах (да и на других рынках) разница в цене между самым лучшим и самым худшим поставщиком BPM не столь велика. Даже с учетом офшоров, она примерно двукратная. Но разница в производительности легко может быть десятикратной или больше. Худшие поставщики (обычно консультанты и интеграторы широкого профиля) не то что приносят пользы меньше или медленнее - польза от них может в действительности отрицательная. Вот почему обычно оправдывает себя просто взять лучших людей и вывести ваш проект BPM на большую дорогу.

Пытаться юридически гарантировать компетентность в контракте, когда вы работаете с таким отличным поставщиком, как BP3,- это просто терять время, тратить ресурсы менеджмента и юристов. Причем это может не понизить, а повысить вероятность провала, потому что контракт свяжет нас плохими требованиями. Юридические гарантии компетентности в контракте в случае отличного поставщика - это то, что в Бережливом производстве называют “перепроизводством” - слишком большие усилия, потраченные без нужды.

Мои комментарии:

Хочется полностью подписаться под статьей.

Традиционный бич ИТ-проектов - автоматизация процессов либо не до конца понятых, либо заведомо неоптимальных. Проблема в том, что на старте проекта непонятым и неоптимальным является буквально каждый процесс! По статистике, неопытной команде требуется порядка 10 итераций, чтобы получить работоспособную модель процесса и процессное приложение, опытная имеет шанс уложиться в 5. Пример, подтверждающий эту статистку: на недавнем семинаре Ассоциации BPM-профессионалов (ABPMP Russian Chapter) “Процессное управление в проектной организации” доклачик рассказал, что текущая версия процесса заключения ддоговоров - девятая.

В такой ситуации пытаться жестко специфицировать требования и условия контракта - это гарантированно загубить проект. Не бывает итерационного усовершенствования бизнес-процессов на основе фиксированного ТЗ.

К счастью, большинство заказчиков, которые к нам обращаются, понимают, что BPM нельзя “внедрить” так, как внедряют, например, ERP-систему. Но встречаются и такие, которые услышали модный термин BPM, но не дали себе труда разобраться ни с методологией, ни с технологией BPMS, ни со спецификой проектной составляющей BPM.

Вместо того, чтобы понять какие идеи заложены в BPM, они пишут требования из сотен страниц с процессными диаграммами, которые, как они считают, смоделированы в нотации BPMN (хотя в действительности это скорее “BPMN-орнаменты”,  чем BPMN-диаграммы), и с эскизами пользовательского интерфейса, полностью игнорирующими тот подход, который предлагают BPMS.

Иногда такого заказчика удается убедить в гибельности такого подхода, иногда - нет. И тогда приходится от проекта отказываться, потому что результата не будет! При этом жалко не только несостоявшегося заказа, но и того, что заказчик, закономерно провалив проект, будет потом рассказывать “пробовали мы этот BPM - ерунда!” Но такие заказчики встречаются все реже, и это внушает оптимизм.