สิ่งที่ช่วยให้เราปรับตัวเข้ากับการซื้อขายออนไลน์ในเงื่อนไขใหม่ได้อย่างรวดเร็ว

Hi!

ฉันชื่อมิคาอิล เป็นรองผู้อำนวยการฝ่ายไอทีของบริษัท Sportmaster ฉันต้องการแบ่งปันเรื่องราววิธีที่เราจัดการกับความท้าทายที่เกิดขึ้นระหว่างการแพร่ระบาด

ในวันแรกของความเป็นจริงใหม่ รูปแบบการซื้อขายออฟไลน์ตามปกติของ Sportmaster หยุดนิ่ง และภาระในช่องทางออนไลน์ของเรา ซึ่งโดยหลักแล้วในแง่ของการจัดส่งไปยังที่อยู่ของลูกค้า เพิ่มขึ้น 10 เท่า ในเวลาเพียงไม่กี่สัปดาห์ เราได้เปลี่ยนธุรกิจออฟไลน์ขนาดยักษ์ให้เป็นธุรกิจออนไลน์ และปรับบริการให้ตรงกับความต้องการของลูกค้าของเรา

โดยพื้นฐานแล้ว สิ่งที่เป็นการดำเนินการด้านข้างของเราจึงกลายมาเป็นธุรกิจหลักของเรา ความสำคัญของทุกการสั่งซื้อออนไลน์เพิ่มขึ้นอย่างมาก จำเป็นต้องเก็บเงินทุกรูเบิลที่ลูกค้านำมาให้กับบริษัท 

เพื่อตอบสนองต่อคำขอของลูกค้าอย่างรวดเร็ว เราได้เปิดศูนย์ติดต่อเพิ่มเติมที่สำนักงานใหญ่ของบริษัท และขณะนี้สามารถรับสายได้ประมาณ 285 สายต่อสัปดาห์ ในเวลาเดียวกัน เราได้ย้ายร้านค้า 270 แห่งไปใช้รูปแบบการดำเนินงานแบบใหม่แบบไร้การสัมผัสและปลอดภัย ซึ่งช่วยให้ลูกค้าสามารถรับคำสั่งซื้อและพนักงานเพื่อรักษางานของพวกเขาได้

ในระหว่างกระบวนการเปลี่ยนแปลง เราพบปัญหาหลักสองประการ ประการแรก ภาระในแหล่งข้อมูลออนไลน์ของเราเพิ่มขึ้นอย่างมาก (Sergey จะบอกคุณว่าเราจัดการกับเรื่องนี้อย่างไร) ประการที่สอง การไหลเวียนของการดำเนินงานที่เกิดขึ้นได้ยาก (ก่อนยุคโควิด) เพิ่มขึ้นหลายเท่า ส่งผลให้ต้องใช้ระบบอัตโนมัติที่รวดเร็วจำนวนมาก เพื่อแก้ไขปัญหานี้ เราต้องถ่ายโอนทรัพยากรจากพื้นที่ที่เคยเป็นพื้นที่หลักอย่างรวดเร็ว เอเลน่าจะบอกคุณว่าเราจัดการกับเรื่องนี้อย่างไร

การดำเนินงานบริการออนไลน์

Kolesnikov Sergey รับผิดชอบการดำเนินงานของร้านค้าออนไลน์และไมโครเซอร์วิส

นับตั้งแต่วินาทีที่ร้านค้าปลีกของเราเริ่มปิดไม่ให้ผู้มาเยี่ยมชม เราก็เริ่มบันทึกตัวชี้วัดที่เพิ่มขึ้น เช่น จำนวนผู้ใช้ จำนวนคำสั่งซื้อในแอปพลิเคชันของเรา และจำนวนคำขอไปยังแอปพลิเคชัน 

จำนวนคำสั่งซื้อตั้งแต่วันที่ 18 มีนาคม ถึง 31 มีนาคมจำนวนคำขอไปยังไมโครเซอร์วิสการชำระเงินออนไลน์จำนวนการสั่งซื้อบนเว็บไซต์

ในกราฟแรกเราจะเห็นว่าเพิ่มขึ้นประมาณ 14 เท่า ในกราฟที่สอง - 4 เท่า เราถือว่าการวัดเวลาตอบสนองของแอปพลิเคชันของเราเป็นสิ่งที่บ่งชี้ได้มากที่สุด 

