З програмістів менеджери: як і навіщо

Менеджери, які виросли з програмістів, тестувальників і інших технічних фахівців, розповіли 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» Даніела Канемана.

Також ходив на тренінги і семінари з мотивації, лідерства, проектного менеджменту, роботі в команді, діловому листуванні.

З чого почати? Вчіть англійську. Знайдіть людей, які вже пройшли цей шлях до ВЕЧОРА-а, спілкуйтеся з ними. Із звичайного спілкування ви візьмете дуже багато. Беріть на себе відповідальність вже сьогодні, не чекайте, поки вас назвуть менеджером або старшим або ще якимось.

Найцінніше, що є у менеджера — це люди. Діліться своєю думкою і слухайте думку інших людей. Працюючи у великій команді, ви не зможете знати все краще за всіх і доведеться покладатися на інших людей. На DOU була стаття про менеджерів , в якій говорилося, що менеджер повинен бути менш чутливим до невдач, ніж розробник.

І ще трохи підтягніть англійська. KubasovaETC — це тренінг-центр для менеджерів та учасників IT-проектів, який створений з моєю участю для тих, кому потрібен робочий IT-англійська і менеджерські soft skills.

Потрібен менеджеру технічний бекграунд? Це питання виникає частіше у тих, у кого немає ні управлінського, ні технічного досвіду. Для деяких пройдені курси з JavaScript і пара місяців роботи у веб-студії — це технічний бекграунд. З іншого боку, у технарів багато проблем при різкому переході у менеджери, про що написано в книзі «Як пасти котів» .

Мені дуже сподобалася стаття на DOU від UI/UX експерта Ліни Кононенко, яка говорить про важливість знання предметної області. Мені здається, що для менеджера глибоке розуміння предметної області важливіше технічних знань. В такому випадку комунікація з бізнесом набуває рівноцінний характер, менеджер може бути повноцінним учасником бізнес-процесу, вносити свої пропозиції і доносити бачення команди в контексті зрозумілою клієнту, а не просто бути виконавцем замовлення.

Лілія Ступницька , Senior Project Manager у SoftServe

Насправді я повернулася на позицію Project Manager вже вдруге. «Захворіла» комп'ютерній ютерами і програмуванням ще в 90-х, коли це було зовсім непопулярно. Більшість людей сприймали комп'ютерній комп'ютери як небезпеку зіпсувати зір чі активність для «ботанів». Але мене тоді захопив тієї світ: можливість створювати щось, чого раніше не існувало, стирати межі нереального.

Свою кар'єр єру в професійному ІТ я почала в 2003 році з посади системного адміністратора. Це була робота при кафедрі університету, яка давала можливість не лише на практиці застосувати знання з hardware і мереж, а й працювати над дипломним проектом.

Потім я отримала пропозицію працювати в SoftServe в напрямку QC. Спочатку сприймала цю роботу як тимчасову, але так вийшло, що пропрацювала в компанії 10 років. Пройшла насичений шлях від інтерна, якого треба було вчити, до менеджера розподілених команд, які знаходилися офісах різних країн світу, навіть на Філіппінах.

Не можу сказати, що свідомо чи цілеспрямовано рухалася до менеджменту. Мене завжди цікавила і продовжує цікавити інженерія. У кожному новому проекті мене заряджає складність технічного завдання та свобода у виборі підходу до його розв'язків язання. Проте в мене завжди добре виходило організовувати процес роботи і працювати з людьми.

Про перехід. Моя перша робота на рівні delivery була в SoftServe на посаді Software Development Manager. Отримавши пропозицію керувати командами, я погодилася. Це був новий вектор розвитку кар'єр кур'єри, і я вирішила спробувати.

Проте після неповного року роботи я пішла в декрет. Саме в цей час відбувалася реструктуризація компанії, і через півроку після мого виходу з декрету цієї посади вже не було.

