Ментальные модели для разработчиков: 5 универсальных вариантов
Привет, %username%. Сегодня предлагаем обсудить, как оперативно решать сложные задачи в разработке при помощи ментальных моделей. Их ещё называют паттернами мышления. Вероятно, на Хабре почти все слышали о »методе уточки». Но есть и другие, не такие известные модели, которые помогают работать — как отдельным разработчикам, так и целым командам. Как именно и что это за модели? Давайте посмотрим.
Что такое ментальные модели и зачем они нужны?
Впервые гипотеза о существовании ментальных моделей была выдвинута ещё в середине 40-х годов XX века. Гипотеза объясняла ход мыслей человека при взаимодействии с внешним миром. Вот современное определение ментальной модели: «Интуитивное понимание принципов работы объекта или системы, которое основано на прошлом опыте человека, уже имеющейся информации, опыте и здравом смысле».
Если проще, то это мыслительный процесс, который направлен на восприятие мира и его элементов, которые нас окружают. По мнению психологов, включая Кеннета Крейка, создателя гипотезы, о которой говорилось выше, ментальные модели по своей сути неполные, но постоянно развивающиеся. Они представляют сложные явления в упрощённом виде. Ментальных моделей десятки, они помогают найти причины разных проблем, возникающих у разработчиков — как программистов, так и тимлидов или менеджеров направлений.
Статья познакомит читателей с универсальными ментальными моделями и методами их формирования, которые могут быть полезны для разработчиков. Какие-то из них подходят для отдельных специалистов, какие-то — для команд. Описанные ниже модели дают возможность использовать не случайные стратегии в ходе решения задачи, а при помощи определённых паттернов проанализировать условия, которые привели к возникновению ошибки и проблемных мест в коде.
5 ментальных моделей, которые помогают в работе
Модель № 1. Ментальная карта
Описание модели. Ментальная карта представляет собой схему, которая визуализирует задачи, идеи, концепты.
Автор идеи. Автором термина «ментальная карта» или «интеллект-карта» является Тони Бьюзен. Это известный писатель, лектор и консультант по вопросам интеллекта, психологии обучения и проблем мышления. В конце 1960-х он разработал методику составления ментальных карт как эффективного способа работы с информацией.
Кто может использовать. О таких картах, вероятно, слышали многие. Их, в частности, используют писатели в ходе работы над объёмными произведениями. Разработчики и целые команды тоже могут применять ментальные карты в работе. Важный момент — эту модель стоит задействовать только в случае решения комплексных задач.
Как использовать. Начинать составление карты нужно с главной идеи, которая лежит в основе всего проекта. Потом к основной идее или проекту подключаются дополнительные задачи, которые нужны для поиска решения.
В итоге формируется своеобразное «дерево проекта», каждая из ветвей которого — отдельная задача или идея. Карта может отражать задачи каждого из членов команды, которые работают над одной большой задачей. Также карту стоит использовать для тестирования программного обеспечения — к «корню» можно подключать «ветви» тестов, которые уже завершены или которые только предстоит выполнить.
Можно придумать и другие варианты использования ментальных карт — если у вас есть варианты, которые вы сами используете, давайте обсудим в комментариях.
Модель № 2.»5 Почему?»
Описание модели. Модель используется для изучения причинно-следственных связей, лежащих в основе той или иной проблемы. Основная задача модели — поиск первопричины возникновения дефекта или проблемы с помощью повторения одного вопроса — «Почему?»
Автор идеи. Модель »5 Почему?» придумал основатель компании Toyota Сакити Тоёда. Она в числе многих других наработок руководства компании помогла Toyota стать международной корпорацией.
Кто может использовать. Что касается сферы разработки, то использовать эту модель могут как отдельные разработчики, так и подразделения компаний, которые работают над различными программными продуктами.
Как использовать. Иногда причина проблемы неявная, а правильно заданные вопросы разбивают поиск на несколько этапов и упрощают локализацию бага или иной неполадки. Ниже — простой пример 5 вопросов к решению проблемы неработающего сервиса.
Почему не удаётся запустить сервис? При апдейте возникла проблема, которую сразу не заметили.
Что привело к этой проблеме? Тестировщики не успели всё проверить должным образом.
Почему не успели? У тестировщиков не было времени, часть команды перебросили на другой проект.
Почему те члены команды, кто остался, не справились с проведением полноценного тестирования? Им не хватило ресурсов плюс несколько человек из команды — новички.
Почему так случилось? Руководитель проекта некорректно составил план и нерационально распределил ресурсы.
Вопросы этой модели помогают локализовать первопричину проблемы и оперативно решить её.
Модель № 3. График-холм
Описание модели. Модель «График-холм» (Hill Charts) помогает оценить, где какая команда (или член команды) сосредоточила основные усилия и в каком статусе находится весь проект. На графике хорошо видны «застрявшие» таски, после чего можно оперативно выяснить причину этого и начать двигаться вперёд.
Автор идеи. К сожалению, автора этой модели определить сложно — в том или ином виде она используется уже несколько десятков лет.
Кто может использовать. Модель идеальна для команд, которые работают над объёмными комплексными проектами. Вот пример использования «холма» Райаном Сингером, Head of Product Strategy в Basecamp. Команда разрабатывала функцию уведомления о переносе события. Как оказалось, список задач Notify of rescheduling завис в одной точке графика на несколько дней.
Команда обсудила возникшую проблему, и оказалось, что бэкенд уже почти готов, а вот дизайн находится в начальной стадии реализации. Было решено разбить единый список задач на три и разнести по разным склонам холма. Получилось вот что:
Стало ясно, что происходит в проекте и что нужно делать для дальнейшего продвижения.
Как использовать. Механика составления этой модели простая: рисуется холм, а участники команды расставляют статус списков собственных задач на «склонах» этого холма. Члены команды, добавляя пункты, определяют, в какой части «холма» эти пункты должны находиться.
Склон вверх — это «во всём разобраться», когда есть общее понимание проекта, но нужно прояснить некоторые моменты либо же закончить общую стратегию. После того как всё прояснилось, а проект готов к началу реализации, наступает вторая фаза — склон вниз. Собственно говоря, это и есть реализация проекта.
Конечно, эта модель субъективна, подходит не для всех команд и проектов. Но, как видим, в некоторых случаях она помогает очень хорошо.
Модель № 4. Закон Паркинсона
Описание модели. Эта модель предназначена для рационального распределения времени и ресурсов при работе команды над определённым проектом.
Автор идеи. Она берёт начало из юмористического эссе Сирила Норткота Паркинсона, которое он написал для журнала The Economist в 1955 году. Согласно «закону», работа расширяется, чтобы заполнить время, отведённое на её завершение.
То есть, если назначить очень уж комфортный срок на решение определённой задачи, то исполнитель спешить не будет и раньше срока вряд ли сдаст свой проект. Может случиться, что исполнитель расслабится настолько, что работа будет выполняться авральными методами в самом конце и качество исполнения будет страдать.
Кто может использовать. Лучше всего модель работает в отношении команд разработчиков. Например, какой-то команде дали месяц на добавление новой функции в проект. Команда хорошо понимает, что времени очень много, больше, чем нужно, и начинает работать неспешно. Настолько, что после завершения задачи обнаруживается гора проблем, решить которые в установленный срок не получится.
Как использовать. Стараться трезво оценивать необходимое для завершения задачи время.Если бы команде дали две недели, то разработчики бы собрались с силами, мобилизовали свои ресурсы и сделали всё качественно и в срок. Естественно, здесь может быть и другая крайность, с которой все мы тоже очень хорошо знакомы — дефицит времени из-за слишком близкого дедлайна. В этом случае всё делается наспех по принципу «и так сойдёт, лишь бы успеть». Но в этом и талант руководителя — установить такой срок, который не позволит чрезмерно расслабиться, с одной стороны, и не «гнать коней» — с другой.
Модель № 5. Бережливый стартап
Описание модели. Речь идёт о модели с обратной связью «Создай — Оцени — Научись». Так, идея, предложенная стартапом, может быть прекрасной, но для её полной реализации потребуется гора времени и ресурсов. В итоге ничего не получается.
Автор идеи. Модель базируется на идее, предложенной Эриком Рисом сначала в блоге www.startuplessonslearned.com, а потом в книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели».
Кто может использовать. Изначально идея имела отношение исключительно к предпринимательству, но её можно использовать и в разработке. Подходит модель в первую очередь для команд, которые занимаются разработкой объёмных проектов.
Как использовать. Основная идея модели — разработка минимально жизнеспособного продукта (MVP — Minimal Viable Product). Это продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Прежде чем бросить все ресурсы на получение финального продукта, стоит выпустить и протестировать MVP. На его основе можно получить обратную связь, которая послужит фундаментом для дальнейшей работы над продуктом и его планомерным развитием.
Цикл этот может быть не однократным, а многоразовым, повторяться до тех пор, пока продукт не станет действительно качественным, способным удовлетворить соответствующую категорию пользователей.
В сухом остатке
В самом конце статьи стоит обратить внимание на то, все эти модели — не панацея. Они представляют собой дополнительный инструмент для разработчика, а не средство от всех проблем. Важно и то, что модели из списка (да и не только из списка, ведь их намного больше) применяются в определённых случаях. Поэтому перед тем как выбрать одну из них, стоит тщательно взвесить все за и против работы с конкретной моделью.
Если у вас есть собственные инструменты такого рода, поделитесь в комментариях. Интересно, что именно вы используете и каков результат.
