როდის მუშაობს Agile და როდის არა: მითები, შეზღუდვები და რეალური ეფექტურობა ბიზნესისთვის

Agile ერთ-ერთი ყველაზე ხშირად გამოყენებადი მიდგომაა პროექტების მართვაში. მას განიხილავენ როგორც ინსტრუმენტს ორგანიზაციული მოქნილობისა და ცვლილებებზე სწრაფი რეაგირების ზრდისთვის, ასევე როგორც საშუალებას პროექტების უფრო სწრაფად და ეფექტურად განხორციელებისთვის. Agile-ის გამოყენება ცალკეულ პროექტებში, პირობები და შეზღუდვები, ასევე „მოქნილი“ და Waterfall მიდგომების გამოყენების ძირითადი განსხვავებები პროექტების მართვაში – სწორედ ესაა ამ სტატიის თემა.

პროექტის ტიპები

პროექტის მართვის სტანდარტების და პროდუქტის განვითარების სასიცოცხლო ციკლის მიხედვით, შემდეგი ტიპის პროექტები გამოირჩევა:

გეგმაზე ორიენტირებული — პროექტები, რომელთა ძირითადი შეზღუდვები დაგეგმილია plan-driven) საწყისი დაგეგმვის ეტაპზე და ხორციელდება PDCA (Plan-Do-Check-Act) ციკლის შესაბამისად.

ადაპტირებადი change-driven) — პროექტები, რომელთა ძირითადი შეზღუდვები დაგეგმილია მთელი პროექტის განმავლობაში და თავად პროექტი დაყოფილია ნაწილებად, რომლებსაც იტერაციები ეწოდება. ასეთი დაყოფის მნიშვნელობა იმ ფაქტის აღიარებაა, რომ პროექტი განხორციელების ეტაპზე ფიქსირდება დიდი რაოდენობით ცვლილებები და, შესაბამისად, ამ პროექტის მართვის მიდგომა უნდა მოიცავდეს მოთხოვნების მუდმივ განახლებას.

ჰიბრიდული პროექტები არის პროექტები, რომელთა ელემენტები (პროდუქტის ფაზები ან ნაწილები) შეიძლება განხორციელდეს როგორც პროგნოზირებადი, ასევე ადაპტური გზით.

თავის მხრივ, ადაპტირებადი პროექტები პროექტის აგების ორ მიდგომას მოიცავს:

• იტერაციულს – პროექტი ხორციელდება მოკლე სეგმენტებად, რომლებიც შეიცავს PDCA (Plan-Do-Check-Act) ციკლს. ეს მიდგომა გამოიყენება იმ პროექტებზე, რომელთა საწყისი მოთხოვნები დეტალურად არ არის აღწერილი და შესაბამისად, პროექტის განხორციელების დროს ეს მოთხოვნები დაზუსტდება ან შეიცვლება.
• ინკრემენტული – პროდუქტი იქმნება და მომხმარებელს ნაწილ-ნაწილ გადაეცემა. ეს მიდგომა გულისხმობს მომხმარებლის მოთხოვნების განხორციელებას მათი პრიორიტეტულობის მინიჭებით რამდენიმე ფაქტორის საფუძველზე, რომელთა შორის მთავარია მოთხოვნის ღირებულება და მის იმპლემენტაციასთან დაკავშირებული რისკი.

Agile არის ადაპტირებადი პროექტი, რომელიც იყენებს როგორც იტერაციულ, ასევე ინკრემენტულ მიდგომებს. ამ ტიპის საფუძველზე შემუშავებულია და გამოიყენება მრავალი მეთოდი (ჩარჩო).

მეთოდების ეს ოჯახი შექმნილია შემდეგი ამოცანების გადასაჭრელად:

• პროექტის შედეგების მომხმარებლისთვის მიწოდება მინიმალურ დროში (ინკრემენტები).
• პროექტში მუდმივი კორექტირებების შეტანა (იტერაციები).
• პროექტის დაგეგმვაზე დახარჯული დროისა და ხარჯების შემცირება.

