aiAPPmaintenanceმხარდაჭერამობილური აპი

მობილური აპის post-launch maintenance კონტრაქტის scope

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

aiNOWProduct teamგანახლდა 26 სექტემბერი, 2026წაკითხვის დრო: 9 წთ

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

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

გაშვების შემდგომი მოვლის ხელშეკრულება

maintenance არის შეთანხმებული სამუშაო, რომელიც აპის გამოშვების შემდეგ მის ფუნქციურ მდგომარეობას, უსაფრთხო განახლებას და ოპერაციულ მხარდაჭერას ეხება. ის შეიძლება მოიცავდეს ხარვეზის გამოძიებას, პლატფორმის ახალი ვერსიის ტესტს, store-ში ახალი build-ის მომზადებას, მცირე ტექსტურ ან UI ცვლილებას და მესამე მხარის კავშირის შემოწმებას.

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

მხარდაჭერის სამუშაოების გამიჯვნა

სამუშაო	საწყისი კითხვა	დასრულების მტკიცებულება
ინციდენტი	მომხმარებელი ვერ ასრულებს არსებულ გზას?	გამეორებული ტესტი, მიზეზი ან ცნობილი შეზღუდვა
ხარვეზის გამოსწორება	დადასტურებული შეცდომა რომელ მდგომარეობაშია?	გამოსწორების build და რეგრესიის შედეგი
მცირე ცვლილება	იცვლება ტექსტი, წესი, ეკრანი ან მონაცემი?	დამტკიცებული მოთხოვნა და მიღების სცენარი
პლატფორმის განახლება	იცვლება SDK, OS, permission ან store-ის მოთხოვნა?	ორივე პლატფორმის ტესტი და release ჩანაწერი
ოპერაციული მოვლა	უნდა შემოწმდეს კავშირი, ლოგი, backup ან კონფიგურაცია?	შემოწმების ანგარიში და აღმოჩენილი რისკების სია

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

ინციდენტის პროცედურა

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

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

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

როგორ მოამზადოთ პლატფორმისა და store-ის განახლება?

iOS და Android-ის განახლება შეიძლება შეეხოს API-ს, permission-ს, ფონის მუშაობას, შეტყობინებას, ბილდს ან store-ის მოთხოვნას. ამიტომ maintenance პაკეტში ჩამოწერეთ, ვინ აკვირდება შესაბამის ცვლილებას, ვინ ამზადებს საცდელ build-ს, რომელ გზებზე ტარდება რეგრესიის ტესტი და ვის ეკუთვნის store submission-ის საბოლოო გადაწყვეტილება.

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

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

რა შეიტანოთ მონიტორინგსა და მონაცემთა დაცვაში?

მონიტორინგი უნდა აღწერდეს კონკრეტულ სიგნალს, წყაროსა და რეაგირების მოქმედებას. გაითვალისწინეთ აპის შეცდომები, backend-ის ხელმისაწვდომობა, გარე API-ის პასუხი, push-ის პრობლემები, გადახდის სტატუსი და store release-ის მდგომარეობა მხოლოდ იმ შემთხვევაში, თუ ეს წყაროები რეალურად არსებობს და კონტრაქტით ხელმისაწვდომია.

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

რომელი ველები უნდა ჰქონდეს ხელშეკრულებას?

სისტემის საზღვარი: აპის ვერსია, backend, ადმინისტრირება, store ანგარიში და გარე კავშირები.
სამუშაოს ტიპები: ინციდენტი, ხარვეზი, მცირე ცვლილება, პლატფორმის განახლება და release.
მოთხოვნის არხი: ვინ აგზავნის, რა მონაცემი ახლავს და როგორ ითვლება მოთხოვნა მიღებულად.
მიღების პირობა: ტესტის სცენარი, პასუხისმგებელი, მტკიცებულება და დახურვის ფორმა.
წვდომა: რეპოზიტორი, store, cloud, ლოგები, საიდუმლოებები და დროებითი მომხმარებლები.
გარე დამოკიდებულება: რა ხდება, თუ ბანკი, რუკა, შეტყობინება ან სხვა პროვაიდერი იცვლის API-ს.
გასვლა: დოკუმენტაცია, მიმდინარე branch, ცნობილი ხარვეზები, წვდომის გაუქმება და ახალი გუნდისთვის გადაცემა.

მოთხოვნების საერთო ჩეკლისტი დაგეხმარებათ საწყისი სისტემის აღწერაში. maintenance კონტრაქტი კი უნდა დაემატოს release-ის შემდეგი ოპერაციის კონკრეტული პასუხისმგებლობებით.

რა ნაბიჯებით შეადაროთ maintenance შეთავაზებები?

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

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

რომელი შეცდომები ზრდის maintenance-ის გაურკვევლობას?

პირველი შეცდომაა მხოლოდ ყოველთვიური „მხარდაჭერის“ სახელის დაწერა სამუშაოს ჩამონათვალის გარეშე. მეორეა store-ისა და backend-ის გამოტოვება, თითქოს აპის ბაგი მხოლოდ ტელეფონში ჩნდება. მესამეა production წვდომის მიცემა საერთო ანგარიშით. მეოთხეა ახალი ფუნქციის ჩასმა maintenance-ში ისე, რომ მოთხოვნა, დიზაინი და მიღების ტესტი არ არსებობს.

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

რას ვერ დაგპირდებათ maintenance კონტრაქტი?

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

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

ხშირად დასმული კითხვები

maintenance მოიცავს თუ არა ახალ ფუნქციას?

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

აუცილებელია თუ არა მონიტორინგი?

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

რა ხდება კონტრაქტის დასრულებისას?

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

დაკავშირებული მასალა

გამოყენებული წყაროები

სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.