Що робити, якщо не беруть до ІТ без технічних знань?

20 January 2021

  • Автор: Уля Днипрова

  • Складність: норм

  • Час: 8 хв

Щоб якісно керувати IT-проєктом однієї управлінської експертизи буде недостатньо. Знадобиться ще й розуміння процесу розробки програмного забезпечення.

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

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

Денис в IT вже 8 років, із них 5 років у ролі менеджера віддалених команд. Наталія керує проєктами в мобільній розробці. За час роботи обидва експерти провели не одну співбесіду і склали власний список, що очікують в IT-компанії від кандидатів на управлінську посаду.

Зібрали поради Дениса й Наталії в одну статтю, щоб можна було одразу проаналізувати, яких знань не вистачає та скласти «роадмеп» щодо розвитку потрібних скілів.

Чому в пріоритеті люди з технічними навичками

Що робити, якщо не беруть до ІТ без технічних знань? 1

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

Наталія Білоусова:

Якось я шукала собі помічника РМ-а. Один кандидат — менеджер із туристичної сфери, дуже підходив за софтскілами.

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

У підсумку, я зрозуміла, що підготовка до роботи «неайтішного» фахівця буде надто трудомісткою, тому зосередилася на кандидатах, у яких крім софтскілів, був ще й досвід в IT.

Які труднощі виникають у РМ-а під час переходу з «неайтішної» області в «айтішну»:

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

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

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

Що вивчати, якщо хочете підтягнути знання самостійно

Що робити, якщо не беруть до ІТ без технічних знань? 2

Не потрібно, щоб РМ детально розбирався в розробці, важливо щоб спеціаліст мав загальне уявлення, як виробляють програмні продукти.

Життєвий цикл ПЗ

Програмні продукти — це не про те, що програміст сів, щось написав — і на цьому все. Існують певні етапи розробки, а Рroject Manager в IT знає ці етапи, розуміє їх особливості й те, які люди потрібні на кожній стадії:

  • Формування вимог до ПЗ. Відповідальність РМ-а — забезпечити якісне планування функціональності й аналіз вимог.
  • Проєктування рішення. На цьому етапі вибудовується зрозумілий інтерфейс і візуальне уявлення продукту. Будується також архітектура рішення.
  • Реалізація та тестування. Потрібно розуміти, що розробка й подальше тестування з виправленням помилок – це нормальний процес. Часто доводиться пояснювати клієнтам, далеким від IT, як роблять програмні продукти й чому баги, наприклад, це норма.
  • Введення в дію (використання) і що відбувається після нього.
  • Експлуатація та супровід (техпідтримка). Чому ми не можемо просто залишити продукт після впровадження, що таке гарантійне обслуговування, технічна підтримка і т.д.

Моделі й методології

Щоб зрозуміти цю тему загалом, достатньо прочитати кілька статей. Мета — сформувати сукупність понять, які мають бути у людини, яка входить в ІТ-компанію.

Потрібно знати найпоширеніші моделі: каскадна (Waterfall), ітераційна, інкрементна модель. Де у всьому цьому місце для Agile та що таке Kanban. Важливо зрозуміти переваги й недоліки кожного підходу, щоб правильно вибрати модель для керування продуктом.

Термінологія

Потрібно розуміти базові речі, щоб відповісти на загальні технічні питання:

  • Що таке архітектура?
  • Що таке бекенд та фронтенд?
  • Як взаємодіють платформи?
  • Що таке бази даних, таблиці та зв’язку, первинний ключ?
  • Що таке DNS, load balancer, реплікація?
  • Клієнт-сервер: товстий і тонкий клієнт, що це?
  • Чим відрізняється клієнт-сервер на web і mobile?
  • Що таке REST?
  • Яка логіка має бути на фронтенді, а яка на бекенді.
  • Безпека, як її забезпечити.

Денис Шаматажі

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

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

Технічна документація

Менеджер не прописує зовсім технічних речей, таких як code style або опис архітектури. Але точно доведеться вивчити, що таке технічне завдання та як його поставити.

Щоб ставити задачі команді, РМ-у потрібно самому розібратися в поняттях:

  • Опис API: розуміти, де які API використовуються, коли потрібно вносити зміни, а коли ні. Це потрібно, щоб оновлення різних частин системи не ламали функціональність, що працює. Дуже часто на аутсорсі буває, що mobile робить одна компанія, а бекенд — інша, й в такій ситуації РМ-у треба трохи уважніше стежити за тим, що відбувається «під капотом».
  • Опис архітектури. В аутсорсі досить часто буває, що клієнт просить описати для зовнішнього замовника або для інтеграції із зовнішньою системою роботу якогось модуля. І тут РМ повинен розуміти, що мав на увазі розробник в описі, щоб телефонуючи замовнику або з кимусь із зовнішніх підрядників, зуміти відповісти на питання, що випливають.
  • Test case, bug report, use case, user story – що це і для чого потрібно.

Якщо хочете отримати чекліст із загальними технічними питаннями для підготовки до співбесіди в IT-компанію, заповніть коротку форму.

