Низкий уровень качества. Если вы не будете контролировать качество, то не сможете узнать о его снижении. Если вы построили работу по принципу ежедневных заданий или имеете ряд часто отслеживаемых параметров (подсчет ошибок и т. д.), то узнаете об этом практически сразу. Существует множество критериев снижения качества: сложный для последующей модификации программный код, не выполненные в полном объеме требования, низкая производительность или нестабильность работы программы. Причин снижения качества тоже немало: технические (связанные с основными методами разработки), производственные (связанные с контрольными процедурами и инструментальными средствами) или планировочные (связанные с календарным и общим планированием). Возможная реакция: установите для команды критерии высокого качества и ставьте ежедневные цели по их достижению (см. главу 15). Для повышения качества нужно чем-то пожертвовать (функциональностью, временем). Часто бывает, что лучше снизить темп работы до тех пор, пока уровень качества не достигнет нужных высот, и все не узнают, как этого достичь, а затем восстановить прежний темп.
Смена направления. Руководство или складывающаяся рыночная ситуация может потребовать изменений. Для проекта в этом может и не быть ничего плохого (можно даже рассчитывать на некий прогресс), но и радоваться тут, пожалуй, особо нечему. В смену направления могут вмешаться бюджетные сокращения или новые общие цели. Возможная реакция: нужно выяснить, нельзя ли ограничиться изменениями отдельных компонентов? Выделите те технические условия или их части, которые все еще жизнеспособны, и сохраните их в конвейере разработки (см. главу 14), затем расположите по приоритетам все, что требуется изменить. Убедитесь в том, что вы не попадаете в сферу действия безапелляционного приказа; ведь сказать: «Сделайте X» – не одно и то же, что сказать: «Мы должны увеличить доход на 10 %». Первое является директивой, второе – решаемой проблемой. Добейтесь выяснения сути проблем и вмешайтесь в процесс, предлагая приемлемые для себя решения (см. далее раздел «Разрешение конфликтов и ведение переговоров»).
Общекомандные или личные проблемы. Бывает, что недовольство одного или нескольких человек негативно отражается на всей команде. Недовольство может быть вызваны кем-то («Я не могу работать с Фрэдом») или чем-то («Я ненавижу наш способ анализа программного кода»). Возможная реакция: сначала поговорите с глазу на глаз со всеми фигурантами. Спросите каждого, что происходит и что можно сделать (вам или ему), чтобы улучшить ситуацию. Устраните проблему и дайте людям возможность найти выход. Ищите не только симптомы, но и причины (см. далее раздел «Разрешение конфликтов и ведение переговоров»).
Разногласия и конфликтные ситуации. Люди открыто не согласны с тем, что должно быть сделано (потенциально это может пойти проекту на пользу), но их несогласие тормозит прогресс. Больше времени тратится не на саму работу, а на дебаты и постоянные пересмотры того, что следует делать. В экстремальных случаях разные группы тайком работают в разных направлениях. Возможная реакция: обратитесь далее к разделу «Разрешение конфликтов и ведение переговоров».
Недостаток веры. Команда совсем не верит в направление работ по реализации проекта. Люди успешно справляются со своей работой и не выражают активного несогласия, но считают, что корабль плывет прямиком на айсберг. Возможные варианты: посмотрите, может быть, они и правы. Если нет, воспользуйтесь всем своим влиянием (см. главу 16), чтобы убедить команду в обоснованности выбранного направления. Начните с малого: кто верит в успех больше всех? Как можно развить его веру и распространить ее на всю команду? Попробуйте поставить команде более узкие задачи и дать толчок к их выполнению. Пройдитесь по офисам и задайте вопрос начистоту: «Послушайте, я знаю, что вы не верите в это направление, но я в него верю. Могу ли я как-нибудь убедить вас последовать этому направлению? Если нет, то не могли бы вы все равно мне довериться, хотя бы на неделю?»
Угроза мятежа. Это экстремально резкая форма выражения неверия в успех. Такой момент наступает, когда командой уже пройден порог крушения всех надежд, и люди практически не реагируют на любую вновь вскрывшуюся проблему, какой бы мелкой она ни была. Более того, люди больше жалуются на мнимые проблемы (к примеру, «Почему руководство, или тестировщики, или маркетологи продолжают работать в прежнем направлении?»), а не решают проблемы насущные. Если ничего не предпринимается, недовольство могут поддержать старые сотрудники, и начнется мелкий или символический саботаж (например, устранение некоторых ошибок может внезапно усложниться). Кто-то должен прямо выступить против сложившейся ситуации и разрядить обстановку. Нужно публично признать факт кризиса, составить список всех жалоб и открыто заняться рассмотрением некоторых из них.
