Слушаю онлайн марафон "Проектные истории" (кстати, может быть, кто-то ещё его слушает?)
Очень трезвые рассказы про то, что такое проекты изнутри в российских реалиях. И да, оно всё именно так.
И, что большая редкость - честно признаётся, что есть такие проекты, когда лучше kill it with fire, а не убивать об них команду.
(я там дальше пишу заметочки для себя - про то, что я выношу из этих историй и комментарии на полях).
* * *
Сверхполезен своеобразный due diligence. О проблематичном заказчике, проблематичных процессах, схемах и т.п. (не всегда, но иногда) можно узнать до официального старта проекта. Не получится уйти с проекта - хотя бы внутренняя готовность будет, бонусом это можно учесть в управлении требованиями и рисками проекта.
* * *
Чем более проблематичный заказчик, тем больше должно быть взаимодействий, причём личных.
Личное взаимодействие вообще важно на всех уровнях. Письменные документы требуют огромных трудозатрат и на написание, и на понимание, поэтому личное общение и взаимодействие не просто всегда эффективнее (это все знают), оно, строго говоря, единственный необходимый способ взаимодействия. Письменная спецификация не может быть основным вариантом ни контракта заказчик/ аналитик, ни аналитик/ разработчик.
Вообще, основная проблема использования спецификации как контракта между заказчиком и разработчиком - в трудоемкости управления требованиями. На долгосрочных проектах неизбежные в силу изменения окружающей среды изменение/ расползание требований могут составить больше четверти объема проекта даже при идеальной спецификации (которой не бывает).
* * *
Как вариант, возможно описание всех возможных сценариев, включая те требования, которые реализованы не будут. Это спасает от пропущенных сценариев и следующих из них архитектурных ошибок. Но естественно, это возможно только при чётком управлении ожиданиями.
Лайфхак для трудных заказчиков: выполнение трассировки требований только в качестве внутреннего документа, без предоставления к нему доступа заказчику. В случае адекватного заказчика это не нужно и даже вредно.
* * *
Отличный лайфхак для фиксации неоднократно измененного требования: после первого изменения дать несколько возможных вариантов использования и сделать так, чтобы заказчик выбрал один и последний раз, полностью осознавая ответственность. Лайфхак, потому что после постоянных изменений текущего варианта осознания ответственности у заказчика не появляется.
Очень трезвые рассказы про то, что такое проекты изнутри в российских реалиях. И да, оно всё именно так.
И, что большая редкость - честно признаётся, что есть такие проекты, когда лучше kill it with fire, а не убивать об них команду.
(я там дальше пишу заметочки для себя - про то, что я выношу из этих историй и комментарии на полях).
* * *
Сверхполезен своеобразный due diligence. О проблематичном заказчике, проблематичных процессах, схемах и т.п. (не всегда, но иногда) можно узнать до официального старта проекта. Не получится уйти с проекта - хотя бы внутренняя готовность будет, бонусом это можно учесть в управлении требованиями и рисками проекта.
* * *
Чем более проблематичный заказчик, тем больше должно быть взаимодействий, причём личных.
Личное взаимодействие вообще важно на всех уровнях. Письменные документы требуют огромных трудозатрат и на написание, и на понимание, поэтому личное общение и взаимодействие не просто всегда эффективнее (это все знают), оно, строго говоря, единственный необходимый способ взаимодействия. Письменная спецификация не может быть основным вариантом ни контракта заказчик/ аналитик, ни аналитик/ разработчик.
Вообще, основная проблема использования спецификации как контракта между заказчиком и разработчиком - в трудоемкости управления требованиями. На долгосрочных проектах неизбежные в силу изменения окружающей среды изменение/ расползание требований могут составить больше четверти объема проекта даже при идеальной спецификации (которой не бывает).
* * *
Как вариант, возможно описание всех возможных сценариев, включая те требования, которые реализованы не будут. Это спасает от пропущенных сценариев и следующих из них архитектурных ошибок. Но естественно, это возможно только при чётком управлении ожиданиями.
Лайфхак для трудных заказчиков: выполнение трассировки требований только в качестве внутреннего документа, без предоставления к нему доступа заказчику. В случае адекватного заказчика это не нужно и даже вредно.
* * *
Отличный лайфхак для фиксации неоднократно измененного требования: после первого изменения дать несколько возможных вариантов использования и сделать так, чтобы заказчик выбрал один и последний раз, полностью осознавая ответственность. Лайфхак, потому что после постоянных изменений текущего варианта осознания ответственности у заказчика не появляется.
-
-
27.02.2016 в 21:56а под этим подписываюсь обеими руками, столкнулась недавно с последствиями отсутствия личного контакта в команде. жестоко.
Личное взаимодействие вообще важно на всех уровнях. Письменные документы требуют огромных трудозатрат и на написание, и на понимание, поэтому личное общение и взаимодействие не просто всегда эффективнее (что все всегда знают), оно, строго говоря, единственный необходимый способ взаимодействия. Письменная спецификация не может быть основным вариантом ни контракта заказчик/ аналитик, ни аналитик/ разработчик.
-
-
27.02.2016 в 22:13пфффф, конечно. Марафон идёт ещё несколько недель, я, правда, смотрю только в записи - ну, они с утра по мск, а у меня утра всегда забитые.
И ещё это спасает от не умеющих говорить лекторов, которых надо слушать на скорости 1.5. Так что я по мере просмотра буду дописывать - хочешь, буду кидать в комменты, чтобы у тебя вылезало в счётчике дискуссий.последствиями отсутствия личного контакта в команде
Если совсем нет личного контакта - это вообще пиздец. У меня оно было в mild-варианте - очень сильно сказывалась деформация работы об заказчиков, которые от всего, не зафиксированного письменно под подпись, могли откреститься в любой момент (собственно, поэтому письменное ТЗ, например, часто выступает как форма контракта). Проблема в том, что если задача - сделать нужное ПО, а не сыграть в игру "перекинь горячую картошку", письменные документы крайне вторичны...
-
-
27.02.2016 в 23:14Река Сена, хочу )
чуть позже расскажу тебе кулстори по этому поводу. ща отваливаюсь)
-
-
19.03.2016 в 14:03Во-2, хотела с тобой поделиться: смотрю сейчас марафон, там дивное. Чувак рассказывает, как они делали проект, проебали все полимеры (из серии "было запланировано 2 релиза, оказалось их 6, сначала сделали пицот метрик, оказалось, надо двадцать" - и так во ВСЁМ), причём отчетливо видно, что проебали они его из-за классического водопада, а не менее классический аджайл там бы отлично сработал. Ну, просто потому что аджайл вообще хорош, когда требования изначально неопределены более чем на треть (оценка эмпирическая и моя). Но чувак рассказывает, как они преодолевали и явно считает, что всё окнорм.
Я, наверное, злобный, а работа в этой компании меня сделала ещё и наглым - я увидела, сколько я, оказывается, умею и могу. И вот смотрю я что-то на этот доклад и это даже несмешно ((.