Комментарии 3
Ситуация когда лид читает ТЗ несколько раз и утверждает его вполне нормальна и адекватна. У меня был подобный опыт работы, где каждое звено тесно работало друг с другом(заказчик ставит задачу, аналитики от заказчика и исполнителя составляют тз, разработчики и тестировщики исполнителя оценивают полноту требований). В такой ситуации аналитик и лид часто немного погружались в обязанности друг дгуга(лид погружался в предметную область, а аналитик умел понимать элементарный код). Но в итоге это давало плюс, в большинстве случаев ТЗ оценивались адекватно. и делались в срок, а если были просчеты то они были минимальны.
В этой ситуации обязанности человека выше(менеджера) дать понять сотрудникам что все они делают общее дело и конфликты не приносят ничего кроме разрушения.
После этой работы я ушел на другую где связь между отделами отсутствует по сути, а аналитиков и тестировщиков нет вообще. Поэтому поставнока задачи в три предложения это нормально, остальное разраб додумывает сам. Издержки которые это все порождает катастрофичны, проект который можно сделать в течении 7-8 месяцев растягивается на 2+ года.
В этой ситуации обязанности человека выше(менеджера) дать понять сотрудникам что все они делают общее дело и конфликты не приносят ничего кроме разрушения.
После этой работы я ушел на другую где связь между отделами отсутствует по сути, а аналитиков и тестировщиков нет вообще. Поэтому поставнока задачи в три предложения это нормально, остальное разраб додумывает сам. Издержки которые это все порождает катастрофичны, проект который можно сделать в течении 7-8 месяцев растягивается на 2+ года.
недоверие возрастало, так как обе команды чувствовали, что другая команда пытается их обмануть
Значит плохой менеджер, который не смог на этом этапе (а лучше — еще раньше) увидеть указанную проблему и разрешить ее.
Проблема у вас в управлении, а не в модульности.
После каждого изменения требований должна производиться его оценка на другие проектные ограничения — срок, бюджет, команду. Результат согласовываться с владельцем продукта.
Если он принимает этот эффект, работаете спокойно. Если цена оказывается не адекватна бизнес-ценности — он откажется сам. Если вы не можете оценить эффект и внятно его рассказать — у вас пока мало опыта, учитесь.
Ибо даже идеальный код бессилен перед изменением требований за день до релиза.
После каждого изменения требований должна производиться его оценка на другие проектные ограничения — срок, бюджет, команду. Результат согласовываться с владельцем продукта.
Если он принимает этот эффект, работаете спокойно. Если цена оказывается не адекватна бизнес-ценности — он откажется сам. Если вы не можете оценить эффект и внятно его рассказать — у вас пока мало опыта, учитесь.
Ибо даже идеальный код бессилен перед изменением требований за день до релиза.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я разработчик, а не юрист