«Порвите свои визитки. Избавьтесь от званий и титулов, от руководителей и иерархических структур. Дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят».
Дж. Сазерленд
В последнее время быстро развивающиеся высокотехнологичные компании стали отходить от привычных распланированных поэтапных способов управления проектами. Самую большую популярность завоевала философия Agile и её методологии Scrum и Kanban. Далее мы расскажем, что это такое, зачем вам это нужно, чем новые методики отличаются от классической работы по согласованному ТЗ, и в чем состоят юридические риски работы по новым подходам.
Классический подход – каскадная, водопадная модель. Каждый этап выполняется после завершения предыдущего.
- Plan (планирование)
- Build (создание)
- Test (тестирование, проверка)
- Review (обзор, пересмотр)
- Deploy (использование, разворачивание)
Все этапы выполняются один за другим. Нагрузка на работников неравномерная, часто совмещаются несколько проектов. Например, тестируется сразу 2 проекта, а в работе нет ни одного. Если при тестировании выясняется, что проект требует полной переработки, выполнение полностью прекращается. В каскадной модели очень важна формальность — согласовать ТЗ, согласовать условия контракта, сдать отчет о проделанной работе.
Например, чтобы при традиционном подходе заказать новое оборудование, нужно по очереди пройти следующие этапы:
- Выбрать оборудование
- Написать заявку
- Рассмотреть заявку у руководства
- Заказать оборудование, согласовав стоимость
- Начать работу
Agile
И в спорте, и в бизнесе выигрывает тот, кто был первым. Философия Agile позволяет ускорить бизнес-процесс минимум в 2 раза.
Agile (англ. проворный) – это общий набор принципов работы, основанные на манифесте Agile:
- люди и взаимодействие важнее процессов и инструментов
- работающий продукт важнее исчерпывающей документации (а бизнес-ценность важнее работающего продукта)
- сотрудничество с заказчиком важнее согласования условий контракта
- готовность к изменениям важнее следования первоначальному плану
Изначально Agile был придуман программистами для ускорения процесса разработки программных продуктов. Благодаря уменьшению бюрократизации и упору на общение и бизнес ценности время от начала работы до запуска проекта сократилось в несколько раз. Группа разработчиков не подгоняет проект под требования ТЗ, а постоянно обменивается идеями, оперативно учитывает «хотелки» заказчика, динамически корректирует программный код и меняет платформы. Именно поэтому рабочий «скелет» готового продукта появляется очень быстро.
Как Agile реализуется на практике
Разработка программного продукта происходит внутри небольшой, до 7 человек, и постоянно общающейся рабочей группы. Команда работает в одном пространстве и включает в себя заказчика. Рабочий процесс разделяется на небольшие циклы (итерации). Каждая итерация длится от 1 до 4 недель включает в себя полный цикл работ (анализ новых требований, проектирование, разработка, тестирование). Сырой, но рабочий продукт готов после каждой итерации. Инженеры не ограничены техническим заданием, жесткими рамками, могут экспериментировать и предлагать группе оригинальные решения. Заказчик вносит пожелания к корректировке и запускается следующая итерация.
Так как подход оказался очень эффективным, простым и прозрачным, методология Agile активно развивалась и распространилась на другие деловые коммерческие сферы вплоть до промышленной инженерии.
Agile успешно внедрен в работу следующих компаний: рестораны быстрого питания «Додо пицца», бухгалтерский сервис «Кнопка», Альфа-Банк и АльфаСтрахование, Сбербанк, производство оборудования NPM, ArtSkills.ru, Достаевский, Facebook, Google, Uber.
Scrum и Kanban – это системы, основанные на философии Agile.
Kanban
При Канбан подходе команда разработчиков едина, а упор делается на стадии исполнения конкретных задач. Стадии выполнения фиксируются на специальных досках, открытых всем членам команды.
Время прохождения задачи по доске контролируется, и таким образом выявляются сильные и слабые места разработки. Наглядно видна скорость работы и объем оставшихся задач.
Scrum
Scrum (скрам) – это схватка в американском футболе, когда благодаря слаженным действиям всей команды мяч удается пронести в зону соперника.
При таком подходе в группе появляются роли владельца продукта (представитель заказчика) и скрам мастера. Scrum мастер не участвует в разработке, а упрощенно говоря, выполняет роль няньки-куратора. Он проводит совещания, решает бытовые проблемы, мотивирует команду, помогает оценить результаты итерации. У каждого члена команды своя зона ответственности, а команда в целом самоорганизующаяся.
Для скрам мастеров, курирующих работу команды, существует 2 официальных системы сертификации:
Professional Scrum Master от Scrum.org
Certified Scrum Master от ScrumAlliance
Методология Скрам описана в книге Дж. Сазерленда «Scrum. Революционный метод управления проектами».
При классической работе рисуются красивые планы, графики, цветные таблицы и презентации. Естественно, что при столкновении с реальностью стройные теории не работают, а планы не выполняются. Выясняется, что появились новые идеи и работу надо корректировать.
Рабочий процесс всегда нагляден и визуализируется. При запуске новой итерации список задач в очереди уже нельзя дополнять. Разработчик уже не будет отвлекаться на новые процессы. Постоянные встречи повышают мотивированность персонала, каждый работник осведомлен о стадии проекта, четких задачах на период. За выполнение всех задач вовремя члены команды могут получать бонусы.
Слаженная работа команды в процессе 2-недельной итерации разрабатывает готовый продукт. Что интересно, на итоговом совещании обсуждается то, как он делался и как улучшить сотрудничество и скорость работы, а не сам продукт.
Почему Agile ускоряет работу над проектом?
- Исключаются простои, неизбежные при строго последовательной работе
- Исключаются потери из-за накопления «хвостов», незавершенных работ
- Исключается многозадачность, при которой всегда теряется работоспособность
- Исключаются потери на дополнительные коммуникации, так как состав группы оптимален и самодостаточен
- Нет потерь времени на поиск идеального решения, так как идет постоянное экспериментирование и эволюционирование результата
- После каждой итерации продукт уже готов к работе
Комментарий юриста
Гибкий подход работы, в котором основное внимание уделяется постоянному общению между членами команды приводит к постоянному изменению требований заказчика. Из-за того, что нет подробных согласованных условий контракта, четкого технического задания заказчик может постоянно выдвигать новые требования, противоречащие логике уже проделанной работы. Например, «А давайте, в доме будет не 2 этажа, а 20. Ну и что, что фундамент надо переделать», «А давайте число пользователей системы будет не 100, а 100 000», «А давайте, автомобиль будет ездить со скоростью в 10 раз больше и с меньшим расходом». Фактически заказчик выдвигает требования, команда работает 2-3 недели и делает рабочую версию, за это время заказчик успевает поменять требования, и команда все переделывает, возможно полностью. Договоры, технические задания, проекты появились как раз для минимизации споров, судебных процессов, четкости понимания конечной идеи. При подходе «работает и ладно» отсутствует детальная документация, а любые вносимые изменения могут привести к поломке готового продукта.
Гибкие методы не будут работать в организациях с жесткой иерархией и в компаниях, где в случае неудачи нужно наказать виновного. На практике представитель заказчика может быть не вправе принимать все решения и результат работы может быть отклонен.
При Эджайл подходе заказчик и исполнитель должны настолько доверять друг другу, чтобы полностью забыть о принципах безопасности работы компании. В Арбитражном процессе суду можно предъявить бумажные договоры, согласованные требования, но никак не доску со стикерами.
Тем, кто считает, что подача судебного иска – это редкое исключение, и что не нужно прикрываться бумагами, мы напомним, что за 2017 год только Арбитражный суд Санкт-Петербурга и Ленинградской области вынес 26 224 решений.
