Два правила адаптации новых сотрудников

Первое: каким объемом задач вы изначально нагрузите сотрудника, такой он и будет выполнять все оставшееся время. Это значит, что, давая сотруднику в первые дни работать не в полную силу, он сочтет это за норму и будет очень сложно повысить его эффективность в будущем, а если перегрузить -- вы рискуете сотрудника загнать и потерять.

Второе правило, которое отлично дополняет первое: то, на чем вы сконцентрируете внимание сотрудника, и будет для него самым важным в компании. Если вы с первых дней постараетесь донести до него цели, задачи, основные принципы компании -- будьте уверены, что при выполнении работы он будет ориентироваться на них и в случае чего сможет выйти за рамки своих обязанностей. А если вы покажете только то, как заполнять поля в эксельке, то ничего шире этих полей сотрудник, скорее всего, не увидит.

Сегодня нашла для вас две отличных статьи:

1. Объясняем дедушке чендж и дизайн-мышление
Вообще у меня уже был пост про "проклятие знания" и умение объяснить сложное простыми словами. Эта статья - пример отличного объяснения. Узнаете принципы дизайн-мышления, что такое ран, чендж и как использовать их в работе.

Прочитать можно здесь

2. Определяемся с карьерным путем
Перевод статьи Тима Урбана про то, как разобраться в себе, определить свои желания и понять, что для вас приоритетнее, а чем можно пожертвовать. Статья длинная (поделенная аж на 3 части), но при этом читается быстро и легко. А Тим Урбан - это тот человек, который выступил на TED с веселым рассказом о прокрастинации (если кто не видел, то вот)

Здесь оригинал, а вот здесь перевод

Про вычисления и нос китайского императора

Есть одна задачка про китайского императора, которая звучит так: никому не позволяется видеть китайского императора. Спрашивается, какой длины нос у китайского императора? Чтобы это выяснить, предлагается обойти всю страну и у каждого жителя спросить, что он думает о длине носа императора. В итоге вы посчитаете какое-то среднее арифметическое, услышав гигантское множество мнений, но к сожалению, таким способом ничего не узнаешь. Среднее арифметическое, выведенное из даже очень широкого диапазона мнений незаинтересованных и невнимательных людей, не улучшает вашего понимания ситуации.

Взяла из "Вы, конечно, шутите, мистер Фейнман", и к чему это я? Ну, например, к тщательному выбору фокус-группы при опросах.

Есть ли у меня в читателях продакт-менеджеры или те, кто тесно связан с развитием продукта? Какие книги/курсы вы посоветовали бы начинающему продакту, чтобы обрести понимание профессии и приобрести знания, достаточные для старта в этой области?

Нашла несколько подборок, но хочу услышать ваше мнение - потом опубликую список из наиболее рекомендуемых книг. Напишите, пожалуйста, свой список мне в личные сообщения - @shenzzzi.

На пост выше про книги для продакт-менеджера откликнулось не очень много людей, так что я поменяю тактику: соберу рекомендации по интернету и знакомым продактам, поэтому с выходом списка рекомендаций придется немного подождать.

Тем не менее коротко расскажу про несколько книг, которые прочитала с начала года #ap_книги:

Scrum. Революционный метод управления проектами
Автор: Джефф Сазерленд, разработчик методологии Scrum. Книга легкая, интересная, то, что нужно, чтобы вместе с автором пройти путь создания методологии и понять, почему в ней все так, а не иначе.
Читать всем, кто работает с применением гибких методологий (даже если это не Scrum - полезно для общего развития), и тем, кто не знает, но хочет быть больше в теме -- да хотя бы для того, чтобы уверенней отвечать на вопросы на собеседованиях.

Deadline. Роман об управлении проектами
Автор: Том Демарко. Если устали от скучных бизнес-книжек, которые сложно читать, а совесть не позволяет затормозить свое развитие и переключиться на развлекательное чтиво, то выбирайте эту книгу. Автор придумал историю одного менеджера, которому позволили поставить эксперименты над ведением проектов, и по ходу продвижения проектов рассказывает основные принципы менеджмента. Очень много в книге уделяется тому, что надо любить свою команду и сотрудников. Девушек особенно порадует, что гугл говорит, что жанр этого произведения - любовный роман, хотя это, конечно же, не так: любовная линия там совсем уж маленькая. Если мало времени, то читайте конец каждой главы, там в нескольких предложениях сформулирована суть.
Читать менеджерам (особенно начинающим) и тимлидам команд.

