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

Качество+Скорость+Цена

Всеми любимая диаграмма Эйлера-Вента с почти научным оправданием причин "долго/дорого/плохо". На самом деле она должна выглядеть иначе: ответственность плюс компетентность. Ответственность без компетентности - дает только нервы и игру в слепой случай. Компетентность без ответственности - требует оправданий результатов. Наличие и того и другого - дает результаты в рамках обещаний. Как раз то, что нужно.

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

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

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

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

Адекватность vs Хитрохвостость vs Технические навыки

Вообще здесь "vs" ставить не правильно, но если не разобраться в том что такое softskill и hadrskill, то получается что хотябы одна их "vs" остается :-) Давайте попробуем обойти и эту проблему.

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

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

Всё чаще и чаще умение нагло врать называют "softskill". Это невозможно срезать на одном техническом собеседовании. Чаще всего попытка поймать на вранье на единственном техническом собеседовании отбрасывает действительно широкопрофильных и опытных специалистов и нанимает только тех кто умеет что-то одно.

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

sudo docker ps -a | grep Exit | xargs docker rm -f 

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

Лучшие вопросы на тему будут иметь формат нахождения несколько решений этой задачи. Пример может быть простой: "Нам нужно обрабатывать post-запрос с json, записывать данные в базу максимально быстро, ответ отдается всегда статичный 200 OK. Нужно 3 варианта решения". Вообще вариантов тут масса, в зависимости от используемого стека технологий и от окружения.

Ну допустим

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

• А давайте поговорим о религии?

• А давайте поговорим о политике?

• А если я прикинусь идиотом, поймет ли он, что я его проверяю? Воспримет ли в шутку или разведет паранойу?

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

Итог найма команды

Быстро ли мы так найдем команду? Нет, не быстро. Зато плюсы очевидны - стабильная команда, которой по плечу всё, на что они скажут "да, мы это сделаем". Возможности масштабировать бизнес путем передачи микросервисов подрядчикам (важно найти тоже ответственных).

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

Самый сложный вопрос - перспектива. Лично у меня возникали следующие возражения и следующие ответы на них получились:

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

• При быстром росте количества задач, потребуется быстро нанять несколько человек и это не срастётся. Ответ: не потребуется, так как рост задач не произойдет в страшных величинах. Всё дело в том, что команда фокусированная на результат генерирует крайне мало техдолга, высокосвязанного кода и прочих генераторов внезапных багов. Количество багов в работе с имеющимся сервисом в районе 1-2%. В работе с новым, с нуля, написанным сервисом, отправленным на различные тесты (нагрузки, функциональные, тестовые внедрения, первые реальные внедрения) - 10-15% со снижением до 1-2% за начальный срок активной борьбы с багами.

• Зарплаты и повышения - при долгосрочной совместной работе нужно индексировать ЗП, иногда индексация воспринимается как халява и снижает уровень ответственности. Ответ: изначальную ЗП давать выше рынка, чтобы хватило на 1.5-2 года без повышений. Не индексировать ЗП для человека который не ростет в компании. У нас рост получаемых денег всегда ассоциирован с ростом зоны прямой ответственности. Для хорошего специалиста, за 1,5-2 года изучившего все системы и сервисы с которыми связана его работа, поработавший с подрядчиками, прошедший 2-3 успешных внедрения продукта - рост есть вообще всегда, просто потому что бизнесу это выгодно.

Слишком радужно

Понимаю как эта статья звучит для большинства. Собственно потому и пишу, ибо нет смысла писать об обыденности. Чтобы понять зачем мне это было всё нужно опишу наше окружение (что мы делаем, зачем и почему):

Мы создаем высоконадежные технические решения для нужд инфраструктуры, передачи данных, обработки данных. Ряд проектов имеет требование в виде "0 ошибок в год на боевых системах" (конечно под это есть сотни тестовых систем с такой же нагрузкой, но меньшими требованиями).

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

Стек технологий:

• Debian Linux 9/10/11, Raspberry Pi OS

• Основной код на C, C++, Часть сервисов Golang

• Web интерфейсы: PHP 7.4, Yii2, vue.js, jQuery (не смейтесь, но для нас оптимально иногда иметь просто один jQuery на фронте)

• БД PostgreSQL

• RabbitMQ