რატომ სჭირდება პროდუქტს მუდმივი ტექნიკური მხარდაჭერა
გაშვებული პროდუქტი არ ნიშნავს დასრულებულს. ბრაუზერები განახლდება, მობილური ოპერაციული სისტემები ახალ ვერსიებს გამოუშვებს, მესამე მხარის API-ების პირობები იცვლება, უსაფრთხოების ხარვეზები გამოჩნდება. გამოყოფილი მხარდაჭერის გარეშე ეს პრობლემები ფარულად გროვდება, სანამ მომხმარებლებს რეალური ზიანი არ მიადგებათ.
ჩვენ ვუწევთ სრული ციკლის მხარდაჭერას ვებ- და მობილური პროდუქტებისთვის: ფრონტენდი, ბექენდი, მონაცემთა ბაზები და ინფრასტრუქტურა. ერთი გუნდი, რომელიც იცნობს თქვენს კოდბაზას, სწრაფად პასუხობს და პროდუქტს სტაბილური და განვითარებადი ინახავს.
როდის სჭირდება ბიზნესს გამოყოფილი მხარდაჭერის გუნდი?
გამოყოფილი მხარდაჭერის კონტრაქტი გამართლებულია, თუ:
- გაქვთ ცოცხალი პროდუქტი რეალური მომხმარებლებით და ვერ ითმენთ გათიშვებს
- შიდა გუნდი ახალ ფუნქციებზეა ფოკუსირებული და ტექნიკური მოვლისთვის დრო არ ჰყოფნის
- მიიღეთ მემკვიდრეობით კოდბაზა და გჭირდებათ გამოცდილი დეველოპერები მის სიჯანსაღეზე
- გსურთ გარანტირებული რეაგირების დრო, ფრილანსერის ხელმისაწვდომობის ლოდინის ნაცვლად
- გჭირდებათ სრული სტეკის გადაფარვა — ვინმე, ვინც ფრონტიდან ბექენდამდე პრობლემებს მოაგვარებს
- შესაბამისობის ან უსაფრთხოების მოთხოვნები მოითხოვს რეგულარულ აუდიტებსა და განახლებებს
რა შედის მომსახურებაში
- ბაგებისა და ჰოტფიქსების გამოსწორება — ფრონტენდი და ბექენდი, ერთი გუნდი
- პერფორმანსის მონიტორინგი და შეფერხების ანალიზი
- დამოკიდებულებათა განახლება და უსაფრთხოების პაჩები
- მონაცემთა ბაზის მოთხოვნების ოპტიმიზაცია და DBA-დონის სერვისი
- CI/CD პაიპლაინის მართვა და განლაგების მხარდაჭერა
- ბრაუზერისა და ოპერაციული სისტემის თავსებადობის განახლებები
- ახალი ფუნქციების შემუშავება რეტეინერის საათების ფარგლებში
- ყოველთვიური სტატუს-ანგარიში შესრულებული სამუშაოთი და გაუმჯობესების რეკომენდაციებით
როგორ ვმუშაობთ
პროგნოზირებადად, სტრუქტურირებულად და გამჭვირვალედ:
- ონბოარდინგი — ვსწავლობთ კოდბაზას, ინფრასტრუქტურასა და არქიტექტურას. ვაფიქსირებთ ნაპოვნს და ერთობლივად ვსაზღვრავთ მხარდაჭერის სკოუფს. ტიპური ონბოარდინგი: 3–5 სამუშაო დღე.
- ტასქების მიღება — ამოცანები შემოდის თქვენი სასურველი ინსტრუმენტით: Linear, Jira, Notion, GitHub Issues ან ელ. ფოსტა. ვახარისხებთ, ვაფასებთ და ვამყარებთ შეთანხმებას სამუშაოს დაწყებამდე.
- შესრულება — ვმუშაობთ ყოველთვიური საათების პულიდან სიმძიმის მიხედვით. კრიტიკული საკითხები რიგს გვერდს უვლის, მიუხედავად დარჩენილი საათებისა.
- ანგარიშგება — ყოველთვიური შეჯამება შესრულებული ამოცანებით, დახარჯული საათებით, სისტემის მდგომარეობისა და შემდეგი ციკლის რეკომენდაციებით.
SLA და რეაგირების დრო
ვახარისხებთ საკითხებს სიმძიმის მიხედვით: კრიტიკული (სისტემა გათიშულია ან მონაცემების დაკარგვის საფრთხე) → 1 საათი; მაღალი (ძირითადი ფუნქცია გაფუჭებულია, შემოსავლის ზარალი) → 4 საათი; საშუალო (გაუარესებული გამოცდილება, გამოსავალი არსებობს) → 1 სამუშაო დღე; დაბალი (მინორული, კოსმეტიკური, გაუმჯობესებები) → დაგეგმილი მიმდინარე სპრინტში.
SLA-ის გარანტია ვრცელდება სამუშაო საათებში (ორ–პარ, 9:00–18:00 GMT+4). პრიორიტეტული და კრიტიკული პაკეტები მოიცავს on-call გარდაფარვას სამუშაო საათების გარეთ.