დეველოპმენტის კომპანია იშვიათად კარგავს ფულს თავად კოდზე. ფული კოდის ირგვლივ იკარგება: ფიქსირებული ფასის პროექტზე, რომელსაც მესამედით მეტი დრო დასჭირდა; მხარდაჭერის საათებზე, რომლებმაც აბონენტს გადააჭარბა; ცვლილებაზე, რომელიც ჩატში შეთანხმდა და არავინ დააფასა; შეფასებაზე, რომელიც ისე გაკეთდა, რომ არავინ ნახა, რეალურად რამდენი დასჭირდა ბოლო მსგავს პროექტს.
ამ კითხვებს დავალებების სისტემა ვერ პასუხობს, რადგან ის დავალებებსა და story point-ებს ითვლის და არა ფულს. ვერც ბუღალტერია პასუხობს, რადგან ის ინვოისებს ხედავს და არა საათებს. პასუხი ამ ორს შორისაა და კომპანიების უმეტესობაში ცხრილში ცხოვრობს, რომელსაც ვინმე თვის ბოლოს ანახლებს.
"},{"heading":"რა უნდა აღრიცხოთ ბექლოგის გარეთ","html":"საკლიენტო ვებპლატფორმა 30 000-ად გაიყიდა. შეფასება 400 საათია, საშუალო ხარჯის განაკვეთით 38, პლუს 2 000 მესამე მხარის ხარჯი: ლიცენზიები და ჰოსტინგი აწყობის პერიოდში. დაგეგმილი ხარჯი 17 200-ია, მარჟა კი 43%.
ინტეგრაციებზე სამუშაო გაიწელა და პროექტს 520 საათი დასჭირდა. ხარჯი 21 760-მდე გაიზარდა, მარჟა კი 27%-მდე დაეცა. ფასი 736 საათამდე გაუძლებდა, სანამ პროექტი მოგებას შეწყვეტდა: (30 000 − 2 000) ÷ 38.
| შეფასება | ფაქტობრივი | |
|---|---|---|
| ფასი | 30 000 | 30 000 |
| საათები | 400 | 520 |
| ხარჯი, საათში 38 | 15 200 | 19 760 |
| მესამე მხარის ხარჯი | 2 000 | 2 000 |
| მარჟა | 43% | 27% |
ციფრები მეთოდს აჩვენებს. სასარგებლო ისაა, რომ გადახრა 300-ე საათზე დაინახოთ, როცა ცვლილების მოთხოვნისთვის ჯერ კიდევ არის დრო, და არა 520-ე საათზე. როგორ აირჩიოთ მოდელი თითოეულ პროექტზე, ამას სტატია ფიქსირებული ფასი თუ საათობრივი განიხილავს.
"},{"heading":"მხარდაჭერის აბონენტები","html":"ვთქვათ, მხარდაჭერის ხელშეკრულებით თვეში 40 საათი იყიდება 2 400-ად. დატვირთულ თვეში გუნდი 55 საათს ხარჯავს. წერილობითი წესის გარეშე ეს 15 საათი უბრალოდ იკარგება და აბონენტის რეალური განაკვეთი საათში 60-იდან დაახლოებით 44-მდე ეცემა.
წესი პირველ თვემდე შეათანხმეთ: დამატებითი საათები ხელშეკრულების განაკვეთით ფასდება, შეზღუდვის ფარგლებში მომდევნო თვეზე გადადის ან უარყოფილია. შემდეგ მხარდაჭერის სამუშაო ყოველდღიურად აბონენტის პროექტზე აღრიცხეთ, რომ გადაჭარბება მესამე კვირაში გამოჩნდეს და არა ინვოისზე.
"},{"heading":"როგორ აირჩიოთ პროგრამა დეველოპმენტის კომპანიისთვის","html":"დაიწყეთ Launch-ის 7-დღიანი საცდელი პერიოდით; ტაბელების დამტკიცებას, პერიოდულ ინვოისებსა და მომგებიანობას Core სჭირდება. თქვენს აწყობაზე კითხვები გაქვთ? მოგვწერეთ.
"}]},"keyFacts":[["რას მართავს","საკლიენტო სამუშაოს ბიუჯეტებს, აღრიცხულ საათებს, შეთანხმებულ ცვლილებებს, მხარდაჭერის აბონენტებს, ინვოისებსა და მომგებიანობას."],["დეველოპერული ხელსაწყოები","Jira-ს, GitHub-სა და GitLab-ს გვერდით მუშაობს და მათ არ ცვლის; მათთან ინტეგრაცია დღეს არ აქვს."],["შეთანხმებული ცვლილებები","შეთანხმებული ცვლილება ცალკე დავალებად ემატება შეფასებით, ამიტომ მისი საათები ცალკე რჩება."],["არ შედის","არ არის სპრინტები, story point-ები და კოდთან კავშირი, კლიენტისთვის კომერციული შეთავაზების გაგზავნა არ შედის, API კი Scale-ში გამოჩნდება."]],"faq":[["ცვლის PLYNTUM Jira-ს ან GitHub-ს?","არა. ბექლოგი და კოდი იქვე დატოვეთ, სადაც არის. PLYNTUM ბიზნესმხარეს ინახავს: პროექტის ბიუჯეტებს, აღრიცხულ საათებს, შეთანხმებულ ცვლილებებს, აბონენტებს, ინვოისებსა და მომგებიანობას."],["როგორ აღრიცხავენ დეველოპერები დროს PLYNTUM-ში?","იმ ფაზებისა და ფუნქციების დავალებებზე, რომლებიც დააფასეთ, ხელით ჩართული საათმზომით ან ტაბელით. Core-იდან მენეჯერი ყოველკვირეულ ტაბელებს ამტკიცებს; საათები პროექტის ხარჯად აღრიცხვისთანავე ითვლება."],["აქვს PLYNTUM-ს Jira-სთან, GitHub-თან ან GitLab-თან ინტეგრაცია?","დღეს არა. API და webhook-ები Scale პაკეტისთვის დაგეგმილია. თუ საათები ტიკეტებიდან ავტომატურად უნდა სინქრონდებოდეს, PLYNTUM ჯერ არ მოგერგებათ."],["როგორ ვადევნო თვალი ფიქსირებული ფასის პროექტის მარჟას?","მიუთითეთ პროექტის ღირებულება და თითოეული ადამიანის სრული საათობრივი ღირებულება. Core-იდან აღრიცხული საათები ჩაწერისთანავე ხარჯად იქცევა, ამიტომ მარჟის შემცირებას პროექტის მსვლელობისას ხედავთ და არა ბოლო ინვოისის შემდეგ."],["რა ღირს PLYNTUM 25-კაციანი დეველოპმენტის კომპანიისთვის?","Scale 25 წევრამდე თვეში 450 დოლარი ღირს, წლიური გადახდით კი თვეში 360, და დატვირთვისა და სიმძლავრის დაგეგმვასაც ამატებს. Core 10 წევრამდე 150 დოლარია."]]}