У тієї годину я отримала пропозицію від компанії Remit, де пропрацювала майже 4 роки на позиціях QA Director і Delivery Manager.

Коли з'єднання явилася можливість, я знову повернулася в команду SoftServe, бо мені дуже подобаються амбіції та візія цієї компанії, і мені хотілося б розвиватися разом з нею. Зараз я знову працюю на рівні проектного менеджменту.

Про відмінності у роботі. Коли ти на інженерній позиції, то тобі хвилюють тільки технічні задачі. Коли ти задіяний у менеджменті, то повинен навчитися бачіті картину ширше. Потрібно розвинути навики переговорів, роботи з людьми, мати базові знання у фінансах, вміти бачіті бізнес клієнта.

Про навчання. Основа основ у проектному менеджменті — це PMBoK. Проте вона може бути дещо складною, якщо це ваша перша книга в цьому напрямку. З власного досвіду можу порекомендувати для початківців:

«Менеджерами не народжуються» Денні Стрігл та Френка Свайтека;
«Strengths based leadership» Тома Рата і Баррі Кончі;
«Guide to Financial Management» Джона Теннета.

На ринку зараз достатня якісної літератури, тому головне — не стримувати себе та багато читати.

З чого починати? Дуже важливо на початку зрозуміти для себе, для чого вам це потрібно. Це дозволить не розчаруватися загалом і чітко розуміти, чи в правильному напрямку ви рухаєтеся.

Наступне — відкиньте всі «не можу», «не готовий», «це складно». Це все відмовки, які перешкоджають розвитку. Людина або хоче змін і робить їх, або насправді не хоче змін і знаходить собі виправдання. Одразу налаштуйтеся, що треба буде багато та старанно працювати, зокрема і над собою.

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

Також варто розглянути освітні курси та модулі. Зараз їх досить багато — як для початківців, так і для людей з досвідом у менеджменті. Якщо ваша компанія не має власних курсів, а свого ментора ві переросли, проте відчуваєте, що ще потрібно здобути чи структурувати знання, то я б рекомендувала LvBS , зокрема курс MS in Tech Management .

Чи потрібен менеджеру технічний бекграунд? Усе залежить від того, що вважати технічним бекграундом. Звісно, менеджер винний розуміти SDLC та суть технологій, з якими працює його команда, проте це зовсім не означає, що людина обов'язково повинна мати досвід роботи техлідом чи архітектором. Я б навіть сказала, навпаки: усі повинні усвідомлювати, що коли техлід змінює кар'єр єрний напрямок на менеджерський, він вже не зможе достатня тримати фокус на інженерії, тому досить швидко втратить технічну кваліфікацію.

Мені зустрічались зовсім не технічні менеджери, які чудово виконували саме функцію управління командами, а також класні технічні менеджери, які погано справлялися з управлінням. Один з найкращих PM-ів, з якими мені доводилося працювати, до роботи в IT керував меблевою фабрикою :) Проте в нього була технічна освіта і він дуже добре розбирався в технологіях.

Олексій Бойчев , Program Manager в Luxoft Ukraine

Моя інженерна кар'єра почалася ще до Luxoft. Три роки я працював програмістом в ІТ-відділі досить великої торговельної компанії. У 2011 році прийшов в Luxoft на поєднану позицію — одночасно був Software Tester і Junior Developer. Взяв участь у кількох проектах, а через рік став Junior Developer офіційно. Виріс до Middle, потім і до Senior.

З 2016 року я став PM. Займався паралельно кілька невеликих проектів, по 4-5 чоловік кожен.

Чому пішов у менеджери? Коли я тільки прийшов у компанію на позицію тестувальника, уже розумів, що хочу рухатися і розвиватися в напрямку проектного менеджменту. У мене було суб'єктивна думка, що у мене це виходить. Компанія дала мені цю можливість.

Про перехід. Мій перехід в PM був досить плавним. Крім моїх поточних проектів у Luxoft на той момент, з'явилися нові, які було необхідно підхоплювати. У цих проектах був якийсь вакуум процесів і планування, який мені і довелося заповнювати. Суть роботи залишалася тією ж, однак її ставало більше.

