ความเร็วของซอฟต์แวร์ปรากฏชัดในสายตาของลูกค้าบ่อยแค่ไหน?

ในทางทฤษฎีลูกค้าควรรู้สึกถึงการปรับปรุงประสิทธิภาพของซอฟต์แวร์จากประสบการณ์โดยตรง

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

เราทราบถึงความแตกต่างระหว่างประสิทธิภาพที่รับรู้ (ความหน่วงแฝงของ GUI และอื่น ๆ ) กับประสิทธิภาพของฝั่งเซิร์ฟเวอร์ (เครื่องจักรเครือข่ายโครงสร้างพื้นฐาน ฯลฯ )

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

แม้ว่า@jwentingทำคะแนนได้ดี แต่ฉันก็ไม่เห็นด้วยกับการประเมินทั่วไป

ผู้ใช้มักจะไม่สังเกตเห็นการปรับปรุงประสิทธิภาพเล็กน้อย

ด้วยสิ่งนี้ฉันสามารถเห็นด้วย

ที่ฉันไม่เห็นด้วยหมุนรอบคำสั่งนี้:

แอปพลิเคชันที่ผู้ใช้ปลายทางส่วนใหญ่ใช้เวลาส่วนใหญ่ในการรออินพุตของผู้ใช้

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

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

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

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

การปรับปรุงประสิทธิภาพบางอย่างไม่ได้สังเกตว่าเป็นประสิทธิภาพ ลูกค้าจะสังเกตเห็นว่าระบบ "รู้สึก" ดีกว่า

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

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

โปรดจำไว้ว่าแอปพลิเคชันส่วนใหญ่ที่ผู้ใช้ส่วนใหญ่ใช้เวลาส่วนใหญ่รอการป้อนข้อมูลจากผู้ใช้ไม่ใช่การประมวลผลอินพุตนั้น ดังนั้นแม้ว่าคุณจะได้รับส่วนลด 10% จาก 100ms เพื่อประมวลผลการคลิกปุ่มและอัปเดตหน้าจอผู้ใช้จะแทบไม่สังเกตเห็นเนื่องจากเธอจะไม่ทำอะไรกับหน้าจอที่อัปเดตอีก 10,000 มิลลิวินาทีหลังจากนั้น

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

อย่างที่คนอื่นพูดในวันนี้มันเกี่ยวกับการรับรู้ประสิทธิภาพและ "fluiditiy" มากกว่าความเร็วที่แท้จริง

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

นี่เป็นสิ่งสำคัญในการซ่อนเวลาแฝงที่คุณไม่สามารถทำอะไรได้ดังนั้นจึงเป็นทักษะที่ดีในการฝึกฝน

ฉันแค่อยากจะกระโดดเข้าไปที่นี่และเสนอกรณีที่ผิดปกติที่ ....

* _{ลูกค้าที่สนใจการดูแลเกี่ยวกับประสิทธิภาพและการแจ้งเตือนการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ !} .

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

กระทู้ฟอรัมมักจะเริ่มต้นด้วยการเปรียบเทียบลูกค้ากับฉากของพวกเขากับซอฟต์แวร์รุ่นต่าง ๆ ซึ่งลูกค้ากำลังทำการเปรียบเทียบมากกว่าตัวนักพัฒนาเอง "ฉากนี้ใช้เวลา 1 ชั่วโมง 40 นาทีในการแสดงผลในเวอร์ชั่น X ตอนนี้ใช้เวลา 32 นาทีในเวอร์ชั่น Y"

"ฉากนี้ใช้เวลาโหลด 18 นาทีในเวอร์ชั่น X ตอนนี้ใช้เวลาโหลด 4 นาทีในเวอร์ชั่น Y"

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

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

ดังนั้นจึงมีเขตข้อมูลเช่นนี้ที่ลูกค้าจริงๆสังเกตจริงๆ - บางครั้งยิ่งกว่าตัวนักพัฒนาเองและนี่คือนอกแนวคิดการโต้ตอบ UI ซึ่งเกี่ยวกับเวลาแฝงมากกว่าปริมาณงาน

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

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

ครั้งเดียวที่ฉันเจอคือ:

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

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

ตัวอย่าง: Apple คิดค่าใช้จ่ายประมาณ $ 130 สำหรับการอัปเกรด Mac OS X แต่ละครั้ง ยกเว้น Snow Leopard ซึ่งขาย $ 30 นักพัฒนาซอฟต์แวร์ได้ทำงานอย่างหนักกับเวอร์ชันนั้น แต่มีการปรับปรุงน้อยมากที่มองเห็นได้จากมุมมองของผู้ใช้ ดังนั้น Apple จึงตัดสินใจคิดค่าบริการขั้นต่ำ

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

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

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

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

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

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

ขึ้นอยู่กับว่าคุณกำลังขายผลิตภัณฑ์ซอฟต์แวร์ของคุณให้ใคร

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

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