Из программистов в менеджеры: как и зачем
Менеджеры, которые выросли из программистов, тестировщиков и других технических специалистов, рассказали DOU, почему они выбрали именно такой путь развития, как обучались и чем принципиально менеджмент отличается от инженерной работы.
Мы собрали много интересных историй менеджеров, поэтому материал опубликуем в двух частях. Представляем первую.
Андрей Галинский, Project Manager в Provectus
До менеджмента я работал разработчиком, ведущим разработчиком, тимлидом, а также ведущим инженером в крупной государственной компании. Занимался разработкой ПО, проектированием и разработкой программно-аппаратных комплексов. Было много проектов, связанных с морской навигацией: работа с железом, электронными картами, обработкой сигналов, автоматизация управления, телеметрия и т. д.
Вплоть до 2011 года работал в основном под Windows и Linux на разных языках и фреймворках, но всегда предпочитал C++. Затем ушел в мобильную разработку.
О переходе. Когда я был разработчиком, у меня периодически появлялись идеи, как улучшить не только код, но и процессы за пределами кодирования — своевременную и качественную поставку, тестирование, документацию. Это и было поводом задуматься о менеджменте. В какой-то момент меня просто назначили PM в той же компании, где я работал на технической позиции. Но фактически я тогда и так уже какое-то время занимался управлением проектами, где выступал в разных ролях.
Таким образом, «чистым» PM, который к коду уже не прикасается, я стал после 10 лет работы техническим специалистом. И на этой позиции работаю уже 8 лет.
Об отличиях в работе. Главная разница в том, что я больше не пишу код. Тяжело сравнивать то, чем занимаешься сейчас, и то, что делал много лет назад.
В программировании мне нравилось чувство удовлетворения, когда сам сделал что-то крутое и интересное. В PM нравится возможность влиять на ход событий и самостоятельно принимать решения, несмотря на серьезную ответственность.
Об обучении. Какие-то знаковые книги, которые плотно засели в памяти, я вряд ли посоветую. Находил материалы по мере необходимости и в зависимости от ситуации. Просто так читать что-то, к чему на данный момент не имеешь отношения, — например, «Основы маркетинга» на позиции разработчика — наверное, не стоит. Когда-то я разрабатывал комплексный проект, который кроме технических частей подразумевал требования к персоналу, пожарной и электробезопасности, рабочим местам. Пришлось погружаться и в это, но сам я вряд ли стал бы такое изучать.
На текущий момент, думаю, актуальны Agile practices related topics, PMBoK, курсы от команды «Стратоплан». Есть также неплохой ресурс projectmanagement.com.
С чего начать? Начинайте с чего-то конкретного — с небольшого проекта, на котором можно потренироваться, чтобы прочувствовать то или иное прикладное применение выбранной практики. Нужно сфокусироваться только на проекте и выбранной методологии, не распыляться и попытаться найти аналогичные примеры, которые помогут в управлении. При этом не бояться экспериментировать и тщательно анализировать успехи и неудачи.
Обязательно нужно доверять своим ощущениям. Идеальный вариант — когда есть опытный PM, который постоянно находится рядом и помогает.
Нужен ли менеджеру технический бэкграунд? Думаю, хотя бы какой-то, но технический бэкграунд нужен. В нашей отрасли PM работает с инженерами и должен, хотя бы в общем, понимать процессы на всех уровнях.
Конечно, нельзя впадать в крайности и лезть «помогать» разработчику, потому что ты сам «раньше такое уже делал». Но и полностью отдавать ему какие-то вещи на откуп тоже нельзя, так как разработчики и менеджеры на одни и те же вещи смотрят под разным углом. Например, инженер хочет сделать качественно, а PM — быстро, потому что это важно для заказчика. И эту ситуацию нельзя отпускать. Здесь технический бэкграунд поможет договориться и найти компромисс.
Илья Кубасов, Delivery Manager в Infopulse
Мой основной технический скил — это MS SQL Server и разработка баз данных. Большую часть опыта я получил в сфере банковских расчетов, аудита и страховых компаний, то есть в тех сферах, где больше всего требуются сложные расчеты и построение всеобъемлющей отчетности.
Еще будучи студентом КПИ, я занимался всевозможными студенческими активностями, участвовал в разных молодежных организациях. С третьего курса стал руководить несколькими группами людей. На пятом курсе мы с друзьями из других областей создали свою всеукраинскую студенческую организацию. В 2010 году, оканчивая университет, я отвечал за работу группы порядка 150 студентов.
Видимо, вся эта деятельность и сформировала во мне готовность брать на себя ответственность, а также дала множество реальных примеров того, что такое «ожидание и реальность» в организационных вопросах.
Поступив на работу в роли SQL Developer, я в первую очередь стремился развить технические навыки, расти профессионально. Помню, что первые 4 года о работе менеджером не думал. Считал для себя достижением пройти несколько собеседований и экспертных комитетов в EPAM, когда переходил с Middle-позиции на Senior. Только получив достаточный опыт работы разработчиком и уровень компетенции в том, что я делаю, я почувствовал желание снова заняться управленческой работой.
В общей сложности пусть от разработчика до позиции Delivery Manager занял примерно 6,5 лет и уже 2,5 года я работаю как Delivery Manager.
О переходе. На момент перехода я уже работал в Infopulse на позиции Senior SQL Developer и выполнял роль DB Lead на одном из проектов с распределенной командой. В нее входили люди из нескольких городов Украины, Индии и Америки.
Планируя «свитч», я начал искать знакомых, которые уже работали менеджерами, советовался с ними, проходил курсы, даже не афишируя это широко. Считаю, что я хорошо выполнил тогда домашнюю работу :)
И вот выпал удобный случай. В один день пришла рассылка от Head of Unit с темой «Кандидаты на карьерный рост», в которой говорилось, что наш юнит расширяется, требуются архитектор, менеджер, команда. Кто хотел бы попробовать себя в новой роли — пишите. Это письмо пришло ровно через одну неделю после того, как я получил сертификат Certified Scrum Master, и за неделю до того, как получил Certified Scrum Product Owner.
Конечно же, я ответил на это письмо руководства, добавил свои сертификаты по Scrum, Microsoft, указал опыт работы менеджером в сфере образования. К тому же уровень английского языка у меня был upper, чего было достаточно. Уже через неделю проходил внутреннее собеседование, через месяц — с заказчиком. Менеджером первого IT-проекта я стал через полгода после того письма. Для меня эта история подтверждает слова: «Удача — это готовность воспользоваться случаем». Думаю, без той подготовки, которую я проделал самостоятельно, эта возможность прошла бы мимо меня.
Об отличиях в работе. Когда создаешь продукт своими руками — это мощная мотивация для разработчика. Ты имеешь полный контроль над своим кодом и можешь сделать его настолько хорошим, насколько можешь. Степень корреляции между тем, насколько ты стараешься, и тем, что получается в результате, очень высокая.
Менеджер в свою очередь влияет на результат совсем другими инструментами: устанавливая правила, ценности, контроль, мотивацию, формируя команду, выступая мостом между заказчиками и разработчиками. Степень осведомленности о том, что происходит в проекте, у менеджера намного выше. Но менеджер успешен, если команда успешна. В отличие от SQL-разработчика, менеджер не может сказать: «Проблема где-то на фронте», — и считать, что на этом его участие закончено.
Об обучении. Как упоминал выше, я получил два сертификата от Scrum Alliance, что было очень вовремя. У меня не было формального опыта работы менеджером, и это послужило некоторым подтверждением компетенции.
Я считаю, что основной опыт управления получил именно в общественных организациях, где не было оплаты, а только мотивация. Именно там была возможность не только читать книги, но и применять абсолютно все, что хочешь, не опасаясь за последствия. В той среде стоимость неправильно принятого решения равнялась нулю гривен без каких-либо репутационных потерь. Эта роскошь не доступна никому на реальном проекте.
Могу назвать несколько книг, которые мне понравились: «Power Listening» Бернарда Феррари, «Вальсируя с медведями» Тома ДеМарко, «Decisive» Чипа Хиза, «Менеджер мафии» V., «Государь» Никколо Макиавелли, «The Effective Executive» Питера Друкера, «Thinking, Fast and Slow» Даниела Канемана.
Также ходил на тренинги и семинары по мотивации, лидерству, проектному менеджменту, работе в команде, деловой переписке.
С чего начать? Учите английский. Найдите людей, которые уже прошли этот путь до PM-а, общайтесь с ними. Из обычного общения вы возьмете очень много. Берите на себя ответственность уже сегодня, не ждите, пока вас назовут менеджером или старшим или еще каким-то.
Самое ценное, что есть у менеджера — это люди. Делитесь своим мнением и слушайте мнение других людей. Работая в большой команде, вы не сможете знать все лучше всех и придется полагаться на других людей. На DOU была статья о менеджерах, в которой говорилось, что менеджер должен быть менее чувствителен к неудачам, чем разработчик.
И еще немного подтяните английский. KubasovaETC — это тренинг-центр для менеджеров и участников IT-проектов, который создан с моим участием для тех, кому нужен рабочий IT-английский и менеджерские soft skills.
Нужен ли менеджеру технический бэкграунд? Этот вопрос возникает чаще у тех, у кого нет ни управленческого, ни технического опыта. Для некоторых пройденные курсы по JavaScript и пара месяцев работы в веб-студии — это технический бэкграунд. С другой стороны, у технарей много проблем при резком переходе в менеджеры, о чем написано в книге «Как пасти котов».
Мне очень понравилась статья на DOU от UI/UX эксперта Лины Кононенко, которая говорит о важности знания предметной области. Мне кажется, что для менеджера глубокое понимание предметной области важнее технических знаний. В таком случае коммуникация с бизнесом приобретает равноценный характер, менеджер может быть полноценным участником бизнес-процесса, вносить свои предложения и доносить видение команды в контексте, понятном клиенту, а не просто быть исполнителем заказа.
Лілія Ступницька, Senior Project Manager у SoftServe
Насправді я повернулася на позицію Project Manager вже вдруге. «Захворіла» комп’ютерами і програмуванням ще в
Свою кар’єру в професійному ІТ я почала в 2003 році з посади системного адміністратора. Це була робота при кафедрі університету, яка давала можливість не лише на практиці застосувати знання з hardware і мереж, а й працювати над дипломним проектом.
Потім я отримала пропозицію працювати в SoftServe в напрямку QC. Спочатку сприймала цю роботу як тимчасову, але так вийшло, що пропрацювала в компанії 10 років. Пройшла насичений шлях від інтерна, якого треба було вчити, до менеджера розподілених команд, які знаходилися офісах різних країн світу, навіть на Філіппінах.
Не можу сказати, що свідомо чи цілеспрямовано рухалася до менеджменту. Мене завжди цікавила і продовжує цікавити інженерія. У кожному новому проекті мене заряджає складність технічного завдання та свобода у виборі підходу до його розв’язання. Проте в мене завжди добре виходило організовувати процес роботи і працювати з людьми.
Про перехід. Моя перша робота на рівні delivery була в SoftServe на посаді Software Development Manager. Отримавши пропозицію керувати командами, я погодилася. Це був новий вектор розвитку кар’єри, і я вирішила спробувати.
Проте після неповного року роботи я пішла в декрет. Саме в цей час проходила реструктуризація компанії, і через півроку після мого виходу з декрету цієї посади вже не було.
В той час я отримала пропозицію від компанії Remit, де пропрацювала майже 4 роки на позиціях QA Director і Delivery Manager.
Коли з’явилася можливість, я знову повернулася в команду SoftServe, бо мені дуже подобаються амбіції та візія цієї компанії, і мені хотілося б розвиватися разом з нею. Зараз я знову працюю на рівні проектного менеджменту.
Про відмінності у роботі. Коли ти на інженерній позиції, то тебе хвилюють тільки технічні задачі. Коли ти задіяний в менеджменті, то повинен навчитися бачити картину ширше. Потрібно розвинути навики переговорів, роботи з людьми, мати базові знання у фінансах, вміти бачити бізнес клієнта.
Про навчання. Основа основ у проектному менеджменті — це PMBoK. Проте вона може бути дещо складною, якщо це ваша перша книга в цьому напрямку. З власного досвіду можу порекомендувати для початківців:
- «Менеджерами не народжуються» Деннi Стрігл та Френка Свайтека;
- «Strengths based leadership» Тома Рата і Баррі Кончі;
- «Guide to Financial Management» Джона Теннета.
На ринку зараз достатньо якісної літератури, тому головне — не стримувати себе та багато читати.
З чого починати? Дуже важливо на початку зрозуміти для себе, для чого вам це потрібно. Це дозволить не розчаруватися загалом і чітко розуміти, чи в правильному напрямку ви рухаєтеся.
Наступне — відкиньте всі «не можу», «не готовий», «це складно». Це все відмовки, які перешкоджають розвитку. Людина або хоче змін і робить їх, або насправді не хоче змін і знаходить собі виправдання. Одразу налаштуйтеся, що треба буде багато та старанно працювати, зокрема і над собою.
Для початку я б рекомендувала знайти собі наставника — людину, на яку вам хотілося б рівнятися, чий стиль управління вам особисто подобається. Такий підхід буде значно ефективніший за читання книжок, тому що інформація через призму досвіду має значно глибший зміст. Навіть якщо для початку досвід не є вашим особистим.
Також варто розглянути освітні курси та модулі. Зараз їх досить багато — як для початківців, так і для людей з досвідом у менеджменті. Якщо ваша компанія не має власних курсів, а свого ментора ви переросли, проте відчуваєте, що ще потрібно здобути чи структурувати знання, то я б рекомендувала LvBS, зокрема курс MS in Tech Management.
Чи потрібен менеджеру технічний бекграунд? Усе залежить від того, що вважати технічним бекграундом. Звісно, менеджер повинен розуміти SDLC та суть технологій, з якими працює його команда, проте це зовсім не означає, що людина обов’язково повинна мати досвід роботи техлідом чи архітектором. Я б навіть сказала, навпаки: усі повинні усвідомлювати, що коли техлід змінює кар’єрний напрямок на менеджерський, він вже не зможе достатньо тримати фокус на інженерії, тому досить швидко втратить технічну кваліфікацію.
Мені зустрічались зовсім не технічні менеджери, які чудово виконували саме функцію управління командами, а також класні технічні менеджери, які погано справлялися з управлінням. Один з найкращих PM-ів, з якими мені доводилось працювати, до роботи в IT керував меблевою фабрикою :) Проте в нього була технічна освіта і він дуже добре розбирався в технологіях.
Алексей Бойчев, Program Manager в Luxoft Ukraine
Моя инженерная карьера началась еще до Luxoft. Три года я работал программистом в IТ-отделе достаточно большой торговой компании. В 2011 году пришел в Luxoft на совмещенную позицию — одновременно был Software Tester и Junior Developer. Поучаствовал в нескольких проектах, а через год стал Junior Developer официально. Вырос до Middle, потом и до Senior.
С 2016 года я стал PM. Курировал параллельно несколько небольших проектов, по
Почему пошел в менеджеры? Когда я только пришел в компанию на позицию тестировщика, уже понимал, что хочу двигаться и развиваться в направлении проектного менеджмента. У меня было субъективное мнение, что у меня это получается. Компания мне дала эту возможность.
О переходе. Мой переход в PM был довольно плавным. Кроме моих текущих проектов в Luxoft на тот момент, появились новые, которые было необходимо подхватывать. В этих проектах был некий вакуум процессов и планирования, который мне и пришлось заполнять. Суть работы оставалась той же, однако ее становилось больше.
Об отличиях в работе. Я люблю планировать, люблю строить и налаживать процессы — это то, с чем работает PM. Все это я делал и раньше, однако сейчас выросли масштабы и, соответственно, зона ответственности и уровень сложности задач.
Например, в моем текущем проекте я отвечаю за всю Software Engineering часть
Ранее моя зона ответственности ограничивалась одним-тремя этапами.
Об обучении. Библия PM — это PMBoK. Все остальное, связанное с проектным менеджментом, тоже надо читать и следить за трендами. Сейчас в моде Agile, это хорошо, но не стоит забывать про Waterfall,
Ни одна из книг не даст правильного ответа или какую-то серебряную пулю, она всего лишь добавляет пищи для размышления. Поэтому могу порекомендовать подпитывать свой ум новой информацией и анализировать ее.
Каждый новый проект — особенный и индивидуальный по множеству причин. Одна из них — разные стейкхолдеры, которые и работают по-разному. В каждом случае процессы в проекте нужно настроить таким образом, чтобы достичь максимально эффективного взаимодействия всех стейкхолдеров. Поэтому чем больше информации — тем больше PM будет видеть и тем правильнее сможет сформировать рабочее окружение.
Из книг могу посоветовать «Management Gurus» Дэвида Эванса об истории Automotive и о том, как менялся Project Management с ходом времени — от начала XX века и до сегодня.
Кроме того, для развития PM-у необходимо испытывать свои возможности и пределы. Именно проектный менеджер должен уметь принимать решения, когда другие их принимать уже не могут, и работать под давлением. Многие заказчики этим пользуются и часто пытаются продавить свои решения, пользуясь физической и психологической усталостью менеджера. Фактически нужно помещать себя в стрессовые условия время от времени — спорт, меньшее количество сна, хобби, требующие усилий. На старте проекта это будет очень полезно. По этой теме порекомендую книгу Питера Друкера «Managing Oneself».
С чего начать? Во-первых, нужно научиться планировать. Всегда и все, даже бытовые вещи, будь то замена розетки дома или задачи по проекту на работе. И в том и в другом случае постарайтесь выделить 50% времени на планирование, 40% на выполнение и 10% на анализ. Lessons learning — обязательное условие для саморазвития. Сделайте выводы, как можно ускорить выполнение задачи, а в следующий раз будете планировать уже по-другому. Этот важный навык должен стать вашей привычкой.
Во-вторых, испытывать себя и быть спокойным во время стресса. Лучше начинать приобретать этот навык до старта карьеры PM-а.
В-третьих, необходимо учиться договариваться. Везде, где вы коммуницируете с людьми — от магазина и почты до рабочего офиса. Договаривайтесь быстрее, договаривайтесь проще и ни в коем случае не создавайте конфликты.
Нужен ли менеджеру технический бэкграунд? Получить технический бэкграунд во всем невозможно. Поэтому его важно уметь получать, а не иметь, важно уметь расширять свой кругозор. Работа проектного менеджера весьма специфическая — она описана в PMBoK и не привязана ни к каким технологиям.
Но если ты управляешь отдельным проектом, ты должен понимать его технический бэкграунд хотя бы на hight-level и уметь быстро его получать. Делается это через общение с людьми, которые передают эти знания, и через самообразование, на которое обязательно нужно выделять время.
Потому нужен ли технический бэкграунд менеджеру? Да. А вот иметь технический опыт перед стартом конкретного проекта, я считаю, не обязательно, но его наличие очень поможет.
Любомир Лядик, Centres of Excellence Director в ELEKS
Спершу я займався розробницько-проектувальною роботою в одній хардверній компанії. Коли ж 12 років тому прийшов у ELEKS, то починав як QA-інженер, потім став QA-лідом.
Після чотирьох років роботи, пов’язаної із тестуванням, прийшов до того, що мені подобається організація процесів, робота з людьми і вирішив піти у проектний менеджмент. Ще через чотири роки доріс до Head of PMO і згодом став директором Центру компетенцій.
Робота менеджера — це знайомства з новими людьми, формування, групування та мотивування команди, донесення до неї ідеї проекту, і, як результат, досягнення цілей. Це те, що дуже мотивує. Коли плани стають реальністю — це особливе задоволення.
Про перехід. Коли я зрозумів, що хочу рухатись у проектний менеджмент, то поставив собі за мету здати PMP-сертифікацію — одну з найбільш визначних у світі. І мені це вдалося. Попередньо я відвідував спеціальні підготовчі курси від ELEKS. Сам курс тривав приблизно п’ять тижнів і давав право отримати сертифікат. Однією з необхідних умов була наявність підтвердженого управлінського досвіду.
Про відмінності у роботі. Найважливіше, що я отримав на позиції PM, — можливість приймати рішення. Саме це є одним із головних KPI. І чим ефективніше та швидше ти це робиш, тим кращий результат. Прийняття рішень — це не тільки вирішення, куди і як рухатися, але й усвідомлення усієї відповідальності, яка постійно зростає. Тобто чим вищу посаду я здобував, тим більшою ставала відповідальність.
Про навчання. Після курсів та отримання PMP-сертифікату я вирішив рухатися на рівні організації, але зрозумів, що мені бракує ширших, більш стратегічних знань. Тому моїм наступним кроком був вступ до LvBS, щоб отримати бізнес-освіту. Обрав напрямок Technology Management — це як стратегічний, так і більш широкий фінансовий менеджмент. Навчання дозволило мені змінити парадигму бачення бізнес-управління як такого на рівні організації.
З чого починати? Вимоги до PM-а — теперішні і ті, які будуть у майбутньому, — відрізнятимуться. Тобто потрібен буде не просто класичний адміністратор, який вміє організувати усі процеси на проекті, а людина-лідер з високими leadership-скілами, soft-скілами та емоційним інтелектом, яка вміє організувати довкола себе інших людей і досягати результату. Ну і, звісно, бути керівником і управлінцем на рівні людських якостей. Це ідеальний профіль керівника на майбутнє.
Багато працівників переходять до нас з інших офісів, попередньо пройшовши випробувний термін. Першим ділом я кажу їм: «Ви повинні розуміти, що потрібно багато працювати з людьми, брати на себе відповідальність, приймати рішення і, власне, не стільки говорити самим, як слухати інших. І досягати результату спільно з командою».
Саме цей набір задач, а не сподівання вищої зарплати, як іноді буває, повинен мотивувати людей ходити на роботу, розвиватися далі. Розмовляючи з потенційним кандидатом на PМ-посаду, я маю щодо нього саме такі очікування. Далі ми ставимо випробні цілі на певний період і, у разі успішного проходження, запрошуємо на роботу.
Чи потрібен PM-у технічний бекграунд? Якщо людина в минулому — розробник, то це, звісно, плюс, але не вимога. Щоб стати PM, зовсім не потрібно мати технічний бекграунд. Головне розуміти ази: як відбувається розробка ПЗ, з чого вона складається. Ґрунтовніші знання не є обов’язковими.
Сьогодні приблизно 90% PM — не технічні фахівці. Іноді це люди, які перейшли не з IT, а з інших сфер, де виконували управлінські обов’язки, які вміють спілкуватися з людьми, чути замовника, менеджити його потреби. Це саме ті люди, на яких ми перш за все робимо ставку.
