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