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

Хотя многие компании относятся к разработке как к промышленному производству, у них есть принципиальные различия. В мире изготовления физических объектов задачи повторяются, действия предсказуемы, а произведённые продукты могут находиться в одно время только в одном месте. При разработке софта многие задачи уникальны, проекту нужно постоянно меняться, а получающийся продукт – это информация, которая может одновременно находиться во многих местах.

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

Заблуждение 1: повышение утилизации ресурсов повысит эффективность работы

Очень многие компании стараются полностью задействовать имеющиеся у них ресурсы по разработке. Средний менеджер по продукту держит показатель использования ресурсов на отметке в 98%. Логика ясна – проекты делаются дольше, если люди не заняты на 100%, поэтому занятая организация будет работать быстрее и эффективнее, чем та, которая не так хорошо использует все людские ресурсы.

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

Они не принимают во внимание изменчивость работы разработчика

Многие аспекты разработки непредсказуемы – когда появятся проекты, решения каких задач они потребуют, как много времени займёт у тех людей, кто не занимался такими вещами раньше, на их завершение. Но компании больше всего знакомы с повторяющимися процессами, типа производства или обработки транзакций, где работа не меняется, а сюрпризов появляется мало. Такие процессы работают по графику, и утилизация ресурсов повышается. Чтобы выполнить на 5% больше, и времени потребуется на 5% больше.

Непостоянные процессы ведут себя совершенно по-другому. При увеличении утилизации ресурсов задержки резко вырастают. Добавьте на 5% больше работы, и её завершение может затребовать на 100% больше времени. Но мало кто это понимает. По нашему опыту с сотнями команд разработчиков мы знаем, что большинство из них работает больше, чем нужно. Чтобы закончить все проекты вовремя и уложиться в бюджет, некоторым организациям, с которыми мы работали, потребовалось бы на 50% больше ресурсов.

Зависимость времени ожидания окончания работы от процента утилизации ресурсов

Конечно, некоторое непостоянство возникает из-за отсутствия дисциплины, и некоторые задачи при разработке проектов (разработка компонентов для самолёта или клинические испытания лекарств) состоят из повторяющихся задач. Но даже если часть работы предсказуема, то будучи скомбинированной с непредсказуемой работой, она выдаст проблемы с планированием.

Они не понимают, как очереди влияют на экономическую эффективность

Высокая утилизация ресурсов неминуемо создаёт очереди из проектов. Когда недоделанная работа замирает в ожидании освобождения нужного ресурса, общая длительность проекта растёт. Очереди задерживают обратную связь, из-за чего разработчики идут по непродуктивному пути дольше. Компаниям становится тяжелее приспосабливаться к растущим нуждам рынка и найти слабости в продуктах, пока это ещё не поздно. По иронии судьбы, именно этого стараются избежать менеджеры, утилизируя ресурсы на 100%.

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

При разработке софта то, что находится в процессе разработки, обычно нельзя увидеть

Очереди на производстве создают физические предметы. Когда склад удваивается, это сразу видно. В случае разработки программного продукта склад состоит из информации – документации по дизайну, процедур и результатов тестирования, инструкций по построению прототипов. При удвоении склада никаких физических признаков этого не видно. А поскольку по стандартам бухгалтерского учёта эта информация по стоимости равна нулю, по финансовым отчётам также не видно прогресса.

Очень трудно бороться с проблемой, которую нельзя увидеть и измерить. Рассмотрим фармацевтическую компанию. Несколько лет назад новый директор по разработке лекарств столкнулся с дилеммой. Он пытался повернуть своих учёных на более инновационный путь. Он хотел, чтобы они больше экспериментировали с новыми химическими веществами, которые в перспективе могли стать лекарствами, и при этом как можно быстрее избавлялись от бесперспективных кандидатов. При этом тесты на животных лежали в области ответственности другого департамента, который ему не подчинялся. Этот департамент оценивали по тому, насколько эффективно он использовал ресурсы для тестирования, что приводило к необходимости высокой утилизации ресурсов. Естественно, учёные из отдела разработки лекарств ожидали по 3-4 месяца результатов тестов, на проведение которых требовалось всего около недели. «Хорошее управление» отделом тестирования мешало работать отделу разработки.

