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

В идеальном мире от правильной организации процесса зависит 50% успеха. А может, и больше — разве это можно посчитать? Но пусть это знают все стартаперы: каким бы прекрасным ни был продукт, который вы придумали, если грамотно не наладить процесс его производства, ничего не получится.

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

Параллельно с новыми технологиями рождаются новые способы управления проектами, которые всем, кто в хай-теке не работает, имеет смысл взять на вооружение.

Самый популярный из этих способов — Agile, метод, который за последние пять лет стремительно набирает популярность в Кремниевой долине и далее везде.

Пока сотрудников Google и Apple отправляют на специальные тренинги, призванные помочь им перейти на Agile с более консервативной и менее подходящей для производителей софтов системы под названием Waterfall, мы решили сами разобраться, что такое Agile и нужна ли нам эта штука. Может, вместе с джинсами, жвачкой и айфонами из Америки нужно привозить этот самый «эджайл»?

Традиционное управление проектами по системе Waterfall, если коротко, заключается в следующем: вы ставите цель, разбиваете процесс на стадии выполнения и переходите к следующему этапу только в том случае, если закончите предыдущий и отчитаетесь о выполнении.

Цель при этом (то есть то, каким будет конечный продукт) остается неизменной. Это удобно, например, при изготовлении стола или самолета.

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

Тут-то и приходит на помощь новый метод, который позволяет работать в быстро меняющихся условиях и мгновенно подстраиваться под новые требования рынка.

Элементы Agile на самом деле используются достаточно давно: считается, что система родилась благодаря двум событиям. В 1986 году в журнале Harvard Business Review вышла статья под названием «Новая игра для развития нового продукта», авторы которой — Хиротака Такеючи и Икуджиро Нонака — предложили новый способ ведения проектов, который можно сравнить с игрой в регби.

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

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

Только в 2001 году идею, кажется, оценили по достоинству: именно тогда группа экспертов, работающих в сфере создания программного обеспечения, впервые встретилась, чтобы обсудить, что общего имели между собой их самые успешные продукты. То, что они выяснили, вылилось в создание «Манифеста проекта Эджайл», в котором были изложены основополагающие принципы системы, основанные на идеях Такеючи и Нонака.

Принципы манифеста Agile

1. Главное для нас — удовлетворить пользователей, вовремя и беспрерывно выпуская для них достойное программное обеспечение.

2. Мы приветствуем изменения требований, даже если проект уже на стадии завершения. Процесс на основе Agile приспособлен для таких изменений в интересах потребителя.

3. Программное обеспечение должно выпускаться часто, от раза в две недели до раза в два месяца, более короткие промежутки предпочтительнее.

4. Разработчики и менеджеры должны работать вместе ежедневно на протяжении всей работы над проектом.

5. Продукты должны создаваться мотивированными сотрудниками. Нужно обеспечивать комфортную атмосферу и любую поддержку, которая им необходима. Для того чтобы работа была сделана, им нужно доверять.

6. Самый эффективный метод донести информацию до сотрудника в процессе разработки — разговор лицом к лицу.

7. Главный критерий оценки труда — программное обеспечение, которое работает.

8. Процессы в системе Agile обеспечивают устойчивое развитие. Спонсоры, разработчики и пользователи должны двигаться в одном темпе.

9. Постоянное внимание к техническим усовершенствованиям и красивому внешнему виду идет на пользу оперативности.

10. Простота — искусство увеличения количества работ, которые нет необходимости делать, — необходима.

11. Лучшее программное обеспечение получается у команд, которые способны к самоорганизации.

12. Команде необходимо регулярно задумываться о том, как работать более эффективно, и выстраивать процессы соответствующим образом.

Манифест — это нечто родом из идеального мира, как и правильный менеджер, приносящий счастье компании, однако сегодня Agile кажется той самой идеальной системой, в которой не бывает долгих совещаний, нудного составления отчетов, страха перед начальством и бесконечных перекуров на работе.

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

Если обычно потребители присылают отзывы на конкретный продукт, дизайн и архитектура которого уже продуманы, то Agile предоставляет разработчикам возможность исправлять все ошибки на той стадии, когда это можно сделать. Наверное, в стабильных условиях это нормально. Но давно мы жили в стабильных условиях?

Собственно, в переводе с английского agile и означает «проворный, мобильный, оперативный, подвижный».

Этот метод управления проектами подразумевает бег на короткие дистанции, когда команда за короткий промежуток времени создает продукт, выпускает его на рынок и ждет отзывов.

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

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

Только кажется, мы все время говорим про идеальный мир. «Чистого Agile нет нигде, каждый проект требует своего подхода, — рассказывает Максим Матузов, наш соотечественник из Кремниевой долины, успевший проработать менеджером программ в Google и Apple. — Важно, как команда предпочитает работать. В основном компании переходят на гибрид Agile и Waterfall, но грезят идеальным эджайлом. А он, на мой взгляд, невозможен в принципе».

Такой подход годится не только для сферы IT: любой бизнес, существующий в меняющихся условиях (даже кафе), может взять это на вооружение.

Главное, что такому бизнесу нужно, — менеджер, способный улавливать тренд, следить за ситуацией и вовремя собрать команду для очередного пересмотра задач. Собрать, кстати, — это не значит созвать совещание на три часа, во время которого кто-то заснет, а кто-то изрисует каракулями весь блокнот. Совещания должны проходить стоя (это называется «стендап-митинг») — это гарантия того, что никто не заснет и все будут активно высказывать идеи, чтобы все это поскорее закончилось и можно было наконец засесть за работу.