ПРИНЦИПЫ ОРГАНИЗАЦИИ ЭФФЕКТИВНОГО ПРОИЗВОДСТВА

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

Что же понимается под «гарантированным, повторяемым и одинаковым результатом»? Для начала определим, что понимается под «результатом»? Результатом, или создаваемой ценностью (в этой книге), считается работающий продукт. Что представляет собой работающий продукт? Таковым является официально выпущенный в интересах широкого (но не массового) круга потребителей релиз программного продукта с заданным уровнем качества, установленный на рабочий стенд и функционирующий согласно ожиданиям и без ошибок. Выпуск релиза производится командой — владельцем программного продукта каждые две недели и содержит приращение продукта в объёме не менее 70% от мощности команды. Под заданным уровнем качества понимается выполнение продуктом всех заявленных в нём функций, без блокирующих их выполнение ошибок, а также без регресса по отношению к предыдущим релизам программного продукта. Допускается автоматическая установка и обновление релиза на рабочем стенде. Дополнительно под результатом понимается официальный выпуск обновления релиза, содержащего исправления найденных в процессе эксплуатации продукта ошибок.

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

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

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

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

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

По аналогии с конвейером производительность производства программных продуктов зависит от следующих факторов:

Как же должно быть организовано современное умное производство программных продуктов, чтобы стать результативным, управляемым и эффективным?

Начну с ключевых принципов его организации.

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

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

Всё, что может быть автоматизировано, следует автоматизировать. Как следствие, цепочка непрерывной сборки, интеграции и развёртывания (CI/CD-конвейер) должна быть полностью автоматизирована.

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

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

Приведу несколько практических правил, которых стоит придерживаться при разработке показателей. Назначение показателя должно быть простым для понимания, а формула его расчёта — достаточно простой. Чем проще расчёт и чем очевиднее смысл показателя, исходящий из его названия, тем проще «продать» его командам, и тем легче командам ориентироваться на него в своей работе.

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

Хорошим тоном считается приведение всех измеряемых показателей к единой системе координат, например, баллам. Мы в компании «Диасофт» используем шкалу 0−700−1000 баллов, где ожидаемый результат — 700 баллов. Серьёзно упрощает восприятие результата и цветовое разделение. Можно использовать трёхцветную схему (красный, жёлтый, зелёный) или расширенную схему, из пяти цветов: «бордовый = совсем плохой результат», «синий = результат, превосходящий ожидание». Чем сложнее и непонятнее измеряемый показатель, тем выше вероятность, что команды начнут использовать «обходные» решения для достижения нужного значения. Что не будет приводить к результатам, возложенным на показатель.

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

Такой подход упрощает восприятие усилий конкретного сотрудника и команды на результат компании в целом. Мы имеем «единую версию правды» и можем принимать управленческие решения на основании тех же показателей, что и команды в своей работе. Плохой является практика наличия разных показателей на разных уровнях компании. Если представить систему показателей как здание, то показатели работы сотрудников и команд будут её фундаментом. Верхние этажи здания — это показатели уровня компании. Как верхние этажи и здание в целом не могут быть устойчивыми без фундамента, так и показатели, «оторванные» от команд, отрываются от реальности и снижают эффективность управленческих решений.

Крайне важно измерять значения показателей регулярно и в режиме реального времени. Вся сила менеджмента — в его регулярности. Регулярный менеджмент должен базироваться на актуальных измерениях. Для каждого показателя необходим детальный протокол расчёта, чтобы можно было быстро и просто разобраться в причинах, которые привели к результату.

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

Приведу пример осознанного действия. Если я бездумно открою кран с водой, то могу обжечься — если этим краном окажется «горячий». Поэтому я осознанно сначала открываю кран с холодной водой, а уже потом — с горячей. Таким образом, под осознанным я понимаю выполнение действий с полным пониманием ожидаемого результата. И пониманием того, как будет меняться результат при изменении моих действий.

Как же добиться от сотрудников осознанных действий? Осознанности придётся обучать. Нужно показывать командам, какое их действие или бездействие привели к полученному результату, и подсказывать, что и как нужно делать уже в следующем спринте для улучшения результата или для предотвращения сбоя. Хотя порой командам надо предоставлять право на ошибку — чтобы закрепление причинно-следственных связей произошло быстрее. Скорее всего, знатоки Scrum меня справедливо поправят, напомнив о специальной практике «ретроспектива», в рамках которой команда должна самостоятельно разбирать свои действия и предлагать мероприятия. Это так, но лишь частично.

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

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

