Agile и головная боль: кто виноват?(Тезисы и видео прямого эфира)

(Транскрипт тезисов часовой беседы Сергея Колесникова и Марии Терегуловой от 13 августа 2020 года)

Необходимость «гибкости организаций» («business agility») была почувствована и озвучена ещё в конце 90-х гг. 20 века. Причём, конечно же, говорили и о турбулентности окружающей среды и других составляющих VUCA*мира.

*VUCA - это аббревиатура, впервые использованная в 1987 году и основанная на теориях лидерства Уоррена Бенниса и Берта Нануса, для описания или анализа нестабильности, неопределенности, сложности и неоднозначности общих условий и ситуаций.

Гибкость организации (Businessagility) проявляется в трёх областях:

1. Отношения в организации (например, выраженные через организационную структуру).
2. Установки и мышление членов организации.
3. Управление процессами.

Когда мы говорим про Agile подход, то чаще всего касаемся только области «управления процессами».

При этом может встать вопрос, мы сам бизнес хотим сделать гибким или улучшаем какие-то его аспекты? Если речь об улучшениях в области генерации идей, креатива Компании (гибкий бизнес), то она может использовать практику «Дизайн-мышление». И, скорее всего, это будет так же касаться и второй области в организации –  «установки и мышление».

Гибкость – это скорость адаптации к чему? Про окружающую среду обсудили вначале, но отдельно стоит остановиться на клиенте. Гибкость Компании служит удовлетворению потребностей клиентов. Приходят такие времена, когда организации должны стать клиентоориентированными на 100%, а соответственно принципы гибкости (agile) должны быть везде.

В таких условиях Agile – это образ жизни, а не формальное улучшение производительности.

Маркетинговая агрессия нам часто мешает воспринимать многие идеи, как настоящие, практичные.

Возвращаясь к гибкому управлению процессами, есть классический подход к управлению проектами (каскадный), а есть agile (инкрементально-итерационный). В них большая разница, начиная с постановки задачи. Если в классическом случае задача чётко определена – нужен портрет Джоконды (Клиент имеет ТЗ с продуманным образом результата), то в альтернативном (гибком, agile) подходе результат будет сформулирован примерно так: «нужен портрет женщины в пейзаже». Уже эту задумку разработчики будут уточнять во время каждой итерации, ориентируясь на потребности клиента, которые могут ещё и меняться в процессе. Именно тогда, когда в итоге каждой итерации получается законченный продукт со своей ценностью для заказчика, ему (заказчику) хочется продолжать.

«Продукт – это упакованный в маркетинг процесс причинения ценности клиенту» (Алексей Кулаков).

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

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

Отметим так же, что проект – это не регулярная деятельность, а только та, которая выполняется впервые.

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

Матрица ответственности, планирование – это привычная работа руководителя в рамках «каскада», а в SCRUM он больше уделяет внимания настоящей кросс-функциональности, сильной взаимозаменяемости (такое "руководство постмодерна"). Однако сами инструменты планирования, понимания людей, обратной связи – все это уместно и схоже в обоих случаях. Частный пример, Канбан для управления задачами может пригодиться везде.