หนังสือเล่มนี้ใช้ภาษาอ่านไม่ยาก คนทั่วไปอ่านได้ เหมือนกำลังฟังลุง Ron บ่นๆ ไปเรื่อยๆ เพื่อปูพื้นฐานและปรับทัศนคติ ใครอ่านที่ผมสรุปไว้และสนใจอยากลองหาฉบับเต็มมาอ่าน ลองดูได้จากลิงค์นี้ครับ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece

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

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

ค้นหาคุณค่าซอฟต์แวร์ของคุณให้เจอ

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

การทำให้เกิดคุณค่า จะเริ่มจากส่วนล่างสุดของพีระมิด ไล่เรียงขึ้นมา โดยเริ่มจาก…

• Guiding – ทีมทำงานต้องเข้าใจว่าอะไรคือสิ่งที่พวกเขาจะต้องทำ เราต้องการอะไร คุณค่าของงานคืออะไร เรามีทรัพยากร เช่น เครื่องมือ เวลา ฯลฯ อย่างไร
• Organizing – ใช้ความสามารถของทีมให้มีประสิทธิภาพ และสร้าง Team มีการพัฒนาความชำนาญขึ้นไปเรื่อยๆ
• Planning – วางแผน ตัดงานเป็นชิ้นตามคุณสมบัติ (Feature) ลำดับความสำคัญตามสิ่งที่ต้องการ เพื่อให้ได้สาระสำคัญของงานนั้นออกมาก่อน
• Building – สร้างงานเป็นชิ้นๆ ตามคุณสมบัติ (Feature) เพื่อส่งมอบงานให้ได้บ่อยๆ สามารถเห็นความคืบหน้าได้เรื่อยๆ
• Slicing – ตัดคุณสมบัติออกเป็นงานให้เล็กที่สุด ที่จะทำให้ส่องมอบงานได้ไว และส่งงานได้ตลอดเวลา
• Quality – นำวิธีการต่างๆมาประยุกต์ใช้เพื่อสร้างงานให้มีคุณภาพอยู่ตลอดเวลา

คุณค่าที่คุณคู่ควร (Value)

คุณค่า (Value)  คือ สิ่งที่เราทุกคนต้องการ (What you want) และในมุมมองของซอฟต์แวร์นั้น เราจะไดรับคุณค่าของมันก็ต่อเมื่อมีการส่งมอบคุณสมบัติ (Features) ของซอฟต์แวร์นั้นออกมา ไม่ว่าจะแบบจับต้องได้ อย่างการทำให้ประหยัดเงิน ประหยัดเวลา หรือจับต้องไม่ได้อย่างการช่วยสร้างความสะดวกสบายในชีวิต หรือทำให้ผู้ใช้ยิ้มได้ ดังนั้น ผู้เขียนจึงให้คำนิยามคำว่า Value คือ “What we want” 

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

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

ดังนั้น การแยกชิ้นงานเป็นชิ้นเล็กๆ คือ การแยกตามคุณสมบัติ (Features) เช่น คุณสมบัติต้องกันฝนกันลมได้ สิ่งที่ส่องมอบคือ โครงสร้างภายนอกของรถ, หรือคุณสมบัติรถสามารถเคลื่อนที่ได้ สิ่งส่งมอบคือ โครงสร้างภายนอกที่ปรอกับใส่ล้อและสามารถเคลื่อนที่ได้ เป็นต้น

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

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

มุ่งสู่สิ่งที่ดีกว่า ด้วยแนวคิดการทำทีละฟีเจอร์ (Guiding)

แบบที่เรารู้ๆกัน โครงการ (Project) ทุกชิ้นจะต้องมีกำหนดเวลาเสร็จชัดเจนเสมอ (Deadline) และต้องการได้ของครบทุกอย่างตามที่สั่งด้วย แต่พอนำไปปฎิบัติจริง ก็มักไม่ได้ตามนั้น, เพราะอะไร?

