როგორ არის მოწყობილი მუშაობა FoodSoul-ის სისტემაზე: იდეიდან შედეგამდე

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

FoodSoul — ცოცხალი სისტემა

FoodSoul — უბრალოდ აპლიკაცია არ არის. მის უკან დგას დიდი ინფრასტრუქტურა: CRM, მონაცემთა შენახვა და დაცვა, ვებ-საიტებისა და მობილური აპლიკაციების შაბლონები და ათასობით პარტნიორი რესტორანი, თითოეულს თავისი საჭიროებები და სამუშაო სცენარები აქვს.

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

როგორ არის მოწყობილი გუნდი და სამუშაოს სტრუქტურა

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

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

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

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

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

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

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

როგორ ვანიჭებთ პრიორიტეტებს

როდესაც პრობლემა ჩნდება, ერთ-ერთ სცენარს მივყვებით.

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

კრიტიკული ბაგი ერთ კლიენტთან — თუ შეცდომა პირდაპირ გავლენას ახდენს პარტნიორის შემოსავალზე ან რეპუტაციაზე, პრიორიტეტი ისეთივე მაღალია. ჩვენ ვახმართ ძირითად რესურსებს და მოკლე ვადაში ვაგვარებთ პრობლემას.

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

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

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

რატომ ჩნდება ბაგები

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

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

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

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

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

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

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

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

პატივისცემით,

Project Manager FoodSoul