Заметки айтишника: наблюдения, которые позволят не развалить ИТ-компанию из-за стремления к лучшему

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

Недавно я начал структурировать свои знания и накопленный опыт в разработке, стал делиться ими в блоге на Хабре. Размышляя над очередной темой статьи, вспомнил, как нашел свою первую работу на третьем курсе во время вечеринки. Тогда пришло, казалось бы очевидное, понимание, насколько для карьеры важен нетворкинг. Вообще масса осознаний, которые в дальнейшем нам кажутся достаточно очевидными, не в любой момент времени и не для всех таковыми являются. Так у меня появилась идея — собраться с силами и рассказать о своих наблюдениях и выводах на пути от студента до CTO компании, вместе с которой прошел путь от стартапа до крупнейшего игрока финтех-рынка. Это не профессиональные советы и какие-то супер-секреты разработчика, а скорее жизненные уроки и опыт, что не раз подталкивали к рефлексии и новому взгляду на свои прошлые убеждения. Возможно, кому-то они помогут не развалить усилия команды. Мне помогают.

В 2010-х было повальное увлечение методиками управления проектами. Руководители искали “волшебную таблетку” для повышения эффективности: маниакально ставили задачи только по SMART, выполняли по Kanban и в процессе использовали Scrum. Меня эта история по стечению обстоятельств не коснулась, во времена моей первой работы в стартапе мы не использовали ни Scrum, ни Kanban, ни каких-либо других систем. Сейчас понимаю, что мне повезло — мы тогда выстроили свой рабочий процесс, который фактически складывался из разных методик. И если бы я пришел в компанию и увидел, что все работает только по Scrum или Kanban, например, то появилось бы убеждение, что выбор одного метода — единственно верный. Но сейчас я уже точно знаю, что не бывает процессов, которые работают идеально на всех этапах — это всегда конструктор, который еще и постоянно меняется и перенастраивается. В конечном итоге настоящий рабочий процесс бывает мало похож на каноничный по Scrum или Kanban. Нет методики, которая работает как волшебная таблетка — внедрил и все само заработало, ее нужно собирать по кусочкам самому.

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

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

Когда я пришел в TYMY, тут уже был проект, продукт и IT. Как у специалиста со своим бэкграундом, моим первым порывом было — всё переделать, переписать и сделать круто. Хорошо, что я этот порыв тогда погасил. Не стоит ломать существующие процессы, структуру и строить с нуля новое. Во-первых, вообще не факт, что новое получится лучше старого. А во-вторых, на реорганизацию процесса нужны время, деньги и силы команды. Гораздо эффективнее начать делать, то что нужно - затратить 20% усилий, а получить 80% результата.

Есть много классных процессов в IT, которые могут попасть под явление «Преждевременная оптимизация». И перед тем, как вводить что-то новое и модное, стоит понять, действительно ли это сейчас необходимо. Например, Kubernetes — инфраструктурная платформа для оркестрации сервисов, предназначенная для их обслуживания, отслеживания работы и масштабирования. Инструмент классный, но прежде чем затаскивать Kubernetes в стартап стоит ответить на вопрос: «А это сейчас точно нужно?». В стартапе, особенно на начале пути, главное — скорость. Если темп быстрый и проект взлетит, то уже после можно потратить время на переписывание и масштабирование. А если заняться оптимизацией на старте, получится достойный проект, но убыточный.

Урок, который я усвоил ещё в студенчестве: не нужно долго размышлять, получится или нет, составлять идеальный план. Иногда нужно просто брать и делать. Перфекционизм должен быть инструментом, который можно включать и выключать обратно. Я был жестким перфекционистом и старался любую задачу детально продумать и после сделать идеально и строго по правилам.

Мы с другом хотели собрать музыкальную группу: пару недель обсуждали состав, план и место репетиций, но действий не предпринимали. В какой-то момент приятель сказал, что надо просто взять и сделать. В итоге мы шесть лет на протяжении учёбы играли в этой группе, это был классный опыт. Впоследствии правило «Бери и делай» не раз помогало в работе — не размышлять долго, а начинать делать и двигаться к цели. Например, хочешь подойти к девушке познакомиться — иди, не думая, хочешь научиться подтягиваться 30 раз — иди и начинай подтягиваться сейчас сколько можешь, хочешь внедрить что-то на работе — сделай первый шаг. Идеальный план может никогда не составиться. Конечно, это правило работает не всегда, но у меня, человека с аналитическим складом ума, было больше ситуаций, когда я подумал и не сделал, чем сделал не подумав.

На стадионе Артура Эша в Нью-Йорке есть табличка с цитатой легендарной теннисистки Билли Джин Кинг: «Pressure is a Privilege» («Давление — это привилегия»). Для профессиональных спортсменов эта фраза символизирует то, чем выше поднимаешься, тем большее давление испытываешь со стороны соперника, болельщиков, журналистов и даже самого себя. В работе всё то же самое, только слово «давление» можно заменить на «ответственность». Когда я стал техническим директором, ответственность выросла в разы. И в моменты, когда становится тяжело, повторяю себе: «Ответственность — это привилегия». Если ты не выдерживаешь этой ответственности или давления, отойди в сторону и уступи место тому, кто сможет.

В детстве родители часто повторяли фразу: «Делай что должно, и будь что будет». Эта фраза стала моим первым уроком. В студенческие годы я понимал её так: если приложить максимум усилий, то обязательно получишь результат. Так и получалось. Например, если при подготовке к экзамену я выкладывался на 100%, то с легкостью его сдавал. Не было ни одного случая, чтобы потраченные усилия не окупились. Казалось, что если работать на максимуме, то всё будет прекрасно. Но за время развития карьеры стало понятно, что это правило работает только на коротких дистанциях и далеко не во всех задачах. И делать надо не «максимум», а то, что «должно».

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

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