Качественный субъективизм

Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.

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

В общем, все молодцы, а на выходе какашка. Нормальный процесс переработки сырого продукта.

И да, отмечу, фраза «каждый легко найдёт оправдания и объяснит, почему налажал не он» не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.

Я как аналитик сделал всё возможное: проанализировал ожидания и возможности, проконсультировался с инженерами. Несколько раз скорректировал требования по мере проявления нюансов.

Я как разработчик реализовал требования в архитектуре и коде насколько позволили уже существующие архитектура и код, а также время и личная смелость.

Я как тестировщик, проверил фичу, пришёл в ужас, зарепортил баги, бился за них, но треть багов умерли вонтфиксами. Часть потом переоткроется, как показывает опыт, но это потом. Ответственные лица решили, что баги не фатальные. С формальной точки зрения блокирующих проблем нет, тестирование — done.

Я как… Ой, а всё, никого ж не осталось. Релиз.

Я как руководитель RnD недоволен, что мне на совете директоров рассказывают про баги в продукте. Каждый из инженеров видел проблему, и никто её не починил (а то и не заметил).

В этой войне авторитетов «рядовой тестировщик» равно как и «рядовой разработчик» с формальной точки зрения не всегда может показать что продукт — ну не готов к использованию. Есть те, кто более равны и есть формальные требования.

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

Конечно, подобная оценка — прежде всего повод к разговору. Может я как тестировщик сгущаю краски. А может я как менеджер не могу сдвинуть релиз, зато могу подстелить соломку другим способом. Обсудим и решим, лишь бы важная информация о качестве продукта не потерялась. А личное впечатление, мнение работающего у нас инженера — это важно.

Полагаю, привносить эту субъективность можно по-разному, и разным командам/компаниям подойдут разные способы. Я лично знаком с системой Quality rating’ов, и сам видел, как она помогала. Если тестировщик поставил фиче оценку 2 из 5, вероятно с фичей что-то не так. Возможны и другие способы, но «техническая» реализация не суть важна. Важно дополнить формальные показатели живым ощущением сотрудника — тогда чуть больше шансов узнать реальное состояние продукта.

Всяко это лучше и полезней, чем пытаться понять, что таск-трекер может сказать о качестве продукта (QA квартирник Codefest’а, привет). Таки таск-трекер для задач, а качество для людей. Давайте у людей и спрашивать о качестве.

Рунглиш. Новояз. Жаргон.

Когда я впервые после учебы пришел работать в серьезную IT-компанию, мне, безусловно, пришлось учиться быстро и многому. И прежде всего мне пришлось учится понимать речь своих новых коллег. В первую неделю, натурально, я понимал от силы треть, когда ребята обсуждали между собой какие-то рабочие моменты. Общаясь со мной, они старались говорить попроще, но и тогда половина слов и их сочетаний оставались непонятными.

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

Профессиональный жаргон — дело не новое, и думаю большинство с ним сталкивалось в своей работе, а уж в сфере IT — просто все. Жаргон свойственен любой профессии; где-то его больше, где-то меньше. В IT обилие жаргона связано, на мой взгляд, прежде всего с тремя аспектами:

  1. Нет общения с посторонними. Чаще всего айтишники общаются с себе подобными. К ним не приходят люди с улицы заполнять бланки. Для общения с заказчиками зачастую есть специальный человек, и программисты, тестировщики и т.д. могут позволить себе речь отличающуюся от повседневной средней нормы чуть менее чем полностью.
  2. Высокий уровень абстракции. Айтишники работают с тем, что невозможно потрогать руками; в лучшем случае можно посмотреть на строчки кода или нарисовать диаграмму, записать последовательность действий или сделать скриншот. Поэтому в разговоре приходится либо оперировать длинными и сложнопроизносимыми понятиями, либо заменять их одинм словом, понятным далеко не всем. Обычно выбирается второе — так быстрее. Кстати, я тоже пишу «айтишники» вместо «люди, работающие в сфере информационных технологий» — по той же причине.
  3. Заимствование терминов. Многие термины и жаргонные слова, используемые айтишниками, заимствованы либо скалькированы из английского языка. Это понятный и естественный процесс: поскольку вся документация доступна прежде всего на английском языке, то зачастую проще использовать английский термин, чем придумывать или вспоминать адекватный перевод, причем еще неизвестно — поймет ли собеседник этот перевод. Так, в предыдущем абзаце я написал «скриншот», хотя мог бы написать «снимок экрана». Многие айтишники даже отказываются от использования русифицированных версий программ, ибо «мало ли, как они там в меню Options перевели».

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

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

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

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

Но на самом деле тут все несложно, нужно просто помнить о двух вещах: роли жаргона и личности собеседника. Основная роль жаргона, как уже упоминалось, ускорение коммуникации. Если сам жаргон начинает, наоборот, тормозить общение — значит нужно от него отказаться. А тормозить общение он начинает когда собеседник с этим жаргоном не знаком (или, тоже интересный вариант, знаком с похожим жаргоном, в котором употребляются схожие слова, вот только значения у них другие).

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

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

P.S. Конечно, жаргон порой используется и для других целей — подавления собеседника неизвестными терминами, демонстрации своей учености/крутости, укрывания сути проблемы за непонятным набором слов, и т.п. Я не хочу здесь останавливаться на этих моментах подробно, поскольку меня сейчас интересует конструктивное использование жаргона, а не борьба с его темными сторонами.