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

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

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

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

პრობლემა: მოუმზადებელი ბილეთები და ხანგრძლივი შეხვედრები

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

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

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

„სართულიანი სკუსები არის ნაყარი ფასით და ჩვენი სისტემა სათანადოდ არ ამუშავებს ფასებს/რაოდენობას მათემატიკას, როდესაც კალათაში არსებული რაოდენობა აჭარბებს ნაყარი ფასების ზღვრებს“.

ახლა, აქ ჯერ კიდევ არ არის საკმარისი დეტალები, მაგრამ მაინც სწორად ხსნის პრობლემას.

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

გამოსავალი: ბილეთების შაბლონების დანერგვა

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

შეცდომების მოხსენებები

დიზაინის ცვლილებები

ფუნქციის მოთხოვნები

ოპტიმიზაციის ამოცანები

შაბლონების გავლენა

შედეგები მყისიერი იყო.

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

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

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

ძირითადი წამყვანები სხვა გუნდებისთვის

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

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

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

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

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

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

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