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

როდესაც 2020 წელს Wayfair-ში სამუშაო ვიშოვე, აღფრთოვანებული ვიყავი, რომ შევუერთდი მჭლე, უხერხულ გუნდს, რომელიც ინახავდა b2b ხელსაწყოს, რომელმაც უზარმაზარი ბიზნესი გამოიწვია. მე გამოვდიოდი როლიდან, სადაც ძირითადად ვმუშაობდი სილოში, ამიტომ განსაკუთრებით აღელვებული ვიყავი, რომ კვლავ დეველოპერული გუნდის ნაწილი ვიქნებოდი. თუმცა, ძალიან სწრაფად აღმოვაჩინე, რომ გუნდის დიდ ნაწილს იმხელა გამოცდილება ჰქონდა იმ ინსტრუმენტებში, რომლებსაც ჩვენ ვიყენებდით, რომ მათ ჰქონდათ წინასწარ განსაზღვრული ვარაუდი, რომ სხვა დეველოპერებს ჰქონდათ იგივე გამოცდილება, გამოცდილება და ცოდნა, რაც მათ ჰქონდათ. მთავარი პრობლემა ის იყო, რომ ინსტრუმენტები, რომლებზეც ჩვენ ვმუშაობდით, იყო შიდა და საკუთრებაში არსებული, ამიტომ ბევრმა ახალმა დეველოპერმა არ იცოდა ისინი ისევე, როგორც გამოცდილი დეველოპერები. ახლა ეს საერთოდ არ არის პრობლემა. თუმცა, ძალიან პრობლემური გახდა, როდესაც ჯირას ბილეთები შეიქმნა, პრიორიტეტული, შეფასებული და მცირე დეტალებით მინიჭება. რა თქმა უნდა, სათაური ხსნიდა ზოგად საკითხს და გამოცდილმა დეველოპერმა, რომელმაც ის დაწერა, ალბათ ზუსტად იცოდა, საიდან უნდა დაეწყო ცვლილებების შეტანა, მაგრამ ჩვენგან, ვინც უფრო ახალი იყო პლატფორმებზე, ძალიან ცოტა გვქონდა დასაწყებად. ამან გამოიწვია მასიური ხვრელები ეფექტურობაში, სადაც ჩვენ მუდმივად ვეძებდით უფრო შრომისუნარიან დეველოპერებს მეტი ინფორმაციის მისაღებად. ამ დაყენების კიდევ ერთი გვერდითი პროდუქტი იყო ის, რომ ჩვენი ტექნიკური დიზაინის შეხვედრები გაჭიანურდა, რადგან უფრო და უფრო მეტ ჩვენგანს ჰქონდა კითხვები ბილეთების შესახებ, რომლებიც წარმოდგენილი იყო შესაფასებლად. დეტალები გამუდმებით იკვეთებოდა საუბარში, მაგრამ არც ერთი არ იწერებოდა. ეს შეხვედრები გაგრძელდებოდა და ბილეთის მინიჭების შემდეგ იგივე კითხვები კვლავ ჩნდებოდა (თუ მიმღებს არ შეეძლო ჯადოსნურად გაიხსენოს კვირების წინანდელი საუბარი, სადაც თავდაპირველად კითხვები იყო დასმული). ეს სამუშაო პროცესი წარმოუდგენლად იმედგაცრუებული და არაეფექტური იყო. მაგრამ, არის იმედი! ცოტა ხნის შემდეგ, რაც ჩვენ გავაცნობიერეთ ეს საკითხი და განვიხილეთ, შეხვედრები უფრო მშვიდად მიმდინარეობდა, ნაკლები დრო დაჭირდა და იყო უფრო გავლენიანი. ბილეთები მდიდარი იყო დეტალებით და მარტივი მოქმედება, ტესტირება და დასრულება. აი, როგორ გავაკეთეთ ეს. პრობლემა: მოუმზადებელი ბილეთები და ხანგრძლივი შეხვედრები ჩვენი ტექნიკური დიზაინის შეხვედრები ხშირად იშლებოდა ბილეთებით, რომლებსაც საკმარისი დეტალები აკლდათ. დეველოპერები, დიზაინერები და სხვა დაინტერესებული მხარეები ძალიან დიდ დროს ხარჯავენ დამატებითი ინფორმაციის მოსაძიებლად ან ამოცანის ბუნდოვანი ასპექტების გარკვევაში. ამან არა მხოლოდ გაახანგრძლივა ჩვენი შეხვედრები, არამედ შეაფერხა განვითარება, რადგან მინიჭებული ბილეთები ხშირად ბრუნდებოდა უკან, რაც საჭიროებდა მეტ განმარტებას სამუშაოს გაგრძელებამდე. ამის შესანიშნავი მაგალითი შეიძლება იყოს ბილეთი, რომელიც მოხსენებული იყო უფლებამოსილი დეველოპერის მიერ, რომელიც უბრალოდ აცხადებდა: „ჩვენ უნდა დავაფიქსიროთ ფასი იატაკის სკუსებისთვის“. ცხადია, საკმარისი რაოდენობის ფონური ინფორმაციის გარეშე, ამ ბილეთის მიღებისას აბსოლუტურად ვერაფერს გააკეთებთ. რა პრობლემაა იატაკზე ფასზე? რა მოხდება მოსალოდნელი? აქვს თუ არა მნიშვნელობა სკუს რაოდენობას კალათაში? ბევრი ღია კითხვაა და ნამდვილად არ არის გზა, რომ დაიწყოთ მუშაობა შეხვედრის გარეშე. ბილეთის უკეთესი აღწერა შეიძლება იყოს. „სართულიანი სკუსები არის ნაყარი ფასით და ჩვენი სისტემა სათანადოდ არ ამუშავებს ფასებს/რაოდენობას მათემატიკას, როდესაც კალათაში არსებული რაოდენობა აჭარბებს ნაყარი ფასების ზღვრებს“. ახლა, აქ ჯერ კიდევ არ არის საკმარისი დეტალები, მაგრამ მაინც სწორად ხსნის პრობლემას. მე არ ვაპირებ ამ მაგალითის დაღლას, მაგრამ დეველოპერ(ებ)ს მოუწევს ამ ყველა დეტალის გააზრება განმეორებითი კითხვებით, საუბრებით და პრეზენტაციებით, სანამ არ გვექნება საკმარისი დეტალები ბილეთის შესაფასებლად ან სამუშაოდ, მიმდინარე მომენტიდან გამომდინარე. დავალება. ამან გამოიწვია ბევრი დაკარგული დრო, რომელიც ჩვენ, როგორც დეველოპერებმა, ვერ დავიბრუნეთ. გამოსავალი: ბილეთების შაბლონების დანერგვა ამ პრობლემის გადასაჭრელად, ჩვენ შევიმუშავეთ სტრუქტურირებული ბილეთების შაბლონების ნაკრები, რომელიც მორგებულია შესრულებული სამუშაოს ტიპზე. ეს შაბლონები უზრუნველყოფდა, რომ ყველა ბილეთი - იქნება ეს ხარვეზის ანგარიში, დიზაინის ცვლილება, ფუნქციის მოთხოვნა ან ოპტიმიზაციის დავალება - შეიცავდეს ყველა საჭირო ინფორმაციას განხილვამდე ან მინიჭებამდე. წესი მარტივი იყო: თუ შაბლონი ბოლომდე არ იყო შევსებული, ბილეთი არ იყო მზად შეხვედრისთვის ან განვითარებისთვის. შეცდომების მოხსენებები აღწერა: პრობლემის მოკლე, მაგრამ დეტალური აღწერა მოსალოდნელი ქცევა: უფრო დეტალური ახსნა, მათ შორის ეკრანის ანაბეჭდები ან Figma მითითებები, თუ როგორ უნდა მუშაობდეს ყველაფერი. ფაქტობრივი ქცევა: დეტალური აღწერა იმის შესახებ, თუ რა ხდება და რით განსხვავდება ის მოსალოდნელი ქცევისგან ხელახლა შექმნის ნაბიჯები: კონკრეტული, დეტალური, ნაბიჯები საკითხის ხელახლა შექმნის შესახებ. ეს უნდა მიუახლოვდეს ისე, რომ ვინმემ შეძლოს ახალი ინკოგნიტო ფანჯრის გახსნა ინსტრუმენტში და ხელახლა შექმნას საკითხი ნაბიჯებიდან გადახრის გარეშე. (არასავალდებულო) დეველოპერის შენიშვნები: ეს არის არასავალდებულო განყოფილება, სადაც შეგვიძლია შემოგთავაზოთ შემოთავაზებული მიდგომები, თუ უკვე გვაქვს კარგი წარმოდგენა, სად უნდა წავიდეს ეს ან როგორ უნდა განვითარდეს. ჩვენ არ გვინდა ვაიძულოთ დეველოპერები გარკვეული გზით გააკეთონ საქმეები, მაგრამ ნებისმიერი მითითება აქ დაგვეხმარება მოგვიანებით ბილეთების შესრულების დაჩქარებაში. (სურვილისამებრ, მაგრამ სასურველია) გარე ზემოქმედება: ეს არის ადგილი, სადაც ჩვენ მოვუწოდებთ ნებისმიერ გარე წყაროს, რომელმაც შეიძლება გავლენა მოახდინოს ამ სამუშაოზე. არის თუ არა გუნდები, რომლებმაც უკვე შექმნეს გამოსავალი ჩვენს API-ში შეცდომის გამო, რომლებსაც დასჭირდებათ შეტყობინება, როდესაც გამოვასწორებთ მას? ეყრდნობა თუ არა ეს შეცდომა სხვა გუნდებს/აპის/წყაროებს ინფორმაციისთვის, რამაც შეიძლება გავლენა მოახდინოს იმაზე, თუ რამდენ ხანს დასჭირდება ამის გამოსწორება? (არასავალდებულო) გავლენა: აქვს თუ არა ამას ცნობილი, გაზომვადი გავლენა გუნდზე ან ბიზნესზე? ეს ყოველთვის არ არის ცნობილი ან ადვილი გასაზომი, ამიტომ არის არჩევითი ველი. მაგრამ მნიშვნელოვანია იცოდეთ პრიორიტეტებისთვის, თუ ის არსებობს. დიზაინის ცვლილებები აღწერა: პრობლემის მოკლე, მაგრამ დეტალური აღწერა მოსალოდნელი ქცევა: სკრინშოტები ან Figma ბმულები მოსალოდნელი, შექმნილი ქცევისთვის. ფაქტობრივი ქცევა: სკრინშოტები ან ვიდეოები, სადაც დეტალურადაა აღწერილი, თუ რა ხდება რეალურად, ასევე იმის აღწერა, თუ რა ხდება და როგორ განსხვავდება ის მოსალოდნელი ქცევისგან (არასავალდებულო) ნაბიჯები ხელახლა შესაქმნელად: თუ ეს არის კონკრეტული ინტერფეისის ელემენტი, რომელიც მხოლოდ კონკრეტულ სიტუაციებში ჩნდება, ჩვენ უნდა ვიცოდეთ ზუსტად როგორ/როდის უნდა იყოს ეს, რათა ვიცოდეთ, როგორ შევამოწმოთ ჩვენი ცვლილებები. (არასავალდებულო) დეველოპერის შენიშვნები: ეს არის არასავალდებულო განყოფილება, სადაც შეგვიძლია შემოგთავაზოთ შემოთავაზებული მიდგომები, თუ უკვე გვაქვს კარგი წარმოდგენა, სად უნდა წავიდეს ეს ან როგორ უნდა განვითარდეს. ჩვენ არ გვინდა ვაიძულოთ დეველოპერები გარკვეული გზით გააკეთონ საქმეები, მაგრამ ნებისმიერი მითითება აქ დაგვეხმარება მოგვიანებით ბილეთების შესრულების დაჩქარებაში. (არასავალდებულო) გავლენა: აქვს თუ არა ამას ცნობილი, გაზომვადი გავლენა გუნდზე ან ბიზნესზე? ეს ყოველთვის არ არის ცნობილი ან ადვილი გასაზომი, ამიტომ არის არჩევითი ველი. მაგრამ მნიშვნელოვანია იცოდეთ პრიორიტეტებისთვის, თუ ის არსებობს. ფუნქციის მოთხოვნები აღწერა: სრული დეტალური სურათი იმის შესახებ, თუ რა არის ფუნქცია. როგორ უნდა ფუნქციონირებდეს, რა არის მოსალოდნელი შეყვანები/გამომავლები და ა.შ. ჩვენ ასევე უნდა შევიტანოთ ნებისმიერი დასაბუთება, თუ რატომ არის ეს ფუნქცია მოთხოვნილი აქ. დეველოპერის შენიშვნები: დეველოპერმა უნდა გამოიყენოს ეს განყოფილება, რათა უზრუნველყოს მითითებები ცნობილ ჩარჩოებზე/ნიმუშებზე, რომლებიც უნდა იქნას გამოყენებული, რათა შეუფერხებლად მოერგოს ჩვენს კოდურ ბაზას. ჩვენ არ გვინდა ვაიძულოთ დეველოპერები დაწერონ კოდი რაიმე ფორმით, მაგრამ ნებისმიერი მითითება აქ ბილეთების შესრულებას უფრო აჩქარებს და უფრო გამარტივებულ PR საუბრებს გამოიწვევს. (სურვილისამებრ, მაგრამ სასურველია) მაკეტები: თუ ჩვენ გვაქვს მაგალითები payloads, ეკრანის ანაბეჭდები, ან Figma მითითებები, რომლებიც უნდა ხელმძღვანელობდეს განვითარებას, ეს ყველაფერი უნდა იყოს ჩართული აქ. (სურვილისამებრ, მაგრამ სასურველია) გარე ზემოქმედება: ეს არის ადგილი, სადაც ჩვენ მოვუწოდებთ ნებისმიერ გარე წყაროს, რომელმაც შეიძლება გავლენა მოახდინოს ამ სამუშაოზე. არის თუ არა გუნდები, რომლებმაც უკვე შექმნეს გამოსავალი ჩვენს API-ში გამოტოვებული ფუნქციისთვის, რომლებსაც დასჭირდებათ შეტყობინება მისი დამატებისას? ეყრდნობა თუ არა ეს ფუნქცია სხვა გუნდებს/აპის/წყაროებს ინფორმაციისთვის, რამაც შეიძლება გავლენა მოახდინოს იმაზე, თუ რამდენ ხანს დასჭირდება ამის შექმნა? (არასავალდებულო) გავლენა: აქვს თუ არა ამას ცნობილი, გაზომვადი გავლენა გუნდზე ან ბიზნესზე? ეს ყოველთვის არ არის ცნობილი ან ადვილი გასაზომი, ამიტომ არის არჩევითი ველი. მაგრამ მნიშვნელოვანია იცოდეთ პრიორიტეტებისთვის, თუ ის არსებობს. ოპტიმიზაციის ამოცანები აღწერა: პრობლემის მოკლე, მაგრამ დეტალური აღწერა ამჟამინდელი მდგომარეობა: უფრო დეტალური ახსნა, თუ როგორ მუშაობს კოდი ამჟამად და რატომ არის არაეფექტური. სასურველი სახელმწიფო: დეტალური აღწერა იმისა, თუ რის გამოსწორებას ვაპირებთ ამ ოპტიმიზაციით, რა მიზნების მიღწევას ვცდილობთ დეველოპერის შენიშვნები: ეს არის სახელმძღვანელო დეველოპერისგან, რომელიც ამტკიცებს ოპტიმიზაციის საჭიროებას. ეს უნდა გამოიძახოს კონკრეტული ფაილები და ტესტები, რომლებიც საჭიროებს რედაქტირებას, ისევე როგორც კონკრეტულ სექციებს, რომლებიც, ჩვენი აზრით, შემაფერხებელია შესრულებაში ან იწვევს დაბნეულობას. : ტესტირება შენიშვნები იმის შესახებ, თუ როგორ შეიძლება ამ ოპტიმიზაციის დადასტურება ან დამოწმება. ჩვენ არა მხოლოდ უნდა დავინახოთ, რომ ჩვენ რეალურად მივიღეთ რაღაც ამ პროცესიდან (და შეიძლება იყოს ის, რითაც შეგვიძლია ვიტრაბახოთ), არამედ უნდა დავადასტუროთ, რომ ცვლილებები არ მოახდენდა გავლენას ცნობილ გარე პროცესებზე, რომლებიც ეყრდნობოდა კოდს. შეიცვალა. გარე ზემოქმედება: ეს არის ადგილი, სადაც ჩვენ მოვუწოდებთ ნებისმიერ გარე წყაროს, რომელმაც შეიძლება გავლენა მოახდინოს ამ სამუშაოზე. ეყრდნობა თუ არა ეს ფუნქცია სხვა გუნდებს/აპის/წყაროებს ინფორმაციისთვის, რამაც შეიძლება გავლენა მოახდინოს იმაზე, თუ რამდენ ხანს დასჭირდება ამის შექმნა ან ტესტირება? გავლენა: აქვს თუ არა ამას ცნობილი, გაზომვადი გავლენა გუნდზე ან ბიზნესზე? ეს ყოველთვის არ არის ცნობილი ან ადვილი გასაზომი, მაგრამ იმისათვის, რომ გავამართლოთ რეფაქტორი ან ოპტიმიზაცია, ჩვენ უნდა გვქონდეს ეს ინფორმაცია. შაბლონების გავლენა შედეგები მყისიერი იყო. ჩვენ სწრაფად დავინახეთ, რომ შეგვეძლო დაახლოებით 3-ჯერ მეტი ბილეთის გავლა ერთსაათიანი ტექნიკური დიზაინის შეხვედრაზე, ვიდრე ადრე. ასევე, დისკუსიები, რომლებიც ამ შეხვედრებზე გვქონდა, უფრო მომგებიანი და გავლენიანი იყო. ჩვენ დროს ვხარჯავდით, რომ გამოგვეხმაურებინა ზღვრული შემთხვევები, ზემოქმედების ქვეშ მყოფი გუნდები და პოტენციური სანახაობების საცობები ან შეფერხებები ამ პროცესში, ვამზადებდით დეველოპერებს სამუშაოსთვის, ნაცვლად იმისა, რომ მთელი ჩვენი დრო დაგვეხარჯა მეტი დეტალების გასაგებად. ჩვენ ასევე ვაიძულებდით საკუთარ თავს შევიტანოთ ნიმუში, სადაც ჩვენ ჩავწერეთ ყველა ეს გამოხმაურება ბილეთში ან აღწერაში ან კომენტარებში. შაბლონები მუდმივ შეხსენებას წარმოადგენდა, რომ ეს დეტალები მნიშვნელოვანი იყო და რომ ისინი უნდა არსებობდეს და ადვილად იპოვონ. გარკვეულწილად, ეს შაბლონები ხელახლა ავარჯიშებდნენ ჩვენს ტვინს ამ ბილეთების მიმართ დოკუმენტაციის პირველ მიდგომაში, იმის უზრუნველსაყოფად, რომ ვინც აიღებს ბილეთს, იქნება ეს უმცროსი დეველოპერი თუ გამოცდილი ინჟინერი, საკმარისი ინფორმაცია ექნებოდა მაღალი ხარისხის კოდის დასაწერად. . შემდეგ, ჩვენ შევამჩნიეთ, რომ ჩვენი განვითარების ციკლები იყო უფრო ლაკონური, ჩვენი შეფასებები იყო უფრო ზუსტი და ჩვენ ვაღწევდით სასურველ 100%-იან ნიშნულს სპრინტებზე ბევრად უფრო ხშირად, ვიდრე ოდესმე გვქონია. ჩვენ შევძელით ჩვენი დაფის გასუფთავება თითქმის თანმიმდევრულად. ეს არ არის მხოლოდ მნიშვნელოვანი ბიზნესისთვის, რადგან ისინი იღებდნენ განახლებებს, როდესაც ჩვენ ვუთხარით, რომ მიიღებდნენ მათ, არამედ ეს იყო გუნდისთვის ნდობის უზარმაზარი გამაძლიერებელი, რადგან თქვენ მუდმივად აყენებთ საკუთარ თავს წარმატებულ მდგომარეობაში. ჩვენმა დაინტერესებულმა მხარეებმა დაინახეს ჩვენი გაუმჯობესებული ეფექტურობა და გამტარუნარიანობა და მოიპოვეს მეტი ნდობა ჩვენი გუნდისა და ჩვენი პროცესის მიმართ. მათ ასევე შენიშნეს, რომ ჩვენი კოდი უფრო მაღალი ხარისხის იყო, რადგან ჩვენ შეგვეძლო მეტი დრო დაგვეხარჯა რეალურ პრობლემაზე. თავიდანვე ვიცოდით, რომ ეს გააუმჯობესებდა ჩვენს ცხოვრებას, როგორც დეველოპერებს, მაგრამ არ გვესმოდა, რამდენად დადებით გავლენას მოახდენდა ეს ჩვენს ბიზნეს პარტნიორებზეც. ძირითადი წამყვანები სხვა გუნდებისთვის თუ ფიქრობთ, რომ თქვენი გუნდი გამუდმებით არის დამძიმებული დაზიანებების ნაკლებობით, შესაძლოა ღირდეს გამოძიების გაკეთება, შეიძლება თუ არა თქვენთვის სტრუქტურირებული ბილეთების შაბლონების შექმნა. მნიშვნელოვანია გავითვალისწინოთ, რომ ამას დეველოპერისთვის დამატებითი დრო სჭირდება იმისათვის, რომ ბილეთები საკმარისად დეტალურად განასახიეროს მოქმედებაზე. მე მჯერა, რომ ეს არის გამართლებული ღირებულება და ეს იწვევს უზარმაზარ დაზოგვას გრძელვადიან პერსპექტივაში, რადგან ეს მნიშვნელოვნად აუმჯობესებს თქვენს სამუშაო პროცესებს, მაგრამ მნიშვნელოვანია აღინიშნოს, რომ ეს ცვლილებები არ ხდება მხოლოდ უფასოდ. ვიღაცამ უნდა დაუთმოს დრო კვლევის ჩასატარებლად და მაღალი ხარისხის ბილეთის დაწერას და ის, სავარაუდოდ, თქვენი განვითარების გუნდი იქნება. როგორც ითქვა, ადვილი მისახვედრია, რამდენად დიდი გამარჯვება შეიძლება იყოს ეს გუნდისთვის. დასაწყებად მე გირჩევთ რამდენიმე მოკლე ნაბიჯს. , შეაფასეთ, ნამდვილად გაქვთ თუ არა პრობლემა. ზოგჯერ ერთი ან ორი დეველოპერი უჭირს დოკუმენტაციას ან ცოდნის გადაცემას, მაგრამ ეს არ არის თქვენი ბილეთების სრულმასშტაბიანი პრობლემის მაჩვენებელი. შესაძლოა, სხვა საკითხებმა, როგორიცაა უკეთესი გაფორმება ან დოკუმენტაცია, შეიძლება გადაჭრას ზოგიერთი საკითხი. პირველ რიგში თუ თქვენ აღმოაჩენთ, რომ ეს არის ფართოდ გავრცელებული საკითხი, რომელიც საჭიროებს გადაწყვეტას, შემდეგი ნაბიჯი არის კატეგორიზაცია, თუ რა ტიპის ბილეთებს იღებთ ჩვეულებრივ და რა ტიპის ინფორმაციაა საჭირო თითოეულში. აშკარა კანდიდატები არის შეცდომები და მახასიათებლები, თუმცა თქვენი კომპანიის ბიზნესის ბუნებიდან გამომდინარე, შესაძლოა გქონდეთ სხვა ტიპის ბილეთები, რომლებიც მუდმივად მიედინება თქვენს სისტემაში და აქვთ განსხვავებული საჭიროებები. შესაძლოა, თქვენი გუნდი მართავს ETL მილსადენს და თქვენ უნდა იცოდეთ, რა შეყვანის/გამოსვლების გავლენას ახდენს ამასთან დაკავშირებულ ბილეთებზე. შესაძლოა, თქვენი გუნდი ფლობს SDK-ს და მასთან დაკავშირებულ ბილეთებს განსაკუთრებული/პრიორიტეტული წესით უნდა დამუშავდეს და უნდა შეიცავდეს რა ბიზნეს ფუნქციებზე შეიძლება გავლენა იქონიოს ცვლილებამ? იცოდეთ თქვენი გუნდი და მათი მოთხოვნები, რათა ზუსტად განსაზღვროთ რა ტიპის შაბლონებია საჭირო. მეორე, როგორც კი თქვენ გექნებათ ყველა ეს ინფორმაცია, განათავსეთ იგი წერილობით სადმე გაზიარებულ ადგილას, რომელზეც ყველას აქვს წვდომა. შესაძლოა, ეს არის გაზიარებული დოკუმენტი, ან ვიკი გვერდი, რომელსაც გუნდი მართავს და აქვს წვდომა, ან შესაძლოა თქვენ თავად შექმნათ შაბლონები ჯირაში და აიძულოთ ხალხი გამოიყენონ ისინი. როგორიც არ უნდა იყოს თქვენი მიდგომა, თქვენ უნდა მიიღოთ შესყიდვა გუნდისა და დეველოპერებისგან, რაც ნიშნავს, რომ მათ უნდა შეეძლოთ ამის დანახვა. ეს არის ერთ-ერთი ყველაზე მნიშვნელოვანი ნაბიჯი, რადგან ეს პროცესი არ გაგრძელდება, თუ თქვენ არ გაქვთ 100% ყიდვა ყველასგან, ვინც დაწერს ბილეთებს. წარუდგინეთ ეს შაბლონები თქვენს გუნდს, შეაგროვეთ გამოხმაურება, ახსენით, როგორ ფიქრობთ, როგორ იმოქმედებს ეს ახალი პროცესი თქვენზე და თქვენს დაინტერესებულ მხარეებზე. დარწმუნდით, რომ გუნდში ყველა კომფორტულია ახალი პროცესით. შემდეგ, , თქვენ უნდა განახორციელოთ ეს ცვლილებები. საკმარისი დეტალების გარეშე წარმოდგენილი ბილეთები დაუყოვნებლივ უნდა გადააგდოთ უკან, განხილვის გარეშე. მნიშვნელოვანია მკაცრად დაიცვან შაბლონის მითითებები, წინააღმდეგ შემთხვევაში ადამიანები ყოველთვის იპოვიან მიზეზებს მის გადასაჭრელად. „ეს საკითხი ზედმეტად კრიტიკულია, დრო არ მაქვს რომ დავწერო“ არის ჩვეულებრივი საჩივარი, რომელსაც მივიღებთ. თუმცა, თუ იყოთ მკაცრი შაბლონის საჭიროების მიმართ და იმუშაოთ ადამიანებთან, რომლებიც ცდილობენ მის გადალახვას, თქვენ საბოლოოდ მოიგებთ მათ. და ბოლოს Wayfair-ზე ჩვენ ვნახეთ უზარმაზარი გაუმჯობესება ჩვენი გუნდის პროცესში, ისევე როგორც მორალი ზემოთ ჩამოთვლილი მცირე ცვლილებების შეტანით. იმედი მაქვს, რომ ეს თქვენს გუნდსაც დაეხმარება.