Цитаты из книг автора «Алексей Минкевич»

Домен V. Беспорядок (Disorder) — именно так автор данной модели назвал ситуацию, в которой люди, принимающие решения, не осознают, в каком домене они находятся и какие практики следует применять. Модель предполагает, что в любой ситуации необходимо двигаться по часовой стрелке: от хаотичного домена к упрощению. Благодаря этому основная масса неблагоприятных ситуаций останется между сложным и запутанным доменами, и лишь некоторая часть перейдет в первый домен, где среда упорядочена. Правда, стоит помнить, что пренебрежение сложностью и чрезмерное стремление к простоте могут привести к обрыву (Cliff) VI, который мгновенно переведет ситуацию в хаотичный домен без возможности так же легко вернуться назад.

Домен IV. Хаотичный (Chaotic). В этом домене приходится иметь дело с неупорядоченной (unordered) средой. Если в предыдущем домене связи между причиной и следствием были неясными, то в этом их просто нет. Схема действий такая: Необходим лидер, который, основываясь на своем чутье, предпримет действия, которые предотвратят агонию → Основываясь на результатах действия и факте, что «кровотечение купировано», лидер может продумать следующие действия по стабилизации ситуации → Получение ответа на ситуацию, который переведет ее в домен III. Практики, которые рождаются в этом домене, называются инновационными (novel). Ситуации в данной среде можно сравнить с городом во время стихийных бедствий. В качестве примеров мы можем взять дефолт в России 1998 г. или крах Enron в 2001 г. Несколько примеров из IT-отрасли: в проекте горят сроки, команда отказывается от всех подходов, использовавшихся ранее, и лихорадочно начинает доделывать работу; во время очередного релиза что-то идет не так: система, которой уже активно пользуются, перестает функционировать, но при этом все еще неясно, что произошло с технической точки зрения; система подвергается атаке злоумышленников, которые нашли уязвимость, а сотрудники компании пытаются применить несогласованные меры для решения ситуации. Если мы снова призовем на помощь аналогию, то все примеры, приведенные выше, можно сравнить с пожаром среди ночи. В такой ситуации нет времени на планирование и обдумывание — нужен лидер, который даст четкие распоряжения по спасению жизней жильцов дома, а заодно и некоторого имущества. Только после этого, избежав угрозы, можно все обдумать и спланировать следующие шаги.

Домен III. Запутанный (Complex). В этом домене среда уже не является упорядоченной (unordered). Важно не путать ее с беспорядком (disorder), о котором мы поговорим дальше. Здесь приходится иметь дело с отсутствием и непониманием связей между причиной и следствием. Лучший вариант найти их — это собрать данные, основываясь на предпринятых действиях (экспериментах). Решения принимаются по схеме: Предпринять действия, которые помогут собрать данные о ситуации → Осознание ситуации на основании полученных данных → Получение ответа на ситуацию, который позволит перевести ее в домен II (запутанный). В этом домене нет хороших решений. Все, что мы делаем, это ищем свой путь и изучаем правила игры. Практики в этом домене называются появляющимися (emerging); к ним мы отнесли Agile. Чаще всего в такой ситуации оказываются стартапы: у бизнеса есть предположение, что определенная гипотеза может сработать. Для подтверждения гипотезы создается минимально жизнеспособный продукт, после запуска которого у компании появляется необходимая информация для планирования следующих шагов. Это можно сравнить с тарелкой спагетти: сложно сказать, как именно переплетены отдельные макаронины между собой, и лучшее, что можно сделать, это потянуть за одну из них и посмотреть, какие еще спагетти с ней соприкасаются.

Домен II. Сложный (Complicated). В этом домене среда является упорядоченной, но уже не так просто найти связь между причиной и следствием. Для нахождения таких связей требуется определенный уровень компетенции и опыта. Решения принимаются по схеме: Осознание ситуации → Анализ ситуации экспертом → Ответ на ситуацию с помощью одного из нескольких вариантов решений. Важно отметить, что, в отличие от предыдущего домена, здесь уже нет единственно верного решения. Любые попытки действовать по принципу домена I вызывают недоумение у экспертов и потерю всяческой мотивации. Это связано с тем, что они могут быть не согласны с навязываемым «единственным правильным решением». Практики в этом домене называются «хорошими» (good practices), как бы намекая на то, что существуют альтернативы. К практикам этого домена мы можем отнести PMBOK, PRINCE2, ITIL. Ярким примером из IT будут проекты по внедрению на предприятиях, скажем, SAP-решений. У таких проектов есть несколько признаков: у исполнителя есть опыт выполнения подобных проектов; заранее известно, что представляет собой готовое решение; решение не начнет приносить пользу до тех пор, пока не будет выполнен основной объем работ. В качестве аналогии можно привести задачу строительства бассейна, где вырытый котлован и подведенные коммуникации будут абсолютно бесполезны до тех пор, пока чаша бассейна не будет сконструирована и наполнена водой. При этом один и тот же проект бассейна не гарантирует успешной реализации без привлечения эксперта, который сможет проанализировать, все ли идет по плану, заменить материал на аналогичный в случае, если необходимый невозможно купить, или решить, какие изменения нужно внести из-за особенностей почвы в данном районе.

