Чему армия могла бы научить тестировщика? Как выглядят две крайности в подходах к тестированию? Как объяснить, что технический долг платежом красен? Что есть общего у предыдущих вопросов?

Общее то, что при всей их разнице, они все близки одному человеку. У Джима Холмса за спиной несколько десятилетий IT-опыта, начавшегося в 80-х в ВВС США — неудивительно, что он готов рассказать о многом. Для него важно понятие «testing culture», и мы задали ему вопросы, которые могут очень сильно различаться, но в конечном счёте так или иначе связаны с культурой тестирования.

— Вводный вопрос: расскажите о себе.

— Меня зовут Джим Холмс, я независимый консультант и владелец собственной компании, Guidepost Systems. Я специализируюсь на качестве поставки ПО и в общей сложности занимаюсь программированием около 20 лет, до этого я долго служил в армии. Качеством я серьёзно заинтересовался около 15 лет назад, во время работы над несколькими не очень удачными проектами. В целом, я много занимался автоматизацией тестов, модульными тестами, интеграционным тестированием и, в особенности, функциональным тестированием, тестированием UI. В частности, я работал в компании, которая написала замечательный инструмент Telerik Test Studio. А в последние 5-8 лет я стал заниматься не только чисто техническими аспектами, но и качеством поставки в целом — то есть насколько хорошо налажена связь между командой, занимающейся поставкой, и бизнесом. Но при этом я по-прежнему много времени отлаживаю скрипты WebDriver и решаю проблемы наподобие периодических сбоев из-за неправильных асинхронных действий. Живу я в городе Эшленд в Орегоне — заметьте, не в Портленде (когда в США говоришь «Орегон», обычно все думают «Портленд»).

— Вероятно, для тестировщика самая необычная часть вашей биографии — это служба в армии. Чем именно вы там занимались?

— Я служил в ВВС США, потому что меня всегда вдохновляли самолёты и мой отец был пилотом. Он взял меня в мой первый полёт, когда мне было всего 4 года. В ВВС же мне очень сильно повезло, я служил в команде E-3 — это такой большой самолёт с огромным диском сверху, там я отвечал за работу радара и некоторых систем связи. В течение одиннадцати лет я занимался администрированием и отладкой этой большой электронной системы. А во время, свободное от полётов, я администрировал компьютеры нашей эскадрильи. Примерно тогда стало возможным создавать сети на рабочих местах. Кроме того, поскольку я был военнослужащим, мне оплачивали образование, поэтому я учился в вечерней школе по разработке ПО.

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

— Да, в случае с армией первое, что приходит в голову — это дисциплина. И с этим у многих тестировщиков и разработчиков проблемы. Считаете ли вы, что им есть чему поучиться у военных?

— Это очень интересный вопрос. Дело в том, что та дисциплина, которой научили меня, была несколько иной, чем, скажем, у десантников, то есть не было постоянных криков и наказаний. Меня научили дисциплинированному подходу к тестированию и, в целом, к решению проблем. Также была важна дисциплина на рабочем месте — понимание того, что есть иерархия; чтобы научиться в ней работать, надо уметь общаться с начальством. Такого рода дисциплина очень сильно мне помогла.

Из армии я ушёл 25 лет тому назад — да, я старик — и работа в гражданском секторе очень интересно контрастировала с моим предыдущим опытом из-за того, какие там были приоритеты. В армии я служил на самолёте, который должен был следить за противником на большой территории и обеспечивать безопасность своих. Любая ошибка означала риск для жизней наших солдат. Я не хочу сгущать краски, но это действительно было так. Так что, когда в IT кто-то начинает паниковать и требовать, чтобы какую-нибудь задачу решили сию же секунду, благодаря своей дисциплине и своему опыту я всегда могу успокоить людей — нам не грозит, что кто-то умрёт, и мы не теряем сотни тысяч долларов в минуту (а я в таких ситуациях бывал). Мы очень часто паникуем и позволяем бизнесу или акционерам нас без нужды запугать и создать необоснованное напряжение, которое никому ничего хорошего не приносит. Возможно, лучшее, чему меня научила армия — это способность призвать к спокойствию, здраво оценить ситуацию и предварительно спланировать свои действия, а не бросаться на задачу бездумно из-за искусственно созданной паники.

— То есть нужно уделять время продумыванию стратегии.