Про відмінності в роботі. Я люблю планувати, люблю будувати і налагоджувати процеси — це те, з чим працює PM. Все це я робив і раніше, проте зараз зросли масштаби і, відповідно, зона відповідальності і рівень складності завдань.

Наприклад, в моєму поточному проекті я відповідаю за всю Software Engineering частина V-моделі, за всі шість процесів інжинірингу і за два етапи системного рівня: Software Integration і Software Qualification Test. Ми займаємося всім стеком згідно Automotive стандарту ASPICE — від Software Requirements Analysis до Quality Assurance.

Раніше моя зона відповідальності обмежувалася одним-трьома етапами.

Про навчання. Біблія PM — це PMBoK. Все інше, пов'язане з проектним менеджментом, теж треба читати і слідкувати за трендами. Зараз в моді Agile, це добре, але не варто забувати про Waterfall, V-модель. Потрібно стежити, як вони розвиваються і як змінюється PM-світ. Кожен проект вимагає індивідуального підходу, і ви повинні бути здатні вибрати правильну методологію та адаптувати її під ваші потреби.

Жодна з книг не дасть правильної відповіді або якусь срібну кулю, вона лише додає їжі для роздумів. Тому можу порекомендувати підживлювати свій розум новою інформацією та аналізувати її.

Кожен новий проект — особливий, індивідуальний по безлічі причин. Одна з них — різні стейкхолдери, які і працюють по-різному. У кожному випадку процеси в проекті потрібно налаштувати таким чином, щоб досягти максимально ефективного взаємодії всіх стейкхолдерів. Тому чим більше інформації — тим більше PM буде бачити і тим точніше зможе сформувати робоче оточення.

З книг можу порадити «Management Gurus» Девіда Еванса про історію Automotive і про те, як змінювався Project Management з ходом часу — від початку XX століття і до сьогодні.

Крім того, для розвитку PM-необхідно випробовувати свої можливості і межі. Саме проектний менеджер повинен вміти приймати рішення, коли інші їх приймати вже не можуть, і працювати під тиском. Багато замовників цим користуються і часто намагаються продавити свої рішення, користуючись фізичною і психологічною втомою менеджера. Фактично потрібно поміщати себе в стресові умови, час від часу — спорт, менша кількість сну, хобі, вимагають зусиль. На старті проекту це буде дуже корисно. По цій темі порекомендую книгу Пітера Друкера «Managing Oneself» .

З чого почати? По-перше, потрібно навчитися планувати. Завжди і все, навіть побутові речі, будь то заміна розетки будинку або завдання за проектом на роботі. І в тому і в іншому випадку постарайтеся виділити 50% часу на планування, 40% - на проведення та 10% на аналіз. Lessons learning — обов'язкова умова для саморозвитку. Зробіть висновки, як можна прискорити виконання завдання, а в наступний раз будете планувати вже по-іншому. Цей важливий навик має стати вашою звичкою.

По-друге, відчувати себе і бути спокійним під час стресу. Краще починати купувати цей навик до старту кар'єри PM-а.

По-третє, необхідно вчитися домовлятися. Скрізь, де ви коммуницируете з людьми — від магазину і пошти до робочого офісу. Домовляйтеся швидше, домовляйтеся простіше і ні в якому разі не створюйте конфлікти.

Потрібен менеджеру технічний бекграунд? Отримати технічний бекграунд у всьому неможливо. Тому його важливо вміти отримувати, а не мати, важливо вміти розширювати свій кругозір. Робота проектного менеджера вельми специфічна — вона описана в PMBoK і не прив'язана ні до яких технологій.

Але якщо ти керуєш окремим проектом, ти повинен розуміти його технічний бекграунд хоча б на high-level і вміти швидко його отримувати. Робиться це через спілкування з людьми, які передають ці знання через самоосвіту, на яке обов'язково потрібно виділяти час.

