Александр, руководитель проектов 1С
Когда вы берете на себя управление проектом, особенно в условиях постоянно меняющихся требований и высокой неопределенности, на первый план выходит вопрос: какой методологии довериться? Scrum часто воспринимается как панацея, гибкая и адаптивная методология, способная подстроиться под любые изменения. Но за годами работы в управлении проектами я понял одно: без критического подхода даже самые современные инструменты могут превратиться в ловушки.
Мы с командой не раз и не два сталкивались с тем, что гибкость, которую так возвышают в Scrum, может легко обернуться хаосом. Каждый раз, когда проект теряет четкие ориентиры, мы превращаемся в моряков на корабле, оставленном на произвол бурных волн. И если вовремя не взять штурвал, можно затонуть в бесконечных изменениях и пересмотрах целей.
Scrum – это инструмент, который требует грамотного подхода, иначе его гибкость станет вашим врагом. И я здесь не для того, чтобы рассказывать о теоретических основах методологии, а чтобы поделиться теми самыми подводными камнями, на которые мы не раз наталкивались. Это история о том, как на практике методы управления проектами проверяются на прочность, когда столкновение с неопределенностью неизбежно.
Отсутствие фиксированных целей — первый шаг к провалу
Одним из главных уроков, который я вынес из своего опыта управления проектами, является необходимость чёткого определения целей на старте. Это кажется очевидным, но в мире Scrum, где всё ориентировано на гибкость и адаптивность, этот момент часто упускают из виду. В результате проект начинает двигаться не к конкретным результатам, а просто «куда-то». Вроде бы ничего страшного, ведь гибкие методологии позволяют корректировать цели на ходу, но когда заказчик не понимает, чего именно он хочет достичь, любая гибкость превращается в хаос.
В одном из наших проектов внедрения ERP-системы клиент не смог чётко зафиксировать цели на этапе устава проекта. На старте обсуждали только складскую систему, без учёта того, как она будет интегрироваться с финансовым и производственным учётом. Нам говорили: «Сначала сделаем склад, а потом посмотрим». Это стало началом масштабных проблем. Проект рос в объёме, появлялись новые требования, и в конце концов нам предложили заняться ещё и производством. Проект изначально не имел чёткой цели, и это стало нашей первой крупной ошибкой.
Цель должна быть зафиксирована в уставе проекта. Это не просто формальность — это необходимый инструмент, чтобы все участники процесса понимали, к чему они идут. Наличие конкретных целей помогает команде ориентироваться в условиях постоянных изменений, иначе проект начинает двигаться по воле случая. А случай — плохой помощник в бизнесе.
Смена команды и лиц, принимающих решения
Второй по значимости камень на пути успешного внедрения Scrum — это смена ключевых лиц, принимающих решения. За годы своей работы я сталкивался с ситуациями, когда команда, начав проект, вынуждена была корректировать все свои действия из-за прихода нового руководителя со стороны клиента. В одном из проектов смена ЛПР (лиц, принимающих решения) произошла трижды за несколько месяцев. Сначала ушёл один аналитик, потом руководитель отдела, затем сменился финансовый директор. Каждый новый человек приносил своё видение проекта, а иногда и новые задачи, что нарушало стройность планирования.
Когда происходит смена ЛПР, проект по сути начинается заново. Не потому, что нужно пересматривать технические аспекты, а потому что новые люди приходят со своим набором приоритетов и ценностей. Наша ошибка заключалась в том, что мы доверились заказчику в вопросе передачи информации новому человеку. Как показала практика, не стоит полагаться на внутренние коммуникации заказчика. Каждый новый ЛПР должен быть вовлечён в проект лично, и с ним нужно вновь прорабатывать все цели и задачи проекта. Именно прямое общение с новыми участниками помогает избежать разрывов и недопонимания.
В одном из проектов, где сменилось несколько ключевых лиц, мы просто обязаны были провести повторную серию встреч, объяснив каждый шаг проекта и каждый его аспект. Только это помогло восстановить общую картину в головах новых участников и продолжить работу.
Документация — артефакты, которые спасают проект
Ещё один важный аспект, который нельзя игнорировать, — это документация. Scrum известен своей склонностью к минимизации формальностей и бюрократии, однако в реальности она может сыграть злую шутку. Особенно это касается работы с большими компаниями и государственными проектами, где подписанный акт — это лишь начало пути к успешному завершению проекта.
Договоры и акты — это не просто бумажки, которые подтверждают завершение этапа. Они являются юридической защитой в случае споров. Но ещё важнее не забывать про артефакты — все документы, которые фиксируют промежуточные результаты работы: отчёты, протоколы, модели и схемы. Без подписанных артефактов можно столкнуться с ситуацией, когда клиент откатывает акт или заявляет, что не получил ожидаемых результатов.
Здесь возникает ещё одна проблема. Заказчик может подписать акт, но если все промежуточные документы не были подписаны должным образом, это может стать причиной разногласий. В одном из наших проектов мы столкнулись с ситуацией, когда клиент отказался признавать результаты этапа, потому что все артефакты не были зафиксированы в должной мере. Вывод прост: перед подписанием актов нужно удостовериться, что все промежуточные документы подписаны и зафиксированы, иначе проект может обернуться длительными судебными разбирательствами.
Управление изменениями — гибкость не без ограничений
Когда компания выбирает Scrum, она рассчитывает на гибкость и возможность адаптироваться к изменениям. Но гибкость тоже должна иметь свои границы. Если на каждом спринте вносятся новые изменения, без учёта общей картины проекта, это может стать катастрофой. Гибкость должна быть инструментом, а не целью.
Заказчик часто не осознаёт, что каждое изменение влечёт за собой новые трудозатраты и потенциальное увеличение бюджета. Необходимо правильно выстраивать процесс работы с изменениями, чтобы не навредить ни проекту, ни команде. В одном из наших проектов, когда клиент добавлял всё новые и новые задачи, мы приняли решение приостановить все дополнительные работы, пока не согласуем новые условия. Это решение оказалось спасительным, поскольку оно позволило нам удержать проект в рамках бюджета и сроков, не жертвуя качеством.
Декомпозиция как способ контроля неопределённости
Когда проект сталкивается с неопределённостью, лучший способ справиться с ней — это разбить задачу на несколько этапов. В Scrum декомпозиция задач — одна из ключевых практик, позволяющая контролировать ход проекта и снижать риски. Однако декомпозиция будет эффективной только тогда, когда каждый этап имеет свои чёткие критерии завершения, и каждый участник команды понимает свою роль и ответственность.
В одном из наших проектов мы внедрили декомпозицию, разбив большой и сложный проект на несколько мелких задач, каждая из которых контролировалась своим менеджером. Это помогло нам удержать проект на плаву и справиться с изменениями, которые происходили на каждом шагу. Но ключевым моментом была фиксация ответственности за каждый этап — без этого декомпозиция становится хаотичной и неуправляемой.
Коммуникация — искусство удержания команды на одной волне
Но даже при чётко зафиксированных целях и грамотно проведённой декомпозиции успех проекта напрямую зависит от коммуникации. Scrum предполагает постоянные встречи и обсуждения, чтобы вся команда оставалась на одной волне. Но что делать, если команда заказчика не включена в процесс? Именно с этой проблемой мы столкнулись в одном из проектов.
Заказчик просто не приходил на ежедневные встречи, считая их бесполезной тратой времени. Команда Scrum продолжала свои обсуждения, но без участия заказчика они потеряли смысл. Мы осознали, что проблема не в самой методологии, а в том, что заказчик не был достаточно мотивирован участвовать в проекте. Это привело к необходимости кардинально изменить подход: мы отказались от ежедневных встреч в пользу более редких, но содержательных обсуждений. Эти встречи были более короткими, но их ценность возросла за счёт того, что заказчик включился в процесс.
Итоги
Scrum — это мощный инструмент, который при правильном применении помогает справляться с неопределённостью и изменениями. Однако успех внедрения этой методологии зависит от множества факторов: от чётко зафиксированных целей до налаженной коммуникации между командой и заказчиком. Важно не только следовать букве Scrum, но и адаптировать его под реалии конкретного проекта.
Подводные камни, с которыми сталкиваются многие команды при внедрении Scrum — это нормальная часть пути. Главное вовремя их распознать и не позволить им затянуть проект в пучину хаоса. Ведь в конце концов не технология обеспечивает успех проекта, а люди, которые ей управляют.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.