Искусство объяснять
Автор: Ли ЛеФевер, основатель и главный специалист компании CommonCraft, которая специализируется как раз на объяснениях: они снимают видеоролики, объясняющие ценность продукта. Знаете ведь, что, если вы не можете объяснить что-то сложное простыми словами, то значит, вы сами до конца не понимаете предмет объяснения? А можете ли вы сказать, из чего состоит хорошее объяснение?
Читать всем.

Impact Mapping
Автор: Гойко Аджич -- It-консультант из Великобритании. Книга о технике построения карт влияний для перехода от разработки по принципу "делаем так, потому что так захотелось" к "делаем так, потому что это решает такую-то проблему". Если кратко, то карту строят, опираясь на четыре вопроса: Почему? (наши цели) Кто? (заинтересованные лица) Как? (юзер-кейсы) Что? (конкретные фичи). Позволяет руководству принимать более осознанные решения при разработке функционала: сначала определяется, зачем делаем, потом -- как делаем.
Читать менеджерам, продуктологам, тимлидам команд, чтобы принимать решения о новых фичах более осознанно.

Вторая часть, если нравится такой формат, будет позже, иначе посты получаются слишком длинными.

Во время общения с авторами продуктовых каналов мне скинули отличную ссылку на подборку книг для продактов и предпринимателей. Там нигде не написано, но говорят, что подборку сделали ребята из SkyEng.

Не знаю, как рейтинг строился, но думаю, что ориентироваться на него можно, потому что книги, входящие в первые 100, действительно часто рекомендуют.
Последние два столбца - это сортировка, For Entrepreneurs - для предпринимателей, For Product Managers - для продакт-менеджеров.

Сама подборка здесь

#ap_книги Вторая часть из интересных книг, которые я прочитала в этом году:

Сердце компании
Автор: Патрик Ленсиони (эти знаменитые "5 пороков команды", "Смерть от совещаний")
В описании написано: если у вас есть возможность прочитать только одну бизнес-книгу в год, то это должна быть именно "Сердце компании". Полностью с этим согласна, но только если вы топ-менеджер, руководитель большой команды или CEO.
Книга о том, как "оздоравливать компанию" - определяться с миссией, ценностями и ключевыми целями компании, добиться "взгляда в одном направлении" от всей команды топ-менеджмента, а далее - спустить это направление до сотрудников, вдохновить их и таким образом избавиться от сплетен и интриг (ведь когда все прозрачно, таких вещей в компании минимум).
Это книга с минимумом воды, практически пошаговая инструкция с примерами из практики.
Кому читать: как я уже написала выше, CEO, топ-менеджерам и руководителям больших команд.

Вальсируя с медведями
Авторы: Том ДеМарко (написавший Deadline), Тимоти Листер
Каюсь, я ее не дочитала, но в целом впечатление уже составила и оно очень приятное. Книга про управление рисками в проектах (о том, какие риски вообще бывают, как их выявить и начать). Основная мысль: Надеяться, что риск не случится, значит этим риском не управлять. Менеджер, который понадеялся, что "пронесет" и завершил проект успешно, виноват не менее, чем менеджер, который понадеялся на "повезет" и проект провалил. В следующий раз может и не повезти.
Кому читать: менеджерам проекта, особенно начинающим.

Никогда-нибудь
Автор: Елена Резанова, карьерный консультант
Книга, которая немного выбилась из моего списка прочитанного тем, что она просто о том, как понять, чего вы хотите (в карьере), как отличить это от "ложных мечт" и начать действовать. Например, если вы мечтаете о том, что будете инструктором по серфингу на Бали, это еще не значит, что вы действительно этого хотите. В 90% случаев это значит, что вы просто устали от вашей текущей деятельности и кажется, что сбежать в диаметрально противоположное занятие - лучший выход. В целом ничего особенного, она просто позитивная.
Кому читать: тем, кто хочет сменить профессию. Или просто если хочется немного почитать про то, как правильно что-то менять в жизни.

