ზრდის ფაზა - 22 მზარდი გუნდის გამოწვევები და ორგანიზაცია

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

ეს არის PRODUCT OWNER_ის პასუხისმგებლობის ნაწილი.
რომ გავიხსენოთ რა არის მისი მოვალეობები: ეს არის რომ მიიღოს გადაწყვეტილებები რა feature- ები გაკეთდეს და რა გადაიდოს.

ეს არის ერთგვარი კლიენტი ტექნიკური გუნდისთვის.

მაშინ როცა CTO უზრუნველყოფს საჭირო რესურსების მობილიზებას, PRODUCT OWNER_ი წყვეტს რა ფუნქციონალი შეიქმნას ამ რესურსების გამოყენებით.
PRODUCT OWNER-ის როლი არის საკვანძო როლი ზრდის ეტაპზე.

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

დამფუძნებლისთვის ეს რთული დროა, ეს იმას ჰგავთ თითქოს product owner_მა მოიპარა მისი პირმშო.  მაგრამ არ შეგეშინდეთ, დამფუძლებელს ყოველთვის შეუძლია გაუზიაროს მისი აზრი პროდუქტის განვითარებასთან დაკავშირებით და  კარგმა product owner-მა უნდა მოუსმინოს ამ აზრებს.

როდესაც ვსაუბრობთ product owner-ზე, უნდა დარწმუნდეთ რომ ის სრულიად განსხვავებული იქნება CTO-სგან.

მაგალითად product owner-ი უნდა იყოს მარკეტოლოგი და ესმოდეს ტექნიკური საკითხები კარგად, ხოლო CTO უნდა იყოს ტექნიკურ საკითხებში ძალიან ძლიერი და ჰქონდეს კარგი გაგება მარკეტინგისა მარკეტინგზე.

ძალიან მნიშვნელოვანია რომ ამ ორ პიროვნებას ესმოდეს ერთმანეთის და ამიტომაც არის საჭირო რომ გარკვეულიგ გაგება ჰქონდეთ ერთმანეთის ძირითადის საქმიანობებისю 

მაშინ როცა product owner_ი მოიფიქრებს გარკვეულ ფუნქციონალს და გაანდობს CTO-ს, CTO-მ ამასთან დაკავშირებით უნდა მოიფიქროს და შესთავაზოს product owner-ს ტექნიკური გადაწყვეტები ამ ახალ ფუნქციონალთან დაკავშირებით, ეს ასევე გულისხმობს ამ ფუნქციონალის ინოვაციურ ჭრილში გადაწყვეტასაც(უფრო სწორედ ასე უდნა მოხდეს IMHO). 

პროექტის მენეჯმენტის ნაწილში, გასათვალისწინებელია ერთი ძალზედ მნიშვნელოვანი საკითხი

REPORTING

რეპორტინგი აუცილებელია ყველანაირი ტიპის DELEGATION-ისთვის, იქნება ეს outsourcing_ი თუ შიდა გუნდი. 

ეს საკითხი რომ გავითვალისწინოთ არის 5 კითხვა შემსრულებლებთან, არ აქვს მნიშვნელობა ეს იქნება ვებ სააგენტო, FREELANCER_ი თუ შდა გუნდი

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

ასე რომ უზრუნველყავით თქვენ ვებ-სააგენტოსთან მჭიდრო კომუნიკაცია, თუ ასეთ რამე ხდება. 

ასევე არის ძალიან მნიშვნელოვანი საკითხი. კერძოდ როცა თქვენ გყავთ მზარდი გუნდი, თქვენ უნდა გქონდეთ SMOOTH ORGANIZATION (კარგად ორგანიზებული უნდა იყოთ გუნდის მართვის ნაწილში), ეს ნიშნავს რომ უნდა გქონდეთ HIGH AGILE ORGANIZATION. 

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

შემდეგი ასპექტი არის smooth organization_ის ქონა, მაღალი AGILITY-ს გათვალისწინებით. 

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

ეს შესაძლებელია იმ შემთხვევაში თუ სრულდება შემდეგი ორი პირობა. 

მაგრამ რა არის ეს?

გახსოვთ სხვადასხვა გარემოები?

• DEVELOPMENT ENVIRONMENT
• TEST ENVIRONMENT
• PRODUCTION ENVIRONMENT?

Continuous integration არის ავტომატური პროცესი, რომელიც გაძლევთ საშუალებას პატარა კოდის საფუძველზე,  მოახდინოთ deploy თითოეულ environment-ში, უბრალოდ განსაზღვრულ ღილაკზე დაჭერით. 

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

ეს უზრუნველყოფს პროგრამის სწრაფ განახლებას. 

შემდეგი კონცეპტი არის continuous deployment, ეს არის ზუსტად იგივე პრინციპი რაც Continuous integration, მაგრამ ღილაკის გარეშე. 

ღილაკი მაგივრად არის პატარა სკრიპტი. 

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

გულახდილად რომ ვთქვათ, ამ ხარისხის და დონის  მიღწევა რთული საქმეა,ეს მოითხოვს ბევრ დროს და მაღალ ხარისხს. 

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

როცა მზარდ გუნდზე ვსაუბრობთ, რა მოხდება მაშინ თუ ორმა დეველოპერმა შეცვალა ერთიდაიგივე SOURCE CODE-ის ფაილი?

SOURCE CODE REPOSITORY SOLUTIONS- მაგალითდ GIT_ი მართავს ამ პროცესს. 

ამისათვის არის კარგი პრაქტიკა:

რაც ნიშნავს რომ ყოველ დეველოპერს შეუძლია ჰქონდეს source code_ის საკუთარი კოპია. 

როცა დეველოპერი დაამთავრებს მის სამუშაოს, ანუ ერთ feature-ს.  ის გაა_publish-ებს ეგრეთ წოდებულ pool request. შემდგომ product owner ან scrum master-ი შეამოწმებს commit-ებს და დარწმუნდება რომ ყველაფერი წესრიგშია  და მხოლოდ ამის შემდეგ გაუკეთებს MERGE-ს, ამ დეველოპერის SOURCE CODE-ს, მთავარ repository-ში. 

ამ პრინციპს ჰქვია GITFLOW. და ამისთვის არსებობს TOOL_ები, რომ ასეთი გზით მოხდეს source code_ის მენეჯმენტი 

რომ შევაჯამოთ ეს ნაწილი

ეს რამოდენიმე პრინციპი მოითხოვს კვირეების და თქვეების მუშაობას. 

მაგრამ ეს მოგცემთ საშუალებას რომ გახდეთ უფრო და უფრო დიდი  და სწრაფად მოახდინოთ რეაგირება მომხმარებლების მოთხოვნებზე და შესაბამისად დარჩეთ AGILE.