Жизнь в IT #2. Худшая работа в карьере

В те времена, когда я ещё жил где-то далеко за МКАД-ом, в нашем городе были две более-менее топовые студии, которые только-только начали работать с московскими заказами, выйдя за границы региона.

И эти веб-студии исповедовали два кардинально разных подхода к работе. Первая — за более творческий и свободный подход — никаких жестких метрик работы, не контролировался приход-уход, полное доверие со стороны руководства — главное качественно и вовремя закрывать задачи. Это касалось не только разработчиков и дизайнеров, но и менеджеров.

Антипод такого подхода практиковала вторая — полный и тотальный контроль за любым распределением человеко-часов; опоздание — предупреждение с последующими штрафами; не успел сдать задачу в срок — выговор с возможными штрафами/лишением премии и т. д; каждый час должен быть зафиксирован в такс-менеджере, в том числе время выхода на обед и прочие радости СКУД. Продуктивность и эффективность была мощная, но, по ощущениям, ребята быстро выгорали, а атмосфера была не самая радужная.

Фишка первой, свободолюбивой — крутой уровень дизайна. Оно и понятно, люди творческие требуют к себе определённого подхода и условий. А предоставляемые условия этой студией способствовали как раз этому самому творчеству.

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

Я прекрасно понимаю причины и профиты обоих подходов. Но ощутив их на себе, я понял, что мне гораздо комфортней работать в свободе. Не люблю, когда выполнение моих задач контролируют. Не просто интересуются, не поверхностно узнают про сроки, а именно контролируют — говорят что и как нужно делать, как нужно общаться с клиентом, что говорить команде, с требованием постоянного отчета о ходе работ, заставляя меня «микроменеджерить» мою команду, чего я не особо люблю делать — я больше про доверие в команде.

Считаю, что микроменеджмент демотивирует.

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

Работа с микроменеджментом со стороны руководства — для меня как минимум неприятна. Как максимум — трэш и выгорание уже через полгода. Именно с этим я и столкнулся лет 5 назад, когда уже переехал в Москву — это был как страшный сон, после пробуждения от которого я отходил в течение пары месяцев «ничегонеделания», восстанавливая силы. Казалось бы, топовая студия разработки в России.

Лучше всего студию можно охарактеризовать так — спустя полгода я стал самым «долгоработающим» сотрудником в отделе. Текучка была настолько безумная, что за эти 6 месяцев у меня сменилось три непосредственных руководителя.

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

Как такое может быть? Пресловутый микроменеджмент, возведенный в абсолют.

Поверите, если я скажу, что гендир лично проводил планёрки по проектам, находящихся в разработке? А так оно и было.

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

Добавим к этому таск-менеджер, вникнуть в работу которого требовалось больше месяца, с отбивкой каждой минуты потраченного времени на каждую задачу всего восьмичасового рабочего дня. Даже менеджерам проектов. Даже руководителям. Бррр. Забудешь вбить в систему за месяц несколько часов — тебе их и не оплатят.

О, а эти невероятные по своим ощущениям еженедельные планерки по понедельникам, для подготовки к которым ты уделяешь практически весь рабочий день. Не успел подготовиться? Добро пожаловать на вечерние неоплачиваемые переработки. По официальной версии они нужны для распределение ресурсов и для понимания, что на проектах всё ок. По факту — тотальный контроль и психологическое давление: малейший косяк — жесткий выговор, статус не тот стоит у задачи — жесткий выговор, с клиента не выбил долги — жесткий выговор.

Что уж говорить, при мне пару раз в слезах выбегали девушки-менеджеры из переговорок после таких планёрок.

И я бы не сказал, что люди в основном увольнялись сами. Из 10 человек, которые работали в отделе разработки, половину уволили. Ведь в понимании руководства — заваленная планерка из-за косяков, которые я описал выше, говорит о профнепригодности менеджера проектов (sic!). Остальных хватает на пару-тройку месяцев после испыталки.

