Джефф Сазерленд - Scrum. Навчись робити вдвічі більше за менший час

Метою цього було привести до Medco нових клієнтів, яких здебільшого обслуговували різні страхові компанії. За допомогою цих нових аптек, чи лікувально-оздоровчих центрів, як їх вирішили назвати, клієнти могли б економити гроші, зменшивши не стільки витрати на свої ліки, скільки загальні медичні витрати. Адже ті суттєво зростають, коли люди лікуються неправильно або приймають препарати, що погано взаємодіють один з одним або просто не підходять цій конкретній особі. Понад те, Medco гарантувала економію коштів. Якщо клієнт не зекономить прогнозовану суму, компанія зобов’язувалась повернути йому різницю.

На Волл-стрит, м’яко кажучи, сподобалась ця новина. Доволі класна ідея, чи не так? Економити гроші й надавати краще медичне обслуговування. Більше клієнтів, більше продажів. Ситуація з гарантованим виграшем. Була лиш одна проблема. Хоча Клеппер і перевірив зі своїми менеджерами, що ідея технічно можлива, він не уточнив, скільки часу займе впровадження цього плану. Люди, які дійсно мали цим займатись, зробили це лише після того, як їхній президент пообіцяв Волл-стрит, що нова система запрацює 7 липня 2007 року. Хай там що, за будь-яких умов.

Дотриматись цього дедлайну було для Medco особливо важливо, бо, хоча вони першими запропонували ідею аптек з автоматизованою розсилкою ліків поштою, конкуренти не дрімали. На жаль, перешкод на їхньому шляху вистачало. Наприклад, значна частина програмного забезпечення компанії, на якому працювала вся роботизована система на місцях, сильно застаріла. На п’яти величезних заводах компанії рецепти обробляли чотири тисячі фармацевтів, пігулки зі складу діставали одні роботи, а обробляли замовлення, пакували та відправляли інші. І всі елементи цієї системи мали взаємодіяти зі стовідсотковою точністю, бо інакше хтось із клієнтів міг просто померти.

Планувалося, що сміливий новий план Клеппера дасть Medco шанс удосконалити їхню систему й залишатися на крок попереду конкурентів. Проте приблизно через півроку в компанії зрозуміли, що вони не встигнуть підготувати все вчасно. Їхні розрахунки показували, що в найкращому разі систему буде запущено щонайменше на рік пізніше. Можливо, навіть більше. Саме тоді вони й звернулися до мене.

Чому ж їм знадобилось аж шість місяців , щоб зрозуміти своє запізнення? Спробуймо відповісти на це питання разом. Не те щоб вони були недостатньо розумними, не мали під рукою відповідних команд або технологій. Не те щоб вони недостатньо напружено працювали чи не прагнули обійти конкурентів. Адже без усього цього просто неможливо стати найбільшою компанією у своїй галузі.

Розробники проекту просто припустилися дуже типової помилки. Вони вирішили, що можуть спланувати все наперед. Вони витратили місяці зусиль на детальні плани, що здавалися бездоганними – викладені в гарних графіках і чітких кроках та майже завжди нескінченно далекі від реальності.

Як я вже казав раніше, планування дуже часто так приваблює та захоплює, що стає для людей важливішим за сам план. А план – важливішим за реальність. Проте завжди слід пам’ятати: гладенько буває лише на папері.

Коли команда вперше сідає за створення плану проекту, приміщення часто немов електризується – наповнюється відчуттям можливостей, відкриття нових світів та випробування нових ідей. Це дійсно є одним з найкращих відчуттів у житті.

А потім настає момент, коли натхнення перетворюється на розрахунки, і частина енергії розсіюється. Люди починають розмірковувати: «Як нам дійсно потрапити з точки А в точку B? І, коли ми це визначимо, скільки часу піде на дорогу?»

На жаль, такий етап розрахунку часто стає простим марнуванням часу. Залучені до нього люди можуть бути дуже розумними, але все одно не розуміти , що закладають у графіки свого планування лише бажане, а не дійсне.

Коли Марк Ленді пояснив мені ситуацію, що склалася в Medco , я відповів: «У вас таки проблема». А після коротенької паузи продовжив: «Але я впевнений, що ми зможемо її розв’язати».

Довелося мені перед самим Різдвом летіти до Нью-Джерсі, щоб цілий день просидіти в цій компанії, визначаючи масштаб проблеми. Зробити це було непросто. Там були цілі гори паперу з вимогами, погодженнями, усілякими звітами, поетапними планами та оцінками якості. Серед усього цього слід було відшукати щось дійсно потрібне для виконання проекту, але ніхто насправді не знав, як це зробити.

Після зустрічі з ключовим персоналом я зателефонував Брентові Бертону, Scrum -тренеру, з яким працював разом над іншими проектами. «Бренте, – мовив я, – мені потрібен ти та всі, кого ти зможеш зібрати до початку січня. Є робота, що неначе саме на нас чекала».