Інструменти проєкту

У цьому блоці знань, головна мета – освоїти понятійний апарат і розуміти питання, які можуть поставити на співбесіді:

  • Які бувають task trackers та який краще?
  • Де й навіщо застосовують project planning? Як побудувати діаграму Ганта?
  • Де зберігати та змінювати вимоги?

Наталія Білоусова:

Практична порада: Виберіть пробний варіант одного з task-трекерів, наприклад, тієї ж Jira і спробуйте подивитися, поставити задачі. Коли на співбесіді вас запитають про досвід роботи з task-трекерами, зможете відповідати:

— Так, з Jira трошки працював, — і це буде додатковий плюс на вашу користь.

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

Тестування

Потрібно сформувати уявлення про типи тестування (функціональне, регресійне, навантажувальне), в якій послідовності проводять, коли вони потрібні:

  • Внутрішнє та зовнішнє тестування.
  • Як відрізнити баг від change request.
  • Артефакти тестувальників: test cases, ПМВ (програма й методика випробувань).
  • Серйозність (severity) та пріоритет (priority) бага/дефекту.
  • В який момент потрібно зупинитись у тестуванні?
  • Чи можна здати проєкт за наявності багів, якого порядку можуть бути ці баги й в якій кількості?

Коли вирішили, ЩО вивчати, визначимо, ДЕ брати потрібну інформацію. Поговоримо про теоретичні знання та практичні вміння.

Де шукати відповіді

Що робити, якщо не беруть до ІТ без технічних знань? 3

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

Денис Шаматажі

Зараз я працюю «мобільним» РМ-ом, тому так чи інакше проєктував мобільний дизайн, постійно читаю про мобільні платформи й можу сам написати простенький додаток.

Теоретичні знання

Наталія Білоусова:

Якби до мене прийшов друг і запитав: «Наташа, хочу в IT, що робити?» — я порадила б фундаментальний курс на Coursera або базовий TechMind, а можна взагалі піти на другу вищу. Все залежить від тривалості навчання та цілей людини, наскільки глибоко вона хоче зануритися в технічну частину.

Денис Шаматажі:

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

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

Хороше джерело знань – взаємодія зі спеціалістом. Спілкування може бути зовсім неформальним: просто якийсь знайомий, якого можна розпитувати.

Інший варіант — знайти більш досвідченого РМ-а або ментора й попросити підкинути актуального контенту або допомогти розібратися в технічному питанні.

Techmind Говори з розробниками однією мовою!

Теорію можна вивчати самостійно: читати новини, статті, стежити за подіями, підписатися на IT-спільноти. Це дуже важливо.

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

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

Де брати інформацію:

  • The Verge, Wired — технічні новини англійською.
  • TechCrunch, MacRumors – для тих, кого цікавить тема стартапів.
  • Producthunt, KickStarter, IndieGoGo – приклади нових продуктів.

Наталія Білоусова:

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

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

Все, що потрібно в роботі, черпаю точково, за потреби. Наприклад, зіткнулася з продуктовою аналітикою – пішла про неї почитала. Не розібралася — пішла запитала друга спеціаліста, що він порадить почитати, що реально працює.

Денис Шаматажі

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

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

Практичні вміння

Якщо говорити про отримання практичних знань, то скільки книг і сайтів ви не вивчили б, поки не зробите щось своїми руками, зрозуміти IT-сферу не вийде. Спробуйте створити щось вручну, щоб побачити як це працює: наприклад, сайт на wordpress або мінімальний додаток, а-ля «Hello, Word». Коли спробуєте втілити теорію в реальність, знання перетворяться на практичну навичку.

Це буде схоже на якісь лабораторні роботи по програмуванню. Такі «лабораторки» можна робити самостійно або піти на курс, де вас проведуть за руку, скажуть, що робити, перевірять, розберуть помилки.

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

Денис Шаматажі:

Є дійсно багато професій, з яких можна заходити в ІТ, навіть без досвіду. Деякі мої друзі стали продактами з customer support, тому що ця позиція прокачує два важливі скіли:

  • Розуміння продукту, потреб і болів клієнтів.
  • Розуміння технічних деталей, необхідних для формулювання відповіді.

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

Наталія: Білоусова:

Support або QA – вигідні позиції, щоб потрапити до IT-сфери й отримати технічний досвід. QA ростуть дуже швидко, це гарний спосіб прокачатися. Навіть студент вже може прийти стажером у компанію та почати набувати досвіду.

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

Скласти план розвитку технічних скілів – лише початок шляху. Тому коли роадмеп готовий — починайте діяти.

Якщо у вашому плані є пункт: отримати технічні навички з погляду менеджменту, приходьте на TechMind.

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

Уля Днипрова

Уля — копірайтер IAMPM. Завжди готова допомогти молодим авторам порадою і просто любить говорити про маркетинг, тексти і сенси. Найкраще ставиться до контентників, які уважно читали «Пиши-скорочуй» та розсилку Максима Ілляхова.