Agile ხშირად აღიქმება, როგორც უფრო თანამედროვე და ეფექტური მიდგომა კლასიკურ Waterfall მოდელთან შედარებით. თუმცა, პრაქტიკაში, ყველა Agile პროექტი არ სრულდება დროულად, ბიუჯეტის ფარგლებში ან დაგეგმილი შედეგით. უფრო მეტიც, Agile მეთოდოლოგიების გავრცელებასთან ერთად, შეინიშნება საპირისპირო ტენდენციაც – კომპანიები უბრუნდებიან ტრადიციულ მართვის მოდელებს. იმის გასაგებად, თუ რატომ ხდება ეს, ღირს თითოეული მიდგომის შეზღუდვების და მათი გავლენის გათვალისწინება პროექტის ეფექტურობაზე.

გაეცანით პროექტის მართვისა და აღრიცხვის მოდულის შესაძლებლობებს Microsoft Dynamics 365 Finance-ში.

გაიგეთ მეტი

გავრცელებული მითები

მცდარი წარმოდგენები პრობლემებს ქმნის კონკრეტული მიდგომის რეალურ გამოყენებაში და, როგორც გამოცდილება აჩვენებს, დაკავშირებულია როგორც პრაქტიკული ცოდნის ნაკლებობასთან, ისე სტერეოტიპებთან, რომლებიც ხაზს უსვამენ უპირატესობებს, მაგრამ უგულებელყოფენ შეზღუდვებს.

მითი 1. „დაგეგმვა საჭირო არაა — უბრალოდ უნდა აკეთო.“

ეს ფრაზა ხშირად Agile-ის ერთ-ერთ პრინციპად აღიქმება. ლამაზად ჟღერს, მაგრამ აჩენს კითხვებს: რა უნდა გაკეთდეს? რა თანმიმდევრობით? რა რესურსებით? რა ფასად? როგორ უნდა მივაწოდოთ პროდუქტი მომხმარებელს? და სხვა.

პრაქტიკაში Agile-ის გამოყენება გამარტივებულ დაგეგმვას გულსიხმობს (Waterfall-თან შედარებით), რადგან:

ა) პროექტი ხორციელდება მოკლე იტერაციებით (სპრინტებით) — როგორც წესი, 2–4 კვირა — და ასეთი პერიოდის დაგეგმვას არ უნდა დასჭირდეს იმხელა რესურსი, რამდენიც 3-წლიან Waterfall პროექტს.

ბ) თუ თავიდანვე ცნობილია დიდი მოცულობის მოსალოდნელი ცვლილებები, ლოგიკურია დეტალურად დაგეგმოთ მხოლოდ თითოეული იტერაქცია (სპრინტი), და არა მთელი რელიზი ან პროექტი, რადგან ეს არ არის პრაქტიკული.

ეს არ გამორიცხავს მთელი პროექტის ღირებულებისა და ხანგრძლივობის წინასწარ შეფასებას.

მითი 2. „ნებისმიერი პროექტი შეიძლება Agile-ით განხორციელდეს.“

ეს აშკარა გადაჭარბებაა. არსებობს ფაქტორების ერთობლიობა, რომლებიც განსაზღვრავს პროექტის სიცოცხლის ციკლის სწორი მეთოდის არჩევას — მისი ძლიერი და სუსტი მხარეების, ბუნებრივი შეზღუდვებისა და პრაქტიკული მიზანშეწონილობის გათვალისწინებით (იხილეთ ქვემოთ).

მითი 3. „Agile— პოპულარული, მაგრამ პრაქტიკაში გამოუყენებელი.“

