Как стать автором
Обновить

Как мы начали дарить заказчикам $40’000 за право оценить качество их продукта

Тестирование IT-систем *Карьера в IT-индустрии IT-компании Управление проектами *Управление разработкой *

А еще, похоже, мы смогли решить нерешаемую проблему и пересечь два множества “не хватает нормальных кадров на рынке” и “без опыта меня никуда не берут”

Проблема компаний с недостатком сотрудников

Все мы с вами живем в очень странном мире, где большинство людей считает, что "the safety inspector is an asshole, the firefighter is a hero”. Собственно, и для многих IT-менеджеров “обеспечение качества продукта” звучит как некое душное “бла-бла-бла”. Этому способствует и похожее отношение со стороны многих заказчиков. Что, впрочем, в половине случаев объясняется неспособностью сейлзов влезть в потребности заказчика и создать у того понимание, что совокупная стоимость жизненного цикла качественного проекта обходится существенно дешевле.

У тех же, кто умеет продавать качественные продукты, встает древняя, как вечное зло, проблема кадров. С рынка все более-менее качественные QA-кадры высасываются быстро. Много “тестировщиков”, но у них соотношение КПД/управленческие+прочие расходы неудовлетворительное. Можно брать нулевых и учить самостоятельно. Собственно, к этому рано или поздно приходят многие компании, в первую очередь аутсорсеры и продуктовики.  

Но есть нюансы.

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

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

Проблема новичков с компаниями

Курсы тестировщиков, вроде бы, должны решать проблему предложения. Но они ее ухудшают.

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

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

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

Здесь опять же есть свое “но” - большинство интернатур проходит для галочки. В результате или вся группа сидит на тестовом приложении или тестирует некоего донора без доступа к API, базе и разработчикам. И то и другое подобно обучению на кависта по картинкам вина.

Пересекаем два множества

Каким образом нам все-таки удалось качественно смерджить два множества “не хватает нормальных кадров на рынке” и “без опыта меня никуда не берут”?

Все гениальное просто. Мы берем мотивированных кандидатов в QA, оставляем имеющих потенциал, даем им глубокие знания по теории тестирования и необходимые практические паттерны, а на выходе обучения формируем команду, где лидом выступает опытнейший QA-архитектор. В нашем понимании “опытнейший” - это имеющий более двадцати лет опыта работы в компаниях уровня Borland, Sun Microsystems, Oracle.

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

Эту задачу как раз и решает опытный QA-архитектор, который имеет опыт и может.

Он берет на себя вопросы коммуникации с владельцем продукта, менеджером проекта и разработчиками. 
Он берет на себя вопрос достижения удовлетворенности заказчика.
Он берет на себя вопросы работы с каждым из интернов. И вопросы отчисления с интернатуры тех, кто не тянет. Точнее, тянет команду назад.
И, что более важно, он берет на себя вопрос построения качества проекта с нуля на уровне ДНК. Даже если до этого конь не валялся.

Как показывает практика, такая комбинация позволяет принимающим проектам, то есть заказчикам, получать результат с отличным соотношением цена/качество, а начинающим тестировщикам входить в профессию не год-два методом проб и ошибок, а в режиме “сразу как надо”.

Топовый QA-архитектор стоит очень дорого, поэтому мы его ставим на проект только на три месяца. Точнее даже на два, так как за первые два месяца он должен среди 6-10 подчиненных разглядеть пару лидов - кандидатов на лидство, а третий месяц осуществлять только их управление и консультирование.

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

Сколько стоит праздник жизни?

Вообще QA-архитектор с опытом 20+ лет обычно стоит заказчику от $120/час или $20’000/месяц.

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

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

Таким образом, заказчик получает:

  • QA-архитектора с опытом 20+ лет.

  • 7-10 толковых джунов, которых по окончании проекта он может оставить себе в штат. А может не оставить. Никаких обязательств.

  • Все это за $0 без скрытых платежей и звездочек.

Наша схема подойдет не всем курсам тестировщиков

Почему? По той простой причине, что я руковожу одной из самых дорогих QA-школ в России и мы можем позволять многие такие вещи, которые просто не по карману другим курсам:

  1. Только 15 человек в группе. 16-го мы не берем никогда.

  2. Как следствие, имеем привилегию проводить входные собеседования. И отбирать только тех, у кого действительно есть задатки и у кого действительно горят глаза. А не тех, кто две недели назад узнал, что в айти можно по-быстрому зайти с заднего крыльца. Собственно, у нас есть и выходные собеседования с QA-ментором, и 1:1 перед началом интернатуры с QA-архитектором. Т.е. и поступить сложно, и выпуститься сложно. :)

  3. Топовые QA-менторы с опытом минимум 10 лет в IT, которые дают возможность каждому из этих 15 действительно учиться, а не “слушать лекции”. Для примера, Линуксу учит ведущий эксперт по безопасности в Acronis.

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

Для нас как для топовой QA-школы, важно, чтобы наши интерны-выпускники получали на выходе шести месяцев обучения и интернатуры крутой уровень теории и возможность вписать реальный бизнесовый опыт в резюме. Как результат, они выбирают между компаниями на свой вкус, а не бегают в табуне окончивших “одноразовые” курсы. Я не утрирую - уровень знаний на выходе такой, что в потоке, который недавно окончил основное обучение и ушел на интернатуру, несколько человек не стали на нее идти. Потому что уже трудоустроились на хорошие места.

Но подойдет большинству принимающих проектов

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

Mandatory Requirements:

  1. SUT (System under test) must have GUI (Graphical user interface). It could be Web UI, Mobile native application or desktop application.

  2. It must have some project documentation (e.g. project goals and purposes, component diagrams and description, features description, use case diagram and main business flows, deployment diagram, definition of data used by SUT, project requirements and so on). We do not expect the project to have all of that but at least something that interns could examine and base the testing documentation on.

  3. SUT should be in active development or at least have development support to fix issues.

  4. At least one internal milestones to emulate release preparation process

  5. Scope enough for N interns for at least 3 months.

  6. Access rights for QA Architect/Lead to setup or configure process key tools (defect tracking, task tracking, test documentation management, assets store).

  7. Dedicated environment for testing or instruction how to deploy locally or in clouds.

  8. Time of development team members (BAs if any, programmers) to clarify questions regarding the functionality and defects discussion.

  9. There must not be limitation by access to the SUT (e.g. 2 shared accounts for all testers).

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

Естественно, есть еще “Nice to have”, его я готова направить заинтересовавшимся.

Теги:
Хабы:
Рейтинг 0
Просмотры 39
Комментарии Комментировать