ในกราฟนี้ เราเห็นการตอบสนองของแนวหน้าและการใช้งาน และสำหรับตัวเราเองแล้ว เราพิจารณาแล้วว่าเราไม่ได้สังเกตเห็นการเติบโตใดๆ เช่นนี้

สาเหตุหลักมาจากการที่เราเริ่มทำงานเตรียมการเมื่อปลายปี 2019 ขณะนี้บริการของเราถูกสงวนไว้ และรับประกันความทนทานต่อข้อผิดพลาดในระดับเซิร์ฟเวอร์จริง ระบบเวอร์ชวลไลเซชัน นักเทียบท่า และบริการในนั้น ในเวลาเดียวกัน ความจุของทรัพยากรเซิร์ฟเวอร์ของเราช่วยให้เราทนต่อการโหลดจำนวนมากได้

เครื่องมือหลักที่ช่วยเราในเรื่องทั้งหมดนี้ก็คือระบบการติดตามของเรา จริงอยู่ จนกระทั่งเมื่อไม่นานมานี้ เรายังไม่มีระบบเดียวที่จะช่วยให้เรารวบรวมตัววัดในทุกเลเยอร์ ตั้งแต่ระดับอุปกรณ์ทางกายภาพและฮาร์ดแวร์ไปจนถึงระดับตัววัดทางธุรกิจ 

อย่างเป็นทางการมีการตรวจสอบในบริษัท แต่ตามกฎแล้ว มีการกระจายตัวและอยู่ในขอบเขตความรับผิดชอบของแผนกเฉพาะ ในความเป็นจริง เมื่อเหตุการณ์เกิดขึ้น เราแทบไม่เคยมีความเข้าใจร่วมกันในสิ่งที่เกิดขึ้นเลย ไม่มีการสื่อสาร และบ่อยครั้งสิ่งนี้นำไปสู่การวิ่งเป็นวงกลมเพื่อค้นหาและแยกปัญหาเพื่อจะได้รับการแก้ไข

เมื่อถึงจุดหนึ่ง เราคิดและตัดสินใจว่าเราอดทนมามากพอแล้ว - เราต้องการระบบที่เป็นหนึ่งเดียวจึงจะมองเห็นภาพรวมทั้งหมดได้ เทคโนโลยีหลักที่รวมอยู่ในสแต็กของเรา ได้แก่ Zabbix ที่เป็นศูนย์จัดเก็บข้อมูลการแจ้งเตือนและเมตริก, Prometheus สำหรับการรวบรวมและจัดเก็บเมตริกแอปพลิเคชัน, Stack ELK สำหรับการบันทึกและจัดเก็บข้อมูลจากระบบการตรวจสอบทั้งหมด รวมถึง Grafana สำหรับการแสดงภาพ, Swagger, Docker และสิ่งที่เป็นประโยชน์อื่น ๆ ที่คุณคุ้นเคย

ในเวลาเดียวกัน เราไม่เพียงแต่ใช้เทคโนโลยีที่มีอยู่ในตลาดเท่านั้น แต่ยังพัฒนาเทคโนโลยีบางอย่างของเราเองด้วย ตัวอย่างเช่น เราให้บริการสำหรับการรวมระบบเข้าด้วยกัน ซึ่งก็คือ API บางประเภทสำหรับการรวบรวมตัวชี้วัด นอกจากนี้ เรากำลังพัฒนาระบบการตรวจสอบของเราเอง - ในระดับตัวชี้วัดทางธุรกิจที่เราใช้การทดสอบ UI และยังมีบอทใน Telegram เพื่อแจ้งเตือนทีมงานอีกด้วย

นอกจากนี้เรายังพยายามทำให้ทีมสามารถเข้าถึงระบบการตรวจสอบได้ เพื่อให้พวกเขาสามารถจัดเก็บและทำงานกับตัววัดของตนเองได้อย่างอิสระ รวมถึงการตั้งค่าการแจ้งเตือนสำหรับตัววัดแคบบางตัวที่ไม่ได้ใช้กันอย่างแพร่หลาย 

