Как меня из лида джуниором сделали и что из этого вышло

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

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

Я успешно прошел собеседование на должность Lead Back-end Engineer и получил оффер с довольно стандартными условиями и хорошей зарплатой. Выходя на работу, я надеялся, что выбранная мной компания окажется достойной и сотрудничество наше станет долгим. Увы, этим надеждам не суждено было сбыться.

Забегая вперед, скажу, что в середине истории я окажусь на позиции Junior JavaScript Developer и буду очень этому удивлен, а в конце буду уволен. Но обо всем по порядку.

Иллюстрация Марии Рыбак

Первые дни на работе

В первые дни работы ничто не предвещало беды. Хороший офис, приличная локация, дружелюбный коллектив.

Закончив с обычными в таких случаях формальностями, я занял свое рабочее место и начал готовить лэптоп к разработке.

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

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

Худшие новости пришли недели через три, когда проект все-таки был запущен. От клиента пришло большое письмо с описанием распределения нас по командам. Команд всего на проекте было выделено четыре, то есть примерно по пять человек в команде. Я, как тимлид, ожидал, что в моей, скорее всего, окажется пару Senior-разработчиков, пару QA и я сам.

Первым (и еще небольшим сравнительно) сюрпризом стало то, что в моей команде из разработчиков оказался только я и... еще один Lead Back-end Developer (назовем его Павел). То есть подчиненных у меня, несмотря на должность, фактически не было, хотя на собеседовании оговаривалось совершенно иное.

Вторым сюрпризом стала нагрузка. И вот тут я уже действительно был удивлен, поскольку в качестве нагрузки на ближайшие месяцы нам предлагалось заниматься... разработкой на Angular. Точнее, на странной смеси классического MVC и Angular в рамках используемого здесь самописного модульного фреймворка. Здесь важно заметить, что мой опыт в фронтенд-разработке — нулевой. Я опытен в разработке высоконагруженных масштабирующихся SOA-систем, баз данных, оптимизации перформанса... но не во фронт-энд разработке.

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

Клиент на этот вопрос ответил, кстати, вполне вменяемо: «Произошла какая-то ошибка, мы пересмотрим комплектацию команд». И вскоре выполнил свое обещание: через пару дней меня и Павла перевели из команды 3 в команду 1, где нагрузкой нам стала... все та же разработка на Angular!

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

Конфликт с руководством

Здесь самое время представить вам руководство этой прекрасной аутсорсинговой компании. Их было двое. Назовем их в честь великих полководцев древности — Юлием и Ганнибалом. Как вы понимаете по моему тону, руководить они не умели от слова совсем.

Юлий выполнял (или делал вид, что выполнял) функцию Head of R&D, что в моем понимании означает, как минимум, обеспечение technical excellence, а также оказание всяческой поддержки сотрудников своей компании в сложных ситуациях. Он также был моим прямым начальником. Он сыграет немалую роль в этой истории, в отличие от Ганнибала, который был CEO (должности назывались иначе, но смысл схожий) и большую часть времени просто отмалчивался, делая вид, что занят. Возможно, так и было.

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

Сказать, что он самоустранился от исполнения этой роли — ничего не сказать. Ответ мне был дан четко и решительно: «Все определяет клиент, я тут ничего не решаю и не вмешиваюсь». Слова истинного руководителя, не так ли? Поскольку моя роль меня по-прежнему не устраивала, я решился проявить еще немного инициативы и попросил технического менеджера со стороны клиента о коротком митинге, чтобы высказать ему свою обеспокоенность подобным распределением ролей. Тот согласился.

После 15 минут разговора с ним картина стала мне совершенно ясна. «Два месяца до релиза, тридцать новых человек на проекте, не до тебя, явно не до тебя», — устало, но уверенно отвечал мне технический менеджер. «Ну а после релиза?» — продолжал надеяться на лучшее я. «It depends on possibilities», — ответил он.

Попутно выяснилось, что на стороне клиента тоже есть команда лидов, которые встроены в те же команды. Ну, то есть вы понимаете схему, да? Есть лиды с американской стороны, которые распределяют таски, и есть «лиды» с нашей, которые эти таски выполняют. Если даже упомянутые «possibilities» и возникнут, то их явно приберегут для своих, а не для свеженанятых украинских Lead Back-end разработчиков, которые даже Angular еще не выучили. То есть мне неявно предложили сменить career path на JavaScript-разработчика и начать новую карьеру с нуля. Даже не спросив моего мнения. Зачем было нанимать лидов, когда можно было нанять синьоров — еще один вопрос к Юлию и Ганнибалу.

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

