Freshcode Training Center

Перевір свої знання або інтуїцію 😉 #fresh_tests

Чистий аркуш дивиться на тебе, а ти — на нього… І не знаєш, із чого почати 😅 Розказуємо, чому так відбувається і як припинити панікувати 👆 Чому нас лякає «чистий аркуш» 🔹 Немає чіткої точки старту 🔹 Є страх зробити неправильно 🔹 Хочеться, щоб одразу вийшло добре і «як треба» 🔹 Задача виглядає занадто великою 🔹 Зʼявляється думка: «Може, я ще не готовий» Насправді страх «чистого аркуша» зазвичай не у відсутності знань чи досвіду, а у тиску, який ми самі на себе створюємо. Хочеться одразу зробити гарно і правильно. Й обовʼязково, щоб перша версія була ідеальною 😌 Читай далі, щоб дізнатися, як позбавитися страху «чистого аркуша» 👇 Почати з мінімального Не «зробити проєкт», а просто відкрити файл і щось у ньому написати. Що саме — не має значення. Перший крок потрібен, щоби зняти напругу початку 👌 Дозволити собі неідеальний старт Перша версія — це не результат. Це чернетка, від якої ти потім відштовхнешся 👆 Розбити задачу на частини Велике завжди лякає більше. Тож варто його розбити на маленькі, але конкретні кроки 🤓 Не «зробити все одразу», а: • зрозуміти, що саме треба; • скласти план; • почати з найпростішого. Не чекати впевненості Вона майже ніколи не приходить «до». Зазвичай впевненість зʼявляється вже в процесі 😌 Дати собі час увійти в роботу Перші 10–20 хвилин можуть бути найважчими. Потім стає легше, бо зʼявляється розуміння, що робити далі 💫 «Чистий аркуш» лякає, бо в ньому немає опори. Але щойно з’являється перший рядок, перший список, перша думка, зʼявляється і точка, від якої можна рухатись. Далі вже простіше — щось додати, щось змінити, щось переписати. Тож наступного разу, коли зловиш себе на ступорі перед новою задачею, не намагайся одразу видати ідеальний результат. Спробуй просто почати 👆 Було корисно? Залишай реакцію цьому допису 😉 #fresh_advice

Це база, без якої не обійтись у роботі. І саме цю базу ми даємо на курсі із проєктного менеджменту 😎

Випробуємо твої знання з проєктного менеджменту? 😉 #fresh_tests

Технічні навички відкривають двері, але саме софт-скіли допомагають у них увійти 🚪Можна бути генієм коду, але офер отримає той, із ким команді буде комфортно. Рекрутер шукає не просто «руки», а людину, яка зможе нормально пояснити свою думку та не посиплеться від критики. Далі розібрали, як пройти цю перевірку 👆 ⠀ Що таке soft-interview Soft-interview — це розмова про твоє мислення, поведінку та взаємодію з іншими людьми. На цьому етапі важливо не те, що ти знаєш, а те, як ти думаєш і реагуєш 👆 Що насправді перевіряють на soft-interview 🔹 Комунікацію Як ти формулюєш думки, чи вмієш пояснювати, ставити питання, слухати співрозмовника. 🔹 Мислення і логіку Як ти підходиш до задач, приймаєш рішення, реагуєш на нову інформацію. 🔹 Адекватність і командність Як ти працюєш у команді, що робиш у конфліктних ситуаціях, як сприймаєш фідбек. 🔹 Мотивацію Чому ти обрав ІТ, цю роль і компанію. 🔹 Зрілість Як ти говориш про помилки, невдачі, попередній досвід і зони росту. Які питання ти можеш почути на soft-interview — Розкажи про складну ситуацію, із якою зіткнувся. — Що робиш, коли не згоден із рішенням команди? — Як реагуєш на критику? — Що для тебе хороший результат? Не існує «правильних» відповідей на ці питання. Важливо показати логіку, мислення та щирість 😌 Чого варто уникати на soft-interview 🚩 Намагатися здаватися ідеальним 🚩 Відповідати загальними фразами 🚩 Мовчати або губитися 🚩 Боятися сказати «я не знаю» чи визнавати помилки Що важливо пам’ятати перед soft-interview 👆 Це діалог, а не іспит 👆 Можна ставити уточнювальні питання 👆 Можна думати перед відповіддю 👆 Важливо бути чесним, а не «ідеальним» Було корисно? Залишай реакцію цьому допису 😉 #fresh_career

Перевір свої знання або інтуїцію #fresh_tests

