Тем самым получается, что для отслеживания выполнения работ надо отслеживать не просто состояния предмета работ (рабочих продуктов, например, в проектировании — проектной документации, в которой отражены какие-то проектные решения), но состояние предмета метода — например принятых проектных решений, предмет метода проектирования.
Вот тут вопрос/непонятка возникла - размышления:
- предмет работ - рабочие продукты, которые собственно создаются в процессе работы
- предмет метода - решения, концепции, выбор технологий и т.д.
Если я правильно понял: работы выполняются по методу, и в процессе выполнения работ создаются какие-то рабочие продукты и их создание нужно отслеживать. Но т.к. метод тоже может менятся в процессе(скажем раньше была одна архитектура, а потом решили использовать другую, потому-что какие-то гипотезы не подтвердились и появились другие) то его нужно отслеживать, чтобы не получилось так, что в конце проекта работы выполнены, но выполнены по старому методу, который уже неактуален.
Наивный пример, что пришел мне в голову:
- изначально команда выбрала язык Go для разработки приложения
- в процессе разработки стало ясно, что Go плохо подходит и приняли решение о переходе на Python, потому что там есть нужные библиотеки с алгоритмами для нашего продукта
- если команда продолжит работать по старому методу(использовать язык Go) то ближе к концу может выяснится, что мы не можем интегрировать библиотеки и, соответственно, не можем проверить продуктовые гипотезы, или интегрировать можем но это займет значительно больше времени/денег и мы пролетим по «коммерческая возможность»::альфа
В этом наивном примере кажется, что такое произойти не может, слишком уж очевидно. Но, наверное, если я немного подумаю и найду что-то не такое глобальное, а поменьше - то легко может.
Примеры чего-то поменьше: другой формат логирования, другой линтер.
И кстати, такое даже бывает, что некоторые агенты саботируют переход на другой метод по разным причинам. Так что еще один повод отслеживать состояние предмета метода
Необходимость коллективного отслеживания состояний: Для успешной командной работы важно не только выполнять задачи, но и совместно отслеживать состояние предметов метода. Это достигается через ведение записей и использование моделей (моделеров), которые отражают текущее состояние работ.
Важность коллективной собранности: Успех проекта зависит от того, насколько команда сохраняет коллективное внимание к состояниям альф и эффективно взаимодействует для достижения общих целей.
Немножко другими словами то, что было сказано ранее важно не просто менять методы, но и делать так чтобы все об этом знали и меняли все что нужно соответственно.
Сотрудничество vs. Кооперация:
- Кооперация предполагает разделение труда и ресурсов с согласованием интерфейсов взаимодействия, но без общей ответственности за итоговый результат.
- Сотрудничество включает в себя не только кооперацию, но и совместную ответственность за конечный результат. Это высшая степень взаимодействия, требующая системного мышления и понимания влияния своих действий на общую цель.
До сих пор я сотрудничество видел только в небольших командах/компаниях. Как только это все разрастается на больше чем(±50-70 человек) уже все сотрудничество переходило в кооперацию, иногда раньше(а каков ваш опыт?).
Не знаю, это естественный предел и бывает ли чтобы большее количество людей оставались в рамках сотрудничества и с чем такой распад связан и как его предотвратить. Т.к. конечно в рамках сотрудничества мне намного приятнее и веселее работать.