Домен I. Простой (Simple), или предсказуемый (Obvious). В этом домене речь идет о простой упорядоченной среде, где не возникает проблем с пониманием причинно-следственных связей. Решения принимаются по следующей схеме: Осознание ситуации → Категоризация ситуации → Ответ на ситуацию с использованием хорошо известного решения. Важно отметить вот что: предполагается, что у ситуации всего одно решение, которое всем кажется очевидным. Ситуации, в которых существует только одно решение, называют лучшими практиками (best practices). Использование лучших практик встречается в управлении качеством, когда организации разрабатывают внутренние стандарты для ужесточения требований, которые могут являться обязательными и на уровне законодательства. Лучшие практики могут быть основаны как на текущих результатах компании и желании их улучшить, так и на анализе рынка (benchmarking). Популярными лучшими практиками являются ГОСТ и ISO. До сих пор, например, колбаса или тушенка с обозначением ГОСТа на этикетке ассоциируется у потребителей с высоким уровнем качества продукта. Пример лучших практик на уровне организаций — это рабочие процессы в компаниях типа McDonald’s, которая смогла сделать так, что бургер компании в любой стране мира будет иметь одинаковый внешний вид и вкусовые качества. Хорошим примером из IT-отрасли может служить тестирование, где есть чек-лист, следуя которому сотрудник имеет возможность удостовериться, что приложение (или его часть) работает корректно.

«Классика или гибкие методологии?» — тема для бесконечных споров на любой конференции или тренинге по управлению проектами. Дискуссия очень заразная, и любой руководитель проектов хотя бы раз участвовал в таком споре. Каждый участник обычно приводит достойные примеры того, как работает его любимый подход и не работает подход его визави. Именно такой спор однажды произошел с одним из коллег, занимающимся внедрением Agile в крупных российских госструктурах. В результате мы договорились и сформулировали утверждение следующим образом: «Раз есть ситуации, при которых одна методология работает лучше другой, то должен быть и способ, позволяющий понять, что лучше использовать для решения поставленной задачи». Коллега сослался на очень любопытный фреймворк Киневина, который мог бы помочь с поиском решения данного вопроса. Мы начали набрасывать на него наши аргументы и буквально влюбились в этот подход. Модель Киневина (Cynefin Framework) была разработана в начале 2000-х гг. в IBM Дейвом Сноуденом. C 1984 г. Дейв работал в компании Data Sciences Ltd, после поглощения которой в 1996 г. оказался в IBM, где впоследствии возглавил IBM Cynefin Centre for Organizational Complexity. Модель Киневина еще называют моделью создания смысла (sensemaking), которая позиционировалась как процесс, посредством которого люди придают смысл своему коллективному опыту. Cynefin в переводе с валлийского означает «прибежище, среда обитания, привычный, знакомый». Давайте рассмотрим эту модель подробнее и разберемся, при чем здесь вообще проекты. Модель состоит из пяти основных доменов принятия решений, в которых может находиться система. Домены также могут называться контекстами или средами. В нашем случае в роли контекста выступает проект, поэтому мы будем рассматривать модель в адаптации к проектам (рис. 67).

Классический подход и Agile — это набор инструментов менеджера. Все больше проектов сочетают в себе разные инструменты. Количество проектов, которые используют смешанные методологии, растет с каждым годом. Определяющим фактором успеха при этом является не использование какой-либо определенной методологии, а применение формального подхода к управлению проектами в целом. Если на проекте используется любой из подходов, то его шансы достичь цели, быть выполненным в рамках бюджета и в срок существенно выше. Гибкие методологии — это стиль и отношение к работе. На уровне управления хорошей командой они дают замечательный мотивирующий эффект, помогают с целеполаганием и повышением результативности. Фреймворк управления проектом по классической методологии, которому посвящена эта книга, почти во всем пересекается с фреймворком гибких методологий, но он гораздо шире и охватывает больше областей. Фреймворки гибких методологий объединили в себе хорошо работающие практики и идеи из «старых книг», упростив сложные для понимания моменты. Нам нравится следующая концепция: «Быть Agile — это не слепое следование какой-либо методологии, это мировоззрение, в основе которого — постоянное совершенствование». К сожалению (или к счастью), в нашей практике не было ни одного проекта, выполненного от и до в соответствии с какой-либо методологией. Каждый раз это череда проб и ошибок: что-то подходит и остается в работе надолго, что-то не подходит, и тогда приходится искать работающие инструменты дальше. Основная идея состоит в том, что не нужно пытаться найти идеальное решение — «серебряную пулю». Нужно быть открытым к изменениям, не бояться пробовать что-то новое. Шаблоны и наработки нужны, они сильно экономят время, но это не панацея. И вот мы подошли к главному вопросу: как узнать, какую же методологию выбрать для проекта? Об этом мы поговорим дальше.

