Написан пост, в котором вы трактуете упомянутую в руководстве работу «Toward a theory of evolution as multilevel learning» в контексте своего рабочего проекта.
Мои рабочие проекты крутятся вокруг создания ПО для обследования и планирования WiFi-сетей и его эксплуатации. Статью я читала ещё в прошлом году, почти весь текст так же написан год назад.
Кратко идеи и инсайты:
1. Ещё ранее по руководствам усвоено, что нет уже старого жизненного цикла, а есть постоянное развитие. Собственно, на примере ПО это проще наблюдать, так как продукт как таковой на рынке больше 10 лет, и постоянно идут обновления большие и малые. Можно считать это эволюцией и постоянным развитием.
2. Learning, оказывается, -- это познание и выбор. Собственно, при производстве ПО learning - это в том числе получение обратной связи от пользователей самых разных ролей.
3. Приходится выбирать, какие новые фичи или исправления внедрять сразу, а какие позже. Здесь можно наблюдать и конфликты между "ветками развития", вариантами выбора, и между выбором сейчас и потом.
4. Самые маленькие изменения - обычно самые быстрые: пофиксить GUI, добавить какую-то галку или фильтр, опции для печати. Поддержка новых версий железа - сложнее. Написание новый драйверов - очень долго, так как (surprise!), встроенное ПО самих железок тоже намного сложнее с каждым новым стандартом!
Многоуровневость: здесь есть перекос в сторону оптимизации составляющих, но меньше внимания тому, что во время эксплуатации есть работы, которые занимают очень много времени самого пользователя. На одном уровне ускорили от 10 до 100 раз, а на другом оставили сигналы от окружающих систем без должного внимания - это конфликт разных уровней.
В эту сторону сейчас и навожу внимание команды.