— Да, и в IT эта проблема уже очень давно: постоянные требования сдавать проект сию же секунду. Главное — сделать быстро, а что именно делается — оказывается второстепенным. Чаще всего с этим давлением можно совладать, если правильно вести диалог. Но для этого важно уметь сказать, что мы создадим больше стоимости, если потратим несколько больше времени и рационально подойдём к проблеме.

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

— Это прекрасный вопрос. Помимо моей самостоятельной работы я также сотрудничаю с Pillar Technology из города Колумбус в Огайо. Я очень давно знаком с людьми из этой компании. Сейчас там работает около 250 человек, и почти все они работают по принципу экстремального программирования (XP): у них много юнит-тестов, и разработка очень хорошо продумана. Когда меня наняли туда три года назад, я был единственным тестировщиком, и они создавали весьма качественный продукт. К тестированию они подходили исключительно с позиции ХР, с позиции test-driven development. Это прекрасный подход, и они вполне успешно его применяли, к тому же мне вместе с некоторыми другими сотрудниками удалось изменить некоторые аспекты доставки ПО.

А сравнить этот опыт можно с другой компанией, в которой я консультирую в течение последних трёх лет. Это промышленная компания, она входит в верхнюю десятку списка Fortune, и в ней работает около 200 тысяч человек по всему миру. У них очень большой IT-отдел для внутренних нужд компании. Там много хороших людей, но тестирование у них застряло на практиках 1980-х или 1990-х. Компания производит огромные партии абсолютно одинаковых продуктов, и многие там привыкли, что при производстве, скажем, шариковых подшипников вполне можно оценить количество ожидаемого брака. Но проблема в том, что такого рода мышление они переносят в IT.

У меня был разговор с четырьмя, в общем-то, весьма умными сотрудниками, которые занимались тем, что собирали отчёты о дефектах из нескольких проектов и пытались предсказать количество возможных дефектов в будущем. Я им сказал, что это вполне резонно делать в промышленности, но как они будут отличать показатели, которые рассчитываются для мобильного приложения, от показателей, скажем, веб-сервисов? Мне ответили, что разницы нет. Так что мне повезло увидеть абсолютно противоположные точки на спектре различных подходов и культур тестирования.

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

— А в вашей практике консультирования бывают случаи, когда уже после завершения работы с компанией вам говорили «ничего лучше не стало»?

— Я вам по секрету скажу, что с людьми тяжело, мы очень непростые создания. Это одна из причин, по которым у меня столько седых волос (вторая — моя дочь). Изменить одного человека сложно, изменить людей в организации ещё сложнее. Так что да, такая ситуация у меня возникает довольно часто.

О некоторых консультантах мы даже говорим, что он «выгорел». Это происходит из-за того, что мы прилагаем очень много усилий к тому, чтобы изменить культуру, сформировавшуюся в организации, и нам приходится очень много работать с проблемами на личном уровне — люди боятся изменений, их постоянно приходится убеждать в том, что это необходимо, и искать тот путь, который подойдёт именно им. Каким бы я ни был сильным и громким, я не могу просто прийти и сказать: сделай то-то и то-то. Нужно прийти к консенсусу. Эту работу нужно вести годами, чтобы хоть чего-то достичь, а когда кажется, что вы решили проблему, и вы уходите консультировать в другую организацию, то встречаете там ровно те же проблемы, что и на предыдущем месте. Вы опять тратите огромное количество времени и сил, а потом выясняется, что в той первой компании всё уже вернулось к прежнему состоянию.

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

— В вашем блоге вы писали о своих профессиональных принципах, и там речь шла о том, что необходимо быть открытым, всегда учиться новому, больше слушать, чем говорить, приспосабливаться и при этом по-доброму относиться к людям. Мне интересно, действительно ли в IT помогает доброе отношение к людям?

— Да, помогает. Я говорил, что служил в армии, где у нас была жёсткая дисциплина — но надо понимать, что дисциплинированность и структурированность никак не мешают доброму отношению и сопереживанию другим людям. Вы знаете шотландского повара Гордона Рамзи? Он ведёт передачу Hell’s Kitchen. Я упоминаю его потому, что шеф-повары в дорогих ресторанах очень часто ведут себя с работниками отвратительно — кричат, оскорбляют. Мне претит такое отношение к людям. Для меня важно доброе отношение друг к другу. Если вы хотите добиться каких-либо изменений, то вам нужно понять, почему люди сопротивляются им, то есть вам нужна эмпатия. И она же позволит вам сделать так, чтобы человек сам захотел измениться. Такой подход значительно более эффективный, чем кричать на людей и требовать, чтобы они слушались и не задавали вопросов. У каждого человека свой разум, своя душа, свой опыт. Я не хотел бы углубляться в философию, но я считаю, что в долгосрочной перспективе доброе отношение и эмпатия позволят вам добиться больших результатов. Так что да, они помогают.