КАК ЖЕ ПРОХОДИТ ПРОЦЕСС ОСОЗНАНИЯ?

Его можно разделить на четыре этапа:

Поясню на том же примере с краном. Допустим, я ничего не знаю про принцип действия «однорукого» устройства, а рычаг управления изначально находится в разных положениях — либо он смещён влево, либо вправо. Если я дёргаю рычаг хаотично, в итоге вода идёт разной температуры и разного напора. Если открою кран с кипятком и сильным напором, недолго и обвариться. Пример может показаться наивным, но именно так со стороны мастера видится исполнение любого процесса неопытным учеником. Далее я задаю в себе вопросы: почему я иногда обжигаюсь, какие действия приводят к этому, как надо открыть кран, чтобы гарантированно не обвариться? И я начинаю разбираться в работе крана. Для начала провожу «серию экспериментов», открывая его, допустим, вверх-вниз, и понимаю, что таким образом регулирую степень напора. Затем двигаю рычаг вправо-влево — и окончательно разбираюсь, как включить холодную, горячую или тёплую воду. И уже затем — осознанно — если мне нужно открыть сильный напор холодной воды, перевожу рычаг влево и вверх до упора. Теперь я могу открыть любой кран подобного типа, гарантированно избежав неприятностей, даже если ни разу до этого такой кран не открывал.

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

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

ИЗ ЧЕГО СКЛАДЫВАЕТСЯ ПРЕДСКАЗУЕМОСТЬ?

Вероятность получения ожидаемого результата высока, если:

Заказчику важно, чтобы его бизнес-цели были выполнены в срок и, желательно, без подвигов. Поэтому очень важно, чтобы они были поставлены в цели спринта. Например, мне нужно на автомобиле добраться из дома до работы. Я строю маршрут в навигационной программе, и она выдаёт мне список улиц, по которым я должен ехать, чтобы добраться до работы. Список улиц — это аналог списка решаемых в спринте задач. Моя цель «добраться до работы к определённому времени» — аналог бизнес-цели заказчика. Важно, чтобы команда, выполняя список задач, в том числе решала и бизнес-цель. В моем случае, если одну из улиц внезапно перекроют, я не достигну своей цели. Но навигационная программа предложит альтернативный маршрут. Так же и команда должна уметь предложить заказчику альтернативное решение, зная о его цели. Вот почему выполнить только задачи спринта недостаточно для того, чтобы сделать заказчика довольным.

Открытая информационная среда — серьёзный помощник в решении этой задачи. Приведу пример с сервисом заказа такси через мобильное приложение. Мне нужно добраться из дома до аэропорта на такси к определённому времени, чтобы успеть на рейс. Вспомним ситуацию из совсем недавнего прошлого. Я вызываю такси по телефону через диспетчера. Жду машину к определённому времени, переживаю, что она может опоздать или не приехать вовсе. Однако узнаю об этом лишь тогда, когда назначенное время уже настанет. Вызов следующей машины усугубляет риск — не успеть на регистрацию. Но вот машина пришла, и я еду в аэропорт. Успею ли на рейс? Никаких гарантий: водитель может плохо знать дорогу, или на маршруте встретятся пробки. Всё это может фатально повлиять на время прибытия в аэропорт. Если я сам плохо знаю дорогу, то наверняка стану дёргать водителя вопросами: далеко ли до пункта назначения, сколько ещё ехать. Более того, попытаюсь помочь ему выбрать более быстрый и безопасный маршрут или надавить на него эмоционально, всячески отвлекать от дороги. Дорога до аэропорта традиционно была стрессом для заказчика.

Теперь о том, как это происходит сейчас. В мобильном приложении вызываю такси. При этом вижу машину и примерное время прибытия ко мне, более того, даже знаю номер машины, имя водителя и телефон для связи с ним. Сев в машину, вижу в его навигаторе подробный маршрут, наличие или отсутствие пробок и ожидаемый срок прибытия в аэропорт. Мне не нужно дёргать водителя. Согласитесь, такой современный вариант гораздо комфортнее.

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

