Agile: возврат к старому в новом мире
Г. Греф помянул, и теперь вслед за ним все повторяют слово: Agile.
Это повторялось уже сотни раз в нашей уже скоро 25-летней практике: столько всяких «революционных» и «совершенно новых» слов и понятий входило в моду, и чаще всего оказывались всего лишь новыми «упаковками» давно известных всем понятий, принципов, технологий. Обычный маркетинговый ход для активизации продаж. Так и на этот раз.
Введенное программистами «ноу-хау» есть ни что иное, как давно забытые или технарям не очень близкие принципы работы команд, основы идеологии «заказчик-исполнитель», элементы простейшего управления любыми проектами. Общение с пользователями и постоянный контакт с ними на предмет удовлетворенности результатами нельзя не приветствовать консультантам по изменениям, которые все внедрения проводят именно на базе создания рабочих групп из представителей компании и экспертов в теме. Ответственность за содержательный результат и за результат проекта изменений - две разные ответственности , путать и смешивать которые не рекомендуется методологией Change Management последние лет 60.
Прекрасные тезисы о том, что изменения важнее планов и что не надо так много времени уделять подготовке документов, радуют нас как консультантов по управлению. Сколько раз приходилось спорить с теми, кто брался за описание бизнес-процессов компаний в надежде там найти возможности для оптимизации деятельности. Мы же всегда настаивали на том, что в условиях меняющейся действительности (а именно такой мир окружает нас) эта работа совершенно бессмысленна: описание процессов займет столько времени, что сами процессы к моменту окончания их описания станут не актуальными.
И, наконец, о коротких задачах. Питер Дракер еще в 54 году в работе «Практика менеджмента» обратил внимание на целесообразность управления по целям ( или по задачам, по результатам – в разных переводах использовались разные понятия). В противоположность бытовавшему тогда функциональному подходу, он предложил формулировать измеримые и счетные целевые показатели на более короткие сроки и по ним оценивать результативность работников. В своей практике, мы уже два десятилетия видим, как в России великолепно срабатывает именно этот, простейший подход, позволяющий договориться «на берегу» и постановщику задачи, и ее исполнителюю. А потому исключающий возможные впоследствии кривотолки на предмет «а у меня этого в должностных обязанностях не написано». К сожалению, слишком часто приходится сталкиваться с тем, как подобную «отмазку» используют программисты, юристы, рекламисты, строители, консультанты и прочие работники «проектного» труда, много времени уделяющие разработке непонятных для пользователя техзаданий, а потом использующие их в качестве аргумента «в борьбе» с неквалифицированным заказчиком. Недавно, например, довелось соприкоснуться с кейсом, когда разработка юридической структуры бизнеса, стоившая заказчикам 1 млн. рублей, оказалась всего лишь схемой с квадратиками и стрелочками, не дававшей владельцам бизнеса возможности понять, что будет происходить с материальными и финансовыми потоками, если они перейдут на новую структуру .А, главное, точно также, как в известной истории с совой и ежиками, не отвечавшая на вопрос – а как же можно перейти к этой новой, замечательной и правильной структуре?
Так что да здравствует хорошо забытое и всегда новое! А еще – хорошо бы, чтобы люди иногда читали книжки. Особенно – совершенно не случайно ставшие классическими.
1 June 2016