Як працюють продуктові команди та ще 8 популярних питань про IT
Якщо ви хочете потрапити в IT, то, швидше за все, вже зіткнулися з великою кількістю термінів, процесів і ролей. Вам може здатися, що всі розуміють, що відбувається, а ви ні. Через це здається, що в IT краще не потикатися.
Але це не так. IT — така сама індустрія, як фінанси чи нерухомість. Вона має свої особливості, у цій статті ми про них розповімо.
Стаття складається із двох блоків. У першому блоці ви дізнаєтеся, як працюють продуктові команди й зрозумієте зміст найпоширеніших термінів. У другому блоці ви отримаєте відповідь на популярні запитання, які виникають у новачків IT.
Якщо ви тільки занурюєтеся у сферу IT і хочете уникнути помилок новачка, також корисно буде прочитати продуктові діалоги про те, як запустити свій стартап.
Про те, як працюють продуктові команди, ми розповімо у форматі історії про Девіда — продакт-менеджера, який вирішив запустити свій стартап.
1 тиждень
Девіда завжди цікавила тема критичного мислення. Він розвивав у собі цю навичку і розумів, що найважливіше у заняттях — це регулярність. При цьому заняття не вимагають багато часу — достатньо виділити 15 хвилин на день для вправ.
Так Девід вирішив зробити додаток для розвитку критичного мислення, який давав би по два завдання на день і нагадував про те, коли їх виконувати.
Девід розповів про свою ідею університетським друзям Джеку та Ганні. Вони захотіли взяти участь у проєкті. Для цього треба було зібрати команду. Зазвичай у команді є продакт-менеджер, розробники, тестувальники, дизайнери, аналітики та маркетологи. Але Девід не міг одразу собі дозволити таку команду.
Девід взяв на себе роль продакт-менеджера – людини, яка відповідає за продукт та синхронізує роботу команди. Девід вже проаналізував аудиторію, визначив цінність продукту та функціональність продукту (фічі), яка цю цінність доноситиме.
Джек та Ганна взяли на себе розробку, яку можна розділити на два напрямки:
Frontend — клієнтська частина продукту, з якою візуально взаємодіє користувач. Це те, що бачить користувач на екрані телефону та ноутбука.
Backend — серверна частина продукту, тобто робота з базою даних та API (метод, щоб програми спілкувалися між собою). Цю частину користувач не бачить, із нею працюють програмісти.
Іноді поділу немає, і всім займається одна й та сама людина. У нашому випадку Джек відповідає за клієнтську частину, а Ганна — за серверну.
Зазвичай, у команді є тестувальники, які перевіряють код на помилки. Це може бути як мануальні тестувальники (перевіряють продукт на помилки вручну), і автоматизатори (пишуть автоматизовані тести). На даному етапі — вирішили, що самі перевірятимуть код, а тестувальника візьмуть пізніше.
Команда шукала дизайнера, який би займався відображенням екранів, кнопок і банерів (User Interface або UI), а також допомагав продакт-менеджеру з User Experience (UX) — проєктуванням того, як користувач взаємодіятиме з інтерфейсом.
У великих компаніях одним дизайнером не обійтись. Для цього можуть бути виділені окремі відділи UX, які займаються UX-дослідженнями користувачів. Але на цьому етапі команда не могла собі цього дозволити. У результаті Девід узяв одного дизайнера.
Залишалося знайти маркетолога та аналітика. Девід вирішив зробити це пізніше. Поки що нема чого просувати та аналізувати.
У вихідні невелика команда зібралася у Девіда. Дали продукту робочу назву Critically. Девід розповів про своє бачення продукту, далі команда перейшла до планування. Для цього було вибрано фреймворк OKR.
OKR має на увазі, що ви ставите одну амбітну ціль (Objective), до якої треба прийти. Потім прописуєте конкретні завдання (Key Results), які потрібно виконати задля досягнення цієї цілі.
За правилами Objective має бути настільки амбітною, щоб за максимальної продуктивності її можна було виконати лише на 70%. Якщо команда досягла цілі на 100%, то вона була надто дрібною. Якщо на 40% і нижче — значить, команда неправильно оцінила свої сили або погано працювала.
Команда вирішила, що зроблять перший реліз через 2 місяці. Досить амбітно.
4 тиждень
Команда активно працювала над продуктом вже чотири тижні. Девід зрозумів, що нічого не встигає. Він працював з ранку до вечора практично без вихідних, але постійно відкладав маркетинг потім. Настав час наймати маркетолога.
Девід опублікував пост із вакансією на Facebook, а його друзі зробили репости. Це допомогло швидко знайти відповідну людину. Такий спосіб розв'язання проблем за допомогою кола друзів та знайомих називається нетворкінг.
У команді з'явився амбітний маркетолог Майк. Як маркетолог він відповідає за просування продукту та залучення користувачів.
Першими завданнями Майка було провести аналіз конкурентів та аудиторії з погляду маркетингу, а далі разом із Девідом уточнити позиціонування та продумати, як його транслювати.
Залежно від продукту та аудиторії, можна використовувати різні канали просування, наприклад:
Пошукова оптимізація (SEO — Search Engine Optimization) — просування сайту через пошукову систему. Завдання — виходити на перші позиції за популярними запитами. Це допомагає залучити лояльнішу органіку (користувачів, які самі прийшли в продукт).
Закупка платного трафіку — залучення користувачів за допомогою контекстної реклами у пошукових системах та таргетованої реклами у Facebook, Snapchat, TikTok та інших соціальних мережах.
Просування у соцмережах (SMM — Social Media Marketing) — залучення користувачів через акаунти в соцмережах. Публікація корисного та залучає контенту, який приваблює та обігріває користувачів.
Просування в магазинах додатків (ASO — App Store Optimization) — оптимізація сторінки програми в AppStore та Google Play, щоб підвищувати кількість завантажень.
Партнерський маркетинг — просування через партнерів. Блогери, ЗМІ та компанії пишуть хороші відгуки та отримують винагороду за звантаження чи покупки.
Майк розумів, що неможливо охопити одразу всі канали. Вирішили розпочати з ASO, SMM та платного трафіку.
8 тиждень
Наближався перший реліз продукту. Завдань ставало дедалі більше. Девід зрозумів, що в команду потрібен аналітик — людина, яка вивчатиме метрики, будуватиме воронки та стежитиме, до яких результатів призводять зміни у продукті.
У команді з'явився ще один учасник — аналітик Сара. Першим її завданням стало налаштування системи аналітики Amplitude. Через неї вся команда може будувати графіки та аналізувати метрики онлайн.
12 тиждень
Вийшов перший реліз продукту — у додатку з'явилися користувачі. Команда вирішила привернути увагу до продукту та розповісти про нього на ProductHunt.
Product Hunt є глобальною спільнотою, де публікуються нові продукти, і користувачі їх оцінюють. Продукт Critically був ще сирим, тому не набрав багато голосів. Натомість команда отримала фідбек (зворотний зв'язок) через те, що варто доопрацювати.
13 тиждень
Кількість користувачів зростала повільно, Девід задумався про те, щоб зробити півот (зміна фокуса стартапу: критичного мислення на ментальну математику). З іншого боку, він розумів, що проблема може бути не в продукті, а в маркетингу. Майк не встигав працювати в усіх напрямках. Півот відклали й зосередилися на платному трафіку.
Для того аби залучити нових користувачів, команда вирішила запустити рекламну кампанію. Майк із дизайнером підготували рекламні банери (креативи) та запустили рекламу у тестовому режимі.
Сара переглянула результати й зрозуміла, що щось іде не так. Конверсія (відношення числа користувачів, які здійснили цільову дію, до загального числа користувачів) у встановлення дуже низька порівняно з бенчмарком (середній показник ринку).
Команда обрала найефективніші креативи, доопрацювала їх та протестувала ще раз. Цього разу конверсія вийшла вищою. Рекламу вирішили масштабувати, тобто запустити на велику аудиторію.
26 тиждень
Кількість активних користувачів зростає, команда хоче розвивати продукт і розуміє, що їм потрібний зворотний зв'язок. Майк проводить кастдев (Customer Development) — глибинні інтерв'ю з користувачами, щоб з'ясувати їхні потреби та мотиви.
Майк виявив потребу аудиторії — користувачі хочуть не тільки мати критичне мислення, а й бути креативними. Майк обговорив цю потребу з Девідом. Було вирішено додати у додаток вправи з розвитку креативності.
Девід разом з дизайнером продумали, як нова фіча виглядатиме у додатку. Вправи будуть в одному розділі, але у них будуть різні кольори. Девід склав документацію (документ із докладною інформацією щодо продукту або за змінами, що вносяться до нього) і віддав її розробникам.
Коли була готова фіча, Девід провів usability тестування — тестування зручності інтерфейсу продукту. Користувачі використовували продукт і відразу коментували свої дії. Девід стежив за їхньою реакцією: де користувачам було все зрозуміло, а де з'являлися труднощі.
Користувачі стали гірше орієнтуватися у продукті, комусь нова фіча взагалі лише заважала. Тоді Девід вирішив розділити продукт на два розділи: за креативністю та за критичним мисленням. Дизайнер зробив макети (прототип програми у Figma), Девід знову підготував документацію, потім фічу розробили та протестували. Рішення масштабували на всіх користувачів.
33 тиждень
Девід пішов на мітап (зустріч фахівців однієї сфери для обговорення питань у неформальній обстановці) по UX. Під час кави-брейку він розповів кільком учасникам про Critically. У результаті вони завантажили додаток.
Через пару днів один із учасників написав про Critically у своєму блозі. Кількість користувачів почала зростати швидше.
Тоді Девід вирішив написати кілька out-reach імейлів (холодний лист із якимось проханням) лідерам думок (авторитетні експерти в індустрії), щоб отримати нові публікації про Critically. За кілька тижнів з'явилося ще кілька оглядів продукту.
48 тиждень
Додаток отримав фічеринг у App Store (потрапив у добірку від редакції). Команда була дуже рада, але ще не розуміла, чим це обернеться.
Через кілька днів у програми почалися проблеми з Retention — відсотком користувачів, що повертаються в продукт. Потім в App Store надійшло багато відгуків про те, що після реєстрації програма вилітає.
Додатком почало користуватися дуже багато людей відразу, і сервер не витримав таке навантаження. Команда додала додатковий сервер, проблему було вирішено.
60 тиждень
Справи у Critically йдуть чудово. Девід почав шукати інвесторів для залучення фінансування. У продукті вже з'явився розділ з вироблення звичок. Також з'явилися досягнення та можливість розвивати навички разом із друзями.
Команда вирішила розширюватися на B2B (продаж бізнесу) — створити продукт, який допоможе розвивати soft skills (універсальні навички) усередині команди. Це могло стати альтернативою тренінгам, яких замало для розвитку навичок.
Для розробки продукту була потрібна ще одна продуктова команда. Поточна команда займалася доробкою та підтримкою основного продукту. Вона не мала часу на це завдання.
У Девіда на прикметі був знайомий продакт (скорочено від продакт-менеджер), якому могло б бути цікаво зайнятися новим продуктом у Critically. Це була Кейт із мітапу по UX, на який ходив Девід кілька місяців тому. Кейт зібрала команду та почала працювати над продуктом.
100 тиждень
Запустили продукт B2B. У штаті тепер є кілька людей, які відповідають за продаж B2B. Вони знаходять корпоративних клієнтів та обробляють ліди (потенційні клієнти, які виявляють інтерес до продукту та залишили контакти).120 тиждень
B2B продукт Critically має попит, проте йому не вистачає гнучкості. HR-відділи компаній хочуть мати можливість створювати власне навчання у додатку. Вирішили розробити no-code конструктор, який дозволить B2B-клієнтам самостійно створювати розділи у додатку.
No-code інструменти дозволяють створювати програми без навичок програмування. Наприклад, конструктор сайтів Tilda є no-code інструментом. Користувач може створити сайт, не вдаючись до написання коду.
130 тиждень
Команда Critically зростає. У компанії матрична структура, тобто співробітники визначаються своїм становищем у матриці, де на одній осі — функція (дизайн, маркетинг, розробка, тестування, аналітика, продаж), а на іншій — продукт (B2C, B2B). У кожного два керівники — функціональний та продуктовий.
У такій структурі функціональний керівник відповідає за якість виконаних робіт його підрозділом, а керівник проєкту — за проєкт від початку до кінця.
У компанії почалися проблеми з комунікаціями: рішення ухвалювалися надто довго, розробка йшла повільно, менеджерам було важко відстежувати роботу співробітників.
Девід почав думати про запровадження Agile. Це ціла культура розробки, зі своїми цінностями та принципами. Agile будується на швидкій перевірці гіпотез, частому постачанні продукту, прозорості, постійному поліпшенні продукту та процесів.
На основі Agile побудовані методології Scrum та Kanban.
У Kanban бізнес-процес ділиться на стадії виконання конкретних завдань: «Планується», «Розробляється», «Тестується», «Завершено» та ін. Для візуалізації команди використовують фізичні дошки або інструменти типу Trello і JIRA.
Головний показник ефективності — середній час проходження завдання на дошці. Якщо завдання пройшло швидко, то команда працювала продуктивно. Якщо завдання затяглося, треба з'ясовувати, якому етапі й чому виникли затримки, як оптимізувати роботу.
Scrum ділить робочий процес на рівні спринти — періоди від тижня до місяця. Над кожним проєктом працює окрема крос-функціональна команда. Це означає, що команда працює незалежно від інших команд. У таких командах збираються спеціалісти різних функцій.
Scrum має на увазі нові ролі: власник продукту та scrum-майстер.
Роль власника продукту схожа з посадою продакт-менеджера. Власник більше працює з командою, щоб усі процеси працювали. А продакт-менеджер найбільше відповідає за досягнення завдань бізнесу. Іноді ці ролі поєднуються, іноді обов'язки розподіляються по-іншому.
Scrum-майстер допомагає власнику продукту організувати бізнес-процес: проводить загальні збори, мотивує команду та стежить за дотриманням scrum-підходу.
Протягом спринту у кожної команди відбуваються регулярні заходи (ритуали).
Перед кожним спринтом йде планування — зустріч, де обговорюють цілі й завдання спринту. З беклогу продукту (список завдань продукту) власник продукту і команда відбирають завдання беклог спринту (список завдань спринт).
Наприкінці спринту проходить рев’ю та ретроспектива. На рев’ю учасники обговорюють результати спринту. На ретроспективі учасники обговорюють, як взаємодіяли між собою та складають план щодо покращення роботи.
На початку кожного робочого дня всі збираються на daily stand up, що триває не більше 10-15 хвилин. Учасники команди розповідають, що вони робили вчора, чим планують зайнятися сьогодні та обговорюють проблеми.
Девід думав про впровадження Scrum та вирішив обговорити це з експертом. Виявилося, що Scrum добре працює у маленьких компаніях, а для Critically більше підійдуть LeSS (Large Scale Scrum) та SAFe (Scaled Agile Framework) — фреймворки, які дозволяють використовувати Agile на великій кількості людей. Там є додаткові ролі та ритуали, які допомагають командам синхронізуватись. Вибрали SAFe.
Так, у компанії з'явилася посада DevOps-інженера (DevOps — скорочення від Development Operations) — людини, яка синхронізує всі етапи створення продукту, впроваджуючи додаткові програмні інструменти.
155 тиждень
SAFe прижився у компанії. Проблеми з комунікацією вирішилися. Це добре вплинуло на метрики, що було важливо, тому що Critically готувалися до одержання Seed round (ранній етап залучення інвестицій).
180 тиждень
Critically не змогли підняти Seed, проте пройшли в акселератор (програма для стартапів, яка дає знання, доступ до експертів та інвесторів), який допоміг їм масштабувати бізнес на інші ринки.Висновок
Через цю історію ми дали загальне уявлення, як працюють компанії в IT. У кожній команді будуть свої особливості, але для стартапу вам вистачить цієї інформації.
Далі ми відповімо на часті питання щодо IT, які виникають у новачків. Попрацюємо руйнівниками легенд.
Ми помітили, що про ІТ склалося багато міфів. Хтось думає, що можна одразу заробляти по $2000, хтось вважає, що до IT можуть потрапити лише чоловіки, хтось думає, що стартап — це щось нереальне. Тому ми зібрали 8 популярних питань і дали на кожне зрозумілу відповідь.
Працювати на віддаленні краще, ніж у офісі?
Залежить від компанії, від ваших особистих якостей та можливості організувати робоче місце. Розглянемо ці чинники докладніше.
Компанія. Підходи до контролю робочого часу у різних компаніях відрізняються. У деяких компаніях дистанційка означає, що ви можете працювати в будь-який час, головне здати все вчасно. За вами не здійснюється додатковий контроль. У деяких компаніях потрібно бути на зв'язку у робочий час. А в деяких — за вашим екраном стежитиме програма, і якщо ви відволіклися, то можуть бути проблеми з менеджментом. Мало кому сподобається пильний контроль за кожною дією.
Ваші особисті риси. Здатність до самодисципліни у різних людей відрізняється. Якщо вам потрібен контроль, щоб працювати продуктивно, то, можливо, робота на віддаленні вам не підійде. Якщо ви можете себе самоорганізувати, то вдома працюватиме навіть простіше — не відволікатимуть розмови інших людей.
Також у людей відрізняються потреби у спілкуванні. Якщо вам потрібно перебувати в оточенні людей, то робота на віддаленні може бути не найкращим варіантом. На віддаленні є зідзвони, але це не замінить ланч із колегами та розмови за чашкою кави у перерву.
Можливість організувати робоче місце. Базові складові робочого місця — це підключення до інтернету, хороше крісло і відсутність факторів, що відволікають. Чимось можна пожертвувати, але якщо з вами мешкає троє дітей, то працювати з дому швидше за все буде проблематично.
Хтось ходить працювати з кафе, але такий варіант працює, коли компанія не контролює співробітника протягом дня — до кафе потрібно дійти, на якийсь час може припинятися з'єднання з інтернетом, може заважати шум.
Ми у skillsetter працюємо повністю віддалено. Нам добре.
Чи важко жінкам потрапити до ІТ?
Складність потрапляння до професії не залежить від вашого гендера. Деяка упередженість до жінок поки що залишається, але компанії працюють над гендерним балансом. Для цього організуються спеціальні програми та воркшопи.
Не думайте, що якщо ви жінка, то не зможете стати продактом чи розробником. Це не так.
В IT можна потрапити лише «через знайомство»?
Від рівня команди залежить бізнес. Тому компаніям невигідно брати на роботу брата дружини лише тому, що це брат дружини.
Люди потрапляють в IT-компанії, тому що вони круті фахівці — мають правильний майндсет (спосіб мислення), релевантний досвід і реальні навички.
Але якщо ваші колеги та друзі прямо порадять вас менеджерам, то це чудово. Так працює нетворкінг, це нормально. У будь-якому випадку, відповідність рекомендаціям перевірятимуть на співбесіді та тестовому завданні.
Тому знаходите нові зв'язки: відвідуйте заходи, спілкуйтеся в чатах, пишіть коментарі на теми, що цікавлять.
Чи можна в ІТ без програмування?
Якщо ви хочете стати розробником, то без програмування це не вийде. З іншого боку, сфера ІТ не обмежується розробкою.
Маркетологам та дизайнерам програмування не потрібне взагалі. Аналітикам потрібні базові навички роботи з SQL та Python для обробки даних. Продакт-менеджерам треба вміти взаємодіяти із розробниками.
Докладніше про те, що потрібно знати в технічній сфері менеджерам продуктів, розповіли у статті «Чи повинен продакт-менеджер вміти програмувати».
Чи можна в IT одразу заробляти $2000?
Якщо на якихось курсах вам одразу обіцяють щомісячний прибуток $2000, то, швидше за все, вас обманюють. Не варто одразу розраховувати на таку винагороду. До нього можна прийти, коли ви вже накопичите досвід та експертизу. Новачки ж отримують менше.
Рекомендуємо зробити фокус не на зарплату, а на можливість здобути досвід і нетворк. Це допоможе швидше просуватися кар'єрними сходами й в результаті підвищувати винагороду.
Чи можна зробити свій стартап?
Так можна. Але не думайте, що стартап це легкий спосіб отримати гроші. Ви повинні бути готові, що роботи та відповідальності буде кратно більше, а результат прийде за кілька років або взагалі не прийде.
Вам потрібно вигадати продукт, який потрібен користувачам, тобто закриває якусь їхню потребу. Потім зібрати команду та створити MVP. А далі тестувати та розвивати продукт.
Для цього необов'язково потрібні мільйони. MVP можна зробити з невеликими витратами, щоби протестувати цінність. І якщо MVP спрацював, то можна шукати інвестиції під проєкт.
Пам'ятайте, що не завжди стартап це технологічно складні продукти. Наприклад, додаток для медитації з технічного боку нескладний продукт, але там може бути складність щодо контенту.
Чи можна виїхати до Кремнієвої долини?
Так можна. Але є складність із документами. Легально ви не можете просто зібрати речі, поїхати туристичною візою до США і почати там шукати роботу.
Вам потрібна робоча віза, а для цього потрібна компанія, яка готова прийняти вас на роботу. Якщо ви тільки починаєте свій шлях, то компанії не буде сенсу перевозити вас до США. Спочатку потрібно здобути досвід.
Якщо ви вже маєте досвід, тоді потрібно знайти потенційні компанії для роботи й подати туди заявки. Будьте готові, що в кожній компанії вас будуть запитувати, чи маєте ви право працювати в США і чи потрібне вам спонсорство на візу. Якщо ви одразу почнете оформляти візу на етапі пошуку роботи, це прискорить процес.
Куди можна піти працювати в ІТ?
Все залежить від ваших цілей. Ви можете піти працювати в агентство, продуктову компанію або фріланс. Розглянемо докладніше кожен варіант.
Агентства — компанії, які розробляють продукти на замовлення. У таких компаніях найчастіше працюють фахівці з країн СНД, Польщі та Індії через низьку вартість години роботи. Агентства отримують гроші коштом того, що купують ваші робочі години дешево, а продають їх дорого. Їм не дуже важливо навчити вас чогось, але там ви можете спробувати себе в різних проєктах та повчитися на своїх помилках.
Продуктові компанії — компанії, які роблять свої IT-продукти. Усього можна виділити 3 типи: стартапи, корпорації та скейлапи.
Стартапи. Це невеликі компанії, які виробляють новий продукт. Стартапом може бути невелика команда із 10-100 осіб. З плюсів — ви спробуєте себе в різних напрямках, буде цікаво і швидше доростете до наступного рівня. З мінусів доведеться переробляти, при цьому винагорода буде не дуже висока.
Скейлапи. Це компанії, які зараз переживають етап стрімкого зростання. Наприклад, Airbnb, Uber, Tinder. Із плюсів — винагорода на рівні корпорації, гнучкість та можливості для зростання. З мінусів — не всі процеси збудовані, можливе перепрацювання.
Корпорації. Великі компанії, які вже мають стійке місце над ринком. Наприклад, Google та Apple. У таких компаніях вже налагоджено процеси. З плюсів — навчання, соцпакет та work-life balance. З мінусів — повільне кар'єрне зростання та обмежена зона відповідальності.
Фріланс — вільна робота. Ви можете знаходити замовлення через фріланс-бази, свій блог, соцмережі. Поріг входу низький, але спочатку ви братимете маленькі проєкти й отримуватимете за них менше грошей. Згодом ви накопичите досвід та базу клієнтів.
Якщо ви займаєтеся нетворкінгом і вибудовуєте стосунки із замовниками, то поступово у вас з'являється більше рекомендацій та корисних зв'язків, а отже, роботодавців, які бажають вас найняти у штат.
З плюсів — свобода, нетворк, можна піти в оренду. З мінусів — потрібно постійно спілкуватися з новими клієнтами, немає соцпакета.
Але не думайте, що на фрілансі достатньо працювати чотири години на тиждень, сидячи на Балі. Таке трапляється, але рідко.
Підсумуємо
Робота в IT — це цікаво та перспективно. Але якщо ви вирішили, що вам потрібно в IT, будьте готові попрацювати, оскільки конкуренція висока.
Не вірте в міфи про зарплату $2000 через місяць після курсів та роботу по чотири години на тиждень. Багато речей реальні, але щоб їх отримати, потрібно спочатку докласти зусиль.
Ми допоможемо вам пройти цей шлях. Після навчання на наших курсах у вас будуть реальні навички та кейси у портфоліо. Цього достатньо, щоб знайти свою першу роботу в ІТ.
