สิ่งที่ควรป้อนข้อมูลของทีมต่อสู้?


11

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

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


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

คำตอบ:


4

แม่: มีลักษณะที่ดีนี้พูดคุย , Florian ฮาให้ที่ FROSCON นี้ (ร็อคกี้) มันเกี่ยวกับความเป็นไปไม่ได้ในทางปฏิบัติของการทำทะเลาะกันเลย

ข่าวดี : ตั้งแต่การต่อสู้เป็นไปไม่ได้ที่จะใช้คุณมีอิสระที่จะทำสิ่งที่คุณต้องการ

ข่าวร้าย : อย่าเรียกว่าทะเลาะกัน

นั่นทำให้คุณเป็นอิสระจากคำถาม: »ฉันกำลังทะเลาะกันใช่มั้ย? « (คำตอบ: ไม่คุณไม่ได้ทำ ) และคุณสามารถตอบคำถามเชิงปฏิบัติของชีวิตได้


เราไม่มีผู้ออกแบบ UI / UX และนักพัฒนาใช้งาน UI / UX กับเจ้าของผลิตภัณฑ์

นี่ไม่ใช่สถานการณ์ที่ผิดปกติ แต่การต่อสู้ AFAIR ขัดต่อความเชี่ยวชาญ: ทุกคนควรมีชุดทักษะเดียวกันและสามารถใช้แทนกันได้

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

ใช่ฉันตอนนี้สถานการณ์ทั้งหมดดีเกินไป ฉันทำงานในทีมที่เราต้องจัดการกับงานในมือที่ค้างอยู่อย่างกว้างขวางเช่น»ในฐานะผู้ใช้ฉันต้องการดูข้อมูลx «และนั่นก็เป็นเช่นนั้น จากนั้นรายการลงบนกระดานวิ่ง หนึ่ง dev เอาไป แก้ไขมัน หลังจากนำไปใช้งานแล้วจะมีการตรวจสอบโดยเพื่อนคนแรกโดยที่การสนทนาเริ่มต้นขึ้นเกี่ยวกับลักษณะของ UI ที่ควรมี

จากนั้น QA-Phase ก็มาถึงและการสนทนาเริ่มต้นขึ้นอีกครั้ง

หลังจากวิ่งที่เราทำตามที่ต่อสู้เรียกร้องตรวจสอบที่การออกแบบที่ถูกฉีกโดยPO น่าเสียดายที่ลูกค้าของเราไม่ได้ทำการรีวิวดังนั้นเขาจึงไม่เห็นซอฟต์แวร์ ณ จุดนั้น

แต่วงจรก็เริ่มต้นใหม่อีกครั้งจนกระทั่งPOพอใจ

แล้วลูกค้าก็มา ...

จากเรื่องราวสงครามครั้งนี้คุณเห็นว่ากระบวนการแบบพิเศษนี้ไม่มีประสิทธิภาพ

สิ่งที่ได้ผลสำหรับเราในที่สุดก็คือการขว้างปาทะเลาะกันบนกระดาน

แต่นั่นไม่ใช่ทางออกสำหรับคำถามของคุณ;)

คุณคิดว่าทุกรายละเอียดที่เป็นไปได้เกี่ยวกับคุณสมบัติควรมอบให้กับนักพัฒนาก่อนที่จะเริ่มการวิ่งหรือเป็นงานภายในคุณสมบัติ

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

ฉันจะฝ่าฝืนกฎการต่อสู้เพื่อกำหนด backlogitem หนึ่งอัน: "จำลองการทำงาน" ซึ่งสามารถตรวจสอบได้อย่างรวดเร็วโดยPOและลูกค้าเพื่อลดการพัฒนาช่วงเวลาที่ใช้ในรายการที่เรียบง่าย

TL; DR

สิ่งที่ควรป้อนข้อมูลของทีมต่อสู้?

ข้อมูลเพียงพอเพื่อให้ตรงตามข้อกำหนดในเวลาน้อยที่สุด


offtopic:

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


นายฮาสค่อนข้างงมงายเกี่ยวกับกรอบการต่อสู้ มันเป็นความเข้าใจผิดประเภทนี้ซึ่งสะท้อนให้เห็นในหลาย ๆ องค์กร
Alan Larimer

เรื่องราวนั้นเล่าซ้ำแล้วซ้ำอีก: "ถ้าเพียง แต่คุณกำลังทะเลาะกันอย่างถูกต้อง" ฉันไม่เคยเห็น บริษัท ที่ต่อสู้กันทำงาน ดังนั้นฉันมีอคติที่แข็งแกร่งต่อการต่อสู้ซึ่งแม้จะเติบโตหลังจากประสบการต่อสู้โดยตรงใน บริษัท ของเรา และนี่เป็นเรื่องเดียวกัน: มันไม่ทำงาน (สำหรับเรา)
Thomas Junk

7

คำตอบที่ยอมรับได้คือ "ทำสิ่งที่เหมาะกับคุณ"

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

