Быстрее, лучше, дешевле. Искусство продуктовой разработки

Перевод статьи Джеймса Синклера

Никому не нужен несвоевременный, вышедший за рамки бюджета продукт. Я не знаю ни одного разработчика, который бы вставал по утрам с похожими мыслями: “Вот бы заняться чем-нибудь бесполезным сегодня. Как мне заставить заказчика заплатить побольше?” Тем не менее дела идут гладко далеко не на всех проектах. И есть ощущение, что с каждым новым — давление работать еще и еще быстрее возрастает. Итак, если наш бизнес —продуктовая разработка, что нужно делать? Как увеличить скорость работы, не снижая её качество?

Несмотря на пятидесятилетний опыт, бесчисленные методологии, советы и книги, IT-проекты продолжают проваливаться.
— Susan Moore, 2015, “IT Projects Need Less Complexity, Not More Governance”, Smarter With Gartner, 17 July 2015

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

Правильное начало — вопрос почему. Каков смысл продуктовой разработки в принципе? Для чего мы создаем конкретно наш продукт? Забудем на время об опенсорсе, этом слоне в комнате, и поговорим о коммерческих проектах. Давайте поговорим о бизнесе.

Бизнес —это о том, чтобы утолить боль клиента

Как я себе это представляю: чтобы создать успешный бизнес, сначала нужно найти что-то, что вызывает у людей боль (боль в буквальном и переносном смыслах, но, как правило, переносном). Затем мы предлагаем сделку — лекарство от боли в обмен на деньги. К примеру, научиться программировать трудно (т.е. больно). Поэтому существуют книжные магазины и курсы программирования. Часть людей недовольна своей внешностью — к их услугам целые индустрии: фитнес, косметика, косметология и т.д. Ценность бизнеса определяется степенью, на которую он утоляет боль своего клиента (либо степенью веры в это). Люди, убежденные в способности нечто победить их боль, счастливы отдать за это нечто деньги.

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

Я не говорю, что разработка — единственное, что создает эту ценность. Скажем, если продукт не известен публике, важно ли, что он вообще существует? То есть продажи и маркетинг принципиально важны. Мы также должны быть уверены, что продукт действительно уменьшает боль наших клиентов, иначе все, что мы делаем — пустая трата времени. Значит, и исследования рынка жизненно необходимы. Далее, обратим внимание на UX и дизайн: именно они делают продукт удобным для пользователей.

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

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

Дела пойдут лучше, если вы примите идею, что “продукт”, “дизайн” и “разработка” — лишь разные стороны одного предмета.
— Greg Veen, 2017, https://twitter.com/gregveen/status/835259928352714752, Twitter, 25 February 2017

Сокращаем временные затраты в пользу бизнеса

Если наша цель “понять человека”, то всему вышеперечисленному следует уделять внимание на постоянной основе. Чем дальше, тем больше мы учимся искусству решения задач. Мы начинаем узнавать лучшие подходы, а значит, наш продукт также меняется.

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

Цель разработки — методично сокращать затрачиваемое на работу время в пользу бизнеса.
— Dan North, Beyond Features and Software that fits in your head

Итак, гибкость команды важна. Но как заполучить такую команду. Скажите, вы:

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

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

Итак, если решение не в том, чтобы выполнять все пожелания разработчиков, то в чем тогда? Короткий ответ звучит так: спросите самих разработчиков. Но спросите правильно и в правильное время. Есть одна вещь, которую нужно понимать: разработчики — это люди, склонные решать проблемы. Хорошие разработчики любят свою работу. Они любят её за возможность работать с интересными головоломками и получать за это деньги. Хорошие разработчики без ума от сложных задач и элегантных решений. Им важно реализовывать свои идеи и профессионально расти. Проблема в том, что многие компании пытаются направить их усилия не в то русло. Преднамеренно или нет, но это происходит.

Фокусировка на неправильных задачах

Почему это происходит? Почему мы направляем внимание команды на неправильные проблемы и даже не осознаем этого? Причина — пропасть между разработчиками и клиентами. Как только проект становится достаточно крупным, подключаются менеджеры и аналитики. И тому есть веская причина: разработчики не могут делать всю работу сами. Разработка — сложный вид деятельности. Писать код — само по себе не просто, а еще нужно принимать решения о типе продукта, думать о планировании, фазах разработки и итерациях, взаимодействии с клиентами… Список можно продолжить. Разработчикам достаточно работы с кодом. Чтобы справиться с остальным, нужны дополнительные ресурсы.

