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

Итак, что же я называю задачами про “гномиков”? Проще всего начать сразу с примера. Знаменитая задача из Google, которая упоминалась в фильме The intetship (Кадры, 2013) и в десятках статей по прохождению собеседований.

Что вы будете делать, если вас уменьшили до 5-центовой монеты, бросили в блендер, который включится через 30 секунд?

Типичная задача.

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

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

• Задача формулируется коротко, но по мере решения могут всплывать новые подробности: размер блендера, способ уменьшения и так далее. Это задача с неявными условиями

• Решение задачи считается собеседующим оригинальным, нетиповым. Это задача на т.н. нестандартное мышление, что бы это ни значило

• Не смотря на прошлый пункт, у задачи есть явное однозначное решение, любое “оригинальное” решение считается неправильным. Это всё-таки задача с ответом

Это признаки можно взять в качестве определения, что же такое “задачи про гномиков.” Или, что ими не является.

• Если вы реально проектируете блендеры и вам нужно сделать их безопасными от попадания всяких гномиков (а то попадёте на судебный иск) — то это уже задача по работе

• Задачи вида “сколько бейсбольных мячей поместится в Боинг” предельно конкретны, и мячи и самолёты существуют в нашей Вселенной

• Если в качестве задачи вам дают чёткое ТЗ со всеми условиями, аспектами и так далее и по нему предлагают вам сделать короткую программку — это тоже совершенно другое

• Если вас просят написать эссе на какую-то тему — тоже можно выдохнуть. У такого формата не может быть явного правильного или неправильного ответа. Возможно, будут смотреть ключевые слова в вашем тексте, возможно, какие-то обязательные пункты-критерии (как в ЕГЭ), или вообще не будут читать.

Казалось бы, я должен любить такие задачи. Они близки к вопросам ЧГК, опыт игры должен мне помогать обходить конкурентов, да и просто приятно щёлкать задачи как семечки. На деле я точно не могу причислить себя к их фанатам, поэтому, как мне кажется, могу попробовать их разобрать объективно.

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

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

Кажется, и такие наивные люди ещё остались. Не смотря на личный опыт, на то, что даже Google, главный оплот «гномиков» на этой планете, отказался от этой практики.

Иногда, это более очевидно. Зачем нужна креативность и сообразительность офис‑менеджеру, дата‑инженеру или бухгалтеру? У них достаточно конкретные задачи, такие, что действия «свободного художника» могут сломать работу остальной команды, если не до уголовной статьи довести. Иногда — менее. Казалось бы, менеджерам или дизайнерам полезно смотреть outside the box. К сожалению, на данный момент до сих пор нет доказательств связи успешности решения задач «на сообразительность» ни с какими рабочими задачами. Корреляция есть только с вероятностью пройти собеседование.

Для справедливости нужно добавить, что IQ‑тесты, разряды по шахматам\го или серьёзные успехи в ЧГК тоже не показывают никакой корреляции ни с рабочими задачами, ни даже между собой.

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

К сожалению, есть большие сомнения даже в том, что успех в задачах «про гномиков» как‑то связан с умением думать. Дело в нескольких факторах.

Во‑первых, любые задачи «в вопросы и ответы» (IQ‑тесты, загадки, викторины) по определению одноразовые. Первый раз, возможно, это что‑то и показывает, но когда тебе ту же загадку тебе задают второй раз, она проверяет только память. Говорят, что задача «засвечена». Сравните с какими‑то задачками на алгоритмы. Даже если вы помните суть, ход решения и основные проблемы, которые вам встретятся, всё равно нужно сесть и написать код. В котором можно допустить парочку нелепых ошибок, назвать криво переменные и много чего ещё. Для «гномиков» же, решения которых выглядят простыми и лаконичными, никаких подобных сложностей нет.

К сожалению, одноразовые задачки собеседующие используют в лучшем случае так же, как одноразовые бритвенные станки. А это значит, что с очень большой вероятностью человек, который показал вам верное решение задачи, просто‑напросто заранее знает правильный ответ. Почему так? Ну давайте посчитаем.

• Согласно разным опросам от 70% до 90% соискателей готовятся к собеседованиям

• Популярные вопросы, которые задают в крупных компаниях, легко гуглятся

• Да и вообще классов вопросов “про гномиков” не так много. Можно потратить 6-8 часов и быть готовым к 90% таких “каверзных” вопросов

• По данным разных опросов hr, от 40% до 80% кандидатов врут в резюме или на собеседованиях, а доля “профессиональных проходителей собеседований” варьируется от 20% до 40% в зависимости от специальности и роли

• Число собеседований в жизни сеньора оценить сложно. Это зависит и от характера человека, от географии, фактор случайности тоже большой. Какое-то число в интервале от 10 до 80. Примерно то же самое с вероятностью знакомства (хотя бы через соцсети) с другими кандидатами на эту позицию, бывшими и текущими сотрудниками.