ตลอดทั้งระบบ เรามุ่งมั่นในเชิงรุกและการแปลเหตุการณ์ให้เหมาะสมโดยเร็วที่สุด นอกจากนี้ จำนวนไมโครเซอร์วิสและระบบของเราได้เพิ่มขึ้นอย่างมากเมื่อเร็วๆ นี้ และจำนวนการบูรณาการก็เพิ่มขึ้นตามไปด้วย และในฐานะส่วนหนึ่งของการเพิ่มประสิทธิภาพกระบวนการวินิจฉัยเหตุการณ์ในระดับบูรณาการ เรากำลังพัฒนาระบบที่ช่วยให้คุณสามารถดำเนินการตรวจสอบข้ามระบบและแสดงผลลัพธ์ ซึ่งช่วยให้คุณค้นหาปัญหาหลักที่เกี่ยวข้องกับการนำเข้าและการโต้ตอบของระบบด้วย กันและกัน. 

แน่นอนว่าเรายังมีพื้นที่ให้เติบโตและพัฒนาในแง่ของระบบปฏิบัติการ และเรากำลังดำเนินการเรื่องนี้อย่างแข็งขัน คุณสามารถอ่านเพิ่มเติมเกี่ยวกับระบบการตรวจสอบของเรา ที่นี่. 

การทดสอบทางเทคนิค 

Orlov Sergey หัวหน้าศูนย์ความสามารถด้านการพัฒนาเว็บและอุปกรณ์เคลื่อนที่

นับตั้งแต่การปิดร้านค้าจริงเริ่มขึ้น เราได้เผชิญกับความท้าทายต่างๆ จากมุมมองของการพัฒนา ก่อนอื่นโหลดไฟกระชากเช่นนี้ เป็นที่ชัดเจนว่าหากไม่มีการใช้มาตรการที่เหมาะสม เมื่อมีการใช้โหลดสูงกับระบบ ระบบก็อาจกลายเป็นฟักทองที่มีเสียงดังปัง หรือประสิทธิภาพลดลงโดยสิ้นเชิง หรือแม้กระทั่งสูญเสียฟังก์ชันการทำงานไป

ด้านที่สอง ซึ่งไม่ค่อยชัดเจนนักก็คือ ระบบภายใต้ภาระงานสูงต้องได้รับการเปลี่ยนแปลงอย่างรวดเร็ว โดยปรับให้เข้ากับการเปลี่ยนแปลงในกระบวนการทางธุรกิจ บางครั้งหลายครั้งต่อวัน หลายบริษัทมีกฎเกณฑ์ว่าหากมีกิจกรรมทางการตลาดมากก็ไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ กับระบบ ไม่มีเลย ปล่อยให้มันทำงานตราบใดที่มันทำงาน

และโดยพื้นฐานแล้วเรามี Black Friday ที่ไม่สิ้นสุด ในระหว่างนี้เราจำเป็นต้องเปลี่ยนระบบ และข้อผิดพลาด ปัญหา หรือความล้มเหลวใดๆ ในระบบจะส่งผลให้ธุรกิจต้องเสียค่าใช้จ่ายอย่างมาก

เมื่อมองไปข้างหน้า ฉันจะบอกว่าเราสามารถรับมือกับการทดสอบเหล่านี้ได้ ทุกระบบทนทานต่อโหลด ได้รับการปรับขนาดอย่างง่ายดาย และเราไม่พบข้อผิดพลาดทางเทคนิคทั่วโลกเลย

มีสี่เสาหลักที่ความสามารถของระบบในการทนต่อโหลดไฟกระชากสูงอยู่ สิ่งแรกคือการตรวจสอบ ซึ่งคุณอ่านเกี่ยวกับด้านบน หากไม่มีระบบตรวจสอบในตัว แทบจะเป็นไปไม่ได้เลยที่จะพบปัญหาคอขวดของระบบ ระบบการตรวจติดตามที่ดีก็เหมือนกับเสื้อผ้าประจำบ้านที่ควรสวมใส่สบายและปรับให้เหมาะกับคุณ

