Джефф Сазерленд - Scrum. Революционный метод управления проектами

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

Замечательно, когда есть производители, выпускающие изысканные автомобили небольшими партиями. Но что делать тем производителям, которые выпускают массовые автомобили? Тогда любой брак оборачивается миллиардными расходами. Как пишет Вумек:

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

Да, вы все верно поняли. Немцы чинили только что собранную машину дольше, чем японцы производили новую. Японские компании скрупулезно проводили сборку с самого начала производственного процесса. Вот почему Toyota стала лучшим в мире производителем автомобилей.

Мы не всегда умеем сразу делать все правильно. Мы люди и мы совершаем ошибки. Однако то, как мы дальше поступаем с этими ошибками, исключительно отражается и на скорости нашей работы, и на ее результатах. В Toyota, как мы уже знаем, каждый сотрудник завода, если заметил погрешность, мог остановить конвейер. Мысль нехитрая: поскольку линия движется безостановочно, а сборка должна проходить безукоризненно, то самый правильный момент для исправления брака — та минута, когда вы его заметили, а не после того, как перед вами будет стоять готовое изделие.

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

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

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

В 24 раза . На исправление ошибки, обнаруженной в день, когда она была сделана, уходил час. Спустя три недели требовалось уже двадцать четыре часа . В принципе не имело значения, была ли ошибка крупной или мелкой, сложной или простой, — в любом случае, если к ней возвращались через три недели, времени требовалось в 24 раза больше. Нетрудно представить, что последовало за этим открытием: каждый разработчик программного обеспечения был обязан тестировать и проверять свой код в день его написания.

Возможности человеческого мозга небезграничны. Мы не в состоянии запомнить более определенного количества объектов; мы неспособны по-настоящему фокусировать внимание за один раз более чем на одном явлении. Рассматриваемая нами тенденция: усложнение процесса исправления ошибок по мере увеличения временного промежутка с момента их совершения — еще раз подтверждает это ограничение. Когда вы работаете над проектом, вы создаете вокруг некое ментальное пространство. Вы знаете все аргументы, почему что-то делается так, а не иначе. Вы держите в уме весьма сложную конструкцию. Воссоздать эту конструкцию спустя неделю очень тяжело . Вам понадобится вспомнить все факторы, которые вы учитывали при принятии решения. Придется воссоздать мыслительный процесс, который привел вас к этому решению. Нужно будет снова стать собой в прошлом, заглянуть в собственное сознание, которое уже изменилось. На все это нужно время. Длительный срок . В 24 раза больше, чем потребовалось бы, чтобы устранить ошибку, как только вы ее обнаружили.