В начале статьи вы задаёте вопрос «Как провести этап аналитики и составить ТЗ, чтобы ожидания заказчика и исполнителя совпали?» и потом «на чьей стороне возникает проблема, как ее устранить?». Судя по гипотетической ситуации приведённой в статье у вас сработали риски с оценкой - дизайн был основан не на реальных данных, плюс не было выявлено критериев приемки ни на этапе аналитики, но в ходе изменений макетов и урезания функционала. Понятно, что все упирается в бюджеты, но можно ли это считать все таки недоработками со стороны подрядчика?
Можно вести переговоры с заказчиком. Можно пытаться двигать бюджеты. Выносить доработки в Change Request-ы. Оформлять доп. соглашения. Много чего можно делать.
Но в любом случае это будет лишь работой с уже сработавшим риском. Фактическая ситуация, когда заказчик не очень-то доволен результатом, а подрядчик не очень-то доволен оплатой - уже налицо, и её можно только смягчить, но не ликвидировать полностью. К сожалению, такие ситуации в заказной разработке - не редкость. :(
Конечно Acceptance Criteria конечно то же может быть хорошим инструментом для того что бы синхронизировать ожидания, но ты их уже пишешь на придуманное решение. Т.е. ты изначально формулируешь Epic->Feature->UserStory и уже к ним пишешь Acceptence. Тут основная мысль в подходе откуда придумывать решение. Если ты уже сделала UserStory просто на основании пускай даже реальных данных и пускай даже это реальные пользовательские истории то тебе уже тяжело мыслить по другому. Идея в том что бы постоянно задавать себе вопрос: А как моё решение повлияет на метрику или индикатор? Или иногда можно задать вопрос: А что будет, если я этого вообще не буду делать? Что будет если я не буду вообще рефакторить этот метод?
В начале статьи вы задаёте вопрос «Как провести этап аналитики и составить ТЗ, чтобы ожидания заказчика и исполнителя совпали?» и потом «на чьей стороне возникает проблема, как ее устранить?». Судя по гипотетической ситуации приведённой в статье у вас сработали риски с оценкой - дизайн был основан не на реальных данных, плюс не было выявлено критериев приемки ни на этапе аналитики, но в ходе изменений макетов и урезания функционала. Понятно, что все упирается в бюджеты, но можно ли это считать все таки недоработками со стороны подрядчика?
Можно вести переговоры с заказчиком. Можно пытаться двигать бюджеты. Выносить доработки в Change Request-ы. Оформлять доп. соглашения.
Много чего можно делать.
Но в любом случае это будет лишь работой с уже сработавшим риском. Фактическая ситуация, когда заказчик не очень-то доволен результатом, а подрядчик не очень-то доволен оплатой - уже налицо, и её можно только смягчить, но не ликвидировать полностью.
К сожалению, такие ситуации в заказной разработке - не редкость. :(
Конечно Acceptance Criteria конечно то же может быть хорошим инструментом для того что бы синхронизировать ожидания, но ты их уже пишешь на придуманное решение. Т.е. ты изначально формулируешь Epic->Feature->UserStory и уже к ним пишешь Acceptence. Тут основная мысль в подходе откуда придумывать решение. Если ты уже сделала UserStory просто на основании пускай даже реальных данных и пускай даже это реальные пользовательские истории то тебе уже тяжело мыслить по другому. Идея в том что бы постоянно задавать себе вопрос: А как моё решение повлияет на метрику или индикатор? Или иногда можно задать вопрос: А что будет, если я этого вообще не буду делать?
Что будет если я не буду вообще рефакторить этот метод?