Еще раз про "одомашивание"
Несколько интересных выводов про риски «in-house» разработки — что может случиться если вы решились «одомашить» программиста.
По мотивам серии переговоров, которые стоили нам больших усилий.
Шел второй час не самых простых переговоров, все участники начали уставать, но голос пока сорвать не успели.
— Мы все же считаем, что внешняя разработка несет для нас слишком большие риски. Так что не вижу вариантов. Синергии нет.
— Андрей у вас же частный дом?
— И большая семья, а живете вы все вместе.
— Не понимаю какое это имеет отношение к вопросу.
— У вас ведь нет личного сантехника, верно?
— Пока не доросли до такого уровня, увы.
— И полагаю, нет планов выделить в вашем доме отдельный кабинет для сантехника и платить ему зарплату?
— А что будет, когда канализация в вашем доме выйдет из строя?
— Плохо будет. Будем мучаться и быстро искать специалиста чтобы починил. И... что с того?
— Но при этом у вас нет планов нанять сантехника «в штат» и платить ему зарплату.
Получается, есть вполне осязаемые риски, поскольку канализация это критическая часть инфраструктуры вашего дома и если она вдруг выйдет из строя — размеренной жизни «пользователей» придет конец.
Даже можно примерно подсчитать ваши финансовые потери — минус минимум один рабочий день для каждого члена семьи, в качестве прямого ущерба и неделя для восстановления обычного графика жизни.
Уверяю — возможный убыток от такого неприятного инцидента будет существенно выше зарплаты сантехника, так что такой найм вполне осмысленен.
Кстати как насчет электричества?
Нанять электрика к себе в штат не планируете?
Не буду дальше утомлять читателей детальным пересказом, этот диалог был лишь одним из многих раундов в тех сложных переговорах.
Но диалог тем не менее показателен:
отличная иллюстрация вечной темы про «риски внешних исполнителей», которая уже всем причастным до одури надоела, которая мешает работать — взрослым людям приходится долго и терпеливо, раз за разом доказывать что ты не верблюд.
Почему-то никому из директоров в голову не приходит нанять сантехника или электрика в качестве сотрудника в штат, но эти же люди постоянно рассуждают о «рисках аутсорса».
Ну да ладно, давайте теперь расскажу о реальных рисках «одомашивания» диких программистов и возможных последствиях.
Job security
Людям свойственно переносить свой жизненный опыт, взгляды и интересы на окружающих, поэтому идея «одомашить программиста», чтобы он работал на вас за зарплату чаще всего посещает именно честных представителей бизнеса.
Из тех, кто добился высот исключительно своими силами, без «протекции, фелляции и пенетрации».
Поэтому считают, что нанимаемый на высокий оклад специалист также является честным и порядочным человеком.
Именно таким джентельменам стоит вбить в поисковик термин «job security» и немного задуматься.
«job security» это западный термин, под которым понимаются не всегда приятные и законные меры, предпринимаемые программистом для удержания на рабочем месте, чтобы его не смогли уволить без серьезных последствий для бизнеса и быстро найти замену.
Такая страховка от увольнения.
Например запутывание исходного кода проекта, для сопровождения которого программист был нанят.
Или усложнение сборки проекта и ее непредсказуемость — когда вместо автоматики в виде скриптов или выделенного сервера, проект начинают собирать локально на машине разработчика, настройки которой разумеется нигде не описаны.
Плюс добавляют пару ручных шагов — с подкладыванием файликов в нужные места.
Есть варианты частичного скрытия исходного кода, например часть проекта выделяется в подключаемую библиотеку, исходный код которой затем объявляется руководству «безвозвратно утраченным».
Существуют и более тонкие методы, вроде «забытых» коммитов и искусственного устаревания исходного кода в репозитории проекта.
А если такой «одомашенный» программист отвечает еще и за выкладку обновлений и соответственно имеет доступ к продуктовым серверам и базам данных — ситуация может резко стать совсем печальной.
Для вас и вашей компании, разумеется.
Общий смысл всех этих хитрых планов — набить себе цену, стать незаменимым для компании и заодно заставить вас умыться кровью при любой попытке увольнения такого персонажа.
Ну и выкручивать вам руки в процессе.
Большие компании, у которых давно есть собственные компетенции от такого защищены и имеют стойкий иммунитет в виде юристов, безопасников и кадровиков — все эти люди быстро, качественно и на ранних этапах свернут ласты такому любителю «job security».
Доверенный сантехник
Круто наверное иметь личного парикмахера-стилиста, гинеколога психолога или юриста, но как только дело доходит до «своих» программистов обязательно начинаются проблемы.
приходите к парикмахеру, а он начинает вас стричь... инструментами из 17-го века.
Обращаетесь к юристу — он ссылается в составленном им сложном юридическом документе на... Рона Хаббарда или сериал про Покемонов.
Варианты с гинекологом скромно опущу.
Но такая дичь хотя-бы заметна и вы сможете понять что «что-то не так» без посторонней помощи.
А с программистами и программами все не так просто и однозначно:
Хера с два вы сможете их проверить, своими силами.
Плохие программы — тоже программы, которые тоже работают, а чтобы отличать плохой код от хорошего люди учатся примерно десятилетие.
Промышленная разработка ПО — сложный и специфичный процесс, который требует специальных инструментов и инфраструктуры, которую врядли вы готовы разворачивать самостоятельно.
При этом точно такой же прикладной софт совершенно спокойно может быть создан... школьником на домашнем компьютере — это тоже правда.
И да, такое ПО тоже будет успешно работать.
Короче говоря, никаких однозначных критериев или внешних признаков, по которым у обычного человека без технической вышки и десятка лет опыта получится отличить плохую программу от хорошей — не существует.
Отсюда вытекает логичный вопрос:
как оценивать работу «одомашенного» программиста, которого вы с таким трудом нанимали?
И программисты об этом знают, поэтому вне специализированных компаний (где могут настучать по голове за кривой код) — всеми способами «срезают углы».
Просто чтобы пораньше уйти домой, забив на все заботы.
Теперь вы тоже знаете, почему любой «in-house» центр разработки у любой компании, кроме занимающейся разработкой ПО как бизнесом — полное говно.
Вне зависимости от класса офиса, наличия Playstation или бюджетов на разработку.
Единственное известное автору исключение — когда компания выстроена вокруг ИТ-системы и по-сути занимается ее обслуживанием: Яндекс, Авито, Майлру и так далее.
Вырастание
То что описано выше про «job security» — все же крайность, да так тоже бывает, но достаточно редко, поэтому не стоит относить вообще всех программистов к членам клуба «любителей пощекотать очко».
Куда чаще нанимая себе разработчика в штат вы столкнетесь с другой проблемой:
ребенок учился, учился и вырос, став взрослым.
Та самая «проблема роста», ага.
Если у вас есть дети, то могли заметить как быстро они растут и как часто приходится менять им гардероб целиком, потому что из старой одежды они уже выросли и в нее больше не влезают.
Точно также растут в уровне знаний и программисты, поэтому очень скоро, в пределах 2-4 лет им станет в вашей компании тесно.
Врядли ваш бизнес ожидает настолько сказочный рост, чтобы айтишники смогли реализоваться в нем целиком и за одно поколение — такое является редкостью даже для западного мира.
Собственно это было редкостью даже для годов быстрого роста индустрии — в 70е и 80е.
Так что рано или поздно (скорее рано) ваш «одомашенный» разработчик перерастет масштаб компании и покинет гнездо, вместе с вашими надеждами и инвестициями.
А вам придется искать следующего, еще полгода.
Эпилог
Если начать перечислять все возможные риски, возникающие с вами в течение жизни — можно легко и просто #бнуться.
Просто представьте насколько много всего может зависеть от одного конкретного человека, если выборы президента в одной известной стране чуть было не дошли до гражданской войны.
А ведь он может заболеть или стать недееспособным в любой момент и без предварительного уведомления.
На фоне всего этого дурацкая идея, что внешняя компания, для которой разработка софта является ежедневной работой, может стать неким «риском» для своих клиентов, который еще и необходимо немедленно устранить, пытаясь сделать ее работу самому — лютая дичь.
Подсчет степени которой оставлю на усмотрение вашей фантазии.