Аналитики Gartner считают самым большим вызовом для современных IT-компаний их готовность к изменениям: в технологиях, среде (например, регуляторные изменения), людях (поколение миллениалов), пользовательском опыте и так далее. В условиях постоянных изменений выживут не самые сильные и умные, а самые гибкие и быстро адаптирующиеся к новым реалиям компании. Именно поэтому очень важно внедрить культуру, базирующуюся на гибких Agile-принципах.

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

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

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

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

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

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

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

Для обучения сотрудников эффективной работе в рамках своей роли мы применяем практику «Быстрый старт». Это специально разработанный комплекс методической литературы для самостоятельного обучения и практических заданий, целью которых становится максимально быстрое включение сотрудника в производственную деятельность. Другими словами, уже на третий день работы в компании сотрудник должен приносить практическую пользу — то есть решать обычные производственные задачи. «Руководитель команды» — столь же важная производственная роль, как и программист. Поэтому разработка материалов быстрой подготовки руководителей команд обязательна для успешного масштабирования команд. Таким образом, на этапе подготовки производится найм новых сотрудников и прохождение ими обучения в виде ролевых быстрых стартов.

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

На этапе деления из включённых в команду-донора сотрудников создаётся новая команда. Первый спринт новой команды ведёт новый руководитель команды под контролем руководителя команды-донора. Он же активно участвует в основных Scrum-активностях новой команды.

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

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

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

Приведу пример из области спорта. Мастер спорта пробегает марафонскую дистанцию за два часа двадцать минут. Но это мастер спорта, а как обычному человеку если не достичь, то хотя бы приблизиться к этому результату? Очевидно, что просто прочитать статьи о методах тренировки недостаточно. Чтобы марафонец быстрее улучшал свои навыки, необходим тренер, который буквально «за ручку» проведёт ученика к мастерству максимально эффективным способом. Более того, даже опытному, заслуженному спортсмену постоянно нужен тренер, который помогает ему готовиться к очередным соревнованиям. Между тем, в разработке программных продуктов считается достаточным наличие наставника только в ходе испытательного срока. У команд должен быть «тренерский штаб», который помогает командам быстро внедрять новые успешные практики, разработанные в других командах.

Как же быстро распространить удачную практику на 100 команд? А на 1000? По моему опыту, на успешное внедрение лишь одной новой практики команде требуется не менее трёх спринтов — при условии, что в них будет участвовать наставник. Как правило, первые два спринта бывают неудачными. И если последовательно обучать команды новой практике, то сотню команд таким образом можно обучить за 300 спринтов — то есть за 12,5 лет. Значит, нужно распараллелить внедрение, но где взять сто наставников? Мой практический опыт подтверждает, что возможно эффективно внедрять несколько практик одновременно при участии одного и того же наставника, параллельно курирующего от 15 до 20 команд. Таким образом, на сто команд достаточно от 5 до 7 наставников.

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

Типовое внедрение практики в командах включает четыре этапа:

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

Такое оформление, по сути своей, заключается в ответах на вопросы:

Подробнее о том, что понимается под практикой, вы прочтёте в следующих главах.

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

После обучения принимается решение о тиражировании практики. Исходя из опыта, команды не могут сразу выполнять практику согласно целевым значениям показателей. Поэтому сначала критерии устанавливаются таким образом, чтобы их смогли выполнить не менее 80% команд. Задача первых двух-трех спринтов — отработать основные элементы практики, впоследствии критерии постепенно, с заданной периодичностью, усложняются. Периодичность изменения критериев выбирается индивидуально для каждой практики. Но, по опыту, наиболее комфортно для команд изменение критериев раз в квартал. При таком подходе можно одновременно внедрять несколько практик. Примерно за два-три квартала любая практика внедряется во все команды и выполняется на хорошем, осознанном уровне.

Ещё двадцать лет назад сроки эксплуатации архитектуры программных продуктов и инструментов разработки существенно превышали жизненный цикл создаваемых на них продуктов. Сейчас — всё наоборот. Технологический стек полностью обновляется за два-три года. Мода на технологическую платформу и архитектуру меняется каждые пять лет, и заметна тенденция к уменьшению этого срока. Получается, за время жизни продукта системная архитектура и технологическая платформа могут несколько раз смениться.

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

