12 რთული კითხვა, რომ ვებდეველოპერის შეთავაზებები სწორად შეადაროთ
შეთავაზებები მსგავსი ჩანს, მაგრამ ფასები განსხვავდება? ეს 12 კითხვა დაგეხმარებათ გაიგოთ საკუთრება, რეპო, ფასის მოდელი, სპეციფიკა, მხარდაჭერა და CMS.
თქვენს მაგიდაზე რამდენიმე შეთავაზებაა. ზედაპირულად ზოგიერთი ერთმანეთს ჰგავს: „ვებგვერდი + ადმინისტრაციის პანელი + SEO + მხარდაჭერა“. რიცხვები კი ძალიან განსხვავდება. ეს ხშირად ნიშნავს, რომ ეს შეთავაზებები რეალურად შედარებადი არ არის. ყველაზე სწრაფი გზა ამის გასაგებად არის ყველა შემსრულებელს ერთი და იგივე რთული კითხვები დაუსვათ და ყურადღებით მოუსმინოთ კონკრეტიკას.
1) ვის ეკუთვნის კოდი და დიზაინის ფაილები გაშვების შემდეგ?
ეს განსაზღვრავს, შეძლებთ თუ არა შემსრულებლის შეცვლას თავიდან აშენების გარეშე და გადაიქცევა თუ არა თქვენი საიტი ხელახლა გამოყენებად აქტივად, თუ „ჩაკეტილ“ აბონენტურ სერვისად.
კარგი პასუხი ჟღერს ასე: „კოდის საწყისი ვერსია, საბოლოო build, დიზაინის ფაილები (Figma/Sketch), ჩვენ მიერ დაწერილი ტექსტები და ყველა შექმნილი ანგარიში თქვენ გეკუთვნით. გაშვებისას ყველაფერს გადმოგცემთ და აგიხსნით, როგორ იმუშაოთ მასთან.“ ჰკითხეთ, რას გულისხმობენ „დიზაინის ფაილებში“. ეს უნდა მოიცავდეს რედაქტირებად ფაილს და არა მხოლოდ ექსპორტირებულ PNG-ებს.
საშიში პასუხი ჟღერს ასე: „ვებგვერდი თქვენ გეკუთვნით, მაგრამ კოდს ჩვენ ვინახავთ“, „საწყის ფაილებს არ ვაზიარებთ“, ან „კოდის გამოსყიდვა შეგიძლიათ დამატებითი საფასურით“. კიდევ ერთი წითელი ალამია ბუნდოვანი ფორმულირებები, მაგალითად „ლიცენზირებულია თქვენზე“. თუ საკუთრებას წერილობით არ აფიქსირებენ, ჩათვალეთ, რომ ქირაობთ.
2) სად ინახება კოდი და მივიღებ თუ არა რეპოზიტორიაზე წვდომას?
რეპოზიტორია არის ერთიანი „სიმართლის წყარო“. თუ წვდომა არ გაქვთ, ვერ ხედავთ პროგრესს, შეცდომის შემდეგ სწრაფად ვერ აღადგენთ და ახალ დეველოპერს ვერ ჩართავთ ზედმეტი დაბრკოლებების გარეშე.
კარგი პასუხი ჟღერს ასე: „Git-ს ვიყენებთ. კოდი ინახება კერძო რეპოში GitHub/GitLab/Bitbucket-ზე თქვენს ორგანიზაციაში, ან გაშვებისას სრულად გადმოგცემთ. თქვენ გაქვთ admin წვდომა. ხედავთ commit-ებსა და release-ებს. გაშვების ვერსიას ვნიშნავთ tag-ით.“ დამატებითი ქულაა, თუ აგიხსნიან როგორ მართავენ secrets-ს (API key-ებს), რომ ისინი რეპოში არ აღმოჩნდეს.
საშიში პასუხი ჟღერს ასე: „დამთავრებისას ZIP-ს გამოგიგზავნით“, ან „ჩვენს სერვერზეა“. ZIP-ით გადმოცემა ისტორიას აკარგვინებს, scope creep-ს მალავს და დებაგინგს ართულებს.
3) ეს ფიქსირებული ფასია თუ საათობრივი — და რა ხდება, თუ scope გაიზრდება?
ფასის მოდელი განსაზღვრავს თქვენს რისკს. ფიქსირებული ფასი უსაფრთხოა, თუ scope მკაფიოა. საათობრივი შეიძლება სამართლიანი იყოს, თუ გაქვთ გამჭვირვალობა და კონტროლი. ყველაზე სახიფათო ვარიანტია „ფიქსირებული ფასი“ ბუნდოვანი scope-ით, სადაც ყოველი დეტალი ფასიან ცვლილებად გადაიქცევა.
კარგი პასუხი ჟღერს ასე: „ეს ფიქსირებულია განსაზღვრული scope-ის ფარგლებში. თუ scope შეიცვალა, სამუშაოს დაწყებამდე ვაგზავნით წერილობით change request-ს ღირებულებითა და ვადებზე ზემოქმედებით. თუ საათობრივია, ვაძლევთ დიაპაზონით შეფასებას, ვაწარმოებთ საათების ლოგს და თქვენ ამტკიცებთ კვირეულ ლიმიტს.“ ჰკითხეთ, რა ითვლება ცვლილებად: ახალი გვერდის ტიპები, დამატებითი ენები, ახალი ინტეგრაციები, admin პანელში ახალი როლები.
საშიში პასუხი ჟღერს ასე: „როგორც წავა, ისე ვნახავთ“, „ნუ ღელავთ, არ შეიცვლება“, ან „ყველაფერი შედის“ — იმის გარეშე, რა არის ეს „ყველაფერი“. თუ ცვლილებების პროცესს ვერ ხსნიან, ბიუჯეტში მოულოდნელობები ძალიან მოსალოდნელია.
4) ტექნიკურ სპეციფიკაციას ვინ წერს — თქვენ თუ მე?
ტექნიკური სპეციფიკაცია „ბიუროკრატია“ არ არის. ეს არის გზა, რომ არ ააშენოთ არასწორი რამ და შემდეგ არ იკამათოთ, რა იყო „თითქოს თავისთავად გასაგები“. თუ სპეციფიკაციას არ ჰყავს მფლობელი, გადაკეთებაში გადაიხდით.
კარგი პასუხი ჟღერს ასე: „ჩვენ ვმართავთ discovery-ს, ვწერთ სპეციფიკაციას და თქვენ ამტკიცებთ. თქვენ გვაწვდით ბიზნეს-წესებსა და მაგალითებს. ჩვენ ამას ვაქცევთ user flow-ებად, გვერდის ტემპლეიტებად, მონაცემთა ველებად, ინტეგრაციებად და acceptance criteria-დ.“ ძლიერ შემსრულებელს შეუძლია გაჩვენოთ მაგალითიც: როგორ იქცევა პროდუქტის ბარათი, რა ხდება როცა მარაგი ნულზე ჩამოდის, რომელი ელფოსტები იგზავნება, რომელი ველებია სავალდებულო.
საშიში პასუხი ჟღერს ასე: „თქვენ გვითხარით რა გინდათ და ავაშენებთ“ — წერილობითი მოთხოვნების გარეშე. ან პირიქით: „სრული სპეციფიკაცია თქვენ უნდა მოგვიტანოთ“ — თუ რეალურად შიდა პროდუქტის გუნდი არ გყავთ. ორივე შემთხვევაში, პასუხისმგებლობის ბუნდოვანება ხშირად მოგვიანებით გადაიქცევა დაგვიანებად და ცვლილებების საფასურად.
5) კონკრეტულად რა ხდება გაშვების შემდეგ — და რამდენ ხანს?
გაშვება ფინიშის ხაზი არ არის. DNS პრობლემები, ელფოსტის მიწოდებადობა, გადახდების edge case-ები და „პატარა“ კონტენტის შესწორებები ყოველთვის ჩნდება go-live-ის შემდეგ. თუ მხარდაჭერა განსაზღვრული არაა, პრობლემის დროს მოლაპარაკებას დაიწყებთ.
კარგი პასუხი ჟღერს ასე: „გვაქვს განსაზღვრული stabilization პერიოდი (მაგალითად, რამდენიმე კვირა) შეთანხმებულ scope-თან დაკავშირებული ბაგების გასასწორებლად. შემდეგ ვთავაზობთ ongoing maintenance-ს მკაფიო პირობებით: რა შედის, რა არის ფასიანი და რა response time გვაქვს.“ ასევე უნდა მოიცავდეს ბექაფებს, უსაფრთხოების განახლებებს და მონიტორინგს — განსაკუთრებით თუ საიტი იყენებს პლაგინებს ან framework-ს, რომელსაც patch-ები სჭირდება.
საშიში პასუხი ჟღერს ასე: „ვუშვებთ და მერე თქვენ თვითონ“ — ან მხარდაჭერა, რომელიც ერთ კონკრეტულ ადამიანზეა დამოკიდებული და არ აქვს ჩანაცვლება. ასევე ფრთხილად იყავით „სიცოცხლის ბოლომდე უფასო მხარდაჭერასთან“, თუ ძალიან ვიწროდ არ არის განსაზღვრული.
6) შემიძლია თუ არა ტექსტებისა და სურათების თვითონ შეცვლა, თქვენთან დარეკვის გარეშე?
თუ ყოველი ბანერის ცვლილებისთვის დეველოპერი გჭირდებათ, საიტის ოპერირება ნელდება. მეორე მხრივ, ყველაფერი რედაქტირებადი არც უნდა იყოს — ზედმეტმა მოქნილობამ შეიძლება არათანმიმდევრული გვერდები და დამტვრეული layout-ები შექმნას.
კარგი პასუხი ჟღერს ასე: „კი. გექნებათ admin პანელი (ან CMS) ძირითადი კონტენტისთვის: გვერდები, ბლოგი/სიახლეები, hero სექციები, პროდუქტის ინფორმაცია, სურათები, SEO ველები. გაგწვრთნით და მოგცემთ მოკლე დოკუმენტაციას. layout-ისთვის კრიტიკულ კომპონენტებს დავბლოკავთ, რომ რედაქტირებით დიზაინი არ დაირღვეს.“ სთხოვეთ, გაჩვენონ რედაქტირების გამოცდილება live დემოთი და არა სკრინშოთებით.
საშიში პასუხი ჟღერს ასე: „ცვლილებებს უბრალოდ ელფოსტით მოგვწერეთ“, ან „კოდში შეცვლით“. ეს ოპერირებისთვის მოუხერხებელია. კიდევ ერთი წითელი ალამია CMS, რომელიც თითქოს არსებობს, მაგრამ იმდენად რთულია, რომ თქვენი გუნდი მას არ შეეხებოდეს.
7) როგორ გააკეთებთ ონლაინ გადახდებს და RS.ge ინვოისებს?
საქართველოში „გადახდები“ ერთი ჩექბოქსი არ არის. უნდა გადაწყვიტოთ: ბარათით გადახდა ახლა თუ მოგვიანებით, რომელი პროვაიდერი, როგორი იქნება checkout flow, როგორ იმუშავებს დაბრუნებები (refund), და როგორ გაიცემა ინვოისები/ქვითრები (მათ შორის RS.ge მოთხოვნები, თუ საჭიროა). ეს არჩევანები გავლენას ახდენს ფასსა და ვადებზე.
კარგი პასუხი ჟღერს ასე: „დავაზუსტებთ თქვენს გადახდების პროვაიდერს და ზუსტ flow-ს (ერთჯერადი, subscription, ნაწილობრივი გადახდები). დავწერთ, რა მონაცემი ინახება, როგორ ვამუშავებთ წარუმატებელ გადახდებს და როგორ გენერირდება ინვოისი. თუ RS.ge ინტეგრაცია საჭიროა, განვსაზღვრავთ ავტომატურია, ნახევრად ავტომატური თუ ხელით და რა ველები არის საჭირო.“ კარგი შემსრულებლები თავიდანვე კითხულობენ იურიდიული პირის დეტალებზე, დღგ-ს სტატუსზე, მიწოდების წესებზე და refund პოლიტიკაზე.
საშიში პასუხი ჟღერს ასე: „გადახდებს მერე დავამატებთ“ — იმის ახსნის გარეშე, რა გავლენა ექნება ამას. ან „RS.ge მარტივია“ — რეალური checkout-ის და ბუღალტრული flow-ის გამოცდილების გარეშე.
8) ვინ ჰოსტავს საიტს და ვისი სახელით არის რეგისტრირებული ანგარიში?
ჰოსტინგი მხოლოდ სიჩქარე არ არის. ეს კონტროლია. თუ ჰოსტინგის ანგარიში შემსრულებელს ეკუთვნის, კონფლიქტის დროს შეიძლება წვდომა დაკარგოთ, ან ვერ შეცვალოთ DNS, ვერ განაახლოთ SSL და ვერ ნახოთ ლოგები, როცა რამე გაფუჭდება.
კარგი პასუხი ჟღერს ასე: „ჰოსტინგი თქვენს საკუთრებაში არსებულ ანგარიშშია (ან თქვენს სახელზე ვქმნით). თქვენ გაქვთ admin წვდომა. პროვაიდერს პირდაპირ თქვენ უხდით. სურვილის შემთხვევაში ჩვენ ვმართავთ deploy-ებსა და მონიტორინგს, მაგრამ გასაღებები თქვენ გრჩებათ.“ ასევე ჰკითხეთ ბექაფებზე (სიხშირე და შენახვის ვადა), SSL სერტიფიკატებზე და სად ჰოსტავს ელფოსტა (სასურველია ვებსაიტისგან განცალკევებით).
საშიში პასუხი ჟღერს ასე: „ჩვენს სერვერზე დავჰოსტავთ“ — თქვენი admin წვდომის გარეშე. ან დომენი „კომფორტისთვის“ შემსრულებლის სახელზეა დარეგისტრირებული. მაგალითად, Weblier-ის მიდგომაა, რომ კოდი და ყველა ანგარიში კლიენტს ეკუთვნის — შედარებისას ეს გამოიყენეთ როგორც ბენჩმარკი.
9) რა არის რეალისტური ვადა და რა იწვევს ხოლმე დაგვიანებას?
ვადა უნდა ასახავდეს რეალურ სამუშაოს: discovery, დიზაინი, დეველოპმენტი, კონტენტი, ტესტირება და გაშვება. მთავარი კითხვა ისაა, რა არის თქვენზე დამოკიდებული — და რა ხდება, თუ მასალებს აგვიანებთ.
კარგი პასუხი ჟღერს ასე: „აი გეგმა კვირების მიხედვით, დამოკიდებულებებით: თქვენ აწვდით ბრენდინგის მასალებს და კონტენტს X თარიღამდე; ჩვენ ვაწვდით დიზაინს Y თარიღამდე; თქვენ ამტკიცებთ Z დღეში; ვმუშაობთ სპრინტებით და ყოველ კვირას გაჩვენებთ სამუშაო დემოს.“ სანდო შემსრულებელი ჩამოთვლის ხშირ მიზეზებს: ნელი დამტკიცებები, არასრული პროდუქტის მონაცემები, ორ ენაზე დაგვიანებული ტექსტი, ბოლო წუთას დამატებული ფუნქციები, გადახდების პროვაიდერთან onboarding, და იურიდიულად საჭირო checkout ტექსტები.
საშიში პასუხი ჟღერს ასე: „ორი კვირა, პრობლემა არაა“ — თუ საქმე უბრალოდ landing page-ს სცდება. ან ვადა milestone-ების გარეშე და დამტკიცებების გარეშე. Weblier-ის ტიპიური პროცესი, მაგალითად, არის discovery (~1 კვირა) → დიზაინი (1–2 კვირა) → build (2–4 კვირა) → გაშვება, მაგრამ ნებისმიერ სტუდიას უნდა შეეძლოს იგივე რეალობის თქვენს scope-ზე მისადაგება.
10) შემიძლია ვნახო სამი ცოცხალი საიტი, რომელიც თქვენ ააშენეთ, და ვესაუბრო ერთ-ერთ კლიენტს?
პორტფოლიო შეიძლება შეცდომაში შემიყვანოს. ლამაზი საიტი შეიძლება ტემპლეიტი იყოს, ან შემსრულებელს მხოლოდ მცირე ნაწილი ჰქონდეს გაკეთებული. კლიენტის რეკომენდაციები გაჩვენებთ, როგორია თანამშრომლობა კონტრაქტის შემდეგ.
კარგი პასუხი ჟღერს ასე: „აქ არის სამი live პროექტი, თქვენს მსგავსად (ინდუსტრია, ფუნქციები, ორენოვანი, e-commerce, admin). აი რა გავაკეთეთ: დიზაინი, build, კონტენტის მიგრაცია, ინტეგრაციები. და დიახ, შეგიძლიათ კლიენტს ესაუბროთ — ნებართვას ავიღებთ და დაგიგეგმავთ.“ კლიენტთან საუბრისას ჰკითხეთ ვადებზე, change request-ებზე და როგორ მოგვარდებოდა საკითხები გაშვების შემდეგ.
საშიში პასუხი ჟღერს ასე: „ლინკებს ვერ გაგიზიარებთ“, „ყველაფერი NDA-ქვეშაა“, ან მხოლოდ Dribbble-ის სქრინებს აჩვენებენ. NDA-ები არსებობს, მაგრამ სტუდიას, რომელიც სტაბილურად მუშაობს, ჩვეულებრივ შეუძლია მაინც რამდენიმე საჯარო საიტის და ერთი რეფერენსის გაზიარება.
11) რა არის თქვენი response time, როცა რამე ფუჭდება?
როცა checkout არ მუშაობს ან საიტი გათიშულია, „მალე გიპასუხებთ“ საკმარისი არ არის. response time გავლენას ახდენს შემოსავალზე და სტრესზე. მაგრამ გულწრფელობაც გინდათ: 24/7 მხარდაჭერა ძვირია და ყველა ბიზნესს არ სჭირდება.
კარგი პასუხი ჟღერს ასე: „ვადგენთ severity დონეებს. კრიტიკულ შემთხვევებზე (საიტი გათიშულია, გადახდები ვერ გადის) ვრეაგირებთ შეთანხმებულ საათებში კონკრეტულ დროის ფანჯარაში და გვაქვს escalation გზა. მცირე საკითხებზე (layout-ის მცირე შესწორება) ვასრულებთ რამდენიმე სამუშაო დღეში.“ ჰკითხეთ, აკვირდებიან თუ არა uptime-ს, ვინ იღებს ალერტებს და შეუძლია თუ არა ერთზე მეტ ადამიანს რეაგირება.
საშიში პასუხი ჟღერს ასე: „უბრალოდ მოგვწერეთ“ — დროის ჩარჩოს გარეშე, ან ერთი დეველოპერი, რომელიც შეიძლება მიუწვდომელი იყოს. ასევე ფრთხილად იყავით, თუ „მყისიერად გავასწორებთ“-ს გპირდებიან ისე, რომ არ ეკითხებიან, რა stack-ია, რა ჰოსტინგია და რა წვდომა ექნებათ — რეალურ ინციდენტებს გამოძიება სჭირდება.
12) ამ შეთავაზებაში რა არ შედის პირდაპირ და მკაფიოდ?
ეს კითხვა კონფლიქტებს თავიდან აგარიდებთ. ყველა შეთავაზებას აქვს საზღვრები. კარგი შემსრულებელი მათ ხელმოწერამდე გეუბნებათ — მაშინაც კი, თუ შეთავაზება ნაკლებად „სრულყოფილად“ გამოიყურება.
კარგი პასუხი ჟღერს ასე: „არ შედის: ქოფირაითინგი, თარგმნა, პროდუქტის მონაცემების შეყვანა, პროფესიონალური ფოტოგრაფია, ფასიანი პლაგინები, მესამე მხარის subscription-ების საფასურები, იურიდიული პოლიტიკების დაწერა, რთული SEO სტრატეგია, რეკლამის tracking-ის დაყენება basic ანალიტიკის მიღმა, custom ილუსტრაციები და ongoing კონტენტის განახლებები. ჩამოუთვლელი ინტეგრაციები scope-ს გარეთაა. X-ზე მეტი გვერდის ტემპლეიტი scope-ს გარეთაა.“ ზუსტი სია პროექტზეა დამოკიდებული, მაგრამ წერილობით უნდა იყოს.
საშიში პასუხი ჟღერს ასე: „ყველაფერი შედის“ — ან დუმილი. ყველაზე ხშირი „სიურპრიზი“ გამონაკლისებია კონტენტის შეტანა, ორენოვანი კონტენტის მომზადება და ინტეგრაციების ხარჯები (გადახდის პროვაიდერის საკომისიოები, SMS, delivery API-ები).
FAQ
თუ ორი შეთავაზება ფასში ახლოა, შეიძლება ვივარაუდო, რომ ეკვივალენტურია?
არა. შეადარეთ, რაზე გექნებათ კონტროლი (ანგარიშები, რეპოზე წვდომა, რედაქტირებადი დიზაინის ფაილები), რა შედის გაშვების შემდეგ და როგორ მუშაობს change request. ორ შემსრულებელს შეიძლება ორივეს ეწეროს „CMS შედის“, მაგრამ ერთი მოგცემთ სუფთა რედაქტორს ტრენინგით, ხოლო მეორე — ძლივს გამართული პანელს, რომელიც მაინც დეველოპერს დაგაჭერინებთ. ორივეს სთხოვეთ „არ შედის“ სია და milestone-ებით გაწერილი ვადები.
სჯობს ფიქსირებული ფასი ავირჩიო თუ საათობრივი?
აირჩიეთ იმის მიხედვით, რამდენად მკაფიოა თქვენი scope. თუ საიტი მარტივია და წინასწარ შეგიძლიათ განსაზღვროთ გვერდის ტემპლეიტები, ინტეგრაციები და admin საჭიროებები, ფიქსირებული ფასი change request პროცესით, როგორც წესი, უფრო უსაფრთხოა. თუ ჯერ ადგენთ პროდუქტის წესებს, კონტენტის სტრუქტურას ან ელით იტერაციებს, საათობრივი მოდელი კვირეული ლიმიტით და გამჭვირვალე რეპორტინგით შეიძლება უფრო გულწრფელი და ნაკლებად კონფლიქტური იყოს.
რა მოვამზადო, სანამ შეთავაზებებს მოვითხოვ?
მზად გქონდეთ: საიტების მაგალითები, რომლებიც მოგწონთ (და კონკრეტულად რა მოგწონთ მათში), აუცილებელი გვერდების სია, ენები (ხშირად ქართული + ინგლისური), ძირითადი ფუნქციები (ფორმები, დაჯავშნა, e-commerce), ვინ უზრუნველყოფს ტექსტებსა და სურათებს, და ნებისმიერი ინტეგრაცია (გადახდები, მიწოდება, CRM, RS.ge ინვოისების საჭიროება). თუნდაც უხეში sitemap და მოთხოვნების 10 პუნქტი მნიშვნელოვნად გაზრდის შეთავაზების სიზუსტეს.
„დომენი და ჰოსტინგი შედის“ კარგია თუ რისკიანი?
შეიძლება კარგი იყოს, მაგრამ მხოლოდ იმ შემთხვევაში, თუ ანგარიშები თქვენს სახელზეა და გაქვთ admin წვდომა. „შედის“ უნდა ნიშნავდეს, რომ შემსრულებელი აწყობას და განახლებებს/გადახდებს მართავს, ხოლო საკუთრება და კრედენშალები თქვენ გრჩებათ. თუ დომენი შემსრულებელზეა რეგისტრირებული, რისკში ხართ. პირდაპირ ჰკითხეთ, ვისი ანგარიშზეა დომენი, ჰოსტინგი, SSL, ელფოსტა, ანალიტიკა და გადახდების პროვაიდერის პარამეტრები.
თუ გინდათ, შეგვიძლია 15–20 წუთიანი მოკლე ზარი და თქვენი არსებული შეთავაზებები ხაზ-ხაზ გავიაროთ. შეხვედრის ბოლოს გექნებათ მოკლე სია კონკრეტული დამაზუსტებელი კითხვების თითოეული შემსრულებლისთვის, ჩვენთვისაც მათ შორის.