เพราะ การวางแผนที่ใช้ในโครงการส่วนใหญ่มัก จะทำเป็นก้อนใหญ่ และตัดเฟสโดยแบ่งตามประเภทกิจกรรม (Activity-based phase) เช่น เริ่มจากการวิเคราะห์ (Analysis) เสร็จแล้วนำไปออกแบบต่อ (Design) และก็ไปเขียนโค้ด (Coding) บลาๆๆ ซึ่งถ้าทำแบบนี้กว่าจะไปถึงเฟสหลังๆ จะรู้ได้อย่างไรว่า จะไม่เกิดบั๊กในภายหลัง หรือมีการเปลี่ยนแปลงความต้องการช่วงกลางทาง  ซึ่งถ้าเกิดเรื่องเหล่านี้ขึ้นมา ก็แปลว่าเราจะไม่สามารถส่งมอบงานที่สมบูรณ์ทั้งหมดได้ใช่หรือไม่? … คำตอบคือ ก็ใช่..

และถ้าเปลี่ยนเป็นทีมส่งมอบงานออกไปได้บ่อยๆ เริ่มตั้งแต่การวางแผนเป็นชิ้นงานเล็กๆ แบบทีละฟีเจอร์ (Feature by Feature) จากนั้นค่อยนำเข้ากระบวนการ ออกแบบ เขียนโค้ด ทดสอบ เสร็จงานก็ปล่อยฟีเจอร์นั้นออกไปขาย และค่อยเริ่มทำฟีเจอร์ชิ้นต่อไป แบบนี้จะดีกว่าไหมครับ?

การทำทีละฟีเจอร์ นอกจากส่งมอบงานได้บ่อยๆ ทำให้ลูกค้าเห็นความเคลื่อนไหวของงานแบบที่จับต้องได้อยู่ตลอดเวลา ลูกค้าเอาไปใช้งานได้ทันที ส่วนตัวทีมพัฒนาเองก็ดูแลโครงการทั้งหมดง่ายขึ้นด้วย เพราะดูแลเป็นฟีเจอร์เล็กๆ ให้เสร็จไปทีละส่วน ก็จะ Win-Win กว่าไหม?

อ่านถึงตรงนี้ลองนึกย้อนกลับไปเทียบกับสิ่งที่ตัวเองกำลังทำ หรือกำลังสั่งให้ทีมพัฒนาทำอยู่ ว่ามันดีกว่าหรือแย่กว่ากัน?..

วิธีจัดการงานทีละฟีเจอร์ให้มีประสิทธิภาพ (Organizing)

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

ดังนั้น วิธีการแก้ปัญหาคือ สร้างทีมทีมีผู้รู้ในแต่ละเรื่องที่จำเป็นสำหรับฟีเจอร์นั้นๆ มารวมกัน หรือเรียกว่า Feature Team

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

ในกรณีที่เรามีผู้เชี่ยวชาญในแต่ละด้านไม่เพียงพอเพื่อจับไปลงทีม เราควรหาผู้ที่มีความรู้ (อาจไม่จำเป็นต้องถึงขั้นผู้เชี่ยวชาญก็ได้) และสร้างกลุ่ม Community of Practice ขึ้นมา โดยให้ผู้รู้คนนั้นสอนคนอื่นๆ ในส่วนที่มีความจำเป็นต้องใช้ทำงาน เช่น Database Community of Practice หรือ UX Community of Practice

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

ลุง Ron ทิ้งท้ายไว้อย่างสะกิดต่อมเซเลบลัมในสมองว่า “ผู้เชี่ยวชาญที่เราจ้างมาด้วยราคาสูง ไม่ใช่จ้างมาเพราะเขาเป็นผู้เชี่ยวชาญเท่านั้น แต่ควรจ้างเขาเพื่อสร้างให้คนอื่นเป็นผู้เชี่ยวชาญได้เช่นกัน” (A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.)

การวางแผนทำทีละฟีเจอร์ (Planning)

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

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

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

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

(อ่านมาถึงตรงนี้ จู่ๆผมก็นึกถึงบริษัทที่ผมเคยทำงานด้วย, สมัยก่อนผมขึ้นต้นด้วยการอธิบายวิธีการเลย ผู้ใหญ่ไม่ต้องรู้หรอกว่ามันดีอย่างไร แต่มันดีนะ ให้ผมทำไปเถอะ เชื่อผม…. และแล้ว เขาก็ไม่ได้เห็นด้วยกับวิธี และไม่อนุมัติให้ทำ.. เพราะเราไม่ได้ตัดแบ่ง ทำ Pilot Team, Pilot Project ทดลองให้เขาดูก่อน)

