Вся правда об agile - сколько гибкости и свободы вам надо?

В своем недавнем интервью основатель и CEO компании Zerocracy Егор Бугаенко так описал agile-подход: «Это методология, придуманная программистами для программистов. Там нет бизнесменов, там нет инвесторов, там нет людей, которые тратят деньги на этих бездельников. То есть просто люди, которым раньше ставили сроки, собрались и сказали: «А давайте без сроков! А давайте свободно! А давайте без requirements! А давайте без формальных документаций! А давайте просто face-to-face, и пошли к черту все начальники!».

Это взгляд опытного программиста, лидера мнений, но есть и другие позиции. Например, что agile — единственно верный подход к ведению проектов, а остальные неэффективны или даже разрушительны в перспективе. О том, какую пользу и какие проблемы на самом деле несет agile бизнесу, рассказывает Андрон Алексанян, эксперт компании SF Education .

Читайте также: Agile поддерживает smart-офис

Коротко об agile

Скорее всего, большинство читателей представляет себе основные положения agile-подхода , но давайте их перечислим:

• главное — люди и общение, а процессы и инструменты вторичны;
• наивысший приоритет — удовлетворение заказчика;
• основной фокус направлен на создание рабочего продукта;
• правки приветствуются на всех этапах проекта.

Звучит привлекательно. Всем бы хотелось, чтобы их компании или команды работали в таком режиме — как можно меньше бюрократии и долгих утверждений, как можно выше эффективность и нацеленность на конечный результат. Однако, все ли так хорошо в реальной жизни? В своей ежедневной работе мне приходится сталкиваться с самыми разными проектами от медицины и фармацевтики до IT и веб-сервисов, и одно могу сказать точно — иногда agile способен привести к краху. Давайте поясню на конкретных примерах.

Когда люди и общение — не главное?

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

Однако, часто команды неправильно интерпретируют этот подход. Вот основные ошибки заигравшихся в agile:

• Самое простое — деятельность вашей компании не предполагает плоскую структуру и принятие решений на ходу. Яркие примеры таких организаций: государственные учреждения, предприятия здравоохранения, научные и исследовательские центры (в том числе частные, конечно же). Сделаю оговорку — конечно, некоторый agile уместен везде. Как минимум, от бюрократии и долгих согласований можно спокойно отказаться и оптимизировать этот процесс, сделав его более прозрачным и гибким.
• Другой пример — сторона заказчика не живет по agile. Допустим, вы занимаетесь разработкой ПО и пропагандируете agile, а клиент — крупная консервативная корпорация с вертикальной структурой и традиционным подходом к управлению. Вряд ли ваши гибкие подходы им покажутся привлекательными: в лучшем случае у вас получится-таки сделать более-менее рабочий продукт, в худшем — вы друг друга не поймете и просто потеряете заказчика. Не надо так.
• Еще одна ситуация касается тех команд, которые внедрили agile, но несколько извратили его. «Гибкий подход к общению и принятию решений» и «хаотичное взаимодействие и управление» — разные вещи. Если у вас все на ходу, все недоделано, везде незакрытые дыры и пробелы, то это не agile, а косяки.

Разве удовлетворить заказчика — не приоритет?

Звучит абсурдно. Всем понятно, что самая главная задача любой компании — доставить заказчику максимум удовольствия и пользы за его деньги. К этому постулату вопросов меньше всего, но они есть. Объясню на примере.

Вы заключаете крупный контракт с корпоративным заказчиком на разработку какого-то продукта. На запуск и осуществление этого проекта понадобится огромное количество средств, человеко-часов и дополнительных манипуляций (например, кадровые перетасовки, поиск каких-то редких комплектующих и так далее). Вы утвердили цену проекта, установили сроки и требования — и вот он, момент истины, день подписания договора. Вы заносите руку, чтобы поставить подпись, и вдруг заказчик выдает: «А давайте перед разработкой основного продукта сделаем еще такой-то модуль и такой-то функционал! Мы все это оплатим дополнительно».

