Процессные астронавты (небольшая зарисовка из жизни)

Дожэль Спольски как-то писал про архитектурных астронавтов. В глубинах IT-шного космоса у них есть братья по разуму - процессные астронавты.

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

К сожалению, это было ровно, чем мы тогда занимались. Например, мы упорно придумывали и воплощали в жизнь Процесс Обработки Заявок Клиентов (всех полутора, ага), который включал в себя портал на Microsoft Sharepoint, проект в TFS и весьма вычурный регламент, объединяющий их в единое целое. Мы сами так и не научились по нему нормально работать, но достаточно настырно пытались заставить полтора наших внутренних клиента работать по этому Процессу. Клиенты, и так не фонтанировавших лояльностью, а тут ещё мы со своим Процессом.

Причиной нашего поведения было желание Сразу Сделать Всё Правильно. Это, наверное, один из самых тяжких грехов в нашей отрасли. Мы говорили себе: "так-так-так, когда-нибудь у нас будет много клиентов, мы должны быть к этому готовы. Давайте придумаем процесс сразу так, чтобы потом никого не переучивать". И мы так увлеклись решением проблем дня завтрашнего, что забыли про день сегодняшний. Я думаю, что мудрый читатель уже догадался, какая судьба постигла проект с такими ценностями и приоритетами.

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

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

"Решение без проблемы", или история одного требования

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

Пытаясь восполнить пробел в информации я стал задавать Product Owner`у вопросы, призванные прояснить конечную цель требуемой функции программы. Вот тут-то и начались проблемы, которых я не ожидал: диалог с Product Owner`ом у меня совсем не клеился. Я пытался узнать, зачем ему эта функция, какую проблему он хочет решить. Он же отвечал мне совсем на другой вопрос: что именно должна делать функция, какой отчёт он хочет увидеть и так далее. Это было весьма трудное общение, осложнённое тем, что поймать его было не так-то просто и он не горел желанием тратить много времени на обсуждение этого требования. Более того, его явно раздражала моя настырность и мои вопросы.

Признаться честно, в определённый момент я просто сдался. Решил, что я, наверное, зря пристаю к человеку и выдумываю на ровном месте какие-то сложности. "Надо просто взять и сделать" (с).  Закончилось это так: демонстрация нашей разработки была проведена практически "на бегу", после чего прошло уже полгода, а ей так НИ РАЗУ и не воспользовались.

Сухой осадок: выброшенные на ветер деньги и испорченное от осознания бесполезности проделанной работы настроение.

Почему так получилось? Я вижу две причины:

1. Product Owner, видимо, сам не понимал, зачем ему нужна эта функция в программе. Такое часто бывает, что люди делают что-то просто так, без чёткого осознания связи своих действий со своими целями и проблемами. Видимо, PO попался в эту же ловушку и сделал свою работу некачественно. Грубо говоря, принёс вместо требования bullshit.
2. Я согласился взять в работу требование без внятного понимания его цели и решаемой проблемы. Грубо говоря, я пропустил bullshit "сверху" в свою команду, не добился того, чтобы входящее требование соответствовало определённому стандарту качества. 

Мораль этой истории состоит в том, что ошибки совершенные "сверху по потоку" запросто приводят к тому, что вся дальнейшая работа становится бесполезной. Garbage in, garbage out. Чтобы защититься от некачественных данных на входе и, тем самым, обеспечить качественный результат на выходе, недостаточно быть просто умным и понимающим - надо обладать определённой твёрдостью и упрямством. Слишком мягкий человек, даже понимая, что он прав, рискует согласиться с плохим решением, просто чтобы не вступать в конфликт с коллегами.

Карьерный рост и бонусы в свете теории ограничений

Некоторое время назад я беседовал с нашим зам. ген.дира и он поделился со мной имевшейся у него идеей о мотивации сотрудников бонусом по результатам проекта. Я тогда подметил один изъян в этой идее: ребята из одной команды могут сделать всё идеально, но проект могут завалить другие. Потом этот умозаключение вывело меня мысли более широкого плана.

Чему нас учит теория ограничений Голдратта? Если в двух словах, то тому, что пропускная способность производственной системы определяется её самым слабым звеном (сиречь, ограничением). Практическое следствие из этого состоит в том, что оптимизация того, что не является ограничением системы, не приведёт к повышению пропускной способности и не имеет смысла.

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

Соображение для руководства: если премировать/депремировать сотрудников по результатам проекта, то "честным" эта премия окажется только для тех, кто работает в "узком месте" проекта. Для остальных этот бонус не будет иметь прямой связи с их реальной работой, что выхолащивает всю идею. 

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