Agile совсем не гибкий

Источник: Vector consulting

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

Этот метод пыток можно сравнить с тем, как заранее определенная стандартная шкала используется для принудительной «подрезки» времени работ в условиях высокой изменчивости. Ориентированная на «спринты» методология разработки программного обеспечения (ПО) Agile страдает от феномена Прокруста. Границы применимости этой концепции в реальном мире весьма ограничены. Чтобы понять, почему и что делать, нужно вернуться к истории управления проектами при разработке ПО.

Сомнительная история

История успешного выполнения программных проектов вызывает сомнения. Согласно ежегодному докладу о хаосе (Chaos Report), проекты в области программного обеспечения, скорее всего, потерпят неудачу с точки зрения качества продукта, затрат и соблюдения сроков. Интересно, что тенденция остается неизменной на протяжении многих лет. В настоящее время широко распространено мнение, что именно методология водопада является одной из основных причин плохой репутации проектов по разработке ПО.

Проблема методологии водопада: процесс важнее скорости?

Методология водопада отвечает двум основным задачам в проектах разработки программного обеспечения:

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

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

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

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

1. требования;
2. проектирование;
3. разработка;
4. тестирование.

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

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

Agile: ускорение процесса?

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

Таким образом, в мире Agile можно отказаться от последовательной работы по этапам разработки программного обеспечения. Команда может работать как самоорганизующаяся группа, которая может итеративно проектирует, разрабатывает, тестирует и выпускает работоспособные функции. Временем управляют с помощью концепции спринтов (широко используемая версия Agile, известная как Scrum) продолжительностью в 15/30 дней. Каждый спринт используется для поставки новой небольшой партии готовых функций ПО. Хотя текущий спринт заморожен, последующие могут быть изменены на основе обратной связи с клиентами.

Вовсе не Серебряная пуля

Итак, Серебряная пуля найдена. Или так только кажется? На самом деле нет ни одного убедительного, четкого и неоспоримого исследования, установившего решающее превосходство методологии Scrum. Кроме того, вызывает озабоченность рост голосов практикующих Scrum против этой методологии. Многие подчеркивают растущую нагрузку разработчиков, постоянно увеличивающийся список отставаний и неудовлетворенность клиентов в отношении удобства использования программного обеспечения. Удивительно, но эти эффекты прямо противоположны тому, что обещал Agile!

В качестве противоположного аргумента сторонники методологии утверждают, что основной причиной проблем являются пробелы в реализации, а не концептуальные недостатки. Аргумент пробелов в реализации перекладывает ответственность за плохие результаты на способности разработчика, а не изобретателя. («Они не смогли выполнить в срок, они были недисциплинированными!»). Подобное объяснение позволяет некоторым теориям управления оставаться повальным увлечением дольше, чем они того заслуживают. Поэтому важно вербализовать скрытые исходные посылки (или граничные условия) теории и проверить ее справедливость на практике.

Ошибочные исходные посылки (предположения)

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

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

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

Таким образом, весьма вероятно, что благодаря децентрализации навыков после принятия Agile многие опытные команды не смогут овладеть некоторыми навыками, особенно теми, которыми обладают опытные эксперты. Хотя каждая команда может иметь требуемое количество сотрудников, чтобы считаться на бумаге «независимой».

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

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

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

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

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

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

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

Гибридное решение

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

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

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

Иногда даже «буфера» в виде одного финального спринта недостаточно, чтобы компенсировать все прошлые грехи. Мало времени, давление, чтобы поскорей выпустить продукт, перегрузка отложенной работой – вот отличный рецепт для большинства компромиссов. Клиентам, скорее всего, будут поставлены некачественные продукты. Клиенты начнут жаловаться команде разработчиков на ошибки. Появится давление расширить команду разработчиков для исправления огромного списка ошибок в будущих релизах, что увеличивает стоимость разработки. Стресс, низкая производительность, задержки и плохое качество вовсе не редкость в такой среде.

Компании по разработке программного обеспечения проигрывают со всех сторон.

Agile против Водопада: решения для экстремальных ситуаций?

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

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

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

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

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

Тип «B» (ретроспективные): это переделки, возникшие благодаря новым знаниям, полученным после тестирования или понятной визуализации. Это своего рода дополнительная ценность, потому что в процессе генерируется новое знание. Например, создание прототипов генерирует переделки типа В с дополнительной ценностью. Переделка типа B неизбежна, и ни один мысленный эксперимент не поможет заранее визуализировать ошибки типа B. Единственный выход – разработать процесс генерации ошибок типа B на ранней стадии цикла разработки.

