Кратко: ТЗ на английском для зарубежной команды требует трёх вещей, без которых внутренний документ может обойтись: глоссария, который задаёт один перевод для каждого бизнес-термина, критериев приёмки в форме, которую можно проверить без вопросов, и израильского раздела с тем, чего зарубежная команда не знает: теудат зеут с контрольной цифрой, НДС и номер распределения, рабочая неделя с воскресенья по четверг, иврит справа налево внутри английского интерфейса и Тиккун 13 к закону о защите приватности. Без этого раздела команда построит систему, правильную для другой страны.
Почему перевода мало
ТЗ, написанное на иврите для израильской команды, опирается на общий контекст. Когда написано «счёт», все понимают, что речь о налоговом счёте с НДС и что выше определённой суммы нужен номер распределения. Когда написано «неделя», все понимают, что она начинается в воскресенье. Зарубежная команда этого не знает и не спросит, потому что не знает, о чём именно нужно спрашивать.
Правило: всё, что в израильской команде понятно без слов, в ТЗ для зарубежной команды должно быть прописано.
Структура
Принятая структура англоязычных документов с требованиями опирается на IEEE 830 и ISO/IEC/IEEE 29148, и зарубежные команды с ней знакомы:
| Раздел | По-английски | Что пишут |
|---|
| Введение | Introduction: Purpose, Scope, Definitions | Цель, границы, что не входит, и глоссарий |
| Общее описание | Overall Description | Продукт, пользователи, ограничения и допущения |
| Требования | Specific Requirements | Пользовательские истории с критериями приёмки, модель данных, интеграции |
| Проверка | Verification | Как проверяется каждое требование и кто его утверждает |
| Приложения | Appendixes | Экраны, примеры файлов, израильский раздел |
Глоссарий: один перевод для каждого термина
Частая ошибка: один и тот же ивритский термин в документе переводят по-разному. «Клиент» становится то customer, то client, то account, и команда строит три сущности. Глоссарий закрепляет один перевод, и весь документ использует только его.
| Иврит | В документе по-английски | Примечание |
|---|
| עוסק מורשה | Licensed VAT dealer (osek murshe) | Ивритский термин тоже нужно оставить: он будет в интерфейсе и в документах |
| מספר הקצאה | Invoice allocation number | Номер, который налоговая выдаёт на счёт |
| חשבונית מס | Tax invoice | Не просто invoice |
| תעודת זהות | Israeli ID number (teudat zehut) | Девять цифр, включая контрольную |
Израильский раздел
Это раздел, который нужнее всего зарубежной команде и которого чаще всего нет. Что в него включить:
- Теудат зеут: девять цифр, с дополнением нулями слева и контрольной цифрой по алгоритму Luhn. Неверная проверка отклонит настоящих клиентов.
- НДС и счета: налоговый счёт, номер распределения для счетов выше порога, ставка НДС как параметр, а не число в коде.
- Рабочая неделя: с воскресенья по четверг, пятница короткий день, суббота выходной. Праздники начинаются вечером.
- Иврит в интерфейсе: направление справа налево, поля со смешанным ивритом и английским, числа внутри ивритского текста. Для полей ввода команде стоит указать автоматическое определение направления.
- Приватность: Тиккун 13 к закону о защите приватности, особенно что считается особо чувствительной информацией и у кого есть к ней доступ.
- Валюта и форматы: шекель, дата в формате день перед месяцем, адреса и индекс из семи цифр.
Критерии приёмки, по которым не надо спрашивать
Для каждого требования пишут критерий приёмки в форме Given, When, Then: дано состояние, когда происходит действие, тогда получается результат. Эту форму знают команды разработки и тестирования во всём мире, и она снимает вопрос «что именно вы имели в виду», который в зарубежной команде обычно возникает уже после того, как код написан.
Критерии приёмки израильского раздела стоит писать с настоящими тестовыми данными: корректный и некорректный номер теудат зеут, имя на иврите с английским словом внутри, дата, выпадающая на субботу.
Частые вопросы
Как написать ТЗ на английском?
По принятой структуре документов с требованиями: введение и границы с глоссарием, общее описание, детальные требования с критериями приёмки и проверка. Для зарубежной команды добавляют раздел о том, что специфично для Израиля.
Достаточно ли перевести ивритское ТЗ?
Нет. Перевод передаёт слова, но не то, что израильская команда понимает без подсказки: НДС и номер распределения, рабочая неделя, теудат зеут, иврит справа налево и приватность. Всё это нужно прописать явно.
Что такое глоссарий и зачем он нужен?
Это список, который закрепляет один перевод для каждого бизнес-термина. Без него один и тот же термин переводят по-разному, и команда строит несколько сущностей вместо одной.
Чего зарубежная команда разработки не знает об Израиле?
Что теудат зеут содержит контрольную цифру, что счёт выше определённой суммы требует номера распределения, что рабочая неделя начинается в воскресенье, что интерфейс должен поддерживать иврит справа налево, и что требует Тиккун 13 к закону о защите приватности.
В какой форме писать критерии приёмки?
В форме Given, When, Then, которую знают команды во всём мире, и с настоящими тестовыми данными для всего, что специфично для Израиля.
С чего начать
Выпишите десять самых важных бизнес-терминов вашей системы и рядом укажите перевод, которым сейчас пользуется зарубежная команда. Если у одного термина больше одного перевода, вы нашли первую проблему.
Написать мне
По теме: Образец технического задания, Разработка и внедрение CRM, IT-консалтинг