Что такое ментальная модель?
Ментальные модели – это набор инструментов (своего рода паттернов), которые могут помочь нам осмыслить идеи или понять что происходит вокруг нас. Они позволяют нам выявить когнитивные отклонения, понять, почему мы думаем так как мы думаем, и как мы рационализируем идеи.
Как ментальные модели позволяют разработчикам думать лучше?
Ментальная модель нашего мозга определяет качество наших мыслей. Понимание того, какая ментальная модель лучше подходит к определенной ситуации может помочь вам работать лучше и мыслить эффективнее.
Если вы разработчик, ментальные модели могут повысить вашу эффективность и производительность. Они могут помочь вам понять проблему, исправить ошибки в коде и предотвратить появление новых.
Представьте себе ситуацию. Вы достаточно активно и быстро пишете код и вдруг что-то идет не так. Вы начинаете проверять исходный код, пробуете варианты решения проблемы, используете отладчик. Если вы все сделали правильно, то вы сможете найти причину проблемы. Однако, это может отнять много времени и сил.
А теперь представим еще один вариант: вы столкнулись с проблемой в коде. Вместо того, чтобы использовать случайные стратегии, вы можете проанализировать ментальную модель системы. Подумайте об условиях, которые привели к возникновению ошибки и найдите области, где код не соответствует ментальной модели. С таким подходом разработчик может найти решения проблемы даже без помощи Google.
Итак, какие ментальные модели помогут вам выйти из тупика? Ниже мы разберем несколько известных ментальных моделей, которые могут помочь вам выполнить свою работу.
Ментальная модель №1: Метод утенка (Rubber ducking)
Rubber ducking – сокращение от rubber duck debugging. Концепция возникла из рассказа в котором программист построчно описал работу программного кода резиновому утенку. Хотя сначала все кажется довольно странным, разумное объяснение этому есть. Объяснение своего кода другому человеку или неживому объекту позволяет вам решить проблему и найти то место, в котором вы застряли. Вам приходится мыслить нестандартно. В конце концов, вы придете к той точке в коде, в которой вы ошиблись.
И уточним – вам не обязательно разговаривать с настоящей резиновой уткой или плюшевой игрушкой. Вместо утенка может выступать ваш коллега или друг. Когда вы пытаетесь подробно объяснить ваш код, потенциально возможные решения проблемы могут прийти сами собой.
Модель 2: Круг компетенций (Circle of Competence)
Круг компетенций заключается в том, чтобы отличить то «что вы знаете» от того «что вы не знаете».
Проще говоря, эта модель помогает вам быть в курсе областей своих компетенций. В то же время, вы понимаете ваши слабые стороны или предметные области, в которых вы не очень сильны. Неважно сколько времени вы работаете разработчиком, вы не можете знать все.
В качестве примера у нас будет будет разработчик игр, который перешел работать в финансовый сектор. Как разработчик игр вы должны: неплохо владеть такими языками как C# и C++, разрабатывать пользовательский интерфейс, программировать окружение или искусственный интеллект для внутриигровых персонажей. Некоторые из этих навыков пригодятся в новой сфере, но позже вы узнаете, что еще необходимо понимать законодательство или управлять службами безопасности.
С помощью круга компетенций разработчики могут предсказать проблемы, с которыми они столкнуться в начале нового проекта или при переходе на новую работу. Как только вы поймете, что находится за пределами круга, вы сможете в нужный момент попросить помощи у экспертов, которые окажут вам поддержку в заполнении пробелов в сложных для вас областях.
Модель 3: Обратная связь (PDCA)
Обратная связь – это цикл, в котором выходные данные из системы, поступают обратно в эту же систему, но уже в качестве входных данных.
Обычно это происходит в цикле «планируй-делай-проверяй-действуй» (plan-do-check-act – PDCA). Данный цикл – это повторяющийся процесс улучшения продуктов и сервисов.
Состоит он из четырех шагов:
- Планируй (Plan): определяем, что нужно сделать, составляем план.
- Делай (Do): выполняем в соответствии с планом.
- Проверяй (Check): анализируем выполнение плана и оцениваем его эффективность.
- Действуй (Act): претворяем план в жизнь.
В разработке программного обеспечения циклы обратной связи могут возникать на этапе программирования. Этот процесс может включать в себя сбор обратной связи от определенной группы пользователей с целью определить, решает ли продукт ту задачу, для которой он был предназначен. В противном случае, ожидания клиентов могут не оправдаться, а деньги и время, затраченные на этапе разработки, были потрачены впустую.
Разработчики могут применять циклы обратной связи во время парного программирования или код-ревью. Представьте junior-разработчика, который пишет код, а senior-разработчик этот код проверяет. В результате этого процесса навыки начинающих разработчиков растут, выявляются ошибки и улучшаются последующие результаты работы всей команды.
Модель 4: Ментальная карта
Ментальная карта – это схема, которая отражает визуальное представление неких концептов или идей. Попробуйте начать проект с составления ментальной карты. Начните с центральной идеи или концепта. Это может быть главная проблема или название проекта.
Далее вы добавляете ответвления или подтемы, которые относятся к центру. Как правило это основные задачи, которые предстоит решить каждой команде.
Вы можете добавить больше подтем или ветвей. Они могут отражать задачи каждого члена команды, которые в результате помогут достичь общей цели.
Ментальная карта также полезна при тестировании программного продукта. Тестировщики могут использовать ее для изучения приложения и для составления списка пройденных и не пройденных тестов. Попутно вы даже можете добавлять вопросы в ответвления. В таком случае отзывы и вопросы организованы в удобном для понимания формате.
Модель 5: График-холм
Графики-холмы – это ментальная модель, которая может помочь вам определить в каком месте идет прогресс, а в каком нет. Подобно форме холма, график состоит из двух фаз – склон вверх и склон вниз.
Первая фаза – склон вверх – «Во всем разобраться». На этом этапе у вас имеется общее понимание проекта, но вам все еще нужно выяснить некоторые моменты или закончить общую стратегию.
Со временем, вы достигаете той точки, когда вы готовы претворить свою стратегию в жизнь. Далее наступает фаза «склон вниз», или проще говоря «реализация».
Разработчики могут использовать такие графики при составлении списка задач для своих проектов. По мере того, как вы добавляете пункты, определяйте в какой части графика они должны находиться.
Опытные разработчики, которые работают на нескольких проектах или руководят несколькими командами, могут использовать эту модель, чтобы оценить, где команда сосредоточила свои усилия. Также это может помочь определить «застрявшие» команды и выяснить, что им необходимо для продвижения вперед.
Модель 6: Закон Паркинсона
Закон Паркинсона – это ментальная модель, согласно которой работа расширяется, чтобы заполнить время, отведенное на ее завершение.
Для примера возьмем команду разработчиков, которой дали три недели чтобы добавить или доработать какую-то функцию в проекте. Команда рада, что у них более чем достаточно времени на выполнение этой задачи. Они начинают работать не спеша и за три недели выполняют задачу, но после получения обратной связи, обнаруживается очень много проблем.
Закон Паркинсона гласит что команды должны устанавливать сроки для достижения максимальной эффективности, даже если они не кажутся реальными.
В первом примере команда была расслаблена из-за иллюзии большого срока. Однако, если бы им был назначен реальный срок в две недели, та же самая команда сделала бы больше за меньшее время. У них даже будет время, чтобы поработать с обратной связью от тестировщиков.
Модель 7: 5 Почему
«5 почему» – это ментальная модель, в которой необходимо пять раз задать один и тот же вопрос «Почему?».
Смысл в том, что когда вы определяете проблему, самое очевидное решение может не устранить основную причину этой самой проблемы. Выявление основной причины позволит разработчикам сэкономить время и силы. В противном случае, они просто будут применять временные меры, в то время как основная проблема будет не решена.
Вот пример, который может быть применим к разработчикам:
- Почему пользователь не смогут войти в календарь в нашем приложении? В недавнем обновлении была ошибка.
- Что привело к ошибке в последнем обновлении? Команда не смогла протестировать все функции.
- Почему команда не смогла протестировать все функции? Новые тестировщики в команде не смогли протестировать все должным образом.
- Почему новые тестировщики не справились с задачей? Им не предоставили нужных ресурсов и не провели нормальное обучение.
- Почему им не предоставили ресурсы и не провели обучение? Большинство новых тестировщиков работают удаленно. Команда, которая ответственна за их обучение, еще не разработала план адаптации для полностью удаленных сотрудников.
Модель 8: Инверсия
Во время решения проблемы мы часто думаем наперед. Такой подход может быть эффективен при решении простых задач. Но к сложным задачам это не всегда применимо. Инверсия помогает нам разбираться в проблемах и находить решения, думая в обратном направлении.
Представим, что вы запустили бесплатный пробный период в вашем приложении с целью увеличить клиентскую базу. Но, к сожалению, конверсия составила всего какие-то 2%.
Как правило, первый вопрос, который придет вам в голову: «Что мне сделать, чтобы больше людей пользовалось моим приложением даже после окончания бесплатного периода?».
Вместо того, чтобы думать наперед, взгляните назад и спросите себя – «Какими функциями больше всего пользуются во время пробного периода? Как можно улучшить впечатления пользователя за период бесплатного пользования?».
Решение первой задачи может заключаться в улучшении вашего онбординга и создании учебных материалов. Тем не менее вы можете выяснить какие факторы способствуют низкой конверсии инвертируя проблему.
Модель 9: принцип бритвы Оккама
Бритва Оккама, также известная как закон экономии. Это ментальная модель, предназначенная для решения проблем. Проще говоря, модель утверждает что всегда есть несколько путей для решения проблемы, самое простое, скорее всего, будет самым правильным.
Представьте разработчика, который для выполнения одной и той же задачи может написать как очень простой, так и очень сложный код. Самое простое решение будет самым лучшим, поскольку его проще и быстрее проверять и поддерживать.
Хотя результат один и тот же, простой код легче реализовать и проще поддерживать в долгосрочной перспективе.
Модель 10: Бережливый стартап
Бережливый стартап включает в себя цикл обратной связи Build – Measure – Learn («Создай – Оцени – Научись»). Многие стартапы начинаются с великолепной идеи, но для реализации задуманного могут уйти недели или месяцы.
Принципы бережливого стартапа решают эту проблему разработкой минимального жизнеспособного продукта (MVP – Minimal Viable Product), который могут протестировать заказчики или клиенты.
Как только целевая аудитория попробует продукт, стартап получит и проанализирует результаты. Цикл будет продолжаться до тех пор, пока не будет готов качественный продукт, способный удовлетворить большую аудиторию.
Команда людей может создать отличный продукт, постоянно получая обратную связь от целевой аудитории. В противном случае у стартапа могут уйти недели или месяцы только до момента бета-тестирования.
Что еще хуже, так это то, что в процессе тестирования могут возникнуть серьезные проблемы. Однако в этот продукт уже вложены тысячи долларов и просто нельзя дольше задерживаться на этом этапе.
Выбирайте правильную ментальную модель
Понимание того какую ментальную модель использовать в определенной ситуации помогает нам работать умнее, а не усердней.
Работа со сложными задачами требует много времени и сил. Ментальные модели помогают нам сегментировать большую проблему на более мелкие. Таким образом, мы можем добраться до сути вопроса и разработать наиболее практичные решения.
Я знаю, что может понадобиться время, чтобы интегрировать эти ментальные модели в вашу повседневную жизнь. Но как только вы выучите этот процесс и примените его, вы сможете выйти из тупика и направиться в верном направлении.
Комментарии