dev.by обсудил с разработчиком, менеджером и основателем компании, за какую работу программисты не хотят браться и с чем это связано.
«Нам платят, вот мы и делаем» — это не аргумент»
Егор Малькевич, Frontend-разработчик и СЕО стартапа SolidBridge, отказался от работы в крупном энтерпрайзе в Абу-Даби, потому что «тяжело работать, когда у компании нет цели».
Егор, как развивалась твоя карьера в ИТ?
В ИТ я стремился с 13 лет. Мне казалось, что те, кто делают Warcraft, гении, и нужно быть таким же. Я много усилий приложил, чтобы построить карьеру. Сейчас мой род деятельности «собирательный»: я разработчик и Product Owner, могу решать абсолютно разные задачи, начиная от бизнес-анализа и заканчивая дизайном. У меня четыре проекта, абсолютно разных, также я организовываю митапы: мне становится скучно, и я веселю себя и других. Но я не воспринимаю это как работу — это отдых для меня, как и программирование. У меня никогда не было отпуска, он мне не нужен, я отдыхаю на работе.
Объясни, как можно отдыхать на работе.
Со временем отношение к работе сильно изменилось. Раньше я думал, что работа — это когда ты пришёл в офис и сидишь там целый день. А сейчас я работой считаю решение конкретной проблемы — не важно, в офисе, на курорте или в самолёте. Я очень мобильный, часто путешествую и не беру для этого отгул или отпуск. Просто нужно уметь договариваться с начальником и объяснять ему, что это выгодно вам обоим.
Расскажи о последнем таком рабочем отдыхе.
Последний раз я работал с крупным энтерпрайзом уровня Google в Абу-Даби. Ко мне обратились примерно так: «Привет, Егор! Мы знаем, что ты классный, пройди наше собеседование». Я прошёл и на следующий день мне сказали, что нужно быть в Эмиратах через 9 дней. Я ответил: «Отлично, я готов». У меня на тот момент была работа, курсы, подкасты, сообщество, и я всё это оставил, чтобы полететь на другой край света, в неизвестную мне команду. Заказчик обеспечил всё: проживание, перелёты, хорошую зарплату. Но через несколько месяцев я ушёл оттуда. Оказалось, люди просто пилят бюджет.
Почему ты не захотел пилить бюджет?
Тяжело работать в компании, у которой нет цели. Все что-то делают, а ты спрашиваешь «Зачем?» и получаешь ответ: «Нам платят, вот мы и делаем». Но это не аргумент, тяжело делать хорошо в таких условиях. Это пример того, когда задача вроде интересная, но ты понимаешь, что всё бессмысленно.
Есть такая теория: когда ты зарабатываешь больше $70 тыс в год, то в принципе уже не имеет значения, заплатят тебе $200 тыс или $0,5 млн — жизнь твоя кардинально не поменяется. Изменения произойдут, если ты будешь зарабатывать больше $1 млн в год. «Звёзды» в среднем тратят на свои расходы до $20 тыс в месяц. Больше этой суммы тяжело потратить и нет даже смысла её зарабатывать, если у тебя нет конкретной идеи, куда её вкладывать.
Нужно спрашивать у себя: ради чего я просыпаюсь и иду на работу? Ради чего коплю деньги? Что будет через 10 лет со мной и моими друзьями? Мне тяжело себя обманывать. Ты не можешь быть просто программистом: ты программист, который делает классную штуку, и ты этим гордишься. А проектом в Абу-Даби я не мог гордиться: я понимал, что через год я не то что останусь на том же уровне, но и пойду в обратную сторону. Да, у меня будет больше денег, но я буду чувствовать себя хуже. А ведь я могу провести это время с пользой.
Твои интересы и интересы заказчика часто не совпадают?
В моей жизни было несколько случаев, когда я после общения с заказчиком понимал, что ничего у нас не выйдет, либо компания сразу говорила, что я не впишусь в её процессы. И здесь важно не обманывать друг друга, а сразу сказать об этом. Приступая к новой работе, я обычно стараюсь получить опыт не только профессиональный, но и эмоциональный. Это, мне кажется, важнее, чем получение персональной выгоды. При этом нельзя получать удовольствие от одного и того же на протяжении 10 лет.
Ты берёшься только за те задачи, которые влияют на твой рост?
Последние годы всё, что я делаю, прямо или косвенно влияет на мой рост, даже то, что раньше я считал бессмысленными, например, помощь другу. Буквально вчера делал сайт знакомому, потому что хочу сохранить хорошие отношения с ним. И не жалею о времени, которое на это трачу. Если быть эгоистом и делать только то, что может тебе что-то дать, легко остаться без людей, на которых можно положиться.
В компаниях, кстати, руководители замечают тех, кто готов закатать рукава и покопаться в г**е, чтобы команда не облажалась. И таких людей нормальные руководители обычно повышают. В то же время, если Вася много сделал для компании, а потом наняли менеджера со стороны, то Вася уйдёт, и правильно сделает.
От рутинной работы тоже отказывешься?
Мне кажется, нельзя нагружать высококвалифицированных людей низкоквалифицированной работой. Тем не менее такие задачи часто прилетают сеньорам, и иногда есть смысл их выполнять. Например, если от этого зависит успех проекта. Но, если задачи не очень важные, я предпочитаю соскочить с них, передав джуниорам или другой команде. В Эмиратах я скидывал где-то процентов 30 грязной работы другим. Я считаю, нет ничего зазорного в том, что вы не всё сделали своими руками.
«Хуже всего — когда люди не видят результата своей работы»
Андрей Рудский, Engineering Manager, считает, что «уговорить девушку пойти на свидание» легче, чем разработчиков выполнить скучную работу.
Андрей, свойственно ли разработчикам отказываться от рабочих задач?
Да, регулярно. В зависимости от уровня инженера это может проявляться по-разному, но источник проблемы общий: непонимание ценности от их выполнения. С точки зрения разработчика — это может быть рутинность, отсутствие новизны и бесконечный перенос дедлайнов (знаю случаи, когда разработчики отказывались от того, что делали длительное время). Это приводит к ощущению застоя в развитии технических навыков и страха потери актуальных знаний. С точки зрения продукта — непонятен вклад в само решение и каков отклик конечных потребителей, что ведёт к ощущению «работы в стол». В конце концов, разработчик идёт к выгоранию, а продукт — к проблемам по качеству и срокам.
Люди очень плохо умеют работать с неопределённостью. И хуже всего — когда они не видят результата собственной работы. Начинается пинг-понг между тестированием и разработкой, а впоследствии ещё и бизнесом, когда задача не доделана, реализована не так, как должна была. Также плохо, когда нет ротации по задачам, либо они разбиты таким образом, что неясен конечный результат. Если человек не понимает, чего от него ожидают, он со временем начинает тухнуть и неявно саботировать работу. Постепенно это приводит к тому, что у нас есть команда из кучи людей, которые не умеют друг с другом общаться. И недовольство выражается любыми формами, не затрагивающими корень проблемы. Редко кто заявляет напрямую, что ему что-то не нравится. Вслух об этом начинают говорить, когда все уже на грани.
Есть ли решение проблемы?
Да, причём очень простое. Нужно объяснять людям, зачем мы что-то делаем. Например, разработчик уже пять раз меняет цвет кнопок и начинает злиться. Но, дав немного контекста — «Мы сейчас проводим эксперимент, чтобы понять, какая цветовая палитра будет лучше подводить пользователя к нажатию на кнопку» — можно успокоить разработчика. Такой подход работает не всегда. Многим всё равно нужен технический челлендж. Тогда можно предложить автоматизировать рутинную работу: написать скрипты сборки, добавить А/В тестирование фреймворка, подготовить инфраструктуру и пр.
Как мотивировать разработчиков браться за задачи, которые не отвечают их интересам?
Думаю, это сложнее, чем уговорить девушку пойти на свидание. Иногда приходится упрашивать: «Слушай, нам необходимо сделать эти нудные таски, но, как с ними закончим, у нас будут более интересные вещи, с которыми мы сможем работать». Если я хорошо знаю команду, то могу сказать, что, выполнив эту задачу, ты приблизишься к своей цели и лучше начнёшь понимать то-то и то-то — это тоже работает. А вот денежная стимуляция, как показывает практика, действует только на короткий срок. Нелогично поднимать зарплату или давать премию за то, что человек отказывается что-то делать.
Чтобы вовремя выявлять проблемы, нужно проводить ретроспективы, one-to-one беседы — они позволяют шире взглянуть на ситуацию, посмотреть на эмоциональное состояние человека, где он находится, с чем связано его недовольство. Главное — не подорвать доверие, и, если человек на грани, нет смысла держать его в офисе, лучше сказать: «Чувак, сходи отдохни».
За что можно уволить сеньора?
За игнорирование подходов в работе или их саботирование. Представьте, что у вас есть команда из двух крутых сеньоров и трёх мидлов. Готовы ли вы мириться с тем, что один из них — токсичный человек? Игнорируя это, вы повышаете вероятность потерять всю команду и подорвать репутацию компании. Либо вы можете подпортить отношения с конкретным человеком и поговорить с ним об обоюдном уходе.
Другой случай: человек может быть прекрасным инженером и писать крутой код, либо делать автоматизированное тестирование с закрытыми глазами, и это специфическая работа, узкое место, как бутылочное горлышко в проекте. Если он не передаёт знания другим, то при его уходе вы теряете всё, что он делал.
В моей практике были люди, которые не тянули по производительности, по качеству, сильно выбивались из общей атмосферы в команде, и ничего не оставалось, как уволить их. Разнообразие, конечно, должно быть, но в меру. Однажды мы не сошлись с человеком по темпераменту, он был менее усидчив, постоянно дёргал коллег, потому что ему надо было что-то спросить. Пытались найти способ, предлагали в чат писать, чек-лист составлять, самому иногда копать и искать ответы. Но ему было проще отвлечь кого-то и спросить, в итоге люди теряли фокус, концентрацию, злились. Мы решили, что в другой команде, где ему смогут уделять больше времени, ему будет лучше.
«Иногда очень скиллованому человеку нам просто нечего предложить»
ИТ-предприниматель Андрей Фан, основатель компании UpsilonIT и стартапа OneBar, отпускает людей, которые «переросли компанию».
Андрей, в вашей компании могут разработчики выбирать, чем им заниматься, отдавая предпочтение тем задачам, которые влияют на их рост?
Нам как компании не хотелось бы услышать ультиматум от разработчика, что он будет делать только то, что ему интересно и выгодно. Не секрет, что для аутсорсинговой компании удобно, когда разработчик умеет делать всего понемногу, потому что тогда проще найти проект. Мы стараемся не брать заказы, где будет сплошная рутина, которую никто не захочет делать. Это невыгодно и несёт большие риски. Например, я бы предпочёл не работать вовсе с заказчиком, которому нужно сделать 10 однотипных сайтов. Но, если задача стоит иначе (допустим, разработать платформу, которая позволяет конечному пользователю создавать такие сайты) — другой вопрос. А просто клепать лендинги — это ведь никому не интересно. Проще отфутболить такой проект, чем уговаривать потом разработчиков и думать, как их туда заманить.
В каких случаях сеньорам приходится делать простые, скучные задачи, которые может выполнить любой джуниор?
Например, если мы начинаем работать с новым заказчиком, и он хочет проверить нас, дав несложное задание. Обычно просят пройтись по сайту или платформе и пофиксить два-три бага. Если нам заказчик интересен, тогда мы отдаём задание более сильным ребятам, чтобы они сделали это быстро. В остальных случаях стараемся распределять задачи по сложности и уровню специалистов, причём так, чтобы нужные люди делали нужные задания.
Давать сеньорам регулярно простые и скучные задачи, которые могут сделать специалисты более низкого уровня, не вижу смысла. Заказчики ведь тоже это понимают и не будут много платить за простую работу. Тогда появляется вопрос: если у вас есть простые таски, за которые платят мало, зачем вы их даёте сеньору? Почему бы не найти для этого джуна или мидла, а сеньора переключить на что-то другое, что будет работать на репутацию компании?
Могут ли у вас разработчики отказаться от определённой работы?
По идее да, но я не помню случаев, когда люди делали это на стадии озвучивания задачи. Часто пока не начнёшь копать, не узнаешь, что тебя ждёт. Многие задачи могут звучать интересно, а по факту сводятся к рутине. А бывает, что звучит просто, а потом оказывается, что это верхушка айсберга.
Был у нас заказчик, для которого мы год всей командой делали сложную систему репортинга. Проект был большой, работа увлекательной. Но, когда мы сделали систему, всё свелось к добавлению туда огромной кипы шаблонов. Делать это пришлось разработчикам, которые всю эту штуку писали. Потом таски перекочевали к одному человеку, он сидел и разгребал их. Через пару месяцев пришёл и сказал, что с репортами пора заканчивать. Мы поменяли ему проект, а репорты доделал другой разработчик. Никто не уволился, всё закончилось хорошо.
Как работаете с теми, кому регулярно что-то не нравится?
Стараемся подыскать другой проект, либо оговариваем таймлайн, когда появится что-то новое. Но чаще разработчики решаются сказать о проблеме, когда у них уже есть офферы от других компаний. Им что-то не понравилось, и они решили, что пора менять работу. Когда начинаешь выяснять причину, оказывается, что человек был чем-то недоволен, но никто об этом не знал. Мы обычно хорошо расстаёмся с людьми. Если у кого-то уже есть оффер, просим поработать ещё месяц, пока мы ищем замену — почти все идут навстречу.
Не пытаетесь удержать человека, сделав встречное предложение?
Ситуация на рынке такова, что хороший разработчик может найти себе новую работу по дороге домой с текущей — буквально за пару часов. Если у компании нет интересных проектов и ей нечего предложить, то сколько ты не изгаляйся, человек всё равно уйдет. Иногда очень скиллованому человеку нам просто нечего предложить, или он перерос компанию и хочет двигаться дальше. Мы расходимся на хорошей ноте. Лучше пожелать удачи, всякое бывает: возможно, через год-два он захочет вернуться.
Работа для Senior-специалистов здесь.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.