О единой терминологии
Всегда, когда заходит речь о создании новой фичи, продукта и т.д, в первую очередь говорят, что надо установить единую терминологию среди всех участников процесса.
Простой пример: на собеседовании вы говорите, что рассчитываете на такой-то размер зарплаты, и эйчар радостно соглашается. Когда вы выходите на работу, выясняется, что вы имели в виду размер зарплаты после вычета налогов, а эйчар - до. А все потому, что вы не утрясли терминологию заранее.
То же самое с продуктом: если заказчик подразумевает под "вывести сумму" вывести сумму с учетом налога, а вы - без, и никто не установил единое понимание слова "сумма" заранее, то на выходе будут проблемы.
Но терминологии на словах недостаточно. Мало кто понимает, что в наименовании параметров, в протоколах разных сервисов одни и те же названия параметров должны означать одинаковые вещи, а в идеале отражать бизнес-терминологию.
Пример с той же суммой: В протоколе одного сервиса у вас есть параметры sum и sumWithTaxes, в протоколе другого - sum и sumWithoutTaxes. С огромной вероятностью в какой-то момент в процессе интеграции между сервисами разработчик/аналитик установит аналогию sum=sum, а не sum=sumWithoutTaxes. С такой же огромной вероятностью аналитик, работающий с командой первого сервиса, придя с вопросом "проверьте сумму" ко второй команде, получит не ту информацию, которая была нужна.
Установление единой терминологии больше относится к области ответственности аналитиков, а наименование параметров - к области разработчиков, но в целом, если уже на первом этапе заметна такая проблема, лучше обратить на это внимание команд.
Всегда, когда заходит речь о создании новой фичи, продукта и т.д, в первую очередь говорят, что надо установить единую терминологию среди всех участников процесса.
Простой пример: на собеседовании вы говорите, что рассчитываете на такой-то размер зарплаты, и эйчар радостно соглашается. Когда вы выходите на работу, выясняется, что вы имели в виду размер зарплаты после вычета налогов, а эйчар - до. А все потому, что вы не утрясли терминологию заранее.
То же самое с продуктом: если заказчик подразумевает под "вывести сумму" вывести сумму с учетом налога, а вы - без, и никто не установил единое понимание слова "сумма" заранее, то на выходе будут проблемы.
Но терминологии на словах недостаточно. Мало кто понимает, что в наименовании параметров, в протоколах разных сервисов одни и те же названия параметров должны означать одинаковые вещи, а в идеале отражать бизнес-терминологию.
Пример с той же суммой: В протоколе одного сервиса у вас есть параметры sum и sumWithTaxes, в протоколе другого - sum и sumWithoutTaxes. С огромной вероятностью в какой-то момент в процессе интеграции между сервисами разработчик/аналитик установит аналогию sum=sum, а не sum=sumWithoutTaxes. С такой же огромной вероятностью аналитик, работающий с командой первого сервиса, придя с вопросом "проверьте сумму" ко второй команде, получит не ту информацию, которая была нужна.
Установление единой терминологии больше относится к области ответственности аналитиков, а наименование параметров - к области разработчиков, но в целом, если уже на первом этапе заметна такая проблема, лучше обратить на это внимание команд.