Очевидным решением подобных проблем является создание буферных мощностей для непостоянных процессов. Некоторые компании давно это поняли. В 3М уже несколько десятков лет разработчики задействуются на 85% их мощности. В Google инженерам позволяют 20% времени (день в неделю) заниматься чем угодно, что означает, что им всегда доступно дополнительное время в случае задержки проекта. Но такое решение довольно сложно организовать. Мало кто избежит искушения занять сотрудников на 100%. Менеджеры рефлекторно выдают новые задачи, когда видят простои.

Но есть и другие решения.

Сменить систему управления

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

Выборочно увеличивать ресурсы

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

Ограничить количество активных проектов

Если нельзя увеличить ресурсы в отделе тестирования на животных, можно уменьшить утилизацию ресурсов, уменьшив количество активных проектов. Дисциплина в отношении жёсткого ограничения работы конвейера, разрабатывающего продукты, часто приводит к лучшему фокусированию и более ясным приоритетам.

Улучшить видимость задач, над которыми идёт работа

Один из методов – доски визуального контроля. Вид у них может быть разный, но ключевой момент – иметь некие физические индикаторы, вроде бумажек для заметок, представляющих работу. На доске должна отображаться вся работа и состояние каждой части проекта. Она должна быть в центре управленческого процесса. Можно собирать ежедневные 15-минутные совещания у этих досок, чтобы координировать усилия и продвигать работу.

Типичный вид доски контроля процесса разработки

Первая колонка – новые задачи, примерно сходные по сложности. Вторая – задачи в работе. Цифра обозначает максимальное количество одновременно решаемых задач. Флажочек у задачи означает проблему. Третья – готовые к тестированию части. Повёрнутый листик означает необходимость вмешаться менеджеру. Четвёртая – тестируемые задачи. Цифра обозначает максимальное количество одновременно решаемых задач суммарно в обеих колонках. Пятая – задачи, прошедшие тестирование.

Заблуждение 2: обработка задач большими партиями улучшает экономику процесса разработки

Вторая причина появления очередей при разработке продукта – размер партий. Допустим, новый продукт состоит из 200 компонент. Можно решить разработать и построить все 200 перед тем, как начать их тестировать. Но если вместо этого разработать 20 компонент, то размер партии будет на 90% меньше. Это сильно уменьшит время ожидания, поскольку в среднем очередь пропорциональна размеру партии.

Уменьшение партий – основной принцип гибкого производства. Он позволяет сокращать работу, ускорять обратную связь, улучшать циклы производства, качество и эффективность. Малые партии в разработке продукта ещё более важны, но мало кто это понимает.

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

В хорошо управляемом процессе размер партий сбалансирует транзакции и стоимость хранения. Это как покупать яйца в продуктовом – если купить яиц на год вперёд, то стоимость перевозки будет низкой, но большинство яиц испортятся, что увеличит стоимость хранения. Если покупать яйца на день, портиться они не будут, но стоимость перевозки будет большой.

Оптимальный размер партии такой, у которого суммарная стоимость (транзакции и хранение) наименьшая. Малые отклонения от этой точки не приносят больших проблем. К примеру, если отклониться от идеального размера партии на 20%, изменение стоимости производства составит лишь 3%.

Разобравшиеся в этом вопросе, компании начинают уменьшать размеры партий, что приводит к удивительным результатам. Некоторые вместо одного тестирования больших партий раз в 90 дней переходят к тестированиям малых партий несколько раз в день. Один изготовитель компьютерной периферии уменьшил время цикла тестирования софта на 95% (с 48 месяцев до 2,5), увеличил эффективность на 220% и уменьшил количество дефектов на 33%. Экономия составила в два раза больше того, чего ожидала компания.

