Мы привыкли думать, что архитектура программ рождается из требований бизнеса, бюджетов и технологий. Но в самом начале любого проекта лежит архитектура мышления — разработчика, заказчика, пользователя. Эта статья и ряд других в серии «каскад» — попытка рассмотреть проектирование как отражение когнитивных механизмов человека. Не UX, не поведение пользователей, а именно то, как фазы нашего мышления формируют будущую систему. И главное — как, поняв это, создавать более устойчивые и человечные архитектуры.
Откуда взялась эта идея
Меня зовут Валерий, я работаю low‑code разработчиком в компании БФТ-Холдинг. По квалификации — исследователь, по специальности приборы и методы контроля (к.т.н.), и практический психолог. Моя экспертиза лежит на стыке точных измерений и человеческого восприятия. И однажды я заметил любопытную вещь.
В книгах по разработке ПО подробно расписаны этапы анализа, генерации идей, тестирования, итераций. Но если присмотреться, это не просто инженерные процедуры. Это точные отражения того, как работает человеческое мышление:
• мы анализируем — потому что мозг умеет расчленять целое на части;
• мы генерируем идеи — потому что включается дивергентное мышление;
• мы проверяем гипотезы — потому что работает критический фильтр;
• мы итеративно улучшаем — потому что мозг обучается через обратную связь.
Методологии разработки — это формализованная проекция когнитивных процессов. Но в профессиональной литературе эти этапы описываются разрозненно: как инструменты, лучшие практики, фреймворки. Редко кто задумывается об их ��бщем источнике — архитектуре мышления. Из‑за этого процессы смешиваются, путаются или применяются не в той фазе. По отдельности использовать процессы – низкоэффективно, а что бы повысить эффективность – нужно знать и видеть весь процесс целиком. Больше знаний – больше контроль и понимание!
Я поставил себе задачу: собрать когнитивную «карту» проектирования, показать фундаментальные механизмы мышления и проследить, как они превращаются в архитектурные решения. И тогда становится ясно, чем на самом деле является программное обеспечение: не просто кодом, а внешней конструкцией, продолжающей и усиливающей наши когнитивные способности.
Почему мы вообще создаём ПО? (и при чём тут мозг)
Обычно мы проектируем систему «от результата»: сначала цель, потом — инструмент для её достижения.
После завершения разработки программа становится самостоятельным объектом — нашим инструментом. А у нас остаются воспоминания о том, как мы искали решения, проверяли гипотезы, натыкались на тупики. Эти действия — элементы другой системы, системы нашего мышления.
Теперь давайте шагнём назад, из процесса, выгрузимся из него, так сказать перестанем ассоциировать себя с ним, и посмотрим на процесс шире.
Зачем же мы создаём ПО? Не просто ради автоматизации, а чтобы усилить, дополнить или изменить возможности собственного мозга.
Вот лишь несколько примеров (на самом деле их гораздо больше, расскажу в других статьях):
• Расширение памяти. Облачные хранилища, поисковики, базы данных — внешняя память, которая, в отличие от человеческой, не искажается и не забывает.
• Новые способы мышления. Поисковый запрос учит нас сводить сложную мысль к набору ключевых слов. Гиперссылки формируют «сетевое» мышление.
• Имитация реальности. Игры и симуляторы дают опыт, который невозможно или опасно получить в жизни, — качество такого опыта выше, чем от простого фантазирования.
• Делегирование рутины. Мозг передаёт ПО задачи, которые выполняет медленно или с ошибками: сложные расчёты, безошибочное повторение операций, хранение точных дат.
• Материализация идей. Интеллект‑карты, диаграммы, блок‑схемы помогают вытащить неосознаваемые связи наружу и сделать их объектом анализа.
• Создание контролируемой среды. Мы строим цифровые пространства, где влияние хаоса минимизировано, а нужные факторы усилены.
Таким образом, ПО — это не просто код, а продолжение нашего познания. И процесс создания ПО неизбежно отражает этапы самого познания.
Как мышление превращается в код: разбор на реальном примере
Чтобы было понятнее, давайте представим, что команда разрабатывает онлайн‑редактор документов с совместным доступом (вроде Google Docs). Я пройду по всем фазам мышления и покажу, какое архитектурное решение за каждой из них стоит.
🧠Фаза 1. До сознательная подготовка (то, что происходит ещё до формального старта)
-
Понятийный механизм
Разработчики начинают с базовых сущностей: «документ», «пользователь», «операция», «версия». Без чёткого понятийного аппарата нельзя строить архитектуру.
2. Абстрагирование
Текст перестаёт быть просто файлом «.doc» — он превращается в с��руктуру данных, последовательность операций или состояние модели.
3. Обобщение
Разные типы контента (текст, таблицы, презентации) обобщаются до единого принципа: «редактируемая структура с историей изменений».
4. Классификация
Пользователи делятся на роли: владелец, редактор, комментатор, читатель. Это ляжет в основу модели прав доступа.
5. Определение (дефиниция)
Формулируется чёткое определение: «Документ — это синхронизируемая модель состояния, поддерживающая конкурентные изменения».
6. Операции с понятиями
Сравниваются подходы: «Это ближе к файловой системе или к распределённой базе данных?»
7. Вербализация
Все ключевые понятия фиксируются в документации и обсуждениях. Без единой терминологии совместная работа невозможна.
8. Восприятие + внимание
Команда фиксирует «боль» пользователей: «Версии файлов конфликтуют, правки теряются». Это точка запуска проекта.
9. Эмоциональный интеллект
Есть реакция пользователей и амбиция сделать по‑настоящему совместный инструмент. Эмоциональная значимость удерживает фокус.
10. Память
Вспоминаются предыдущие решения: блокировки файлов, системы контроля версий, распределённые базы.
Параллельно, уже начинает работать механизм мета познания и на старте может задавать вопросы: «Насколько это важно? Стоит ли этим заниматься?». Не с эмоциональной окраской, а уже взвешенно: «сколько затрачу ресурсов – какая будет выгода?».
🧩 Фаза 2. Осмысление и структурирование проблемы
11. Анализ
Проблема разбивается на части: синхронизация, конфликт изменений, сохранение истории, управление доступом.
12. Абстрагирование
Отбрасывается второстепенное (дизайн кнопок). Выделяется ядро: «конкурентные операции над общей структурой».
13. Сравнение
Проводятся аналогии: Git? Базы данных? Репликация? Текст рассматривается как поток операций.
14. Системное мышление
Учитывается влияние на серверную нагрузку, задержки сети, безопасность, масштабируемость.
15. Целеполагание
Формулируется цель: «Несколько пользователей могут редактировать документ одновременно без потери данных».
16. Критическое мышление
Проверяется реалистичность: «Что при плохой сети?», «Что, если 50 человек правят один абзац?».
💡 Фаза 3. Генерация решений (инкубация и озарение)
17. Дивергентное мышление
Генерируются варианты: блокировки, merge, OT (операционные трансформации), использование CRDT, мастер‑сервер, peer‑to‑peer.
18. Блуждание ума, инсайт (DMN – Default Mode Network)
После паузы, отвлечения на другие задачи или род занятий (что лучше), приходит инсайт: «Не синхронизировать текст, а синхронизировать операции».
19. Аналогическое мышление
Сравнение с распределёнными системами и транзакционными журналами.
20. Комбинаторика
Объединяется: журнал операций + временные метки + трансформация конфликтов.
21. Интуиция
Команда чувствует, что операционные трансформации дадут большую гибкость, даже если они сложнее в реализации.
22. Пространственное мышление (если нужно) Визуализация идей, мысленные манипуляции с формами. Визуализация и рисование низкодетализированных скетчей (wireframes) экранов: где кнопка «создать групповой заказ», как выглядит общая корзина, экран участника.
🔎 Фаза 4. Верификация, синтез, планирование
23. Конвергентное мышление
Из множества вариантов выбирается нужная архитектура (например, OT).
24. Критическое мышление
Проводятся стресс‑тесты сценариев: разрывы соединения, конфликт правок, откат изменений.
25. Моделирование
Мысленный прогон: 10 пользователей печатают одновременно. Система сохраняет консистентность (согласованность)?
26. Синтез + планирование
Создаются API, схема взаимодействия клиент‑сервер, протокол обмена операциями.
27. Конкретизация
Перевод абстрактного решения в конкретные шаги, этапы, техзадание.
28. Итеративная петля
После запуска появляются новые слои: комментарии, история версий, предложения правок, ИИ‑помощники.
🚀 Фаза 5. Реализация и коррекция
29. Память (процедурная)
Автоматизация рутинных шагов реализации, если это навык. Использование привычных инструментов: Jira для задач, Confluence для документации, проведение ревью прототипов по отработанному сценарию.
30. Внимание (устойчивое и распределенное)
Удержание фокуса на процессе, переключение между подзадачами. Удержание фокуса на всей цепочке задач, переключение между обсуждением API с бэкендером, UI с дизайнером и правками в ТЗ.
31. Мета познание (мониторинг)
Непрерывный контроль за продвижением к цели, сравнение плана с реальностью. «Мы успеваем по срокам? Технические сложности соответствуют первоначальной оценке? Не ушли ли мы в сторону от бизнес-цели?».Важно выделять, видеть и следовать этапам.
32. Обратная связь (через восприятие)
Получение данных от пользователей / коллег о результатах действий. Проведение самостоятельного тестирования в разных ролях (критик, тестировщик, пользователь, служба поддержки).
33. Анализ + сравнение
Сопоставление полученного результата с ожидаемым. Выявление расхождений. Если расхождение велико → возврат на Фазу 1, 2 или 3 с уточнёнными данными. Начинается новый виток.
Ловушки мышления, которые подстерегают на каждом этапе (будет выделено в отдельную статью)
Те же самые когнитивные механизмы, которые помогают нам мыслить, могут и завести не туда.
-
На этапе анализа легко попасть в ловушку фрейминга: то, как мы поставили вопрос, определяет ответ. Если спросить: «Как нам избежать потери данных?», мы будем искать защиту. Если спросить: «Как сделать совместное редактирование удобным?», мы придём к OT/CRDT. Одна и та же задача, разные рамки — разные архитектуры.
-
На этапе аналогий работает «закон инструмента»: если у вас есть молоток, всё вокруг кажется гвоздями. Команда, которая хорошо знает Git, может попытаться натянуть его модель на онлайн редактор, даже если это не оптимально.
-
На этапе генерации мешает фиксация (функциональная застылость): привычное использование объекта мешает увидеть его новые возможности. Например, мы привыкли, что документ — это файл, и долго не можем перейти к модели «потока операций».
-
На этапе критики опасна склонность к подтверждению своей точки зрения: мы ищем подтверждения правильности выбранного решения, а не опровержения. Команда, влюбившаяся в OT, может недооценить сложность реализации, хотя CRDT был бы проще.
-
На этапе моделирования мы часто переоцениваем свою способность удержать в голове все сценарии (иллюзия прозрачности). Кажется, что система понятна, но в реальности всплывают нюансы, которые не были учтены.
Осознавая эти ловушки, мы можем сознательно переключать «режимы» мышления и избегать типовых ошибок ещё до того, как они попадут в код.
Что даёт нам это понимание?
Когда мы видим, что этапы разработки — это отражение этапов мышления, мы перестаём быть просто исполнителями. Мы начинаем управлять собственной когнитивной деятельностью.
• Мы понимаем, в какой фазе сейчас находимся, и не пытаемся генерировать идеи, когда нужно критиковать (и наоборот).
• Мы можем выносить во внешние инструменты те операции, с которыми мозг справляется плохо: долговременное хранение точных данных, сложные расчёты, бескомпромиссная логика.
• Мы проектируем системы, которые усиливают человека, а не перегружают его, потому что видим их как продолжение нашего познания.
Любая система сначала существует в голове. Анализ, дивергенция, критика, интуиция — всё это не просто этапы разработки, а этапы мышления, которые затем материализуются в коде.
Осознав это, мы становимся когнитивными инженерами — теми, кто умеет строить мосты между внутренней архитектурой сознания и внешней архитектурой взаимодействия.
Автор: fiksnorthstar56