• Оценить, сколько людей в первый раз, справляются с той или иной задачей сложно. Эта доля не должна быть больше 50% заинтересованной (пришедшей на собеседование) аудитории, иначе сложно назвать её нестандартной. Кажется, что указанную задачу Гугла на самом деле в первый раз решило около 10%, но это недостоверная информация. Вопросы ЧГК, близкие по духу к “гномикам” (например, такой или такой) обычно даются тяжело и являются самыми сложными в своих турах (-10%-20% к числу взятых). В зависимости от уровня сложности это от 15% до 30%. И это не в среднем по IT-шникам, это по той аудитории, которой интересно играть в вопросы и ответы, которые собрались для этого в свободное время и заплатили за участие. Ещё там в команде 6 человек и минута на размышление. Чёрт с ней с минутой, но в индивидуальных турнирах результативность меньше (хотя это сложно оценить из-за того, что там разные вопросы). И, конечно, это число будет зависеть от сложности задачи. Ну, пусть будет 25%.

Итак, предположим, вы собеседуете на синьорскую востребованную позицию в хорошей компании с хорошими деньгами. Вы даёте им задачу «про гномиков». Возьмём оптимистичный сценарий. У вас 30% кандидатов — это «профессиональные проходимцы» собеседований. Другие люди, допустим 10%, подготовились ко встрече и через друзей‑коллег‑знакомых сузили круг возможных вопросов. Ещё 10% кандидатов просто уже видели эту задачу на прошлых собеседованиях. Все они ответят «правильно». Из оставшихся 50% кандидатов 25%, то есть 13% от общего числа кандидатов, услышат задачу в первый раз и решат её. Это значит, что если вы будете смотреть на выборку тех кандидатов, что вам ответили, на каждого «целевого» человека приходитсяпо 4 человека, которые являются шумом в том сигнале, что даёт вам ваша задача.

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

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

Увы, нет. Возможно, кто‑то из тех 10% опытных кандидатов вам скажет. Я тоже, дурак, так делал. Например, когда получал одну и ту же задачу на четвёртом собеседовании чуть ли не подряд. Но не все такие, можно сказать, мы их уже в учли в этих 10%. А вот ответ «профессионалов» вы не отличите точно.

Так вышло, что мне пришлось участвовать в процедуре ловли доказанных читеров в интеллектуальных играх. Честно вам скажу, до тех пор, пока они сами не сознавались, я до последнего рассматривал вариант какой‑то дурацкой ошибки. Тут тебе и «озарения» и зрелищный ход мысли во время того, как человек «думает». И возмущение в лучших чувствах, когда возникают сомнения в честности результата. Какие великие артисты погибают!

Так что, если у вас в команде нет театральных режиссёров или следователей, я бы не стал надеяться на то, что вы кого‑то там сможете различить.

— Ну есть же пути сделать соотношение вероятностей в этом калькуляторе приятнее?

Есть, не буду спорить.

Можно уменьшить сложность задачи. Если 90% заинтересованных решают её и так, смысла в спецподготовке немного. Но кого вы так фильтруете? Нет ли более простого способа с этим справиться?

Можно, повысить оригинальность задачи. Брать не первую, а 15-ую ссылку из гугла по запросу «задачи „с подвохом“ для собеседований». К сожалению, у этого есть свои минусы. Популярные задачи для собеседований ещё более‑менее норм с точки зрения корреляции сложности ну хоть с чем‑то. А вот «оригинальные» могут иметь как прямые дырки, так и просто очень плохи. (Ниже разберем почему). Это естественный отбор: чем лучше задача, тем она популярнее. К тому же, любые «внешние» (существующие «в гугле») задачи всегда уязвимы для атаки класса «профессор лопух, лопух, приём». Устный экзамен в вузе с микронаушником не является феноменом уже лет 15.

Можно самому придумывать задачи. Это радикальное решение. Но будут ли собственные задачи хороши? И один раз их же не получится придумать, надо поставлять регулярно. Сможете? Например, большинство игроков спортивного ЧГК не пишет вопросы. Обычно этим, причём за приемлемые деньги, занимаются специальные редакторы. Если вы можете в промышленных масштабах поставлять свежие задачки «на логику» и они будут постоянно хороши, может, вам стоит подумать о подработке или даже смене профессии? Кроме редакторов интеллектуальных игр можно попробовать основать своё HR‑агентство.

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

— В вопросах «на логику» важен не самом ответ, а возможность послушать, как кандидат думает.