ด้านที่สองคือการทดสอบ เราให้ความสำคัญกับประเด็นนี้อย่างจริงจัง: เราเขียนหน่วยแบบคลาสสิก การทดสอบการรวม การทดสอบโหลด และอื่นๆ อีกมากมายสำหรับแต่ละระบบ เรากำลังเขียนกลยุทธ์การทดสอบด้วย และในขณะเดียวกันก็พยายามเพิ่มระดับการทดสอบจนถึงจุดที่เราไม่ต้องการการตรวจสอบด้วยตนเองอีกต่อไป

เสาหลักที่สามคือไปป์ไลน์ CI/CD กระบวนการสร้าง การทดสอบ และการปรับใช้แอปพลิเคชันควรเป็นอัตโนมัติมากที่สุด และไม่ควรมีการแทรกแซงด้วยตนเอง หัวข้อของไปป์ไลน์ CI/CD ค่อนข้างลึกซึ้ง และฉันจะพูดถึงมันเพียงสั้นๆ เท่านั้น เป็นเรื่องที่น่าสังเกตว่าเรามีรายการตรวจสอบไปป์ไลน์ CI/CD ซึ่งทีมผลิตภัณฑ์แต่ละทีมต้องดำเนินการด้วยความช่วยเหลือจากศูนย์สมรรถนะ

และนี่คือรายการตรวจสอบ

ด้วยวิธีนี้จึงบรรลุเป้าหมายหลายประการ นี่คือการกำหนดเวอร์ชัน API และการสลับคุณลักษณะเพื่อหลีกเลี่ยง Train Release และบรรลุความครอบคลุมของการทดสอบต่างๆ ในระดับที่การทดสอบเป็นแบบอัตโนมัติเต็มรูปแบบ การปรับใช้เป็นไปอย่างราบรื่น และอื่นๆ

เสาหลักที่สี่คือหลักการทางสถาปัตยกรรมและโซลูชันทางเทคนิค เราสามารถพูดคุยเกี่ยวกับสถาปัตยกรรมได้มากมายเป็นเวลานาน แต่ฉันต้องการเน้นหลักการสองสามข้อที่ฉันอยากจะเน้น

ขั้นแรก คุณต้องเลือกเครื่องมือพิเศษสำหรับงานเฉพาะ ใช่ ฟังดูชัดเจน และชัดเจนว่าควรใช้ค้อนตอกตะปู และนาฬิกาข้อมือควรถอดประกอบด้วยไขควงพิเศษ แต่ในยุคของเรา เครื่องมือจำนวนมากพยายามทำให้เป็นสากลเพื่อให้ครอบคลุมกลุ่มผู้ใช้สูงสุด: ฐานข้อมูล แคช เฟรมเวิร์ก และส่วนที่เหลือ ตัวอย่างเช่น หากคุณใช้ฐานข้อมูล MongoDB ฐานข้อมูลจะทำงานกับธุรกรรมหลายเอกสาร และฐานข้อมูล Oracle จะทำงานกับ json และดูเหมือนว่าทุกอย่างจะใช้ได้กับทุกสิ่ง แต่หากเรายืนหยัดในเรื่องผลิตภาพ เราจำเป็นต้องเข้าใจจุดแข็งและจุดอ่อนของแต่ละเครื่องมืออย่างชัดเจน และใช้สิ่งที่เราจำเป็นสำหรับประเภทงานของเรา 

ประการที่สอง เมื่อออกแบบระบบ ความซับซ้อนที่เพิ่มขึ้นแต่ละครั้งจะต้องได้รับการพิสูจน์ เราต้องจำสิ่งนี้ไว้เสมอ ทุกคนรู้หลักการของการมีเพศสัมพันธ์ต่ำ ฉันเชื่อว่าควรจะนำไปใช้ในระดับของบริการเฉพาะและในระดับของระบบทั้งหมดและในระดับภูมิทัศน์ทางสถาปัตยกรรม ความสามารถในการปรับขนาดส่วนประกอบของระบบแต่ละส่วนในแนวนอนตามเส้นทางโหลดก็มีความสำคัญเช่นกัน หากคุณมีความสามารถนี้ การปรับขนาดจะไม่ใช่เรื่องยาก