Заблуждение 3: у нас замечательные планы разработки, нужно лишь строго их придерживаться

Мы ещё никогда не встречали проект, требования к которому оставались постоянными за всё время разработки. Но многие организации продолжают свято верить в свои планы. Любые отклонения списываются на плохой менеджмент и исполнение, и для их уменьшения они отслеживают каждый шаг. Для процессов производства с частым повторением шагов это хороший подход – но для инноваций при разработке он не подходит. Новые озарения могут приходить ежедневно, а условия – постоянно меняться.

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

Определение пользовательских потребностей также может представлять проблему. И неудивительно – клиентам сложно точно составить требования к несуществующим пока решениям. Знакомство с существующими свойствами продукта может мешать человеку формулировать его требования к новым продуктам. Предпочтения пользователей могут резко меняться в процессе разработки, так как конкуренты представляют новые предложения, и на рынке появляются новые тренды.

Поэтому, если четко придерживаться первоначального плана, каким бы гениальным он ни был, можно прийти к полному провалу. Мы, конечно, верим в планирование – разработка продукта является набором сложных действий, требующих координации и внимания к деталям. Но планы надо рассматривать, как начальные гипотезы, которые постоянно пересматриваются.

Заблуждение 4: чем раньше начнём, тем раньше закончим

Менеджеры ненавидят простои и пытаются использовать их для старта новых проектов. Даже если новую работу нельзя начать, потому что люди должны сначала закончить другой проект, менеджеры убеждают всех, что всё, что можно сделать по новому проекту сегодня, станет работой, которую не нужно будет делать завтра. Это заставляет компании начинать больше проектов, чем они могут реально исполнить, и приводит к размыванию ресурсов.

Если это происходит, компания будет спотыкаться во время всего процесса разработки. А такие замедления вредны, ведь разработка продукта – товар скоропортящийся: технологии и рынок меняются и выходят в утиль очень быстро. Чем медленнее идёт процесс, тем больше вероятность, что его направление придётся менять. Одно из подразделений военной разработки обнаружило, что стоимость и задержки в разработке проекта экспоненциально росли при росте длительности его разработки – причём в 4-й степени. Если график проекта удваивался, то стоимость и отклонения от графика росли в 16 раз.

Важность уменьшения количества незавершённой работы очевидна, если взглянуть на формулу из классической теории очередей – закон Литла. В среднем время цикла пропорционально размеру очереди, делённому на скорость обработки. Если в Старбаксе перед вами стоит 20 человек, и бариста обслуживает пять человек в минуту, то вас обслужат через 4 минуты. Время цикла можно уменьшить, увеличивая скорость или уменьшая количество работ. Обычно на практике удаётся реализовать второй вариант.

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

Заблуждение 5: чем больше возможностей в продукте, тем он будет популярнее

Команды разработчиков часто верят, что добавление функций увеличивает ценность продукта, а удаление – уменьшает. Это объясняет, почему продукты выходят такими сложными. Пульты дистанционного управления невозможно использовать, компьютеры приходится настраивать часами, в автомобилях есть столько ручек и кнопок, что они напоминают кабину самолёта, и даже тостеры теперь делают с инструкциями и LCD-дисплеями.

Компании, не считающие, что больше – значит лучше, выпускают элегантные в своей простоте продукты. Датский производитель аудиотехники, телевизоров и телефонов Bang & Olufsen понимает, что клиентам не всегда нравится играться с эквалайзером, балансом и прочим, чтобы найти оптимальную комбинацию настроек для прослушивания музыки. Их колонки класса high-end автоматически подстраиваются под песни – всё, что остаётся клиенту, это выбрать громкость.

Убеждать компании в том, что «меньше» иногда может означать «больше», тяжело, поскольку приходится прилагать усилия в двух областях разработки.

Определение проблемы

