✍🏼 ทุกอย่าง vs. บางอย่าง
บทสนทนาระหว่างอาจารย์และเพื่อนร่วมชั้นเรียนของผมเมื่อนานมาแล้วให้แนวคิดที่ดีมากในการทำโปรดักท์ หน้าที่ของเราไม่ใช่ตามใจคนทุกคนแต่เลือกที่จะทำอะไรที่ดีที่สุดสำหรับคนบางคน
บทสนทนาระหว่างอาจารย์และเพื่อนร่วมชั้นเรียนของผมเมื่อนานมาแล้วให้แนวคิดที่ดีมากในการทำโปรดักท์ หน้าที่ของเราไม่ใช่ตามใจคนทุกคนแต่เลือกที่จะทำอะไรที่ดีที่สุดสำหรับคนบางคน
การเริ่มต้นซอฟต์แวร์ทุกตัวน่าสนใจที่เป้าหมายแรก จะเรียกว่าไมล์สโตนแรกก็ได้ บางคนอยากเห็นงานคุณภาพสูง บางคนสนใจแผนการพัฒนาซอฟต์แวร์แบบละเอียด … ไม่ใช่พวกนี้เลยที่เราต้องการ โปรโตไทป์ต่างหากที่ควรเป็นเป้าหมายแรกของเรา
คนทำโปรดักท์มีอำนาจอยู่ในมือ (อาจจะไม่รู้ตัว) อำนาจที่เราจะเลือกได้ว่าเราอยากทำอะไรออกมาให้โลกใบนี้ ว่ามันจะเป็นซอฟต์แวร์เวอร์ชั่นที่ 10 ของเรื่องเดิมที่น่าเบื่อหรือว่าจะเป็นเวอร์ชั่นแรกของเรื่องใหม่
ถามว่าใครควรเป็นคนออกแบบยูไอ? บางทีเราอยากจะผลักภาระนี้ไปให้ดีไซเนอร์ แน่นอนว่ามันคือหน้าที่ของพวกเขา แต่ผมคิดว่าเราในฐานะโปรแกรมเมอร์ควรฝึกหัดทักษะนี้ได้ด้วยครับ เพราะ …
อะไรคือปัจจัยสำคัญที่ชี้วัดว่า “นี่คือซอฟต์แวร์ที่ดี”? … คำถามที่ตอบไม่ยาก ซอฟต์แวร์ที่ดีคือซอฟต์แวร์ที่มีคนใช้ คำตอบที่ง่ายแต่ทำจริงๆยากไม่ใช่เล่น
ลองดูวิดีโอที่เล่าเรื่องเบื้องหลังการสร้างเฟสบุ๊ก แพลตฟอร์มแล้วได้แรงบันดาลใจดีมากครับ คิดเร็ว ทำเร็ว รับฟัง มีอำนาจตัดสินใจ ประหยัด และสร้างอิมแพค
การเขียนใหม่คือความเสี่ยงที่ยิ่งใหญ่ที่สุด เพราะเรากำลังจะโยนความรู้ที่สะสมมาในโค๊ดเบสเดิมทิ้งไป เรากำลังยื่นโอกาสทางการตลาดให้คู่แข่งที่กำลังไล่ตามมา และสำคัญที่สุด “เราจะมั่นใจได้อย่างไรว่าการเขียนใหม่ครั้งนี้จะดีกว่าเดิม?” ทางเลือกที่ดีกว่า …มีแน่นอน 👉🏽
มองดูซอฟต์แวร์ของตัวเองตรงหน้าแล้วรู้สึกสลดใจ มันเก่าเก็บ มันเทอะทะ มันไปต่อยาก … มันกระตุ้นต่อมอยากเขียนใหม่ให้ทำงาน เขียนด้วยเทคโนโลยีใหม่ เขียนด้วยไอเดียใหม่ๆ ดีมั้ย?
การทดสอบการใช้งานซอฟต์แวร์ตัวใหม่ของเราไม่จำเป็นต้องลงทุนทดสอบและสัมภาษณ์คนเป็นสิบเป็นร้อย … ตัวเลขจากสถิติบอกเราว่าแค่ห้าคนก็พอแล้ว เหตุผลคือ …
ถ้ามีคนบอกว่า “ขยายฟ้อนท์ให้หน่อย” เราจะมองว่ามันคือความต้องการ (Requirement) หรือความต้องการ (Need)? การทำซอฟต์แวร์ที่ดีไม่ใช่การขยายขนาดฟ้อนท์แต่มันคือการแก้ปัญหาที่ว่า “รายงานตอนนี้อ่านยาก” มากกว่า