Метод водопада подразумевает, что все ошибки относятся к типу А и, следовательно, должны быть предотвращены. Эта школа мысли вдохновила производственный слоган «Изначально правильный» (First Time Right). Жесткость процесса с помощью проверок и «шлюзов» становится ключом к недопущению ошибок типа А. Agile предполагает, что все ошибки относятся к типу B, поэтому она рассматривает одноразовые передачи между этапами как пустую трату времени. Следовательно, Agile часто перемещается назад и вперед между всеми фазами.

Изучение истории автомобилестроения

Интересно, что Agile – именно тот подход, с помощью которого автомобили выпускались в конце 18 века. Он называется «кустарным» методом производства. Небольшой группе ресурсов со смешанными навыками давали машину, которая собиралась этой группой от начала до конца. Многофункциональная группа обладала навыками проектирования, подгонки и даже машинных операций. Не слишком совершенные детали можно было подогнать и приспособить друг к другу, и, в конце концов, автомобиль выпускался после трудных переделок. Этот способ производства автомобилей действительно был очень дорогим, и только богатые люди могли себе позволить машину в ту эпоху.

Когда Генри Форд представил концепцию конвейера с четким разделением труда, сборка была трансформирована. Четкая последовательность работ с различными ресурсами, специализирующимися на различных задачах сборки, определяла сборочные линии Ford Motors. Автомобили перемещались между рабочими станциями (вместо работников) для непрерывного потока продукции. Специализация по одному типу задач, а также предотвращение потерь при переключении (для ремесленного производства) между различными навыками, позволила увеличить производительность почти в пять раз.

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

Однако чтобы быть успешным, подход сборочного конвейера требует двух критических условий:

1. Обратные потоки незначительны
   Работа продвигается в одном направлении. Если характер работы таков, что он часто возвращается к предыдущим рабочим станциям для доработки, может возникнуть хаос с неконтролируемыми остановками линий конвейера и снижением производительности. (В таких условиях лучше всего использовать ремесленное производство или Agile). В случае Форда, работа сборочной линии была обеспечена путем стандартизации деталей, которые подходили к любому автомобилю, без необходимости подгонять и корректировать неподходящие детали для конкретного автомобиля, что устраняло обратный поток.
2. Передаточные партии должны быть небольшими (в идеале, поток единичных деталей)
   Передача больших партий не только увеличивает время выполнения на каждом этапе, но и приводит к позднему обнаружению проблем качества.

Модель быстрого потока (Rapid Feature Flow)

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

1. Минимизация обратных потоков

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

Этап требований

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

Этап проектирования

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

Шлюзы и принцип «держать в голове результат» должны помочь в предотвращении ошибок типа А и обнаружении ошибок типа В на раннем этапе процесса.

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

2. Минимизация передаточной партии

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

Как сделать передаточную партию одной функции – установить контроль над незавершенным производством (НЗП) в разных группах ресурсов. Контроль НЗП подразумевает, что новая функция будет введена в группу ресурсов только тогда, когда завершается работа над другой функцией в соответствии с критериями, установленными для передачи. Правило «один вошел, когда другой вышел» обеспечивает передаточную партию на уровне одной функции. (Следует проявлять должную осторожность, чтобы определить функции таким образом, чтобы они были достаточно независимыми).

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

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

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

Однако предложенная модель работы имеет следующие недостатки:

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

3. Улучшение предсказуемости

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

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

Разделение предсказаний и обязательств лучше всего можно понять с помощью аналогии с Google Maps. Карты Google показывают ожидаемое время поездки, учитывая пробки (очереди) на дороге. Но это всего лишь прогностический инструмент, и водитель не может приехать точно во время, заявленное Google. Что он может сделать эффективно, так это сократить потери в каждый момент вождения. В случае единого менеджера в системе фокус улучшения предсказуемости достигается за счет уменьшения очередей в системе и управления проблемами, прерывающими поток, на ежедневной основе.

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

4. Динамическое планирование релизов программ

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

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

1. шкала времени (для обеспечения предсказуемости, когда что-то будет выполнено);
2. шкала работы (для понимания объема).

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

Вы же помните, что случилось с Прокрустом? Он сам принял смерть на своем ложе от рук Тесея!

 

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.