เมื่อพูดถึงโซลูชันทางเทคนิค เราได้ขอให้ทีมผลิตภัณฑ์เตรียมชุดคำแนะนำ แนวคิด และโซลูชันชุดใหม่ ซึ่งพวกเขานำไปใช้เพื่อเตรียมพร้อมสำหรับภาระงานคลื่นลูกถัดไป

เคชิ

มีความจำเป็นต้องเข้าใกล้การเลือกแคชในเครื่องและแคชแบบกระจายอย่างมีสติ บางครั้งการใช้ทั้งสองอย่างภายในระบบเดียวกันก็สมเหตุสมผล ตัวอย่างเช่น เรามีระบบที่ข้อมูลบางส่วนเป็น Showcase Cache กล่าวคือ แหล่งที่มาของการอัปเดตอยู่ด้านหลังระบบ และระบบจะไม่เปลี่ยนแปลง ข้อมูลนี้ สำหรับแนวทางนี้ เราใช้ Caffeine Cache ในเครื่อง 

และมีข้อมูลที่ระบบเปลี่ยนแปลงอย่างแข็งขันระหว่างการทำงานและที่นี่เราใช้แคชแบบกระจายกับ Hazelcast อยู่แล้ว แนวทางนี้ช่วยให้เราใช้ประโยชน์จากแคชแบบกระจายได้ในจุดที่จำเป็นจริงๆ และลดต้นทุนการบริการในการหมุนเวียนข้อมูลคลัสเตอร์ Hazelcast ในที่ที่เราสามารถทำได้โดยไม่ต้องใช้แคช เราได้เขียนมากมายเกี่ยวกับแคช ที่นี่ и ที่นี่.

นอกจากนี้ การเปลี่ยนซีเรียลไลเซอร์เป็น Kryo ใน Hazelcast ยังช่วยให้เราได้รับการส่งเสริมที่ดีอีกด้วย และการเปลี่ยนจาก ReplicatedMap เป็น IMap + Near Cache ใน Hazelcast ทำให้เราสามารถลดการเคลื่อนไหวของข้อมูลทั่วทั้งคลัสเตอร์ได้ 

คำแนะนำเล็กน้อย: ในกรณีที่แคชจำนวนมากใช้ไม่ได้ บางครั้งก็ใช้กลยุทธ์ในการอุ่นแคชที่สองแล้วสลับไปใช้แคชนั้นได้ ดูเหมือนว่าด้วยวิธีนี้เราควรได้รับการใช้หน่วยความจำเป็นสองเท่า แต่ในทางปฏิบัติ ในระบบเหล่านั้นที่มีการปฏิบัติเช่นนี้ การใช้หน่วยความจำลดลง

กองปฏิกิริยา

เราใช้สแต็กปฏิกิริยาในระบบจำนวนมาก ในกรณีของเรา นี่คือ Webflux หรือ Kotlin ที่มี coroutines สแต็กปฏิกิริยานั้นดีเป็นพิเศษเมื่อเราคาดว่าการดำเนินการอินพุต-เอาท์พุตจะช้า ตัวอย่างเช่น การเรียกใช้บริการที่ช้า การทำงานกับระบบไฟล์หรือระบบจัดเก็บข้อมูล

หลักการที่สำคัญที่สุดคือการหลีกเลี่ยงการบล็อคการโทร เฟรมเวิร์กแบบรีแอกทีฟมีเธรดบริการสดจำนวนเล็กน้อยที่ทำงานภายใต้ประทุน หากเราปล่อยให้ตัวเองทำการบล็อกการโทรโดยตรงโดยไม่ระมัดระวัง เช่น การเรียกไดรเวอร์ JDBC ระบบก็จะหยุดทำงานทันที 

พยายามเปลี่ยนข้อผิดพลาดให้เป็นข้อยกเว้นรันไทม์ของคุณเอง โฟลว์ที่แท้จริงของการดำเนินการโปรแกรมจะเปลี่ยนไปใช้เฟรมเวิร์กแบบโต้ตอบ และการเรียกใช้โค้ดจะกลายเป็นแบบไม่เชิงเส้น ด้วยเหตุนี้ การวินิจฉัยปัญหาโดยใช้การติดตามสแต็กจึงเป็นเรื่องยากมาก และวิธีการแก้ไขที่นี่คือการสร้างข้อยกเว้นรันไทม์ที่ชัดเจนและมีวัตถุประสงค์สำหรับทุกข้อผิดพลาด

