Текст книги "IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит"

Глава 3
Начало. Получение вакансии

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

Встреча с заказчиком и определение профиля кандидата, или, как это часто называют, «снятие заявки»,[3]3
  Кстати, именно такую формулировку чаще используют в кадровых агентствах.


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

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

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

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

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

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

● Узнать немного лучше личность человека, с которым вы будете общаться. Для этого полезно изучить его соцсети, посмотреть, что он пишет и как. Или же не пишет вовсе. Эта информация поможет вам лучше говорить с человеком «на одном языке».

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

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

Итак, предварительная работа проделана: статус проекта понятен, заказчик изучен, вакансия испещрена комментариями и вопросами. Что дальше? Дальше – сама встреча. Основная ваша задача на ней – понять правильный профиль кандидата, которого вы будете искать. И очень важно, чтобы в этом вопросе заказчик вам помогал и был с вами на одной стороне. Хотя иногда его и нужно возвращать к реальности. Но сначала предлагаю разобраться с тем, какие вопросы по вакансии вы можете задать.

Я бы условно поделил их на несколько групп.

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

● Чем занимается компания?

● Сколько в ней человек, какая структура и география?

● Какие планы по развитию на текущий год?

● Кто основные конкуренты, есть ли среди них компании-доноры (то есть те, в которых можно будет искать людей на вакансию)?

● Почему сотрудники в принципе выбирают эту компанию?

● Почему клиенты ее выбирают?

Вторая группа – вопросы о проекте. По факту они очень тесно связаны с вопросами о компании и как бы вытекают из них.

● На какой проект ищут человека, на какой стадии сейчас проект?

● Сколько человек на проекте?

● Сколько человек в команде, в которую ищем кандидата?

● Какая методология разработки? Если гибкая, то насколько Scrum[4]4
  Scrum – один из фреймворков гибких подходов к разработке. Подробнее мы о нем поговорим далее.


[Закрыть] (или не Scrum) чистый, какие элементы внедрены?

● От кого поступают задачи?

● Есть ли code review[5]5
  Code review – это практика, когда более опытный разработчик или команда совместно с автором просматривают написанный кусок кода, анализируют и рецензируют его с целью нахождения узких мест, ошибок и выявления наиболее оптимальных решений. В современных IT-компаниях эту практику в большинстве случаев стараются внедрить.


[Закрыть] (для разработчиков)?

● Есть ли система контроля версий (СКВ)[6]6
  Система контроля версий – это специальное ПО, сохраняющее различные версии проекта, чтобы впоследствии была возможность вернуться к предыдущей версии. Например, если новые доработки оказались «кривыми» и повлекли много ошибок (багов), которые не были замечены при тестировании. Еще важная черта системы контроля версий – это возможность писать проект одновременно нескольким разработчикам и даже командам разработки.


[Закрыть], какая? (Скорее всего, это будет видно в описании вакансии, самые популярные СКВ – Git, SVN, Mercurial, TFS.)

● Как часто бывают релизы[7]7
  Условно релиз можно назвать анонсом, выпуском нового функционала ПО.


[Закрыть]?

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

● Какие задачи будет выполнять кандидат?

● Какие задачи сейчас есть в бэклоге[8]8
  Бэклог – список задач, которые нужно выполнить команде, отсортированный по приоритетности их выполнения. Термин как раз относится к семейству гибких методологий, о которых мы говорили выше.


[Закрыть] (если по-простому – в пуле)?

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

● Представим себе ситуацию, что кандидат сегодня вышел на работу. Какие задачи он получил бы прямо сейчас?

● А через месяц/полгода?

● Зачастую полезно узнать, в каком процентном соотношении и какие задачи будут у кандидата. Например, если мы ищем фронтенд-разработчика[9]9
  Фронтенд-разработчики – это разработчики видимой на веб-странице части программного обеспечения, то есть того, что мы с вами можем увидеть как пользователи.


[Закрыть], важно понять, какой процент его времени будет занимать верстка, так как не все фронтенд-разработчики готовы заниматься ею в каком-то существенном объеме.

По факту всеми этими вопросами мы пытаемся разговорить оппонента и собрать по крупицам информацию, которую сможем добавить в вакансию. Но не стоит пугаться: не все IT-специалисты будут сидеть и отмалчиваться. Большинство из них будут рады услышать от вас такие вопросы, рассказать подробнее о задачах и помочь вам накидать такого смыслового «мяса» в вакансию, чтобы кандидаты на старте лучше понимали, с чем им придется столкнуться.

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

● Какой текущий стек[10]10
  Стек технологий – это набор элементов, языков программирования, фреймворков, библиотек, который используется для разработки проекта.


[Закрыть]? Какая архитектура проекта?

● Планируются ли какие-то изменения в стеке? Этот вопрос можно конкретизировать. Например, если в вакансии мобильного разработчика указано знание Objective-C, обязательно стоит уточнить, планируется ли переход на Swift, так как Objective-C – устаревающая технология и специалистов с ней искать будет сложнее и дольше.

● Есть ли на проекте legacy-код[11]11
  Legacy-код – устаревший код, который необходимо поддерживать. Обычно, если его много, это означает отсутствие новых интересных задач для разработчика, а значит – сложности в поисках для вас.


[Закрыть]? Если да, какой процент задач будет составлять поддержка legacy, а какой – разработка нового функционала?

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