Проговаривание проблемы, которую разработчики пытаются решить – самая недооцененная часть процесса инноваций. Слишком многие компании посвящают этому слишком мало времени. Но это важная фаза – именно так команды понимают свои истинные цели и высказывают гипотезы, которые можно проверить и уточнить. Качество постановки задачи кардинально влияет на способность команды фокусироваться на том, что действительно имеет значение.

При планировании Диснейленда Уолт Дисней не торопился добавлять новые функции, как другие парки. Он задался вопросом: как можно обеспечить посетителей парка волшебными впечатлениями от его посещения? IDEO и другие компании посвящают целые фазы разработки продукта погружению в контекст, в котором они видят продукт или услугу. Их разработчики читают всё о рынках, наблюдают и интервьюируют пользователей, изучают предложения конкурентов, и воплощают новые знания в картинки, модели и диаграммы.

Определение того, что можно спрятать или от чего можно отказаться

Часто командам хочется поразить своих коллег и начальников гениальными техническими решениями. Пользователям же просто нужен продукт, который работает без проблем. С их точки зрения лучшие решения – это простые решения, прячущие от них ту работу, которой разработчики так гордятся.

Одна из понимающих это компаний – Apple. Их наибольшее преимущество заключается в возможности добраться до сути проблемы. Как говорил Джобс: «Когда ты начинаешь рассматривать проблему, и она кажется очень простой – ты не понимаешь её сложности, и твои решения будут чересчур простыми. Углубляясь в проблему, ты видишь, что она сложна. И ты приходишь к разным запутанным решениям – на этом большинство людей и останавливаются». Но не Apple. «Действительно великий человек продолжит движение и найдёт ключевой принцип в основе проблемы, и придёт к красивому и элегантному решению».

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

Менеджеры же должны концентрироваться на том, не улучшит ли удаление одной из функций их продукт, и не позволит ли оно команде сосредоточиться на реально важных для клиентов вещах. Это можно проверять в быстрых экспериментах для каждой из функций.

Разработчики часто думают, что продукт закончен, когда больше нечего добавить. Их логику надо обратить – продукты приближаются к совершенству, когда из них нечего выбросить. Как сказал Леонардо да Винчи: «Простота – лучшее усложнение».

Заблуждение 6: мы будем более успешны, если у нас всё получится с первого раза

Многие проекты не справляются с обязательствами по бюджету, графику и техническим требованиям. Конечно, плохое планирование, негибкие процессы и слабое лидерство играют свои роли. Но менеджеры часто не понимают, что свою роль играют и их требования «сделать всё правильно с первого раза». Успех с первого раза направляет команды на территорию менее рискованных решений – даже если клиенты не считают их существенным улучшением по сравнению с тем, что было раньше. Команды не получают стимула для разработки инновационных решений проблем пользователей.

Чтобы избежать ошибок, команды предпочитают линейные процессы, где каждый шаг отслеживается в обзорных «воротах». Работа на следующем шаге не начнётся, пока проект не пройдёт «ворота». Когда проект двигается по линейному пути, в него вкладывается очень много сил, и стоимость изменений проекта из-за новых идей многократно возрастает. На поздних этапах поощряются успешные тесты, а сюрпризы, даже очень ценные, рассматриваются как негатив. К сожалению, линейный процесс приводит к задержкам проекта – поскольку обратная связь тормозит, команды держатся за плохие идеи дольше, чем нужно, и проблемы не начинают обсуждать до того момента, когда их решение становится слишком дорогим.

Лучшей стратегией будет терпимое отношение к провалам в первые разы – пусть лучше люди быстрее завершают итерации и быстрее учатся на своих ошибках.

Инструкция по избеганию распространённых ошибок:

