Первое, что мне понравилось в этой главе - это раздел про четыре обязательных вида разбиений системы (и пятый “почти обязательный”) и связанные с ними описания. Думаю, что это одна из самых практичных идей в курсе, которую сразу хочется брать и отрабатывать в практике. И это тот самый случай, когда курс по сути дает мета-модель для описаний на проекте и это помогает экономить внимание. В большинстве случаев документация проектов содержит в том или ином виде “лоскуты” информации из приведенных выше разбиений, но там ключевой вопрос: “А достаточно ли этого?” Дальше честный ответ: “В общем случае недостаточно, но вот необходимый минимум!” И это гарантия, что мы не совершаем “новичковых” ошибок. Это очень хороший инструмент. Ну и попробовав его приложить к текущему проекту тоже выявил недостатки текущих своих “гибридных” описаний и пошел их дорабатывать.
Раздел про функциональный анализ и модульных синтез тоже очень понравился. В разделе довольно много внимания уделяется различию между “созерцателем/ аналитиком” и “деятелем/синтетиком/инженером/”. При прочтении подумал, что в реальной жизни часто проблема еще и в дефиците лидерства, потому что чаще всего аналитики совсем неглупые и даже неравнодушные люди, но как только они понимают проблему, дальше возникает мгновенный запрос на лидерство, потому что надо пойти и начать что-то делать. И в большинстве случаев действий не возникает, потому что не находится ответ на вопрос: “А почему я? И зачем мне это надо?”
И еще одна мысль в эту сторону. В западных проектах и командах намного меньше распространены аналитики в виде отдельных сотрудников. Чаще всего ожидается, что аналитик - это роль, которую могут играть если не все члены команды, то точно все разработчики. То есть способность отрабатывать роль аналитика ожидается от инженера из коробки, а не выделяется в отдельную должность. Мне это прям бросилось в глаза несколько раз. И кажется, что это решает и проблему эффективности, и проблему профессиональных инженерных знаний для синтеза, и сразу дает ответ на вопросы “А почему я? И зачем мне это надо?”, то есть снижает риск дефицита лидерства. Похоже на элегантное решение сразу нескольких проблем.
Много времени потратил на моделирование примеров несовпадающих функционального и конструктивного разбиений. Это оказалось прям контринтуитивно, несколько часов просто не было версий. Помогло обсуждение с группой на курсе и ответы преподавателей. После этого дело пошло, но ощущения уверенности и тем более беглости нет и в помине. И ответы на вопросы в курсе сигнализируют о том же, ошибок было немало.
Ну и самая глубокая идея про то, что основная сложность в практике возникает при типизации в реальных проектах, т.е. подборе в реальном проекте объектов соответствующего типа мета-мета-модели из курса. Все примеры с Р. Фейнманом, физикой и математикой зашли “как родные”. Я бы в ряд этих примеров еще Л.Д. Ландау добавил, у него в научной школе много было построено именно для отсечения сдающих теоретический минимум ровно по этому навыку. Вот в этом навыке надо прибавлять, это основа для беглости применения системного мышления. Я этого так ясно не понимал. Теперь, кажется, понимаю)))