С этого момента я начал стремительно терять надежду на долгое и успешное сотрудничество с компанией. Другой на этом месте начал бы сразу собирать вещи, но я все же решил поговорить с Юлием и Ганнибалом о случившейся ситуации. В конце концов в компании были и другие, хоть и меньшие проекты, на которые я мог бы перевестись.

Состоявшийся разговор с руководством вышел, безо всякого преувеличения, эпичным. Ганнибал многозначительно молчал, а вот Юлий не скрывал своего раздражения моим вольнодумством. «У нас в компании так: сказали — сделал», — сообщил мне он. Это прямая цитата, ребята. «Почему же мне это не сообщили при приеме на работу?» — пронеслось у меня в голове. «Потому что тогда никакой дурак сюда бы и не пошел!» — ответил я сам себе. И знаете что, я позволил себе разозлиться и высказать им, что дела так не делаются и в моем оффере присутствуют слова «Lead Back-end», а слова «Junior JavaScript» отсутствуют. И в данной ситуации с их стороны полагаются как минимум извинения, а как максимум...

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

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

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

Поэтому я и обращаюсь к уважаемому комьюнити DOU, как мог бы обратиться к третейскому судье. Выскажите, пожалуйста, свое мнение по данному вопросу. С моей точки зрения, я потерял пару месяцев своего времени впустую, сделал свое резюме несколько хуже (см. «job hopper») и потерял некоторое количество нервных клеток, так что извинения здесь считаю уместными. Да, мне платили зарплату исправно. И зарплату лида, а не джуниора. Но это можно сказать про любое место работы в моей карьере.

Для удобства сбора мнений я подготовил следующий опросник. Он совсем короткий, всего несколько вопросов, что я поднимаю в статье. Результаты обещаю опубликовать через несколько дней здесь же в комментариях или, если они будут того стоить, в отдельной статье. Комменты приветствуются, попрошу только воздержаться от хейта и напрасных сомнений в стиле «ну и почему мы должны тебе верить». Верить мне причин нет, но и особых причин лгать я не вижу. Да и история здесь такая, что нарочно не придумаешь. Деананомизировать компанию и ее руководителей, подчеркиваю, я не стану, вне зависимости от результатов опроса. Тех, кто узнает по тексту название компании, очень прошу — не выдавайте ее. Любителей деанонимизировать всех и вся из вредности я тоже прошу не вмешиваться. Я этого точно не хочу.

Disclaimer. Написанием данной статьи я не намерен нанести никакого репутационного ущерба ни компании, ни упомянутым здесь лицам. Поэтому все имена и несущественные детали изменены, название компании и мое собственное имя (по которому, конечно, очень легко вычислить компанию) отсутствуют. Более того, скажу сразу, что считаю данный случай не единичным курьезом, а проявлением системной проблемы нашего IT-сектора в целом — использование жесткой административно-командной системы там, где были бы уместны Аgile-методы. Иначе говоря, советским мышлением руководства компании. Но об этом как-нибудь в другой раз. А раз проблема системная, то цели «мстить» или выдвигать претензии конкретно этой компании у меня нет. Моя цель другая — выяснить мнение комьюнити по этому вопросу. А дальше уже будем плясать от полученных результатов.

Bonus

А чтобы вам было легче отвечать на приведенные вопросы, добавлю еще несколько примеров failed leadership со стороны руководства компании на правах анекдотов.

Не тот кофе

В первый день работы в компании я, понятное дело, оформлял документы и знакомился со всеми значимыми людьми. В какой-то момент я и Александр (офис-менеджер, который, к слову, оказался самым доброжелательным персонажем в этой истории) решили сходить за кофе и пообщаться о местных порядках. Попробовав кофе, я тут же понял, что здесь принято пить какую-то невероятную бурду. (Сам офис, кстати, был на 10 из 10, далеко не все в этой компании было плохо.) Я за годы работы лидом привык оптимизировать вокруг себя всё и решил проявить инициативу в первый же день. Выяснив цену кофе и ассортимент поставщика, я проконсультировался со своей знакомой баристой насчет смены марки кофе («Как вы вообще могли это пить?» — спросила она недоуменно), я предложил Александру перейти на другую. Стоила она на 15% дороже, но по вкусу была много лучше. Александр согласился.

И что вы думаете было дальше? Когда эта история дошла до Юлия, он вызвал меня к себе и спросил меня строгим голосом, цитирую: «Для чего ты ищешь проблемы в моей компании?». Верите? Я бы, честно говоря, не поверил, если бы не слышал это своими ушами. Оставим за скобками вопрос, почему собственно «моей», а не «моей и Ганнибала». Но видеть в улучшении «поиск проблем», на мой взгляд, выходит за рамки логики и относится к области уязвленного эго.

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

