Як працюють продуктові команди та ще 8 популярних питань про 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 і платного трафіку.

Поринайте в роботу продуктових компаній з нашими курсами.
Якщо хочете навчитися запускати продукти від нуля до одиниці: починайте вчитися симуляторі продакт-менеджера.
Якщо хочете навчитися просувати продукти на закордонних ринках: спробуйте симулятор digital-маркетолога.

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 інструменти дозволяють створювати програми без навичок програмування. 

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, що виникають у новачків. Попрацюємо руйнівниками легенд.

Часті питання щодо роботи в IT

Ми помітили, що про ІТ склалося багато міфів. Хтось думає, що можна одразу заробляти по $2000, хтось вважає, що до IT можуть потрапити лише чоловіки, хтось думає, що стартап – це щось нереальне. Тому ми зібрали 8 популярних питань і дали на кожну зрозумілу відповідь.

Працювати на відстані краще, ніж в офісі?

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

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

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

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

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

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

Ми у skillsetter працюємо повністю віддалено. Нам добре.

Чи складно жінкам потрапити до ІТ?

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

Не думайте, що якщо ви жінка, то не зможете стати продактом чи розробником. Це не так.

В IT можна потрапити лише "за знайомством"?

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

Люди потрапляють в 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 через місяць після курсів та роботу по чотири години на тиждень. Багато речей реальні, але щоб їх отримати, потрібно спочатку докласти зусиль.

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

Почніть навчатись вже сьогодні.
Якщо хочете навчитися запускати продукти від нуля до одиниці: починайте вчитися симуляторі продакт-менеджера.
Якщо хочете навчитися просувати продукти на закордонних ринках: спробуйте симулятор digital-маркетолога.