การส่งมอบงานออกมาเรื่อยๆ แบบนี้ จะเรียกรอบส่งงานนี้ว่า Iterations หรือ Sprints, โดยฟีเจอร์ (Feature) ที่ส่งมอบ จะเรียกว่า Story ซึ่งการทำงานแบบนี้ จะต้องวางแผนอยู่ตลอดเวลา เพราะมีการปรับเปลี่ยนเรื่อยๆ ไม่สามารถวางแผนในครั้งแรกครั้งเดียวแล้วใช้ได้เลย (ย้อนกลับไปย่อหน้าบนๆ อีกเช่นกัน ว่าทำไมไม่ต้องลงรายละเอียดกับมัรเยอะ และทำไมเรามักมีปัญหาเมื่อแผนเปลี่ยน)

ลุง Ron บอกว่า ไม่แนะนำให้ทำเป็น Story ใหญ่ๆ, ไม่แนะนำให้แตกงานย่อยๆ ออกมาเป็น Task ที่มีแต่ด้านเทคนิค (Technical) เพราะฝั่งที่ไม่มีความรู้ด้านเทคนิคจะอ่านไม่เข้าใจเลย และอีกประเด็นคือ การแปลง Story ออกมาเป็นฟีเจอร์เล็กๆ จะใช้เวลาทำและเข้าใจง่ายกว่าเป็น Technical Task

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

ลุง Ron เตือนไว้ว่า ในขณะที่วางแผน อย่าไปใส่ความท้าทายให้เป้าหมาย (stretch goals) เช่น “ลองใส่เพิ่มไปอีก 1 ฟีเจอร์ซิ๊” การทำแบบนี้มันจะทำให้ทีมพยายามทำมันให้เสร็จ โดยที่พวกเขาต้องเร่งทำงานอื่นให้เร็วขึ้น ทดสอบน้อยลง โค้ดลดคุณภาพลง เพียงเพราะต้องหาเวลาเพื่อรับความท้าทายขึ้นอีกแค่ 1 ฟีเจอร์ และท้ายที่สุดเราอาจจะได้งานช้าลงเพราะทีมต้องกลับมาปรับปรุงโค้ดหรือแก้ Defect ที่เกิดขึ้นในภายหลัง

“ความกดดันเป็นสิ่งที่อันตราย พยายามลีกเลี่ยงมัน”

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

สร้างมันขึ้นมาทีละฟีเจอร์ (Building)

ประโยชน์ของการย่อยงานทำทีละฟีเจอร์ (Feature by Feature) ทีมและองค์กรจะได้เรียนรู้ และเห็นผลของงานได้เร็ว สามารถเปลี่ยนแปลง ปรับปรุง การทำงานและตัวงานได้ตลอดเวลา (หรือเรียกกันว่า False Fast, Learn Fast)

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

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

ในการทำงานแบบเดิม เราต้องรอจนถึงเฟส Test ถึงจะพบว่ามี Defect อะไรบ้าง ซึ่งมันอาจมีมากหรือน้อยจนทำให้ใช้เวลาเกินที่วางแผนไว้ แต่หากทำเป็นรอบและทุกรอบมีการ Test อยู่แล้ว เมื่องานทั้งหมดใกล้เสร็จ เราก็ไม่ต้องกังวลกับ Defect ก้อนโตในตอนท้าย (ผู้เขียนใช้คำว่า “nearly free of defects” คืองานเกือบจะไม่มีข้อผิดพลาดเกิดขึ้น)

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

แนวคิดแบบแนวตั้ง และสร้างเท่าที่จำเป็น  (Build Feature and Foundation in Parallel)

ฟีเจอร์ของซอฟต์แวร์ต้องมีโครงสร้าง (Foundation) ของซอฟต์แวร์ที่ดี, แต่สิ่งที่เราต้องคิดคือ จะทำอย่างไรให้ทั้งสองอย่างสมดุลและเสร็จไปพร้อมกันได้ ในเวลาที่จำกัด และเท่าที่จำเป็น

