სად იკარგება მარჟა საკლიენტო დეველოპმენტში
დეველოპმენტის კომპანია იშვიათად კარგავს ფულს თავად კოდზე. ფული კოდის ირგვლივ იკარგება: ფიქსირებული ფასის პროექტზე, რომელსაც მესამედით მეტი დრო დასჭირდა; მხარდაჭერის საათებზე, რომლებმაც აბონენტს გადააჭარბა; ცვლილებაზე, რომელიც ჩატში შეთანხმდა და არავინ დააფასა; შეფასებაზე, რომელიც ისე გაკეთდა, რომ არავინ ნახა, რეალურად რამდენი დასჭირდა ბოლო მსგავს პროექტს.
ამ კითხვებს დავალებების სისტემა ვერ პასუხობს, რადგან ის დავალებებსა და story point-ებს ითვლის და არა ფულს. ვერც ბუღალტერია პასუხობს, რადგან ის ინვოისებს ხედავს და არა საათებს. პასუხი ამ ორს შორისაა და კომპანიების უმეტესობაში ცხრილში ცხოვრობს, რომელსაც ვინმე თვის ბოლოს ანახლებს.
რა უნდა აღრიცხო ბექლოგის გარეთ
- თითოეული საკლიენტო პროექტის ფასი ან ბიუჯეტი, ფიქსირებული თუ საათობრივი.
- საათები ადამიანების მიხედვით შეფასებასთან შედარებით, იმ დონეზე, რომელზეც აფასებდი: ფაზები ან ფუნქციები და არა ყოველი დავალება.
- ცვლილების მოთხოვნები გადაწყვეტილებით: შედის, დამატებით ფასდება თუ უარყოფილია.
- მხარდაჭერის აბონენტები: ყოველთვიურად გამოყენებული საათები გაყიდულ საათებთან შედარებით.
- ინვოისები და მისაღები თანხები იმავე კლიენტზე, რომ დაგვიანებული გადახდა იმ სამუშაოს გვერდით ჩანდეს, რომელსაც ეკუთვნის.
როგორ მუშაობს PLYNTUM-ში
- პროექტები კლიენტისა და ფაზის მიხედვით. აწყობა, მეორე ფაზა და მხარდაჭერის ხელშეკრულება შეიძლება ერთი კლიენტის ცალკე პროექტები იყოს. იხ. კლიენტებისა და პროექტების მართვა.
- დავალებები იმ დონეზე, რომელზეც აფასებ. ტიკეტები დავალებების სისტემაში დატოვე, PLYNTUM-ში კი იმ ფაზებისა და ფუნქციების დავალებები შექმენი, რომლებიც დააფასე. დაფის, სიისა და თაიმლაინის ხედები გეგმას აჩვენებს.
- დრო დავალებაზე. დეველოპერები საათებს ამ დავალებებზე წერენ — ხელით ჩართული საათმზომით ან ტაბელით. Core-იდან ტაბელებს მენეჯერი ამტკიცებს. იხ. დროის აღრიცხვა.
- ცვლილების მოთხოვნები. მოთხოვნები და დამტკიცებები ყოველ ცვლილებას პასუხისმგებელსა და ჩაწერილ გადაწყვეტილებას აძლევს, სანამ მასზე მუშაობა დაიწყება.
- აბონენტები და ინვოისები. Core-იდან პერიოდული ინვოისები მხარდაჭერის ხელშეკრულებებს იწერს; ერთჯერადი ინვოისები, გადახდები და მისაღები თანხები იმავე კლიენტზეა.
- მომგებიანობა. Core-იდან დამტკიცებული საათები თითოეული ადამიანის სრული საათობრივი ღირებულებით ხარჯად იქცევა და პროექტის ღირებულებასა და პირდაპირ ხარჯებს ედარება. იხ. პროექტის ბიუჯეტი, ხარჯი და მომგებიანობა.
ფიქსირებული ფასის პროექტი, დათვლილი მაგალითით
საკლიენტო ვებპლატფორმა 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-ე საათზე. როგორ აირჩიო მოდელი თითოეულ პროექტზე, ამას სტატია ფიქსირებული ფასი თუ საათობრივი განიხილავს.
მხარდაჭერის აბონენტები
ვთქვათ, მხარდაჭერის ხელშეკრულებით თვეში 40 საათი იყიდება 2 400-ად. დატვირთულ თვეში გუნდი 55 საათს ხარჯავს. წერილობითი წესის გარეშე ეს 15 საათი უბრალოდ იკარგება და აბონენტის რეალური განაკვეთი საათში 60-იდან დაახლოებით 44-მდე ეცემა.
წესი პირველ თვემდე შეათანხმე: დამატებითი საათები ხელშეკრულების განაკვეთით ფასდება, შეზღუდვის ფარგლებში მომდევნო თვეზე გადადის ან უარყოფილია. შემდეგ მხარდაჭერის სამუშაო ყოველდღიურად აბონენტის პროექტზე აღრიცხე, რომ გადაჭარბება მესამე კვირაში გამოჩნდეს და არა ინვოისზე.
როგორ აირჩიო პროგრამა დეველოპმენტის კომპანიისთვის
- ცვლის შენს დეველოპერულ ხელსაწყოებს? არ უნდა სჭირდებოდეს. დავალებების სისტემა შეინარჩუნე და ისეთი ბიზნესფენა აირჩიე, რომელიც იმ დონეზე მუშაობს, რომელზეც აფასებ და ინვოისს წერ.
- ინტეგრაციები. PLYNTUM-ს Jira-სთან, GitHub-თან და GitLab-თან ინტეგრაცია დღეს არ აქვს, API და webhook-ები კი Scale პაკეტისთვის დაგეგმილია. თუ საათები ტიკეტებიდან ავტომატურად უნდა სინქრონდებოდეს, ეს პირველ რიგში შეამოწმე.
- დრო, რომელსაც დეველოპერები რეალურად აღრიცხავენ. საათმზომი იმ დავალებაზე, რომელზეც მუშაობენ, პარასკევის ტაბელს სჯობს.
- ცვლილებების კონტროლი. მოთხოვნა გადაწყვეტილებით, პროექტის გვერდით და არა ჩატში.
- ფასი მთელი გუნდისთვის. PLYNTUM-ის ფასი სამუშაო სივრცეზეა: თვეში 55 დოლარი 5 წევრზე, 150 — 10 წევრზე, 450 — 25 წევრზე (ყოველთვიური გადახდით). იხ. ფასები.
რას არ აკეთებს PLYNTUM
- დავალებების (issue tracking) სისტემა არ არის: არ აქვს სპრინტები, story point-ები, სიჩქარის დიაგრამები და კოდთან კავშირი.
- Jira-სთან, GitHub-თან, GitLab-თან და Slack-თან ინტეგრაცია დღეს არ აქვს; API და webhook-ები დაგეგმილია.
- შეთავაზებებს ჯერ არ ადგენს; შეთავაზებები და გაყიდვების CRM დაგეგმილია.
- საბუღალტრო პროგრამა არ არის და ხელფასს არ ითვლის.
როგორ დაიწყო
- აირჩიე ერთი ფიქსირებული ფასის პროექტი და ერთი მხარდაჭერის კლიენტი. ისინი მარჟის დაკარგვის ორივე გზას აჩვენებს.
- შექმენი დავალებები იმ ფაზებისა და ფუნქციებისთვის, რომლებიც დააფასე, შეფასებით საათებში, ტიკეტები კი იქვე დატოვე, სადაც არის.
- შეიტანე თითოეული ადამიანის სრული საათობრივი ღირებულება და თითოეული პროექტის ღირებულება. ხელფასები მხოლოდ ხელმძღვანელობას უჩანს.
- სთხოვე გუნდს, ორი კვირა დრო ყოველდღიურად აღრიცხოს, შემდეგ კი თითოეულ ფაზაზე საათები შეფასებას შეადარე.
- ცვლილების მოთხოვნები ჩატიდან მოთხოვნებში გადაიტანე გადაწყვეტილებით და შეთანხმებულ დამატებით სამუშაოს ინვოისი გამოუწერე.
დაიწყე Launch-ის 7-დღიანი საცდელი პერიოდით; ტაბელების დამტკიცებას, პერიოდულ ინვოისებსა და მომგებიანობას Core სჭირდება. შენს აწყობაზე კითხვები გაქვს? მოგვწერე.