И тогда эти “дополнительные” сотрудники становятся для разработчиков окном в мир. Менеджер и аналитик берут на себя общение со всеми заинтересованными сторонами. Менеджер отвечает за результат. Отчитывается перед руководством. А что для менеджера важнее всего:

  • Сколько это будет стоить?
  • Сколько времени это займет?
  • Почему так дорого?
  • Почему так долго?
  • Почему до сих пор не готово?
  • Бог мой, чего это мы переплачиваем так много на этом затянувшемся проекте?!

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

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

Работа занимает больше времени, чем вы ожидаете. Даже если учесть закон Хофштадтера.
— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid, цитата из Wikipedia, Hofstadter’s law

Рассмотрим сценарий: менеджер проекта просит неопытного программиста сделать оценку. Оценка готова, она выглядит разумно. И вот менеджер делает из неё план и назначает дедлайн. При этом хороший менеджер добавит немного времени “сверху”. Затем случается неизбежное — разработчик не укладывается в сроки. Он работает дольше и устает сильнее. Он чаще ошибается. Это не все… Ведь разработчик по-прежнему не успевает, а менеджер начинает интересоваться, почему так долго. Тогда, выбирая простейший пусть к решению задач, разработчик делает еще больше ошибок. Теперь наш проект не просто не укладывается в сроки, но и забагован.

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

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

— Твоя оценка немного больше той, на которую мы рассчитывали. Можем что-нибудь сделать, чтобы уменьшить её?

На этом месте опытный разработчик спросит:

— Уменьшить на сколько?

Менеджер называет сроки.

— Это будет не просто, но посмотрим что можно сделать, — скажет разработчик, потирая подбородок. — Придется исключить кое-какие требования и оставить только базовый функционал.

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

Оценки — необходимое зло. К сожалению, люди думают, что разработка походит на строительство домов или ремонт машин, а значит подрядчик/механик должен уметь предоставить четкую оценку планируемых работ. Так, чтобы заказчик мог принять или отклонить их. […] В продуктовой разработке, однако, все по-другому. Дополнить существующую систему, совместить её разные элементы, понять, как в конце концов они будут взаимодействовать друг с другом — это изменяющиеся, гибкие задачи. Невероятно трудно оценить время, если в начале пути не известна ни дорога, по которой пойдешь, ни окончательное направление.
— Steve Smith, The 5 Laws of Software Estimates

Я не жалуюсь. Всем понятно, что оценки — необходимое зло. Проблема в том, что оно превращается в порочный круг. Пытаясь уложиться в сроки, мы выбираем простые пути, снижаем качество и уверяем себя, что вернемся к ним позже. Но “позже” не наступит. При переходе на новый этап, мы уже проиграли время, так как вынуждены править ранее созданные баги. И теперь имеем дело с хрупким кодом, не годящимся для быстрых изменений. Как только круг замкнулся, разработчику уже нет дела до боли заказчика, его беспокоят другие вопросы:

  • Как побыстрее отметить задачу “выполненной” и прогнать стоящего за спиной менеджера?
  • Как свести к минимуму работу с этим негодным кодом? Потому что, чем больше его трогаешь, тем выше вероятность сломать программу.
  • Как вогнать кусочек кода, которым я мог бы гордиться, в эту кипящую бездну технического долга?
  • Как обосновать свои решения людям, которые понятия не имеют о том, что я делаю, и как все это сложно?!
  • На кого я переведу стрелки, когда заказчик будет жаловаться на баги, поправить которые просто не было времени?
  • Что написать в резюме, ведь оно мне потребуется для поиска проекта, где все будет не в таком беспорядке?

Я не встречал разработчика, который бы хотел делать запоздалый, некачественный продукт. Но мы давим на них, требуем меньшей оценки, так как хотим видеть быстрый результат (как будто меньшая оценка сама по себе может сделать разработку быстрее). Программисты идут на поводу, желая угодить, но потом застревают, так как оценка оказалась неверной. Теперь они под давлением принятых обязательств: работают дольше, предпочитают простые решения, согласны на компромисс в отношении качества, так как им постоянно задают один и тот же вопрос: “Еще не готово?” Но довольных таким положением вещей нет. Результат —по-прежнему запоздалый и забагованный продукт.