Почему не сбежал я? Это был мой первый опыт работы на таком уровне — крутые проекты, топовые бренды, я старался впитывать знания и опыт как губка. И был уверен, что такой уровень микроменеджмента везде на этом уровне, да и кому я буду нужен, если не справлюсь тут? Тот самый синдром самозванца.

Чем в итоге всё завершилось у меня? Буквально в двух словах.

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

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

Как итог, нас с моим руководителем вызвали на ковёр к генеральному.

— Плохой менеджмент со стороны Jukka, — так объяснил причину произошедшего мой руководитель.

— О_о, — в изумлении посмотрел я на руководителя, но ничего на это не сказал.

После чего, конечно же, меня попросили «по собственному». Буквально за пару часов подписали заявление, рассчитали и выкинули на мороз. Стандартная практика, я даже особо не успел передать другие свои проекты: «Сами разберёмся».

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

Это ощутимо ударило по моей самооценке и по утихшему было на время моему синдрому самозванца. Работаешь усердно на протяжении нескольких месяцев, а потом получаешь вот такой результат. «Ну вот, меня раскрыли, я самозванец. Что делать дальше — без понятия, может пойти в Пятёрочку.. ?»

На моральное восстановление после этой сложной ситуации ушло больше месяца «ничегонеделания».

А сразу после, нашёл её — работу своей мечты.

Дальше — о ней.

2323
8 комментариев

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

6
Ответить

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

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

в 95% случаях он мне отказывал

1
Ответить

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

3
Ответить

да, у меня такая же ситуация была в посте, только в роли пм, параллельно вёл 3-4 крупных проекта, не успевал за всем следить, проваливал сроки, все шишки падали на меня.

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

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

2
Ответить

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

Ответить

Я пришла в компанию с нулевой базой. Не знала, что такое вэб-приложение, терминал, о питоне знала только его название. Как я туда устроилась? Благодаря своим коммуникативным навыкам. Также один парень, который бесплатно стажировался там, смог быстро освоить стек и поднялся до миддл-разраба. От меня ожидали того же и сразу взяли в штат. Итак, я пришла и начала осваивать 1.5 месяца python, selenium, html, css, jquary. Сама проходила курс на степике. Тот же парень мне сильно помогал. Очень много гуглила. И приступила писать автотесты. Было очень больно. Проект, который я бы сейчас сделала за 2 месяца, делала 8 месяцев. Более 7000 строчек кода и 700 автотестов по одному проекту. Второй проект был поменьше. В течение года я все больше развивала свои навыки в сторону программирования. Изучала sql, go, linux, docker, ci/cd. И через год ушла в другую компанию джуниор программистом, где требовалось знание Selenium.

1
Ответить

Текст с позиции линейного персонала, когда хочется свободы, ресурсов и хорошей зарплаты. Компании оцениваете с этой позиции и это не плохо, просто Вы не отвечаете за всю компанию, будет ли зарплата у сотрудников или наличие денег за аренду. Если смотреть с позиции руководителя, то проблем с «творческим и свободным» подходом тоже хватает. Потому что дизайнер Петя забухал в поисках вдохновения или его кинула подруга, программист Федя обиделся, что ему жестко сказали доделать работу до конца недели, а не упрашивали. Хочется ясности и понимания, что с проектом, когда деньги поступят от заказчика и меньше независимых и непонятных моментов. То что, проект завалился, а федеральный прошёл ожидаемо, так как профит с федерала был больше и кейс в актив, а Ваш проект к сожалению компания не вывезла в моменте. Ресурсов не хватило, может денег зажали на внешних, может у Вас отношения с руководством не заладились, сейчас сказать трудно. Но видимо клиент для компании был важнее Вас тк слили Вас, а не клиента…… В любом случае я желаю найти Вам хорошую работу, которая Вас будет полностью устраивать , а своим сообщением я хотел показать, что можно взглянуть на ситуацию с другой стороны.

Ответить