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

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

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

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

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

საკლიენტო ვებპლატფორმა 30 000-ად გაიყიდა. შეფასება 400 საათია, საშუალო ხარჯის განაკვეთით 38, პლუს 2 000 მესამე მხარის ხარჯი: ლიცენზიები და ჰოსტინგი აწყობის პერიოდში. დაგეგმილი ხარჯი 17 200-ია, მარჟა კი 43%.

ინტეგრაციებზე სამუშაო გაიწელა და პროექტს 520 საათი დასჭირდა. ხარჯი 21 760-მდე გაიზარდა, მარჟა კი 27%-მდე დაეცა. ფასი 736 საათამდე გაუძლებდა, სანამ პროექტი მოგებას შეწყვეტდა: (30 000 − 2 000) ÷ 38.

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

ვთქვათ, მხარდაჭერის ხელშეკრულებით თვეში 40 საათი იყიდება 2 400-ად. დატვირთულ თვეში გუნდი 55 საათს ხარჯავს. წერილობითი წესის გარეშე ეს 15 საათი უბრალოდ იკარგება და აბონენტის რეალური განაკვეთი საათში 60-იდან დაახლოებით 44-მდე ეცემა.

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

1. ცვლის თქვენს დეველოპერულ ხელსაწყოებს? არ უნდა სჭირდებოდეს. დავალებების სისტემა შეინარჩუნეთ და ისეთი ბიზნესფენა აირჩიეთ, რომელიც იმ დონეზე მუშაობს, რომელზეც აფასებთ და ინვოისს წერთ.
2. ინტეგრაციები. PLYNTUM-ს Jira-სთან, GitHub-თან და GitLab-თან ინტეგრაცია დღეს არ აქვს, API და webhook-ები კი Scale პაკეტისთვის დაგეგმილია. თუ საათები ტიკეტებიდან ავტომატურად უნდა სინქრონდებოდეს, ეს პირველ რიგში შეამოწმეთ.
3. დრო, რომელსაც დეველოპერები რეალურად აღრიცხავენ. საათმზომი იმ დავალებაზე, რომელზეც მუშაობენ, პარასკევის ტაბელს სჯობს.
4. ცვლილებების კონტროლი. შეთანხმებული ცვლილება, ჩაწერილი პროექტის გვერდით და არა ჩატში.
5. ფასი მთელი გუნდისთვის. PLYNTUM-ის ფასი სამუშაო სივრცეზეა: 5 წევრზე თვეში 55 დოლარი, 10 წევრზე 150, 25 წევრზე 450 (ყოველთვიური გადახდით). იხ. ფასები.

• დავალებების (issue tracking) სისტემა არ არის: არ აქვს სპრინტები, story point-ები, სიჩქარის დიაგრამები და კოდთან კავშირი.
• Jira-სთან, GitHub-თან, GitLab-თან და Slack-თან ინტეგრაცია დღეს არ აქვს; API და webhook-ები დაგეგმილია.
• CRM-ის ძირითადი ფუნქციები შესაბამისი წვდომით მუშაობს. შეთავაზების შიდა მონახაზი და მოგებული გარიგების გადაყვანა Core-იდან იწყება და შესაბამის უფლებებს მოითხოვს; კლიენტისთვის გაგზავნა და ინტეგრაციები ცალკე გადაამოწმეთ. ნახეთ CRM-ის პირობები.
• საბუღალტრო პროგრამა არ არის და ხელფასს არ ითვლის.

1. აირჩიეთ ერთი ფიქსირებული ფასის პროექტი და ერთი მხარდაჭერის კლიენტი. ისინი მარჟის დაკარგვის ორივე გზას აჩვენებს.
2. შექმენით დავალებები იმ ფაზებისა და ფუნქციებისთვის, რომლებიც დააფასეთ, შეფასებით საათებში, ტიკეტები კი იქვე დატოვეთ, სადაც არის.
3. შეიტანეთ თითოეული ადამიანის სრული საათობრივი ღირებულება და თითოეული პროექტის ღირებულება. ხელფასები მხოლოდ ხელმძღვანელობას უჩანს.
4. სთხოვეთ გუნდს, ორი კვირა დრო ყოველდღიურად აღრიცხოს, შემდეგ კი თითოეულ ფაზაზე საათები შეფასებას შეადარეთ.
5. შეთანხმებული ცვლილებები ჩატიდან პროექტის დავალებებში გადაიტანეთ და შეთანხმებულ დამატებით სამუშაოს ინვოისი გამოუწერეთ.

დაიწყეთ Launch-ის 7-დღიანი საცდელი პერიოდით; ტაბელების დამტკიცებას, პერიოდულ ინვოისებსა და მომგებიანობას Core სჭირდება. თქვენს აწყობაზე კითხვები გაქვთ? მოგვწერეთ.