[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } } ]
{ "author_name": "Daria Khokhlova", "author_type": "self", "tags": ["\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430","\u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435_\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438","\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430_\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430"], "comments": 5, "likes": 19, "favorites": 29, "is_advertisement": false, "section_name": "default", "id": "12904" }
Daria Khokhlova
10 231

6 мифов о создании продуктов: Распределение ресурсов, длина итерации, скрытая функциональность

Издание Harvard Business Review опубликовало материал о шести основных мифах, сопровождающих разработку любого продукта, написанную Стефаном Томке (профессор Гарвардской школы бизнеса) и Дональдом Рейнертсеном (писатель, автор книги «Правила разработки продукта»). На статью обратил внимание российский инвестор Аркадий Морейнис.

Редакция vc.ru публикует адаптированный перевод заметки.

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

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

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

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

1. Миф: Активное использование большого количества ресурсов помогает повысить производительность команды

Большинство компаний, пишут авторы материала, стремятся по максимуму использовать все имеющиеся у них ресурсы при работе над проектом. По результатам некоторых исследований, большинство менеджеров стремится обеспечить загруженность своих сотрудников в среднем на 98%, пишут Томке и Рейнертсен. «Логика кажется им очевидной: чем меньше люди работают, тем медленнее ведется разработка. Чтобы достичь минимальных сроков, каждый сотрудник должен посвящать 100% своего времени работе над проектом».

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

  1. Менеджеры не в полной мере учитывают изменчивость разработки. «Многие аспекты разработки программного продукта непредсказуемы. Точно определить, какие именно задачи потребуется решать в ходе проекта и как с ними справятся работники, никогда не занимавшиеся ничем подобным, практически невозможно». Связано это с тем, что компании привыкли иметь дело с задачами, сроки исполнения которых растут линейно в зависимости от увеличения сложности или числа подзадач. С программными продуктами такой принцип не работает — увеличение сложности на 5% может привести к увеличению требуемого времени на 100%.
  2. Менеджеры не осознают, как высокая загруженность сотрудников влияет на другие проекты компании. Пока все работники сосредоточены над одним проектом, разработка других продуктов может простаивать. «Компаниям становится трудно приспособиться к меняющимся условиям на рынке и быстро реагировать на возникающие проблемы. Ирония заключается в том, что именно этого они и хотят избежать, нагружая всех сотрудников работой».
  3. Большинство элементов производства неосязаемы. При создании физического объекта, пишут Томке и Рейнертсен, все элементы видны и осязаемы. Если для того, чтобы собрать продукт, произвели в два раза больше деталей, чем планировалось, этот факт не пройдёт мимо руководства. В случае разработки программного продукта элементы не видны никому, кроме самого разработчика. «Провести инвентаризацию всех произведенных элементов и потраченных ресурсов невозможно. Если на исследование конкретного вопроса было потрачено в два раза больше ресурсов, никаких физических свидетельств тому не появляется», — говорят авторы материала.

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

— Аркадий Морейнис в записи на Facebook

Очевидное решение проблемы, пишут Томке и Рейнертсен, заключается в создании «буферной подушки» ресурсов. Многие компании, отмечают авторы материала, уже придерживаются подобной концепции — так, например, корпорация 3M загружает разработчиков лишь на 85%, а Google предоставляет работникам время на работу над собственными идеями.

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

  • Изменение системы контроля и вознаграждений (к примеру, награждать работников не за количество выполненной работы, а за скорость решения проблем).
  • Выборочное увеличение загруженности работников — только на тех участках, где это действительно требуется.
  • Ограничение количества активных проектов.
  • «Видимость» затрат. Стоит сделать так, чтобы все затраты были очевидны для участников процесса и для руководства.

2. Миф: Разработка функций большими «партиями» повышает экономичность разработки

«Допустим, вы ведёте работу над продуктом, для создания которого вам нужно разработать 200 различных элементов или функций. Перед вами стоит выбор: вы можете разрабатывать по 20 компонентов за итерацию и тестировать их в течение каждого цикла, а можете сразу создать все 200 компонентов — и только после этого приступить к тестированию», — объясняют авторы материала.

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

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

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

— Аркадий Морейнис в записи на Facebook

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

Авторы приводят в пример компанию-разработчика компьютерной периферии, добившуюся с помощью сокращения сроков одной итерации на 98% (с 45 месяцев до 2,5 месяцев) увеличения эффективности работы на 200% и снижения количества дефектов на 33%.

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

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

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

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