К сожалению, это тоже не так. Этот класс задач — «на озарение», то есть невозможно составить план решения такой задачи и просто по нему идти. Поэтому тот подход, который хорош для алгоритмических сессий, тут не работает. Ситуация, когда человек думает над задачей и ситуация, когда его просят всё максимально вслух проговаривать — разные. Если не верите, можете попробовать посмотреть телеЧГК в те времена, когда обсуждение во время суперблицев (когда вместо команды играет один игрок) одобрялось. Да и сама игра норм была)) Один и тот же человек во время обычного вопроса и суперблица ведут себя совершенно по‑разному, это нормально. Это даже нынешняя телегруппа поняла и теперь игроки имеют право думать молча. Так вышло, что у меня тоже есть некоторый опыт игры и в суперблицах. Подтверждаю, это совершенно другой вид спорта, молчать гораздо эффективнее, чем вываливать на слушателя всё, что проносится перед тобой в этот момент.

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

Ну и, положа руку на сердце. Предположим, вам нравится задача и её решение. Вот человек будет говорить какие‑то разумные вещи, включит логику и придумает другое решение? Ну, например, для задачи с блендером предложит использовать мерную шкалу, которая часто бывает рельефной, как лестницу? Отличное решение! Оригинальное, свежее, яркое. Чем оно хуже авторского? Да оно лучше! Скажите честно, вы готовы признать, что это тоже ответ, захлопать в ладоши и предложить кандидату офер? Даже если готовы, вы в меньшинстве. Большинство просто переформулирует задачу: «что вы будете делать, если вас уменьшили до 5-центовой монеты, бросили в блендер с плоской мерной шкалой, который включится через 30 секунд?». И предложит думать дальше. Неявные условия такие неявные.

Увы, от шаблона «вопрос‑ответ» уйти невероятно сложно. В спортивном ЧГК есть механизм апелляций, но даже там есть свои сложности и засчитать можно далеко не любой оригинальный ответ. На собеседовании апеллировать некому. Психологический фактор тоже отбросить не получится: «ваша» версия всегда будет вам казаться лучше «чужой».

— Всё равно эти вопросы хороши для понимания ясности мышления и указанные выше проблемы можно или исправить или сделать не такими серьёзными.

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

То, что они все «свечки» (то есть уже задавались) мы разобрались. Мы проговорили и то, что они имеют дырки (возможны другие хорошие решения). Ещё можно сказать, что вопросам про гномиков просто не хватает редактуры.

Вот так мог бы выглядеть типичный вопрос «на сообразительность » на собеседовании:

Что может как поднять тебя в небо, так и опустить на глубину?

Лестница? Лифт? Самомнение? Знание? Воображение? В такой формулировке всё является ответом. Что же там написано на бумажке? Что‑то парадоксальное? Что‑то бесспорное? А чёрт его знает. И как объяснить кандидату, что его ответ неправильный? Можно сделать такую «подлость», как «метку»:

Отгадайте загадку: «Что может как поднять тебя в небо, так и опустить на глубину?»

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

Отрывки из перевода одной загадки с английского языка. ОН может поднять тебя в небо. ОН может опустить тебя на глубину. ОН может принимать разные формы. Назовите ЕГО.

Это делает вопрос не таким коротким и изящным. Вопрос становится проще. Хотя, если с ним имеет дело один человек, то не сильно. Ну и появляется повод назвать весь вопрос пижонством или постмодернизмом. Зато теперь действительно существует цепочка рассуждений, которая ведёт к нужной версии, а также помогает однозначно выбрать из всех вариантов правильный (если вы его придумаете, конечно).

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

Скорее наоборот, кандидата такие вопросы чаще «закрывают», особенно, если он не даёт правильный ответ. Есть мнение,что кандидата открывает small talk, уместные шутки, бытовые мелочи, обсуждение его опыта, общих знакомых или интересов. Но уж точно не ощущение того, что ты что‑то не ответил.

— Ну есть же кандидаты, с которыми больше не о чем разговаривать!

Видимо, они называются джуны или стажёры. Нет опыта работы, образования нет (или оно совсем другое), нет опыта прохождения ругаемых всеми онлайн курсов или пет‑проекта, абсолютная tabula rasa. В таком узком случае действительно можно задавать несложные вопросы «на логику».

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

В остальных случаях у вас всегда есть две хорошие темы для разговоров: задачи, которые нужно решать кандидату после офера и опыт кандидата. Если у вас есть возможность дать упрощённые версии боевых задач в боевых условиях — замечтательно. Аналитики в вашей компании используют Jupyter Notebook и гуглят куски кода на StackOverflow? Дайте кандидату возможность запустить у себя Юпитер и гуглить. Конечно, надо помнить про коммерческие тайны и персональные данные. В природе существует много генераторов и обфускаторов данных. Какой‑то пример всегда можно вырвать из прода, сделать ему «обрамление» и напилить на его основе задач.

Готовых задач в природе тоже хватает. Leetcode, sql-ex, тысячи их.

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

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

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

Ну если вам вот прям позарез хочется чего-то на логику, так задайте прямо вопросы ЧГК! Кое-кто так зачёты в вузе получал, ничего, все живы. Получите обкатанную “на бою” редакторскую работу, лишённую большей часть проблем, описанных выше. База большая, пользоваться ей можно бесплатно, выбирайте на свой вкус. Вот IT кубок есть, например. Вот хорошая серия для новичков. ЧГК, 60 секунд, брейн-ринг — почему нет? Только, ради бога, не надо использовать вопросы своей игры или квизов. Это немного другая история.

