Вы — менеджер нового проекта индивидуальной разработки.
Вам принесли договор неизвестно кем и как он был заключен, вам дали контакты заказчика и дальше вы предоставлены сами себе.
Изучив функциональную сферу проекта, понимаешь, что в данном случае правильно будет применить Agile. Но в контракте уже прописаны четкие этапы в соответствии с каскадной моделью развития со сроками, результатами и фиксированной ценой для каждого этапа.
Что делать в этой ситуации? 
1. Подготовка проекта
Убедитесь, что методология Agile и высокоитеративные циклы разработки обеспечивают значительные преимущества для вашего проекта.Если вы, например, строите гидроэлектростанцию, то начинать с небольшого гребного колеса и постепенно его увеличивать будет не лучшей идеей.
То же самое касается и масштабного внедрения ERP-системы, когда над каждым модулем работает отдельная проектная команда, все они должны быть интегрированы и работать одновременно – здесь без качественного чертежа и единого шага не обойтись.
-пошаговый план.
Но если ваша задача достаточно локальная, у вас компактная проектная команда, тесное взаимодействие с заказчиком, то есть все предпосылки для использования Agile.
2. Этап концептуального проектирования
Итак, в соответствии с методологией Agile вы определили минимальный функционал, который имеет наибольшую важность для заказчика, и в кратчайшие сроки внедрили его в продуктивное использование.Затем вы начинаете публиковать обновления каждые две недели, добавляя функции и исправляя комментарии.
Первая засада ждет вас, когда приближается срок выполнения этапа проектирования по контракту (рис.
3).
Рис.
3 Завершение этапа проектирования По договору вы к этому времени должны предоставить ТЗ на весь функционал, но вы его толком не изучили, потому что были заняты запуском первого релиза.
Что делать? На самом деле ничего страшного в этом нет, вы просто отправляете техническое задание, в котором весь функционал описан на очень высоком уровне (можно напрямую скопировать формулировку из договора), причем по тем функциям, которые вы уже изучили или даже если уже реализовано, вы предоставляете подробную спецификацию.
Практически всегда клиент будет к этому лояльным.
Самый важный для него функционал он получил очень быстро, комментарии исправляются оперативно, у него нет причин вам не доверять, ему не терпится двигаться дальше, и он легко подпишет какое-то формальное техническое задание.
Кстати, это очень хороший момент, чтобы пересмотреть функциональную сферу проекта.
У заказчика уже могут быть пожелания относительно уже реализованного функционала.
И у вас есть отличный шанс обменять эти маленькие, понятные и нужные заказчику дополнительные функции на мутные и опасные кусочки требований из договора.
Просто согласуйте такую замену с заказчиком и зафиксируйте ее в техническом задании без изменения стоимости договора и заключения дополнительных соглашений.
3. Этап реализации
Настоящая засада ждет вас дальше, когда приближается срок этапа реализации.
Рис.
4 Завершение этапа внедрения К этому моменту половина функционала уже работает в продакшене, вторую половину еще толком не начали изучать, и вы приносите заказчику акт с просьбой закрыть для вас этап внедрения.
Потом обычно что-то щелкает в голове: «Как я могу закрыть для них всю разработку, если я пока получил только половину?!» К такому повороту надо подготовиться заранее и встретить его во всеоружии:
- Вам необходимо заранее объяснить заказчику, почему вы придерживаетесь Agile-методологии.
Поговорите о бесперебойной доставке ценного программного обеспечения, снижении рисков и тому подобном.
- Вы можете нарисовать схему, подобную рис.
4, и наглядно показать, что половина работы сделана, поэтому вы хотите получить половину денег.
- Очень хорошо, если у вас есть критические дефекты в функционале, находящемся в продуктивном использовании.
Вы говорите: «Как же так, вы хотите, чтобы мы устранили за вас дефекты, то есть выполнили работу по 4 этапу, а за 2 этап вы нам еще не заплатилиЭ» Если внедряемая система действительно полезна заказчику – это хороший рычаг воздействия.
- Чтобы заказчику было психологически проще подписать вам акт, можно попробовать реализовать в системе заглушки для остального функционала: нерабочие пункты меню, интерфейсы без реализации и т. д. При этом объясните, что все это будет реализован на этапе реализации, по уже знакомой ему итерационной схеме.
- Можно констатировать, что в сложившейся ситуации виноват сам заказчик, поскольку он не смог сразу сформулировать все требования.
И вы его устроили и позволили постепенно на протяжении всего проекта формулировать требования.
- Постоянно напоминайте, что это только второй этап и до завершения проекта еще далеко.
- Ну и используйте все остальные стандартные инструменты из арсенала менеджера проекта: запросы, манипуляции, выматывание, угрозы, шантаж.
На этом этапе все средства хороши.
4. Этап реализации
После подписания акта на этап реализации можно потом расслабиться.Больше не будет подводных камней из-за несоответствия вашей методики контракту.
Просто посмотрите, какие отчетные материалы вы должны предоставить на этапе реализации.
Обычно там есть какие-то протоколы миграции данных, протоколы обучения пользователей, инструкции и т. д. Если вы раньше все сделали правильно, то вы уже подписали эти документы в части реализованного функционала.
И самое главное, ваша подпись на потоке.
Заказчик, штатно подписывая очередной протокол обучения, даже не заменит того факта, что это был последний протокол, необходимый для закрытия этапа внедрения.
Рис.
5 Завершение этапа внедрения
5. первоначальное сопровождение промышленной эксплуатации
То же самое относится и к начальному этапу поддержки промышленной эксплуатации.С первого месяца работы над проектом вы научили заказчика, что по любому поводу он выявит дефекты в системе отслеживания ошибок, а вы оперативно над ними поработаете.
Заказчик уже понимает, чем ошибка отличается от нового требования, как распределяются приоритеты дефектов и почему всем дефектам нельзя присвоить критический приоритет. Когда приближается срок закрытия начального этапа поддержки, вы просто выгружаете все дефекты, внесенные заказчиком в ходе проекта, готовите их в красивом отчете со всей статистикой и графиками и отправляете вместе с отчетом заказчику.
Желательно, чтобы на этом этапе у вас не осталось критических дефектов.
Остается только объяснить заказчику, что ваш проект подошел к концу, и для дальнейшего исправления недочетов необходимо заключить отдельный договор на обслуживание системы.
Если вы последовали этим рекомендациям, то вы осознали все преимущества методологии Agile, то есть получили полезный продукт, максимально соответствующий потребностям клиента.
При этом мы уложились в сроки и бюджет, изначально указанные в контракте.
Теги: #agile #Заказная разработка #контракт #водопад #scrum #agile
-
Электрический Трансформатор
19 Oct, 24 -
Алгоритм Косараджу По Полочкам
19 Oct, 24 -
Задайте Вопрос Водителю Марсохода
19 Oct, 24
