Привет, Хабр! Меня зовут Денис Шевчук, и вот уже 17 лет я тружусь в мире 1С. Сегодня я не только разработчик в Outlines Tech, но и руководитель компании Плоская утка. Последнее звучит круто, да? Но знаете, чего я на самом деле хотел? Работать меньше. Я был уверен, что свой бизнес – это путь к свободе: работать по 3 часа в день на побережье океана, попивая коктейль и наблюдая, как деньги капают на счёт. А в итоге настолько увяз в управленческой рутине, что устроился на вторую работу программистом, чтобы снова вспомнить о простых и понятных радостях написания кода.

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

Первая работа и путь к предпринимательству

В 1С я попал в 20 лет: выбор фреймворка не был для меня осознанным решением. Тогда я учился и брался за любую работу, которая позволяла заработать. Однажды к нам на курс пришел первый в моей жизни работодатель и сказал, что ему нужны толковые ребята. Я согласился и попал на свою первую работу: сначала на полдня, а потом на фултайм. Зарплата в 4000 рублей (150$) казалась настоящим триумфом. Постепенно я шел глубже: проекты начинали требовать знаний не только в коде, но и в общем понимании бизнеса, его логики. Я отправился получать второе высшее в экономике, чтобы расширить свои компетенции. Спустя 7 лет я окончательно выгорел на производственных проектах и принял решение уйти во фриланс, чтобы попробовать себя в новом формате работы.

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

Управление компанией: ожидание vs реальность

Как я представлял себе идеальным день руководителя? Подъем в 10 утра, неспешное утро с пробежкой, работа не более 4-5 часов в день и все это, конечно же, где-нибудь на берегу Средиземного моря. В реальности, руководить компанией – это как жить на краю обрыва. Внезапные увольнения сотрудников требовали включения сразу на несколько дней в подбор и найм новых. Каждый новый сотрудник – это не только помощь, но и новые заботы. Обучение, онбординг, а потом ещё и текучка. Один ушёл, второго переманили конкуренты, третий вообще решил уйти в буддистский монастырь. Бюрократия и бесконечный менеджмент поглощали все силы. Желания что-то делать оставалось мало. Единственное, чего я хотел от этой авантюры – меньше работать, но оказалось, что я просто заменил одну работу другой. Причем если программировать мне нравилось, то заниматься управлением не особо. 

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

Кому на проекте жить хорошо: возвращение к разработке

Со временем в таком режиме я понял, что мне не хватает удовольствия в работе, которое мне приносит работа руками. Хотелось снова создавать и видеть мгновенную отдачу, а не разбираться, кто срывает дедлайны и почему клиент недоволен. Программирование – это как медитация. Ты пишешь, тестируешь, видишь результат. Это было чем-то, чего не хватало мне на управленческой позиции. В этот момент в моей жизни случился крупный проект в Outlines Tech: достаточно сложный, чтобы я мог применить свои навыки и знания, но при этом с фиксированным кругом задач, на которых я мог отдохнуть от ответственности. Проект в роли разработчика стал для меня чем-то вроде забега вместо привычного марафона. И хотя из-за двойной нагрузки проект дается тяжело, но я испытываю удовольствие на каждом этапе его реализации. 

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

Баланс на грани: что я делаю, чтобы оставаться в графике и не сходить с ума

Управление компанией и работа разработчиком – это две параллельные вселенные. Конечно, мне изначально пришлось искать более лояльного работодателя, который лояльно отнесся бы к наличию у меня дополнительной объемной занятости. Но в итоге чтобы справиться, мне пришлось научиться строго разделять время. Утром я обсуждаю проекты и задачи с командой, а вечером пишу код. Сейчас я живу в Барнауле, где разница с Москвой 4 часа. Иногда это помогает удачнее распределить время, но из-за того, что люди преимущественно живут в московском часовом поясе, приходится балансировать между делами вечером. Какого-то секрета в тайм-менеджменте у меня нет – я «по старинке» утром выписываю в столбик запланированные задачи и иду по нему. Конечно, без жертв не обходится. К сожалению, часто первыми под удар попадают сон и время с семьей. Последнее я стараюсь компенсировать на выходных, если получается. 

Важную роль для меня играет отказ от многозадачности. Я не верю в то, что человеческий мозг способен разрываться между задачами без потери эффективности. Поэтому, я выделяю блоки времени на работу без отвлечений. Это позволяет мне глубже погружаться в задачи и быть продуктивным. Например, утром я решаю все накопившиеся вопросы в своей компании, а дальше отключаю уведомления, чтобы полностью погрузиться в проект по разработке. Свою команду я тоже предупреждаю о часах, когда буду полностью недоступен. Важный момент – я всегда слежу за тем, насколько загружен мой календарь и сколько времени я трачу на созвоны. 

Мои инсайты после опыта в двух ролях

Опыт руководства собственной фирмой и работа в роли рядового программиста позволили мне иначе взглянуть на обе роли: 

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

–– Спорный для многих тезис, но я пришел к тому, что руководителю не обязательно разбираться досконально в том, чем он руководит. Объясню на бытовом примере: моя жена водит машину. Она не разбирается детально в ее внутреннем устройстве, но знает как эффективно сдвинуть ее с точки А и довезти до точки Б. На работе тоже самое. Даже более: знать в деталях работу своего сотрудника может быть вредно. Мне будет казаться, что моя точка зрения единственно верная и я буду контролировать больше параметров, чем надо для достижения цели. Это будет изводить и меня, и команду: вместо эффективного решения задачи, сотрудники будут что-то выдумывать и пытаться угодить мне, а не закрыть конечную цель. 

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

Руководитель и разработчик: мои итоги

Моё решение совмещать две роли кажется странным многим, но оно позволяет мне быть счастливым. С одной стороны, у меня есть то, что я создал своими руками и продолжаю развивать. Это мое детище, которое дает мне ощущение себя как классного предпринимателя и надежду на светлое будущее, что если я поработаю еще несколько лет, то обязательно перееду на Лазурный Берег и перестану работать. Даже если это просто иррациональная мечта. С другой стороны – у меня есть творческая реализация в роли разработчика, где я могу попробовать новые проекты. Готов ли я выбрать в итоге что-то одно? Точно нет, ведь по-отдельности я не нахожу радости ни в управлении, ни в разработке. 

Если бы меня спросили, что самое главное в моей истории, я бы ответил: «Занимайтесь тем, что действительно приносит вам удовольствие». Иногда уход в сторону открывает неожиданные горизонты. А если вы сейчас находитесь перед выбором в какую специальность пойти, менять ли стек, брать на себя руководство или остаться исполнителем, то предлагаю заглянуть на канал Outlines Tech. Там мои коллеги собрали подробную инструкцию по самоопределению с вопросами для анализа, книгами и психологическими тестами. 

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