Дело в том, что TargetProcess и её сотрудники свято чтят soft skills. Они очень любят рассказывать о себе. Например о том, как они обходятся без менеджеров и директора по управлению персоналом, какой у них стильный офис и как они получили ажно $5 млн инвестиций. Выходят хвалебные статьи, основатель активно визионирует, а члены самой-звёздной-команды выкладывают в командный инстаграмм фотографии с котлетами бабла. Короче, все при деле — «мы продуктовая компания, а не вот эти вот… ГАЛЕРЫ», «мы как белорусский Google!».
С самого начала у меня было какое-то внутреннее ощущение что дело тут нечисто. При таких замашках надо действительно быть стоящим игроком. Я насторожился, но в итоге списал всё на «должно быть я что-то не понимаю». Кажется, это называется эффект Даннинга-Крюгера. Но пост-фактум все странности становятся очевидны и я долго ругал себя за невнимательность.
Собеседование в TargetProcess квалификацию особо не проверяет, что явно не уровень продуктовой компании. Пусть так — у меня есть Github-аккаунт, у меня есть Хабр, у меня есть UpWork с отзывами, мою квалификацию можно проверить тысячью и одним способом, не задавая глупых вопросов про GetHashCode.
Чего действительно не ожидаешь от места, где «важны soft-skills» — собеседуют одни люди, а в команду попадаешь совершенно к другим. Уже это должно было стать красным флагом, но я, видимо, слишком наивен.
От момента, как я принял оффер до моего фактического приезда прошёл МЕСЯЦ. 30 дней. Четыре рабочих недели. Если компания декларирует упор на общение и софт-скиллы, то за эти 30 дней можно было организовать бесчисленное количество онлайн-встреч, посмотреть на меня через камеру, поговорить со мной текстом, голосом, познакомиться, выпить через skype в конце концов, дать тестовую задачу. Да господи, хоть онбординг провести и сказать мне по итогу — мол, нет, чувак, извини, не подходишь. Просто чтобы не дёргать меня через пол-страны и не жечь мои деньги. Но ничего из этого компания не сделала.
Кстати, про онбординг.
— Чем я могу помочь команде? Давайте для ознакомления я починю несколько застарелых багов, чтоли. Руки чешутся.— Это так не работает — ответил мне человек, играющий в тимлида— А как оно работает?— Ну… не знаю… Я ожидаю некой автономности от своих сотрудников… Ну возьми разгреби воон ту штуковину.
Вот и весь тебе онбординг в устах Андрея Хмылова. Замечательный процесс, заточенный под быстрое и эффективное введение новых людей в работу над кодовой базой с более чем 15-летней историей. Особое внимание стоит обратить на заинтересованность, ответственность и готовность помочь.
Помогает в процессе онбординга полностью отсутствующая документация. Кусочек readme.md в репозитории, где-то документ в облаке, где-то заметка в личном блоге, где-то схема в онлайн-рисовалке, ссылка на которую передаётся из уст в уста. Передавать из уст в уста — наиболее общепринятый способ распространения информации о системе. Намеренно объяснять никто ничего не собирается — «ожидается автономность от сотрудников» ©.
Общего списка всех репозиториев, ссылок на них и объяснения, что в них есть — так же нигде нет. Системный администратор сделает вам пользователя чтобы вы могли залогиниться на свою рабочую машину — всё остальное в режиме «ну… попроси кого-нибудь». Вместо назначения ответственных за процесс принимается гениальное управленческое решение — закрыть информационные дыры с помощью soft-skills. Браво, узнаю управленческие практики google.
Какая ирония: компания, делающая инструмент для управления процессами разработки не может наладить процессы разработки сама у себя. Как это вообще блин работает?
Это очень похоже на job security driven development. Намеренно ограничивать знания о системе, чтобы никого не рискнули уволить и зарплату повышали не из-за профессиональных качеств, а потому что «никто же больше в этом не разберётся!». Страх, что «в системе больше никто не разберётся» довольно распространён в нашей сфере, но давайте замнём для ясности и коротко пройдёмся по самой системе чтобы понять, так ли всё плохо.
Система
Процессный и организационный бардак ни о чём не говорит при условии, что сама система сделана на совесть. Но
«Любая организация, проектирующая систему неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации».— Закон Конвея.
Старик Конвей и здесь оказался прав.
Первое, что я увидел — единого кода системы не существует. Есть разные куски, написанные в разное время, разными людьми, с разными взглядами и разными убеждениями по вопросу «как надо». Разумеется, все они уже уволились, онбордить сотрудников никто не планирует, поэтому разбираться надо с нуля.
Если долго всматриваться в этот код, то создаётся впечатление, что авторы не проблему решали и не фичи делали, а показывали какие они умные. Что они знают паттерн strategy, или пробуют новый фреймворк за счёт работодателя, или новый язык, или просто креативят в пустоту. По итогу проблемы (зачастую выдуманные) решаются наименее очевидным из всех возможных способов. Технологические понты. Как и бывает в таких случаях, инструментарий авторы не понимали и не утруждали себя погружением в детали на предмет зачем это нужно, как оно работает и к месту ли. Что закономерно, ведь, как и было сказано, важны soft-skills. А стало быть на хрен идут проблемы продукта — тут надо показать коллегам какой ты умный и красивый. Вершина и кульминация этого буйства сознания — использование самописной монады Maybe<>, которая где-то в середине стека вызовов прагматично разворачивается в if (maybe.HasValue). Функциональное программирование вам, так сказать, в production.
Выстроив в голове модель сущностей, открываешь для себя другую особенность. Называется «без штанов, но в шляпе». Приведу абстрактный пример: вообразите себе витиеватые заросли Repository Pattern, всё по науке, интерфейс-реализация, в разных неймспейсах, с заделом на тестирование. Вот вся эта красота развешена поверх… статического подключения к БД! Такое нам в Новосибирск из Индии везут на рефакторинг! Тоннами! Я ещё будучи джуном понял, почему подключение к БД нельзя пихать в статический контекст. Что же помешало «лучшим умам» не наступить на эти грабли? Видимо, тот факт что про грамотное управление лайфтаймом подключения не расскажешь на тим-митинге и внутренней конфе. А вот прочитать статью на википедии и красиво всё разложить по репозиториям — вполне себе социально одобряемое. Десять soft skills из десяти.
Обычно подобный треш и угар в системе пресекается системным архитектором. Но это не наш случай: в дополнение к soft-skills, тут полный agile. То есть предполагается, что все сотрудники — профессиональные инженеры, которые сами могут договориться и принять правильное техническое решение. Вкусно, как Orbit со вкусом design by committee.
Видавший виды руководитель знает, что agile и делегирование принятия технических решений команде на практике означает «слабоумие и отвага», если не проводить жесточайшего кадрового отбора по хард-скиллам. Но чтобы организовать такой отбор во-первых нужен человек неприлично высокой квалификации, который и будет проводить собеседование, а во-вторых — опытный управленец с намётанным глазом.
В рамках своей первой и единственной задачи я разгребал код, написаный местным техническим директором. Что ж… если человек не может спроектировать простое консольное приложение, принимающее флаги и делающее действия, то строгий кадровый отбор по хард-скиллам — явно история не про него. Вот и остаётся писать в буклетах «процесс разработки не нуждается в менеджерах» и загадочно улыбаться.
Сам по себе отвратительный код — это нормально. Для какого-нибудь аутсорса. Разница в том, что аутсорс-компания обычно не претендует на лавры best place for work и какой-то особый уровень экспертизы. Да и лица там не настолько высоконагружены, чего греха таить.
Кстати, о лицах
Вообще я не очень хорошо разбираюсь в людях, предпочитаю всё-таки системы. Но тут сам б-г велел, ведь радужно-оптимистичные статьи жанра «личностный рост для разработчика» предписывают работать с талантливыми людьми. Сам не читал, но что-то такое слышал на краю Интернета. Грех не воспользоваться случаем.
И вот впервые в жизни я увидел молодых мальчиков и девочек с высокодуховными лицами, лоснящихся от высоких зарплат. Они не ходят, они как будто парят над землёй, стоя на облаке из квалификации. Ну, думаю, наконец-то. Вот они — настоящие инженеры. Сбылась мечта идиота, я работаю не с аутсорс-недоучками и вайтишниками, а с самыми, что ни на есть мозгами. Которые в курсе трендов и технологий!
Я обратился к людям из «самой звёздной команды"™ в попытке поговорить с ними о технических штуках, рассказать о том, через что сам прошёл, обсудить тенденции, архитектуры разных вещей (в том числе и самой системы)…
Видимо, что-то пошло не так. В ответ я получил пачку и без того мне известных buzzword-ов, одухотворённо-покровительственный взгляд и отшучивание. Всю первую неделю я гадал — что же не так? Может я как-то… не знаю… Вопросы не те задаю? Или, может, надо не про себя рассказывать, а больше вопросов задавать, попросить научить меня чему-нибудь?
Всё оказалось гораздо проще. Технические дискуссии коллег не интересуют. Поначалу казалось что их вообще мало что интересует, но потом я просёк фишку. «Высоконагруженные лица» оживляются на разговорах о чём-то более мирском. Ну вы знаете, не об этих ваших абстракциях, паттернах и технологиях, а о чём по-проще: кто в каком ресторане обедал, где провести тимбилдинг, куда поехать в отпуск, кто какой гаджет купил и прочие темы «за жизнь» «за покупку второй бэхи».
Тут у меня, наверное, нет комментариев. Видимо вот такой он, градус дискуссии профессионалов высокого класса. И ничего с этим не поделаешь.
Итог
Вот что мне всю жизнь непонятно — почему инвесторы вкладываются в такие компании? Предположим, что у меня были бы деньги на долю и я хочу разобраться: а что тут, собственно, покупать? Обычно в стартапах покупают рост в надежде, что он будет взрывной. Но взрывной рост сложно организовать без продукта, попадающего в голубой океан пользовательских потребностей. Здесь требуются удачливые визионеры, грамотные маркетологи, Product Manager-ы и работающий как часы продакшен.
В TargetProcess: единственный визионер (он же основатель, он же Миша Дубаков) ушёл с продукта, плотняком ударился в идею околокорпоративного no-code. TargetProcess после этого начал заниматься хаотичным метанием в надежде догнать Jira под руководством каких-то сомнительных личностей.
Продакшен? Увы, поверхностный аудит кода и разговор с людьми отчётливо показал что продакшен больше интересует красивая жизнь, нежели продукт или технологии.
Взрывной рост сложно пережить без чёткого управления и подготовленных процессов. Здесь уровень разгильдяйства вкупе с возрастом предприятия даёт явное понимание что людей, способных внедрить и настроить процессы в компании нет и никогда не было. Документация, онбординг, ответственные, передача информации? По всем пунктам провал. Взрывной рост разорвёт всю конструкцию на куски по наложенным на коленке швам.
Однако TargetProcess не уникален. Подобных компаний на рынке полно. Думаю, будет не лишним написать пару советов как не угодить в местечковый Theranos.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.