Agile software is a service
โดยทั่วไปเรามี Perception ต่อธุรกิจสองแบบใหญ่ๆ
ธุรกิจขายสินค้า เป็นธุรกิจที่ขายของที่จับต้องได้ชัดเจน เช่น คุณขายหมูเป็นกิโลกรัม
ธุรกิจขายบริการ เป็นธุรกิจที่ขายความพึงพอใจให้ลูกค้า เช่น การท่องเที่ยว
ผมพบว่า คนทำงานซอฟต์แวร์ มักมี Perception ต่อซอฟต์แวรเป็นแบบแรก คือ เราขายซอฟต์แวร์ ขายสินค้าจับต้องได้
เมื่อเราเชื่อแบบนี้ มูลค่าหรือ Value proposition ของเราก็จะกลายเป็นตัวความสามารถของซอฟต์แวร์ ยิ่งมีความสามารถเยอะเท่าไหร่ ก็ยิ่งมีมูลค่ามาก
เมื่อเราเสนอ Value proposition แบบนี้ให้กับลูกค้า เราทำโปรเจ๊กต์โดยบอกกับลูกค้าว่าคุณต้องจ่ายแพงเพราะเรามีความสามารถ “เยอะกว่า”
แต่ในทาง Agile software development เราปรับตัวตามสถานการณ์ที่มี
เกิดอะไรขึ้น ถ้าคุณทำไป 8 Sprint ลูกค้าขอเปลี่ยนเรื่อยๆ จนพบว่า สุดท้าย ซอฟต์แวร์ที่ลูกค้าต้องการจริงๆ มีแค่หน้าจอโง่ๆ หน้าจอเดียว พอแล้ว จบ
เอ๊ะ ผลงานสุดท้าย “ปริมาณ” มีแค่นี้เอง ทำไมแพงจังเลย คุณต้องเพิ่มให้ผมนะ
ผมเคยปรึกษากับคนที่เขาทำงานในธุรกิจบริการ ผมก็เล่าๆ ปัญหาแบบนี้ให้ฟัง
เขาบอกว่า “ทำไมผมต้องคิดมากด้วย ลูกค้าพอใจก็จบแล้วนี่ แกอุตส่าห์หาจนเจอว่าสิ่งที่เขาอยากได้คือหน้าจอโง่ๆ จอเดียว แกทำให้เขาพอใจขนาดนั้นก็ได้เงินก็ถูกแล้วนี่ แพงตรงไหน”
ใช่ เขามาจากธุรกิจบริการ งานของเขาไม่ได้วัดที่ปริมาณ เขาวัดที่ว่าลูกค้าพอใจก็จบ จ่ายเป็นร้อยล้านก็ได้ถ้าความพอใจถึง
เขาไม่ต้อง Justify ว่า เห้ย ทำแค่นี้เอง ทำไมแพง
จริงๆ ปัญหามันอาจจะเกิดจากตอนที่เราคุยกัน เรามักมี Value proposition ในแบบของการ “ซื้อขายของ” แต่แรก
ตั้งแต่วันแรกที่เราเสนอโปรเจ๊กต์ เราก็บอกเขาว่า เรามีมากกว่า
แล้วที่สำคัญคือ หลายๆ ครั้ง เราเองก็เชื่อแบบนั้นด้วย
เราเชื่อจริงๆ นะ เชื่อจากใจเลย เชื่อในขนาดที่ว่า พอลูกค้าถามปริมาณ เราก็อึ้ง ตอบไม่ได้ ไม่สามารถบอกได้เต็มปากว่า “ปริมาณงานไม่เกี่ยว”
ซึ่งผมเห็นคนที่มาจากธุรกิจบริการ เขาไม่เห็นรู้สึกว่าจะมีปัญหาในการตอบกลับไปเลยว่า “ปริมาณงานไม่เกี่ยว”
ถ้าเราทำ Waterfall Model ที่ไม่เปลี่ยน เราสามารถวัดปริมาณงานได้ จากจำนวน Requirement และความยากของ Requirement
แน่นอนในโลกแบบนั้น มันง่ายที่จะขาย “ปริมาณ”
เราสามารถทำได้เท่ากันในราคาที่ถูกกว่า
เราสามารถทำได้ฟีเจอร์มากกว่าในเงินเท่ากัน
มันทำได้ มันเสนอจุดแข็งแบบนั้นได้ ถ้า Requirement มันนิ่งและชัดเจน
ในวันนี้ที่เราจะเป็น Agile โอเค ก็ดี
แต่ถ้า Branding ข้างนอก ที่เราให้ลูกค้ามองเข้ามา ยังเป็นเรื่องของ “สินค้า” อยู่ เราจะทำ Agile ได้ยังไง
เราจะตัดสิ่งที่ไม่จำเป็นออกได้ยังไง? เราจะเปลี่ยน Software ให้ Minimal และตรงกับใจลูกค้าที่สุดกลางโปรเจ๊กต์ได้ยังไง? แล้วเราจะคิดราคาเป็นจำนวน Sprint ได้ยังไง?
ถ้าเรายัง Justify งานของตัวเองด้วย “ปริมาณ” และ “ความสามารถ” อยู่ ยังอยู่ในโลกของการมองซอฟต์แวร์เป็น “สินค้า” เราก็จะยังติดอยู่ในวังวนเดิม
หลายครั้ง แค่บอกว่าทำไมตัวเองมีคุณค่า เรายังไม่กล้าบอกเลยว่า “ก็เราทำให้เขาพอใจได้มากกว่า” เพราะเรายังเชื่อว่า “ปริมาณ” สำคัญสุด เวลาคนมาถามว่า ปริมาณคุณน้อยจัง ทำไมแพง เราก็ได้แต่บ่นอุบอิบในใจ ไม่กล้าพูดเต็มปาก
ผมคิดว่า ถ้าเราจะเป็น Agile เราควรจะมองซอฟต์แวร์เป็นงาน “บริการ” แล้ววัดกันที่ความพึงพอใจมากกว่า
มันเข้ากับ Model ของ Agile กว่านะผมว่า
ถึงแม้ไม่ใช่ธุรกิจ แม้แต่ทำในองค์กร
หลายๆ ครั้ง ผมพบว่า Developer ยังวัดงานของตัวเอง ด้วยจำนวน Bug ที่แก้ไข จำนวน Line of code ที่ผลิต จำนวน Commit ใน Git หรือจำนวน Feature ที่ Released
ซึ่งมันง่ายที่จะวัด แต่มันจะเป็นสิ่งที่ดีจริงเหรอ
ผมว่ามันมี Measurable bias อยู่นะ คือ แทนที่เราจะมองว่าเป้าหมายจริงๆ ของงานคืออะไร แล้วหาตัววัดมาวัด เราดันไปหาอะไรก็ได้ที่วัดได้ง่ายๆ มาก่อน แล้วกำหนดเป็นเป้าหมายของงาน
จำนวน Feature วัดง่าย โอเค เอาเป็นเป้าหมาย เราเป็น Developer ที่ดี ต้องออก Feature เยอะๆ
จำนวน Bug วัดง่าย โอเค เราเอาเป็นเป้าหมายละกัน Developer ที่ดี ต้องแก้ Bug ได้เยอะๆ
ถามว่ามันเป็นเป้าหมายที่ดีจริงเหรอ?
ข้อนี้ผมคงตอบแทนแต่ละคนไม่ได้ เพราะแต่ละองค์กร มีโจทย์ไม่เหมือนกัน บางองค์กรอาจจะเป็นเป้าหมายที่ดี บางองค์กรอาจจะไม่ใช่
แต่ผมว่ามันก็มีคุณค่าพอที่เราจะลองมานั่งทบทวนกันจริงๆ จังๆ นะ ว่าตกลง มันเป็นเป้าหมายที่ดี จริงเหรอ?
หรือเราจะมองว่าตัวเองเป็น “คนบริการ” ไม่ใช่ “คนทำของขาย” ทำให้ Stakeholder พึงพอใจ ถามว่าความพึงพอใจของเขาคืออะไร แล้วก็วัดจากจุดนั้นอีกทีนึงดีล่ะ
แต่ละคนคงมีคำตอบไม่เหมือนกัน
แต่ก็เป็นคำถามที่อยากฝากให้ลองทบทวนดูครับ