Вообще говоря, внедрение новых продуктов, инструментов и технологических платформ состоит из тех же четырёх шагов, что и внедрение новых практик и технологий. Существенным отличием является первый, подготовительный шаг. Хорошим тоном будет его выполнение в концепции MVP (англ. minimum viable product, минимально жизнеспособный продукт). Под этим термином понимается функционал, способный удовлетворить основные потребности заказчика. Кроме того, он должен быть недорогим по стоимости разработки и внедрения.

Допустим, есть потребность внедрить новый инструмент статического анализа кода в рамках конвейера непрерывного тестирования и развёртывания (DevOps-pipeline). Он может выявлять большой список ошибок кода. Однако для успешного внедрения нужно ограничить список выявляемых ошибок теми, ради избежания которых куплен инструмент. Если целью приобретения было выявление ошибок, связанных с безопасностью, то и нужно ограничить настройку только этими ошибками. На этапе пилотирования следует убедиться, что продукт соответствует ожиданиям. Если взять наш пример: инструмент уверенно выявляет ошибки кода, связанные с безопасностью, интегрируется в наш конвейер непрерывного тестирования и развёртывания, время его работы соответствует нашим ожиданиям, результат выводится в понятном для разработчика виде, а журналы легко читаются и позволяют быстро локализовать проблему. Именно в таком виде стоит внедрять инструмент в команды — и лишь на следующих этапах добавлять выявление новых типов ошибок.

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

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

Структура, не способная быстро адаптироваться к изменяющимся условиям, будет сопротивляться изменениям. Во-первых, обратная связь будет либо затруднена, либо отсутствовать вовсе. Просто сравните: если вы собираете обратную связь по результату каждого спринта (то есть каждые две недели), то в квартал вы можете сделать шесть корректировок своей работы. Если собираете её раз в квартал, не больше одной — и та под сомнением, поскольку заказчики часто уже не помнят деталей. Во-вторых, пока обратная связь дойдёт до нужного руководителя, который сможет принять адекватное решение, минует немало времени, а может и не дойти, затерявшись на просторах организации. Но если не давать реакцию на обратную связь, то зачем её собирать? В-третьих, если для реализации принятого решения нужно мобилизовать всю организацию, такое решение скорее всего не будет доведено до конца или же его реализация займёт непозволительно долгое время.

По типу организационного управления выделяют следующие структуры.

Линейная структура образуется в результате построения аппарата управления только из взаимоподчинённых органов в виде иерархической лестницы.

Функциональная структура предполагает, что каждый орган управления специализирован на выполнении отдельных функций на всех уровнях.

Дивизионная структура включает крупные автономные производственные подразделения (дивизионы), имеющие оперативно-производственную самостоятельность и несущие ответственность за получение прибыли.

Матричная структура представляет собой решётчатую структуру, в которой управление по функциям ложится на плечи руководителей подразделений. Организация выполнения проектов осуществляется руководителями проектов. Эта структура построена на принципе двойного подчинения исполнителей: с одной стороны — непосредственному руководителю функциональной службы, с другой — руководителю проекта.

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

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

Исторически сложилось, что IT-службы в большинстве организаций выполняют вспомогательную или сервисную функцию. Это, как правило, отдельное подразделение с собственной командой, руководителем, своими целями и задачами. Зрелость IT-службы определяется степенью её вовлечения в бизнес-процессы компании. От простейших «подай-принеси» до более продвинутых вариантов, когда выделяется должность «директор по IT». В этом случае директор по IT согласует стратегию развития подразделения со стратегией компании. Деятельность IT-службы может быть организована в соответствии с практиками ITIL (англ. IT Infrastructure Library — библиотека инфраструктуры информационных технологий) и ITSM (англ. IT Service Management — управление IT-услугами).

ITSM — подход к управлению и организации IT-услуг, направленный на удовлетворение потребностей бизнеса.

ITIL — библиотека практик по управлению услугами и жизненным циклом услуги.

