В последнее время у меня выработалась стойкая аллергия на фразы вроде "реорганизация", "повышение эффективности" и прочие модные лозунги. Ясное дело - изменения необходимы. Окружающая среда как река, и мы гребем против течения. Перестанем грести - унесет. Ключевой вопрос тем не менее - что именно и как менять? Так вот - слишком часто необходимость "реорганизаций" преувеличена и за ней скрывается непонимание реальных проблем. Кроме того сам подход подразумевает наличие четкого плана действий, и что мы достоверно знаем к какому результату приведут наши действия. А это очень часто не так :-)
По моей статистике - около 30 процентов новых фич, которые запрашивает у ИТ бизнес в итоге никогда не используются и оказываются никому не нужны. Еще процентов 20 используются крайне редко или используется только какая-то незначительная ее часть. И почти ни одна не используется полностью без доработок в том виде, в котором была запрошена изначально. И это нормально.
На мой взгляд здесь есть два аспекта.
Какие конкретно проблемы решаем?
"Одна из основных ошибок менеджмента в современных бизнес организациях заключается в поиске правильных ответов, в то время, когда следует все свое внимание уделить поиску правильных вопросов"
Питер Друкер
Ну вы поняли :-) Прежде, чем искать решения проблемы, надо сначала четко понять, в чем эта проблема состоит. Так вот этапу анализа сплошь и рядом уделяется недостаточно внимания. Проблема кажется всем очевидной, так как у менеджеров накоплен большой опыт в сфере и настроено множество автоматических реакций мозга. Люди склонны слишком быстро переходить к выработке решения и уделяют недостаточно внимания уточнению правильности своего понимания проблемы, а именно оно часто ошибочно.
Здесь поможет некий формализованный чек-лист, этапов решения проблемы, через который нужно насильственно проводить любую сложную задачу, чтобы не пропустить ни одного из этапов. Там, где я сейчас учусь, это называется "проблемно-ориентированным подходом". Вариаций множество.
Тактика частых ошибок и фокус на быстрой обратной связи
Еще одно соображение - многие вещи, относящиеся к правильности или неправильности курса можно понять только во время движения. Поэтому иногда нужно побыстрее перестать исследовать и теоретизировать и начать двигаться.
Не знаю, как у других, а у нас иногда бывает так - когда бизнес запрашивает фичу, в ее требования часто включается все, что менеджер может придумать потенциально полезного сразу. Все возможные способы оплаты сразу, интеграция и обмен данными всем, что можно придумать полезного, множество дополнительных полей в справочнике и т. д... И фича не запускается в работу до тех пор, пока не будет реализовано все. А в итоге используется половина самых основных функций, причем, если бы не было потрачено время на реализацию ненужной второй половины, проект можно было запустить в два раза быстрее.
Так же и не в ИТ проектах.
P.S.
Это не значит впрочем, что нужно ограничивать и отфутболивать какие-то изменения еще на первом этапе. Нужно часто и много экспериментировать и почаще ошибаться. Нужно поощрять инициативу и изменения.
Как говорил Джек Уэлч: "Любые перемены несут с собой новые возможности. Поэтому реакцией организации на изменения должно быть не выжидание, а повышение активности".