หากเรามัวแต่ไปทำโครงสร้างพื้นฐานของซอฟต์แวร์ เช่น ออกแบบ Framework สุดหรู, สร้าง Library ที่พร้อมใช้ทุกอย่าง แต่แล้วฟีเจอร์ต่างๆ ที่เป็นคุณค่าของซอฟต์แวร์ ไม่เสร็จ หรือเสร็จไม่ครบ แบบนี้ซอฟต์แวร์ของเราจะไปมีค่าอะไร เพราะมันใช้งานไม่ได้ตามที่ลูกค้าต้องการ

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

พัฒนาฟีเจอร์ออกมาเพื่อให้ใช้งานได้ก่อน โดยทำขึ้นมาอย่างง่ายๆ หรือที่เรียกว่า MVP – “Minimum Viable Product” จากนั้นค่อยกลับมาเก็บรายละเอียดให้ดีอีกครั้ง

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

การออกแบบที่ดี และไร้ข้อผิดพลาด (Bug-Free and Well Designed)

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

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

ดังนั้น สิ่งที่ควรทำในการทำซอฟต์แวร์ คือ ต้องป้องกัน (Prevent) ไม่ให้เกิดข้อผิดพลาด มากกว่าการมาตามแก้ไขข้อผิดพลาดในภายหลัง (Fix)

สิ่งที่เราจะเริ่มทำคือ ทดสอบระบบด้วยการทดสอบระดับ Business ว่าสามารถใช้งานได้ตามที่ต้องการไหม หรือที่เราเรียกว่า Acceptance Test-Driven Development (ATDD) และค่อยต่อด้วยทดสอบระดับ Technical ด้วยวิธีการต่างๆ

ซอฟต์แวร์ของเราจะใหญ่ขึ้นเรื่อยๆ ตามจำนวนฟีเจอร์ที่เพิ่มและโค้ดที่เขียน ดังนั้นจะใช้เวลาและยากมากที่ต้องทดสอบทั้งหมดทุกครั้งหลังจบรอบการทำงาน (System Test, Integration Test) ดังนั้น ทีมพัฒนาควรทำ Automate Tests ให้ครอบคลุมทั้งระบบงาน หรือออกแบบทำไว้ตั้งแต่ก่อนพัฒนาระบบ หรือที่เรียกกันว่า Test-Driven Development (TDD)

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

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

ดังนั้น ในทุกรอบการทำงาน เพื่อให้ระบบเราสอดคล้องกับฟีเจอร์ใหม่ในรอบนั้นๆ ควรให้ความสำคัญถึงการทำ Refactoring Code ด้วย เพื่อไม่ให้เกิดความยุ่งยากซับซ้อนในรอบทำงานต่อๆไป

Test และ Refactor ทั้งสองอย่างนี้เป็นเรื่องสำคัญของการพัฒนาระบบแบบ Feature-by-Feature เพราะจะทำให้งานเรามีคุณภาพได้ตลอดเวลา เพื่อพร้อมส่งมอบงานให้ลูกค้าได้เสมอ

ส่งท้าย

จากที่สรุปมาให้อ่านทั้งหมด ผมสังเกตได้ว่า ลุง Ron Jeffrie มีคำที่พยายามย้ำอยู่เรื่อยๆไม่กี่คำ คือ คุณค่า (Value), ทีม (Team), การพัฒนาทักษะ (Learn), การทำงานเป็นรอบ (Iteration) และ การทำทีละฟีเจอร์ (Feature-by-Feature), การส่งมอบ (Shipable)

ดังนั้น หัวใจหลักของการพัฒนาแบบ “The Nature Way” ที่ลุง Ron เอามาเสนอ เราต้องให้ความใส่ใจกับคำ 6 คำนี้แหละครับ ส่วนใครอ่านไปแล้วจะคิดต่อหรือหาความรู้เพิ่มเติม จากนั้นเอาไป Adapt & Implement กันอย่างไร ก็คงขึ้นอยู่กับแต่ละวัฒนธรรมองค์กร

ขอให้สนุกครับ

—

ที่มาของเนื้อหาและรูปภาพ จากหนังสือ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece เขียนโดย Ron Jeffries

ชีวิตมั่งคั่งด้วยกระเป๋าสตางค์ใบเดียว

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

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

รายได้ต่อปี = ราคากระเป๋าสตางค์ x 200

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

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

ช่วง 2-3 ปี มานี้ ผู้หลักผู้ใหญ่ระดับบริหาร ที่เรามักมีภาพในหัวว่า เขาต้องเคร่งขรึม ได้แสดงออกไปในทาง “เซอไรพส์!..” (โปรดทำเสียงสูงๆ)