— Вы проводите семинары, и на одном из них учите программированию людей, не умеющих программировать. У меня есть два вопроса. Во-первых, какие проблемы чаще всего мешают людям самостоятельно программировать? Во-вторых — считаете ли вы, что в течение следующего года автоматизированное тестирование станет преобладать над ручным?

— По моему опыту, людям чаще всего мешают не технические сложности, а страх. Могу привести пример из моего опыта в компании из Fortune 10, о которой я уже рассказывал. Я работал с командой тестировщиков, которые занимались тестированием вручную, и нам нужно было провести автоматизацию при помощи WebDriver. Из них большинство не могли даже открыть Eclipse, чтобы начать писать код. Они боялись написать скрипт для автоматизации, потому что в их понимании это немногим отличалось от написания масштабируемого веб-сервиса или базы данных с многопоточностью, то есть вещей, которым разработчики учатся годами. Этот страх мешал им делать в общем-то несложные вещи.

Я сейчас разрабатываю курс для Ministry of Testing на основе семинара, в котором я объясняю, что вам не нужны годы практики для того, чтобы просто открыть файл Java, C# или скрипт Ruby, прочитать его и понять общую структуру, или для того, чтобы написать простой тест на WebDriver. Более того, даже если вы не до конца понимаете всё, что происходит в коде, вы можете дать общую оценку ему, потому что знаете, например, что один метод не должен занимать три экрана, не должно быть четырёх вложенных операторов if — их сложно будет тестировать, нельзя давать переменным имена из одной буквы и так далее. На мой взгляд, на начальном этапе главная трудность — это преодолеть опасение, что вам придётся решать неимоверно сложные задачи. И мне всегда было интересно смотреть, насколько быстро мои клиенты от этого страха избавляются — надо просто дать человеку несложный модульный тест и попросить его написать arrange, act и assert. Я думаю, эта человеческая составляющая очень важна.

Большая часть технологий, с которыми мы работаем, не так уж и сложны, вещами наподобие беспилотных автомобилей занимаются немногие. Я как-то проводил семинар для одного клиента в Индии, и там был один менеджер без какого-либо опыта программирования. Этот менеджер поначалу сильно злился, и причина была как раз в том страхе, о котором я сейчас говорил, а на этот страх накладывалось нежелание показаться глупым. Но к концу первого же занятия он погрузился в написание тестов настолько, что мне пришлось выставить его из аудитории через час после того, как занятие уже закончилось — он сидел, уткнувшись в монитор, в паре с другим участником семинара и писал простенькие тесты для алгоритма заработной платы. И дело здесь вовсе не в моих преподавательских навыках — просто это показывает, насколько большую роль играет этот страх или его отсутствие. Здесь речь идёт о вещах, заложенных в человеческой природе.

Ваш второй вопрос относился к переходу от ручного тестирования к автоматизированному. У меня здесь есть определённый опыт, я три года работал в компании, которая занимается автоматизацией тестирования. Я считаю, что вопрос следует ставить иначе и стремиться не к автоматизации тестирования, а к развитию тестировщиков и обретению ими множества технических навыков, одним из которых должно быть автоматизированное тестирование. Мне хотелось бы видеть таких тестировщиков, которые, имея пользовательскую историю, спецификацию и требования, могли бы свободно вести диалог с разработчиками о достаточно специализированных вещах и совместно искать решения, которые затем будут воплощены в коде. Это несколько отличается от того подхода, при котором тестировщик учит программирование, просто чтобы уметь писать WebDriver-скрипты. Этот навык, конечно, тоже важен, но, на мой взгляд, он не самый важный. Сверхзадачей, на мой взгляд, является умение вести диалог с разработчиком и способствовать тому, чтобы он имел в виду процесс тестирования, когда он пишет код. Даже TDD уже будет значительным результатом — я считаю, что все организации должны уметь так писать.

