Не актуализировать ТЗ
Идеального ТЗ, учитывающего сразу все, не бывает в 99,9% случаев. Всегда есть что-то неучтенное, что в процессе разработки или тестирования изменяется или добавляется.
Актуализация ТЗ - это та самая вещь, на которую хочется сейчас забить, ведь аукнется оно в далеком будущем. Как правило, "далекое будущее" наступает довольно быстро, где-то на этапе тестирования вашего ТЗ, когда тестировщик будет заводить баги по неактуальному ТЗ, разработчик раздражаться от того, что ему приходится тратить время на объяснения, что так и надо было, а вы - пытаться лихорадочно вспомнить, что же вы в этом ТЗ писали.
Все изменения, о которых договорились в процессе разработки/тестирования, будь то это изменение логики или просто дописывание забытых требований, нужно актуализировать в ТЗ как можно скорее. А если к вам несколько раз пришли с фразой "поясни эту строчку", стоит сразу же подумать над переформулировкой.
Под "сразу" я не имею в виду бросить все дела и актуализировать ТЗ - тайм-менеджмент и переключение между задачами никто не отменял, но занести задачу "исправить ТЗ" в список дел и сделать ее как можно скорее все-таки нужно.
Но актуализировать тоже нужно с умом - бывает так, что в итоговом документе черт ногу сломит. Например, я часто встречаю такие способы:
- Писать внутри ТЗ после старого требования в скобках новое:
передавать параметр a (26.06 договорились передавать параметр b)
- Упоминать человека, с которым договорились. Если вам очень надо запомнить, напишите это в комментарии куда-нибудь, иначе ТЗ превращается в список сотрудников
передавать параметр b (согласовано с Ivanov Ivan)
- Просто копировать переписку из месссенджера или почты, в которой что-то изменялось, в конец ТЗ (это верх лени, на мой взгляд):
Ivan: а давай передавать параметр b вместо a?
Fedor: а давай.
- Вариация копирования переписки: вставлять в конце или после каждого требования FAQ из всего того, что спрашивали в процессе разработки или по конкретно этому требованию.
- Передавать туда-то сумму.
FAQ:
- В каком параметре передается сумма?
- В параметре b
Я считаю, что между обычным ТЗ и актуализированным ТЗ не должно быть разницы в оформлении. Единственное, что может меняться - версионность ТЗ и комментарии, что изменилось, к каждой версии.
PS. Я не знаю, как это работает в организациях, где ТЗ отдается аутсорсу без возможности поменять, или каждое изменение согласовывается десятью печатями. Но, сдается мне, и там аналитику нужно держать у себя актуальную версию.
Идеального ТЗ, учитывающего сразу все, не бывает в 99,9% случаев. Всегда есть что-то неучтенное, что в процессе разработки или тестирования изменяется или добавляется.
Актуализация ТЗ - это та самая вещь, на которую хочется сейчас забить, ведь аукнется оно в далеком будущем. Как правило, "далекое будущее" наступает довольно быстро, где-то на этапе тестирования вашего ТЗ, когда тестировщик будет заводить баги по неактуальному ТЗ, разработчик раздражаться от того, что ему приходится тратить время на объяснения, что так и надо было, а вы - пытаться лихорадочно вспомнить, что же вы в этом ТЗ писали.
Все изменения, о которых договорились в процессе разработки/тестирования, будь то это изменение логики или просто дописывание забытых требований, нужно актуализировать в ТЗ как можно скорее. А если к вам несколько раз пришли с фразой "поясни эту строчку", стоит сразу же подумать над переформулировкой.
Под "сразу" я не имею в виду бросить все дела и актуализировать ТЗ - тайм-менеджмент и переключение между задачами никто не отменял, но занести задачу "исправить ТЗ" в список дел и сделать ее как можно скорее все-таки нужно.
Но актуализировать тоже нужно с умом - бывает так, что в итоговом документе черт ногу сломит. Например, я часто встречаю такие способы:
- Писать внутри ТЗ после старого требования в скобках новое:
передавать параметр a (26.06 договорились передавать параметр b)
- Упоминать человека, с которым договорились. Если вам очень надо запомнить, напишите это в комментарии куда-нибудь, иначе ТЗ превращается в список сотрудников
передавать параметр b (согласовано с Ivanov Ivan)
- Просто копировать переписку из месссенджера или почты, в которой что-то изменялось, в конец ТЗ (это верх лени, на мой взгляд):
Ivan: а давай передавать параметр b вместо a?
Fedor: а давай.
- Вариация копирования переписки: вставлять в конце или после каждого требования FAQ из всего того, что спрашивали в процессе разработки или по конкретно этому требованию.
- Передавать туда-то сумму.
FAQ:
- В каком параметре передается сумма?
- В параметре b
Я считаю, что между обычным ТЗ и актуализированным ТЗ не должно быть разницы в оформлении. Единственное, что может меняться - версионность ТЗ и комментарии, что изменилось, к каждой версии.
PS. Я не знаю, как это работает в организациях, где ТЗ отдается аутсорсу без возможности поменять, или каждое изменение согласовывается десятью печатями. Но, сдается мне, и там аналитику нужно держать у себя актуальную версию.