Комментарии в контектсте волонтерского проекта создания Маскота
Продолжая обсуждение из темы Гипотезы для исследования: инженерия саморазвития и общественных систем в эпоху ИИ. Версия 0.2:
Можно подробнее расписать что мы имеет ввиду под портфолио - я так понимаю что это вариант “Assurance”/верификации/доказательства качества/уровня мастерства, то что нужно как-то понять работодателю, потенциальному партнеру, покупателю инфо товаров (конечно чего угодно, но мы тут говорим больше про интеллектуальный труд). Тут мы(сообщество и школа) можем и помочь с формой подачи и уже с тем что в эту форму можно будет положить, ведь может даже человек и начинает это понимать, а показать-то нечего, после обучения только и дали бумажку и “Hello world” уровень учебного проекта. А это и есть как раз культура оценки знаний (и тут сразу на домен HR мы начинаем покушаться, а почему бы и нет).
Тут общался недавно в клубе, и затронули (буквально пару сообщений) что нынешние редакторы (в большинстве случаев программного кода) для кода. Есть обсидиан(еще конечно и кода и ноушен). Они все создавались для текста - не мыслей (а есть разница?). Нужно может нам редактор мыслей, с логом мышления, не только конечного результата. Сейчас все сразу ссылаются на Git, но это инструмент (с методом его использования) был создан два десятка лет назад, человеком (Линусом) что бы иметь возможность указывать какие они глупые и для одиночной работы (ведь централизованные репозитории на серверах для командной работы было дополненно уже как расширение гитхабом, они еще придумали концепт Pull Request (PR) ). Сейчас все больше и больше начинают понимать что с ИИ Гит не работает, например вот интересные идеи компанией создающий редактор с нуля Sequoia Backs Zed's Vision for Collaborative Coding — Zed's Blog . Понятия снапшота (а если назовем мысли), как кусочек, который сможем логировать??
Про Риски - проблемы в коорпарациях, то что не все думают и вслепую применяют большие фреймворки (SAFE, use case 2.0). После этого группа из https://ivarjacobson.com поняли что нужно давать маленькие методики (как ядро) и только после размышлений иметь возможность по нужде расширять из https://www.ivarjacobson.com/files/use-case_3.0_v1.0.pdf :
This guide describes how to apply use cases in an agile and scalable fashion. It builds on feedback and lessons learned since the initial publication of the Use-Case 2.0 e-book in 2011. Our goal is to provide you with an integrated family of practices which help you get the most out of your use cases. These practices are applicable for small co-located agile teams, but are also applicable to large distributed teams, outsourcing, and complex multi-system developments. Select, mix and match the use case practices described in this guide to support your work; add use-case practices later if you need more detail and structure to guide your work.
Тут тоже менять культуру маленьких ядер(каких? Тут у нас тоже есть чем поделиться), культуру мышления (этим тоже богаты).
И еще тем кто предлагает эволюцию огранизаций, вместо пышного маркетинга(тут мы тоже пытаемся этого избежать) обучить коорпарации или просто менять ценности при выборе/решениях об обучении сотрудников, обществ(школы, высшие учебные заведения, профессиональное жизненное развитие).