Большинство знакомых мне программистов делают все, что в их силах. Но и они увязают. Они так заняты наверстыванием упущенного, что даже не помышляют о слове “быстрее”. Они сфокусированы на неправильных вопросах, на выживании. Трудно думать о будущей пенсии, когда умираешь от голода. Подобным образом, трудно сконцентрироваться на поиске лучших решений, если работаешь семь дней в неделю над проектом, релиз которого должен был быть вчера. В такой ситуации первый шаг, который стоит предпринять — осознать, что ускорение требует инвестиций. И если дела идут плохо, потребуются как денежные/временные вложения, так и эмоциональные.

Разрываем порочный круг

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

  1. Сжечь все огнем. “Нужно вернуться на пару лет назад и переписать все заново”. Это случается, когда уровень “технического долга” слишком велик. В этом есть свой смысл. Но на это может не быть бюджета, а рынок не будет ждать, пока мы перепишем продукт с нуля.
  2. Возмущение. “Мы и так спешим. Как вы можете всерьез думать, что такая задача решается получасовым мозговым штурмом! Вы издеваетесь?!” Так бывает, когда разработчики вынуждены писать плохой код. Они ощущают вину за баги и жалобы пользователей. Их гнев понятен. Разработчики с таким настроем нуждаются в том, чтобы быть услышанными. Им важно видеть, что все понимают, в какой ситуации они казались. Поэтому мы должны демонстрировать, что серьезно относимся к любым изменениям в проекте.

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

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

Знакомим разработчика с болью клиента

Итак, как научить разработчика понимать боль клиента? Об этом написано много, я лишь резюмирую. Ниже представлены основные идеи, от наименее к наиболее эффективным:

  1. Заставьте разработчиков регулярно пользоваться продуктом, который они делают. То, что имеют в виду, говоря “пить собственное шампанское” или “есть собственный корм”. Цель — поставить разработчиков на место пользователей. В этом случае баги станут болью их авторов. Проблема такого подхода в том, что программисты — не обычные пользователи (большую часть времени) и воспринимают продукт по-другому. Поэтому способ поможет избавиться от явных багов, но не обещает откровений. Кроме того, зачастую его трудно реализовать. Скажем, мы пишем программу для стоматологов. Как сделать, чтобы разработчики пользовались ею каждый день?
  2. Заставьте разработчиков участвовать в поддержке продукта, поощряйте их в этом (может потребоваться достаточно убедительное поощрение). Это точно поможет им испытать на себе боль клиентов. Например, если они будут отвечать на звонки, письма, твиты (и неважно что еще), то будут получать информацию из первых рук — от самих пользователей. Занимаясь этим достаточно долго, они узнают типичные ошибки и слабые места. Из раза в раз повторяющаяся жалоба — прекрасный мотиватор для улучшения продукта. К сожалению, люди редко обращаются в поддержку, когда все работает как надо, а значит этот источник знаний несколько предвзят.
  3. Заставьте разработчиков наблюдать, как юзеры работают с программой. Это самый трудный вариант, он предполагает высочайший уровень организованности, но и дает лучшие результаты. Разработчики видят, как ведет себя их продукт в руках настоящих клиентов при решении настоящих задач в настоящих жизненных ситуациях. Они узнают хорошего, плохого и злого.

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

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

Мой опыт подсказывает, что чем более изолированно работают разработчики, тем хуже продукт, который они делают. Здесь не помогает наличие в команде бизнес-аналитика, который видит своей задачей защитить программистов от пользователей, а пользователей от программистов. Модель работы, при которой разработчики не имеют представления о пользователях — опасный путь.
— Jeff Atwood, 2005, ‘Ivory Tower Development’, Coding horror, 7 February 2005.

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

Спросите разработчиков

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

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

Детали процесса зависит от вас. Одни предпочитают мозговые штурмы, другие — разговоры тет-а-тет. У каждого подхода свои достоинства и недостатки. Но запомните, независимо от выбранного метода, всегда четко указывайте на существующие ограничения. У вас небольшой бюджет?— скажите об этом. Для проекта важны дедлайны, их нельзя пропустить ни в коем случае?— дайте разработчикам знать. Мы ведь предполагаем, что ваша команда состоит из умных, знающих свое дело людей? — тогда дайте им возможность предусмотреть все факторы. Если же они не понимают даже после многократных объяснений: что же, и вы научились чему-то…