ElasticSearch

เมื่อใช้ Elasticsearch อย่าเลือกข้อมูลที่ไม่ได้ใช้ โดยหลักการแล้วนี่เป็นคำแนะนำที่ง่ายมาก แต่ส่วนใหญ่มักเป็นสิ่งที่ถูกลืม หากคุณต้องการเลือกมากกว่า 10 เรกคอร์ดในแต่ละครั้ง คุณต้องใช้ Scroll หากต้องการใช้การเปรียบเทียบ จะเหมือนกับเคอร์เซอร์ในฐานข้อมูลเชิงสัมพันธ์ 

อย่าใช้ตัวกรองภายหลังเว้นแต่จำเป็น ด้วยข้อมูลขนาดใหญ่ในตัวอย่างหลัก การดำเนินการนี้จะโหลดฐานข้อมูลอย่างมาก 

ใช้การดำเนินการเป็นกลุ่มตามความเหมาะสม

API

เมื่อออกแบบ API ให้รวมข้อกำหนดสำหรับการลดข้อมูลที่ส่งให้เหลือน้อยที่สุด นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งในส่วนที่เกี่ยวข้องกับส่วนหน้า: ตรงทางแยกนี้ที่เราก้าวไปไกลกว่าช่องทางของศูนย์ข้อมูลของเรา และกำลังทำงานบนช่องทางที่เชื่อมต่อเรากับลูกค้าอยู่แล้ว หากมีปัญหาเพียงเล็กน้อย ปริมาณการใช้งานที่มากเกินไปจะทำให้ผู้ใช้ได้รับประสบการณ์เชิงลบ

และสุดท้าย อย่าทิ้งข้อมูลจำนวนมาก ต้องชัดเจนเกี่ยวกับสัญญาระหว่างผู้บริโภคและซัพพลายเออร์

การเปลี่ยนแปลงองค์กร

Eroshkina Elena รองผู้อำนวยการฝ่ายไอที

ในขณะที่การกักกันเกิดขึ้น และความต้องการเพิ่มขึ้นอย่างรวดเร็วของการพัฒนาออนไลน์และการแนะนำบริการ Omnichannel เราก็อยู่ในกระบวนการของการเปลี่ยนแปลงองค์กรแล้ว 

โครงสร้างบางส่วนของเราถูกถ่ายโอนไปทำงานตามหลักการและแนวปฏิบัติของแนวทางผลิตภัณฑ์ มีการจัดตั้งทีมงานขึ้นมาเพื่อรับผิดชอบการดำเนินงานและการพัฒนาผลิตภัณฑ์แต่ละรายการ พนักงานในทีมดังกล่าวมีส่วนร่วม 100% และจัดโครงสร้างงานโดยใช้ Scrum หรือ Kanban ขึ้นอยู่กับว่าอะไรดีกว่าสำหรับพวกเขา การตั้งค่าไปป์ไลน์การปรับใช้ การใช้แนวทางปฏิบัติทางเทคนิค แนวทางปฏิบัติด้านการรับประกันคุณภาพ และอื่นๆ อีกมากมาย

โชคดีที่ทีมผลิตภัณฑ์ของเราส่วนใหญ่อยู่ในด้านบริการออนไลน์และทุกช่องทาง สิ่งนี้ทำให้เราสามารถเปลี่ยนไปใช้โหมดการทำงานระยะไกลได้ในเวลาที่สั้นที่สุดเท่าที่จะเป็นไปได้ (จริงๆ แล้วภายในสองวัน) โดยไม่สูญเสียประสิทธิภาพ กระบวนการที่ปรับแต่งเองทำให้เราสามารถปรับตัวเข้ากับสภาพการทำงานใหม่ได้อย่างรวดเร็ว และรักษาอัตราการส่งมอบฟังก์ชันใหม่ที่ค่อนข้างสูง

