Комментарии 13
Спасибо за статью. Оказывается, я не один пытаюсь совместить «водопад на бумаге» и Agile в реале. Дело даже не в договоре: олдскульное начальство требует видимость водопада.
Хорошие советы, годные, но вот у меня где-то первой трети проекта возникает большое объективное недоверие к команде исполнителей, и как бизнес-закзчик я уже не иду на поводу и не подписываю акты до выполнения 100% обязательств. И да, я олдскул
Внезапно, суровая правда agile: получается сделать за одинаковое время, что так, что так.
Могу быть не прав, но площади прямоугольников-то совпадают…
Могу быть не прав, но площади прямоугольников-то совпадают…
Ошибся тредом, удалено.
Хорошо, если
1) заказчик, который использует систему и принимает доработки и
2) заказчик, который подписывает акты
это один и тот же человек.
Или если хотя бы второй прислушивается к мнению первого.
В реальности же в критический момент сдачи этапа абстрактный заказчик часто оказывается многоголовой гидрой, и у каждой головы обнаруживается своё собственное видение и собственные интересы.
1) заказчик, который использует систему и принимает доработки и
2) заказчик, который подписывает акты
это один и тот же человек.
Или если хотя бы второй прислушивается к мнению первого.
В реальности же в критический момент сдачи этапа абстрактный заказчик часто оказывается многоголовой гидрой, и у каждой головы обнаруживается своё собственное видение и собственные интересы.
Вы правы, очень важно в самом начале выявить всех стейкхолдеров и управлять их влиянием на проект. Но это нужно делать независимо от выбранной методологии и условий договора, поэтому я тут этот вопрос не рассматривал. Про управление стейкхолдерами очень хорошо написано тут: Стейкхолдеры: зона особого внимания
Я конечно возможно не очень большой специалист в Agile, но если на втором рисунке поменять местами вертикальные и горизонтальные столбцы, то мы получим тот же самый Waterfall. Весь проект разбивается на этапы по внедрению конкретных функций. То есть на мой взгляд тут правильнее понять, что именно хочется заказчик, чтобы заработало всё и в один день или для него важнее начать использовать результаты проекта как можно раньше.
Если вы в такой формулировке зададите вопрос заказчику, он всегда вам ответит, что чем раньше результат, тем лучше. Вам уже самому надо подумать, каков риск того, что, например, взявшись за реализацию функции №5 вам не придется полностью переделывать всю архитектуру, созданную для функций №1-4? И не лучше ли сначала все функции продумать, а потом браться за разработку? Мы предположили, что вы как менеджер взвесили все за и против и решили, что в данном случае итерационный процесс будет предпочтительнее. В идеале было бы заключить договор Time&Material, и работать до полного удовлетворения заказчика. Но заказчики на это почти никогда не идут. Они хотят платить за результат, а не за процесс, полагая, что тем самым перекладывают риски на исполнителя. Плюс их IT служба привыкла делать типовые договоры с этапами соответствующими фазам какой-нибудь каскадной методологии. Точно также привык работать и ваш отдел продаж. В итоге вы получаете описанную ситуацию.
Но Вы же сами в начале написали, что принесли уже готовый договор, в котором описаны все этапы работы. Таким образом, Вы сразу же начинаете нарушать данный договор и предоставлять клиенту не то, что он ожидает. Конечно клиент не захочет платить Вам деньги за этапы, так как он не видит результаты работы. Он ждёт общую документацию по всей системе, а ему предоставляются три важных, на наш взгляд, для него функции.
Я считаю что, правильность выбранного подхода к разработке зависит от того, когда и какие результаты хочет клиент. А исполнитель должен руководствоваться именно тем, что написано в договоре и плане работ. А если мы предоставлены сами себе и считаем, что уместнее применить другой подход к плану работ, то вперёд убеждать в этом клиента. Ведь для клиента главное результат, а для нас оплата.
Я считаю что, правильность выбранного подхода к разработке зависит от того, когда и какие результаты хочет клиент. А исполнитель должен руководствоваться именно тем, что написано в договоре и плане работ. А если мы предоставлены сами себе и считаем, что уместнее применить другой подход к плану работ, то вперёд убеждать в этом клиента. Ведь для клиента главное результат, а для нас оплата.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение Agile в рамках договора с фиксированными фазами