Управление проектами - статьи



              

Как же обмануть Железный Треугольник?


Я нередко называю гибкие методологии "законным обманом, который приводит к победе". В любой организации есть устоявшиеся стереотипы поведения, которые только мешают работе, и на поверку оказываются совершенно лишними. Просто есть условности, о пользе которых никто не задумывается.

Вот три устоявшихся стереотипа, которые я стараюсь изменить:

  • Cначала нужно получить требования, а потом уже проектировать; сначала проектировать, а уже потом писать код.
  • Лучше описывать все подробно, чем делать приблизительные наброски и обсуждать их.
  • Людям лучше работается в изолированных рабочих помещениях.
  • Давайте заменим эти правила на другие:

  • Сочетать различные виды деятельности и одновременно разрабатывать систему. Получить вначале ровно столько требований, сколько нужно, чтобы начать работу над архитектурой продукта (точное количество требований будет варьироваться в зависимости от конкретного проекта). Писать код на самых ранних стадиях проекта, чтобы быстрее получить отзывы о разрабатываемом варианте архитектуры.
  • Кратко и быстро отражать основные моменты разработки в документации и не забывать сопровождать документацию живым общением.
  • Дать всем возможность работать в одном помещении.
  • Эти три постулата можно доказать двояко. Во-первых, книгами, в которых говорится об том же, с точки зрения теории и практики разработки ПО. Во-вторых, словами руководителей успешных проектов, которые уже многие годы применяют эти правила и подтверждают их своим личным опытом.

    Моя статья слишком мала, чтобы описать все стратегические и тактические приемы, которые они используют. К тому же, об этом можно прочесть в нескольких книгах: "Managing the Design Factory", "Skunk Works", "Theory of Constraints", "Lean Software Development", "Agile Software Development", и "Agile Management for Software Engineering.

    Я же пока ограничусь констатацией факта: когда я вижу, что проект перегружен, то начинаю с этих трех стратегий. Впрочем, не только я, но и другие опытные руководители. Давайте теперь обратимся к их опыту.




    Содержание  Назад  Вперед