● Важно также обратить внимание на сам стек и на мелочи, которые могут быть указаны в стеке, но существенно усложнят поиск или окажутся нелогичными. Так, если продолжить пример с вакансией мобильного разработчика, в ней может быть указан еще и такой язык программирования, как C++. Это язык, который напрямую не относится к мобильной разработке; важно понимать, для чего его добавили, какие задачи на нем будет выполнять кандидат.

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

Пятая группа вопросов – о вакансии. Эта группа посвящена текущему статусу поисков и должна помочь вам на старте прикинуть сложность и узкие места будущего поиска. Кроме того, задавая эти вопросы, мы так или иначе узнаем о важных для заказчика soft skills и о его собственных.

● Почему вакансия открылась? Если вакансия на замену, чем не подошел предыдущий сотрудник?

● Как строится наем в компании сейчас, сколько человек на вакансию успели посмотреть, на каком этапе отваливается наибольшее количество кандидатов и по какой причине?

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

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

● Есть ли пример идеального резюме? Это вообще отличный вопрос, который позволяет вам еще раз сверить ваши «хотелки» и четче понять, совпадают ли ваши с заказчиком взгляды на идеальных кандидатов.

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

● Какая вилка зарплаты? Готовы ли рассматривать более высокую? Если найдется идеальный кандидат, но на 10/15/20 тысяч дороже, готовы ли будете обсуждать бюджет? Какие навыки должны быть у специалиста, чтобы готовы были предложить ему зарплату по верхнему пределу? Для рекрутера это еще один триггер, ведь то, как заказчик опишет профиль кандидата, ради которого можно будет идти обсуждать бюджет вакансии или которому можно будет дать максимальную зарплату, обозначит рекрутеру еще раз наиболее критичные и важные для заказчика моменты в вакансии. Иногда оказывается так, что после этого вопроса заказчик отвечает, что максимум в вилке получит только кандидат, реально соответствующий всем параметрам. Тогда становится понятно, что, скорее всего, реальная вилка несколько занижена, потому что идеальных мало / не существует.

● Белая зарплата или серая? Ой, нельзя мне такое писать в книгах: это ж может оказаться, что у нас в стране есть серые или даже черные компании. А они есть. Только не рассказывайте государству – оно ж не в курсе. И для кандидатов это может быть критичным моментом, не уточнив который вы потратите свое и их время, а еще можете и на негатив нарваться. Так что да, это важный вопрос.

● Какой соцпакет? Есть ли ДМС? Если да, то что включает? Распространяется ли на семью? Компенсация фитнеса, питания, обучения, проезда, телефона?

● Какой график работы? Если гибкий, что это значит: с которого и по который час можно начинать или заканчивать работу?

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

● Есть ли релокационный пакет? Если да, что включает? Готовы ли в принципе смотреть иногородних кандидатов? А иностранных? С каким гражданством?

● Есть ли парковка около офиса? Корпоративный транспорт, если офис далеко от метро?

● Как бы продавал вакансию кандидату сам заказчик? На чем бы делал акцент? Почему он сам работает в компании и на этом проекте?

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

● Какие личностные качества важны?

● Какие люди хорошо приживаются в команде? Почему?

● Какие, наоборот, не приживаются никогда?

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

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

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

Обязанности:

■ Разработка нового функционала.

Требования:

■ Опыт разработки на JavaScript.

■ React.js.

■ Понимание концепции REST, HTTP-запросов.

Желательно:

■ Опыт верстки с использованием css3, постпроцессоров, LESS, SASS.

■ Знание библиотек работы с состоянием приложения flux, redux (желательно).

■ Опыт тестирования компонентов.

■ Опыт работы с TypeScript.

■ Знание принципов работы сборщиков Webpack, Gulp.

Итак, давайте приблизительно переведем на более понятный язык то, что мы сейчас прочитали:

● JavaScript (JS) – один из наиболее популярных языков программирования, на котором чаще всего делается пользовательский интерфейс (фронтенд-разработка).

● React.js – JavaScript-библиотека с открытым исходным кодом для разработки пользовательских интерфейсов, облегчает программирование на JS (в следующих главах мы подробно поговорим про то, что это такое).

● REST – это стиль архитектуры программного обеспечения для распределенных систем, отвечает за правила работы с URL-адресами страниц.

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

● css3 – язык описания стилей: с его помощью создатель веб-страницы задает цвета, шрифты, расположение блоков и т. д.

● LESS, SASS – языки, созданные на основе css для реализации тех же целей – оформления веб-страницы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть].

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

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

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

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

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

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

[13]13
  ¹³ Берем реальные задачи.
  ¹⁴ Прописываем важность (по нашему мнению) каждой.
  ¹⁵ Ставим оценку этому параметру: насколько менеджер по продажам сможет выполнять эту задачу.
  ¹⁶ Дальше прописываем риски, которые видим в вакансии.
  ¹⁷ Здесь же наоборот: чем ниже риск, тем ниже балл; чем выше риск, тем выше балл. Вероятность того, что менеджеру по продажам надоест делать то, что он и так делал сто лет, кажется высокой.
  ¹⁸ Из итога оценки по задачам мы вычитаем риски, чтобы получить балл, на который будем опираться в дальнейшем.


[Закрыть]