บุคคลและการโต้ตอบเกี่ยวกับกระบวนการและเครื่องมือ
ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุมการ
ทำงานร่วมกันของลูกค้าในการเจรจาสัญญาการ
ตอบสนองต่อการเปลี่ยนแปลงตามแผน ( Agile manifesto )

มันไม่ใช่คำถามว่าทีมของคุณควรเริ่มเรื่องอะไรมันเป็นคำถามว่าทีมของคุณช่วยให้ทีมงานของคุณแก้ปัญหาความต้องการทางธุรกิจได้อย่างไร


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

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


4

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

สิ่งที่ได้ผลสำหรับเราคือ:

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

Tl; DR: อย่ากำหนด UX ให้ครบถ้วนก่อนการเข้ารหัส รอจนกว่าผู้ใช้จะเห็นมันและเล่นกับมัน


4

คุณคิดว่าทุกรายละเอียดที่เป็นไปได้เกี่ยวกับคุณสมบัติควรมอบให้กับนักพัฒนาก่อนที่จะเริ่มการวิ่งหรือเป็นงานภายในคุณสมบัติ

พูดง่ายๆก็คือถ้าเจ้าของผลิตภัณฑ์ไม่สามารถส่งมอบการออกแบบ ui / ux ก่อนการวิ่งการพัฒนา ui / ux ควรเป็นเรื่องไม่ใช่งาน

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


3

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

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


3

หากคุณทะเลาะกันทุกคนสามารถเป็นนักออกแบบ UI / UX

UI / UX ไม่ควรจะเป็นภายหลัง มันควรจะส่งมอบ ควรได้รับการอนุมัติจากเจ้าของผลิตภัณฑ์ของคุณ มันควรจะปรากฏขึ้นแม้ว่าจะเป็นเพียง gif เมื่อส่งมอบ

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

UI / UX ที่สรุปแล้วเท่านั้นที่อยู่ในซอฟต์แวร์ที่ไม่ทำงาน

จากความคิดเห็นของคุณ:

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

กำจัดทุกสิ่งที่ไม่จำเป็นช้าลงคุณ

คุณมีความคิด บอกเจ้าของผลิตภัณฑ์ พวกเขาควรจะนั่งถัดจากคุณ

พวกเขาเกลียดหรือไม่ ก้าวต่อไป. รักเหรอ? ทำมัน. ไม่เข้าใจหรอ แสดงให้พวกเขา

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

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

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


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

@ อัปเดตโน้ตของ Rashid
candied_orange

@Rashid หากคุณประเมินเวลาแทนความซับซ้อนแสดงว่าคุณทำผิด!
svidgen

2

จากประสบการณ์ของฉัน:

  • การวิเคราะห์ล่วงหน้าน้อยเกินไปทำให้การพัฒนาหยุดทำงานไม่มีประสิทธิภาพ
  • การวิเคราะห์ล่วงหน้ามากเกินไปทำให้เกิดการวิเคราะห์อัมพาต (Sprint ไม่เคยเริ่มต้น)

เราทำอะไร:

  • กำหนดเกณฑ์" พร้อมสำหรับการพัฒนา " บางอย่าง
  • สำหรับเรื่องราว UX นี่อาจเป็น "เรามีโครงร่างที่ทีมงานเข้าใจดี"

ระหว่างการวางแผน Sprint:

  • เรื่องราวใด ๆ ที่ไม่พร้อมสำหรับการพัฒนาจะถูกโยนออกไป (พวกเขาจะก่อกวนทีมและกลับไปวิเคราะห์เพิ่มเติม)
  • เรื่องราวแนวเขตใด ๆ จะประกาศว่า "มีความเสี่ยงสูง" และดำเนินการตั้งแต่เริ่มต้น Sprint
  • เรื่องราวที่เข้าใจกันดีนั้นได้รับการประเมินและอนุญาตให้เข้าสู่ Sprint

ระบบนี้ช่วยให้เราสามารถอุทิศส่วนใหญ่ของ Sprint ทุกการดำเนินการเช่นเราทำงานได้อย่างมีประสิทธิภาพมากขึ้น


2

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

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

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

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

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


1

ฉันไม่แน่ใจว่าคุณกำลังทำตามหลักการที่คล่องตัว แต่นี่คือวิธีการจัดการสิ่งนี้

เราไม่ได้กำหนด UI / UX ที่แน่นอนก่อนที่จะเริ่มการวิ่ง

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

เราใช้เวลามากเกินไปในระหว่างการวิ่งเพื่อพยายามออกแบบ UI / UX ให้เสร็จ

ทำงานบนวิธีการตรวจสอบเมื่อสิ่งที่จะทำ ฉันมีความรู้สึกบางคนกำลังทำการประเมิน UI / UX ไปมาอย่างต่อเนื่อง มีคนจำนวนมากที่มีความคิดเห็นเกี่ยวกับ UX / UI โดยไม่มีสิ่งใดจากลูกค้าเพื่อรองรับสมมติฐานของพวกเขา

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.