● Flux, redux — это библиотека для управления состоянием приложений.

● TypeScript — расширенная версия JavaScript, которая позволяет упрощать и ускорять разработку крупных JS-приложений за счет добавления типизации, классов и модулей.

● Webpack, Gulp — инструменты, которые собирают разбросанные по модулям файлы проекта, объединяют в единые файлы в правильном порядке и ужимают их в размере.

Казалось бы, описание достаточно детальное. Но все равно вопросы остаются. Вот только некоторые из них:

● Какой новый функционал нужно будет разрабатывать конкретно? В обязанности входит только новый функционал или поддержка старого? В каком соотношении?

● Какого опыта разработки на JS будет достаточно? Задачи какого уровня кандидат должен уметь решать?

● Насколько критичен опыт с React? Готовы ли смотреть с другими фреймворками? А с нативным JS (то есть без использования фреймворков)?

● Насколько хорошо нужно понимать REST? Кажется, если кандидат с опытом, он априори понимает REST. Какого уровня тогда нам нужен специалист?

● Сам ли он будет верстать или есть верстальщики? Какой процент задач по верстке, какой — по разработке?

● Правильно ли понимаю, что flux — обязательное требование, а redux — опциональное? Готовы ли смотреть кандидатов без redux?

● Надо тестами код покрывать или целиком процесс тестирования проводить? Есть ли тестировщик в команде?

● Насколько критичен опыт с TypeScript? В сравнении с остальными технологиями, что из них важнее, без какой точно не будете смотреть кандидатов?

● Опять-таки возникает вопрос о требуемом уровне специалиста. Кажется, что большинство фронтов с Webpack работали.

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

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

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

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

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

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

Помните, что чем точнее вы поймете заказчика на данном этапе, тем эффективнее будет ваша работа.

Еще одна ситуация, с которой вы также можете столкнуться, — заказчик и сам не понимает, кого же он хочет найти. Так часто бывает, если вакансия для компании или для рынка в целом — новая. В такой ситуации я сам оказался однажды: у меня была вакансия человека, каких на рынке не существует. Мы запускали стартап, и нам нужен был специалист с комплексным функционалом — набором навыков, которым ни один среднестатистический существующий специалист не обладает. В попытке расписать все детали и сделать нормальное описание вакансии я записывал всё и вся — и так и не мог понять, что за специалист у меня вырисовывается. Ведь профили очень разные: то ли мне нужен уставший от рекрутмента рекрутер, то ли аккаунт-менеджер из онлайн-школы, обучающей IT, то ли просто аккаунт-менеджер, то ли деврел[12].

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

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

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

Теперь по-человечески. Допустим, я не могу понять, кто мне нужен — менеджер по продажам или менеджер по поддержке клиентов. Я создаю таблицу.

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

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