АНАЛІЗ ПЕРЕВАГ ВПРОВАДЖЕННЯ ГНУЧКОЇ МЕТОДОЛОГІЇ УПРАВЛІННЯ ПРОЄКТАМИ В НЕ-ТЕХНІЧНИХ ВІДДІЛАХ КОМПАНІЇ - Научное сообщество
Главная
UA RU EN

Вас приветствует Интернет конференция!

Приветствуйем на нашем сайте

Рік заснування видання - 2011

АНАЛІЗ ПЕРЕВАГ ВПРОВАДЖЕННЯ ГНУЧКОЇ МЕТОДОЛОГІЇ УПРАВЛІННЯ ПРОЄКТАМИ В НЕ-ТЕХНІЧНИХ ВІДДІЛАХ КОМПАНІЇ

12.06.2024 18:21

[2. Экономические науки]

Автор: Кукуяшний Ярослав Андрійович, магістрант, Національний технічний університет України «Київський політехнічний інститут імені Ігоря Сікорського», м. Київ


Гнучкі методології управління проєктами докорінно змінили підхід організацій до розробки програмного забезпечення та ІТ-проектів. Засновані на принципах, викладених у Маніфесті Agile у 2001 році, методології Agile надають пріоритет співпраці з клієнтами, гнучкому плануванню та адаптивним процесам розробки. Ці методології, включаючи Scrum, Kanban та Lean, наголошують на ітеративному прогресі, командній співпраці та гнучкості, що дозволяє командам швидко адаптуватися до мінливих вимог та більш ефективно надавати високоякісні результати [1,2].

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

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

1. Відсутність (або слабка) комунікація: ефективна комунікація є основою будь-якої успішної команди. У не-технічних відділах слабка комунікація може призвести до непорозумінь, дублювання зусиль і пропущених дедлайнів. Команди часто стикаються з труднощами у поширенні інформації та забезпеченні того, щоб усі члени команди були в одному інформаційному полі.

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

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

4. Тиск з боку клієнтів: не-технічні команди часто стикаються з тиском з боку замовників або клієнтів, що може змусити їх надавати перевагу швидкості над якістю. Цей зовнішній тиск може призвести до порушення стандартів і підвищення рівня стресу серед членів команди.

5. Небажання слухати і чути: ефективна командна робота вимагає активного слухання та готовності розглядати різні точки зору. Коли члени команди не бажають слухати, це може стримувати інновації та заважати почути цінні ідеї.

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

Scrum - це ітеративний та інкрементний фреймворк Agile, який допомагає командам керувати складними проєктами, розбиваючи їх на керовані ітерації. Кожна ітерація зазвичай триває 1-4 тижні і забезпечує потенційний приріст продукту, який можна відвантажити.

Ключові принципи Scrum: Емпіричне управління процесом - рішення ґрунтуються на спостереженнях, досвіді та експериментах. Співпраця - тісна комунікація між членами команди та зацікавленими сторонами є дуже важливою. Самоорганізовані команди - команди самостійно керують своєю роботою та процесами.  [1,2].

Церемонії Scrum. Sprint planning - команда визначає цілі та завдання для майбутнього спринту. Daily Scrum - Щоденна зустріч впродовж якої команда сихнронізується стосовно виконаних задач та виниклих проблем які блокують подальшу роботу над задачами. Sprint review - Команда демонструє завершену роботу зацікавленим сторонам та збирає зворотній зв'язок. Sprint Retrospective - Команда аналізує процес спринту та визначити сфери для покращення. Backlog Refinement - процес постійного оновлення, деталізації та пріоритезації елементів Product Backlog. Цей процес зазвичай проводиться регулярно, щоб забезпечити, що беклог продукту є актуальним і містить достатньо детальні завдання для майбутніх спринтів [2].

Документи Scrum. Беклог продукту - пріоритетний список функцій, покращень та виправлень для майбутніх спринтів. Беклог спринту - список завдань і користувацьких історій, які потрібно завершити в поточному спринті. Діаграма згортання - візуальне представлення роботи, що залишилася, у порівнянні з часом, що залишився до кінця спринту [3].

Проаналізувавши основні проблеми управління проєктом для не-технічних команд, а також методи і інструменти гнучкої методології керування проєктами Scrum, я пропоную використовувати наступні підходи для оптимізації робочого процесу: Планування робіт команди на ітерацію в один тиждень - дозволить команді фокусуватись на поставлених цілях ітерації і сформує чітке бачення командою пріоритетів. Також планування робіт дозволить команді обирати обʼєм робіт який точно буде виконаним протягом ітерації, що зменшить вірогідність встановлення командою нереалістичних термінів виконання задач і зробить роботу команди більш прогнозованою для компанії. Щоденні зустрічі з обговоренням поточного стану задач і блокуючих факторів - допоможуть уникнути слабкої комунікації і її негативних наслідків для проєкту. Також позитивно вплинуть на можливості команди реагувати на зміну пріоритетів і залишатися в фокусі найважливіших задач. Уточнення і розбір деталей задач - цей процес дозволить всій команді однаково розуміти, що є очікуваним результатом по виконанню робіт. Щотижнева зустріч по обговоренню результатів ітерації дозволить аналізувати слабкі і сильні сторони процесів протягом ітерації.

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

Література:

1. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M. et al. (2001). Manifesto for Agile Software Development. http://Agilemanifesto.org/ 

2. Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28-35. 

3. Rasnacis, A., & Berzisa, S. (2017). Method for adaptation and implementation of agile project management methodology. Procedia Computer Science, 104, 43-50.



Creative Commons Attribution Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License
допомога Знайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter

Другие научные работы даной секции

Конференции

Конференции 2024

Конференции 2023

Конференции 2022

Конференции 2021



Міжнародна інтернет-конференція з економіки, інформаційних систем і технологій, психології та педагогіки

Наукова спільнота - інтернет конференції

:: LEX-LINE :: Юридична лінія

Інформаційне суспільство: технологічні, економічні та технічні аспекти становлення