Как раздробленное видение вызывает проблемы в проекте

Когда каждый член проектной команды смотрит на применяемые методы лишь со своей позиции, постоянно возникают старые проблемы. В годы кризиса программного обеспечения разработчики сразу погружаются в ПО, не тратя время на то, чтобы понять потребности пользователей. О новых требованиях они узнают в середине проекта и вынуждены удалять из программы часть кода, чтобы заменить его. Многие agile-методы направлены на формирование у команд четкого понимания потребностей заказчика с самого начала проекта, что помогает избежать больших объемов неэффективной работы. Но когда в команде не налажены коммуникации – например, разработчик создает код и «спихивает» его владельцу, не задумываясь об истинных потребностях клиента, – это может привести к однообразным проблемам, которые придется решать постоянно.

Что касается владельцев продуктов, их радует, что Agile дает возможность решать именно те задачи, которые нужны пользователям. Ведь до этого им приходилось констатировать, что контроль над проектом утерян, и лишь беспомощно наблюдать, как команда программистов собирает прошлогоднее ПО, потому что последний разговор с пользователями состоялся именно в прошлом году. Но владелец продукта будет по-прежнему разочарован, зная, что пишет пользовательские истории лишь для того, чтобы обнаружить: команда исполняет не совсем то, что он имел в виду. Команда считает, что владелец продукта ждет от нее угадывания его мыслей, а владелец, напротив, полагает, что эти люди хотят узурпировать все его время и постоянно слышать ответы на любые имеющиеся у них вопросы.

Такой же разрыв происходит и с другими ролями в проекте. Менеджеры проектов и лидеры команд счастливы, что разработчики взяли на себя создание структуры и конкретизацию целей. Они отмечают постепенные улучшения, но, к сожалению, не фундаментальные изменения в работе. Последние невозможны, если члены команды работают, соперничая друг с другом. Менеджер проекта, который видит пользовательские истории, приклеенные к доске в качестве прямой замены диаграммы Ганта в файле Microsoft Project, но продолжает по привычке «командовать и контролировать», будет часто реагировать на изменения в проекте, требуя от команды работать сверхурочно, чтобы не отставать от первоначального плана. Руководитель команды может занять жесткую позицию, ограждая сотрудников от дополнительных задач, пересматривая график с точки зрения сроков или сокращения объема работ. И менеджер проекта, и руководитель команды могут улучшать проект, но если бы они рассматривали перспективы с точки зрения друг друга, то могли бы избежать конфликта и при этом достичь хорошего результата.

Другими словами, когда не налажены коммуникации, каждый на своем месте может использовать новые инструменты (пользовательские истории), но придерживается старых установок, что вызывает трения в команде.

Новые инструменты лучше, поэтому дела идут успешнее. Но члены команды действительно не чувствуют большой разницы, потому что возвращаются прежние конфликты. И тогда рождается недоумение: неужели это все, что может Agile?

Как показывает опыт, многие команды столкнулись с подобной проблемой при внедрении отдельных практик и получили закономерный результат – «лучше-чем-ничего». Компания VersionOne разрабатывает гибкие программные инструменты и способствует развитию agile-сообщества во многих областях. Но ее главная заслуга – публикуемые ежегодно State of Agile Development Survey. Результаты 2013 года[11] демонстрируют, что многие команды добились улучшений, применяя agile-методологии.

• 88 % опрошенных VersionOne в рамках проекта State of Agile Development Survey 2013 заявили, что их компании занимались гибкой разработкой.

• 92 % респондентов сообщили о произошедших за год улучшениях во всех областях их деятельности и оцененных в результате проведенного опроса. Ведущие категории – способность управлять изменяющимися приоритетами (92 %), повышение производительности (87 %), улучшение обзора проекта (86 %), улучшение командного духа (86 %) и повышение качества программного обеспечения (82 %).

Хотя команды agile-проектов продвигаются быстрее и лучше реагируют на изменения, они часто терпят неудачу из-за культурных и мировоззренческих различий между водопадной и гибкой методологиями. Респонденты указали три основные причины провалов agile-проектов: «отсутствие опыта в использовании гибких методов», «философия компании расходится с agile-ценностями» и «внешнее давление со стороны тех, кто придерживается водопадной модели».

Когда новые команды начинают работать по agile-методологиям, они сталкиваются с проблемами. Чаще всего это происходит, потому что они не изменили водопадных способов работы. Пример команды проекта «Музыкальный автомат» показал: недостаточно просто добавить новую практику, чтобы решить проблемы, которые вызывают конфликты и мешают изменениям. Участники проекта «Музыкальный автомат» могли утверждать, что имеют опыт гибкой разработки, но во многих отношениях они оставались водопадной командой, начавшей применять некоторые важные agile-инструменты. (Дэйв Вест из аналитического агентства Forrester Research придумал специальный термин для подобных ситуаций: Water-Scrum-Fall[12].) Другими словами, они стали самой эффективной водопадной командой.

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Как раздробленное видение вызывает проблемы в проекте:

  1. Как вызывать катастрофы
  2. Как лидерство и храбрость помогают обрести видение правильного пути развития бизнеса
  3. Глава 1 Как объединить лидерство и храбрость, чтобы достичь идеального видения пути развития бизнеса
  4. 8. До пенсии вам остается около 10 лет. Вы решили инвестировать в привлекательный, с вашей точки зрения, проект по строительству недвижимости (около 1 млн руб.), но, посчитав ваши сбережения, вы понимаете, что вам придется занять еще 500 000 руб., так как минимальный вход в проект – 1,5 млн руб. Кредит вам, скорее всего, дадут, проект рассчитан на 5 лет. Ставка по кредиту – 16% годовых, ожидаемая доходность проекта – 25% годовых. Вероятность успеха проекта, по оценке независимых специалистов, ок
  5. ДЕКЛАРАЦИЯ . Положив руку на сердце, скажите: «Я выше любой проблемы», «Я справлюсь с любой проблемой». Коснитесь лба и произнесите: «Я думаю как миллионер!». ПРАКТИКУМ НАЧИНАЮЩЕГО МИЛЛИОНЕРА
  6. 20.Вызывайте эмоции
  7. 83. Упражнение«Что вызывает во мне желания»
  8. 27. Стабильность на одном уровне вызывает творческое вдохновение на другом
  9. Видение и миссия
  10. Видение
  11. 1.2. Проблема выбора как объект микроэкономического анализа
  12. Краткосрочное банковское кредитование как способ финансирования инвестиционных проектов
  13. ТО, КАК МЫ ВИДИМ ПРОБЛЕМУ, – И ЕСТЬ ПРОБЛЕМА
  14. Нет такого понятия, как проблема, есть только возможности
  15. Промышленная политика как инвестирование крупных проектов: опыт проведения
  16. 10.4. Проекты с неравными сроками действия, прекращение проектов, учет инфляции
  17. Видение своего персонального бренда