Agile: возврат к старому в новом мире

Г. Греф помянул, и теперь вслед за ним все повторяют слово: Agile.
Это повторялось уже сотни раз в нашей уже скоро 25-летней практике: столько всяких «революционных» и «совершенно новых» слов и понятий  входило в моду, и чаще всего оказывались всего лишь новыми «упаковками» давно известных всем понятий, принципов, технологий. Обычный маркетинговый ход для активизации продаж. Так и на этот раз. 
Введенное программистами «ноу-хау» есть ни что иное, как давно забытые или технарям не очень близкие принципы работы команд, основы идеологии  «заказчик-исполнитель», элементы простейшего управления любыми проектами. Общение с пользователями и постоянный контакт с ними на предмет удовлетворенности результатами  нельзя не приветствовать консультантам  по изменениям, которые все внедрения проводят именно на базе создания рабочих групп из представителей компании и экспертов в теме. Ответственность за содержательный результат и за результат проекта изменений -  две разные ответственности , путать и смешивать  которые  не рекомендуется методологией Change Management последние лет 60. 

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

И, наконец, о коротких задачах. Питер Дракер еще в 54  году в работе «Практика менеджмента»  обратил внимание на целесообразность управления по целям ( или по задачам, по результатам – в разных переводах использовались разные понятия).    В противоположность бытовавшему тогда функциональному подходу, он предложил формулировать измеримые и счетные целевые показатели на более короткие сроки и по ним оценивать результативность работников.  В своей практике, мы уже два десятилетия видим, как в  России великолепно срабатывает именно этот, простейший подход, позволяющий договориться  «на берегу» и постановщику задачи, и ее исполнителюю. А потому исключающий возможные впоследствии кривотолки на предмет «а у меня этого в должностных обязанностях не написано». К сожалению, слишком  часто приходится  сталкиваться с тем, как подобную «отмазку» используют программисты, юристы, рекламисты, строители, консультанты и прочие работники  «проектного»  труда, много времени уделяющие  разработке непонятных для пользователя техзаданий, а потом использующие их в качестве аргумента  «в борьбе» с неквалифицированным заказчиком. Недавно, например, довелось соприкоснуться с кейсом, когда разработка юридической структуры бизнеса, стоившая заказчикам 1 млн. рублей, оказалась всего лишь    схемой с квадратиками и стрелочками, не дававшей владельцам бизнеса возможности  понять, что будет происходить с материальными и финансовыми потоками, если они перейдут на новую структуру .А, главное, точно также, как в известной истории с совой и ежиками, не отвечавшая на вопрос – а как же можно перейти к этой новой, замечательной и правильной структуре?

Так что да здравствует хорошо забытое и всегда новое! А еще – хорошо бы, чтобы люди иногда читали книжки. Особенно – совершенно не случайно ставшие классическими.