ესეც მცდარი ხედვის მეორე მხარეა. Agile ძალიან ეფექტურად მუშაობს გარკვეული ტიპის პროექტებში როგორც სრული იმპლემენტაციის მოდელი (მაგ., ცვლილებების მართვა, Six Sigma, IT განვითარება და სხვ.).
ასევე ის წარმოადგენს ჰიბრიდული პროექტების მნიშვნელოვან ნაწილს — მოდელს, რომელიც თანამედროვე ტექნოლოგიური განვითარებიდან გამომდინარე სულ უფრო მეტად ხდება დომინანტი, განსაკუთრებით IT სფეროში.

Მითი 4. „Agile-ში გუნდს მართვა არ სჭირდება — ის თვითორგანიზებულია და ყველა გადაწყვეტილებას თავად იღებს.“

თვითორგანიზება ნამდვილად სასურველი პრაქტიკაა თანამედროვე მენეჯმენტში, მაგრამ მოსაზრებები, თითქოს:
ა) გუნდი თავიდანვე თვითორგანიზებულია;
ბ) პროექტს მართვა არ სჭირდება;
გ) თუ გუნდი თვითორგანიზებული არ არის, ის Agile არაა —
საკმაოდ სადავოა.

თვითორგანიზების ხარისხი დამოკიდებულია გუნდის ზომაზე, მონაწილეების ფსიქოლოგიაზე, გამოცდილებაზე, კვალიფიკაციაზე, პროექტის სტრესულობაზე, მომხმარებლისთვის მის მნიშვნელობაზე, ორგანიზაციის მართვის კულტურაზე და სხვა ფაქტორებზე.

პრაქტიკაში, მართვის სტილი (დირექტიული თუ სერვისული) უნდა შეირჩეს რეალური სიტუაციის მიხედვით — როგორც „ადაპტურ“, ისე „პროგნოზირებად“ პროექტებში — და შეიძლება სხვადასხვა ეტაპზე შეოცვალოს.

მითი 5. „ Waterfall მოდელი მოძველებულია, Agile — ახალი და თანამედროვე მიდგომაა.“

ფაქტობრივად, ინკრემენტული და იტერაციული მიდგომები უკვე მრავალი წელია არსებობს.
რაც ნამდვილად ახალია, არის დროის ჩარჩოები, მაგალითად SCRUM-ში, სადაც იტერაციის ხანგრძლივობა მკაცრადაა განსაზღვრული.

ამ მიდგომას აქვს როგორც უპირატესობები, ისე მინუსები (იხილეთ ქვემოთ).
აღსანიშნავია, რომ კონკრეტული მიდგომის ეფექტურობა დამოკიდებულია არა მის „სისრულეზე“ ან „მოძველებაზე“, არამედ იმაზე, რამდენად შეეფერება იგი პროექტის გარემო პირობებს.

მითი 6. „კანბანის დაფაზე სტიკერების გადატანა — ეს არის Agile.“

ფერადი სტიკერები და ვიზუალური დაფები ნამდვილად თვალში საცემია, მაგრამ ზოგჯერ მათ გადამეტებულ მნიშვნელობას ანიჭებენ.

სინამდვილეში:

ა) კანბანი თავდაპირველად პროექტების მართვისთვის შექმნილი სრულებითაც არ იყო;

ბ) სტატუსების დაფები მხოლოდ ვიზუალიზაციის ინსტრუმენტია — შესაძლებელია გამოიყენოთ ან საერთოდ არ გამოიყენოთ.

პროექტის რეალური მდგომარეობის მონიტორინგისთვის ბევრად უფრო ძლიერი და კომპლექსური ინსტრუმენტები არსებობს.

მიზანშეწონილობა
ნებისმიერი პროექტის ჩაშენებული არსი „სამმაგი შეზღუდვაა“ (triple constraint). შესაბამისად, პროექტის დაწყებამდე, მომხმარებელთან შეთანხმებულია ერთ-ერთი შეზღუდვა (შინაარსი/ხანგრძლივობა/ღირებულება), რომელსაც დაექვემდებარება პროექტის გუნდის ყველა ქმედება დაგეგმვასა და იმპლემენტაციასთან დაკავშირებით.