В этом-то как раз и суть новизны продукта — никто ещё не знает, хорош он или нет. Надо пробовать, тестировать, и не бояться менять планы даже посередине пути.

— Аркадий Морейнис в записи на Facebook

«План должен рассматриваться в качестве начальной гипотезы, которую следует постоянно пересматривать».

4. Миф: Чем раньше проект будет запущен, тем раньше он будет закончен

«Простой для руководителей неприемлем. Как только в компании появляются свободные ресурсы, менеджеры стремятся начать работу над новым проектом. Сотрудники занимаются поставленными задачами, и работать над возникшими проблемами может оказаться некому — всё это мы уже обсуждали выше».

Проблема, по словам Томке и Рейнертсена, заключается в том, что такой подход приводит к слишком раннему старту. Если запустить работу над продуктом, когда у компании нет достаточных средств, чтобы вести её безостановочно, говорят авторы, результат может оказаться неудовлетворительным. Связано это с тем, что технологии и гипотезы на ИТ-рынке быстро себя изживают, и любое промедление может оказаться для продукта губительным.

Как ни парадоксально, гораздо эффективнее перед началом работ потратить ещё времени и просто порубить топором количество задач, оставив только самые важные, которые можно сделать за меньшее время.

— Аркадий Морейнис в записи на Facebook

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

5. Миф: Чем больше функций мы закладываем в продукт, тем больше он понравится клиентам

Команды разработки, по словам авторов материала, убеждены, что дополнительные функции продукта создают дополнительную ценность, а удаление функций, напротив, снижает её. Именно поэтому, отмечают Томке и Рейнертсен, большинство программных продуктов настолько сложны: «Салоны современных автомобилей напоминают кабины самолётов, пультами невозможно пользоваться, а настройка домашнего компьютера занимает часы. Даже скромный тостер поставляется с ЖК-дисплеем и инструкцией по использованию».

Как отмечают специалисты, компании, которые бросают вызов этому распространённому убеждению, способны создавать элегантные и простые продукты. В качестве примера авторы приводят датскую компанию Bang & Olufsen, занимающуюся производством аудиотехники. «Команда осознала, что пользователь не хочет возиться с настройками эквалайзера, чтобы слушать музыку. Системы Bang & Olufsen автоматически подбирают оптимальные настройки, освобождая время владельца».

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

  1. Определение проблемы. Как можно больше времени стоит потратить на формулировку проблемы, которую решает продукт. «Это тот элемент процесса, который разработчики зачастую недооценивают. Здесь важно чётко осознать, какие цели стоят перед командой и какие гипотезы стоит проверить, чтобы двигаться дальше. Вряд ли Уолт Дисней при создании своего парка развлечений задумывался о том, чтобы построить больше парковок, кафе и аттракционов. Скорее всего, он размышлял о том, как создать уникальный опыт. Решение не пришло в одночасье, оно потребовало длительных исследований».
  2. Определение функциональности, которую можно скрыть. «Часто компании стремятся показать, как много усилий они потратили, демонстрируя пользователю всю функциональность продукта — хотя большое искусство заключается в том, чтобы скрыть всё, чем разработчики так гордятся, и позволить покупателю пользоваться технологией без лишних проблем. Apple поняла это одной из первых. Как говорил Стив Джобс, основной принцип разработчиков ИТ-гиганта — во что бы то ни стало найти простое и элегантное решение, даже если кажется, что его не существует».

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

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

— Аркадий Морейнис в записи на Facebook

6. Миф: Мы станем более успешными, если у нас получится хороший и нужный продукт с первого раза

Желание преуспеть с первой попытки, пишут Томке и Рейнертсен, зачастую побуждает работников и руководство принимать менее рискованные решения. «Вся работа над проектом тщательно контролируется. Снижается скорость реагирования на новые проблемы и гипотезы. Команда выстраивает процесс линейно, чтобы избежать ошибок».

Необходимость добиться успеха — пусть даже и небольшого — серьёзно снижает желание и возможность рисковать при запуске нового продукта. Если вы делаете действительно новый продукт, то лучше рискнуть и попробовать что-то действительно новое — это, вполне вероятно, окажется провалом. Но, если оно выстрелит, оно может выстрелить выше и сильнее, чем прилизанное и вычищенное УГ.

— Аркадий Морейнис в записи на Facebook

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

#разработка #управление_проектами #разработка_продукта

Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

Комментарии Комм.

0 новых

Популярные

По порядку

Прямой эфир

Приложение-плацебо скачали
больше миллиона раз
Подписаться на push-уведомления