Путь от разработчика до менеджера

При построении карьеры в определенной области чаще всего выделяют 2 уровня движения: горизонтальный и вертикальный.

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

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

Первый путь связан с работой с людьми намного меньше, чем второй и это для большинства людей — самое решающее отличие.

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

С детства меня захватывали компьютеры и все, что с ними связано, тем не менее назвать себя гиком, технарем в полной мере этого слова я не могу. Эксперименты с языками программирования прошли через мои школьные годы, включая победы на мелких районных олимпиадах (на городской я, естественно, валился ибо не был особо заинтересован в сложных алгоритмах). Сайт школы был написан мной для какой то научной школьной конференции, на которую меня принудительно послали. Университет, само собой, оказался Информатики и Радиоэлектроники (БГУИР) и после второго курса я оказался в америке, где уже закончил обучение в колледже по специальности программист-аналитик. Параллельно продолжались эксперименты с мелкими сторонними проектами и системами. Первая официальная работа в айти — программист пхп.

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

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

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

В последствии я сильно укреплял эти навыки чтением огромного количества литературы, начиная от обычных Листера, де Марко, Брукса и продолжая психологической литературой, такой как книги Эрика Берна или изучение различных психологических типологий.

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

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

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

Проблемы взаимодействия технарей и гуманитариев свойственны не только IT, но и другим областям и принципы улучшения коммуникации схожи. Самым простым способом решения проблемы является наличие человека, который бы выполнял роль посредника между заказчиком и разработчиками, так называемого “переводчика”. Этот человек, обладает техническим складом ума, часто техническим образованием или опытом работы на технической позиции, умеет общаться с людьми, находить к ним подход, то есть обладает высокими коммуникативными навыками. Его задача, понять желания обеих сторон, то есть понять, что хочет заказчик и перевести это на язык технической документации или технических терминов, понятных разработчику, и в обратную сторону, суметь объяснить заказчику в понятных для него словах, с какими техническими трудностями столкнулись разработчики или какая тех информация и как влияет на задание заказчика. Обычно это роль выполняет бизнес-аналитик, в его отсутствие тимлид, проектный менеджер или технический редактор

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

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

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

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

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

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

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

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

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

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

В каждом конкретном случае учитывайте все эти возможности и умейте донести это до команды.

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

Я хочу подчеркнуть один очень важный и неочевидный момент в профессиональном развитии, в принципе, в любой отрасли: важно в какой то момент не застрять делая одно и тоже, хоть и хорошо. Поясню на примере: если вы проработали 5 лет в госсекторе, то при переходе в аутсорс компанию вы обнаружите что почти ничего из того, что вы так хорошо умеете, тут не нужно. Аналогично проработав 5 лет в аутсорсе и перейдя в продуктовую компанию вы тоже откроете для себя много нового. Этот эффект можно смягчить много читая, слушая курсы, посещая конференции, но все равно практику не заменит ничего. Потому не бойтесь периодически менять компании, в среднем это каждые 2–3 года, ведь чем шире ваш опыт — тем выше ваша ценность как специалиста и тем шире ваши возможности.

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

Проще говоря — это то, как вы работаете с собой и другими людьми и что из этого получается: то что вы хотите или все вокруг вам мешают.

Итак давайте подведем итоги.

Основные качества и компетенции которые вам понадобятся:

• Проактивность/инициативность
• Умение анализировать
• Устойчивая психика
• Решительность
• Нацеленность на решение проблем
• Желание постоянно учиться и быть информированным
• Готовность брать на себя ответственность
• Уметь работать с разными людьми (основанное на любой или нескольких психологических типологиях)
• Умение сказать “нет”, где это необходимо и аргументированно отстаивать свою точку зрения
• Стратегическое мышление
• Умение планировать в первую очередь свое время
• Умение встроиться в бизнес и выступать в команде в позиции представителя бизнеса. Учитывать скорость и стоимость денег, уметь донести это команде.

Можно еще добавить в список такие качества как харизма, оптимизм, эмпатию, амбиции и так далее. Роль личности — ключевая в управлении проектами.

Технические компетенции:

• Знание как минимум одной серьезной методологии, такой как PMI или PRINCE2
• Отличное знание гибких методологий и в каких случаях их применять
• Умение планировать проект (WBS, Gannt chart, crititcal path и т.д) и полное понимание его жизненного цикла и всех сопутствующих документов
• Умение использовать основные технические инструменты на уверенном уровне (Excel, MS Project, Jira и т.д)
• Знание минимум одного иностранного языка, лучше английский
• Умение создавать грамотные презентации.