Прогибаться или нет?

Знаете что такое «незакрытый гештальт»? :) Ага, именно такой случай не давал мне покоя на протяжении всего отпуска. Началось все со статьи Артема Сердюка о «Как поссориться с заказчиком и заставить себя ненавидеть», где я даже не удержался от комментария по поводу процесса. Но осталось чувство неопределенности или недосказанности в вопросе «А стоит ли указывать Заказчику на то КАК делать продукт?».  

Вернулся из отпуска с чувством того, что нужно поподробнее эту тему раскрыть. Итак…

«Стоит ли навязывать Заказчику свой процесс?»

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

Для меня это вопрос актуальный, так как непосредственно связан с ежедневной деятельностью, как в качестве руководителя проекта, так и консультанта.

Если дать короткий ответ, то я считаю, что нужно прививать Заказчику хорошие и правильные процессы разработки, при условии, что практики на самом деле принесут пользу. Сразу отмечу, что слово «прививать» сильно отличается от слова «навязывать» и делать это нужно с умом, опираясь на опыт и победив основной скепсис со стороны Заказчика.

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

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

Свою позицию по этому вопросу я высказал, а теперь приведу аргументы.

Всю дальнейшую статью я разбил на 2 части:

  1. Почему наши предложения процесса не поддерживаются, а иногда даже воспринимаются агрессивно
  2. На что нужно обратить внимание, когда предлагаешь свой процесс

Так что поехали разбираться почему «навязывание» вашего процесса иногда вызывает негативную реакцию.

До того, как назвать причины, хотелось бы сделать важное допущение. Все предлагаемые вами процессы и практики на самом деле несут пользу Заказчику. Не вам лично, а именно Заказчику!

Причина №1: Отсутствие непререкаемого авторитета

Почему люди во многих областях жизни спокойно верят процессам, которые им навязывают, а в разработке ПО эти же люди (в лице Заказчиков) вдруг начинают яростно сопротивляться?

Я прихожу к врачу, рассказываю симптомы и он (после серии исследований) ставит диагноз и назначает лечение. Я знаю, что он долго учился, много видел таких больных и, вероятно, знает лучше меня. Я, смирившись, выполняю его предписания по приему лекарств и, например, диете.

Да, знаете, что появление Интернета принесло врачам огромную головную боль. Теперь большинство пациентов с ними спорят :) Эффективность труда врача упала, так как авторитет подорван и нужно прилагать дополнительные усилия, чтобы переубедить пациента. Конечно, в каком-то мизерном проценте случаев осведомленность пациента привела к более эффективному лечению, но ROI очень низок.

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

Да, и чуть не забыл. Заказчик не пропустит возможность напомнить вам, что экспертность и опыт – это конечно хорошо, но посмотрите на статистику успешных проектов в ИТ. Просто вижу клиента, который говорит: «Что там статистика говорит? Меньше 30% успешных? 20%+ закрывается не дождавшись результата? Так не нужно мне рассказывать как это делать»  :)

Причина №2: Нельзя изменить процесс разработки без изменения «пограничных» процессов. А это очень хлопотное занятие.

Рассмотрим пример. Вы вдруг решили внедрить SCRUM со всеми его фишками: частыми релизами на продакшн, короткими итерациями и т.д. Даже если вы нашли контакт с руководителем отдела ИТ и вам разрешили делать правильный процесс, то через какое-то время станет понятно, что нужно менять очень многое. Например:

  •  нужно теперь саппорт команду приучить к частым релизам и постоянному обучению нужным фичам
  • заставить спонсоров проекта принимать фичи каждую итерацию и подписывать счета
  • и т.д.

При всех очевидных достоинствах таких изменений, которые приводят к улучшению работы всей организации Заказчика в целом, эти изменения могут лежать за пределами круга власти того человека, который хочет и может изменить процесс разработки. А любые изменения, которые вы проводите за пределами своей зоны власти, обычно занимают намного больше усилий и времени. Если не верите, вспомните, как вы решали сложный вопрос с отделом ИТ в своей организации: вроде и люди знакомые и задача ясна, а дело буксует и требует постоянных «согласований» и «эскалаций».

Причина№3: Любое изменение – это риск потерять то, что есть.

Мотивация сохранения всегда сильнее мотивации на достижение. Именно поэтому нас пугают в рекламе «бактериями, которые уничтожают ваши зубы пока вы спите» и другими страшилками о потере здоровья, статуса или денег.

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

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

Причина №4: Вы пришли слишком поздно

Народная мудрость гласит: «Коней на переправе не меняют» и одно из главных правил руководителей проектов гласит: «В конце проекта процесс менять запрещено».

Даже гениальная идея требует времени на ее адаптацию. К ней должны привыкнуть, вместе с ней мы должны «пройти по граблям» (причина №3) и перейти на новый уровень. А это все требует времени. В вашем проекте его может и не быть :)

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

Основные причины мы описали. Теперь давайте попробуем понять, что же нам сделать, чтобы наши предложения имели больший шанс на успех.

 (Продолжение темы “Прогибаться или нет. Часть 2“) 

Sep 20th, 2012
  1. Sep 20th, 2012 at 15:11 | #1

    Кстати, из правила №2 есть очень полезное следствие – если на проект не распространяются регуляторные требования (GAMP, ISO/CD 13485, …), то с заказчиком, особенно не очень техническим, имеет смысл обсуждать только те нюансы процесса, которые затрагивают пограничные процессы: частоту релизов, процедуру приемки и т. д.

    А вот внутреннюю кухню можно и ИМХО нужно “инкапсулировать”.

    • Sep 20th, 2012 at 15:32 | #2

      Да, следствие очень правильное.

      А вот про “инкапсуляцию” я бы уточнил. То есть цель абсолютно правильная – инкапсулировать изменения в своем процессе, так, чтобы они не отразились на других.

      Но на практике так получается только при мелких технических изменениях. Иногда, оптимизация с нашей стороны укажет на недостатки (затыки) в процессах Заказчика и мы невольно опять будем вовлечены в изменение процесса.
      Хотя, по правде сказать, если благодаря нашим внутренним изменениям и улучшениям стали видны недостатки в процессе работы на стороне Заказчика, то это достижение :)

Leave a comment