ორი შეზღუდვის დაწესება მნიშვნელოვნად ართულებს პროექტის დანერგვას, ხოლო მესამე – პროექტს ნამდვილ მიღწევად აქცევს. თუ „Waterfall“ მოდელში (პროგნოზირებადი ტიპი) მთავარი შეზღუდვაა შინაარსი, ანუ რა უნდა გაკეთდეს შედეგის მისაღწევად, მაშინ Agile მეთოდებში ეს ჩვეულებრივ ხანგრძლივობაა. ანუ, Agile-ის გამოყენება, პირველ რიგში, მომხმარებლისთვის პროდუქტის რაც შეიძლება სწრაფად მიწოდების მცდელობაა (ჩვეულებრივ, ნაწილ-ნაწილ, ანუ თანდათანობით).

ამგვარად, გამოიყენება კონტენტის (და ხარისხის) „კომპრომისი“ მიწოდების სისწრაფეს შორის. ამ ზოგადი პრინციპის გარდა, პროექტის განხორციელების კონკრეტული მიდგომის განხილვისას გათვალისწინებულია შემდეგი ფაქტორები:

• პროდუქტის ფუნქციების ურთიერთდამოკიდებულების ხარისხი — რამდენად შეიძლება კონკრეტული პროდუქტის ფუნქციის გამოყენება სხვა ფუნქციების გამოყენების გარეშე.
• პროექტის სპეციფიკაციების დეტალიზაციის (ხარისხის) ხარისხი — დაბალი დეტალიზაცია პროექტის განხორციელების პროცესში შინაარსში ცვლილებების რისკს შეიცავს, რაც დაუყოვნებლივ იწვევს საბოლოო შედეგის შექმნისას იტერაციების გამოყენების აუცილებლობას, ასევე ამ იტერაციების ხანგრძლივობის შეზღუდვას.
• თუ პროექტი კონტრაქტით ხორციელდება,— მაგალითად, ფიქსირებული ფასის კონტრაქტი ვარაუდობს, რომ სპეციფიკაციები დეტალურია და შინაარსში ცვლილებების რისკი მცირეა, მაგრამ ამ შემთხვევაში იტერაციული მიდგომა აზრს კარგავს.
• რა ზომისაა პროექტის გუნდი — რაც უფრო დიდია გუნდი, მით უფრო რთულია მისი მართვა და საჭიროა მისი მცირე ჯგუფებად დაყოფა, რაც ართულებს მუშაობას მოკლე იტერაციების დიდი რაოდენობით.
• საბოლოო შედეგის ხარისხი — რაც უფრო მაღალია მოთხოვნები პროდუქტზე და რაც უფრო კრიტიკულია ის მომხმარებლისთვის, მით უფრო მკაცრია შინაარსობრივი შეზღუდვები და მით უფრო არასასურველია ცვლილებების შეტანა.

რეკომენდაციები და შეზღუდვები ერთი ან მეორე მიდგომის გამოყენებასთან დაკავშირებით:

იდეალური პირობები Agile პროექტებისთვის:

• სამუშაოს განუსაზღვრელი მოცულობა, ანუ მოსალოდნელია ცვლილებების დიდი რაოდენობა.
• პროექტის საბოლოო შედეგის მომხმარებლისთვის უმოკლეს დროში მიწოდების აუცილებლობა.
• პროექტის საბოლოო შედეგის მომხმარებლისთვის ნაწილებად მიწოდების შესაძლებლობა.
• პროექტი ხორციელდება ორგანიზაციის შიდა საჭიროებებისთვის (ხელშეკრულების გარეშე).
• პროექტი ხორციელდება გარე მომხმარებლისთვის „მიწოდებისთანავე გადახდის“ ხელშეკრულებით (დრო და მასალები).
• პროექტის გუნდში ადამიანების რაოდენობა 6 ადამიანამდეა.

Waterfall პროექტების პირობები:

