Як почати кар’єру в IT, якщо не вмієш писати код: досвід PM'а

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

В IT потрапив випадково — якось мені на пошту надійшла анкета на вакансію проектного менеджера. Заради цікавості я її відкрив і повеселився, поки відповідав на смішні питання рекрутерів. А оскільки я не звик кидати почате на півдорозі, то вже заодно пройшов і тестове завдання, розібрався з мануалами і склав тест Google Adwords. Під кінець подальших співбесід мене захопило, і я захотів спробувати себе в новій галузі. Так все почалося.

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

Про перші кроки

IT-компанії справді беруть новачків на роботу. Бо бракує готових фахівців. Справа не в конкретному вузі, а в тому, що наша система освіти не дає комплексних фахових знань, котрі можна застосовувати на практиці. Скільки, наприклад, в економічних університетах було лекторів, які побудували дійсно ефективну і актуальну бізнес-модель? Не можна говорити, що таких немає, але здебільшого це теорія, а не практика. Як на мене, університет вчить організовувати власний час та швидко шукати та систематизувати інформацію.

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

Щодо безкоштовної роботи для стажу — це погана ідея. Хіба що, можливо, для здобуття досвіду під час навчання. Людина вчиться в першу чергу для себе, а роботодавцю має видавати результат, то чому він має бути безкоштовним? Якщо працівник приносить прибуток чи іншу користь, це повинно бути оплачено.

Якщо є можливість, потрібно йти на курси і потім одразу працювати.

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

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

Про зарплатню

Узагальнені суми ви й так бачили у свіжому дослідженні DOU. Я вважаю правильною систему, коли спершу новачок отримує мінімальну ставку, а решта — бонус за успішне ведення проекту. В такому випадку, коли PM погано працює, йому вистачає лише на булку та кефір, відповідно при якісній роботі ситуація діаметрально протилежна. Але не все аж так просто, є особливості. Під час сприятливої економічної ситуації в країні, наприклад, років вісім тому у банківському секторі можна було отримувати пристойну зарплатню легше і спокійніше, аніж в ІТ. Тепер ж відрив на користь IT доволі відчутний. Але щоб заробити «айтішні» гроші, потрібно й працювати в рази більше.

Бувають і дивні випадки: якось до нас на випробувальний термін потрапила дівчина. Не допрацювавши і до кінця робочого дня, запитала, коли вже вона буде отримувати велику зарплатню. Не варто так. Спершу потрібно показати, що можеш, а потім навіть без питань усе буде зрозуміло.

Приклад із особистого досвіду. Спершу кар’єра (і зарплатня відповідно) розвивається за експансивним (поривчастим) типом розвитку — ще «зелений» PM вчиться на заявках. Опрацював, наприклад, сотню, конвертнув лише одну і почав працювати над проектом. Потім йому вже не потрібно 100, а достатньо 10. А з досвідом усі 5 вхідних заявок стають проектами. Кількість переходить в якість. Згодом вже нема потреби розпилятися — цікавіше, ефективніше і вигідніше вести менше проектів, але з більшим оборотом.

Про проект в IT

Коли PM бере в роботу проект, то має розуміти навіщо. Бізнес-проекти створені, аби приносити прибуток. Відповідно вся робота команди має бути направлена на те, щоб заробити більше коштів для проекту. Витрати, конверсії, ліди, вартість/кількість транзакції, приріст аудиторії — це проміжні метрики, котрі допомагають досягти кінцевої мети. Клієнт довірятиме компанії і буде погоджуватися на впровадження нововведень тільки тоді, коли PM надасть рішення, які працюють.

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

Зараз я зовсім не беру нових заявок. Тим не менше роботи завжди вистачає. Клієнти приходять від партнерів або через «сарафанне радіо». Але не можна одразу надати новому клієнтові комерційну пропозицію — спершу потрібно зробити ґрунтовний аналіз. А на це потрібно багато часу — необхідно оцінити проект з усіх сторін, перш ніж зрозуміти, чи може агентство взагалі бути йому корисним.

Про боротьбу з овертаймами

Під час роботи у фінансовому секторі я мав доволі комфортні дедлайни і за стандартний робочий день усе встигав. У більшості IT-компаній існує режим багатозадачності. У Netpeak в мене траплялися тижні перепрацювань. Хоч вони були оплачувані здобутим результатом, але це суттєва проблема. Мене врятувало структурне планування.

Я навчився так розподіляти робочий час, щоб працювати менше, а встигати більше. Все сплановано заздалегідь — на місяць, тиждень і день. Місяць та тиждень, а також всі зустрічі та скайп-коли я прописую в системі Планфікс (сервіс-задачник, синхронізований з внутрішньою агентською CRM) та календарі, деякі задачі з обов’язковими чек-листами — тижневими та місячними — щось на зразок чек-поінтів. А ось щоденне планування мені досі комфортніше вести у звичному паперовому записнику, щоправда, ніхто ці каракулі, крім мене, розібрати не може — тому це суто для мене, але такий підхід також допомагає мені структурувати денну операційку.

Усі задачі я розбиваю на 4 блоки:
— Операційка;
— Планування;
— Спілкування по поточній роботі;
— Аналітика майбутніх проектів.

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

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

Дуже економить час в нашій команді правило відповідати день в день на кожен вхідний запит. Заборонено нагромаджувати дедлайни — все має бути оперативно і по строкам.

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

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

Про прокачку скілів

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

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

Наприклад, Марина Бриль — ми з нею прийшли в агентство приблизно в один час без досвіду в IT. Обидва починали працювали над абсолютно збитковим проектом з мінімальною комісією. Ми заглибилися в тематику, проводили зустрічі і всіляко гарували над проектом попри його, на перший погляд, безперспективність. Зараз проект в рази розширився, в мене своя команда, а Марина завдяки своїй наполегливості очолює департамент мобайлу, працює з крупними проектами та ділиться знаннями на конференціях. І таких історій успіху у нас багато.

Висновки

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

Взагалі, однозначного рецепту успіху немає, в кожного він свій. Одне я зауважив напевне, і це стосується не тільки ІТ, а взагалі будь-чого, що робить людина. Можна гарувати до сьомого поту, і щось може тимчасово не вдаватися, не склалися поки планети — треба більше зусиль, не боятися помилок (вони трапляються скрізь, але в 99 кейсах зі 100 це поправимо). Однак якщо сумніватися і нічого не робити взагалі, або робити нечесно, не до кінця — 200% нічого і не вийде. Завжди варто доводити почате до логічного завершення.