ทำให้ผู้ที่ไม่ใช่โปรแกรมเมอร์เข้าใจกระบวนการพัฒนา


66

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

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


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

คำตอบ:


34

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

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


+1 สำหรับการชี้เรื่องนี้ ไม่มีอะไรที่เป็นอันตรายต่อโครงการมากนักถ้าผู้ใช้เทคโนโลยีและผู้ที่ไม่ใช้เทคโนโลยีมีความเคารพซึ่งกันและกันน้อยมาก
mhr

28

วิธีการหนึ่งที่ฉันพบว่าประสบความสำเร็จคือ:

เราทุกคนรู้ว่าคอมพิวเตอร์ทำอย่างเดียวและสิ่งที่บอกให้ทำ

การเขียนโปรแกรมเป็นวิธีการที่เราบอกคอมพิวเตอร์ในขณะนี้สิ่งที่เราสิ่งที่มันจะทำในภายหลัง

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

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


4
+1 สำหรับ "บอกสิ่งที่เราต้องการในภายหลัง" ด้วยความคิดที่ว่าซอฟต์แวร์ส่วนใหญ่ทำสิ่งใหม่

12

IMO ฉันพบว่าความโปร่งใสที่นำเสนอโดยกระบวนการแบบเปรียว (เช่น Scrum, Crystal และอื่น ๆ ) เป็นวิธีที่แสดงให้เห็นว่าการพัฒนาทำงานอย่างไรเพื่อผู้มีส่วนได้เสียโดยเฉลี่ย


1
นี่คือกลยุทธ์ที่ยอดเยี่ยมถ้าคุณทำ 100% ของการพัฒนา หากฝ่ายใดฝ่ายหนึ่งจัดการโดยอีกฝ่ายคุณจะต้องประนีประนอมกันสักหน่อย
JBRWilkinson

3

คำอธิบายโดยอุปมาคือสิ่งที่เป็นนามธรรม แต่นี่คือแนวคิดบางอย่างที่มักจะเหมาะกับฉัน:

โปรดทราบว่าคำอธิบายเหล่านี้ไม่มีข้อแก้ตัวในการทำงานเลอะเทอะ

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

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

ในที่สุดฉันถามว่า Intel และ Microsoft ไม่สามารถหลีกเลี่ยงข้อบกพร่องพวกเขาคาดหวังให้เราทำอย่างไร


2
จุดที่ดีมากเกี่ยวกับ Microsoft
Casebash

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

1
-1 @ ThorbjørnRavnAndersenถูกต้อง โพสต์นี้ผิด เป็นไปได้มากที่จะพิสูจน์โปรแกรมที่ถูกต้อง (ขึ้นอยู่กับความคิดของความถูกต้องบางอย่าง) พวกเราบางคนทำตลอดเวลา ฉันคิดว่าผู้โพสต์เข้าใจผิดเกี่ยวกับผลลัพธ์ทางญาณวิทยาของปัญหาการหยุดชะงักและทำให้ผู้ที่ไม่ใช่โปรแกรมเมอร์สับสนกับการอ้างสิทธิ์ที่ไม่จริง
Philip JF

2

ฉันได้ตอบคำถามที่คล้ายกันโดยละเอียดยิ่งขึ้นแต่สิ่งสำคัญคือ "การเขียนโปรแกรมเหมือนกับการสร้างโรงงานหรือสายการประกอบ"


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

@mri - ใครก็ตามที่สร้างโรงงานจริงจะบอกคุณว่าไม่ว่าเครื่องจักรในโรงงานจะได้รับการออกแบบมาดีเพียงใดส่วนของมันก็ยังคงต้องใช้มือพอดี เครื่องมือของเราอาจลดความซับซ้อนของมือ แต่เราไม่ได้ (รหัสส่วนใหญ่) ประกอบการประดิษฐ์เพื่อใช้ประโยชน์จากวงจรและขอบเขตหน่วยความจำ เหมือนเฟอร์นิเจอร์สไตล์ช่างฝีมือ "มือที่สวยงาม" ที่ได้รับประโยชน์จากระบบอัตโนมัติของวันนั้น
DaveE

2

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

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

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

ไม่มีกระบวนการใดที่ปราศจากข้อบกพร่องแม้ว่าจะสามารถเข้าใกล้ถึงระดับคุณภาพที่สูงขึ้น

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


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

0

หากคุณมีความคุ้นเคยกับการพัฒนาซอฟต์แวร์ hi-rel เช่นการควบคุมเครื่องปฏิกรณ์นิวเคลียร์การสื่อสารในห้วงอวกาศหรืออุปกรณ์สอดใส่ทางการแพทย์ (ฯลฯ ) คุณอาจอธิบายว่าโครงสร้างต้นทุนและเวลาการส่งมอบสำหรับการจัดการ priject และ QA นั้นเป็นอย่างไร อาจมีขนาดใหญ่กว่าสิ่งที่ธุรกิจทั่วไปสามารถจ่ายได้สำหรับโครงการซอฟต์แวร์ของพวกเขา


0

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

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

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

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

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

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

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


0

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


0

ต้นทุนและเวลา

เวลา

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

ราคา

นี่คือจากหนังสือ Code Compete ของ Steve McConnel (อ้างจากหน่วยความจำดังนั้นให้อภัยฉันถ้าฉันไม่สามารถถ่ายทอดมันด้วยเอฟเฟ็กต์เดียวกัน) - มันง่ายสำหรับลูกค้าที่จะขอคุณสมบัติใหม่ ในฐานะผู้จัดการผลิตภัณฑ์คุณไม่ควรพูดกับสิ่งที่ลูกค้าถาม คุณควรประเมินความพยายามและค่าใช้จ่ายในการสร้างคุณสมบัติใหม่นั้น พวกเขาจะเข้าใจอย่างช้าๆว่าคุณสมบัติใหม่นั้นไม่คุ้มกับเงิน / เวลาหรือบางทีพวกเขาอาจไม่ต้องการมัน ฉันไม่ได้แนะนำให้คุณใช้อาวุธนี้เพื่อทำให้ตกใจ แต่ใช้มันอย่างตรงไปตรงมาและอาจช่วยในการขับรถกลับบ้านได้


-2

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

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


-2

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


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