Суть в том, что правильно поставленное тестирование далеко не сводится к модульным тестам или интеграционным тестам. Очень часто люди удовлетворяются тестированием типового пути выполнения кода — все тесты пройдены, везде стоят галочки, достигнуто 100%-е покрытие кода. Но ведь ничто из этого не гарантирует качества кода, не так ли? Хотя это тоже необходимые процедуры, конечно же. Так что в моём понимании тестировщик должен не просто написать несколько функциональных тестов или тестов в WebDriver, а думать о том, как ему наладить более тесное сотрудничество с разработчиками, бизнес-аналитиками. Можно, например, попробовать mob programming. В общем, я считаю, что автоматизация — это инструмент, а не цель.

— Слова «тесное сотрудничество с разработчиками» нам как организаторам Heisenbug очень близки — даже слоган конференции у нас «о тестировании, но не только для тестировщиков». И в связи с этим сотрудничеством хочется задать такой вопрос: что вы, как человек с большим опытом тестирования, хотели бы сказать нашим читателям-программистам?

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

На мой взгляд, разработчикам важно понять, что хороший тестировщик может быть весьма ценным, и если заранее с ним поговорить, можно сэкономить себе много времени и нервов. Это то, о чём говорится в теории ограничений. Предположим, я разработчик, и я вижу, что тестировщик обнаружил некоторую проблему. Если вместо того, чтобы переписываться о ней в TFS или где-либо ещё, я просто подойду к нему и поговорю лично, то этот разговор поможет мне сократить количество дефектов в коде, который я пишу. К тому же в личном общении большинство тестировщиков, как правило, далеко не такие страшные. В общем, вы, как разработчик, сможете улучшить качество своего кода, если избавитесь от расхожих стереотипах о тестировщиках — которые, к сожалению, зачастую имеют основание, и над этим нам тоже надо работать.

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

Если вам тоже близок такой формат конференции, а Джим вас заинтересовал, обратите внимание: он тоже выступит на ближайшем московском Heisenbug, где подробнее расскажет о своём опыте в компании из списка Fortune 10. Как изменить культуру тестирования в гигантской компании, если гиганты обычно неповоротливые? 6-7 декабря на Heisenbug можно будет узнать и об этом, и о многом другом.

— Хочется сравнить разработчиков с тестировщиками вот в чём. Вы написали книгу о лидерстве «The leadership journey». Известно, что у разработчиков сложное отношение к лидерству: пока для других это заветная мечта, разработчики зачастую ассоциируют его с кучей неприятных обязанностей, никак не связанных с самым интересным — написанием кода. А распространён ли такой взгляд среди тестировщиков?

— Я думаю, что это настрой, общий для IT: неважно, занимаетесь ли вы администрированием базы данных, программированием, тестированием, управлением проекта. У вас есть работа, которую вы хорошо делаете, вам комфортно, у вас есть опыт, вы обладаете влиянием именно в этой роли. По сравнению с этим необходимость взять на себя больше обязанностей и, о ужас, работать с людьми, звучит значительно менее комфортно и вызывает отторжение. Поэтому в самом начале моей книги я предлагаю способы выяснить, действительно ли вам всё это нужно, и что вообще значит быть лидером.

Некоторые функции лидера можно выполнять, при этом не продвигаясь вверх по иерархии. Человек, который в рамках команды имеет больше опыта и навыков, чем другие, будет в этой команде неформально выполнять роль лидера. Так что речь необязательно идёт о том, чтобы стать менеджером: возможно, вы просто считаете, что вам нужно обладать большим влиянием в вашей команде. Хотя в некоторых организациях считается само собой разумеющимся, что, набрав определённый опыт, человек начинает занимать руководящие должности. Его делают техническим руководителем, и, в дополнение к написанию кода, он теперь оказывается ответственным за квалификацию своей команды. А на более высоких ступенях он вообще перестаёт писать код. Так что, в целом, руководство может иметь много разных форм. Специфика нашей области в том, что мы боимся занимать руководящие должности, потому что боимся потерять свои технические навыки из-за того, что перестанем писать код или тестировать. Помимо этого, если тестировщик не занимается разработкой, то ему будет страшно руководить программистами. Все эти проблемы абсолютно естественны, преодоление их — неотъемлемый аспект руководства в нашей отрасли.

