Пересечение тестирования и архитектуры: интервью с Нилом Фордом
Что может значить должность «QA architect»? А что значит совсем уж непонятная должность «meme wrangler»? С какого момента при работе над архитектурой надо подключать тестировщиков? Как менять процессы в организации так, чтобы люди при встрече с первой же сложностью не возвращались к старым?
Нил Форд на своём сайте представляется тремя вариантами: «ThoughtWorker» (сотрудник компании ThoughtWorks, которую многие знают из-за Мартина Фаулера), «Software Architect» и «Meme Wrangler». Вскоре на нашей конференции Heisenbug он расскажет о создании «эволюционных архитектур», которые возможно менять при изменении внешних обстоятельств. А пока что мы расспросили Нила: и о том, как это пересекается с тестированием, и о многом другом.
— Можете для начала рассказать о себе и о своей карьере?
— Конечно. Я в ThoughtWorks почти 14 лет. До этого был техническим директором в небольшой фирме по консультированию и обучению, примерно из 25 человек, и там начал пробовать свои силы в технологиях вроде Java. Первые три книги я написал до того, как я присоединился к ThoughtWorks. Самая первая была о Delphi, на тот момент довольно популярном в России и в Европе.
Когда я был техническим директором, подустал быть альфа-гиком. Когда ты знаешь больше, чем люди вокруг, ты особо не развиваешься. Я начал выступать на множестве конференций, и мне очень понравилось находиться среди других спикеров, потому что они были очень умными и заинтересованными людьми. И я стал неосознанно подыскивать компанию, в которой бы в основном работали действительно умные и заинтересованные люди. И буквально споткнулся о ThoughtWorks, как и многие, на сайте Мартина Фаулера. По таким вещам, как CruiseControl и библиотека для тестирования NUnit, я заметил, что они делают огромный вклад в open source и делают много очень интересных вещей. И так я нечаянно начал процесс собеседования с ThoughtWorks, в конце которого получил предложение работы. Это было для меня хорошим шагом, потому что это очень умные и очень увлечённые разработчики.
Я мог бы быть независимым консультантом, но в этой роли мне не нравятся две вещи. Первая — ты должен сам заниматься всеми бизнес-делами: выставлять счета, гоняться за людьми ради денег, регулировать денежные потоки и всякое такое. Я способен этим заниматься, но меня это не увлекает. Моя страсть — программное обеспечение и разработка.
И второе: если ты независимый консультант, то тебе редко удаётся поработать в сотрудничестве с кем-то, в команде. Ты почти всегда сам по себе, а мне очень нравится командная разработка. Я даже несколько книг написал совместно с другими авторами, включая мою последнюю книгу «Эволюционная архитектура». Мне кажется, что при совместной работе результат получается большим, чем сумма отдельных составляющих. Когда ты сотрудничаешь в творческой работе, будь то писательский проект или программа, можешь получить больше точек зрения и более общее представление, поэтому и результат получится лучше.
Так что в апреле будет уже 14 лет, как я в ThoughtWorks. Я так хорошо знаю это, потому что одно из интересных преимуществ работы в ThoughtWorks — если ты проработал в компании 10 лет, получаешь 12-недельный оплачиваемый творческий отпуск, когда ты можешь делать всё, что угодно. А после этого каждые 5 лет получаешь 6-недельный оплачиваемый творческий отпуск, так что мне остался год до первого 6-недельного. 12-недельный мне очень понравился, и я предвкушаю следующий. Так что ты всегда помнишь, какой десяток лет ты уже здесь: они отмеряются такими приятными отпусками.
— Это очень ощутимая длина отпуска, круто.
— Я был нанят ThoughtWorks на должность архитектора и выполнял эту роль какое-то время, пока не перешёл на директорский уровень. Большая часть моей работы и сейчас относится к области архитектуры программного обеспечения, я провёл много времени на пересечении архитектуры и инженерных практик (например, continuous delivery) — подозреваю, что тут мои интересы пересекаются с интересами аудитории Heisenbug.
В частности, то, о чём я много говорил в последнее время — это тема моей самой последней книги, построение эволюционной архитектуры. Если ты можешь предотвратить появление багов, то людям, которые занимаются тестированием приложения, будет легче. Эволюционная архитектура включает в себя техники защиты для критических архитектурных свойств — типа развёртываемости, тестируемости, масштабируемости, производительности и так далее.
— А что значит «Meme Wrangler»?
— По правилам ThoughtWorks ты можешь выбрать любое название должности, кроме нескольких зарезервированных вроде «генеральный директор». Если придумаешь сам себе интересную должность, то пожалуйста. А когда кончится набор визиток, можно придумать новую.
Моей первой должностью было «архитектор приложений». Эта должность отражала суть работы, но очень часто в больших компаниях она подразумевает, что ты больше не приносишь особой пользы, что ты больше проводишь времени за рисованием картинок, чем за созданием чего-либо.
А одно из преимуществ разработки на заказ — то, что ты можешь знакомиться с большим количеством различных проектов. Архитекторы программного обеспечения, думаю, по своей природе такие «pattern matchers»: мы пытаемся применять паттерны ко всему, что видим, даже к вещам из реального мира. Так что, если ты архитектор в разработке на заказ, тебе доводится видеть множество разных проектов, ты видишь в них повторяющиеся паттерны, видишь, какие из них работают. И я понял, что, на самом деле, моя работа — что-то вроде сбора интересных идей из экосистемы программного обеспечения. Отсюда пошло «Meme Wrangler».
Meme (мем) — это термин, который придумал писатель Ричард Докинз, это широко распространённая единица для обозначения идей. Всем знакомы мемы из интернета — это некая остроумная штука, которая цепляет и распространяется как вирус. И у слова «wrangle» есть два полезных значения, первое — выступать судьёй в споре, а второе значение — «сгонять в стадо». И я выбрал себе должность Meme Wrangler, потому что это более точно отражает то, чем я сейчас занимаюсь. Более того, теперь, когда я выпускаю очередную книгу, я пишу в Твиттере, что «заарканил очередной мем» и поместил его в эту книгу.
— Можете пояснить, что должен делать архитектор программного обеспечения, чем вы занимаетесь как архитектор ПО?
— Конечно, я могу попробовать, но ни у кого особо не получается дать этому определение. Мартин Фаулер — человек, который очень круто умеет давать определения всему в области программирования — публично отказался давать определение термину «архитектор ПО» в своём тексте «Кому нужен архитектор?».
Но если посмотреть на роль архитектора ПО, то одна из вещей — они несут ответственность за всё то, что потом трудно изменить. Это всё, что связано со структурой вашей системы ПО: какие основополагающие паттерны вы будете использовать, какой язык или какие фреймворки. Потому что все эти решения несут далеко идущие последствия.
Одна из вещей, о которых архитекторы действительно очень сильно заботятся — то, что мы называем «архитектурными параметрами», ещё это называют «нефункциональными требованиями», но нам это название не нравится. Это такие вещи, как производительность, масштабируемость, эластичность, развёртываемость — всё это входит в зону ответственности архитектора. Архитектор может создать структуру, которая будет учитывать и требования по самой программе, и все эти архитектурные параметры, которые должны быть в ней обеспечены.
Предположим, вы архитектор и вам нужно создать структуру системы ПО для регистрации студентов в университете. Допустим, у нас есть тысяча студентов и 10 курсов, на которые они должны записаться. А теперь, основываясь на наших знаниях о том, как устроены университеты, как вы думаете, что произойдёт: студенты распределятся равномерно в течение семестра так, чтобы у нас получилось одинаковое количество студентов на каждом курсе, или они все будут тянуть до последнего часа, а потом ринутся записываться все разом?
А это эластичность, это архитектурный параметр, который вы должны обеспечить, когда делаете такую систему. Скорее всего, это нигде не указано, но вы это знаете, просто исходя из предметой области. Это то, что делает архитектуру систем ПО такой сложной: вам нужно понимать предметную область, а также технические возможности и ограничения вашей компании. Вы можете быть ограничены, например, тем, что уже выбрана эта реляционная база данных для стандарта нашей компании, а нам нужно сделать так, чтобы производительность при этом повысилась. Как мы можем добиться этих результатов?
В этом и заключается работа архитектора ПО — справляться со всеми этими важными решениями, связанными с тем, что имеет очень длительные последствия и что очень сложно изменить потом. Многие элементы структуры, такие, как пользовательский интерфейс, разработать довольно легко, потому что ты всего лишь меняешь один слой приложения. А архитектура — это больше про то, как все эти слои сопоставлены между собой, и обычно это гораздо сложнее изменить.
Говорят, что микросервисы сейчас довольно популярны, и такая архитектура создавалась именно с расчётом на постоянные изменения. Так что вносить серьёзные изменения в микросервисную структуру гораздо проще, но они такими были созданы изначально. И это очень интересная тема для исследования — как проектировать архитектуру, которую легко изменять, потому что для индустрии это именно то, с чем было больше всего сложностей на протяжении очень долгого времени.
— К вопросу об архитектуре и должностях: я всё чаще вижу на визитных карточках и в LinkedIn должность «архитектор QA».
— Это одна из проблем термина «архитектор»: каждой компании приходится изобретать свои названия для этого. Я встречал и «архитекторов QA», и «архитекторов данных», «архитекторов систем», «архитекторов решений», «технических архитекторов» — я встречал архитекторов всех возможных мастей. И это проблема, потому что никто не может дать чёткого определения, и дают то, какое хочется.
Что может значит «архитектор QA» для какой-то конкретной компании, я даже не знаю точно. Разрабатывает ли такой человек структуру QA? Как по мне, так это ближе к функции архитектора как техлида, потому что часто архитектор также является и техническим руководителем проекта. Но архитектор также занимается и презентацией, и документацией. Так что, если я архитектор и у меня появилась гениальная идея для новой архитектуры, но я не могу сделать презентацию и убедить людей с деньгами, что мы должны это сделать, то у нас не будет шанса воплотить мою крутую идею. Это означает навыки коммуникации.
Эти навыки применимы и к области QA, и того, кто это делает, тоже можно назвать «архитектор». Понимаете, это такая расплывчатая должность. Многие организации просто приходят к тому, что называют самого старшего инженера архитектором, потому что это круто звучит и они не могут придумать, как его ещё назвать. Типа, знаете, сениор-сениор-сениор разработчик — окей, архитектор. И я встречал компании, где есть один тип архитекторов, и я встречал компании, где есть десятки разновидностей архитекторов. По сути, это выдуманные должности. Моя «meme wrangler» в этом смысле лучше, потому что она очевидно выдуманная.
— Давайте поговорим в направлении вашего выступления на Heisenbug. Вы выступите на конференции по тестированию —, а что для вас самого качество ПО?
— Я лично рассматриваю качество архитектурных компонентов системы. Я знаю, что мир QA больше рассматривает ПО как чёрный ящик, то есть смотрит с позиции пользователя, нет ли там ошибок и сбоев, корректно ли оно функционирует. Безусловно, я тоже в этом заинтересован, но меня больше волнуют первопричины ошибок: почему приложение ненадёжно, почему оно периодически вылетает? Здесь я должен быть последним рубежом обороны, выясняя, из-за чего это происходит. И есть такие вещи, как производительность и отзывчивость. О них сейчас много разговоров в мире UI, у них есть чёткие показатели: если твой мобильный сайт загружает видимый контент дольше, чем 3 секунды, пользователи уйдут и перейдут куда-то ещё.
На веб-производительность обращают большое внимание: каково время до загрузки первого видимого контента, каково общее время загрузки страницы. И всё это параметры качества, которые безусловно видны с точки зрения стороннего наблюдателя, а я — тот, кто должен придумать, как мы построим систему, в которой такие показатели будут достигнуты. И это может повлечь изменения во фронтенде, касающиеся того, какие веб-технологии будут использованы, но также это может повлечь изменения и в бэкенде. Может быть, передавать информацию не в реальном времени, а пакетно, и посередине сделать механизм кэширования? Для меня так и выглядит качество: определить, каковы требования, и потом придумать техническую реализацию, которая воплотит их.
— Можете привести самый интересный кейс из практики, связанный с качеством?
— Сложно сказать, все проекты разные, так что лучший — это всегда последний, над которым я работал!
Ну, как-то я работал над системой, где требования частично напоминали Lotus Notes. Помните такую древнюю программу? Она была ужасной программой, но делала одну вещь очень-очень хорошо. Эта программа очень хорошо синхронизировалась: ты мог скачать свою почту и заметки, потом поймать такси, куда-то поехать, в это время ответить на все письма, а в следующий раз, когда ты подключишься к сети, всё автоматически выгрузится, синхронизируется и заработает волшебным образом.
И у нас был клиент с системой для продаж, который хотел такой же принцип работы. Потому что коммивояжеры вечно в разъездах, и нужно было, чтобы они могли размещать заказы без интернет-подключения, а потом всё синхронизировалось бы и становилось как надо.
И мы поняли, насколько это трудная задача, из-за кучи пограничных случаев и сценариев, которые нужно предусмотреть. Сначала мы разработали систему, которая работала вообще без подключения к интернету, потом уже занялись синхронизацией. И там была куча головной боли — например, производительность работы приложения в онлайне по сравнению с офлайном, при подключении появлялась заметная задержка, потому что в это время происходила синхронизация. Так вот, в этом случае QA были для нас большой занозой, потому что они находили пограничные случаи, которые рушили всю систему.
А со стороны это кажется простой задачей. Приложения типа Dropbox и Google Drive решили эту задачу так, что она стала невидимой. И она кажется лёгкой. Но когда мы пытались её решить, оказалось, что существует миллион пограничных случаев. Так что без надёжного QA трудно найти их все, каждый из которых должен быть возвращён на согласование со структурой приложения, чтобы проследить, что общая структура всё ещё работает.
Собственно, пока мы разрабатывали эту систему, вносили фундаментальные изменения в структуру, мы поняли, что пограничные случаи будут частыми и неприемлемыми. И это отличная иллюстрация того, насколько важно иметь очень хорошо налаженный цикл обратной связи между разработкой архитектуры и такими частями, как QA. Слишком многие компании откладывают это на самый последний момент, но если так делать, то в итоге многие вещи будут сделаны неправильно, и придётся возвращаться назад и тратить уйму времени, чтобы переделывать. Если наладить тесный контакт между разработкой архитектуры и тестированием, то можно находить эти пограничные случаи и менять структуру гораздо быстрее. К счастью, в этом проекте мы были крайне гибки — так как это был проект ThoughtWorks, у нас был очень быстрый цикл. И у нас была очень сильная команда тестировщиков.
— Многие в тестировании спрашивают, как они могут повлиять на архитектуру. Для них архитектура — это нечто в башне из слоновой кости. Что с этим можно делать?
— Мне кажется, что тестировщикам было бы полезно прийти к архитекторам и объяснить им, что они плохо делают свою работу, а тестировщикам лучше знать, как её выполнять. Люди же любят, когда им такое говорят! Вообще-то нет, не любят, ничего хорошего из этого не выйдет.
У меня есть любимая мантра для таких случаев: «лучше показать, чем обсуждать». Вам нужно показать, насколько отличается ваш мир от их мира. Если вы инженер-тестировщик, вам нужно привести юзкейса, который наглядно продемонстрирует недостаток проектирования. Если вы покажете этот сценарий архитектору, то это уже не просто жалоба на что-то, а конкретная демонстрация: «Вот, ваш проект не будет работать в таком сценарии, так что её нужно изменить». Если они на это не согласятся, то это значит, что они просто потеряли связь с реальностью. А архитекторы должны быть чувствительны к вещам, которые происходят в реальном мире.
Есть отличная небольшая, как я это называю, поэзия от бывшего министра обороны Дональда Рамсфельда, в котором говорится об «известных известных» и «неизвестных неизвестных». Так вот, в каждом проекте ПО есть «неизвестные неизвестные», так что разработка любой архитектуры должна быть итеративной. Потому что неважно, сколько ты будешь продумывать, вещи, которые ты никак не мог предвидеть, просто будут внезапно появляться, пока ты будешь пытаться построить эту структуру.
Предположим, пять лет назад ты начал разрабатывать новую систему, а потом через два года вдруг появился Docker. Не было никаких шансов, что ты мог предугадать, что появится нечто такое. Но тебе необходимо пересмотреть свою структуру сразу, как только это произошло, потому что теперь некоторые вещи могут стать гораздо проще и некоторые твои проблемы могут быть решены.
Поэтому тебе нужно постоянно пересматривать весь свой мир. А думать, что ты заперся в башне из слоновой кости и можешь выбрасывать через дырку в полу проекты, которые не будут меняться годами, а люди просто будут их реализовывать — это просто наивно, это непонимание основополагающих принципов разработки ПО.
Исходя из вашего опыта, как бы вы сказали, темп изменений в области разработки ПО замедляется или ускоряется?
— Ускоряется.
— Конечно! Причём даже темп ускорения тоже ускоряется! Так что любая компания, любая организация, которая НЕ стремится наладить цикл обратной связи с дизайном, совершает большую ошибку. Потому что частью этого жизненно важного цикла обратной связи должно быть именно тестирование (QA). Это последний рубеж обороны, который позволяет как раз делать то, как вы заявили, что ваша система будет делать.
Мы собираем вместе все те штуки, которые должна делать наша система, а QA должны оценить, действительно ли она делает всё обещанное. А если нет, то тестирование, демонстрируя это, позволяет сделать две важные вещи. Во-первых, это помогает получить более хорошую обратную связь по архитектуре. Во-вторых, это позволяет тебе точнее определить твои цели.
Одна из вещей, в которых я абсолютно уверен в архитектуре — это что архитектурные параметры должны иметь точное объективное определение. Потому что если у меня есть точное объективное определение производительности или эластичности, то ребятам из QA будет проще сказать, правильно всё у тебя или нет. Тут или есть, или нет. Если у тебя есть объективный результат для этих показателей, это проясняет отношения между этими двумя частями вашей организации и позволяет создать лучший цикл обратной связи.
— Когда вы разрабатываете архитектуру, на каких стадиях проекта вы привлекаете тестировщиков?
— С самого начала. Когда мы начинаем проект, у нас обычно присутствуют архитекторы, разработчики, бизнес-аналитики и QA-инженеры, и если есть кто-то, кто занимается инженерией данных, архитектурой данных или data science, они тоже присутствуют. Потому что глупо составлять такую архитектуру, которую будет сложно тестировать.
Их фидбэк нужен, начиная с самых ранних стадий. Потому что всегда, снова и снова в самых разных проектах, бывает так. Сначала архитектор придумывает какую-то структуру и говорит: «Мы будем делать вот так». А потом кто-то из мира данных или тестирования говорит: «Знаешь, если делать так, то нам будет очень сложно с этим работать, но если сделать вот так, то и нам будет проще, и для вас задача тоже не сильно усложнится». И собирать эти идеи на ранних стадиях очень важно, потому что так можно сделать такую структуру, которая очень сильно упростит жизнь тестировщикам и всем остальным, не только тестировщикам. Ты же не хочешь свести с ума своих архитекторов данных.
Есть одна фраза, которую мы часто используем в ThoughtWorks, «прокладывать мощёные дорожки» для людей. Мы делаем это, когда строим свою инфраструктуру, штуки типа deployment pipeline. Мы не хотим, чтобы разработчики испытывали трудности с использованием этих инструментов, мы пытаемся проложить мощёную дорожку, чтобы у них возникало как можно меньше помех в том, чтобы делать то, что мы считаем нужным. А ещё мы считаем, что нужно иметь надёжную QA, так что нужно, чтобы они принимали участие в разработке архитектуры с самого начала, чтобы мы могли видеть, что для них в дальнейшей работе с этой структурой не будет трудностей, потому что зачем создавать им лишние трудности, если мы с легкостью можем сразу сделать структуру иначе, чтобы сократить большинство этих трудностей. И сокращение помех это такой способ ускорить цикл обратной связи, что является наиболее насущной целью аджайл-разработки.
— Звучит знакомо. А что вы думаете о том, что от чётких ролей «бизнес-аналитик», «QA» и так далее движутся к какой-то обобщённой форме?
— Это совершенно нормально. В ThoughtWorks у сотрудников есть и уровни, и роли, и люди могут менять роли, если хотят. Распространённая ситуация, когда разработчик становится тестировщиком на одном проекте, потом становится снова разработчиком на другом. Потому что некоторым просто интересно, как живут другие, они хотят попробовать что-то, чего ещё не пробовали. Мы стараемся максимально автоматизировать процесс тестирования, и чтобы этим заниматься нужно немного разрабатывать. И если в команде тестировщиков появляется сильный разработчик, это помогает им автоматизировать больше.
— А когда не разделяют даже роли QA и разработчиков?
— Нет, роли нужны, роли должны быть. Позволить разработчикам заниматься тестированием — это как дать заключённым ключи от их собственных камер. Они совершенно точно пойдут по пути наименьшего сопротивления и упустят абсолютно все пограничные случаи, это будут сплошные слепые пятна.
По-настоящему хороший тестировщик должен уметь сломать что угодно, это не разработчик. Конечно, бывает, что человек может выступать в обеих ролях, но это два совершенно разных образа мышления. И совершенно точно нельзя давать кому-то тестировать то, что сам этот человек написал. Потому что в структуру его кода встроены неверные допущения, и если этот человек сделает те же неверные допущения при тестировании, то пропустит много всего. Поэтому, даже если вы делаете проект без формальной роли тестировщика в нём, хотя бы сделайте так, чтобы код одного разработчика тестировал другой разработчик. Потому что иначе всё закончится очень глупыми багами, которые никому не пришло в голову проверить.
Но я совершенно нормально отношусь к тому, чтобы иметь гибкие роли внутри проекта. Всё это делается для того, чтобы команда была как можно менее многочисленной — это мудрость, пришедшая к нам из 1975 года, которую только сейчас начинают осознавать.
— 1975-го?
— Фред Брукс в «Мифическом человеко-месяце» писал, что привлечение новых людей в отстающий проект по разработке ПО тормозит его ещё сильнее. Он был первым из тех, кто решил провести анализ зависимости продуктивности команды разработки и её размера. Он был первым (хотя он это так и не называл), кому пришла в голову идея «команды на две пиццы». Хоть у него распределение ролей было немного не таким, но его результаты были весьма точны. Чем больше коммуникативных связей необходимо поддерживать, тем сложнее это делать, особенно когда работа идёт над чем-то настолько сложным, как ПО. Так что многие компании делают более гибкие роли, что отражает их стремление поддерживать малочисленность команд. Но это не значит, что роли вообще не нужно делать и от них нет никакой пользы.
Это как многие команды решают, что хотят аджайл, потому что хотят избежать того, что им кажется скучным — вроде документирования важных решений, QA и тому подобного. Но если так делать, то получится только аджайлная катастрофа. Все эти вещи всё равно надо делать, нужно просто найти такой способ, чтобы всё это было с наименьшими трудностями. Но, я считаю, что это всё ещё критически значимо для проектов разработки ПО.
— Очень интересно.
— Кстати, я считаю, что Apple стоит нанять корректора, чтобы вычитывать глупые тексты на их диалоговых окнах. Потому что на их диалоговых окнах Wi-Fi есть два настолько ужасных примера страдательного залога, что я прямо закипаю каждый раз, когда их вижу. Потому что я писатель и я ненавижу плохие тексты. Не надо позволять разработчикам писать тексты для UI, пусть разработчики пишут код. И стоит нанять корректора в команду QA, чтобы исправить их и меньше раздражать пользователей.
— Окей, возвращаясь к теме небольших команд. Вероятно, у вас в ThoughtWorks большой опыт — как перейти к таким?
— Ну, как я говорил раньше, «лучше показать, чем обсуждать». Чтобы показать вашей организации, что они должны стремиться к формированию небольших команд, достаточно отследить количество сообщений, которые передаются между подразделениями для решения простых вопросов.
Допустим, мне нужно изменить выгрузку из каталога в моём приложении. Сколько тикетов я должен создать? Один для слоя UI, один для разработчиков, один для администратора баз данных, один для отдела эксплуатации — и сразу понятно, что это просто шум и помехи. Если у вас одна команда, и вы все вместе, то вам нужно ноль сообщений, потому что вы все сидите вместе и вам достаточно сказать: «Эй! Давайте изменим процесс выгрузки из каталога!» И у вас одна автономная команда и нужно всего одно сообщение о том, что будет изменена выгрузка из каталога, а не 50 тикетов в Jira, которые болтаются по всей компании.
Это один чёткий показатель. И это именно то, к чему подводит книга Фреда: ущерб, наносимый большими разделёнными командами, в основном состоит в том, что большая часть времени уходит на попытки разобраться с потоками информации: тикетами, или запросами, или чем угодно ещё, что происходит между этими командами. Если просто посадить их вместе, работать становится гораздо проще.
Мы начали так делать по чистой случайности. У нас начали самоорганизовываться команды вокруг этой идеи, и это прекрасно сработало. Мы заметили, что работа пошла быстрее, и это вдохновило нас на то, чтобы максимально это распространить.
Я считаю, что единственный способ реализовать этот подход в компании — это «лучше показать, чем обсуждать». Если вы пытаетесь привнести такой подход в вашу компанию, выберите простой не жизненно важный проект и попробуйте. Уберите перегородки, создайте общее рабочее пространство, посадите туда небольшую межфункциональную команду. И крайне важно, о чём я уже говорил, измеряйте. Измеряйте их скорость, как часто они выпускают релизы, сколько у них багов — любые метрики, которые можно собрать по этой команде. И ваша компания убедится, что показатели действительно улучшатся.
А мы делаем разделение сотрудников по их функциям в работе. Разделение сотрудников по их функциям в работе очень удобно для отдела HR, но ужасно для разработки ПО. Разделение по командам гораздо лучше. Это безумие — иметь целый отдел тестировщиков, отделённый от того, что им нужно тестировать. Как ты должен погружаться в предметную область, если ты далеко от бизнес-аналитиков и разработчиков? Тестировщикам нужны глубокие знания в предметной области, как это всё работает, а если у них очень ограниченный доступ к бизнес-аналитикам, потому что они находятся в другой части компании, то как тут получить все те знания по предметной области, которые нужны тестировщику для эффективной работы? Но если вы сидите в одной комнате, то тестировщику будет гораздо проще наклониться к бизнес-аналитику и сказать:
— Эй! А если изменить это значение на то, то должен происходить кредитно-дефолтный своп? Это так и должно быть?
— Да.
— Хорошо.
Этот 15-секундный разговор позволил избежать полного цикла движения тикетов Jira, электронных писем, суеты и всего того, что только вызывает помехи в работе. Так что иметь команду, которая находится в одном помещении, то есть когда есть возможность поговорить, не выходя из комнаты, это действительно крайне важно. И это гораздо лучше, находиться в одной комнате, чем пользоваться чем-то типа Slack, потому что если вы в одной комнате, ты можешь посмотреть, а не занят ли этот человек, а не закидывать его отвлекающими сообщениями через Slack.
Есть аналогия, которую я привожу, поясняя удобство нахождения в одной комнате. Предположим, что мы вернулись во времени на 30 лет назад и вам нужно узнать погоду в Чикаго. Как вы это сделаете? Можете включить канал с прогнозами погоды по телевизору и надеяться, что там дойдёт дело до Чикаго. Или, может быть, пойти в библиотеку и посмотреть, нет ли там чикагских газет. Или позвонить кому-нибудь. И когда возникает столько сложностей, вам уже не хочется узнать эту погоду. А сейчас её можно узнать мгновенно, достаточно просто открыть приложение на смартфоне.
В проектах ПО есть такие же значимые вещи: если это сложно сделать, то ты просто не будешь этого делать, а если это пустяковое дело, то ты это сделаешь, просто потому что нет никаких препятствий. И так же с взаимодействием между бизнес-анализом и QA: если наладить этот контакт очень легко, то это произойдёт, а если для этого нужно создать email или открыть Slack, посмотреть доступен ли этот человек, ввести сообщение. Это создаёт достаточно помех, чтобы не делать этого вовсе, хотя если бы это было легко, то это бы принесло много пользы.
— Логично. Однако мы движемся к миру с большим количеством распределённых команд. Вот у вас есть офисы в Лондоне, Нью-Йорке, не знаю, Чикаго или там в Сингапуре. То есть всё равно приходится полагаться на средства коммуникации.
— Да, приходится. Но штука в том, чтобы укреплять коммуникационные связи, которые разрываются дистанцией. У нас почти все команды распределённые, так что мы установили видеокамеры, чтобы члены команд могли видеть друг друга всё время: видеть лицо, жесты.
Я так ненавижу Slack! Slack — это новейшая версия того, куда приходит умирать продуктивность. Некоторым командам удаётся хорошо его использовать, но большая часть людей пользуется им ужасно, превращая в свалку. Каждому проекту требуется место «по умолчанию» для свалки всего подряд, и этим стал Slack. Некоторые пытаются использовать его, чтобы поддерживать коммуникацию «в одном помещении». И его можно так использовать, нужно только быть очень дисциплинированным, потому что с механизмом, который так постоянно тебя отвлекает, просто невозможно заниматься разработкой. Я отказываюсь когда-либо пользоваться Slack, потому что он просто уничтожает мою продуктивность, постоянно меня отрывая от работы, потому что всем всё время что-то нужно.
Это удобный формат, если вы работаете над проектом в команде и нужно быстро получить информацию, но это не заменяет общения друг с другом в одном помещении.
Коммуникацию можно укрепить при помощи повсеместного использования веб-камер. Алистер Кокберн проводил много интересных исследований того, что он сам назвал температурой коммуникативных каналов. И текст — это очень холодный канал коммуникации, настолько холодный, что нам пришлось изобрести эмодзи, чтобы люди не раздражались. Потому что текст очень легко неправильно считать и эмодзи нужны, чтобы добавить контекст. Как часто вы используете эмодзи, когда разговариваете с кем-то лично?
— Никогда.
— Никогда! Потому что вы просто можете взглянуть на лицо собеседника и увидеть, о чём он говорит. Это один из тех коммуникативных каналов, о которых говорит Алистер Кокберн. Если вы замените личное общение на Slack, то вы потеряете все те уровни коммуникации, которые есть при личном общении. Поэтому камеры гораздо более выгодны, чем Slack, хотя может показаться, что объём передаваемой информации такой же, но есть огромный пласт невербальной информации, которая передаётся между людьми, когда они разговаривают, и сокращая количество этих каналов, мы делаем этот канал коммуникации гораздо менее ценным.
— Да-да. В какой-то момент я заметил, что начал ставить смайл в конце каждого предложения, чтобы не звучать так чертовски холодно.
Спрошу теперь о другом. Предположим, мы хотим улучшить в компании IT-инфраструктуру, сервисы, сделать её быстрее, лучше, сильнее. И некоторые нанимают для этого архитектора со стороны. С вашей точки зрения, это достижимо, или для такого всё-таки нужен кто-то внутри компании?
— Тут совершенно точно нужно участие людей со стороны компании. И вот почему. Может прийти кто-то со стороны и показать людям, как делать эти преобразования, добиться, чтобы люди работали по-новому, и так далее. Но как только случится какой-то внеплановый кризис, они все вернутся к своим вредным привычкам.
В больших организациях почти невозможно кардинально п