Наука общения
Автор: Ванесса Ван Эдвардс, основатель лаборатории The Science of People, исследующей поведение людей
О том, как производить хорошее впечатление и находить подход к людям. Делится на три части: первые  5 секунд, первые 5 минут и первые 5 дней. Зацепило с первых страниц тем, что не предлагает пересиливать свой тип общения - если вы не душа компании и не любите тусовки на огромное количество людей, то и не надо, общайтесь правильно с глазу на глаз.
Я даже на рассылку Ванессы после этой книги подписалась и с удовольствием ее читаю.
Кому читать: всем - для общего развития, ну и чтобы приятных в общении людей в мире стало больше.

Есть много книг, которые меня каким-то образом не зацепили, но не хочу их "не советовать" - каждому свое. Для себя я придерживаюсь правила, которое вычитала уже не помню где: если за 20-40 страниц книга не зацепила, то читать ее не стоит. Оно относится в основном к художественной литературе, но сейчас и бизнес-книги написаны так, что их приятно читать. Конечно, на все техническое это все не действует, и порой приходится себя пересиливать, чтобы дочитать. Не верю, что, например, первые 20 страниц Виггерса могут зацепить :)

К посту выше от подписчика прилетела поправка, что я опечаталась - в науке общения части делятся на "5 минут, 5 часов, 5 дней". Но книга все равно отличная, читайте)

Обещанную подборку книг для начинающих продакт-менеджеров, которую я обещала, мы вместе с Нетологией оформили в статью на Хабре

И большое спасибо вам за отзывы! В топ рекомендаций попали книги от Intercom, а также практически все посоветовали курс Олега Якубенкова GoPractice.

И на этой хорошей ноте завершаю получившуюся неделю книжных рекомендаций.

Раз канал аналитический, поговорим наконец и про ТЗ (техническое задание, мало ли кто не знает).

Хорошее ТЗ, вопреки тому, что иногда думают, должно быть просто понятным. Понятным не только автору, но и любому человеку в команде, который его прочитает.
По моему опыту есть разные вещи, которые это ТЗ портят, поэтому давайте стартуем цикл мини-заметок о том, как НЕ надо писать ТЗ.

ТЗ, которое может понять только разработчик

Бывает так, что ТЗ пишет бывший разработчик. Или аналитик, который сильно залезает в код. И тогда, грубо говоря, вместо

