Продолжаю читать Business Objects Re-engineering for re-use и, кажется, начал лучше понимать причины бесплодности моих попыток что либо изменить в командных процессах - помимо слабости моих софт-скиллов, конечно же. Похоже, что я пытаюсь “надавить” на какие-то отдельные точки, не учитывая, что все они входят в единую мощную парадигму разработки продуктов. А парадигму парой слов (и даже дискуссией/спором на пару часов) не изменишь, по крайней мере, надеяться на это не стоит.
Нужно определить основы этой парадигмы и подсветить явно их противоречия/расхождения-с-реальностью. Сказать легче, чем сделать.
Попробую сформулировать обнаруженные проявления господствующей парадигмы, возможно, в процессе смогу добраться до основ.
- Эффективность по ресурсам.
- Из нее следует нарезка задач в стиле Scatter-Gather
- Из нее следует “Я выкрутился - теперь ваша очередь”. Границы работы у каждой роли свои, а “После нас - хоть потоп”.
- Из этого узкого понимания области своей работы следует невнимание к ролевым интересам.
- А еще “синдром внешнего врага” у каждой роли - “я-то весь в белом, это все они напортачили”.
- Shaking Foundations - шаткие основы. Господствующая парадигма очень ориентирована на выполнение-работ/execution/operations и не уделяет должного внимания фундаментальному пониманию того, что и как мы делаем.
- Отсюда концентрация на инструментах, а не на принципах.
- Сильная связанность через неявные знания. То есть, многие вещи не фиксируются в явном виде, подразумевается, что те, кому нужно, и так это знают. Беда в том, что речь про персоналии, а не про роли.
по ресурсам) B(Шаткие основы
Легкое важнее простого) A --> A1[Scatter-gather] A1 --> A2[Нет понимания связи
работ и результата] A2 --> A3[Невнимание к ролевым интересам] A2 --> A4[Синдром внешнего врага] B --> B1[Инструменты важнее принципов] B --> B2[Работы важнее решений] B --> B3[Поведение важнее структуры] B --> B4[Персоны важнее ролей] B2 --> A1 B3 --> A2 B4 --> A3
Это не окончательная схема, тут еще думать и думать…