ด้วยความน่าเชื่อถือของพวกเขา เมื่อได้ออกมาสื่อสารกับคนทั่วไปแบบคนทั่วไปแล้ว (เอ๊ะยังไง!?!)
ก็คงไม่แปลกที่การทำ CEO Branding จะประสบความสำเร็จ
เช่น คุณซิกเว่ เบรกเก้ ออกมาปั่นสามล้อโปรโมทดีแทค, คุณตันภาสกรบนจอทีวีโฆษณาขายชาเขียว,
คุณวิกรม กรมดิษฐ์เขียนหนังสือผมจะเป็นคนดี, คุณก่อศักดิ์ ไชยรัศมีศักดิ์เขียนหนังสือซีอีโอโลกตะวันออก,
พี่ป้อมภาวุธโฆษณาตลาดดอทคอมบนสื่อออนไลน์
แล้วก็อีกหลายๆท่าน

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

อาทิตย์ที่แล้วพี่สาวผมเพิ่งฝากซื้อหนังสือ “บรรยง พงษ์พานิช คิด” แน่นอนว่ามีเขียนสอดแทรกวัฒนธรรมองค์กรเหมือนกัน เพราะเขาคือ ประธานกรรมการ บริษัท หลักทรัพย์ ภัทร จำกัด (มหาชน)

พอผมได้ยินชื่อเท่านั้นแหละ “ใครวะ ไม่รู้จัก!?!”
ก็เลยไปซื้อให้ แล้วแอบอ่านก่อนส่งมอบ
เท่านั้นแหละคุณเอ๋ย ผมก็ยังไม่รู้จักเขาอยู่ดี (ฮ่าๆ)
เอาเป็นว่าผมจะรู้หรือไม่รู้ก็ไม่ใช่ประเด็น แต่หนังสือเล่มนี้เป็นอีกเล่มหนึ่งที่คนระดับผู้บริหารได้เขียนและใช้สำนวนอ่านง่าย

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

ปล. โปรดเอาใจช่วย CEO Branding คนต่อไป ที่อาจเป็นป้าผม (คุณยาใจ ไวพยาบาล) หัวหน้าสหกรณ์จังหวัดอุตรดิตถ์ ตอนนี้ชีขึ้น Cover เป็นรูป ถั่วเขียวพันธุ์ชัยนาท 72 คาดว่ากำลังโน้มน้าวให้สมาชิกสหกรณ์ปลูกเป็นพืชเศรษฐกิจ

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

ปล1. ตอนซื้อคิดว่าราคา 220 บาทแพงแล้วนะ แต่พอได้อ่านทั้งหมด มันก็ยังรู้สึกแพงเหมือนเดิม (เอาเถอะ ยอมจ่ายให้แกไปเที่ยวรอบโลกแล้วกยับมาเขียนเล่มสามต่อ)
ปล2. ไม่เหมาะแก่การเอาไปอ่านในส้วม หรือในอ่าง แม่งเปียกแล้วบวม เป็นรอยนิ้วมือ

ผมพบว่าปัญหานี้อยู่รอบตัวเรา และผลกระทบมันก็มีอยู่ แต่ต่างกันแค่ระยะเวลาที่ใช้ กับความสำคัญของเรื่องที่จะต้องตัดสินใจ ถ้าในระดับชาติ อาจยกตัวอย่างได้ว่า ประชาชนต้องการให้รัฐบาลป้องกันน้ำที่กำลังไหล่บ่ามาท่วมชุมชนของพวกเขา แต่รัฐบาลและนักวิชาการกำลังทะเลาะกันเรื่องทฤษฎีป้องกันน้ำ เช่น จะใช้ถุง Big Bag หรือ น้ำดันน้ำ อะไรก็ว่ากันไป กว่าจะตัดสินใจได้ ประชาชนก็จทน้ำไปเรียบร้อยแล้ว หรือเรื่องบางเรื่องก็ถูกยืดเยื้อไว้ หรือภาษาชาวบ้านเรียกว่าการดอง เช่น การสร้างถนนในบางเส้น ที่อาจไปทับที่ของผู้ใหญ่หรือทับที่ป่าบางส่วน จะลุยต่อก็เจ็บตัว จะไม่ทำก็โกงกินไม่ได้ สุดท้าย ก็ดองไว้เหมือนเดิม (อาจจะอีกตัวคือโฮปเวล) ซึ่งผมว่าประเทศเราเห็นชัดเจน เพราะด้านหนึ่งหลังชนฝาเรื่องโกงกินจึงจำเป็นต้องสร้าง แต่อีกด้านหนึ่งเจอการขัดขาเพราะจับได้หรืออะไรก็ว่าไป แล้วก็เกิดการดองเกิดขึ้น

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