Обсуждая ограничения, будьте осторожны. Если скажете, что денег нет, зато есть жесткие дедлайны без возможности для маневра —вам ответят, что ничем не могут помочь. Будьте крайне аккуратны в этом. Написанный в короткие сроки качественный продукт стоит денег. Разработчикам важно, что вы готовы вкладываться в них и их инструменты. Нет бюджета, нет времени, нет надежды, что положение дел изменится — умный программист начнет искать другое место. И в такой ситуации я поддержу его. Самое удачное время для эмоций и эмпатии. Покажите, что вам это все не безразлично, что вы готовы вкладывать ресурсы в будущем. Объясните, что в настоящий момент сложилась ситуация, когда возможности крайне ограниченны. Тогда, быть может, разработчик предложит свой вариант выхода из этого плачевного положения.

Ремни безопасности и усиление двигателя

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

  • Разработка через тестирование (test-driven development, TDD)
  • Непрерывная интеграция (Continuous Integration)
  • Парное/групповое программирование
  • Код ревью

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

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

Очевидно, TDD бережет время и деньги. А если принять во внимание поддержку продукта — много времени и много денег.
— Eric Elliott, 2014, ‘The Outrageous Cost of Skipping TDD & Code Reviews’, JavaScript Scene,14 December 2016

Разработка через тестирование, непрерывная интеграция и другие техники улучшают качество. Это означает меньше ошибок в продакшене. Найденная до релиза ошибка — меньше работы по исправлению, меньше конфузных ситуаций и довольный клиент. Это продуктивнее и дешевле. Нет необходимости из раза в раз тратить время на одинаковые баги. Более того, это гибкий, готовый к изменениям код. Код, который проще переиспользовать и дополнять. Меньше временных затрат на ломающийся на ходу функционал, больше — на внедрение нового. Как результат — “быстрый” и качественный продукт.

Каналы обратной связи

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

Сокращение времени фидбека от пользователей — вот то, что принесло нам действительно системные перемены.
— Phil Wills, 2015, ‘Delivering Continuous Delivery, continuously’, The Guardian, 5 January 2015.

Если вы в курсе IT трендов последних лет, то, должно быть, слышали о круге добродетели (virtuous cycle). Термин близок понятию continuous delivery, но смысл не в словах. Continuous delivery объединяет ряд практик, обеспечивающих стабильный канал обратной связи. С его помощью уменьшаются риски при наращивании/интенсификации разработки.

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

Британское правительство было обеспокоено численностью кобр в Дели. Оно предложило вознаграждение за каждую убитую змею. Сначала стратегия работала успешно. Однако со временем предприимчивые индийцы стали разводить кобр ради премий. Узнав об этом, правительство свернуло программу. Заводчики, разводившие кобр, потеряли в них интерес и отпустили на волю. Таким образом, популяция этого вида змей в Индии выросла еще больше изначальной.
Wikipedia, The Free Encyclopedia, Cobra effect

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

Понять “комплексность” — значит понять, что действие в пространстве меняет само это пространство. Что касается причин и последствий изменения —то их понимание возможно только ретроспективно.
— Liz Keogh, 2015, Cynefin for Developers, 7 January 2015

Если все это правда, как можно преуспеть в столь сложной среде? Ответ в том, что знатоки подразумевают, говоря: “Пробуй, чувствуй, реагируй”. Другими словами, создайте устойчивый канал обратной связи — и вы будете знать, что работает, а что нет. Добившись этого, можно начинать двигаться вперед так быстро, как только возможно. Держитесь правила делать небольшие изменения короткими циклами. Тогда риск ошибок будет небольшим, их будет легче исправить. Экспериментируйте, закрепляйте успешные попытки, отказывайтесь от неудачных.

Когда речь заходит о комплексности, нужно уметь изучать, чувствовать, реагировать. Тогда, работа становится аккуратна, безопасна, она сама рассказывает вам о предмете, с которым вы имеете дело. Это сфера интенсивного обмена информацией, риска, инноваций.
— Liz Keogh, 2012, Cynefin for Devs, 11 March 2012.

Заключение

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

За помощь в переводе спасибо Михаилу Шамшурину