นอกจากนี้เรายังจำเป็นต้องเสริมความแข็งแกร่งให้กับทีมที่อยู่แนวหน้าของธุรกิจออนไลน์อีกด้วย ในขณะนั้นเห็นได้ชัดว่าเราสามารถทำได้โดยใช้ทรัพยากรภายในเท่านั้น และคนประมาณ 50 คนในสองสัปดาห์ได้เปลี่ยนพื้นที่ที่พวกเขาเคยทำงานมาก่อนและมีส่วนร่วมในการสร้างผลิตภัณฑ์ใหม่สำหรับพวกเขา 

สิ่งนี้ไม่จำเป็นต้องใช้ความพยายามในการจัดการเป็นพิเศษใดๆ เนื่องจากนอกเหนือจากการจัดกระบวนการของเราเอง การปรับปรุงทางเทคนิคของผลิตภัณฑ์ และแนวทางปฏิบัติในการประกันคุณภาพแล้ว เรายังสอนให้ทีมของเราจัดระเบียบด้วยตนเอง - เพื่อจัดการกระบวนการผลิตของตนเองโดยไม่เกี่ยวข้องกับทรัพยากรด้านการบริหาร

เราสามารถมุ่งเน้นทรัพยากรการจัดการของเราได้ตรงจุดที่ต้องการในขณะนั้น - ในการประสานงานร่วมกับธุรกิจ: สิ่งที่สำคัญสำหรับลูกค้าของเราในขณะนี้ ฟังก์ชั่นใดที่ควรใช้ก่อน สิ่งที่ต้องทำเพื่อเพิ่มความสามารถในการรับส่งข้อมูลของเรา เพื่อส่งมอบและดำเนินการตามคำสั่งซื้อ ทั้งหมดนี้และแบบอย่างที่ชัดเจนทำให้ในช่วงเวลานี้โหลดกระแสมูลค่าการผลิตของเราด้วยสิ่งที่สำคัญและจำเป็นจริงๆ ได้ 

ชัดเจนว่าด้วยการทำงานทางไกลและการเปลี่ยนแปลงที่รวดเร็ว เมื่อตัวชี้วัดทางธุรกิจขึ้นอยู่กับการมีส่วนร่วมของทุกคน คุณไม่สามารถพึ่งพาเพียงความรู้สึกภายในจากซีรีส์ “ทุกอย่างเป็นไปด้วยดีกับเราไหม? ใช่ มันดูดี” จำเป็นต้องมีตัวชี้วัดวัตถุประสงค์ของกระบวนการผลิต เรามีสิ่งเหล่านี้ ซึ่งพร้อมให้สำหรับทุกคนที่สนใจตัวชี้วัดของทีมผลิตภัณฑ์ ประการแรก ทีมงาน ธุรกิจ ผู้รับเหมาช่วง และฝ่ายบริหาร

แต่ละทีมจะมีสถานะทุกๆ สองสัปดาห์ โดยมีการวิเคราะห์หน่วยเมตริกเป็นเวลา 10 นาที มีการระบุจุดคอขวดในกระบวนการผลิต และพัฒนาวิธีแก้ปัญหาร่วมกัน: สิ่งที่สามารถทำได้เพื่อขจัดปัญหาคอขวดเหล่านี้ ที่นี่คุณสามารถขอความช่วยเหลือจากฝ่ายบริหารได้ทันที หากปัญหาที่ระบุอยู่นอกขอบเขตอิทธิพลของทีม หรือความเชี่ยวชาญของเพื่อนร่วมงานที่อาจพบปัญหาที่คล้ายกันแล้ว

อย่างไรก็ตาม เราเข้าใจดีว่าเพื่อที่จะเร่งความเร็วหลายๆ ครั้ง (และนี่คือเป้าหมายที่เราตั้งไว้สำหรับตัวเราเอง) เรายังจำเป็นต้องเรียนรู้อีกมากและนำไปใช้ในการทำงานประจำวันของเรา ขณะนี้เรากำลังขยายแนวทางผลิตภัณฑ์ของเราไปยังทีมอื่นและผลิตภัณฑ์ใหม่อย่างต่อเนื่อง เพื่อบรรลุเป้าหมายนี้ เราต้องเชี่ยวชาญรูปแบบใหม่สำหรับเรา นั่นคือโรงเรียนออนไลน์ของนักระเบียบวิธี

