Слушаю онлайн марафон "Проектные истории" (кстати, может быть, кто-то ещё его слушает?)
Очень трезвые рассказы про то, что такое проекты изнутри в российских реалиях. И да, оно всё именно так.
И, что большая редкость - честно признаётся, что есть такие проекты, когда лучше kill it with fire, а не убивать об них команду.
(я там дальше пишу заметочки для себя - про то, что я выношу из этих историй и комментарии на полях).
* * *
Сверхполезен своеобразный due diligence. О проблематичном заказчике, проблематичных процессах, схемах и т.п. (не всегда, но иногда) можно узнать до официального старта проекта. Не получится уйти с проекта - хотя бы внутренняя готовность будет, бонусом это можно учесть в управлении требованиями и рисками проекта.
* * *
Чем более проблематичный заказчик, тем больше должно быть взаимодействий, причём личных.
Личное взаимодействие вообще важно на всех уровнях. Письменные документы требуют огромных трудозатрат и на написание, и на понимание, поэтому личное общение и взаимодействие не просто всегда эффективнее (это все знают), оно, строго говоря, единственный необходимый способ взаимодействия. Письменная спецификация не может быть основным вариантом ни контракта заказчик/ аналитик, ни аналитик/ разработчик.
Вообще, основная проблема использования спецификации как контракта между заказчиком и разработчиком - в трудоемкости управления требованиями. На долгосрочных проектах неизбежные в силу изменения окружающей среды изменение/ расползание требований могут составить больше четверти объема проекта даже при идеальной спецификации (которой не бывает).
* * *
Как вариант, возможно описание всех возможных сценариев, включая те требования, которые реализованы не будут. Это спасает от пропущенных сценариев и следующих из них архитектурных ошибок. Но естественно, это возможно только при чётком управлении ожиданиями.
Лайфхак для трудных заказчиков: выполнение трассировки требований только в качестве внутреннего документа, без предоставления к нему доступа заказчику. В случае адекватного заказчика это не нужно и даже вредно.
* * *
Отличный лайфхак для фиксации неоднократно измененного требования: после первого изменения дать несколько возможных вариантов использования и сделать так, чтобы заказчик выбрал один и последний раз, полностью осознавая ответственность. Лайфхак, потому что после постоянных изменений текущего варианта осознания ответственности у заказчика не появляется.
Очень трезвые рассказы про то, что такое проекты изнутри в российских реалиях. И да, оно всё именно так.
И, что большая редкость - честно признаётся, что есть такие проекты, когда лучше kill it with fire, а не убивать об них команду.
(я там дальше пишу заметочки для себя - про то, что я выношу из этих историй и комментарии на полях).
* * *
Сверхполезен своеобразный due diligence. О проблематичном заказчике, проблематичных процессах, схемах и т.п. (не всегда, но иногда) можно узнать до официального старта проекта. Не получится уйти с проекта - хотя бы внутренняя готовность будет, бонусом это можно учесть в управлении требованиями и рисками проекта.
* * *
Чем более проблематичный заказчик, тем больше должно быть взаимодействий, причём личных.
Личное взаимодействие вообще важно на всех уровнях. Письменные документы требуют огромных трудозатрат и на написание, и на понимание, поэтому личное общение и взаимодействие не просто всегда эффективнее (это все знают), оно, строго говоря, единственный необходимый способ взаимодействия. Письменная спецификация не может быть основным вариантом ни контракта заказчик/ аналитик, ни аналитик/ разработчик.
Вообще, основная проблема использования спецификации как контракта между заказчиком и разработчиком - в трудоемкости управления требованиями. На долгосрочных проектах неизбежные в силу изменения окружающей среды изменение/ расползание требований могут составить больше четверти объема проекта даже при идеальной спецификации (которой не бывает).
* * *
Как вариант, возможно описание всех возможных сценариев, включая те требования, которые реализованы не будут. Это спасает от пропущенных сценариев и следующих из них архитектурных ошибок. Но естественно, это возможно только при чётком управлении ожиданиями.
Лайфхак для трудных заказчиков: выполнение трассировки требований только в качестве внутреннего документа, без предоставления к нему доступа заказчику. В случае адекватного заказчика это не нужно и даже вредно.
* * *
Отличный лайфхак для фиксации неоднократно измененного требования: после первого изменения дать несколько возможных вариантов использования и сделать так, чтобы заказчик выбрал один и последний раз, полностью осознавая ответственность. Лайфхак, потому что после постоянных изменений текущего варианта осознания ответственности у заказчика не появляется.
- а я ещё покопаю всякие трипадвайзоры и лайкэлокалы 
.