Из пришедшего запроса на оплату (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 - это валюта.

Во-вторых, такое ТЗ быстрее устаревает. Названия параметров могут меняться, колонки переименовываться - особенно на начальной стадии разработки. Если не успевать менять ТЗ (а его в таком случае не успевают обычно менять), то в будущем вы не сможете ни понять, что тут происходит, ни разобраться с помощью разработчика.

Как от этого избавляться: самое простое - попросить коллег прочитать ваше ТЗ (желательно тех, кто не знает, как работает конкретно эта часть системы) и сказать, все ли им понятно.

Принимать в ТЗ разработческие решения, будучи аналитиком

Один из самых спорных и часто задаваемых вопросов - это "насколько глубоко аналитик должен погружаться в техническую часть при написании ТЗ?". Документы и уровень погружения аналитика бывает разный и зависит всегда от того, что принято в компании: где-то аналитик пишет совсем верхнеуровневые бизнес-требования, где-то углубляется на уровень протокола, а где-то прописывает за разработчика взаимосвязи между компонентами и схему БД.

В слишком глубокий уровень я отношу: архитектуру системы (включая решения про синхронность-асинхронность, если решение не продиктовано какой-то реальной бизнес-необходимостью), взаимодействие между компонентами (передача событий, шины, обработка технических исключений), структура БД, наименования таблиц, колонок и т.д.

Лично мне нравится такая точка зрения: если вы компетентнее разработчика (например, вы N лет были крутым архитектором, а теперь аналитик в каком-то стартапе, где все делается джунами на коленке), то вы можете внутри ТЗ расписать техническое решение. Если нет, то даже не пытайтесь.

Три причины сказать себе "стоп", когда ТЗ становится слишком техническим:
- В 99% случаев аналитик в этом плане НЕ компетентнее разработчика
- Бывает так, что младший разработчик делает все, как написано в ТЗ вместо совета старшего товарища, а на ревью ему прилетает про "кто вообще тебе так сказал делать" (я видела такие случаи, и см. первый пункт)
- Разработчики в большинстве своем придерживаются точки зрения, что такие ТЗ расхолаживают и отучают думать самих разработчиков

Писать не по шаблону, принятому в команде

В каждой компании есть свои правила оформления ТЗ, и не важно, какие конкретно - кто-то пишет по ГОСТУ, кто-то вставляет информацию для тестирования, а кто-то нет, важно одно: внутри одного проекта все ТЗ должны быть оформлены по максимуму одинаково для удобства тех, кто их читает.

Можно провести аналогию с конвейером: представьте, что вы собираете детские пирамидки. Перед вами стоит лента, по которой в определенной последовательности проезжают кольца для пирамидки: от самого большого до самого маленького, затем снова самое большое - уже для новой. Вы просто механически берете и каждое насаживаете на палку для пирамидки в той последовательности, в которой они приезжают, и вам не нужно сравнивать их размеры. А теперь представьте, что конвейер выдает вам все кольца в разной последовательности: сначала вам придется дождаться всех колец, потом сравнить их по размеру, и только потом собрать пирамидку. На сколько % упадет ваша скорость сбора пирамидок в этом случае?

То же самое с ТЗ: когда остальная команда вынуждена искать ссылку на протокол то в начале, то в конце документа, или тестировщик видит сценарии то в начале, то в середине - это повышает вероятность того, что многие пункты из ТЗ будут просто пропущены или вас достанут вопросами "а где это находится".

Поэтому, если по какой-то причине вы пишете не по шаблону:
- Если есть на то адекватные причины, обсудите с теми, кто пишет ТЗ и поменяйте общий шаблон ,чтобы все писали по-новому. Покажите остальным участникам команды, где были изменения.
- Если стандартный шаблон не подходит (задача слишком необычная), то напишите не по шаблону, но лучше всего в дальнейшем сесть с разработчиком, тестировщиком и пройтись с ними по ТЗ, чтобы убедиться, что все моменты поняты.
- Если нет адекватных причин и вы просто привыкли писать по-другому, отвыкайте.

Если у вас в команде нет единого стандарта описания, шаблона ТЗ - самое время его завести.

Не актуализировать ТЗ

Идеального ТЗ, учитывающего сразу все, не бывает в 99,9% случаев. Всегда есть что-то неучтенное, что в процессе разработки или тестирования изменяется или добавляется.

Актуализация ТЗ - это та самая вещь, на которую хочется сейчас забить, ведь аукнется оно в далеком будущем. Как правило, "далекое будущее" наступает довольно быстро, где-то на этапе тестирования вашего ТЗ, когда тестировщик будет заводить баги по неактуальному ТЗ, разработчик раздражаться от того, что ему приходится тратить время на объяснения, что так и надо было, а вы - пытаться лихорадочно вспомнить, что же вы в этом ТЗ писали.

Все изменения, о которых договорились в процессе разработки/тестирования, будь то это изменение логики или просто дописывание забытых требований, нужно актуализировать в ТЗ как можно скорее. А если к вам несколько раз пришли с фразой "поясни эту строчку", стоит сразу же подумать над переформулировкой.

Под "сразу" я не имею в виду бросить все дела и актуализировать ТЗ - тайм-менеджмент и переключение между задачами никто не отменял, но занести задачу "исправить ТЗ" в список дел и сделать ее как можно скорее все-таки нужно.

Но актуализировать тоже нужно с умом - бывает так, что в итоговом документе черт ногу сломит. Например, я часто встречаю такие способы:
- Писать внутри ТЗ после старого требования в скобках новое:
передавать параметр a (26.06 договорились передавать параметр b)

- Упоминать человека, с которым договорились. Если вам очень надо запомнить, напишите это в комментарии куда-нибудь, иначе ТЗ превращается в список сотрудников
передавать параметр b (согласовано с Ivanov Ivan)

- Просто копировать переписку из месссенджера или почты, в которой что-то изменялось, в конец ТЗ (это верх лени, на мой взгляд):
Ivan: а давай передавать параметр b вместо a?
Fedor: а давай.

- Вариация копирования переписки: вставлять в конце или после каждого требования FAQ из всего того, что спрашивали в процессе разработки или по конкретно этому требованию.
- Передавать туда-то сумму.
FAQ:
- В каком параметре передается сумма?
- В параметре b

Я считаю, что между обычным ТЗ и актуализированным ТЗ не должно быть разницы в оформлении. Единственное, что может меняться - версионность ТЗ и комментарии, что изменилось, к каждой версии.

PS. Я не знаю, как это работает в организациях, где ТЗ отдается аутсорсу без возможности поменять, или каждое изменение согласовывается десятью печатями. Но, сдается мне, и там аналитику нужно держать у себя актуальную версию.

Шутки в ТЗ

Сегодня воскресенье, поэтому пост будет покороче. Реччь пойдет о таком странном явлении, как юмор в ТЗ.  Есть две вещи, о которых мне хотелось бы поговорить:
- Юмор
- Неформальный язык

Сейчас в компаниях, где ТЗ пишется "для своих", где все друг друга знают, многие начинают писать ТЗ так же, как и общаются, а именно: вставлять мемасики посередине ТЗ, шутки и чуть ли не анекдоты. Это, конечно, забавно, когда первый раз открываешь страницу, но когда перечитываешь ТЗ несколько раз, шуточка про то, с чем созвучен элемент экрана bottom sheet, начинает неимоверно раздражать. Как один и тот же анекдот, который рассказывают тебе каждый день, а ты вынужден его слушать. Если при этом я открыла ТЗ, чтобы найти нужную информацию, но информации нет, есть только вот это - автора хочется убить.

Пожалуйста, не надо так. Никогда так не надо.

Про неформальный язык в следующем выпуске, а ваши лайки и шаринг постов показывают, насколько интересна поднятая тема. Не стесняйтесь :)