• სამუშაოს განსაზღვრული მოცულობა, ანუ ცვლილებების რაოდენობა პროგნოზირებადია და იტერაციების გამოყენებას აზრი არ აქვს.
• სამუშაოს დრო მეორეხარისხოვანი ფაქტორია.
• პროდუქტის ფუნქციები მჭიდროდ არის დაკავშირებული ერთმანეთთან, ანუ ინკრემენტული მიდგომა შეუძლებელია ან მკაცრად შეზღუდულია.
• შიდა ან გარე პროექტი ნებისმიერი ტიპის კონტრაქტის ფარგლებში.
• პროექტის გუნდის წევრების ნებისმიერი რაოდენობა.

თუ პროექტი და მისი პირობები „სასაზღვროა“, ანუ არსებობს როგორც პირველი, ასევე მეორე ჯგუფის წინაპირობები, ასეთი პროექტი შეიძლება განხორციელდეს ჰიბრიდული ტიპის მიხედვით:

• პროექტის ფაზები განისაზღვრება Agile-ის მიხედვით, ზოგი კი Waterfall-ის მიხედვით.
• პროდუქტის ზოგიერთი მახასიათებელი Waterfall-ის მიხედვითაა, ზოგი კი Agile-ის მიხედვით.

ზემოთ მოყვანილი მცდარი წარმოდგენებისა და „მიზანშეწონილობის“ სია ამომწურავი არ არის, რადგან არსებობს სხვა ფაქტორებიც, რომლებიც გავლენას ახდენენ პროექტის განხორციელების კონკრეტული მიდგომის გამოყენების ეფექტურობაზე. მაგალითად, მნიშვნელოვანი და აქტუალური თემაა პროექტის შემსრულებელი ორგანიზაციის (ორგანიზაციული მოქნილობა) საერთო მოქნილობა, ასევე მისი მომხმარებელი (თუ პროექტი ხორციელდება კონტრაქტით). გარემო, რომელშიც პროექტი ხორციელდება, მისი წარმატების კრიტიკული ფაქტორია. მიუხედავად ამისა, ამ სტატიაში განხილული საკითხები, შეზღუდვები და რეკომენდაციები მნიშვნელოვანია იმის გასაგებად, თუ რომელი მართვის მეთოდია საუკეთესო კონკრეტულ სიტუაციაში გამოსაყენებლად. ასევე აღსანიშნავია, რომ პროექტის განხორციელების ვარიანტის სწორმა არჩევანმა შეიძლება მნიშვნელოვნად იმოქმედოს მის წარმატებაზე, მაგრამ არ იძლევა გარანტიას, რომ პროექტი განხორციელდება დადგენილი შეზღუდვების ფარგლებში ან საერთოდ განხორციელდება, რადგან კონკრეტული ინიციატივისთვის დამახასიათებელი რისკების ერთობლიობა – როგორც მისი შეფასებისა და პრიორიტეტულობის ეტაპზე (მართვის პორტფელის დონე), ასევე მისი განხორციელების ეტაპზე (მართვის ოპერატიული დონე) – პირდაპირ გავლენას ახდენს ძალისხმევის საბოლოო შედეგზე და მის მიღწევადობაზე.

უზრუნველყავით თქვენი ბიზნესის ოპტიმიზაცია Microsoft Dynamics 365 Finance-ის Project Management & Accounting-ის ფუნქციონალით.

გაიგეთ მეტი

ვლად ბერეზინი

Business Development Manager, SMART business

20+ წლიანი გამოცდილება ბიზნესის, პროექტებისა და გაყიდვების მენეჯმენტის სფეროში. 2007 წლიდან 2012 წლამდე იყო პროექტების მართვის ინსტიტუტის (PMI) პრეზიდენტი, კიევის ფილიალში. პრაქტიკული გამოცდილება პროექტების დანერგვაში საწარმოს რესურსების დაგეგმვის (ERP), ადამიანური რესურსების (HR), მარკეტინგის, ორგანიზაციების, EPM, PPM, BPMS და ბიზნეს პროცესების (BP) სფეროებში.