პროდუქტის განვითარების ფაზა - 15 სტარტაპ მენეჯმენტის ტექნიკები

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


ასე რომ ადრეული სტარტაპი  გამოწვევა მდგომარეობს შემდეგში:  პროდუქტი უნდა გამოიყურებოდეს მაქსიმალურად კარგად საბოლოო მომხმარებლისთვის, ამასთან შემქმნელების ჯგუფმა ეს უნდა უზრუნველყოს A BIT MANUALLY.
ეს არ არის ყველაფერი, ყოველთვის ფასის შემცირება ნიშნავს ძალიან ინტენსიურ მენეჯმენტს.

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

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

პირველი და შეიძლება ყველაზე მნიშვნელოვანი არის SOURCE CODE MANAGEMENT-ი. 

შენ ხარ მფლობელი, და შესაბამისად source code უნდა გეკუთვნოდეთ თქვენ, ანუ თქვენ კომპანიას. 

არა ერთ თვეში, არა ერთ წელში არამედ დასაწყისშივე, პირველივე დღიდან. 

ამის გამოსავალი არის შემდეგში, უნდა დარეგისტრირდეთ GIT ONLINE REPOSITORY-ზე, ისეთებზე როგორებიც ამ სურათშია წარმოდგენილი.

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

ამის პლუსებია:

• წვდომა source code-ზე - ყოველთვის გექნებათ Backup-ი კოდის(შესრულებული სამუშაოსი)
• დეველოპერების შესრულებულ სამუშაოსთან წვდომა (შეგიძლიათ ნებისმიერ დროს ნახოთ ვინ რა გააკეთა, დაამატა და ა.შ.)
• შესაძლებლობა რომ გააზიარო წვდომა ნებისმიერ ახალ დეველოპერთან. 

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

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

ერთი ის რომ ნებისმიერ დროს რომ შეწყვიტოს ურთიერთობა ბევრს არ დაკარგავთ არცერთი, მაქსიმუმ დაკარგოთ იმ კვირის მუშაობა. 

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

ძალიან ბევრი წარუმატებელი სტარტაპი ყოფილა, მხოლოდ იმის გამო რომ source code-ის მფლობელი იყო დეველოპერი. 

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

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

SOURCE CODE მენეჯმენტის შემდეგ, მოდი ვისაუბროთ AGILE PROJECT MANAGEMENT მეთოდოლოგიაზე. 

ეს არის ყველაზე უფრო მორგებული მეთოდოლოგია სტარტაპებისთვის. 

რომლის დროსაც თქვენ უნდა :

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

არის ბევრი კურსი ამ მეთოდოლოგიასთან დაკავშირებით და სასურველია თუ გადახედავთ, მაგრამ ძირითადი აზრი მდგომარეობს შემდეგში: 

არსებობს product backlog_ი, სადაც ჩამონათვალია იდეების, და ყოველი სპრინტის (როგორც წესი 1 ან 2 კვირის პერიოდის დრო) დროს თქვენ ირჩევთ ამ იდეებიდან რომელი განახორციელოთ სპრინტის პერიოდში. 

ასე რომ ყოველი სპრინტის შემდეგ უნდა გქონდეთ პროდუქტსი ახალი ვერსია.

ასევე ძალიან მნიშვნელოვანია რომ მიჰყვეთ შემდეგ რიტუალებს ამ მეთოდოლოგიის გამოყენებისას.

რიტუალები:

• რეტროსპექტივა დემონსტრაციასთან ერთად
• Burn down chart -ი გაძლევთ საშუალებას პროგრესს ადევნოთ თვალყური დღიურ ჭრილში.  - თვალყური უნდა ადევნოთ რომ თქვენი დეველოპმენტის პროცესი არ ჩერდება, 
• 1 კვირა პასუხისმგებლობების გარეშე  (ანუ ახალი source code_ის გარეშე)  - არ არის ნორმალური

ეს მეთოდოლოგია ასევე საშუალებას გაძლევთ რომ შეაფასოთ შესრულებული სამუშაო დაგეგმილთან მიმართებაში, რამდენად ჩამორჩებით ან უსწრებთ დაგეგმილ გრაფიკს. 

BURN DOWN CHART_ი გაძლევთ ამის საშუალებას, თქვენ შეგიძლიათ ადევნოთ შესრულების პროცესს თვალყური დღიურ ჭრილში. 

ეს ფუნქცია აქვს თითქმის ყველა AGILE SOFTWARE-ს. 

შეიძლება ეს არ აკეთოთ დასაწყისში სანამ 1 დეველოპერი მუშაობს, მაგრამ როცა გაიზრდება გუნდი, ამის კეთება აუცილებელია.

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

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

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

რომ შევაჯამოთ სტარტაპის მენეჯმენტის ტექნიკები, ჩვენ უნდა

1. დავწეროთ შემდგომი ვერსიის სპეციფიკაციები 
2. ვაკონტროლოთ source code თქვენი საკუთარი რეპოზიტორით
3. გამოვიყენოთ AGILE მეთოდოლოგია - რაც მოგცემთ, უკეთეს კონტროლს პროექტის დაგეგმვაზე, უფრო მოქნილს გახდის პროექტს, უკეთეს კომუნიკაციას უზრუნველყოფს თქვენს გუნდის წევრებთან და 

რაც შეეხება გუნდს, მოდი შემდეგ სექციაში ვნახოთ, რა ტიპის რესურსი გჭირდებათ თქვენი პროექტისთვის.