Тому потрібен технічний бекграунд менеджеру? Так. А ось мати технічний досвід перед стартом конкретного проекту, я вважаю, не обов'язково, але його наявність дуже допоможе.

Любомир Лядик , Centres of Excellence Director в ELEKS

Спершу я займався розробницько-проектувальною роботою в одній хардверній компанії. Колі ж 12 років тому прийшов у ELEKS, то починав як QA-інженер, потім ставши QA-лідом.

Після чотирьох років роботи, пов'язаної із тестуванням, прийшов до того, що мені подобається організація процесів, робота з людьми і вирішив піти у проектний менеджмент. Ще через чотири роки доріс до Head of PMO і згодом ставши директором Центру компетенцій.

Робота менеджера — це знайомства з новими людьми, формування, групування та мотивування команди, донесення до неї ідеї проекту, і, як результат, досягнення цілей. Це ті, що дуже мотивує. Коли плани стають реальністю — це особливе задоволення.

Про перехід. Коли я зрозумів, що хочу рухатись у проектний менеджмент, поставивши собі за мету здати PMP-сертифікацію — одну з найбільш визначних у світі. І мені це вдалося. Попередньо я відвідував спеціальні підготовчі курси від ELEKS. Сам курс тривав приблизно п'ять тижнів і давав право отримати сертифікат. Однією з необхідних умов була наявність підтвердженого управлінського досвіду.

Про відмінності у роботі. Найважливіше, що я отримав на позіції PM, — можливість приймати рішення. Саме це є одним із головних KPI. І чим ефективніше та швидше ти це робиш, тим кращий результат. Прийняття рішень — це не тільки вирішенню, куди і як рухатися, але й усвідомлення усієї відповідальності, яка постійно зростає. Тобто чим вищу посаду я здобував, тим більшою ставала відповідальність.

Про навчання. Після курсів та отримання PMP-сертифікату я вирішив рухатися на рівні організації, але зрозумів, що мені бракує ширших, більш стратегічних знань. Тому моїм наступним кроком був вступ до LvBS, щоб отримати бізнес-освіту. Обрав напрямок Technology Management — це як стратегічний, так і більш широкий фінансовий менеджмент. Навчання дозволив мені змінити парадигму бачення бізнес-управління як такого на рівні організації.

З чого починати? Вимоги до ВЕЧОРА-а — теперішні і ті, які будуть у майбутньому, — відрізнятимуться. Тобто потрібен буде не просто класичний адміністратор, який вміє організувати усі процеси на проекті, а людина-лідер з високими leadership-скілами, soft-скілами та емоційним інтелектом, яка вміє організувати довкола себе інших людей і досягати результату. Ну і, звісно, бути керівником і управлінцем на рівні людських якостей. Це ідеальний профіль керівника на майбутнє.

Багато працівників переходять до нас з інших офісів, попередньо пройшовши випробувний термін. Першим ділом я кажу їм: «Ви повинні розуміти, що потрібно багато працювати з людьми, брати на себе відповідальність, приймати рішення і, власне, не стільки говорити самим, як слухати інших. І досягати результату спільно з командою».

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

Чи потрібен PM-технічний бекграунд? Якщо людина в минулому — розробник, то це, звісно, плюс, але не вимога. Щоб стати PM, зовсім не потрібно мати технічний бекграунд. Головне розуміти азі: як відбувається розробка ПЗ, з чого вона складається. Ґрунтовніші знання не є обов'язковими.

Сьогодні приблизно 90% PM — не технічні фахівці. Іноді це люди, які не перейшли з IT, а з інших сфер, де виконували управлінські обов'язки, які вміють спілкуватися з людьми, чути замовника, менеджити його потреби. Це саме ті люди, на яких ми перш за все робимо ставку.

Опубліковано: 18/07/18 @ 07:00
Розділ Різне

SEO Блог