да, этот шаг у нас уже пройден) чек-лист создавался еще в те времена, когда шаблоном я не пользовалась. Ну а уже после создания и повсеместного использования шаблона ТЗ чек-лист стал дополнением.
Спасибо за интересный коммент, есть над чем задуматься и порассуждать)
ТЗ в мире разработки ИС - вполне конкретный вид документа, формализован в различных методиках, стандартах.
Согласна с этим утверждением. Есть и стандарты ГОСТ по разработке, и внутренние корпоративные стандарты компаний, которые говорят нам о том, что должно быть описано в таком документе. И в данном случае ТЗ – это действительно синоним описания постановки на разработку.
В моей статье речь про исследование до написания ТЗ/постановки и про проверку некоторых пунктов, которые мы потом формализуем в документе ТЗ или в описании постановки на разработку.
Например, тот же самый пункт про требования на доработку на разных устройствах – было немало задач, когда функциональность нужна была только на одном устройстве, или наоборот, когда заказчик озвучивал требование только для одного устройства, бизнес-аналитик фиксировал это в БТ, а потом (уже после разработки) выяснилось, что надо было сделать на всех устройствах. Конечно, можно было сказать «этого не было в БТ», «что заказали, то и сделали», но если можно предусмотреть и исключить такие ситуации до разработки, то почему бы это не сделать?
Таким образом, я говорю о том, что чек-лист помогает сократить кол-во ошибок в постановках, помогает валидировать как БТ и требования заказчика, так и ТЗ/постановки коллег. Валидировать на предмет таких ситуаций, как:
действительно ли заказчик озвучил то, что ожидает от разработки
действительно ли бизнес-аналитик правильно зафиксировал это в БТ
действительно ли в постановке на разработку учтено всё, что покроет ожидания заказчика
странно видеть в чек-листе то, что должно быть описано (формализовано) до постановки на разработку.
В этом как раз нет ничего странного) Чек-лист и есть тот самый формализованный список того, что мы должны учитывать до разработки. Именно он помогает не забывать указывать в ТЗ/постановках то, что ожидает заказчик. И именно он помогает избежать багов и наличия CR, когда в разработке участвует несколько команд или даже подразделений (в случае с интеграционными задачами).
Различные стандарты и методологии документирования – тоже хорошо, но в данной ситуации, когда я только устраивалась в X5 Tech, они не покрывали всех моих потребностей для написания таких постановок, которые бы учитывали все нюансы нашей корпоративной системы и особенностей разработки. Поэтому и был сформирован такой чек-лист, которым я решила поделиться.
Резюмируя:
ТЗ в данном случае – синоним постановки на разработку;
чек-лист – формальное описание того, что должно быть учтено до разработки;
и такое формальное описание позволяет валидировать документы (БТ/ТЗ/описания постановок на разработку) и/или бизнес-требования на предмет того, чтобы результат разработки закрывал потребности и ожидания заказчика.
да, этот шаг у нас уже пройден) чек-лист создавался еще в те времена, когда шаблоном я не пользовалась. Ну а уже после создания и повсеместного использования шаблона ТЗ чек-лист стал дополнением.
Спасибо за интересный коммент, есть над чем задуматься и порассуждать)
Согласна с этим утверждением. Есть и стандарты ГОСТ по разработке, и внутренние корпоративные стандарты компаний, которые говорят нам о том, что должно быть описано в таком документе. И в данном случае ТЗ – это действительно синоним описания постановки на разработку.
В моей статье речь про исследование до написания ТЗ/постановки и про проверку некоторых пунктов, которые мы потом формализуем в документе ТЗ или в описании постановки на разработку.
Например, тот же самый пункт про требования на доработку на разных устройствах – было немало задач, когда функциональность нужна была только на одном устройстве, или наоборот, когда заказчик озвучивал требование только для одного устройства, бизнес-аналитик фиксировал это в БТ, а потом (уже после разработки) выяснилось, что надо было сделать на всех устройствах. Конечно, можно было сказать «этого не было в БТ», «что заказали, то и сделали», но если можно предусмотреть и исключить такие ситуации до разработки, то почему бы это не сделать?
Таким образом, я говорю о том, что чек-лист помогает сократить кол-во ошибок в постановках, помогает валидировать как БТ и требования заказчика, так и ТЗ/постановки коллег. Валидировать на предмет таких ситуаций, как:
действительно ли заказчик озвучил то, что ожидает от разработки
действительно ли бизнес-аналитик правильно зафиксировал это в БТ
действительно ли в постановке на разработку учтено всё, что покроет ожидания заказчика
В этом как раз нет ничего странного) Чек-лист и есть тот самый формализованный список того, что мы должны учитывать до разработки. Именно он помогает не забывать указывать в ТЗ/постановках то, что ожидает заказчик. И именно он помогает избежать багов и наличия CR, когда в разработке участвует несколько команд или даже подразделений (в случае с интеграционными задачами).
Различные стандарты и методологии документирования – тоже хорошо, но в данной ситуации, когда я только устраивалась в X5 Tech, они не покрывали всех моих потребностей для написания таких постановок, которые бы учитывали все нюансы нашей корпоративной системы и особенностей разработки. Поэтому и был сформирован такой чек-лист, которым я решила поделиться.
Резюмируя:
ТЗ в данном случае – синоним постановки на разработку;
чек-лист – формальное описание того, что должно быть учтено до разработки;
и такое формальное описание позволяет валидировать документы (БТ/ТЗ/описания постановок на разработку) и/или бизнес-требования на предмет того, чтобы результат разработки закрывал потребности и ожидания заказчика.