Я попросил прокомментировать мои мысли тех HR, которые нанимали меня, вместе с которыми я искал себе коллег и профессионализм которых у меня не вызывает сомнений. Часть из них оставили следующие комментарии:

Татьяна Долгова

ex-HR «Нетология групп»

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

Задавать правильные вопросы и уметь их интерпретировать непросто, это скилл, который нужно прокачивать. Именно нужно, а не можно. Хороший лид должен овладеть такой компетенцией. В конце концов есть HR-менеджеры, которые могут помочь.

У меня был заказчик , один из топ-менеджеров и основателей. Он проводил собеседование задавая задачку о вероятностях и бросках кубиков. Подробностей не помню, зато помню ответ: 3/4.

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

Кандидат — это человек и поэтому нужно отнестись к нему как к человеку, а не так, как, порой, к студентам относятся некоторые экзаменаторы. Мы уже все давно закончили школу и отучились в вузе, реальная жизнь сложнее. Возможно, вам попадется кандидат, который с блеском решит дюжину задачек, но при этом будет не способен работать в команде. Рано или поздно, вам придется с ним попрощаться. На собственном примере знаю, что порой важнее умение наладить доверительные отношения с коллегами, нежели обладать каким-то навыком. Например, у тебя случается сложный кейс и времени мало, ты идешь к тому, кто знает как. Он тебе объясняет, помогает и ты приходишь к результату и в сроки. Обычно в этом и суть. Ну и чем такой навык уступает способности решить задачку на собеседовании?

Денис Олейник

Personal Career Advisor Лаборатории карьеры Алёны Владимирской

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

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

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

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

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

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

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

Больше статей об аналитике, интеллектуальных играх, книгах и музыке — в моём канале в телеге.

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

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

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

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

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

Представленный в статье материал предполагает знакомство читателя с основами объектно-ориентированного программирования.

Типы шаблонов 

Существует три типа шаблонов:

• порождающие;

• структурные;

• поведенческие.

Порождающие

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

Существует несколько видов порождающих шаблонов:

• abstract factory;

• builder;

• factory method;

• lazy initialization;

• object pool;

• prototype;

• singleton;

• Multiton.

Рассмотрим каждый из них подробнее.

Абстрактная фабрика (abstract factory) – разновидность порождающих шаблонов проектирования, которые содержат интерфейс для создания взаимосвязанных объектов, но при этом не производят спецификации конкретных классов для этих объектов. То есть, абстрактная фабрика группирует индивидуальные, но связанные фабрики вместе без указания их конкретных классов.

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

Вот пример такого класса. В нем передаются данные (круг, прямоугольник, квадрат) в AbstractFactory, чтобы получить необходимый тип объекта.

