«Быть или не быть» или как избежать рамок
при принятии проектных решений

Занимаясь чем-то профессионально, мы постоянно принимаем решения. Большие и маленькие, важные и не очень. От того насколько правильно мы их принимаем, зависит успех всех нашей деятельности.

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

Обычный вопрос при принятии решений в команде разработки продукта звучит так: добавлять или нет фичу, принимать или нет еще одного программиста, поддерживать вконтакте или только фейсбук, делать или не делать адаптивную верстку… Решаются такие вопросы либо единолично, либо голосованием. В качестве ответа получаем «Да» или «Нет». Обычно ни тот, ни другой ответ не устраивает команду на 100%. И чем руководствоваться в процессе решения не до конца понятно. Принятие решения часто сопровождается долгими мучениями, раздумьями и взвешиваниями. В итоге оно принимается, и дальше команда живет с ним живет.

Ради эксперимента попробуем взглянуть на те же самые вопросы под другим углом – более широко:

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

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

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

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

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

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

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

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

«Боже, это же очевидно! Как я сам до этого не догадался?»

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

Шаг 1. Обнаружить проблему. Если вы видите, что выбор сводится всего к двум вариантам (делаем то или это), или, еще хуже – к одному варианту (быть или не быть), значит, вы попали в рамки. Осознали, что в рамках – отлично! Первый шаг к победе сделан.

Шаг 2. Осознанно искать другие решения. Хитрость именно в том, чтобы искать решения явно и осознанно, а не выбирать из первого, что пришло в голову. Некоторые приёмы:

1. Исчезновение вариантов. Представим, что мы не можем принять ни один из имеющихся вариантов. Вот не можем, и всё тут. Вспоминаем народную мудрость «Голь на выдумки хитра», заставляем свой мозг включиться и изобретаем что-то новое.
2. Не ИЛИ, а И. Вместо того, чтобы выбирать между двумя имеющимися вариантами, попробуем объединить их. В каждом есть достоинства и недостатки. Оставив достоинства обоих вариантов, попробуем изменить ситуацию так, чтобы нивелировать недостатки.
3. Как у других. Наверняка, с подобной проблемой уже сталкивались другие люди. Например, ваши конкуренты. Так давайте используем это себе на благо. Должна же от конкурентов быть какая-то польза :)

Шаг 3. Выбрать нужное решение. Итак, нашли несколько хороших вариантов – нужно выбрать один. На этом этапе нас подстерегает еще один коварный враг – наши эмоции. Например, разум подсказывает, что проект пора закрывать, а сердце кричит, что он еще может окупиться, и жалко его бросать, ведь мы так много в него вложили. Здесь нужно приложить усилия и дистанцироваться от вопроса. Попробовать взглянуть на него со стороны. Спросить себя, а если бы в этой ситуации был мой друг, что бы я ему посоветовал? А если бы я спросил совета у Стива Джобса, что бы он мне сказал? Очень часто при такой постановке вопроса мгновенно возникает совершенно однозначный ответ.

Шаг 4. Проверить. Никто не в состоянии предвидеть то, как будут развиваться события и к чему приведет принятое вами решение. Даже если мы уверены в результате, у нас есть огромный опыт, мы эксперты, у нас интуиция и степень доктора наук в обсуждаемой области. Тезис, что решение будет работать – всего лишь предположение. Просто признайте это.

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

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

Правильных вам решений!

Впервые статья была опубликована на Хабрахабре

Нажимая на кнопку, вы даете согласие на обработку своих персональных данных и соглашаетесь с политикой конфиденциальности