У світі ІТ, де код — це закон, менеджери проєктів відіграють роль мосту між розробниками та рештою світу. Часто вони стикаються з викликами, які вимагають не просто знання Gantt-діаграм, а розуміння коду, який пишуть їхні команди та технічних процесів. Але що трапляється, коли технічні навички менеджера залишають бажати кращого? Представляємо 5 факапів, які можуть зруйнувати ІТ-проєкти у вигляді новел.
Новела перша: Втрачена у термінології
Аня – молода і амбітна проєктна менеджерка в невеликій IT-компанії, яка спеціалізується на розробці продуктів для зарубіжних ринків. Вона відома своєю здатністю координувати команди та підтримувати відмінні стосунки з клієнтами. Однак її відсутність технічних знань часто стає причиною непорозумінь.
У ході одного з проєктів, клієнт з Німеччини замовив розробку веб-застосунку, що має використовувати динамічні дані з їхньої CRM-системи. Команда розробників запропонувала використовувати JavaScript для реалізації потрібної функціональності, але Аня, плутаючи його з Java, наполягла на використанні останньої, вірячи, що це одне й те ж.
Розробники, хоч і здивовані вибором Ані, почали працювати з Java. Аня, чувши, що Java — потужна та надійна мова, вирішила, що вона ідеально підійде для проєкту, не усвідомлюючи, що Java значно повільніша для цілей веб-розробки порівняно з JavaScript, що призначений для клієнтської частини веб-застосунків.
Аня, Аня, що ж ти наробила…
Коли проєкт був майже завершений, стало зрозуміло, що продукт значно повільніший та менш відповідає вимогам клієнта, ніж очікувалося. Перевірка коду виявила, що основна проблема криється у використанні Java для фронтенду, що є нетиповим та неефективним рішенням.
Проєкт затримався на кілька місяців, а вартість його розробки значно зросла. Аня зіткнулася з серйозною критикою з боку керівництва і клієнта, що підірвало її репутацію і самовпевненість. Після цього інциденту вона зрозуміла, що без глибоких технічних знань неможливо ефективно управляти IT-проєктами.
Ця історія відображає, як відсутність розуміння базової технічної термінології може призвести до серйозних збитків і затримок у проєкті. Вона підкреслює важливість технічних знань для проектних менеджерів у сфері IT. А отримати їх можна на курсі Techmind, який розроблений саме для проєктних менеджерів, які працюють в IT.
💡 JavaScript – мова програмування, що використовується для створення інтерактивних ефектів усередині веб-браузерів, відома своєю швидкодією та гнучкістю. Java – мова програмування, призначена для роботи у багатьох платформах, від серверів до мобільних телефонів, зазвичай використовується для більш великомасштабних і тривалих проєктів.
Новела друга: Коли «хот фікс» стає «холодним душем»
Максим — досвідчений проєктний менеджер у великій IT-компанії, яка працює над розробкою корпоративних систем для міжнародних клієнтів. Він завжди прагне до швидкого вирішення проблем і вважає, що може швидко адаптуватися до будь-яких викликів. Однак його відносне нерозуміння глибинних технічних деталей іноді призводить до помилок.
Напередодні важливої демонстрації продукту для нового клієнта, Максим виявив незначну помилку в інтерфейсі, яка могла негативно вплинути на враження користувача. Щоб швидко виправити це, він запропонував розробникам зробити «хот фікс» без повного циклу тестування.
Команда розробників під тиском від Максима поспішно внесла зміни до коду. Максим вирішив проігнорувати звичний процес QA та затвердив випуск оновлення, вірячи, що ризик мінімальний і що все піде гладко.
Знав би ти, Максиме, де впадеш
Під час демонстрації, коли клієнт перевіряв функціональність продукту, відбувся серйозний збій. Оновлення, внесене як «хот фікс», спричинило непередбачені наслідки, в результаті чого важливі частини системи перестали функціонувати. Це викликало розчарування у клієнта і поставило під сумнів професіоналізм компанії.
Після цього інциденту Максим і його команда змушені були провести низку нарад для виправлення ситуації, що значно затягнуло проєкт і збільшило його вартість. Максим зрозумів, що намагання заощадити час, ігноруючи важливість процесу тестування та QA, може призвести до серйозних втрат.
Ця історія показує, наскільки важливо дотримуватись встановлених процедур та враховувати всі технічні аспекти перед внесенням «хот фіксів». Ризик здається невеликим лише на перший погляд, але його наслідки можуть бути дуже відчутними.
💡 Хот фікс (hot fix) — швидке внесення змін до живої версії продукту для виправлення критичних помилок, зазвичай минаючи стандартні процедури тестування та перевірки.
Новела третя: Ігнорування технічних боргів
Ірина — проєктна менеджерка з тривалим досвідом у міжнародній IT-компанії, що займається розробкою корпоративного софта. Вона зарекомендувала себе як компетентний керівник, але її слабке розуміння технічних деталей іноді призводить до невиправданих рішень.
Проєкт, який курирує Ірина, почав відставати від графіку через накопичені технічні борги, які не були вчасно вирішені. Незважаючи на попередження своїх розробників про необхідність рефакторингу коду, Ірина вирішила ігнорувати ці рекомендації, вважаючи, що важливіше утримувати короткі терміни випуску продукту.
Замість виправлення основних проблем існуючого коду, Ірина наполягала на додаванні нових функцій, сподіваючись задовольнити вимоги клієнта та покращити зовнішні показники проєкту. Це призвело до збільшення кількості непередбачених збоїв і зниження загальної продуктивності системи.
Борги треба сплачувати вчасно
У критичний момент, під час презентації продукту важливому клієнту, система вийшла з ладу, виявивши всі накопичені помилки та недоліки. Помилки в коді, які могли бути усунуті на ранніх етапах, спричинили серйозні збої, що негативно вплинуло на довіру клієнта до компанії.
Проект зазнав значних затримок, а компанія втратила потенційні доходи та довелося витрачати додаткові ресурси на невідкладне вирішення проблем. Ірина отримала серйозне зауваження від керівництва та зрозуміла значення належного управління технічними аспектами проєктів. А якби пройшла Techmind, знала би, як працювати з технічним боргом.
Ця історія ілюструє, як недооцінка технічних боргів може призвести до фатальних наслідків для проєкту та компанії в цілому. Важливо не лише дотримуватись графіків, а й уважно ставитись до технічної якості продукту.
💡 Технічний борг — це концепція в розробці програмного забезпечення, що вказує на відкладене вдосконалення коду, яке необхідно виконати. Ігнорування технічного боргу може призвести до складніших і дорожчих проблем у майбутньому.
Новела четверта: Оцінка часу та ресурсів: «Завжди занадто оптимістично»
Володимир — енергійний і оптимістичний проєктний менеджер у стартапі, який займається розробкою мобільних застосунків. Він відомий своєю здатністю швидко запускати проєкти та мотивувати свою команду, але його недостатнє розуміння технічних деталей часто призводить до нереалістичних планів.
Володимир взявся за амбітний проєкт розробки нової функціональності для мобільного застосунку, яка повинна була включати складну інтеграцію з зовнішніми API. Він встановив дуже агресивні терміни для завершення проєкту, базуючись лише на загальному огляді вимог та не врахувавши технічні складнощі, озвучені його командою розробників.
Під тиском встановлених термінів, команда почала працювати надійно, але зіткнулась з низкою технічних викликів, які не були враховані Володимиром. Виявилося, що деякі API, які мали інтегруватися, були застарілими або мали обмежені можливості, що істотно вплинуло на можливості реалізації проекту.
Володя, не чуди
По мірі наближення дедлайну стало очевидно, що проєкт не буде завершений вчасно. Коли Володимир представив проміжні результати інвесторам, вони були розчаровані відсутністю значної частини обіцяної функціональності.
Проєкт зазнав затримок, і додаткові ресурси були витрачені на перепланування та додаткову розробку. Володимир зіткнувся з критикою з боку команди та інвесторів, що підкреслило важливість точної оцінки і планування на початкових етапах проєкту. А якби він знав, як працювати з API, то не потрапив би у часову пастку.
Ця історія підкреслює, як важливо для проектних менеджерів мати реалістичне розуміння технічних вимог та потенційних викликів. Оптимізм є хорошою якістю, але він повинен бути збалансований з технічною обізнаністю та реалістичним плануванням.
💡 API (Application Programming Interface) — це набір правил і специфікацій, за якими різні програмні додатки можуть взаємодіяти один з одним. API дозволяє розробникам використовувати певні функції або дані інших програм або сервісів, спрощуючи створення і розширення функціональності своїх програм без необхідності розробки всього з нуля.
Новела п’ята – фінальна: «Невидимі зв’язки»
Тетяна — досвідчена проектна менеджерка в IT-компанії, що займається розробкою хмарних рішень. Вона звикла довіряти своїй інтуїції та досвіду, але іноді її небажання вдаватися в технічні деталі призводить до недорозумінь у команді.
Проєкт, який вела Тетяна, включав інтеграцію різних хмарних сервісів для створення єдиної платформи для аналізу даних. Тетяна вирішила пропустити декілька технічних зустрічей, вважаючи, що вони зайві, і сконцентрувала свої зусилля на управлінні графіком проєкту.
Відсутність Тетяни на ключових обговореннях призвела до того, що вона пропустила важливу інформацію про несумісність деяких сервісів, що мали інтегруватися. Це призвело до серйозних проблем з обміном даними між системами, які вже були частково інтегровані.
Що, важко на міт з’явитись?
Коли проєкт перейшов в тестову фазу, виявилося, що дані не можуть ефективно передаватися між різними модулями, що спричинило повний перегляд підходу до інтеграції. Це стало очевидним тільки тоді, коли клієнт почав тестування і зіткнувся з численними помилками в звітах.
Проєкт зазнав значних затримок, і Тетяна була змушена пояснити причину цих проблем. Компанія витратила значні ресурси на виправлення помилок, що не тільки збільшило витрати, але й підірвало довіру клієнта до компанії.
Ця історія підкреслює важливість участі проектного менеджера в технічних обговореннях, навіть якщо вони здаються рутинними або зайвими. Важливо забезпечити, що всі аспекти проєкту взаємодіють гармонійно, і невидимі зв’язки між компонентами не переростають у непередбачені проблеми.
Епілог
Всі ці історії, звичайно, вигадані. Або ні. Можливо, саме ви впізнали себе в них. Можливо, це наші студенти до навчання на Techmind, поділились своїм досвідом.. Не дозволяйте таким факапам стати частиною вашого ІТ-проєкту. Більше ніж 3200 випускників вже отримали Tech Skills на курсі TechMind і тепер використовують ці навички для управління ІТ-проєктами, розмовляючи однією мовою з розробниками. Запишіться на курс сьогодні та станьте менеджером, який веде проєкти до успіху, а не до фіаско.