Lean базируется на шести принципах. 1. Исключение затратных процессов и продуктов разработки. Фокусироваться нужно на основных функциях продукта, которые необходимы большинству пользователей. Не стоит тратить время на эксклюзивные свойства/функционал, востребованные небольшим числом пользователей. Более того, если какими-либо функциями мало пользуются, то их нужно убирать из продукта. Сопровождение этих функций требует денег, а наличие в кодовой базе замедляет разработку. Дефектов быть не должно. Зачем тратить время и нервы на устранение дефектов в готовом продукте? Лучше потратить чуть больше времени, но написать код качественно с первого раза. Переключение с задачи на задачу отнимает время. Инженеру приходится вспоминать контекст, заново прочитывать требования, поднимать проектную переписку. Гораздо лучше работать над одной задачей в один временной отрезок. Планирование зависимостей осуществляется таким образом, чтобы минимизировать или вообще сократить до нуля простои команд, когда одну из них блокирует другая. Зачем работать над детальной документацией требований, если ее никто не читает и она мгновенно устаревает в процессе? К этой же категории относится микроменеджмент и излишняя менеджерская деятельность. Команда разработки должна знать весь контекст и понимать, что нужно делать. 2. Акцент на обучении и постоянном совершенствовании. Обучение должно проходить на собственном опыте. Команда все время обогащает свои знания, пробует новые подходы и экспериментирует. Как и везде, в этом нам помогает цикл Деминга: планирование — действие — проверка — корректировка. 3. Принимать решения как можно позже. Если у нас есть возможность отложить принятие решения, то лучше это сделать. Почему? Чем больше удалось собрать информации, тем выше будет качество принятого решения. Следовательно, чем позже вы принимаете решение, тем больше у вас будет информации и тем более верным оно будет. 4. Поставлять как можно раньше. Тот же принцип, что и в Extreme Programming. Предельно быстрая доставка продукта заказчику и короткие итерации, создающие ценность. Оперативная обратная связь. 5. Уважение и доверие. Важно уважать людей, с которыми работаешь, и поручать им ту работу, которую они умеют выполнять лучше всего. Нужно обеспечить команду всем необходимым для работы и доверить ей ответственность за результат. Приветствуется уход от армейской системы управления с приказами и микроменеджментом. Вместо этого командой нужно управлять, вдохновляя и мотивируя ее. Важно отсутствие политики, то есть нужно делиться всей информацией с командой. Если команда полностью понимает контекст, то она сама сможет принять лучшее решение. Так происходит, поскольку у членов команды есть еще и технический контекст, в который они разбираются лучше. Ответственность за результат должен нести тот, кто делает реальную работу.

6. Строить целостное решение. Концентрироваться на общей картине и том, что действительно важно, и не зацикливаться на деталях. Важно смотреть на работу с точки зрения продукта или системы, чтобы понять, насколько работа способствует их улучшению. Вся команда должна понимать и разделять принципы бережливости: «Мыслить широко. Делать быстро. Ошибаться редко. Учиться стремительно».

Методология Lean («Бережливое производство») родилась в производственной сфере. Это произошло потому, что нужно было устранить из производственной цепочки шаги, которые не добавляли ценности итоговому продукту и за которые клиент не хотел платить. Понятие «lean» появилось в 1980-х гг. Как правило, компании, применяющие Lean, характеризуются культурой непрерывного совершенствования, которая проявляется и в организации как таковой, и на базовом операционном уровне. Базовым принципом мышления в стиле Lean является создание ценности. Действие, создающее ценность, должно соответствовать трем критериям: быть нужным потребителю; менять форму/функцию продукта/услуги, тем самым приближая их к финальному состоянию; должно быть произведено без дефектов с первого раза. Если одно из требований не выполняется, то считается, что действие не создает ценности. Lean-методология строится на идее снижения затрат, она отодвигает в сторону любые вещи, не направленные на достижение цели, — в частности, любые артефакты, которые не создают реальную ценность для бизнеса. Например, зачем писать детальную документацию, если система развивается настолько быстро, что документ мгновенно устаревает? Но раз уж совсем без документации нельзя, то можно изменить подход и улучшить качество кода, чтобы он легко читался, так что будет сразу понятно, как и что работает.