— И ещё один вопрос, сравнивающий разработчиков и тестировщиков. Среди разработчиков есть активная дискуссия относительно удалённой работы: одни считают, что это давно надо сделать практикой по умолчанию, а другие возражают, что живое общение не заменить скайпом. Вы работаете удалённо — какое ваше мнение об удалёнке в тестировании?

— Из 18 лет, прошедших с рождения моей дочери, я работал удалённо 13 или 14. Так что у меня действительно есть мнение по этому вопросу. На мой взгляд, удалённая работа — важный инструмент, она позволяет расширить круг людей, с которыми потенциально можно работать. Например, с человеком, который живёт в другом штате или на другом континенте. Так что я сторонник удалённой работы, в некоторых ситуациях она оказывается очень полезной.

При этом нужно признать, что при удалённой работе возникают существенные проблемы с общением и с производительностью. Чисто с технической точки зрения команда, которая работает полностью или по большей части на расстоянии, должна обладать хорошей инфраструктурой. Каждый участник такой команды должен работать по принципу DevOps. Не должно возникать ситуации, когда мы днями не можем связаться с администратором сервера, чтобы получить логи для отладки. Кроме того, нужно серьёзно подойти к организации средств общения. А если вы решили, что Skype и какого-нибудь мессенджера вам достаточно, Skype for Business брать не стали и пользуетесь бесплатной версией Google Hangouts, то у вас будут проблемы. Удалённая работа требует хорошей инфраструктуры. Кроме того, от вас требуется больше ответственности и дисциплинированности. Да, вы можете работать хоть в пижаме, но вы должны работать, а не играть на Xbox днями напролёт — стыдно признаться, но говорю это по собственному опыту.

Помимо этого, разговоры в коридорах и живое общение являются неотъемлемой частью вообще любой работы — просто люди так устроены. И надо признать, что здесь у удалённой работы есть существенный недостаток. Пускай у вас запущен hangout в Slack и живой видеочат — это всё не то. Эта проблема решаемая, но для этого нужны время и дисциплинированность, и для каждого нового участника команды эту проблему нужно решать заново.

За последние 20 лет я работал на расстоянии в два раза больше, чем в офисе, как я уже сказал — это прекрасный инструмент. Но при этом необходимо иметь чёткое представление о преимуществах и недостатках такой работы. Кроме того, организации нужно собирать всю команду вместе для живого общения по меньшей мере четыре раза в год, чтобы наладить те связи, которые не выстроишь через интернет. Нужно всем посидеть в одной комнате, поработать, поспорить, повеселиться. Всё это очень важно для создания хорошо слаженной команды. Если же вы считаете, что удалённая работа — это просто способ снизить издержки, вас ждёт разочарование. У меня опять получился довольно длинный ответ, но что поделать, вы задаёте интересные вопросы.

— У вас есть пост с заголовком «Technical debt: payment plan». Фразу «технический долг» можно увидеть часто, но вот в сочетании с фразой «график платежей» впервые, хотя это очень логичное развитие метафоры. Означает ли это, что мы ещё не дошли до той степени ответственности, когда к техническому долгу относимся так же серьёзно, как денежному, и что нам стоит исправляться?

— Это очень важный вопрос. Я думаю, любой, кто работал в IT сколько-либо продолжительное время, обязательно столкнулся с проблемой технического долга. Тут мне нужно поблагодарить Триш Ку (Trish Khoo), в Twitter её можно найти как hogfish. Она — отличный тестировщик, я знаком с ней уже много лет. Она, собственно, и написала пост «Technical debt: payment plan». Я тоже захотел написать об этом, когда прочитал этот пост, потому что в течение пяти лет делал выступления на конференциях, где высказывал, в общем-то, похожие мысли.

Итак, в нашей отрасли уже давно присутствует проблема технического долга, нам всем приходится думать, как его избежать и что с ним делать, когда он всё-таки возникает. По-моему, ваше предложение думать о нём, как о финансовом долге, имеет очень важные последствия. Если вы проведёте соответствующее исследование, то увидите, что этот технический долг действительно приводит к финансовым издержкам. Из-за технического долга ваш проект занимает на X больше времени, на нём работает на Y больше людей, и всем им нужно платить определённую зарплату. То есть эти издержки вполне измеримые, хоть их может быть не так-то просто оценить. Или, предположим, вам пришлось исправлять 30 багов в течение полутора месяцев из-за проблем, связанных с техническим долгом. Это, опять-таки, приводит к увеличению цены проекта в долларах. Более того, речь идёт не только об издержках в долларах, но и об альтернативных издержках: эти полтора месяца вы могли бы заниматься чем-либо другим.

