Джеки Баваро - Карьера менеджера IT-проекта. Как устроиться на работу в ведущую технологическую компанию

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

– Что вы посоветуете продукт-менеджерам, желающим развить свою карьеру?

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

Уделяйте главное внимание тем, с кем вы работаете. Эти люди – ваш лучший ресурс для самосовершенствования. Поскольку в технической работе случаются стрессы, важно, чтобы окружающие вас были доброжелательными. Лучше всего работать с людьми, с которыми вы работали раньше. Конечно, это сложно сделать в начале карьеры, но если вы проявите достаточное упорство, то возможно, найдете подходящих людей через два-три «рукопожатия». Вы также можете организовать себе «пробный период», работая консультантом.

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

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

– Расскажите немного о своей карьере.

Я всегда занимался управлением программами. Я начал работу над Microsoft Office в качестве практиканта и два лета занимался Outlook. После колледжа я пришел в Microsoft работать над Visual Studio в команду, где был создан язык C# и велась работа над C++.

Я начал заниматься постпроцессорным компилятором C++, поэтому моя работа была очень технической. Многие люди ассоциируют управление программами с внешними интерфейсами, но я сотрудничал с AMD, Intel и производителями интегральных схем. Это было очень здорово.

Поработав так некоторое время, я занялся другими аспектами компилятора C++. Я спроектировал язык для общей языковой инфраструктуры (Common Language Infrastructure, CLI). Я ездил по миру и взаимодействовал с ECMA, ISO и компаниями, занимавшимися развитием языка.

После этого я решил расширить свой опыт. Я стал одновременно играть роли продукт-менеджера и руководителя. В качестве продукт-менеджера я занимался разработкой Visual Studio 2008. Хотя я все еще был руководителем программ, моя деятельность была сосредоточена на управлении выпуском продукта. Обычно руководители программ мало занимаются управлением проектами и значительную часть времени тратят на дизайн продукта. Релиз-менеджеры уделяют внимание завершению проекта и другим задачам управления проектами, обеспечивающим успешный выпуск продукта.

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

Затем я вернулся в США и получил должность руководителя групповых программ по. NET Framework. Руководитель групповых программ является менеджером второго уровня. Я принимал участие в выпуске Windows 8, а затем перешел в команду, работавшую над C# и Visual Basic. У них был новый компилятор, но его разработка выбилась из графика, поэтому я занялся решением проблемы с его выпуском.

Совсем недавно я приступил к новому еще неоконченному проекту по разработке оборудования. Для разнообразия я решил вернуться к роли независимого исполнителя и моя миссия в этом проекте – создать первоклассную платформу разработки.

– Какие моменты были прорывными в вашей карьере?

Действительно ярким моментом в моей карьере было написание языковой спецификации, которая в конечном счете стала стандартом для C++ и CLI. Я работал над ней вместе с сотрудниками других компаний.

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

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

Еще один аспект, о котором я хочу рассказать, – это влияние, которое вы можете оказывать уже на ранних стадиях своей карьеры. Одной из моих первых разработок для компилятора C++ стала реализация ключа /GS (проверка безопасности буфера). Эта функциональная возможность стала реакцией на атаки, основанные на переполнении буфера. Моя команда создала средство противодействия переполнению буфера, но его эффект был неполным. Я подумал, что нужно сделать для того, чтобы эта наработка стала действительно полезной.

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

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