Вы, как профессионал, понимаете, что эти правки будут стоить очень-очень дорого и потребуют еще тонны усилий. Приступать надо завтра, но это никак не зафиксировано в договоре — может вам вообще не оплатят эту работу? Что делать?
Если откинуть лозунги «долой лишние разговоры, даешь «агиле», «контракты — треп, лучше б работать начали быстрей», вы рискуете огромными деньгами. Своими деньгами.

Agile говорит: ударьте по рукам, подпишите договор как есть и с честным джентльменским словом за пазухой идите выполнять свою работу — нечего тратить время на юридические формальности. А что дальше? Учтите, agile рассчитан только на рыцарей, как действовать с разбойниками, он не рассказывает.

Лично мне такой подход не близок. Я не готов рисковать ради повышения эффективности на 1-2 дня. Пусть юридический отдел работает по agile , раз все такие гибкие — пусть за один день внесут необходимые правки в контракт, сразу же его подпишем и за работу.

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

Может рабочий продукт — это не так уж важно?

Очередной бред. В смысле «не важно»? А что тогда важно? Снова приведу пример.

Вы работаете в команде по разработке программного продукта — например, какого-то веб-сервиса. Работаете, конечно, «гибко»: никакой документации (максимум — краткие комментарии в коде), никаких четких рамок (но производительность труда приветствуется). Процесс разработки уже близится к концу, но тут произошли непредвиденные, но вполне реальные ситуации:

• из проекта ушли сразу два ключевых сотрудника (ни для кого не новость, что обычно весь процесс держится на нескольких людях);
• заказчик внес кардинальную правку, которая ломает структуру уже почти доделанного проекта.

Как будем аджайлить дальше?

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

А ведь есть еще и клиент, который внес правку, сломал проект и ушел довольный. И как дальше жить, вы же головой за все отвечаете? Да вот никак — смотреть, страдать и учиться на своих ошибках.

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

А можно еще одну правочку?

Именно с этих слов может начинаться каждый день, если вы работаете по agile, ведь правки не запрещены (и даже приветствуются!) на всех этапах проекта. В таком подходе есть определенные плюсы: продукт получается максимально доработанным и адаптированным под нужды заказчика. Или все-таки нет?

Есть один тонкий момент. Например, вы — разработчик программ автоматизации бизнеса, а я — крупный заказчик. У нас был проект, которому вы четко следовали, прописали большую часть всех модулей, но тут я говорю: «Коллега, а давайте мы переделаем модуль документооборота и обмена статусами — то, что было, мне не подходит».

Для заказчика, несведущего в IT — это просто очередная «правочка», но вы-то понимаете, что вся предыдущая работа — коту под хвост. Вы начинаете переделывать, работаете-работаете, а через пару дней я говорю: «Отбой, возвращаемся к старому плану».

Знаете, что самое интересное в такой ситуации? То, что происходит в голове у инициатора правок. Есть два варианта:

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

Скорее всего, большинство скажут: «Какое твое дело, деньги платят — работай, какая разница, что у него в голове». Да, это отчасти верно. Но если правки настолько масштабные, что требуют практически полной переделки проекта? А если на очереди клиент, который ожидает вашего освобождения от текущего проекта , и из-за сомнительной «правочки» вы рискуете его потерять?

Много подобных вопросов можно еще задать сторонникам аджайла. Правки на всех этапах — это чудесно, эффективно и ведет к успеху, если делать это с умом. Не надо ломать структуру проектов, не надо действовать хаотично, не надо «прикидывать все на коленке» и «разбираться по ходу». Спланируйте чуть лучше: потратьте немного больше времени, но сэкономьте на переделке. Вносите грамотные и взвешенные правки!

Смотрите также: Что такое Agile? 2 часть

Заключение

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

Фото Pixabay

При использовании материала гиперссылка на соответствующую страницу портала HR-tv.ru обязательна