Много лет назад я работал в компании, где на каждые 10 дней работы над новой функциональностью приходилось 3 дня исправления возникших проблем с качеством и техническим долгом. А на каждые эти 3 дня приходился день исправления исправлений. Были проблемы, которые открывались заново по многу раз. Всё это стоило денег. Я ушёл из этой организации, поэтому что за то время, пока я там работал, мне не удалось изменить сложившуюся там культуру и заставить их признать, что такая ситуация недопустима. Последней каплей стала моя неудачная попытка объяснить директору, что из трёх лет, что я там работал, мы потеряли год из-за исправления проблем, связанных с техническим долгом. Мне не удалось донести до него мою мысль, он перевёл разговор на другую тему. Я считаю, что людям, работающим в IT, нужно научиться лучше объяснять значимость технического долга и издержек, к которым он приводит. Мы не можем просто сидеть в своём углу, работать и ни с кем не общаться. Нам нужно научиться говорить на языке, который будет понятен бизнесу. А бизнес понимает язык долларов и потерянного времени. Бизнес начинает думать, когда падают продажи или обновления лицензий, а это происходит из-за падения качества, что, в свою очередь, вызвано техническим долгом.

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

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

— У этой проблемы две стороны. Бизнесу непонятно, зачем проводить рефакторинг и зачем писать автоматизированные тесты. Им видно только, что люди тратят на написание тестов в два раза больше времени, чем на написание кода, и это кажется им чудовищным. Это уже вопрос образования, поэтому необходимо объяснить, что разработка — это процесс, который налаживался десятилетиями. Существует статистика и исследования, которые показывают, что попытки сэкономить на тестировании прямо приводят к издержкам в долларах из-за задержек и исправлений. Бизнес этого не понимает.

Со своей стороны мы не научились правильно общаться с бизнесом, не научились убеждать. Кроме того, нам зачастую нехватает настойчивости, чтобы объяснить, что некоторые вещи не обсуждаются, их нельзя игнорировать или откладывать. Есть безопасные и продуктивные практики, которые сложились исторически, и если вы, менеджеры, будете им следовать, в итоге вы же будете рады, потому что будет создана большая стоимость. Это тяжёлый разговор, и мы, айтишники, не умеем его вести.

— Поэтому всегда хорошо, когда у менеджера или тимлида есть опыт разработки — тогда они эти вещи понимают. Хороший проект проще создать, когда у менеджмента есть технический опыт.

— В той компании из Fortune 10, о которой я говорил выше, у нас была ровно такая проблема. Менеджеры низшего и среднего звена не понимали, почему тестирование так важно. Нам удалось перезапустить проект и достичь согласия по вопросу о том, когда проект считать готовым, то есть мы добились того, чтобы включить менеджеров в диалог. Мы определили, что пользовательская история будет считаться готовой тогда, когда будет документация, когда в поддержке будут хорошо знакомы с новой функциональностью, когда продукт оунер проверил выполнение требований, который он же написал при помощи Acceptance Testing.

Помимо этого, мы добились согласия менеджмента на реализацию конкретных технических мер, которые он не понимал. Мы договорились, что код должен отвечать стандартным показателям статического анализа (например, анализа с помощью Sonar Cube), то есть он не должен быть слишком сложным, не должно быть слишком много строк в методах. Менеджеры поняли, что для поддержания здоровой базы кода необходимо соблюдать отраслевые стандарты того, как должен выглядеть код. Кроме того, в нашем определении готового проекта была фраза «необходимое тестирование», то есть мы не указывали определённого количества тестов, которое нужно выполнить, или определённое покрытие кода автоматическими тестами, которого нужно достигнуть. Благодаря этому руководитель группы проектов, разработчик и тестировщик могли по отношению к каждому модулю определить, какое тестирование будет достаточным. Каждый раз это происходило в ходе диалога, и менеджеры довольно долго не могли понять, что это опять-таки отвечает общепринятым в отрасли практикам.

— На этом наши вопросы закончились. Спасибо большое за ваши развёрнутые ответы.

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