public class AbstractFactoryPatternDemo {    public static void main(String[] args) {       //get shape factory       AbstractFactory shapeFactory = FactoryProducer.getFactory(false);       //get an object of Shape Rectangle       Shape shape1 = shapeFactory.getShape("RECTANGLE");       //call draw method of Shape Rectangle       shape1.draw();       //get an object of Shape Square        Shape shape2 = shapeFactory.getShape("SQUARE");       //call draw method of Shape Square       shape2.draw();       //get shape factory       AbstractFactory shapeFactory1 = FactoryProducer.getFactory(true);       //get an object of Shape Rectangle       Shape shape3 = shapeFactory1.getShape("RECTANGLE");       //call draw method of Shape Rectangle       shape3.draw();       //get an object of Shape Square        Shape shape4 = shapeFactory1.getShape("SQUARE");       //call draw method of Shape Square       shape4.draw();           } } 

Шаблон строитель (builder) предназначен для того, чтобы отделить конструирование сложного объекта от его представления, таким образом, чтобы в результате одного и того же процесса конструирования могли получаться разные представления. По сути, данный шаблон позволяет создавать различные варианты объекта, избегая при этом “загрязнения” конструктора. Полезно, когда у объекта может быть несколько разновидностей или когда в создании объекта задействовано много шагов. Вот пример TestBuilderPattern, показывающий, как использовать класс Builder для получения объекта

public class TestBuilderPattern {                 public static void main(String[] args) {                //Using builder to get the object in a single line of code and    //without any inconsistent state or arguments management issues                                                      Computer comp = new Computer.ComputerBuilder(                                    "500 GB", "2 GB").setBluetoothEnabled(true)                                   .setGraphicsCardEnabled(true).build();                 }  }

Фабричный метод (factory method) – предназначен для обеспечения возможности передачи логики создания объекта в дочерние классы. То есть, фабрика делегирует создание объектов наследникам родительского класса. Благодаря этому, мы можем использовать в коде программы не специфические классы, а манипулировать абстрактными объектами на более высоком уровне.

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

Шаблон объектный пул (object pool) это просто набор инициализированных и готовых к использованию объектов.  То есть мы можем не создавать объект, а просто взять его из пула.

В примере пул объектов управляет соединениями и предоставляет способ их повторного и совместного использования. Он также может ограничить максимальное количество объектов, которые могут быть созданы.

// Java program to illustrate  // Object Pool Design Pattern  abstract class ObjectPool<T> {      long deadTime;      Hashtable<T, Long> lock, unlock;      ObjectPool()      {          deadTime = 50000; // 50 seconds          lock = new Hashtable<T, Long>();          unlock = new Hashtable<T, Long>();      }      abstract T create();      abstract boolean validate(T o);      abstract void dead(T o);      synchronized T takeOut()      {          long now = System.currentTimeMillis();          T t;          if (unlock.size() > 0) {              Enumeration<T> e = unlock.keys();              while (e.hasMoreElements()) {                  t = e.nextElement();                  if ((now - unlock.get(t)) > deadTime) {                      // object has dead                      unlock.remove(t);                      dead(t);                      t = null;                  }                  else {                      if (validate(t)) {                          unlock.remove(t);                          lock.put(t, now);                          return (t);                      }                      else {                          // object failed validation                          unlock.remove(t);                          dead(t);                          t = null;                      }                  }              }          }          // no objects available, create a new one          t = create();          lock.put(t, now);          return (t);      }      synchronized void takeIn(T t)      {          lock.remove(t);          unlock.put(t, System.currentTimeMillis());      }  }     // Three methods are abstract  // and therefore must be implemented by the subclass  class JDBCConnectionPool extends ObjectPool<Connection> {      String dsn, usr, pwd;      JDBCConnectionPool(String driver, String dsn, String usr, String pwd)      {          super();          try {              Class.forName(driver).newInstance();          }          catch (Exception e) {              e.printStackTrace();          }          this.dsn = dsn;          this.usr = usr;          this.pwd = pwd;      }         Connection create()      {          try {              return (DriverManager.getConnection(dsn, usr, pwd));          }          catch (SQLException e) {              e.printStackTrace();              return (null);          }      }         void dead(Connection o)      {          try {              ((Connection)o).close();          }          catch (SQLException e) {              e.printStackTrace();          }      }         boolean validate(Connection o)      {          try {              return (!((Connection)o).isClosed());          }          catch (SQLException e) {              e.printStackTrace();              return (false);          }      }  }     class Main {      public static void main(String args[])      {          // Create the ConnectionPool:          JDBCConnectionPool pool = new JDBCConnectionPool(              "org.hsqldb.jdbcDriver", "jdbc:hsqldb: //localhost/mydb",              "sa", "password");             // Get a connection:          Connection con = pool.takeOut();          // Return the connection:          pool.takeIn(con);      }  }

Шаблон прототип (prototype) позволяет создавать объекты через клонирование других объектов вместо создания через конструктор. Такие шаблоны обычно применяют, когда требуется, чтобы система оставалась независимой как от процесса создания новых объектов, так и от типов порождаемых объектов.

Шаблон одиночка (singleton) это порождающий шаблон, который позволяет убедиться, что в процессе выполнения программы создается только один экземпляр класса с глобальным доступом. Данный шаблон можно использовать для координации с другими объектами, так как поля «Одиночки» будут одинаковы для всех, кто его вызывает.

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

public enum NazgulName {    KHAMUL, MURAZOR, DWAR, JI_INDUR, AKHORAHIL, HOARMURATH, ADUNAPHEL, REN, UVATHA  }  public final class Nazgul {    private static final Map<NazgulName, Nazgul> nazguls;    private final NazgulName name;    static {      nazguls = new ConcurrentHashMap<>();      nazguls.put(NazgulName.KHAMUL, new Nazgul(NazgulName.KHAMUL));      nazguls.put(NazgulName.MURAZOR, new Nazgul(NazgulName.MURAZOR));      nazguls.put(NazgulName.DWAR, new Nazgul(NazgulName.DWAR));      nazguls.put(NazgulName.JI_INDUR, new Nazgul(NazgulName.JI_INDUR));      nazguls.put(NazgulName.AKHORAHIL, new Nazgul(NazgulName.AKHORAHIL));      nazguls.put(NazgulName.HOARMURATH, new Nazgul(NazgulName.HOARMURATH));      nazguls.put(NazgulName.ADUNAPHEL, new Nazgul(NazgulName.ADUNAPHEL));      nazguls.put(NazgulName.REN, new Nazgul(NazgulName.REN));      nazguls.put(NazgulName.UVATHA, new Nazgul(NazgulName.UVATHA));    }     private Nazgul(NazgulName name) {      this.name = name;    }     public static Nazgul getInstance(NazgulName name) {      return nazguls.get(name);    }     public NazgulName getName() {      return name;    }  }

А обратиться к конкретному Назгулу можно с помощью следующего вызова:

LOGGER.info("DWAR={}", Nazgul.getInstance(NazgulName.DWAR));

LOGGER.info("DWAR={}", NazgulEnum.DWAR);

Структурные

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

Здесь тоже имеется несколько видов шаблонов. Рассмотрим кратко каждый из них.

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

Предположим, у вас есть класс Bird с методами fly() и makeSound(). А также класс ToyDuck с методом squeak(). Давайте предположим, что у вас не хватает объектов ToyDuck, и вы хотели бы использовать объекты Bird вместо них. Класс Bird обладает некоторой схожей функциональностью, но реализует другой интерфейс, поэтому мы не можем использовать его напрямую. Так что мы будем использовать шаблон адаптера. Здесь нашим клиентом был бы ToyDuck, а адаптируемым — Bird.

interface Bird  {      // birds implement Bird interface that allows      // them to fly and make sounds adaptee interface      public void fly();      public void makeSound();  }     class Sparrow implements Bird  {      // a concrete implementation of bird      public void fly()      {          System.out.println("Flying");      }      public void makeSound()      {          System.out.println("Chirp Chirp");      }  }     interface ToyDuck  {      // target interface      // toyducks dont fly they just make      // squeaking sound      public void squeak();  }     class PlasticToyDuck implements ToyDuck  {      public void squeak()      {          System.out.println("Squeak");      }  }     class BirdAdapter implements ToyDuck  {      // You need to implement the interface your      // client expects to use.      Bird bird;      public BirdAdapter(Bird bird)      {          // we need reference to the object we          // are adapting          this.bird = bird;      }         public void squeak()      {          // translate the methods appropriately          bird.makeSound();      }  }     class Main  {      public static void main(String args[])      {          Sparrow sparrow = new Sparrow();          ToyDuck toyDuck = new PlasticToyDuck();             // Wrap a bird in a birdAdapter so that it          // behaves like toy duck          ToyDuck birdAdapter = new BirdAdapter(sparrow);             System.out.println("Sparrow...");          sparrow.fly();          sparrow.makeSound();             System.out.println("ToyDuck...");          toyDuck.squeak();             // toy duck behaving like a bird          System.out.println("BirdAdapter...");          birdAdapter.squeak();      }  }

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

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

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

Зачастую возникает необходимость скрыть сложность системы от тех, кто будет с ней работать. Для этого существует шаблон с соответствующим названием – Фасад (Facade), который скрывает содержимое путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

Поведенческие

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

Шаблон цепочка обязанностей (Chain of responsibility) — позволяет организовать в системе  несколько уровней ответственности. Применяется, когда имеется более одного объекта, который может обработать определенный запрос или когда надо передать запрос на выполнение одному из нескольких объектов, точно не определяя, кому именно.

В примере ниже у нас есть интерфейс для обработки запроса и есть конкретные обработчики ConcreteHandler1 и ConcreteHandler2.

class Client  {      void Main()      {          Handler h1 = new ConcreteHandler1();          Handler h2 = new ConcreteHandler2();          h1.Successor = h2;          h1.HandleRequest(2);      }  }  abstract class Handler  {      public Handler Successor { get; set; }      public abstract void HandleRequest(int condition);  }     class ConcreteHandler1 : Handler  {      public override void HandleRequest(int condition)      {          // некоторая обработка запроса                     if (condition==1)          {              // завершение выполнения запроса;          }          // передача запроса дальше по цепи при наличии в ней обработчиков          else if (Successor != null)          {              Successor.HandleRequest(condition);          }      }  }     class ConcreteHandler2 : Handler  {      public override void HandleRequest(int condition)      {          // некоторая обработка запроса                     if (condition==2)          {              // завершение выполнения запроса;          }          // передача запроса дальше по цепи при наличии в ней обработчиков          else if (Successor != null)          {              Successor.HandleRequest(condition);          }      }  }

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

Посредник (Mediator) является поведенческим шаблоном, который обеспечивает взаимодействие множества объектов, позволяя объектам не ссылаться явно друг на друга.

Шаблон Итератор (Iterator) является объектом, с помощью которого можно получить последовательный доступ к элементам объекта-агрегата без использования описаний каждого из агрегированных объектов. Данный шаблон дает способ доступа к элементам объекта без показа базового представления.

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

abstract class Handler     public static void main(String[] args) {        NameRepository namesRepository = new NameRepository();           for(Iterator iter = namesRepository.getIterator(); iter.hasNext();){           String name = (String)iter.next();           System.out.println("Name : " + name);        }            }  }

Шаблон проектирования Хранитель (Memento) фиксирует и хранит текущее состояние объекта, чтобы оно легко восстанавливалось. То есть, мы можем, не нарушая инкапсуляцию, зафиксировать состояние объекта так, чтобы позднее восстановить его в этом состоянии.

Заключение

Тема шаблонов проектирования не ограничивается представленными в этой статье. Здесь мы рассмотрели только основные шаблоны проектирования и их виды.

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

Меня зовут Александр Яничкин, у меня небольшое маркетинговое агенство и я уже 6 лет занимаюсь таргетингом.

Недавно занялся вопросом системной лидогенерации на чеки от 30 000 рублей за 1 услугу. В процессе работы проанализировал методы получения таких клиентов у своих близких коллег и собранный материал изложил в данной статье.

Юнит — таргетолог или маркетинговое агенство.

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

Тезисно

• у всех так или иначе есть какой-то путь привлечения клиентов, но системно и управляемо это делают лишь треть юнитов;

• продают курсы или образовательные услуги ~60% юнитов;

• большие деньги (от 300к) получается делать, либо забирая % с бюджета, либо набирая более 15 проектов*).

Подробности, выводы, а также ответ на вопрос «Зарабатываю ли я больше 300 000 рублей?», ниже.

Каналы

Анализировал 11 каналов привлечения клиентов. Разбил их на 2 категории — управляемые и нет. Сравнил какое количество специалистов используют те или иные методы и получил:

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

• 35% юнитов запускают таргетированную рекламу на контентную цепочку писем или рассылку;

• Таргетированную рекламу на свои услуги запускают 28%;

• Выступают на конференциях и как-либо светятся личностью в медийном пространстве 21% юнитов;

• Рассылают резюме на сайтах с работой 21%;

• Балуются массовыми рассылками (спамом) 7%;

• Получают лиды с комментирования чужих постов или постов на профильных ресурсах 7%.

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

• Удивительно, что не ко всем приходят клиенты по сарафану, только 57% довольствуются этим источником на постоянной основе;

• 50% юнитов пишут контент на профильных ресурсах по бизнесу и маркетингу;

• Получают рекомендации из закрытых чатов предпринимателей 14% — это больше про маркетинговые агенства, чем про одиночек;

• Вертикальные видео из инсты, YouTube или TikTok работают лишь у 14%;

• Бартер, когда за рекомендацию выплачивается % от дохода с клиента, используют 7% юнитов на постоянной основе, хотя есть он, практически, у всех.

Для удобства, та же самая информация в виде таблицы:

Причем из всех юнитов регулярно постят контент на личной странице или в группе только 42%, а ведут рассылки через личные сообщения вдвое меньше (21%).

Примечательно, делают это самые богатые (по мнению автора) юниты.

Чем ещё занимаются юниты

• 64% инфобизят от личного бренда или продают наставничества/коучества/менторинг;

• 14% имеют свой проект — это либо образовательный проект, либо какой-либо другой бизнес, не путать с инфобизнесом или маркетинговым агенством;

• 14% работают в найме и совмещают с фрилансерской деятельностью.

Как все-таки заработать

По-настоящему хороший доход имеют лишь 28% юнитов. Под этим я подразумеваю стабильный систематический заработок от 300 000 рублей.

Больше 300 лично у меня не выходит.

Причем, заработать такую сумму именно на маркетинговых услугах можно 2 путями:

• брать % с бюджета клиента, в иной форме это может быть работа за привлеченные заявки или иной вид, главное, чтобы был % от результата;

• набирать большое количество однотипных проектов, то есть забрать 15 филиалов одной и той же франшизы или 10 школ программирования, но с разного ГЕО.

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

Выводы

• В первую очередь следует уделить внимание собственному контенту и продвижению через него.

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

• Обязательно необходимо догревать аудиторию через контент или рассылки.

• Заработать можно либо с % от бюджета в той или иной форме, либо за счет нишевания.

Мнение автора

А вообще, видимо, сделать на маркетинговых услугах 1 000 000 чистыми что-то нереальное. Поэтому, надо уходить либо в бизнес, либо менять сферу деятельности и уходить в найм, где платят действительно большие деньги (IT, crypto, менеджмент).

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

Привет, Хабр! Меня зовут Салават Сафиуллин, и сегодня я хочу поделиться с вами своим первым опытом создания дашборда на Visiology 3. Это новая версия платформы, которой мы пользуемся уже несколько лет, но она кардинально отличается как архитектурой, так и принципами работы. Дашборды на версии нужно создавать заново и по-другому. Поэтому мне было особенно интересно сделать пробу и подготовить дашборд на базе демонстрационной Visiology 3.0. Под катом — подробный рассказ о моем «пилоте» и некоторые мысли о работе с новой версией Visiology.

Изначально я не писал текст для блога Visiology, но когда опубликовал его “от себя”, мне написал модератор и сказал, что так делать нельзя. Вообще странно, ведь я делюсь опытом. Но, к счастью, бдительные коллеги из Visiology заметили пост до того, как его заблокировали и пригласили в свой корпоративный блог. 🙂 В связи с этим, рассказывать о платформе, наверное, смысла нет. Но если все же среди читателей есть те, кто не вникал глубоко, что такое Visiology, свое мнение о платформе уберу под спойлер. 

Visiology 3.0 — добро или зло?

Новости о том, что скоро появится Visiology 3.0, и что архитектура системы будет отличаться, и что нам придется рано или поздно мигрировать на третью версию не все восприняли с оптимизмом. 

Сначала казалось, что нам придется запускать очередной проект, ведь при переходе на версию 3.Х потребуется делать все заново. Однако по мере приближения релиза оказалось, что не все так уж страшно:

1. Для третьей версии Visiology не требуется никаких новых лицензий

2. Оба движка могут работать рядом, хоть на одном сервере, так что к миграции можно подготовиться

3. Поддержка 2 сохраняется как минимум до начала 2025 года, так что нас никто и никуда не торопит.

4. Visiology 3 работает на базе ClickHouse, так что она должна стать быстрее и бигдатее, чем предыдущая (хотя это пока в теории — чтобы проверить нужно хорошо нагрузить движок и посчитать цифры).

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

Как это делается в 2.29

Чтобы добавить источники данных во второй версии Visiology, необходимо подключить их через панель администрирования.

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

Когда мы заходим в панель администрирования Visiology 3.0, сразу видны разительные отличия. Первое и очевидное — новая схема работы с моделью данных. Я уже показал ее нашим аналитикам, и теперь они ждут, когда смогут сами перетаскивать панельки и протягивать стрелочки. 

Для того, чтобы добавить новый источник данных (пока это можно сделать только через JDBC), достаточно нажать правую кнопку и выбрать источник. После этого он появляется в модели данных как отдельное окошко.

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

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

На портале версии 2 дашборд из 3 версии виден в качестве окошка с открытым интерфейсом авторизации. Наверное, это потому что портал “не родной”. А может быть я пока не разобрался как сделать так, чтобы дашборд был виден полностью.

Если зайти в дашборд, то он раскрывается полностью, прямо на портале. 

Выводы

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

Тем не менее, первый опыт работы с 3.0 показал, что использовать платформу на полную еще катастрофически рано. В третьей визиолоджи нет кучи вещей, которых не хватает на фоне работающей 2 версии. По факту на платформе пока нельзя даже соединить две таблицы фактов  (а ведь это must have практически в любом проекте). Так что сегодня у меня фактически есть просто демка, которая позволяет поиграться с графической моделью данных. Тут еще крутым плюсом должен стать DAX, но у нас в штате пока нет ex-Power BI спецов, так что тестирование этого функционала мы отложили на попозже. Потенциальное повышение производительности еще предстоит оценить, но это, наверное, я буду делать уже когда получу доступ к Visiology 3.2, которую (надеюсь) можно будет считать полноценной платформой. 

В любом случае 3.0 (и думаю, что 3.1) будут скорее демонстрационными версиями. Так что с одной стороны я рад, что у нас уже есть работающая BI-система, и мы не сидим, не гадаем, ждать очередных версий Visiology 3 или внедрять пока 2.29, а с другой стороны — конструирование первой модели данных и дашборда уже помогли мне заинтересовать аналитиков новыми возможностями Visiology 3, и это точно будет полезно, когда мы подойдем к процессу миграции.

Кстати, если среди читателей попадутся пользователи Visiology, расскажите, а вы уже пробовали новую версию платформы? Что думаете по этому поводу?

Часто в начале спринта у тестировщика нет задач. Ну а что, тестировать еще нечего, приходится ждать готового функционала.

Давайте рассмотрим стандартные этапы разработки новой фичи: создание дизайна, верстка, разработка, тестирование. И всё здесь так, но где-то между ними затесалось создание тестовой документации.

Как выглядит сценарий работы, к которому нужно стремиться:

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

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

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

4. Фронтенд разработчики приступают к верстке, мы параллельно работаем над чек-листом.

5. Бэкенд разработчики приступают к работе, наш чек-лист готов.

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

Почему такой поход — это хорошо?

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

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

В-третьих, вы будете понимать апдейты по этой задаче и от дизайнеров, и от фронтов, и от бэков.

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

Как происходит обычно и почему это плохо?

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

Потому что тайминг. Потому что заказчику всегда нужно вчера, если фича уже готова к тестированию, с 99% вероятностью никто не захочет ждать, пока вы напишите какие-то сценарии и только потом приступите к тестированию. 

В таком подходе только постфактум, когда мы закончили с тестированием фичи, мы создаем задачи на создание чек-листа и тест-кейсов.

Сравнивая с предыдущим подходом к работе, здесь, очевидно, степень погружённости в задачу минимальная. Во время её разработки мы сосредоточены на другом, мы не идем в параллели с девами. Конечно, это понижает качество тестирования.

Как переходить к новому подходу?

Если работа уже выстроена на старом проекте, изменения должны быть постепенные.

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

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

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

По ней проще определять, что именно брать в работу. Начинать стоит с основного функционала и с самого «страшного» — всё что связано с деньгами.

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