Привет, Хабр! Как растут и развиваются тестировщики? Почему одни застревают на уровне мидла, а другие дорастают до руководителя группы, отдела, а дальше — выше, сильнее, быстрее — до топ-менеджеров и CTO. Эту тему исследовал я, Фёдор Зволинский — спикер направления «Программирование» в Skillbox и менеджер качества в крупной IT-компании. Статья написана по мотивам моего эфира для комьюнити Skillbox Code Experts. Примечательно, что почти всё тут сказанное применимо не только для роста с позиции QA-инженера, но и для других IT-специализаций. Поехали! 

Кто такие технологи, зачем нужны и как использовать опыт тысячелетней давности? 

Однажды я задумался, почему одни QA-инженеры застревают в мидлах, а другие — дорастают до CTO. Я исследовал эту тему, проводил интервью и пришёл к определённым выводам, которыми готов поделиться. 

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

Начну издалека: в Советском Союзе были технологи, в западном мире — инженеры и изобретатели. Это ребята, которые запускали и отлаживали процессы. Почему это важно? Хороший пример — Генри Форд, который отнюдь не изобрёл автомобиль, отнюдь не сделал его первым, или лучшим, или наиболее подходящим. Зато он сделал его массовым. А добился он этого как раз за счёт выстраивания процессов и внедрения конвейера для одного из видов их отладки. 

Именно Форд изобрёл I-процесс — линейный поток выпуска автомобилей. Интересно, что он делал одну модель из одних и тех же запчастей. А даже если менял модель, запчасти были совместимы между собой — как детальки lego. Это был реально один поток, одна труба, в которой всё собиралось. И, самое важное, как этот процесс был построен. У всех конкурентов были большие складские и логистические затраты: изготовили детали, куда-то их увезли, они там заржавели, их привезли и почистили, отправили дальше. Естественно, всё это сказывалось на экономике. 

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

Если мы посмотрим на производство программного обеспечения, то поймём, что там тоже есть свои flow. Задачки создаются, грумятся, передаются в разработку, тестируются, выкатываются, поддерживаются и так далее. 

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

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

О бедных джунах замолвите слово 

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

С разработчиками примерно такая же история. Джуниор-разработчик не строит архитектуру, не вписывает бизнес-решения. Он ничего не делает, кроме перекладывания JSON или простеньких вызовов. А если у него нет документации, зато есть 25 срочных задач, то и вовсе теряет способность работать и кричит в стол.

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

Проблемы Шивы в современном мире

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

Но что делать, если хочется расти дальше? Нужно ли набирать задач больше, чем можешь переварить? Через некоторое время и в этой ветке наступает развилка — часть людей выгорает и берёт паузу (или уходит из профессии / меняет место работы и там идёт по пути ограниченного количества задач — нужное подчеркнуть). А небольшой процент оставшихся автоматизирует работу вокруг себя. И успевают делать всё, что в них попадает, как Шива, у которого не одна пара рук.

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

Так мы видим, что автоматизация не является самым ценным в нашей истории. Это внешняя оболочка, проявление, симптом. А самое важное — как раз умение разобраться в порядке выполнения действий, предусмотреть все корнеркейсы и описать это в виде доступных инструкций, т.е. по факту создать процесс. А дальше уже всё равно, кто это будет выполнять — машина, ИИ или толпа маленьких злобных гремлинов. Главное, что инструкция, вход в процесс и результат работы этого процесса — уже есть.

Менеджмент через призму навыков

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

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

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

Археология процессов, или где откопать о них информацию

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

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

Более простым вариантом будут книги о производстве. Не так много книг, которые детально раскрывают особенности производства, но начать можно с автобиографии Форда или книги про производственную систему Toyota Таичи Оно. Они достаточно лёгкие, но там есть возможность проследить взаимосвязь — почему именно так поступали эти мэтры, как они нашли свою оптимизацию, какие отправные точки у них были, чтобы мы в результате получили весь этот масс-маркет?

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

Разобравшись, станет гораздо проще перекладывать свою работу для зарабатывания денег в эти операции. И, как следствие, проще с ней справляться, брать больше задач и расти быстрее, чего, собственно, и хотят все достигаторы.

Что общего у кодинга с процессами

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

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

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

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

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

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

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

Человеческий фактор или неизвестная переменная в виде людей

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

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

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

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

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

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

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

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

Выводы: как осваивать скилл-нутриенты

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

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

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

Конец! Учитесь процессам сами, обучайте других, и будет вам счастье!