Джефф Сазерленд - Scrum. Революционный метод управления проектами
- Название:Scrum. Революционный метод управления проектами
- Автор:
- Жанр:
- Издательство:Манн, Иванов и Фербер
- Год:2015
- Город:Москва
- ISBN:978-5-00057-722-6
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джефф Сазерленд - Scrum. Революционный метод управления проектами краткое содержание
Scrum. Революционный метод управления проектами - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Замечательно, когда есть производители, выпускающие изысканные автомобили небольшими партиями. Но что делать тем производителям, которые выпускают массовые автомобили? Тогда любой брак оборачивается миллиардными расходами. Как пишет Вумек:
…Немецкому заводу приходилось прилагать довольно большие усилия, чтобы исправить дефекты в автомобилях, только что сошедших с конвейера; тогда как японский завод практически сразу и без усилий создавал безупречный автомобиль8.
Да, вы все верно поняли. Немцы чинили только что собранную машину дольше, чем японцы производили новую. Японские компании скрупулезно проводили сборку с самого начала производственного процесса. Вот почему Toyota стала лучшим в мире производителем автомобилей.
Мы не всегда умеем сразу делать все правильно. Мы люди и мы совершаем ошибки. Однако то, как мы дальше поступаем с этими ошибками, исключительно отражается и на скорости нашей работы, и на ее результатах. В Toyota, как мы уже знаем, каждый сотрудник завода, если заметил погрешность, мог остановить конвейер. Мысль нехитрая: поскольку линия движется безостановочно, а сборка должна проходить безукоризненно, то самый правильный момент для исправления брака — та минута, когда вы его заметили, а не после того, как перед вами будет стоять готовое изделие.
Несколько лет назад я был в Калифорнии, где встречался с разработчиками из компании Palm. Они одними из первых создали портативное устройство, названное карманным персональным компьютером, а сегодня известное как смартфон. Программисты Palm автоматически отслеживали свои действия и изучали все их параметры. Одним из многочисленных факторов, которые они измеряли, была необходимая продолжительность работы по исправлению ошибок. Другими словами, сколько времени у разработчика уходило на то, чтобы решить проблему, которую он создал в системе. Компьютер отслеживал каждый такой случай автоматически.
В один прекрасный день стали готовить код, написанный, скажем, Мэттом, к интеграции в систему, и вдруг при автоматическом тестировании обнаружилась ошибка. Как и большинство разработчиков, Мэтт махнул на это рукой и поклялся, что обязательно вернется к ошибке позже. Вот напишет новый код и тогда исправит старый. В большинстве компаний по разработке программного обеспечения тестирование не проводится в тот же день, как запускается программа. Могут пройти недели или месяцы, прежде чем код протестируют, и только тогда будет обнаружена проблема. В Palm ежедневно проводились автоматические проверки, поэтому об ошибке стало известно сразу.
Тогда в компании внимательно присмотрелись ко всем своим Мэттам — а в ней работали сотни разработчиков — и решили проанализировать, сколько времени понадобится на то, чтобы исправить ошибку сразу, а сколько — если вернуться к ней через несколько недель. Все мы в состоянии понять, какой сложной и запутанной может быть программа, поэтому я вас спрашиваю: во сколько раз больше будет потрачено времени во втором случае?
В 24 раза . На исправление ошибки, обнаруженной в день, когда она была сделана, уходил час. Спустя три недели требовалось уже двадцать четыре часа . В принципе не имело значения, была ли ошибка крупной или мелкой, сложной или простой, — в любом случае, если к ней возвращались через три недели, времени требовалось в 24 раза больше. Нетрудно представить, что последовало за этим открытием: каждый разработчик программного обеспечения был обязан тестировать и проверять свой код в день его написания.
Возможности человеческого мозга небезграничны. Мы не в состоянии запомнить более определенного количества объектов; мы неспособны по-настоящему фокусировать внимание за один раз более чем на одном явлении. Рассматриваемая нами тенденция: усложнение процесса исправления ошибок по мере увеличения временного промежутка с момента их совершения — еще раз подтверждает это ограничение. Когда вы работаете над проектом, вы создаете вокруг некое ментальное пространство. Вы знаете все аргументы, почему что-то делается так, а не иначе. Вы держите в уме весьма сложную конструкцию. Воссоздать эту конструкцию спустя неделю очень тяжело . Вам понадобится вспомнить все факторы, которые вы учитывали при принятии решения. Придется воссоздать мыслительный процесс, который привел вас к этому решению. Нужно будет снова стать собой в прошлом, заглянуть в собственное сознание, которое уже изменилось. На все это нужно время. Длительный срок . В 24 раза больше, чем потребовалось бы, чтобы устранить ошибку, как только вы ее обнаружили.
Уверен, вы уже сталкивались с подобным явлением в своей жизни. Скорее всего, еще в детстве вы усвоили простое правило: делай все как следует с первого раза . Единственное, что следует к этому добавить: если вы допустили ошибку (а мы все совершаем ошибки), исправлять ее надо немедленно, как только она будет обнаружена. Если не сделать сразу, то придется дорого платить за свою ошибку.
НАПРЯЖЕННЫЙ ТРУД ПОРОЖДАЕТ ЕЩЕ БОЛЬШЕ РАБОТЫ
Когда основатель OpenView Venture Partners Скотт Максвелл сотрудничал в начале 1990-х годов с McKinsey & Company, он получил от Джона Катценбаха одно напутствие, показавшееся ему тогда довольно странным. В те годы Джон Катценбах возглавлял McKinsey, в настоящее время он руководит Центром Катценбаха, действующим в рамках компании Booz Allen Hamilton; он известный автор множества статей и бестселлеров. Именно этот опытный эксперт в области управления дал Максвеллу совет, который тот запомнил на всю жизнь.
В разговоре со Скоттом Джон Катценбах вспомнил, что в 1970-е годы, когда он только начинал работать в McKinsey, в компании все трудились семь дней в неделю. Такова была корпоративная культура, и от каждого сотрудника ожидали абсолютной приверженности. Если ты работал меньше, считалось, что ты недобросовестно относишься к своим обязанностям и не вносишь нужного вклада в общее дело.
По религиозным причинам Джон Катценбах не приходил на службу по субботам. Поневоле он обратил внимание на одно интересное обстоятельство: работая меньшее количество часов, он тем не менее успевал делать больше , чем остальные сотрудники, трудившиеся каждый божий день. Надо сказать, в те времена в McKinsey работали практически одни мужчины. Джон решил попробовать работать пять дней в неделю и обнаружил, что стал успевать еще больше. Когда трудишься не покладая рук, заметил он, успеваешь делать намного меньше. Он сказал Скотту, что всегда хотел сократить свою трудовую неделю до четырех или даже трех дней, но опасался, что такой наглости McKinsey уже не выдержит.
Скотт и другие молодые консультанты тогда посмеялись над ним: «Работать меньше часов? Кажется, это называется “сачковать”». И все-таки идея Джона Катценбаха запала Скотту в душу, поселившись там на многие годы, пока он продвигался по карьерной лестнице. Основав OpenView Venture Partners и став ее руководителем, он начал вкладывать деньги в технологические компании, причем некоторые из них уже использовали Scrum. От кого-то он услышал мое имя как создателя методики. Выяснил, что я живу с ним в одном городе, — и однажды утром пригласил меня позавтракать вместе. За кофе и круассанами Скотт рассказал мне историю одной компании, в которую он инвестировал. Команда разработчиков, применяя Scrum, улучшила свою продуктивность сначала на 25 процентов, а потом дошла до 35. Скотт находился под большим впечатлением. Моя мгновенная реакция несколько охладила его: «Как?! Двадцать пять?! Тридцать пять?! Да они что-то делают не так!!!»
Читать дальшеИнтервал:
Закладка: