Закоулки мозга

Продолжаю читать Business Objects Re-engineering for re-use и, кажется, начал лучше понимать причины бесплодности моих попыток что либо изменить в командных процессах - помимо слабости моих софт-скиллов, конечно же. Похоже, что я пытаюсь “надавить” на какие-то отдельные точки, не учитывая, что все они входят в единую мощную парадигму разработки продуктов. А парадигму парой слов (и даже дискуссией/спором на пару часов) не изменишь, по крайней мере, надеяться на это не стоит.

Нужно определить основы этой парадигмы и подсветить явно их противоречия/расхождения-с-реальностью. Сказать легче, чем сделать.

Попробую сформулировать обнаруженные проявления господствующей парадигмы, возможно, в процессе смогу добраться до основ.

  1. Эффективность по ресурсам.
  2. Из нее следует нарезка задач в стиле Scatter-Gather
  3. Из нее следует “Я выкрутился - теперь ваша очередь”. Границы работы у каждой роли свои, а “После нас - хоть потоп”.
  4. Из этого узкого понимания области своей работы следует невнимание к ролевым интересам.
  5. А еще “синдром внешнего врага” у каждой роли - “я-то весь в белом, это все они напортачили”.
  6. Shaking Foundations - шаткие основы. Господствующая парадигма очень ориентирована на выполнение-работ/execution/operations и не уделяет должного внимания фундаментальному пониманию того, что и как мы делаем.
  7. Отсюда концентрация на инструментах, а не на принципах.
  8. Сильная связанность через неявные знания. То есть, многие вещи не фиксируются в явном виде, подразумевается, что те, кому нужно, и так это знают. Беда в том, что речь про персоналии, а не про роли.
Эффективность
по ресурсам
Шаткие основы
Легкое важнее простого
Scatter-gather
Нет понимания связи
работ и результата
Невнимание к ролевым интересам
Синдром внешнего врага
Инструменты важнее принципов
Работы важнее решений
Поведение важнее структуры
Персоны важнее ролей

Это не окончательная схема, тут еще думать и думать…