К сожалению, наличие выделенной IT-службы вне зависимости от уровня зрелости её процессов на практике обладает рядом недостатков. Во-первых, SLA используют не только для обеспечения определённого качества услуг, но и как барьер для снятия с себя ответственности. Так как качество работы IT-службы оценивается по уровню качества предоставляемых услуг, это мотивирует службу включать в SLA множество дополнительных условий, при которых соглашение может не выполняться. Во-вторых, взаимодействие бизнеса и IT через сервисную модель приводит к существенным (порой на несколько месяцев) задержкам в реализации и внедрении функциональности. Желание бизнеса самоустраниться от участия в разработке функциональности и получить полностью удовлетворяющий продукт с «запредельным» уровнем качества заставляет IT-службы тратить ресурсы и время на подготовку и согласование максимально подробных технических заданий, а затем — на многомесячный процесс разработки и выпуска. При этом чаще всего реализованную функциональность при сдаче бизнесу приходится дорабатывать. В нашем быстро меняющемся мире к моменту выпуска продукта требования сильно меняются, а в ряде случаев потребность в функционале полностью отпадает. Всё это приводит к взаимному недовольству как бизнеса, так и IT-службы. Бизнес обвиняет IT-службу в негибкости, затягивании сроков, выпуске некачественного программного обеспечения и длительном исправлении ошибок. В свою очередь служба предъявляет бизнесу свои претензии: в постоянном изменении требований, отказе от собственных задач, в недостаточности финансирования службы для найма необходимого количества сотрудников.

Вам знакома изложенная ситуация? Значит, эта книга — для вас!

Как-то ещё можно понять работу на основе SLA между разными компаниями, но зачем поддерживать борьбу между подразделениями внутри одной компании? Этот перманентный конфликт точно не ведёт к культуре согласия.

Так что же, нужно отказаться от SLA? Как убрать разногласия бизнеса и IT-службы? На мой взгляд, SLA как мера качества предоставляемых услуг должно остаться, а как регламент взаимодействия бизнеса и IT — исчезнуть.

В наше время скорость для бизнеса исключительно важна. Решение, предоставленное слишком поздно, может быть в лучшем случае бесполезно, а в худшем — вредно. Поэтому необходимо обеспечить плотную работу бизнеса и команды разработки. Для этого придётся отказаться от сервисной модели работы IT-службы. Между бизнесом и командой разработки не должно быть стены в виде SLA, через которую проблемы перекидывают друг другу. Цели бизнеса и команды разработки должны быть едины. Очень важно, чтобы бизнес был прямым заказчиком реализуемой функциональности. При непосредственном участии в разработке бизнес уже через две недели получает установленную в рабочей среде функциональность. Иными словами, цели бизнеса должны стать целями команды разработки.

Ещё один пример из жизни. Допустим, мне нужно доехать из дома до работы к 9:00. Я решил воспользоваться услугой такси, вызвав его через мобильное приложение. У сервиса такси есть определённые параметры SLA: класс автомобиля, его чистота, дружелюбность водителя, характер вождения. Водитель такси сам выбирает путь, которым везёт меня до работы. Таким образом, моя бизнес-цель — доехать из дома до работы к 9:00. Цель водителя такси — довезти меня до пункта назначения, указанного в приложении, согласно заявленному SLA. Легко заметить, что наши цели сильно различаются. Кроме наглядного расхождения, что водитель не имеет цели довезти меня точно к 9:00, есть и менее очевидные. Водитель приедет по адресу, указанному в мобильном приложении, и если я неправильно его укажу, это будет моей виной.

Теперь рассмотрим пример, когда используется служебная машина. В этом случае перед водителем поставлена цель: доставить меня из дома на работу к 9:00. То есть наши цели совпадают. Поэтому водитель уточнит моё истинное местонахождение и приедет ко мне домой (или, скажем, на дачу) заранее, с учётом возможных пробок, чтобы довезти вовремя. Главным критерием моей оценки качества оказанной услуги будет в первую очередь то, достиг ли я своей бизнес-цели. И лишь во вторую очередь я оценю чистоту салона и настроение водителя.

То же самое и в работе. Заказчик оценивает качество оказанной ему услуги через призму достижения бизнес-цели. Если она не достигнута, то — независимо от того, насколько качество оказанной услуги соответствует или даже превосходит SLA — бизнес останется недоволен услугой. Поэтому важно, чтобы у заказчика и команды разработки были и единые цели, и общая ответственность за результат.

Структуризация организации по дивизионам производится, как правило, по одному из трёх критериев:

Например, в компании «Диасофт» мы осознанно выбрали первый подход к организации дивизионов — продуктовые центры. Каждый из них владеет набором продуктов определённого функционального направления, например, «финансовые рынки». Центр имеет оперативно-производственную самостоятельность и несёт ответственность за получение прибыли. Элементарное подразделение продуктового центра — производственная команда, владеющая продуктом. Каждый центр состоит из 7−15 производственных команд, а каждая из них включает 7−10 сотрудников. Лучше объединять команды вокруг нескольких функционально близких продуктов.

У дивизионной организационной структуры есть ряд преимуществ.

Есть, однако, и недостатки.

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

Ключом к построению эффективного процесса разработки программных продуктов являются автономные команды. Команда должна создавать ценность совершенно самостоятельно. Чем больше автономных команд, тем больше ценностей в единицу времени может быть произведено. К сожалению, простое объединение сотрудников в команды не приводит к повышению производительности. Ошибочно думать, будто бы люди изначально знают, как работать в команде. Эффективная командная работа вовсе не равна сумме усилий всех её членов, даже при условии высокой квалификации и высокой результативности каждого.

«Команду мечты» можно сравнить с симфоническим оркестром, состоящим из талантливых музыкантов, а её лидера — с дирижёром. Оркестр — нечто большее, нежели просто коллектив музыкантов. Безупречное исполнение своей партии каждым оркестрантом недостаточно для хорошего концерта, важна согласованность. Только от безупречно согласованной игры мы, слушатели, сможем получить эстетическое удовольствие. Чтобы команда стала выдающейся, она должна стать сыгранной. В спорте команда звёзд проигрывает менее звёздной, но более сыгранной.

Для эффективной работы исключительно важно взращивать зрелую командную работу. Все аспекты деятельности должны рассматриваться сквозь эту призму.

В компании важно создавать комфортную корпоративную атмосферу командной работы.

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

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

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

Зрелые команды, подобно мастерам спорта в беге на марафонскую дистанцию, должны каждый спринт давать гарантированный результат. Как мастер спорта по марафону должен уложиться в норматив 2 часа 20 минут, так и зрелая команда должна в течение очередного спринта дорабатывать программный продукт (направляя на приращение программного продукта не менее 70% своей мощности) и выпускать релиз или обновление релиза продукта с заданным уровнем качества. Марафонец не может сразу показать результат уровня мастера спорта и должен постоянно, от забега к забегу, улучшать свой результат. Таким же образом система управления производством должна помогать команде и мотивировать её к повышению своей зрелости — постоянно увеличивая приносимую заказчикам ценность и, как следствие, улучшая свою результативность.

Команды должны развиваться на основе передачи опыта. Для спорта это правило очевидно: под руководством тренера спортсмен быстрее улучшит свои навыки, нежели «варясь в собственном соку». Наставник на основе собственного опыта подскажет, какие практики должен освоить его подопечный, как правильно отрабатывать приёмы, а какие упражнения не надо делать, потому что они скорее принесут вред, чем пользу.

Однако в мире Agile и в производстве ПО такая мысль очевидной почему-то не является. Скорее наоборот — всячески приветствуется самостоятельное развитие команд. Лично я считаю это мнение ошибочным. У команды должен быть тренер, который составит план её развития, подскажет, какие практики нужно освоить и как их правильно выполнять. Конечно, кроме обязательной, у команды может и должна быть и произвольная программа. Причём успешные идеи из произвольной программы одной команды стоит включать в обязательную программу остальных. Проще говоря, важно построить среду распространения удачных практик среди всех команд, для этого (то есть для учёта, оценки, планирования и распространения) и нужна структура наподобие тренерского штаба. Таким штабом становится центр управления производственными командами.

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

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

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

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

Совокупность процессов, в которых участвует команда, образует синхронизированную виртуальную модель команды — её цифрового двойника. Это не тень, которая только отражает состояние реального объекта. Цифровой двойник так же автоматически влияет на реальный объект в обратную сторону. Скажем, цифровой двойник команды автоматически подсказывает ей действия, направленные на успешное выполнение спринта, несмотря на негативный прогноз. Использование технологии чат-ботов как канала взаимодействия между цифровым двойником и командой позволяет сгладить их коммуникацию — фактически перевести их взаимодействие в простое общение.

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