Слишком формальное или слишком неформальное ТЗ

Есть слова-канцеляризмы, которые усложняют чтение ТЗ. Например, "В силу того, что ..., указанный выше элемент при нажатии должен функционировать согласно...". И да, такое нужно заменять на фразы проще - "при нажатии элемент должен подсвечиваться красным, потому что..". Главное - чтобы легко читалось.

Есть сленговые слова, которые раздражают. Не всех, наверное, но меня раздражает, к примеру, когда в списке участников проекта пишут "Вася aka заказчик". А т.к. это действительно не всем нравится, то стоит от них воздержаться.

И наконец, есть иностранные слова. Сейчас достаточно много заимствований, которые все понимают, но если перенасытить фразу англицизмами, есть шанс, что она будет истолкована неправильно (даже если вам кажется, что все очевидно). Тут нужна мера и понимание, какие слова все используют в вашей команде, а какие вызовут сложности.

На прошлой работе у меня был такой случай:
Один человек написал "необходимо провести ресерч". Потом пришел второй и поправил слово на "резерч". После передачи третьему сотруднику задача стала называться "необходимо провести резерв" и стало вообще непонятно, что происходит, пока в конце концов не поменяли на "исследование" :)

И как итог: все написанное в последних двух постах относится только к тем ТЗ, которые НЕ выходят наружу - там это все не так критично. Если аналитик позволяет себе допускать такое в ТЗ, которое читает кто-то, кроме "своих", то я бы задумалась о компетентности такого аналитика. Это как есть за столом: дома можно чавкать, а в гостях нет. Но, в принципе, и там, и там не стоило бы.

На самом деле мне кажется, что это все, что я хотела сказать про ТЗ, если не брать совсем очевидные вещи, как "полнота требований", "однозначность" и т.д.

Еще могу добавить, что лично мне не нравится, когда разделы ТЗ не нумеруют. Документ вида

Введение
...
Заключение

выглядит менее законченно, чем

1. Введение
...
4. Заключение

Зависит от шаблона, но бывает, что удобно нумеровать и сами требования (когда ТЗ длинное). А бывает и неудобно (когда ТЗ уменьшается на одну страницу). Например:

FR1. Сделать...
FR2. Сделать...

Плюс в том, что разработчик/тестировщик вместо "у тебя противоречие между фразами "..." и "..."" всегда может написать "у тебя противоречие в пунктах FR1 и FR2".

Еще хочу услышать ваши мнения по поводу ТЗ и собрать в пост: что вам кажется важным в написании ТЗ? Что нравится, а за что, наоборот, хочется выкинуть документ в мусорку?

