การทำ Software ของ Microsoft กับ Google ต่างกันอย่างไร

Teerayut Hiruntaraporn
2 min readDec 4, 2021

--

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

จริงๆแล้วมันมาจากคำถามที่ว่า

ซึ่งแน่นอนว่ามันต้องมีหลายคนไม่เห็นด้วย ต่างๆนานา แต่ส่วนตัวสนใจความเห็นของคุณ David Seidman ซึ่งเคยทำงานในทั้ง 2 ที่ เลยอธิบาย Context ที่ไม่เหมือนกันของทั้งสองที่ได้อย่างน่าสนใจ ดังนี้ครับ

วิธีคิดของ Microsoft ยุค 90

ในยุคนั้นมี Microsoft จะมีคู่แข่งที่สำคัญคือ

  • Apple Macintosh
  • Word Perfect ผู้ครองตลาด 50% ใน Word processor ในยุคนั้น
  • Lotus 1–2–3 ผู้นำใน Spreadsheet ในยุคนั้น

ดังนั้นเมื่อเจอการแข่งขันกับคู่แข่งที่มีความสามารถ สิ่งที่ Microsoft ทำก็คือ

ปล่อย Feature ให้มากที่สุด

โดยมีคำที่เป็นวลีภายในคือ

Shipping is a feature.

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

อีกส่วนหนึ่งที่สำคัญคือ Code ที่เขียนในยุค 90s มันไม่ได้มี Practice ทางวิศวกรรมซอฟท์แวร์ที่ดีเท่ากับยุคหลังๆ

เมื่อการเปิดกว้างมีราคาที่ต้องจ่าย

อีกเรื่องหนึ่งที่ทำให้ Microsoft ประสบความสำเร็จในเรื่อง Adoption ของซอฟท์แวร์ของ Windows ก็คือการที่ Microsoft อนุญาตให้ 3rd-party มาพัฒนาระบบเพิ่มเติมได้ จุดนี้ทำให้มี Tool หรือ Program ต่างๆ ให้ผู้ใช้ได้ใช้งานได้หลากหลาย

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

มันแก้ไขยาก

โดยเนื่องจาก องค์กร ลูกค้า ต้องการซอฟท์แวร์ที่ Stable ทำให้ Microsoft ไม่สามารถที่จะหักดิบเปลี่ยนอะไรได้ง่ายๆ หรือบ่อยๆ หรือทำอะไรที่ Breaking Change หนักๆ ได้

ทัศนคติเกี่ยวกับการ update บ่อยๆ กับความเสถียร

และเนื่องจากการที่ Microsoft พยายามทำภาพของความเสถียรของตัวซอฟท์แวร์นั่นเอง ทำให้ การ Update บ่อยๆ นั้น เป็นไปได้ยาก ในช่วงเวลานั้น โดยมีสามารถอยู่ใน 2 ส่วน

  1. Microsoft จะต้องทดสอบทั้งหมด ตั้งแต่ Ground Up ซึ่งกินระยะเวลายาวนาน โดยทั้งหมด เป็นการทำงานภายในองค์กรทั้งสิ้น
  2. อันนี้เป็นความเห็นส่วนตัว ในช่วงนั้น มีความเชื่อที่ว่า ระบบที่เสถียรมันต้องไม่ update กันบ่อยๆ ถ้าใครจำช่วงเวลานั้นได้ จะคุ้นๆ ว่า ถ้าจะ update ออก major version ใหม่ไปเลยดีกว่า ทำให้ release แต่ละครั้งนานเป็นปีๆ

Google: เมื่อ Engineering Wise นำหน้า Business

ถ้าใครได้อ่านหนังสือเกี่ยวกับ Google จะพอทราบว่า Google นี่เริ่มด้วยคนที่มีความ Geek เป็นส่วนใหญ่ ทำให้เขาให้ค่ากับ Engineering Quality มาก มากขนาดที่ว่า ยอมเสียเวลาทำนาน หรือยอมจ่ายแพง นั่นแหละ

ทำให้ Google ซีเรียสกับเรื่อง Technical Debt หรือ Architect มาก

Google กล้า Test กับลูกค้า

ในการ release ซอฟท์แวร์ของ google จะมีความแตกต่างกับ Microsoft อย่างเห็นได้ชัด เช่นการเปิดตัว google หรือ การเปิดตัว gmail เขาก็เปิด version ที่ดูง่ายๆ ออกมา ให้ผู้ใช้ใช้งาน แล้วรับ Feedback จากลูกค้าโดยตรง

แต่แน่นอนว่า เขาคงต้องบริหารความเสี่ยงด้วย จึงมักจะเปิดให้ใช้อย่างจำกัด เช่น เป็น invite only เป็นต้น

Gmail ในตอน release (Cr: Wikipedia)

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

เรื่องที่ชวนคิด: ถ้า Google เกิดในช่วง 90 จะทำเหมือน Microsoft ไหมนะ

ส่วนตัวคิดว่า อาจจะทำก็ได้นะ ส่วนหนึ่งเพราะ Feedback loop ในช่วงนั้นน่าจะใช้เวลาเยอะ อย่าลืมว่าช่วงนั้น เครื่องยังเป็น Pentium ใช้ Disk 3.5 เดินใส่กระเป๋าเดินไปเดินมา ระหว่างกัน ทุกบ้านก็ไม่ได้มีคอมพิวเตอร์ใช้กัน

ที่ๆ จะขายได้และมีเงินจ่ายก็มีแค่องค์กร ซึ่งเราก็ Ship Junk หรืออะไรที่ไม่เสร็จก็ไม่ได้ ไม่เช่นนั้นเขาก็ไม่สั่งของเราต่อ มันก็ต้องซีเรียสกันพอสมควร

จุดนี้ก็ทำให้นึกถึง Apple ขึ้นมา เพราะในช่วงแรกๆ Apple ก็ไม่ได้ Release อะไรบ่อยๆ เช่นเดียวกัน พึ่งมา Courage กันจริงๆ ก็ยุค iPhone นี่แหละ

ดังนั้น ในอนาคตก็ไม่รู้ว่าจะมีปัจจัยอะไรที่จะทำให้ การออก update บ่อยๆ หรือการไปให้ลูกค้าลองเลย เป็นสิ่งที่ไม่ควรทำหรือไม่

ส่งท้าย

สิ่งสำคัญที่ก่อให้เกิดพฤติกรรมในการทำซอฟท์แวร์ที่แตกต่างกัน ก็มาจากบริบทและสถานการณ์ในเวลานั้น

รวมถึงแผนการบริหาร ว่าบริษัทให้คุณค่ากับเรื่องอะไร

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

--

--

Teerayut Hiruntaraporn
Teerayut Hiruntaraporn

No responses yet