ТЗ, которое может понять только разработчик
Бывает так, что ТЗ пишет бывший разработчик. Или аналитик, который сильно залезает в код. И тогда, грубо говоря, вместо
Из пришедшего запроса на оплату (v1/payment) сохранять сумму и валюту (параметры am и c_iso)
получается что-то такое:
Из пришедшего запроса v1/payment сохранить параметры am и c_iso в базу transaction_card, в колонки a и b
Вариаций на эту тему много: пишут про ключи, объекты, контейнеры, мне недавно попалось "чайлдом должен быть label. Обеспечивает single-select" (я до сих пор не понимаю, что в контексте ТЗ обозначает эта загадочная фраза). И бывают менее распространенные варианты этой ошибки, например, ТЗ "от бухгалтера бухгалтеру" - вставлять вместо формул слова "посчитать сальдо", "от маркетолога маркетологу" и т.д.
Чем это плохо:
Во-первых, ТЗ читают не только разработчики, но и остальные члены команды: менеджеры, другие аналитики и т.д. А еще приходят новые сотрудники. Всем этим людям важно понимать суть, а не распутывать клубок из названий БД и колонок, и это еще хорошо, если названия говорят сами за себя, но бывает так, что само название плохое: база называется tr_1, пришедший параметр валюты не currency, a c_iso и т.д. Поди потом догадайся, что действительно происходит в этом ТЗ, не дернув автора ТЗ, что c_iso - это валюта.
Во-вторых, такое ТЗ быстрее устаревает. Названия параметров могут меняться, колонки переименовываться - особенно на начальной стадии разработки. Если не успевать менять ТЗ (а его в таком случае не успевают обычно менять), то в будущем вы не сможете ни понять, что тут происходит, ни разобраться с помощью разработчика.
Как от этого избавляться: самое простое - попросить коллег прочитать ваше ТЗ (желательно тех, кто не знает, как работает конкретно эта часть системы) и сказать, все ли им понятно.
Бывает так, что ТЗ пишет бывший разработчик. Или аналитик, который сильно залезает в код. И тогда, грубо говоря, вместо
Из пришедшего запроса на оплату (v1/payment) сохранять сумму и валюту (параметры am и c_iso)
получается что-то такое:
Из пришедшего запроса v1/payment сохранить параметры am и c_iso в базу transaction_card, в колонки a и b
Вариаций на эту тему много: пишут про ключи, объекты, контейнеры, мне недавно попалось "чайлдом должен быть label. Обеспечивает single-select" (я до сих пор не понимаю, что в контексте ТЗ обозначает эта загадочная фраза). И бывают менее распространенные варианты этой ошибки, например, ТЗ "от бухгалтера бухгалтеру" - вставлять вместо формул слова "посчитать сальдо", "от маркетолога маркетологу" и т.д.
Чем это плохо:
Во-первых, ТЗ читают не только разработчики, но и остальные члены команды: менеджеры, другие аналитики и т.д. А еще приходят новые сотрудники. Всем этим людям важно понимать суть, а не распутывать клубок из названий БД и колонок, и это еще хорошо, если названия говорят сами за себя, но бывает так, что само название плохое: база называется tr_1, пришедший параметр валюты не currency, a c_iso и т.д. Поди потом догадайся, что действительно происходит в этом ТЗ, не дернув автора ТЗ, что c_iso - это валюта.
Во-вторых, такое ТЗ быстрее устаревает. Названия параметров могут меняться, колонки переименовываться - особенно на начальной стадии разработки. Если не успевать менять ТЗ (а его в таком случае не успевают обычно менять), то в будущем вы не сможете ни понять, что тут происходит, ни разобраться с помощью разработчика.
Как от этого избавляться: самое простое - попросить коллег прочитать ваше ТЗ (желательно тех, кто не знает, как работает конкретно эта часть системы) и сказать, все ли им понятно.