Всего за 999 руб. Купить полную версию
Интересно, что вся эта системная динамика возникла из-за введения вознаграждения, причем между верхней частью модели и ее нижней частью пока нет явной взаимосвязи.
Словом, нет никаких гарантий того, что введение вознаграждения обусловливает увеличение скорости разработки или даже влияет на нее.
Отказ от такой системы вознаграждения фундаментальное решение, которое позволяет устранить корневую причину этой дисфункции. Другая, пусть более поверхностная, но тем не менее работоспособная контрмера использование управленческой командой принципа бережливого менеджмента «пойди и посмотри»:
«Быстрые решения». Одно из трудных и медленных решений для увеличения скорости разработки улучшить человеческий ресурс: нанять сильных разработчиков, расширить обучение и коучинг имеющейся команды, уволить слабых сотрудников. Альтернатива достичь цели быстро и с наименьшими усилиями за счет «быстрого решения» или так называемого квик-фикса (quick fix). Иногда быстрое решение работает как в краткосрочной, так и в долгосрочной перспективе и действительно улучшает систему. Но иногда это не удается, и тогда получается как в поговорке: «Быстрее значит медленнее». Например, если стоит цель увеличить скорость поставки новой функциональности, первое, что обычно приходит в голову людям, увеличить количество разработчиков. Согласно их предположению, это самый быстрый и простой способ решить проблему со скоростью разработки. Итак, добавим в нашу схему это «быстрое решение» (символ БР):
Эффекты взаимодействия. Бюджет ограничивает наем новых сотрудников. Одно из трудных и медленных решений найти способы увеличить бюджет. Быстрое и простое решение нанять намного более дешевых разработчиков. В этом случае бюджет оказывает эффект взаимодействия, влияя на другие причинно-следственные связи. Когда принимается решение нанять дополнительных разработчиков, недостаточный бюджет вынуждает вас нанимать наиболее дешевых.
Просто провести (обратную) причинно-следственную связь напрямую от бюджета к коэффициенту найма очень дешевых разработчиков не совсем правильно, так как, по сути, это будет означать, что уменьшение бюджета ведет к увеличению найма очень дешевых разработчиков. Мы же хотим показать эффект взаимодействия а именно то, что причинно-следственная связь A влияет на причинно-следственную связь Б. Чтобы графически показать это, мы проводим линию обратной причинно-следственной связи от бюджета к линии быстрого решения (БР), которая в результате раздваивается на коэффициент найма обычных и очень дешевых разработчиков:
Сильные эффекты. Нам доводилось работать и с очень крутыми, но недорогими разработчиками, и с очень дорогими, но ужасными. Но, как правило, вы получаете то, за что платите, нанимая разработчиков из большого пула дешевой рабочей силы, вы получаете в среднем гораздо более низкий уровень квалификации, чем при найме из пула дорогих. В нашей модели мы хотим показать, что наем очень дешевых разработчиков резко увеличивает долю слабых (низкоквалифицированных) разработчиков в группе. Чтобы показать такой сильный эффект в модели, мы используем толстую линию:
Отложенные эффекты. Одной из проблем при найме разработчиков является заблуждение о небольшом разбросе в их квалификации ошибочное мнение, будто программисты не слишком отличаются друг от друга (с точки зрения производительности, качества кода и т. д.). Но исследования показывают, что верхний квартиль по уровню квалификации способен работать примерно вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница, согласитесь. Кроме того, модель COCOMO, основанная на многолетних масштабных исследованиях, показывает, что уровень квалификации группы разработчиков наиболее важный из всех факторов, влияющих на ее производительность [Boehm00]. Наконец, очень слабые программисты в среднем создают код худшего качества (с плохим дизайном) и с бо́льшим количеством дефектов, что дополнительно тормозит всю систему.
Но все эти влияния проявляются не немедленно, а с некоторым запозданием. Например, если вы наймете много слабых разработчиков, пройдет относительно много времени, прежде чем начнут ощущаться последствия их плохой работы / некачественного кода. Соответственно среднее снижение скорости поставки новой функциональности (вызванное сильным влиянием разброса квалификации программистов) произойдет не сразу, а спустя какое-то время.
Чтобы показать такое отложенное воздействие, мы используем на модели линию с двойной чертой:
Отложенный характер эффектов негативно влияет на способность системы к обучению и коррекции. Если результат или случайное следствие какого-либо действия проявляется с большой задержкой во времени, люди часто не видят (причинно-следственной) связи между ними, не понимают, что именно A повлияло на Б или, еще сложнее, что A повлияло на Б, а Б в ответ повлияло на А.
Следовательно, люди не учатся и не исправляют ошибки в правилах, управленческих действиях, инструментах и т. д. Именно из-за отложенных эффектов постепенное улучшение через практику бережливого подхода кайдзен может занимать длительное время: чтобы увидеть, улучшается ли что-то и как, требуется терпение и способность проникать в суть вещей.
Петли положительной обратной связи. Петли положительной или отрицательной обратной связи[9] и отложенные эффекты тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.
Таким образом, группа разработки входит в самоусиливающуюся нисходящую спираль последовательность петель положительной обратной связи, где каждая петля усиливает последующую. К счастью, этот нисходящий тренд ограничен бюджетом.
Попробуйте увидеть в системе петли положительной обратной связи.
По мере того как уходит все больше крутых разработчиков, которые могли бы создавать отличный код и обучать других, у слабых разработчиков становится все меньше возможностей для обучения. Процент слабых разработчиков растет, а качество кода и производительность падают все ниже. Код становится все более грязным, запутанным, с большим количеством повторений, что снижает способность группы быстро реализовывать новую функциональность. Падение скорости реализации новой функциональности вынуждает нанимать еще больше дешевых разработчиков. Короче, в системе создается множество самоусиливающихся петель положительной обратной связи.
Подсказка: чтобы выявить петли положительной обратной связи, найдите циклы с четным количеством причинно-следственных связей с обратным эффектом. В модели выше мы видим пять таких петель.
Заключение
Приведенный сценарий это только пример. Диаграмма причинно-следственных циклов позволяет наглядно представить сложную и неявную динамику системы рабочей среды. Лучше всего составлять ее на доске вместе с группой.
Учимся видеть ментальные модели