Терміни, які ми використовували у цьому дописі 👇 Блокер — певний фактор, що блокує прогрес задачі. API — посередник, що дозволяє різним програмам обмінюватися даними між собою. Фіча — англіцизм або сленговий термін, перекладається як «функція». Спринт — певний проміжок часу, за який розробляється функціонал системи. Воркшоп — один із видів збору вимог та методів проведення зустрічі, де всі учасники мітингу не тільки слухають, а й взаємодіють. Користувацький шлях — карта шляху клієнта, яка відображає взаємодію користувача із застосунком. User stories — короткий опис функції з точки зору користувача. Acceptance criteria — чіткий і перевірюваний набір вимог, за допомогою якого визначають, чи є функціонал готовим та прийнятним для користувача. Capacity — максимальний обсяг роботи, який команда може виконати за період часу. Story point — відносна оцінка обсягу та складності задачі. Таска — англіцизм або сленговий термін, перекладається як «задача». Реліз — процес випуску нової версії програмного забезпечення. Roadmap — стратегічний план розвитку продукту, який відображає ключові етапи, цілі та часові межі реалізації функцій проєкту. #fresh_knowledge

Уяви звичайний робочий ранок Марини. Ще нещодавно вона працювала адміністраторкою торговельної точки, а сьогодні — проєктна менеджерка в IT 👩‍💻 Нові задачі, інша відповідальність і ритм. ⠀ На прикладі її робочого дня ми розберемо, чим займається проєктний менеджер і в чому суть цієї професії. А всі професійні терміни, що траплятимуться у процесі, пояснимо у кінці 👆 ⠀ Читай далі, щоби прожити цей день разом із Мариною та краще зрозуміти професію ПМ 🤓 ⠀ Ранок. О 08:55 Марина робить каву, відкриває ноутбук і швидко переглядає Slack та Jira: що змінилося за ніч, які нові повідомлення з'явилися, чи виникли критичні задачі. О 09:30 — щоденний стендап на 15 хвилин. Розробники кажуть, що зробили, чим займаються і які блокери. Тестувальник розповідає, які баги виявив, та запитує, що і як має працювати. Бізнес-аналітик розказує про свої апдейти або просто слухає команду, щоби бути в контексті. Один із розробників зазначає, що потрібен доступ до API (див. словник у кінці 👆). Марина одразу записує це у свій список задач. QA запитує, яка має бути поведінка таблиці клієнтів, якщо інтеграція видає помилку. Відповість бізнес-аналітик, оскільки він прописував поведінку системи у різних ситуаціях. Після стендапу — перші дзвінки. Клієнт телефонує з проханням додати ще одну фічу у поточний спринт. Тут починається важлива частина роботи ПМ — управління очікуваннями. Марина пояснює, що додавання вимоги означає 2 варіанти: або прибрати іншу задачу з поточного спринту, або продовжити терміни. Вона фіксує домовленість у Confluence і просить бізнес‑аналітика підготувати оцінку впливу та, за можливості, чернетки вимог. Це — типовий приклад компромісу. ПМ не каже «ні» автоматично, але конвертує прохання у конкретні наслідки й рішення. Опівдні — планування з аналітичним акцентом. Разом із бізнес-аналітиком і розробниками Марина запускає воркшоп у Miro. Вони збирають користувацький шлях, виділяють ключові сценарії і позначають залежності між фічами. На дошці зʼявляються sticky notes із user stories та потоками даних. Марина веде сесію: ставить питання, щоб виявити невизначеності, і просить бізнес-аналітика конкретизувати acceptance criteria безпосередньо на дошці. Після узгодження вони переносять підсумкові user stories до Trello — створюють картки, призначають відповідальних, додають чеклісти й орієнтовні оцінки. Для аналітики Марина швидко робить просту оцінку capacity у Google Sheets: скільки story points команда може взяти на спринт, які буфери на ризики. Вона експортує ключові таски з Trello у Jira (або залишає у Trello для менш формальних команд), щоб синхронізувати трекінг. Друга половина дня інколи непередбачувана. Сьогодні у середовищі системи після інтеграції зʼявився критичний баг — реліз функціоналу можуть відтермінувати. Марина швиденько збирає зустріч: розробники, тестувальник і бізнес-аналітик. Вони діагностують проблему — помилка у зовнішньому API. Марина разом із командою виносять рішення тимчасово відкатитися на попередню стабільну версію системи, повідомити про це клієнта та оновити плани. Також — оцінити з розробниками скільки часу піде на вирішення цього багу. Роль ПМ тут — зібрати команду, проаналізувати проблему, обговорити її, винести рішення та оновити оцінки. Під кінець дня Марина переглядає метрики: скільки задач у прогресі, скільки блокерів вирішено, на скільки стрічка виконання відповідає roadmap. Перед тим, як вимкнути ноут, записує собі пріоритети на завтра. Підсумуємо? 🔷 ПМ — це про координацію, комунікацію і прийняття рішень. Необовʼязково знати код, але треба розуміти процеси і вміти говорити із технарями. 🔷 Навички, які допомагають найшвидше: чітка комунікація, організація зустрічей, пріоритизація, уміння працювати з ризиками. 🔷 Інструменти: Trello/Jira для задач, Confluence/Docs для документації, Slack для комунікації, Miro для воркшопів, Google Meet/Zoom для зустрічей. 🔷 Роль часто потребує швидкої реакції на невизначеність, тому важлива стійкість і вміння структурувати інформацію. #fresh_knowledge