Оказавшись узким местом в системе, всегда ожидаешь работы в многозадачном режиме с постоянным переключением между нормальной работой с полной занятостью и более редкими эпизодами разовых задач. Имейте в виду: множество команд, как правило, нагружены массой задач, возложенных на них в то же самое время, но не называйте это «многозадачностью». Люди обычно используют термин «многозадачность», чтобы замаскировать факт перегруженности команды. Разделение работы и подталкивание команды к многозадачному режиму часто удерживает вас от признания, что работы больше, чем времени, особенно если учесть дополнительное время и когнитивные усилия, необходимые для переключения между задачами.
Например, команда, которая 100 % своего времени посвящает разработке, может иметь руководителя с магическим мышлением, который просит ее потрудиться несколько часов в неделю в режиме многозадачности, в связи с чем люди уже не имеют ни поддержки, ни обучения, ни ремонта, ни совещаний, ни других дел. Им трудно однозначно определить, что работы оказалось больше, чем времени, особенно если лишние задачи добавляются понемногу, а не за один раз. Разработчики начинают чувствовать себя перегруженными, и, поскольку все это носит название «многозадачность», они не всегда догадываются, почему им так тяжело. Появится чувство, будто есть много работ на неполный рабочий день, за которыми невозможно угнаться. Можно помочь команде, применяя теорию массового обслуживания, чтобы разобраться в проблеме. Теперь мы знаем, что работа накапливается в узком месте где-то в рабочем процессе и растет взваленный на разработчиков ее объем.
Система вытягивания – способ выполнения проекта или процесса, который использует очереди или буферы для устранения ограничений. Это еще одна концепция из тех, что возникли в японской автомобильной промышленности, но впоследствии нашли свое место в области разработки программного обеспечения. Производители автомобилей, в частности Toyota, в 1950-х и 1960-х годах оценили свои склады комплектующих и попыталась найти способы уменьшить количество деталей, которые должны там лежать. После длительных экспериментов они обнаружили, что даже если в наличии почти все детали, необходимые для сборки автомобилей, то дефицит нескольких деталей может задержать всю линию. Потому что в итоге все монтажные бригады ждут поставки недостающих запчастей. Стоимость задержки становится важна: если деталь в дефиците, то задержка ее поставки на конвейер оказывается очень дорогой, а если часть имеется в изобилии, то стоимость задержки низкая.
Команды Toyota обнаружили, что можно сократить расходы и поставлять автомобили гораздо быстрее, если знать, какие запчасти нужны прямо сейчас, и поставлять на линию только их. Чтобы реализовать это, они придумали производственную систему Toyota (TPS). Это предшественница бережливого производства, которые Том и Мэри Поппендик адаптировали для создания бережливой разработки программного обеспечения.
В основе TPS лежит идея существования трех типов потерь, которые создают трудности в рабочем процессе и должны быть удалены.
М
М
М
Любой, кто участвовал в плохо управляемых, буксующих проектах программного обеспечения – особенно тех, что используют неэффективный процесс, – не понаслышке знаком с идеями неравномерности, бесполезности и неразумности. Это верно для неэффективных водопадных процессов, но любой работавший, скажем, в команде с неправильным мышлением, способной достигать только результата «лучше-чем-ничего» (или еще худшего) с применением Scrum или XP-практики, также может распознать эти случаи.
Не кажутся ли вам знакомыми какие-либо из перечисленных ниже действий?
• Заставить всех подписать спецификацию занимает много времени, а разработчики между тем сидят и ждут старта проекта. Как только он начнется, они уже опоздали.
• Вечная забота менеджмента – обеспечить бюджет. К тому времени, когда проект получает зеленый свет, думать об этом уже поздно.
• На середине разработки группа признает, что важные элементы дизайна или архитектуры программного обеспечения должны быть изменены, но это вызовет большие проблемы, потому что зависят от них многие другие вещи.
• QA-команда (Quality Assurance) не начинает тестирования программного обеспечения, пока каждая функция не будет завершена. Позднее они найдут серьезную ошибку или проблемы с производительностью, и команде разработки придется отвлекаться от текущей работы, чтобы это исправить.
• Анализ и дизайн продолжаются так долго, что, когда кодирование все-таки начнется, каждый программист вынужден работать по ночам и выходным, чтобы уложиться в срок.
• Архитектор программного обеспечения проектирует большие красивые сложные системы, которые внедрять нецелесообразно.
• Даже мельчайшие изменения в спецификации, документе или плане проекта должны пройти трудоемкий процесс управления изменениями. Вместе с тем люди находят способы, чтобы обойти его, внося радикальные, крупномасштабные изменения в систему заявок на техподдержку или отслеживание ошибок.
• Проект не успевает завершиться в срок, поэтому руководитель добавляет людей в команду в последние несколько недель. Вместо ускорения выполнения проекта этот шаг создает путаницу и хаос[81].
Вспомните ваши собственные проекты, которые столкнулись с проблемами из-за заведомо глупых действий. Возможно, это правила, которые пришлось выполнять (или обходить), установленные вашим руководителем или являющиеся частью культуры компании. А может быть – ненужные дедлайны, произвольно назначенные, чтобы мотивировать вас.