Цифровой профиль производства — это хранилище, содержащее исторические и актуальные данные обо всех производственных процессах, что позволяет оптимизировать эффективность производства и бизнеса в целом. Кроме того, он содержит исторические и актуальные данные обо всех командах (независимо от их географического расположения) и используемых в работе инструментах. Например, команды могут одновременно работать в разных трекерах задач: Digital Q. Tasks, Atlassian Jira или Redmine. Вся информация о задачах и их движении будет сохраняться в цифровом профиле в едином виде, удобном для последующего анализа и обработки. Профиль не зависит от конкретного типа или экземпляра использованного командой инструмента.

Цифровой профиль производства основан на огромном объёме данных, полученных в ходе измерений множества характеристик объектов в реальном мире. Анализ накопленных данных позволяет получать точную информацию о производительности процессов, а также приводить к выводам о том, какие изменения и когда требуется вносить как в программный продукт, так и в сам процесс его производства.

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

СИТУАЦИОННЫЙ ЦЕНТР:

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

Одним из аналогов навигационного приложения для производства программных продуктов является график сгорания задач (англ. burndown chart). Он показывает скорость реализации задач и прогнозирует срок реализации оставшихся задач. Подробно о графике сгорания задач смотрите в соответствующем разделе книги.

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

Ситуационный центр создаёт широкий простор для совершенствования и наращивания возможностей цифровой системы управления производством программных продуктов.

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

Использование единого информационного пространства даёт определённые преимущества:

Чем среда взаимодействия отличается от прямой передачи данных и документов между участниками команд? Для лучшего понимания сравним два подхода к разработке и согласованию с командой технического задания.

Устаревший подход предполагает разработку документа аналитиком команды, далее он рассылает документ всем членам команды. Допустим, в команде, кроме аналитика, ещё шесть участников. В этом случае получаем семь копий документа, исходная — у аналитика, остальные — у членов команды. Каждый из них вносит изменения в свою копию документа в режиме правки и возвращает документ аналитику. Тот, получив шесть разных копий документа, переносит изменения в свою копию. Затем повторяется процесс согласования.

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

В компании «Диасофт» для организации единого информационного пространства используется Atlassian Confluence.

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

Приведу пример организации единого информационного пространства в компании «Диасофт». Оно состоит из четырёх видов взаимосвязанных пространств.

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

На этапе становления команды эксперты без отрыва от работы выполняют следующие действия:

На этапе развития команды:

На этапе масштабирования:

Эксперты должны «жить» в своих командах и посещать её основные мероприятия (планирование, ежедневная встреча, обзор результата спринта, ретроспектива). Особое внимание — наиболее слабым участкам работы команды. За квартал эксперт обязан посетить любое мероприятие каждой подшефной команды не менее трёх раз. Исходя из моего опыта, за одним экспертом можно закрепить от 7 до 15 команд: семь, если они на этапе становления, и 15 — на этапе развития.

Центр управления производственными командами участвует в разработке годовой стратегии развития команд. В нашем быстро меняющемся мире принимать стратегию больше, чем на год, не имеет смысла. Далее она декомпозируется на квартальные этапы. Детально стоит прорабатывать мероприятия только ближайшего квартала. Примером стратегической цели развития может быть создание и внедрение во все команды очередной полезной практики. Рекомендую придерживаться следующей квартальной декомпозиции стратегической цели:

Если практика несложная, рекомендую объединить второй и третий, а также четвёртый и пятый этапы. Параллельно вы можете внедрять несколько практик.

Профессиональное сообщество (англ. Community of Practice) — самоорганизующаяся группа экспертов, которые обмениваются знаниями по определённой тематике, общаются, чтобы вместе решать профессиональные задачи, учиться друг у друга и находить новые решения и подходы.

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

При построении сообщества необходимо обратить внимание на четыре основных фактора его успешной работы:

Рекомендую организовать (правильнее сказать — помочь созданию) профессиональное сообщество вокруг каждой значимой для компании производственной роли, например:

Со временем такие сообщества должны перехватить лидерскую функцию по определению, развитию и распространению технологий и инструментов в командах. Именно профессиональные сообщества, а не технологические дирекции должны определять, какие технологии и инструменты команды будут применять в работе. Таким образом организация перейдёт от внедрения или навязывания технологий и инструментов командам к самостоятельному освоению. Это снизит сопротивление команд при использовании новых практик, технологий и инструментов.