Привет.
Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.
Некогда, забавы для и пользы ради, я подрабатывал в одном неплохом кадровом агентстве — собеседовал приходящих программистов на предмет знания C#/.NET. В мои обязанности не входило полное техническое интервью — скорее, начальный скрининг кандидатов чтобы понять who is who, отфильтровать совсем уж ужас и в случае чего дать советы что почитать и как усовершенствовать навыки. И был у того кадрового агентства один интересный клиент. Он у всех на слуху, но тогда мне про него мало что сказали — я только понял, что вроде как ищет он rock stars — высококвалифицированных разработчиков, при том независимо от используемых технологий. После того, как я порекомендовал для них несколько человек — со мной связалась заместитель ген. директора и пригласила на встречу, ибо мои рекомендации не совсем устраивали заказчика. Так я познакомился с учредителем. Там мне была рассказана очень интересная история о том, зачем им нужны rock stars и как это всё вместе работает. Оказалось что вовсе не rock stars нужны. Нужны, как дал мне понять руководитель — люди с крепкими фундаментальными знаниями (алгоритмы, проектирование, операционные системы, сетевые технологии), которые будут готовы к росту и развитию. И вот они их берут и развивают, а затем отправляют реализовывать довольно сложные аутсорс-проекты. Заодно мне рассказали какие проблемы в этом плане испытывает компания. Я ушел в раздумьях и довольно долго катал в голове эту бизнес-модель, равно как и мысли о российской IT-индустрии в целом и политике работы с кадровым составом в частности.
В конечном итоге, через несколько лет я, наконец, утряс всю имеющуюся у меня в голове информацию и уложил её в модель, которая согласуется с окружающей реальностью. Это дало ответ на вопрос почему кадровый пайплайн упомянутой выше компании идеологически не может работать, а заодно и много другой интересной побочной информации. Так родилась моя классификация разработчиков по типажам.
Важно понимать что нет "плохих" типажей. Если какой-то из типажей вам кажется плохим, то вы просто не умеете его готовить. Помним: каждой задаче — подходящий инструмент. Я расскажу про все 4 типажа в виде карточек, давая краткую характеристику, указывая бэкграунд, цели и мотивацию, а так же рассказывая про сильные и слабые стороны. Особенно стоит уделить внимание бэкграунду, так как в конкретный типаж люди вырастают из своего бэкграунда. Начнем мы с чего по-проще.
Линейный программист
Соль индустрии IT-шной. На таких людях, говорят, мир держится. Он же "хомячок". Он же "гребец на галере", но я предпочитаю избегать таких ярлыков, поэтому просто — "линейный программист". Он не хватает звезд с неба, не пишет своих компиляторов и СУБД. Ну максимум — сделает пару инструментов, чтобы облегчить себе жизнь, в остальном — просто решает рабочие задачи. Редко меняет место работы. Усидчив. К работе относится как к работе, без особого энтузиазма. В меру ленив. Дисциплинирован (но бывают исключения), однако без надлежащего управления быстро "расхлябывается" и теряет фокус. Управлять такими людьми можно по стандартным методикам — описанным например в книге Дж. Рейнвотера — Как пасти котов. Квалификация может варьироваться и определяется исключительно опытом и количеством проектов, в которых линейный программист принял участие. Иногда квалифицированные линейные программисты попадают на минимальные управленческие должности — их нарекают team lead и тут-то вышеуказанная книга им и пригождается. Но самая главная особенность линейного программиста — весьма частое отсутствие желания развиваться и экспериментировать. Он прекрасно решит даже очень нудную задачу, которую вы ему предложите, если та не будет слишком сложной. Он выберет как можно более быстрый и прямолинейный инструмент из тех, что знает. Развитие для этих людей носит спорадический характер и в основном идет "вширь": изучить новый фреймворк или новый инструмент, который поможет лучше решать повседневные рабочие задачи. Или "пришел заказчик, который использует вот такую штуку — ну что уж, будем разбираться". Примечательно, что знания полученные в результате спорадического развития отдельных линейных программистов как раз и составляют опыт аутсорс-компании. Однако, двигать горы и исследовать окружающий мир "вглубь" самостоятельно линейного программиста чаще всего просто не тянет. Например изучать новый, хайповый язык программирования ему просто не интересно. Только если новый язык помогает в решении повседневных задач. И уж тем более разрабатывать свой язык — увольте. И это — нормально. Хуже всего то, что линейные программисты "каменеют" когда долго сидят на одном месте. То есть если у вас есть человек, который стабильно занимается концептуально одними и теми же проектами на протяжении 3-5 лет — то очень маловероятно, что он сменит типаж и будет развиваться "вглубь". Но вот раньше этого эмпирического срока — все возможно и зависит от бэкграунда.
Бэкграунд: разный. В "линейных программистах" могут оказаться и люди, прошедшие онлайн-курсы, и выпускники ВУЗов, некоторые олимпиадники, бывшие ученые технических направлений и даже люди из концептуально другой профессии (известны случаи когда дальнобойщики становились разработчиками на PHP). Важно понимать, что линейный программист — само по себе является бэкграундом и почвой для прыжка в другой типаж. Но! Прыгнет человек или нет — зависит прежде всего от его личных желаний, а не от навыков. Наличие того или иного бэкграунда определяет лишь направление потенциального прыжка, а не его вероятность! А вот вероятность прыжка с течением времени резко падает. Однако если вам нужен верный сотрудник на долгосрочный контракт — научитесь выявлять желающих "прыгнуть" заранее. Сбежит с проекта — будет неприятно.
Ценит: стабильность, среднюю, но 2-раза-в-месяц-стабильную зарплату, покой и личные отношения в коллективе, нормированный рабочий день, офисные плюшки вроде бильярдной, фруктов по выходным, оплаты проезда или тренажерного зала, мед. страховку и (возможно нудную, но) ненапряжную работу.
Сильные стороны: усидчивость, ответственность, коммуникабельность (раз на раз), полная контролируемость, спокойное поведение в стрессовых для проекта ситуациях
Слабые стороны: сложные и/или нестандартные задачи, абстракции, поведение в стрессовых для компании ситуациях, говнокод опять же
Собеседование: стоит уделить внимание психологии: усидчивость, дисциплинированность, коммуникативные навыки, стремления, вот это всё. Так же имеет смысл поговорить о предыдущем опыте и посмотреть в резюме. Дать стандартное тестовое задание а-ля "написать чат на web sockets", смотреть на сроки выполнения, "вылизанность" задачи и адекватность подобранных инструментов. Хорошо идут технические вопросы на знание языков, протоколов, паттернов и стандартных бибилотек. Плюсом будет если соискатель уже имеет опыт конкретно с вашим набором фреймворков, но если нет — не беда. Если все остальное в порядке — разберется. Это его работа.
Чего спрашивать не стоит: не спрашивайте почему люки круглые (вообще ни у кого это не спрашивайте), не просите его развернуть красно-черное дерево маркером на доске, дать оценку сложности алгоритма, произвести топологическую сортировку или спроектировать высоконагруженную систему. От этого линейному программисту нехорошо, хочется врезать вам по тыкве и убежать.
Rock star (Software Scientist)
Концентрированный исследователь. Такие больше похоже на классических ученых, но только от IT. Им интересны алгоритмы, теоретические исследования, концептуально новые направления в индустрии, но прежде всего — им интересно экспериментировать. Ради этих экспериментов их и нанимают, собственно. Они готовы часами копаться в сложных штуках и решать задачи, постановка которых другим людям даже не понятна. Они — эксперты в сложных вопросах. Они точно знают в каких случаях q-sort стоит заменить на heap sort и чем они отличаются, или может быть какие алгоритмы кластеризации подойдут для анализа потока биржевых котировок, а иные знают какие оптимизации используются внутри g++ и как они помогают жить. Костяк таких людей, например, способен разработать новый язык программирования и компилятор к нему. Или значительно улучшить какую-бы то ни было существующую систему. Еще они часто предрасположены к функциональному программированию. Ни на что не намекаю — просто статистическая закономерность. Кстати, говнокодить rock stars могут (особливо на стадии прототипирования идей), но в массе своей не допускают плохой код до финальных версий разрабатываемых ими вещей, стараются сделать все красиво, с комментариями и удобными программными интерфейсами.
Но.
Как всегда есть "но", которое все портит. Важно понимать что ни при каких условях эти люди не будут решать ваши задачи. То есть да — rock stars будут решать те задачи, которые интересны им. За ваши деньги. И при том — за большие деньги. И при том — не факт что будет какой-то результат. То, что ваши задачи совпали с задачами, которые интересны rock star — очень и очень большая удача и счастливое стечение обстоятельств, не более. Но если завтра rock star-у взбредет в голову контрибьютить в GHC вместо улучшения вашей сборки MySQL — то у вас будет ограниченное количество времени чтобы быстро и решительно его уволить. При попытке заставить оного вернуться к своим задачам — получите, в зависимости от темперамента и ваших soft skills, или конфликты или тихий провал сроков. Ну хорошо хорошо, чтобы людей так капитально разворачивало — это бывает редко и происходит постепенно, да. А вот обратная ситуация — если пересадить rock star с улучшения вашей сборки MySQL на улучшение GHC против его желания — бывает достаточно часто. И, как нетрудно заметить, приводит к аналогичным последствиям. И именно это обстоятельство делает rock star категорически неприемлемым для аутсорса.
Именно поэтому rock stars лучше всего чувствуют себя в продуктовых компаниях (например JetBrains), где им дают полную свободу в рамках одного продукта и полностью исключают внезапную смену скоупа задач (разве что только через увольнение). Люди получают возможность заниматься теми задачами, которые им интересны, самореализовываться, раскрываться и их при этом особо никто не дергает. Получается хорошая штука — окей, идет в релиз. Нет? Ну и черт с ним. В таких условиях rock stars пускают корни, живут весьма долго (до десятка лет) и им хорошо.
Со стороны менеджмента здесь требуется легкий и ненавязчивый контроль — так, чтобы rock star не разбредались и их не "заносило" в бесперспективные эксперименты. Ну и так же мягко доносить, что та или иная интересная ему разработка нерелевантна.
Есть другой замечательный пример работы с rock stars — это Google, в котором rock star-у дают возможность заниматься тем, что он хочет. Google их кормит, поит, одевает и защищает от внешних угроз. Взамен — все, что rock star наизобретает — будет принадлежать и продвигаться Google, превращаясь в его продукты. Fair enough. Эдакие посевные инвестиции в отдельно взятой компании.
Бэкграунд: лицей или другая хорошая школа, высшее образование в хорошем ВУЗе по IT-специальности или же математике. Круглый (хотя бы овальный) отличник. Вероятно, участие в серьезной научно-исследовательской деятельности (научные публикации как плюс) и/или олимпиадное программирование прямо со школы.
Ценит: покой (пока решает задачу), свободный ненормированный график с возможностью удаленной работы, адекватность менеджмента, возможность поработать с другими rock stars, сложные, интересные и нестандартные задачи, стабильное финансирование. Офисные плюшки или воспринимает как должное или игнорирует напрочь, но в целом не испытывает к ним особого пиетета.
Сильные стороны: сложные задачи, исследовательская деятельность, нередко проектирование.
Слабые стороны: зачастую наличествуют проблемы в коммуникации, отсутствует стрессоустойчивость, нестабильность в компании или проекте легко спугивает rock stars, жестко поставленные сроки превращаются в стресс, невозможность переключаться по предметным областям — только разве что по своему желанию. Не смотря на всю творческость, несамостоятелен за пределами своих задач.
Собеседование: алгоритмы и структуры данных, оценки сложности, олимпиадные задачи — ваши надежные друзья. Можно заставить разворачивать дерево на доске (но зачем?) — но гораздо лучше дать несложную математическую задачу. Главное не спешите и не торопите: дайте человеку подумать столько, сколько ему нужно. Творческие задачи, задачи на соображалку (ну только не про люки же!) и задачи на проектирование в формате "давайте порассуждаем" и "предложите решение" так же неплохи. В резюме смотрите на образование и публикации. Поспрашивайте про участие в олимпиадах, научно-практических конференциях, поинтересуйтесь темой дипломной работы. Если рассказывает с горящими глазами — вы нашли то, что нужно. Так же стоит удостовериться, что соискатель знает в совершенстве какой-нибудь язык программирования (любой), иначе не очень понятно как он будет реализовывать свои эксперименты.
Чего спрашивать не стоит: не задавайте глупых вопросов. К глупым вопросам относится: детали реализации чего-либо а-ля "а что делает HTTP-заголовок Content-Length?", вопросы про коммуникативные навыки и прочая психология (да, rock stars могут обладать абсолютно мерзким характером — но что поделаешь, такова плата за них), и уж тем более не заикайтесь и даже не думайте проверять стрессоустойчивость. Пунктуальность проверяйте только на уровне "не пропадает на неделю и ладно".
Делец (Software Engineer)
Редкий зверь в наших краях. Его иногда называют "ориентированный на результат", "любой каприз за ваши деньги". Эдакий линейный программист, который неожиданно (а на самом деле — предсказуемо) обзавелся самостоятельностью, самомотивацией и начавший расти туда, куда считает нужным. Это не rock star, потому что его не интересуют глубокие и абстрактные задачи. Его интересуют работающие инструменты, приносящие конкретную, ощутимую пользу, которую можно потрогать руками здесь и сейчас (зачастую — в виде хрустящих купюр в кармане, но об этом позже). Если работающего инструмента нет — делец делает его для себя сам. Очень любит конкретику в постановках задач, в технологиях и — что самое важное — в общении. Про таких еще говорят "строгий, но справедливый". Коммуникативные навыки хорошие. Политкорректен, дружелюбен, не тяжел, хотя бывает грубоват и склонен к занудным формальностям. Делец таков не от хорошей жизни, потому как грубиянов и молчунов суровая реальность дельца быстро ставит на место. Будешь грубить — угрохаешь репутацию. Будешь молчать — не получишь заказы. Не будешь избегать и разрешать конфликты, лезть на рожон — останешься без денег. Материалист. Работает с теми задачами, которые ставит для него объективная реальность. Если чего-то не понимает — спрашивает и добивается конкретного ответа. Его хлеб — тщательно подобранный или разработанный собственноручно инструментарий, опыт, умение разбираться во всякой гадости в приемлемые сроки и работа на скорость и на качество. Инструментарий подбирает сам или посоветовавшись с другими дельцами — и не дай вам б-же дать ему совет в этот момент. Ответственный. Хороший делец не срывает сроки и обеспечивает рабочий и поддерживаемый продукт. К говнокоду относится как к одному из инструментов. Может занять технического долга, если это уместно и полезно в конкретной ситуации, учитывая специфику проекта. Сведущ в менеджменте. Нередко понимает в нем больше, чем непосредственный начальник. На основании этого может рекомендовать ad-hoc управленческие решения. Из профессиональных изъянов стоит отметить невнимательность к мелочам, но и это у хороших дельцов лечится.
Крутое описание — не правда ли? В чем же подвох? Подвоха тут два. Первый заключается в том, что делец не терпит над собой никакого начальства, особенно если оно менее квалифицированно чем сам делец. Во многом это обусловлено той самой осведомленностью о способах менеджмента. Ну еще и тем, что делец сам прекрасно понимает как делаются деньги в IT-индустрии. Как следствие — делец не подчиняется приказам. Делец сотрудничает в рамках контрактов. Любая попытка заставить дельца делать что-либо за пределами контракта (если не формально подписанного — то хотя бы устно оговоренного) — ведет к вежливому отказу в лучшем случае или к расторжению контракта в худшем. Если делец не подписывался отсылать вам ежедневные отчеты — он этого делать не будет. Если не подписывался тратить на вас 8 часов в день (при наличии сроков сдачи задания) — то он этого делать не будет. Если не подписывался на правки по проекту — ну вы поняли. Однако если вы выкупаете оптом какое-то кол-во рабочего времени дельца (без конкретных сроков и конкретных задач), то он с радостью будет выслушивать ваши стенания, невнятные требования, поддакивать и участвовать в любой корпоративной шизе — ну а что? Уплочено же. Любой каприз за ваши деньги.
Второй подвох заключается в самом отношении дельца к деньгам. Делец не подвержен нематериальной мотивации. На ваши "компания будет оплачивать вам тренажерный зал, обеды и котиков по пятницам" скорее всего ответит "давайте лучше деньгами". А денег делец любит много. И не просто много, а очень много. Да, он лоялен к нестабильности выплат, к переработкам и к оплате за результат, однако эта оплата должна быть большая.
Долгосрочными контрактами на маленькие ежемесячные суммы его не заманишь. Только на большие — выкупайте рабочее время оптом, да. Как следствие — делец часто меняет место работы (в той мере, в которой для него существует это понятие). Засидишься — станешь линейным программистом. Как следствие — квалифицирован решать довольно широкий спектр задач. Помните — хороший делец всегда стоит своих денег. А если вы не дадите ему достаточно денег — делец попытается реквизировать рычаги управления. Разными способами — от наглого увода заказчика и команды (если у него есть такие полномочия), до честного разговора по душам. Если это не удастся — он вас быстро и решительно покинет, потому как а зачем? Хорошие дельцы заканчивают открытием собственных компаний, но, как было сказано выше, дельцов в нашей стране в принципе мало.
Бэкграунд: часто самоучка. Занимается программированием потому что интересно. Высшее образование наличествует, но стоит смотреть на репутацию учебного заведения. Если учебное заведение серьезное — то троечник. Ибо как работает с первого курса. Да и вообще изучению всяких наук предпочитает по-скорее добраться до реальной работы. Очень часто фрилансит. У некоторых дельцов проблемы с фундаментальными знаниями. Однако если это точно делец — то эти проблемы легко решаются.
Ценит: высокую оплату своих услуг (именно в такой формулировке), соблюдение договоренностей, качественные решения проблем. График и плюшки — по договоренности, но обычно предпочитает свободный график, не привязанный к месту работы с фиксированными целями, а плюшки — да выдайте лучше деньгами.
Сильные стороны: широкая и в меру глубокая квалификация, самостоятельность, ответственность, ориентированность на результат, толерантность к нестабильности в компании (пока соблюдаются его контракты), толерантность к недолгосрочным контрактам и внезапным их расторжениям (не нарушениям, а расторжениям я сказал!), слоновья стрессоустойчивость.
Слабые стороны: высокая стоимость (в 2 раза выше чем у линейных программистов и это только начало), могут и сами нарушать обязательства договора (это если делец плохой и ни на что не годный — или просто начинающий), неуправляемость в режиме "я начальник-ты дурак" (если не уплочено), краткосрочность планов, непунктуальность если иного не предусмотрено договором.
Собеседование: хорошего дельца найти трудно. Ваш друг — репутация. Посмотрите резюме, не поленитесь связаться с человеком, который сотрудничал с соискателем ранее. Если речь идет об удаленной работе — посмотрите что у соискателя с доступностью. Как быстро он отвечает на почту и сообщения, телефонные звонки. Если лично — насколько пунктуален по назначенным встречам. Дальше расспросите о знаниях требуемой технологии. Но только так — без фанатизма. Конечно неплохо если делец точно знает какой адрес в памяти у функции закрытия подключения в проприетарной библиотеке, которую вы используете — но поверьте, это не то, что следует спрашивать. Неплохо будет попросить примеры проектов, которые делец уже реализовал на вашем стеке/с использованием вашей технологии. У хорошего дельца всегда найдется что показать и рассказать. Задачи на проектирование и "как решить вот эту проблему с заданной технологией" идут на ура, особенно если приправлять проектными деталями (например решить задачу в условиях когда заказчик требует релиза каждую неделю и т.п.).
Чего спрашивать не стоит: алгоритмические вопросы, математика, задачки на внимательность и прочая чепуха, которую спрашивают у rock stars. Разве что только на уровне концепции. Ну то есть делец может в общих чертах знать что такое, скажем, бикубическая интерполяция, но не заставляйте его реализовывать её на бумаге или на компьютере без интернета — будете справедливо (но вежливо) посланы. Отдельным пунктом следует упомянуть тестовое задание. Не давайте стандартных тестовых заданий: хороший делец таких заданий за всю жизнь переделал столько, что вам и не снилось и еще одно ему вот вообще не нужно. Далее. Смиритесь с тем фактом, что тестовое задание — это трата рабочего времени дельца. Приготовьтесь к тому, что оно будет платным. Предложите заключить NDA, временный контракт и сделать, например, коммит с фиксом бага для какого-нибудь вашего продукта или какой-либо системы с условием оплаты по выполнению и оговоренными требованиями к качеству. Это — самый эффективный метод. Не забудьте рассказать как настроить окружение. У хорошего дельца это не займет много времени, но бывают казусы.
Пассажир (business bullshitter)
У этого типажа много "ласковых" названий в народе. Наименее квалифицированные коллеги ему подчиняются, более квалифицированные его не любят. Начальники таких обожают и дальше я объясню почему. Кратко: пассажир харизматичен. Всё. Много и красиво говорит, но катастрофически мало (или некачественно) делает. Повышенная коммуникабельность — его хлеб и зачастую пассажир попадает на менеджерские должности, так как не знает как сделать самому, но обладает достаточным ораторским талантом чтобы заставить работать кого-то вместо себя, и — более того — убедить начальника что именно он и должен руководить проектом. Во всем он демонстрирует серьезность, рвение и уверенность в себе, стремится порешать любую проблему, организовать совещание и обсудить, обязательно учитывая мнение команды. Со стороны может показаться что у него шило в известном месте. Он почти всегда на связи, всем отвечает на письма, показательно вежлив (так, что врезать порой хочется извините вырвалось) и может найти подход хоть к самому дьяволу. Один только минус — техническая квалификация. По правде говоря, ему не очень нравится программирование (вплоть до отвращения), но очень нравится покомандовать. Поэтому слабую техническую квалификацию (или её полное отсутствие) он часто "замазывает" красивыми словами, показным участием, заинтересованностью, дружелюбием и коммуникабельностью. Одна из самых страшных ошибок — ставить таких людей на средние менеджерские должности в командах. Как только вы это сделали — всё. Вы больше не получите достоверных данных о том, что происходит внутри команды с технической точки зрения. У вас будет красиво представленный бриф по происодящему, но те места, которые пассажир не понимает на техническом уровне будут из него исключены. А это в 90% случаев — скрытые проблемы и разнообразные детонаторы.
Тем не менее, грамотно подобранный пассажир может помочь команде общаться с заказчиком. Например, для пассажира ничего не стоит убедить заказчика перенести дату релиза — и при этом последний еще и будет думать что это наилучшее решение. Использовать пассажиров в роли дипломатов для заказчиков — одно удовольствие. Однако помните: харизматичные пассажиры — это как токсичный анестетик широкого спектра действия. Имеет смысл периодически опрыскивать им заказчиков, однако утечка бочки анестетика внутри команды приводит к весьма плачевным последствиям.
Бэкграунд: "лидер класса", "альфа-самец" в университете (жалко что не проверишь никак). Мистер обаяние. Образование может быть разным. Однако имейте в виду, что оценки могли получаться так же через ораторский навык. Программированием мог начать заниматься потому что интересно, но с таким обаянием у него были вещи в жизни и по-важнее. Нередко имеет свой персональный web-сайт на отдельном домене. Сделал его сам.
Ценит: все то же, что и линейный программист минус работа, плюс возможность поруководить.
Сильные стороны: коммуникабельность, способность убеждать, способность доносить информацию красочно, с шутками-прибаутками, про стрессоустойчивость лучше спрашивать отдельно
Слабые стороны: техническая квалификация. Многие технические вещи способен понимать лишь тезисно. Активен, но быстро теряет интерес и концентрацию на сложных и средних технических задачах. А в худшем случае — и вообще на любых задачах.
Собеседование: определитесь с тем нужен вам пассажир или нет. Если нет — при повышенной общительности и дружелюбности соискателя — держать ухо востро. Настоящие специалисты ведут себя спокойно. Старайтесь отсеивать красивые слова, общие утверждения, а выделять суть сказанного. Поинтересуйтесь достижениями в техническом плане. Попросите показать свой домашний проект, объяснить как он работает. Хорошо помогают те же вопросы что и для линейных программистов. Следите за тем, чтобы там, где соискатель не знает — честно говорил "не знаю", а не пускался в пространные рассуждения. Ну и тестовое задание как всегда. Если к тестовому заданию будет объемное пояснение, в коде — не продраться от комментариев и соискатель рвется объяснить как он это сделал — перед вами пассажир. Ежели пассажир вам все-таки нужен, то поинтересуйтесь как бы он объяснил заказчику срыв сроков релиза. Так же душевный разговор на предмет знания методик управления — SCRUM, PMBOK и разбор управленческих кейсов — могут возыметь положительный эффект. Но это уже история не про программирование.
Чего спрашивать не стоит: в случае с пассажиром — запретных тем нет (в рамках приличия). Если возникли подозрения на то, что перед вами пассажир — попробуйте вот что: задайте какой-нибудь вопрос, на который технический соискатель бы отказался отвечать по причине нерелевантности. Поговорите… Ну я даже не знаю. Про то, какую музыку любит соискатель, или фильмы, или игры. Или куда он ездил путешествовать. Если перед вами пассажир — то будет длинный рассказ. Если вы ошибаетесь — то вам ответят кратко и тезисно.
Выводы
Отдельной строкой стоит заметить, что четкой границы между этими типажами нет. Человек вполне может находиться где-то между дельцом и rock star, или rock star может дрейфовать в сторону пассажира. А прямо сейчас какой-нибудь линейный программист может перепрыгивать в дельца, увольняясь с уютной галеры и заводя аккаунт на UpWork. Поздравим же его с этим! Однако концептуально я склонен считать, что стабильно и в долгосрочной перспективе любой программист плотно обосновывается в одном из этих четырех типажей.
Возвращаясь к описанной первоначально ситуации. Если вы набираете и растите потенциальных rock stars, то использовать их на аутсорсных проектах — это как забивать микроскопом гвозди. Если же вы выращиваете дельцов — будьте готовы делиться деньгами и полномочиями. А для решения задач аутсорса вполне подходят крепкие линейные программисты. Если это сложный аутсорс — то с добавлением одного rock star или дельца в команду на "птичьих правах". В противном случае, если вы культивируете rock stars в своей компании, но у вас аутсорс — то смиритесь с тем, что единственный возможный способ на этом заработать — забирать себе промежуточные артефакты их работы. После того, как они вырастают — их надо отпускать. При том отпускание должно быть встроенно в саму бизнес-модель и кадровый пайплайн компании. Так вижу.
Именно это я бы и хотел объяснить учредителю компании из начала статьи. Но сейчас для него, боюсь, эти знания уже нерелевантны.
Спасибо за внимание! Хороших вам кадров!