Можно даже попробовать оценить возможный профит от этого изменения. Какой процент сотрудников пьет кофе? Грубо говоря, 50%. Насколько улучшается производительность сотрудника, выпившего неплохой, пусть и недорогой кофе вместо бурды? Тут оценить сложно, но все же не зря его люди пьют, он действительно придает энергии. Ну, пусть будет по минимуму, 1% от дневного output. Итого имеем +0,5% к средней производительности всех сотрудников на ровном месте. Допустим, я ошибся в пять раз, пусть будет +0,1%. Вы представляете, сколько это — 0,1% в переводе на доллары для компании в 100+ сотрудников? Думаю, в разы больше, чем доплата в 50 гривен за пачку кофе. На целую библиотеку книг по эффективному менеджменту для Юлия хватило бы.

Не тот таск

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

Помучившись неделю от скуки, я все-таки получил временную задачу со смежного проекта, раз старт моего откладывался.

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

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

Не тут то было. Начнем с очевидного: чтобы стянуть проект, мне понадобились креденшелы. Поскольку я к тому времени своих еще не имел, то попросил о помощи Андрея. Я полагал, что он сбросит мне копию сорцов или, возможно, разово позволит воспользоваться своими креденшелами. Какое же было мое удивление, когда он в ответ сбросил мне в скайпе креденшелы... Юлия. «У нас все ими пользуются в таких случаях», — не моргнув глазом сообщил мне он. «Ну что ж, можно и так», — ошарашенно сказал я и поставил галочку «save my credentials».

Стянув проект и установив необходимые компоненты, мне почти сразу удалось его успешно скомпилировать, что вообще-то неплохой результат. Но при запуске обнаружилась проблемка — не хватало файла appSettings.development.json. На мой вопрос, где его взять, Андрей все так же невозмутимо прислал мне копию и предложил сделать это первым пунктом гайда. «У нас всегда так делают», — добавил он.

А теперь внимание, снова вопрос на логику! Что лучше: иметь в установочном гайде пункт «После скачки солюшена попроси у тимлида копию appSettings.development.json и добавь в солюшен» или просто сделать так, чтобы этот файл изначально был частью солюшена? И всегда был up-to-date, был частью CI и так далее? Одновременно автоматизируя один пункт из вышеупомянутого гайда? Сделаю вид, что ответ не очевиден.

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

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

Кстати, коммуникация в этой компании — отдельная песня. Официально все пользуются скайпом, там заведен общий чат и прочее. Тем людям, которые скайп ненавидят (к которым отношусь и я), позволяют коммуницировать через телеграм. Для коммуникаций с клиентом используется Teams. Рабочих почтовых ящиков, кажется, три, хотя уже точно не помню, может, и больше. Работа ведется через вечно тормозящие виртуалки. В общем, хотя бы в выборе мессенджера и почты здесь свобода. Но вот только не в выборе своей должности, увы.

Не те отзывы

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

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

У меня тогда еще не отбили напрочь желание проявлять инициативу, так что я тут же предложил: «Смотрите, у вас ведь компания быстро расширяется. Давайте предложим сотрудникам, прошедшим испытательный срок и решившим остаться, оставлять отзыв. Добровольно, конечно, но раз им у вас понравилось, то вряд ли они откажутся. Обычно отзывы оставляют после более долгого срока работы, но ведь и негативный отзыв вам оставил человек, который ни дня у вас не проработал. Это дает вам пять-десять отзывов в месяц. Через несколько месяцев вы с лихвой перекроете тот негативный фидбэк свежей информацией». Надежда оценила идею и радостно согласилась. «Только мне нужно с Юлием согласовать», — добавила она. Через пару дней она сообщила, что тот дал добро. Слава богу, подумал я, все же он способен на хорошие решения... Изредка.

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

Кстати, у этой компании рейтинг на DOU больше 90. Как это возможно, понятия не имею. Статистическая погрешность, видимо.

Заключение

На этом я заканчиваю свою статью. Это первая моя публикация на уважаемом мною DOU, так что для меня важны ваши отзывы. Оставляйте комментарии, пообщаемся.

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

Если вам нужен человек с 10+ годами опыта бэкенд-разработки, с опытом работы за рубежом, патриот, человек мегаинициативный, с отличными идеями и неуемной энергией; если ваша компания не огромный монстр с обязательными тайм-репортами и скрамом «для вида», а действительно гибкая компания, в которой приветствуются перемены к лучшему, или если вы компания, которая созрела совершить переход к гибким методологиям, но не знает, как это сделать, дайте знать здесь же, в комментах, с указанием почты. Поговорим.

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

Приверженцам командно-административного подхода к работе — огромная просьба не беспокоить.

Спасибо за внимание. И не забудьте, пожалуйста, про опрос! Результаты обещаю опубликовать в ближайшее время.

Всегда ваш,

Неизвестный тимлид.