นักระเบียบวิธีคือผู้ที่ช่วยเหลือทีมในการสร้างกระบวนการ สร้างการสื่อสาร และปรับปรุงประสิทธิภาพการทำงาน โดยพื้นฐานแล้วคือตัวแทนของการเปลี่ยนแปลง ขณะนี้ ผู้สำเร็จการศึกษาจากกลุ่มแรกๆ ของเรากำลังทำงานร่วมกับทีมและช่วยให้พวกเขาประสบความสำเร็จ 

ฉันคิดว่าสถานการณ์ปัจจุบันเปิดโอกาสและโอกาสให้เราซึ่งบางทีเราเองยังไม่ตระหนักดีนัก แต่ประสบการณ์และการฝึกฝนที่เราได้รับในขณะนี้เป็นการยืนยันว่าเราได้เลือกเส้นทางการพัฒนาที่ถูกต้อง เราจะไม่พลาดโอกาสใหม่ ๆ เหล่านี้ในอนาคต และจะสามารถตอบสนองต่อความท้าทายที่ Sportmaster จะเผชิญได้อย่างมีประสิทธิภาพเช่นเดียวกัน

ผลการวิจัย

ในช่วงเวลาที่ยากลำบากนี้ เราได้กำหนดหลักการสำคัญในการพัฒนาซอฟต์แวร์ ซึ่งผมคิดว่าจะเกี่ยวข้องกับทุกบริษัทที่เกี่ยวข้องกับเรื่องนี้

คน. นี่คือสิ่งที่ทุกอย่างวางอยู่บน พนักงานจะต้องสนุกกับงานและเข้าใจเป้าหมายของบริษัทและเป้าหมายของผลิตภัณฑ์ที่พวกเขาทำงานอยู่ และแน่นอนว่าพวกเขาสามารถพัฒนาอย่างมืออาชีพได้ 

เทคโนโลยี. จำเป็นสำหรับบริษัทที่จะต้องใช้แนวทางที่เป็นผู้ใหญ่ในการทำงานกับกลุ่มเทคโนโลยีและสร้างความสามารถในจุดที่จำเป็นจริงๆ มันฟังดูง่ายและชัดเจนมาก และมักละเลยไปมาก

กระบวนการต่างๆ. สิ่งสำคัญคือต้องจัดระเบียบการทำงานของทีมผลิตภัณฑ์และศูนย์ความสามารถอย่างเหมาะสม เพื่อสร้างปฏิสัมพันธ์กับธุรกิจเพื่อทำงานร่วมกับธุรกิจในฐานะหุ้นส่วน

โดยทั่วไปแล้ว นั่นเป็นวิธีที่เรารอดชีวิตมาได้ค่อนข้างมาก วิทยานิพนธ์หลักในยุคของเราได้รับการยืนยันอีกครั้งโดยคลิกที่หน้าผากดังกึกก้อง

แม้ว่าคุณจะเป็นธุรกิจออฟไลน์ขนาดใหญ่ที่มีร้านค้ามากมายและเมืองที่คุณดำเนินธุรกิจอยู่ พัฒนาธุรกิจออนไลน์ของคุณ นี่ไม่ใช่แค่ช่องทางการขายเพิ่มเติมหรือแอปพลิเคชันที่สวยงามซึ่งคุณสามารถซื้อของบางอย่างได้ (และเนื่องจากคู่แข่งก็มีช่องทางที่สวยงามเช่นกัน) นี่ไม่ใช่ยางอะไหล่สำหรับเผื่อไว้เพื่อช่วยให้คุณฝ่าฟันพายุได้

นี่เป็นความจำเป็นอย่างยิ่ง ซึ่งไม่เพียงแต่ต้องเตรียมความสามารถด้านเทคนิคและโครงสร้างพื้นฐานของคุณเท่านั้น แต่ยังต้องเตรียมบุคลากรและกระบวนการของคุณด้วย ท้ายที่สุด คุณสามารถซื้อหน่วยความจำ พื้นที่เพิ่มเติม ปรับใช้อินสแตนซ์ใหม่ ฯลฯ ได้อย่างรวดเร็วภายในเวลาไม่กี่ชั่วโมง แต่จำเป็นต้องเตรียมบุคลากรและกระบวนการล่วงหน้าสำหรับเรื่องนี้

ที่มา: will.com