1. Делайте очереди и потоки информации видимыми
2. Оценивайте стоимость задержек и учитывайте её
3. Не задействуйте ресурсы на 100%, опустите утилизацию там, где она очень высокая
4. Передвиньте внимание систем контроля с эффективности на время отклика
5. Уменьшите стоимость транзакций, чтобы можно было работать с меньшими партиями и более быстрым откликом
6. Экспериментируйте с партиями поменьше. Всегда можно вернуть, как было.
7. План разработки – это гипотеза, которая будет эволюционировать при поступлении новой информации
8. Начинайте проекты, только если все ресурсы для них полностью доступны
9. Настройтесь на простоту. Думайте, что можно удалить, а не только о том, что можно добавить.
10. Экспериментируйте раньше, быстрее и чаще. Используйте компьютерные модели и физические прототипы.
11. Накладывающаяся и итеративная разработка лучше линейной
12. Настраивайтесь на ускорение откликов, а не на успех с первого раза

Изучив 391 команду из тех, что изготавливали микросхемы на заказ, мы увидели, что те, кто пользовался итеративным подходом и делал тесты как можно раньше и чаще, ошибались чаще остальных. Но из-за использования недорогого прототипирования они выиграли (по затратам времени и сил) у тех, кто пытался всё сделать правильно с первого раза. Команды, у которых были слишком дорогие прототипы, тратили больше времени и сил на спецификации, разработку и проверки. А так как их итерации происходили ближе к концу процесса, а количество их было меньше – обнаружение серьёзных проблем у них происходило с большой задержкой.

Эксперименты с разными идеями – обязательная часть процесса инноваций. Когда экспериментируешь часто и быстро, конечно, придётся смириться с провалом многих идей. Но это позволяет командам быстрее отбрасывать плохие решения и концентрироваться на более перспективных.

Классический пример преимуществ подхода «ошибайся раньше и чаще» – неожиданная победа команды Новой Зеландии на «Кубке Америки» 1995 года по яхтенному спорту. Для улучшения дизайна киля команда использовала две одинаковых лодки, одна из которых менялась в процессе разработки, а вторая оставалась контрольной. Ежедневно команда симулировала новые гипотезы на компьютере, применяла лучшие из них, а затем устраивала состязание с контрольной лодкой и изучала результат.

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

Эксперименты, закончившиеся неудачей, не обязательно являются неудачными. Они выдают информацию, которую нельзя было предвидеть. Чем короче цикл эксперимента, тем больше он даёт отзывов, которые можно быстрее включать в новые этапы разработки.

Создание такой среды разработки – дело сложное. Ошибки смущают людей, показывают пробелы в знаниях, что в результате может подорвать их уверенность в себе. Задумайтесь, часто ли менеджеров повышают и команды награждают за раннее обнаружение проблем, приведших к смерти проекта – даже если раннее перераспределение ценных ресурсов компании было ей выгодно? Особенно сложно работать в этом направлении в организациях с «нулевой терпимостью к неудачам».

Томас Эдисон всё это понимал, и в его лабораториях всё было настроено под быстрые и частые эксперименты, в которых исследователи могли тесно сотрудничать с рабочими. В лабораториях были обширные библиотеки с легкодоступной информацией, склады с нужными запчастями, и разнообразная рабочая сила, от чернорабочих до инженеров и учёных. Эдисон хотел быть уверенным, что сразу после появления новой идеи её удастся быстро воплотить в модель или прототип. Он говорил, что «успех измеряется количеством экспериментов, которые можно впихнуть в 24 часа».

Развитие IT (компьютерный дизайн, моделирование, симуляция) уже позволило сделать шаги на пути к разработке лучших продуктов за меньшее время и деньги. Но многие компании не пользуются всем потенциалом этих инструментов, поскольку их управленческое мышление развивается медленнее технологий. Они всё ещё подходят к разработке информационного продукта как к фабричному производству. С развитием информационных технологий возможностей по улучшению процесса разработки продукта будет становиться ещё больше – поэтому больше будет и риска для тех компаний, которые не смогли разглядеть отличий между разработкой софта и фабричным производством.

Автор:

Источник