Присылайте ваши случаи, примеры и мнения сюда - @shenzzzi

Еще раз про разграничение обязанностей

Пока собираю мнения по поводу ТЗ, хочу еще раз затронуть тему разграничения обязанностей. Я уже писала про это раньше (см. выше - должен ли аналитик принимать разработческие решения), но ситуации "принимаю решения вне своей компетенции" встречаются чаще и касаются не только ТЗ.

Пример: бывший разработчик перешел на должность менеджера, но никак не хочет снимать с себя принятие технических решений. Идет время, система меняется, он уже не кодит, но на совещаниях продолжает "представлять мнение разработчиков", предпочитая не звать тех, кто действительно сейчас занимается разработкой.

Принимаемые им решения часто опираются на то, "как было раньше" или "как я считаю". В итоге, если на совещании достигнута какая-то договоренность, в реальной жизни оказывается, что так нельзя, и чаще всего на этапе, где поменять что-либо означает большой сдвиг сроков. Теряются время, силы и терпение участников процесса, теряется доверие команды, а менеджер становится "тем козлом, который принимает решения за нас". Будут ли хорошие отношения в такой команде? Нет.

Правильный подход будет в том, что, даже если бывший разработчик разбирается в технических моментах лучше (или думает так), нужно спрашивать того, кто ответственен за разработку сейчас. В процессе обсуждения либо бывший разработчик докажет текущему, что так действительно лучше, либо текущий расскажет бывшему новые нюансы работы системы.

Что делать: переходя на новую должность, отпускайте от себя прошлые обязанности, учитесь делегировать и максимум - давать советы. Потому что, решая что-то за кого-то, вы и решения правильные рано или поздно перестанете принимать, и отношения с командой испортите.

По поводу ТЗ пришли два замечания:

Не приводить примеры в ТЗ

Да, желательно везде, где есть риск быть непонятым, приводить примеры. Они помогут разработчику проверить себя на этапе реализации, а тестировщику будет легче проверить итоговый функционал.

Особенно относится это к формулам сложнее, чем "2+2", алгоритмам и сложным условиям if-else.

Неграмотность в ТЗ

Могу только сказать свое мнение на этот счет:

- В том, что уходит вовне, все орфографические и грамматические ошибки надо исправлять и явно указывать на них автору. Считаю выходящие вовне документы с ошибками снижением репутации компании.
- В том, что читается только внутри, иногда стоит обращать внимание на ошибки. Иногда! Не нужно превращаться в поборника грамотности, который раздражает всех тем, что просит писать "кофе навынос" вместо "кофе на вынос"

Но в целом, если человек делает по ошибке в каждом слове, скорее всего, это коррелирует с тем, как он пишет код или документацию. Стоит также посмотреть, как человек реагирует на замечания в свою сторону и имеет ли желание исправиться: например, сложно научить человека писать "тся-ться" правильно, если он до сих пор этому не научился, но еще сложнее, если человек сознательно делает ошибки.

У меня, к примеру, был сотрудник, который писал "Тебе" с большой буквы, потому что считал это уважением к собеседнику, и никак не хотел от этого отказываться :)

О единой терминологии

Всегда, когда заходит речь о создании новой фичи, продукта и т.д, в первую очередь говорят, что надо установить единую терминологию среди всех участников процесса.

Простой пример: на собеседовании вы говорите, что рассчитываете на такой-то размер зарплаты, и эйчар радостно соглашается. Когда вы выходите на работу, выясняется, что вы имели в виду размер зарплаты после вычета налогов, а эйчар - до. А все потому, что вы не утрясли терминологию заранее.

То же самое с продуктом: если заказчик подразумевает под "вывести сумму" вывести сумму с учетом налога, а вы  - без, и никто не установил единое понимание слова "сумма" заранее, то на выходе будут проблемы.

Но терминологии на словах недостаточно. Мало кто понимает, что в наименовании параметров, в протоколах разных сервисов одни и те же названия параметров должны означать одинаковые вещи, а в идеале отражать бизнес-терминологию.

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

Установление единой терминологии больше относится к области ответственности аналитиков, а наименование параметров - к области разработчиков, но в целом, если уже на первом этапе заметна такая проблема, лучше обратить на это внимание команд.