| Topic 50 | Coconuts Don't Cut It (มะพร้าวใช้แทนไม่ได้) |
|---|
ชาวเกาะพื้นเมืองไม่เคยเห็นเครื่องบินมาก่อน และไม่เคยเจอคนแปลกหน้าแบบนี้มาก่อนเลย แลกกับการใช้ที่ดินของพวกเขา คนแปลกหน้าเหล่านั้นก็ส่งนกกลไกที่บินเข้าออกตลอดทั้งวันบน “รันเวย์” มาให้ พร้อมกับความมั่งคั่งทางวัตถุมหาศาลสู่เกาะบ้านเกิดของพวกเขา คนแปลกหน้าพูดถึงเรื่องสงครามและการต่อสู้อยู่บ้าง วันหนึ่งทุกอย่างก็จบลง และพวกเขาก็จากไปทั้งหมด พร้อมกับความมั่งคั่งแปลกประหลาดนั้นติดตัวไปด้วย
ชาวเกาะพยายามอย่างสิ้นหวังที่จะเรียกโชคลาภของพวกเขากลับคืนมา จึงสร้างสนามบินจำลอง หอควบคุม และอุปกรณ์ต่าง ๆ ขึ้นมาใหม่ด้วยวัสดุท้องถิ่น เช่น เถาวัลย์ เปลือกมะพร้าว ใบปาล์ม และอื่น ๆ แต่ด้วยเหตุผลบางอย่าง แม้ว่าพวกเขาจะมีทุกอย่างพร้อมแล้ว เครื่องบินก็ไม่มาสักที พวกเขาเลียนแบบ “รูปแบบ” ได้ แต่ไม่ใช่ “เนื้อแท้” นักมานุษยวิทยาเรียกปรากฏการณ์นี้ว่า cargo cult
บ่อยครั้งเหลือเกินที่ เรา เองก็คือชาวเกาะเหล่านั้น
มันง่ายและน่าดึงดูดใจที่จะตกหลุมพราง cargo cult นี้ ด้วยการลงทุนสร้าง artifact ที่มองเห็นได้ชัดเจน คุณก็หวังว่าจะดึงดูดเวทมนตร์ที่ทำงานอยู่เบื้องหลังตามมาด้วย แต่เหมือนกับ cargo cult ดั้งเดิมในเมลานีเซีย [79] สนามบินปลอม ๆ ที่ทำจากเปลือกมะพร้าวไม่มีทางทดแทนของจริงได้เลย
ยกตัวอย่างเช่น เราเคยเห็นทีมที่อ้างว่าใช้ Scrum อยู่กับตาตัวเอง แต่พอลองตรวจสอบดูใกล้ ๆ กลับพบว่าพวกเขาทำ daily stand up meeting แค่สัปดาห์ละครั้ง ด้วย four-week iteration ที่มักจะกลายเป็น six- หรือ eight-week iteration พวกเขารู้สึกว่ามันโอเค เพราะพวกเขาใช้เครื่องมือจัดตารางแบบ “agile” ที่กำลังนิยมอยู่ พวกเขาลงทุนแค่กับ artifact ผิวเผินเท่านั้น—และถึงอย่างนั้นก็มักจะเป็นแค่ในชื่อเรียกเท่านั้น เหมือนกับว่าคำว่า “stand up” หรือ “iteration” เป็นคาถาวิเศษสำหรับคนที่เชื่อโชคลาง ไม่น่าแปลกใจเลยที่พวกเขาก็ล้มเหลวในการดึงดูดเวทมนตร์ตัวจริงมาเหมือนกัน
Context Matters (บริบทสำคัญ)
คุณหรือทีมของคุณเคยตกหลุมพรางนี้บ้างไหม? ลองถามตัวเองดูว่า ทำไมคุณถึงใช้ development method แบบนั้นตั้งแต่แรก? หรือ framework นั้น? หรือเทคนิคการ testing แบบนั้น? มันเหมาะกับงานที่คุณต้องทำจริง ๆ หรือเปล่า? มันได้ผลดีกับคุณจริงไหม? หรือมันถูกเอามาใช้เพราะแค่มันเป็นสิ่งที่เรื่องราวความสำเร็จจาก internet ล่าสุดใช้กันอยู่เท่านั้น?
ทุกวันนี้มีเทรนด์ที่คนชอบเอานโยบายและกระบวนการของบริษัทที่ประสบความสำเร็จอย่าง Spotify, Netflix, Stripe, GitLab และอื่น ๆ มาใช้ตาม แต่ละบริษัทก็มีแนวทางเฉพาะตัวของตัวเองในการทำ software development และ management แต่ลองคิดถึงบริบทดูสิ คุณอยู่ใน market เดียวกัน มีข้อจำกัดและโอกาสแบบเดียวกัน มีความเชี่ยวชาญและขนาดองค์กรใกล้เคียงกัน มี management แบบเดียวกัน และมีวัฒนธรรมแบบเดียวกันหรือเปล่า? มี user base และ requirement ที่คล้ายกันไหม?
อย่าหลงกลไปกับมัน artifact เฉพาะเจาะจง โครงสร้างผิวเผิน นโยบาย กระบวนการ และ method ต่าง ๆ ยังไม่เพียงพอ
| Tip 87 | ทำในสิ่งที่ได้ผล ไม่ใช่สิ่งที่กำลังเป็นเทรนด์ |
|---|
คุณจะรู้ได้ยังไงว่า “อะไรได้ผล”? คุณต้องพึ่งพาเทคนิคพื้นฐานที่สุดของความเป็น Pragmatic นั่นคือ
ลองมันดู
ลอง pilot ไอเดียนั้นกับทีมเล็ก ๆ หรือชุดของทีมเล็ก ๆ ก่อน เก็บส่วนที่ดีที่ดูเหมือนจะได้ผลดีเอาไว้ แล้วทิ้งส่วนที่เหลือไปในฐานะของเสียหรือภาระส่วนเกิน ไม่มีใครจะมาลดระดับองค์กรของคุณ เพียงเพราะมันทำงานต่างไปจาก Spotify หรือ Netflix หรอก เพราะแม้แต่บริษัทเหล่านั้นเองก็ไม่ได้ทำตามกระบวนการปัจจุบันของพวกเขาตอนที่กำลังเติบโตอยู่เหมือนกัน และอีกหลายปีต่อจากนี้ เมื่อบริษัทเหล่านั้นเติบโตเต็มที่ ปรับตัว และยังคงเติบโตรุ่งเรืองต่อไป พวกเขาก็จะทำอะไรที่แตกต่างออกไปอีกครั้งอยู่ดี
นั่นแหละ คือความลับที่แท้จริงของความสำเร็จของพวกเขา
One Size Fits No One Well (ไม่มีขนาดไหนที่พอดีกับทุกคน)
จุดประสงค์ของ software development methodology คือการช่วยให้คนทำงานร่วมกันได้ อย่างที่เราคุยกันไปแล้วใน Topic 48, The Essence of Agility ไม่มีแผนเดียวที่คุณจะทำตามได้เวลาพัฒนาซอฟต์แวร์ โดยเฉพาะแผนที่คน อื่น คิดขึ้นมาจากอีกบริษัทหนึ่ง
หลักสูตร certification หลายอันนั้นแย่ยิ่งกว่านั้นอีก เพราะมันตั้งอยู่บนสมมติฐานว่านักเรียนสามารถท่องจำและทำตามกฎได้ แต่นั่นไม่ใช่สิ่งที่คุณต้องการ คุณต้องการความสามารถในการมองข้ามกฎที่มีอยู่ และหาโอกาสที่จะใช้ประโยชน์ให้ได้เปรียบ นั่นเป็น mindset ที่ต่างไปจาก “แต่ Scrum/Lean/Kanban/XP/agile เขาทำแบบนี้กัน…” โดยสิ้นเชิง
แทนที่จะทำแบบนั้น คุณควรหยิบเอาส่วนที่ดีที่สุดจาก methodology ใด ๆ ก็ตาม แล้วปรับใช้ให้เข้ากับสถานการณ์ ไม่มีขนาดไหนที่พอดีกับทุกคน และ method ในปัจจุบันก็ยังห่างไกลจากความสมบูรณ์แบบ ดังนั้นคุณจะต้องมองไปมากกว่าแค่ method ยอดนิยมเพียงอันเดียว
ยกตัวอย่างเช่น Scrum กำหนด project management practice บางอย่างไว้ แต่ตัว Scrum เองก็ไม่ได้ให้แนวทางเพียงพอในระดับเทคนิคสำหรับทีม หรือในระดับ portfolio/governance สำหรับผู้บริหาร แล้วคุณจะเริ่มจากตรงไหนดี?
Be Like Them! (เป็นแบบพวกเขาสิ!)
เรามักจะได้ยินผู้นำด้าน software development บอกกับทีมงานของตัวเองว่า “เราควรทำงานแบบ Netflix สิ” (หรือบริษัทชั้นนำอื่น ๆ สักแห่ง) แน่นอนว่าคุณ ทำ แบบนั้นได้อยู่แล้ว
ก่อนอื่นเลย ไปหา server สักสองสามแสนตัว และ user หลายสิบล้านคนมาก่อนละกัน...
The Real Goal (เป้าหมายที่แท้จริง)
เป้าหมายจริง ๆ แล้วไม่ใช่การ “ทำ Scrum” “ทำ agile” “ทำ Lean” หรืออะไรก็ตามที่ว่ามา เป้าหมายคือการอยู่ในสถานะที่สามารถส่งมอบซอฟต์แวร์ที่ใช้งานได้จริง ซึ่งมอบความสามารถใหม่ ๆ ให้กับ user ได้ ในทันทีที่ต้องการ ไม่ใช่อีกหลายสัปดาห์ หลายเดือน หรือหลายปีข้างหน้า แต่คือ เดี๋ยวนี้ สำหรับหลาย ๆ ทีมและองค์กร continuous delivery ให้ความรู้สึกเหมือนเป็นเป้าหมายอันสูงส่งที่ไปไม่ถึง โดยเฉพาะถ้าคุณแบกรับ process ที่จำกัดการส่งมอบให้เหลือแค่ระดับเดือน หรือแม้แต่ระดับสัปดาห์ แต่เหมือนกับเป้าหมายอื่น ๆ ทั้งหมด กุญแจสำคัญคือการมุ่งหน้าไปในทิศทางที่ถูกต้องอยู่เสมอ
กราฟแสดงข้อมูลเวลาในการส่งมอบตามแต่ละช่วง แกนนอนแสดง entity สามแบบ ได้แก่ iteration แบบหลายเดือนหรือเป็นปี (waterfall), iteration แบบสั้นตายตัว (scrum) และ continuous delivery แกนตั้งแสดง entity ได้แก่ ชั่วโมง สัปดาห์ และปี กราฟแสดงบล็อกทั้งหมดเก้าบล็อก สามบล็อกแนวนอนแรกแสดง entity ของเวลาส่งมอบ (ปี) บล็อกที่สี่ถึงหกแสดง entity ของเวลาส่งมอบ (สัปดาห์) บล็อกที่เจ็ดถึงเก้าแสดง entity ของเวลาส่งมอบ (ชั่วโมง) มีเส้นโค้งที่ลดลงเรื่อย ๆ ลากผ่านบล็อกที่หนึ่ง สี่ และเก้า
ถ้าคุณกำลังส่งมอบเป็นระดับปี ลองย่นวงจรลงมาเหลือเป็นระดับเดือนดู จากเดือน ก็ตัดให้เหลือเป็นสัปดาห์ จาก sprint สี่สัปดาห์ ลองเหลือสองสัปดาห์ดู จาก sprint สองสัปดาห์ ลองเหลือหนึ่งสัปดาห์ จากนั้นก็เป็นรายวัน แล้วสุดท้ายก็ส่งมอบแบบ on demand โปรดสังเกตว่าการส่งมอบแบบ on demand ได้ ไม่ได้แปลว่าคุณถูกบังคับให้ต้องส่งมอบทุกนาทีของทุกวัน คุณส่งมอบตอนที่ user ต้องการ ตอนที่มันสมเหตุสมผลในเชิง business
| Tip 88 | ส่งมอบตอนที่ User ต้องการ |
|---|
เพื่อจะขยับไปสู่ style การพัฒนาแบบต่อเนื่องนี้ คุณต้องมี infrastructure ที่แข็งแกร่งดุจหินผา ซึ่งเราจะคุยกันใน topic ถัดไป Topic 51, Pragmatic Starter Kit คุณพัฒนาบน main trunk ของ version control system ของคุณ ไม่ใช่ใน branch แยกต่างหาก และใช้เทคนิคอย่างเช่น feature switch เพื่อ roll out ฟีเจอร์ที่กำลัง test อยู่ให้ user บางกลุ่มโดยเฉพาะ
เมื่อ infrastructure ของคุณเข้าที่แล้ว คุณต้องตัดสินใจว่าจะจัดระเบียบงานยังไง มือใหม่อาจจะอยากเริ่มด้วย Scrum สำหรับ project management บวกกับ technical practice จาก eXtreme Programming (XP) ส่วนทีมที่มีวินัยและประสบการณ์มากกว่าอาจจะมองไปที่เทคนิค Kanban และ Lean ทั้งในระดับทีมและอาจจะรวมถึงประเด็นเรื่อง governance ในระดับที่ใหญ่กว่าด้วย
แต่อย่าเพิ่งเชื่อคำพูดของเราไปซะทั้งหมด ลองไปสำรวจและทดลองแนวทางเหล่านี้ด้วยตัวคุณเอง แต่ก็ต้องระวังด้วยว่าอย่าทำมันมากเกินไป การลงทุนกับ methodology ใดอันหนึ่งมากเกินไปอาจทำให้คุณมองไม่เห็นทางเลือกอื่น ๆ ไปเลย คุณจะเคยชินกับมัน แล้วในไม่ช้าก็จะเริ่มมองไม่เห็นวิธีอื่นเลย คุณจะกลายเป็นคนแข็งทื่อ และตอนนี้คุณก็ปรับตัวได้เร็วเหมือนเดิมไม่ได้อีกต่อไปแล้ว
สู้ใช้มะพร้าวไปเลยดีกว่า
Related Sections Include (Section ที่เกี่ยวข้อง)
- Topic 12, Tracer Bullets
- Topic 27, Don't Outrun Your Headlights
- Topic 48, The Essence of Agility
- Topic 49, Pragmatic Teams
- Topic 51, Pragmatic Starter Kit