Занимаясь чем-то профессионально, мы постоянно принимаем решения. Большие и маленькие, важные и не очень. От того насколько правильно мы их принимаем, зависит успех всех нашей деятельности.
Когда речь идет о разработке ПО или развитии стартапа – от решений ключевых сотрудников зависит как коммерческий успех проекта, так и благополучие, эффективность и боевой дух команды. Ошибки здесь выявляются далеко не сразу и обходятся очень дорого.
Прочитала недавно отличную книгу «Ловушки мышления» Чипа и Дэна Хизов. Она совсем не про IT. Скорее наоборот. Она про то, как надо мыслить каждый день. В ней нет ни слова про дизайн или программирование. Но именно в ней я нашла много советов, как улучшить процесс принятия решений в IT компании. Этими советами, приправленными собственными наблюдениями, я и собираюсь с вами поделиться.
Обычный вопрос при принятии решений в команде разработки продукта звучит так: добавлять или нет фичу, принимать или нет еще одного программиста, поддерживать вконтакте или только фейсбук, делать или не делать адаптивную верстку… Решаются такие вопросы либо единолично, либо голосованием. В качестве ответа получаем «Да» или «Нет». Обычно ни тот, ни другой ответ не устраивает команду на 100%. И чем руководствоваться в процессе решения не до конца понятно. Принятие решения часто сопровождается долгими мучениями, раздумьями и взвешиваниями. В итоге оно принимается, и дальше команда живет с ним живет.
Ради эксперимента попробуем взглянуть на те же самые вопросы под другим углом – более широко:
Оказывается, если немного сместить фокус внимания, и посмотреть на вопрос шире, то становится гораздо понятнее, как его решать. Вариантов решения становится больше и выбирать один из них можно гораздо разумнее.
Типичная проблема, возникающая при принятии решений называется «узкие рамки» и не дает увидеть весь спектр возможных вариантов. Коварство узких рамок в том, что в большинстве случаев мы не осознаем, что попали в них. Разберем примеры проявления узких рамок при разработке продукта.
Много раз ловила себя на том, что зацикливаюсь на каком-то одном варианте. Он мне не нравится, но как его исправить – не вижу. Сижу и перемещаю линию на пиксель влево – на пиксель вправо или чуть чуть меняю оттенок какого-нибудь цвета. Обычно – это сигнал того, что я зашла в тупик. Надо отдохнуть, отойти от монитора, спросить чьего-нибудь совета, посмотреть на какой-нибудь вдохновляющий пример (для меня это, как ни странно, apple.com :) или еще раз почитать задачу – а правильно ли я её понимаю.
Одна из проблем, кстати, бывает связана именно с постановкой задачи. Рамки часто создаются при её постановке. Вместо того, чтобы формулировать проблему, и искать способы её решения, люди начинают сразу обсуждать делали первого пришедшего в голову решения и тем самым ограничивают себе варианты.
Например, нужно сделать сайт туристического агентства. Клиент говорит «мне нравится сайт вон того конкурента. Хочу также. У них крутилка красивая на главной и кнопки оранжевые – просто супер». И все! Дизайнер может думать только о том, как сделать крутилку и оранжевые кнопки, но так, чтобы не было сильно похоже на сайт конкурента. Т.е. он думает не о том, как сделать удобнее для посетителей и не о том, что еще людям может быть полезно при выборе путевок. Он изо всех сил решает совершенно другую задачу.
После ученых, программисты – самые разумные и часто пользующиеся собственным мозгом люди. Но даже они порой попадают в рамки. Упираются в решение одной задачи, не видят очевидных решений, сажают ошибки. По моим наблюдениям это происходит, когда они либо устали, либо их все время кто-то дергает и не дает сосредоточиться, либо их поджимают сроки, либо все это одновременно. Бывает, конечно, и такое, что программист недостаточно грамотный, принимает решения исходя из своей узкой сиюминутной проблемы и не берет в рассмотрение общую задачу. Но мы о таких говорить не будем :)
Встречалась много раз с тем, что маркетологи действуют строго по учебнику (конечно не все, но многие). Блог, SEO, форма подписки, нагрев письмами. Плюс, соцсети, куда публикуются обновления блога вперемежку с постами из популярных пабликов. Плюс, конечно, контекстная реклама. И так для абсолютно любого проекта. Не важно, что это – бетонный завод, медицинский центр или высокотехнологичный стартап. В чем причина таких узких рамок, мне неизвестно. Казалось бы, работа – креативная, должна состоять из постоянных экспериментов. Возможно, вмешивается страх не отбить рекламный бюджет.
Как ни странно, находясь в рамках, человек очень редко это осознает. При этом он не способен найти очевидный ответ, потому, что просто не смотрит в его сторону. У кого не было случая, что при виде элегантного решения мы восклицаем:
«Боже, это же очевидно! Как я сам до этого не догадался?»
Не нужно быть гением, чтобы находить красивые и правильные решения. Это могут все. И для этого есть методы.
Шаг 1. Обнаружить проблему. Если вы видите, что выбор сводится всего к двум вариантам (делаем то или это), или, еще хуже – к одному варианту (быть или не быть), значит, вы попали в рамки. Осознали, что в рамках – отлично! Первый шаг к победе сделан.
Шаг 2. Осознанно искать другие решения. Хитрость именно в том, чтобы искать решения явно и осознанно, а не выбирать из первого, что пришло в голову. Некоторые приёмы:
Шаг 3. Выбрать нужное решение. Итак, нашли несколько хороших вариантов – нужно выбрать один. На этом этапе нас подстерегает еще один коварный враг – наши эмоции. Например, разум подсказывает, что проект пора закрывать, а сердце кричит, что он еще может окупиться, и жалко его бросать, ведь мы так много в него вложили. Здесь нужно приложить усилия и дистанцироваться от вопроса. Попробовать взглянуть на него со стороны. Спросить себя, а если бы в этой ситуации был мой друг, что бы я ему посоветовал? А если бы я спросил совета у Стива Джобса, что бы он мне сказал? Очень часто при такой постановке вопроса мгновенно возникает совершенно однозначный ответ.
Шаг 4. Проверить. Никто не в состоянии предвидеть то, как будут развиваться события и к чему приведет принятое вами решение. Даже если мы уверены в результате, у нас есть огромный опыт, мы эксперты, у нас интуиция и степень доктора наук в обсуждаемой области. Тезис, что решение будет работать – всего лишь предположение. Просто признайте это.
Хорошая новость в том, что в большинстве случаев предположение можно проверить в условиях, приближенных к реальности. Решили, что нужно внедрять новую функцию – сделайте кнопку-заглушку и проверьте, как часто будут на неё нажимать. Думаете, что прием еще одного программиста ускорит разработку на 20% – замерьте в течение нескольких дней, сколько времени программисты тратят на кодирование и сколько – на взаимодействие внутри команды. Учтите, что чем больше участников, тем больше взаимодействия между ними, причем зависимость далеко не линейная.
В каких-то случаях для проверки предположения достаточно расчета, в других – моделирования, в третьих – эксперимента или близкого к реальности прототипа. Но при любом раскладе, проверка в полевых условиях поможет трезво взглянуть на принятое решение. И что важно, относясь к проверке как к исследованию, мы будем морально готовы к возможной ошибке и следующей за ней смене курса.
Необходимость принимать решения – важная часть нашей работы, а способность делать это хорошо – важная часть успеха. Научиться принимать правильные решения совсем не трудно. Это может сделать любой человек, и для этого не нужен даже аттестат о среднем образовании. Хитрость в том, чтобы чаще включать мозг и анализировать собственное поведение. А распознав проблему узких рамок, превратить принятие решения в осознанный рациональный процесс.
Правильных вам решений!
Когда речь идет о разработке ПО или развитии стартапа – от решений ключевых сотрудников зависит как коммерческий успех проекта, так и благополучие, эффективность и боевой дух команды. Ошибки здесь выявляются далеко не сразу и обходятся очень дорого.
Прочитала недавно отличную книгу «Ловушки мышления» Чипа и Дэна Хизов. Она совсем не про IT. Скорее наоборот. Она про то, как надо мыслить каждый день. В ней нет ни слова про дизайн или программирование. Но именно в ней я нашла много советов, как улучшить процесс принятия решений в IT компании. Этими советами, приправленными собственными наблюдениями, я и собираюсь с вами поделиться.
Невидимая проблема
Обычный вопрос при принятии решений в команде разработки продукта звучит так: добавлять или нет фичу, принимать или нет еще одного программиста, поддерживать вконтакте или только фейсбук, делать или не делать адаптивную верстку… Решаются такие вопросы либо единолично, либо голосованием. В качестве ответа получаем «Да» или «Нет». Обычно ни тот, ни другой ответ не устраивает команду на 100%. И чем руководствоваться в процессе решения не до конца понятно. Принятие решения часто сопровождается долгими мучениями, раздумьями и взвешиваниями. В итоге оно принимается, и дальше команда живет с ним живет.
Ради эксперимента попробуем взглянуть на те же самые вопросы под другим углом – более широко:
Добавлять или нет фичу? | Какие задачи сейчас самые приоритетные? Решение каких задач принесет больше денег/клиентов/фидбека… за короткое время/в перспективе? |
Принимать или нет еще одного программиста? | Как можно наилучшим образом использовать свободный бюджет N тыс. руб.? Можем ли мы выделить еще M тыс. руб., чтобы решить какие-то еще приоритетные задачи? |
Поддерживать вконтакте или только фейсбук? | Кто наша целевая аудитория, где она ведет себя наиболее активно: соцсети, форумы, вебинары? Какими средствами можно её привлекать/удерживать/выстраивать с ней диалог… наиболее дешево? Какие маркетинговые инструменты дадут нам эффект прямо сейчас, а какие смогут работать на будущее? |
Делать или не делать адаптивную верстку? | Какой % пользователей с мобильных устройств заходит на сайт? Теряем ли мы их? Какой % пользователей мы готовы потерять, а какой – уже нет? |
Оказывается, если немного сместить фокус внимания, и посмотреть на вопрос шире, то становится гораздо понятнее, как его решать. Вариантов решения становится больше и выбирать один из них можно гораздо разумнее.
Типичная проблема, возникающая при принятии решений называется «узкие рамки» и не дает увидеть весь спектр возможных вариантов. Коварство узких рамок в том, что в большинстве случаев мы не осознаем, что попали в них. Разберем примеры проявления узких рамок при разработке продукта.
Рамки в дизайне
Много раз ловила себя на том, что зацикливаюсь на каком-то одном варианте. Он мне не нравится, но как его исправить – не вижу. Сижу и перемещаю линию на пиксель влево – на пиксель вправо или чуть чуть меняю оттенок какого-нибудь цвета. Обычно – это сигнал того, что я зашла в тупик. Надо отдохнуть, отойти от монитора, спросить чьего-нибудь совета, посмотреть на какой-нибудь вдохновляющий пример (для меня это, как ни странно, apple.com :) или еще раз почитать задачу – а правильно ли я её понимаю.
Одна из проблем, кстати, бывает связана именно с постановкой задачи. Рамки часто создаются при её постановке. Вместо того, чтобы формулировать проблему, и искать способы её решения, люди начинают сразу обсуждать делали первого пришедшего в голову решения и тем самым ограничивают себе варианты.
Например, нужно сделать сайт туристического агентства. Клиент говорит «мне нравится сайт вон того конкурента. Хочу также. У них крутилка красивая на главной и кнопки оранжевые – просто супер». И все! Дизайнер может думать только о том, как сделать крутилку и оранжевые кнопки, но так, чтобы не было сильно похоже на сайт конкурента. Т.е. он думает не о том, как сделать удобнее для посетителей и не о том, что еще людям может быть полезно при выборе путевок. Он изо всех сил решает совершенно другую задачу.
Рамки в программировании
После ученых, программисты – самые разумные и часто пользующиеся собственным мозгом люди. Но даже они порой попадают в рамки. Упираются в решение одной задачи, не видят очевидных решений, сажают ошибки. По моим наблюдениям это происходит, когда они либо устали, либо их все время кто-то дергает и не дает сосредоточиться, либо их поджимают сроки, либо все это одновременно. Бывает, конечно, и такое, что программист недостаточно грамотный, принимает решения исходя из своей узкой сиюминутной проблемы и не берет в рассмотрение общую задачу. Но мы о таких говорить не будем :)
Рамки в маркетинге
Встречалась много раз с тем, что маркетологи действуют строго по учебнику (конечно не все, но многие). Блог, SEO, форма подписки, нагрев письмами. Плюс, соцсети, куда публикуются обновления блога вперемежку с постами из популярных пабликов. Плюс, конечно, контекстная реклама. И так для абсолютно любого проекта. Не важно, что это – бетонный завод, медицинский центр или высокотехнологичный стартап. В чем причина таких узких рамок, мне неизвестно. Казалось бы, работа – креативная, должна состоять из постоянных экспериментов. Возможно, вмешивается страх не отбить рекламный бюджет.
Как увидеть рамки?
Как ни странно, находясь в рамках, человек очень редко это осознает. При этом он не способен найти очевидный ответ, потому, что просто не смотрит в его сторону. У кого не было случая, что при виде элегантного решения мы восклицаем:
«Боже, это же очевидно! Как я сам до этого не догадался?»
Не нужно быть гением, чтобы находить красивые и правильные решения. Это могут все. И для этого есть методы.
Шаг 1. Обнаружить проблему. Если вы видите, что выбор сводится всего к двум вариантам (делаем то или это), или, еще хуже – к одному варианту (быть или не быть), значит, вы попали в рамки. Осознали, что в рамках – отлично! Первый шаг к победе сделан.
Шаг 2. Осознанно искать другие решения. Хитрость именно в том, чтобы искать решения явно и осознанно, а не выбирать из первого, что пришло в голову. Некоторые приёмы:
- Исчезновение вариантов. Представим, что мы не можем принять ни один из имеющихся вариантов. Вот не можем, и всё тут. Вспоминаем народную мудрость «Голь на выдумки хитра», заставляем свой мозг включиться и изобретаем что-то новое.
- Не ИЛИ, а И. Вместо того, чтобы выбирать между двумя имеющимися вариантами, попробуем объединить их. В каждом есть достоинства и недостатки. Оставив достоинства обоих вариантов, попробуем изменить ситуацию так, чтобы нивелировать недостатки.
- Как у других. Наверняка, с подобной проблемой уже сталкивались другие люди. Например, ваши конкуренты. Так давайте используем это себе на благо. Должна же от конкурентов быть какая-то польза :)
Одно из эмпирических правил заключается в том, чтобы продолжать искать варианты, пока вы не влюбитесь по крайней мере дважды. (Чип Хиз и Дэн Хиз)
Шаг 3. Выбрать нужное решение. Итак, нашли несколько хороших вариантов – нужно выбрать один. На этом этапе нас подстерегает еще один коварный враг – наши эмоции. Например, разум подсказывает, что проект пора закрывать, а сердце кричит, что он еще может окупиться, и жалко его бросать, ведь мы так много в него вложили. Здесь нужно приложить усилия и дистанцироваться от вопроса. Попробовать взглянуть на него со стороны. Спросить себя, а если бы в этой ситуации был мой друг, что бы я ему посоветовал? А если бы я спросил совета у Стива Джобса, что бы он мне сказал? Очень часто при такой постановке вопроса мгновенно возникает совершенно однозначный ответ.
Шаг 4. Проверить. Никто не в состоянии предвидеть то, как будут развиваться события и к чему приведет принятое вами решение. Даже если мы уверены в результате, у нас есть огромный опыт, мы эксперты, у нас интуиция и степень доктора наук в обсуждаемой области. Тезис, что решение будет работать – всего лишь предположение. Просто признайте это.
Склонность считать себя великим специалистом («просто я интуитивно это знаю») сидит внутри каждого из нас (Чип Хиз и Дэн Хиз)
Хорошая новость в том, что в большинстве случаев предположение можно проверить в условиях, приближенных к реальности. Решили, что нужно внедрять новую функцию – сделайте кнопку-заглушку и проверьте, как часто будут на неё нажимать. Думаете, что прием еще одного программиста ускорит разработку на 20% – замерьте в течение нескольких дней, сколько времени программисты тратят на кодирование и сколько – на взаимодействие внутри команды. Учтите, что чем больше участников, тем больше взаимодействия между ними, причем зависимость далеко не линейная.
В каких-то случаях для проверки предположения достаточно расчета, в других – моделирования, в третьих – эксперимента или близкого к реальности прототипа. Но при любом раскладе, проверка в полевых условиях поможет трезво взглянуть на принятое решение. И что важно, относясь к проверке как к исследованию, мы будем морально готовы к возможной ошибке и следующей за ней смене курса.
Что имеем
Необходимость принимать решения – важная часть нашей работы, а способность делать это хорошо – важная часть успеха. Научиться принимать правильные решения совсем не трудно. Это может сделать любой человек, и для этого не нужен даже аттестат о среднем образовании. Хитрость в том, чтобы чаще включать мозг и анализировать собственное поведение. А распознав проблему узких рамок, превратить принятие решения в осознанный рациональный процесс.
Правильных вам решений!