В интернете и книгах полным-полно best practices, которые освещают те или иные моменты в работе над ИТ-проектом. Однако best practices не позволяют увидеть всю картинку, на которой был бы виден весь путь реализации проекта с нуля. Мне не удалось найти такой «мануал», который бы разложил четко и по полочкам весь объем и порядок работ в заказном прое…
Хорошая статья. Без воды и по делу!
Хотелось бы чуть больше раскрыть информацию про то, как происходит estimate проекта. Как действовать, если неопределенность в ТЗ или, скажем, используемом API может создать доп. расходы/время?
ТЗ штука составная. Нужно разбить его на четко определенные смысловые куски и на неопределенные. Дальше нужно понять, сильно ли зависят четко определенные смысловые куски от неопределенных.
Если особо НЕ зависят - то можно проэстимировать эти куски и начать работу над ними, параллельно прорабатывая требования в неопределенных кусках ТЗ. Как раз здесь и проявляется удобство рамочного договора, где одно ТЗ можно разбить на несколько смысловых кусков и паковать их в отдельные приложения к договору.
Если зависят - то НЕ нужно начинать эстимирование до тех пор пока не появится первый четко определенный независимый кусок.
Неопределенность - один из самых серьезных врагов заказной разработки.
Тот враг, которого щадить нельзя.
Поэтому все что с точки зрения вашей команды плохо определено - не эстимируйте, или эстимируйте без обязательств. И добивайтесь такой детализации, с которой вам и вашей команде было бы комфортно взять ответственность за свои estimates.
К неопределенности в API(и чем либо еще) относимся так же как и к неопределенности в каком-то куске ТЗ. Устраняем неопределенность до тех пор, пока не станет комфортно брать ответственность за свои оценки.
Смог обьяснить?