ต่อให้มี Decision making theory, Change Management, Risk managment หรืออะไรก็ตามที่ช่วยทำให้วางแผนวิเคราะห์กับสิ่งที่จะเกิดในการตัดสินใจในแต่ละอย่าง สุดท้ายแล้ว เมื่ออยู่ในโลกความเป็นจริง และกับคนหมู่มากที่ล้วนมีอำนาจ มีเงิน เชื่อมั่นในตัวเองสูง ทุกอย่างที่กล่าวมาอาจถูกมองข้ามไป

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

แต่ทั้งนี้ทั้งนั้นผมก็ไม่ได้บอกให้รีบด่วนตัดสินใจ หรือให้ไม่ต้องคิดมากเพื่อจะตัดสินใจนะ เพียงแค่อยากให้เข้าใจว่า “ไม่มีอะไร perfect แต่ก็ต้องมีแผนรับมือกับความบกพร่อง”

ปล. แนวคิดนี้ผมแอบคิดถึงวิธีการพัฒนาระบบแบบ Scrum คือแบ่งงานออกเป็น Sprint เสร็จเป็นรอบๆ ไม่ต้องสมบูรณ์ครบทุกอย่างตามที่สั่ง แต่ก็สามารถใช้งานได้ เท่าที่ระบบจะมี แล้วค่อยๆทำเพิ่มต่อไปเรื่อยๆๆ จนสมบูรณ์ภายหลัง ส่วนเรื่องความพร้อมในการรับมือความบกพร่อง นอกจาก Test แล้ว ยังต้องมีแผนสำรองด้วย ทั้งนโยบาย(แผนสำรอง), ระบบ, Operation

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

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

ดังนั้นผู้บริโภคแบบเราควรมีเกราะป้องกันการตลาดแบบนี้ดีๆ
นั่นคือ สติและปัญญา เท่านั้น ที่จะรู้เท่าทันอารมณ์และความต้องการของตนเอง
และระงับความอยากได้

จะว่าไปนอกจากในรูป ก็มีเล่มดังๆ อีกสองเล่ม ที่น่าอ่านมากของ Dan Ariely คือ

“พฤติกรรมพยากรณ์ (Predictably Irrational)”
และ “เหตุผลที่ไม่ควรมีเหตุผล (The Upside of Irrationality)”

ของพวกนี้ เป็นดาบสองคม แต่ถ้าเราอ่านเอาสนุก อ่านเอาความรู้
อ่านเอาความเท่าทันของการตลาด ก็จะดีมากครับ ผมแนะนำเลย

The Go-Giver: A Little Story about a Powerful Business Idea 

เป็นหนังสือที่เขียนโดย Bob Burg และ John D. Mann เล่าถึงเรื่องพลังแห่งการให้

ผมคงไม่ขอลงรายละเอียด เนื่องจากไม่ได้อ่านเต็มๆครับ แต่ได้ตามอ่านจากบทความสรุปมา

น่าสนใจมาก โดยเฉพาะ กฏที่ชื่อว่า

Five Laws of Stratospheric Success

1. The Law of Value: Your true worth is determined by how much more you give in value than you take in payment.
2. The Law of Compensation: Your income is determined by how many people you serve and how well you serve them.
3. The Law of Influence: Your influence is determined by how abundantly you place other people’s interests first.
4. The Law of Authenticity: The most valuable gift you have to offer is yourself.
5. The Law of Receptivity: The key to effective giving is to stay open to receiving.

ซึ่งได้มีผู้แปลเป็นภาษาไทยดังนี้ครับ

กฎห้าข้อแห่งความสำเร็จล้นฟ้า

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

ที่มาคำแปลภาษาไทย http://honglub.com/