Shape Up – หยุดวิ่งวนอยู่ในลูป แล้วสร้างงานที่เป็นรูปธรรม

บันทึกจากหนังสือ Shape Up – Stop Running in Circles and Ship Work that Matters แนวทางการทำงานของบริษัท Basecamp ซึ่งผมหยิบประเด็นมาเท่าที่สนใจและอาจใส่มุมมองส่วนตัว – ไม่ใช่การแปลหนังสือนะครับ

บริษัท Basecamp เคยได้รับการประเมินว่ามี มูลค่าแสนล้านเหรียญ ทั้งๆ ที่มีพนักงาน 50 คน เป็นทีมพัฒนาโปรดักส์ Basecamp จำนวน 12 คน (Designer + Developer)

เค้าไม่ได้เปิดเผยกว่ารายได้และกำไรเป็นเท่าไหร่ บอกแค่ว่ากำไรหลายล้านเหรียญทุกปี และ กำไรทำให้เค้ามีอิสระ ไม่ต้องระดมทุนจากตลาดหุ้น ไม่ต้องกุมไข่ง้อใคร – $1 in profit is the ultimate FU money

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

ข้อแรก เราไม่ได้อินกับ Waterfall หรือ Agile หรือ Scrum • ข้อที่สอง เราไม่แปะ Post-it เต็มผนัง • ข้อสาม เราไม่มี Stand Up รายวัน, ไม่มี Sprint หรือการเร่งงานเป็นรอบให้เหนื่อยและหมดแรง เราไม่มี Backlogs ไม่ใช้ Kanban และไม่มี Velocity Tracking

Jason Fried

หมายเหตุจากเม่น – จริงๆ ไอเดียบางอย่างมันก็ตรงกับ Agile ทำงานเป็นรอบคล้าย Sprint นั่นแหละ อย่าไปหลงคารมการตลาดของทั่นเจสันมากนักเลย 555

เกริ่นนำ

เติบโตจึงเจ็บปวด

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

ลองผิดลองถูกมาหลายปี ทีม Basecamp พบแนวทางว่า

สร้างงานให้ได้ใน 6 สัปดาห์

แทนที่จะกำหนดขอบเขตงาน กำหนดเวลาก่อนดีกว่า ไม่งั้นโปรเจ็กก็จะเลื่อนไปเรื่อยๆ • เวลา 6 สัปดาห์นั้นนานพอให้ใคร่ครวญแต่ก็สั้นจนไม่อาจเอ้อระเหยได้ • ตั้งเป้าหมายแล้วให้อิสระการทำงานกับทีม โดยทีมที่เหมาะสมคือ ดีไซเนอร์ 1 คน โปรแกรมเมอร์ 1-2 คน

ขึ้นโครง (Shape) ก่อนส่งต่อทีม

เหล่าซีเนียร์ (หัวหน้าทีม ทั้ง Business, Dev, UX/UI) ต้องประชุมกันก่อนว่า ไอเดียนี้เจ๋งดีมั้ย เป็นไปได้หรือเปล่า ก่อนส่งต่อทีมทำงาน

Shape ➔ Bet ➔ Build

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

1. SHAPE – ขึ้นโครง ก่อนส่งต่อ

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

การขึ้นโครงมี 2 แนวทาง

1.1 ร่าง flow ในบอร์ดทดลอง

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

ตัวอย่างการร่าง Flow

โจทย์คือสร้างระบบ AutoPay – ให้ลูกค้ามาจ่ายเงินรายเดือนได้อัตโนมัติ เราก็ควรเริ่มร่างทีละขั้น เช่น เริ่มให้เค้าเปิดใช้งาน AutoPay จากหน้าใบแจ้งหนี้ได้ แล้วก็ไปที่หน้ากรอกรายละเอียดบัตรเครดิต กดส่ง ↓

แต่แล้ว ยอดค้างชำระเดิมล่ะ จะให้จ่ายเลยดีมั้ย? ก็เพิ่มตัวเลือกสีแดงในรูปไป ↓

แต่พอคิดไปคิดมา Flow จริงๆ มันควรเริ่มจากการกดจ่ายเงิน แล้วค่อยเปิด AutoPay ดีกว่านี่นา ↓

ถ้าคุยแบบนี้เสร็จ เวลาคนเอาไปทำ ก็จะเกิดปัญหาน้อย

1.2 วาดด้วยปากกาหัวอ้วนๆ

ตัวอย่างฟีเจอร์ Todo List ที่จัดกลุ่มได้ หากจะเพิ่มปุ่ม Add เราต้องใส่ในทุกกลุ่มมั้ย? หรือมันจะรกไป เอาไปซ่อนในอีกเมนูดีกว่า? ↓

อีกตัวอย่างคือ ฟีเจอร์ปฏิทินราย 2 เดือน รูปแรกคือบรีฟ รูปที่สองคืองานที่เสร็จ ↓

การใช้ปากกาหัวอ้วนๆ ทำให้เราไม่ลงรายละเอียดมากเกิน ทีมสามารถเอาไปต่อยอดได้ง่าย

ปิดความเสี่ยง

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

เตรียม Pitch

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

สิ่งที่ควรมีใน Pitch คือ

1. ปัญหาคืออะไร
2. จะใช้เวลาทำแค่ไหน? 1-6 สัปดาห์ (ไม่มีเกินนี้)
3. ทางแก้ที่เสนอ
4. การปิดความเสี่ยงที่คิดไว้
5. สิ่งที่ไม่ทำ ไม่รวมในขอบเขตงานนี้

ตัวอย่าง Pitch ของทีม Basecamp ➔

2. BETS – ทำหรือทิ้ง? ไม่ต้องทดไว้

เมื่อเหล่าซีเนียร์ขึ้นโครงต่างๆ ไว้พร้อมแล้ว ก็เอาสิ่งเหล่านั้นมา Pitch กับผู้บริหารบนโต๊ะเดิมพัน (Betting Table) ซึ่งประกอบด้วย CEO, CTO, Senior Dev, Product Strategist ที่เป็นกลุ่มเล็กและตัดสินใจได้เลย

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

เดิมพัน ไม่ใช่วางแผน

เค้าใช้คำว่าเดิมพัน เพราะมองว่าผลลัพธ์นั้นมีแค่สำเร็จ หรือ ล้มเหลว – ที่เปิดใช้งานจริงไม่ได้

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

ไม่มี Backlogs

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

เก็บสิ่งที่อยากทำไว้

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

ไม่ทำงานลอยๆ โดยไม่ผ่านการขึ้นโครงก่อน

ไม่มีการแทรกงานระหว่างรอบ

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

แต่งานไม่ออกก็ตัดจบ

เค้าใช้คำว่า Circuit Breaker ในความหมายว่า ต่อให้ทุกอย่างเลวร้าย ไม่เป็นไปตามที่ Pitch สิ่งที่สูญเสียสูงสุดคือ เวลา 6 สัปดาห์ของทีมนั้น (2-3 คน)

ทำไม่สำเร็จ ก็ตัดจบ เก็บบทเรียน แล้วไปขึ้นโครง (Shape) ใหม่ให้รอบคอบกว่าเดิม ไม่มีงานที่บานปลาย มีแค่มันไม่สำเร็จ

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

แล้วจัดการบั๊กยังไง?

เมื่อจบรอบ 6 สัปดาห์ เค้าจะมีคูลดาวน์อีก 2 สัปดาห์ (รวมเป็น 2 เดือนพอดี) ช่วง 2 สัปดาห์นี้ อาจนำมาใช้กับโปรเจ็กเล็กๆ หรือการเก็บบั๊กจุกจิก

แต่ถ้าบั๊กใหญ่ ก็นำไป Shape – Pitch – Bet เหมือนงานอื่นๆ ได้เลย

นอกจากนั้น ในบางช่วงของปี จะมีช่วงเวลาระดมทีมเก็บบั๊กด้วยกัน

คำถามสำคัญสำหรับ Bet

อิงตามใน Pitch เลย คือ

1. ปัญหาที่จะแก้ สำคัญจริงหรือเปล่า?
2. เวลาที่เลือกไว้ เหมาะสมมั้ย?
3. ทางแก้นี้ น่าสนใจมั้ย?
4. เหมาะที่จะเอามาทำตอนนี้มั้ย?
5. คนที่เหมาะกับงานนี้ มีคิวมั้ย?

แล้วถ้าเลือกเดิมพันกับงานนี้ ก็ประกาศให้รู้ทั่วกันทั้งองค์กร เพื่อเริ่ม Build

3. BUILD – สร้างงานที่เป็นรูปธรรม

มอบหมายทั้งโปรเจ็ก ไม่ใช่สั่งทีละอย่าง

Assign projects, not tasks คือการให้อำนาจและอิสระในการทำงาน จัดตารางและสร้าง Task เอง รับผิดชอบที่ผลลัพธ์ ไม่ใช่รอคนสั่งทีละงาน

เอาขึ้นเว็บ/แอปแล้วถึงเรียกว่าเสร็จ

Done means deployed หมายถึงทีมจะต้องพัฒนาและทดสอบ (QA) ให้ได้ภายในรอบงานนั้นๆ การโชว์ความคืบหน้าเฉยๆ ไม่เรียกว่างานเสร็จ

ทำสิ่งที่ยากก่อน ไปพร้อมกันทั้งทีม

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

ตัวอย่างการทำงาน

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

หมายเหตุจากเม่น – จากรูปทำให้ผมคิดว่า ดีไซเนอร์ของเค้า น่าจะต้องทำ Frontend เป็นด้วย ไม่งั้นงานมันจะรอกันนานเลย ตำแหน่งงานแบบนี้เรียกว่า Full Stack Designer นะครับ

เอาข้อมูลจริงมาออกแบบ

เวลาทำงาน เค้าก๊อบข้อมูลจริงมาใช้ออกแบบเลย (อันนี้ตรงกับแนวทาง Stop using lorem ipsum in your designs) แล้วขึ้นเว็บทดสอบ ปิดการเข้าถึงด้วย HTTPAuth ทำให้ปลอดภัยโดยไม่ต้องมีระบบซับซ้อน

กำหนดขอบเขตงาน (Scope)

การทำงานเหมือนการสำรวจดินแดน เราต้องทำแผนที่คร่าวๆ ว่าอะไรอยู่ตรงไหน จัดกลุ่มรวมกันเป็นพื้นที่ หรือสโคปงาน ที่สามารถทำให้สำเร็จทั้ง Frontend – Backend พร้อมกันได้

Map Outline ➔ Map Tasks ➔ Map Scope

ตัวอย่าง Scope และ Task

เราอาจจะเริ่มจากการจดสิ่งที่ต้องทำคร่าวๆ ก่อน อยู่ในกลุ่มชื่อ Unscoped แล้วพอมองภาพรวมออกว่า งาน 3 รายการนี้คือฟีเจอร์เพิ่มรายการใหม่ เราก็ค่อยย้ายไปรวมกันในกลุ่ม (Scope) ชื่อ Start New

พอทำไปเรื่อยๆ ก็อาจพบว่าแบ่งย่อยได้อีก ก็เพิ่ม Scope ไปเรื่อยๆ แล้วไล่ทำทีละ Scope ให้เสร็จ

ระหว่างทำ เราจะเจองาน 2 แบบ

1. Must-Have สิ่งที่ต้องทำ ไม่งั้นงานล่ม
2. Nice-to-Have มีก็ดี หากไม่มีก็ยังส่งมอบงานได้อยู่ ทีม Basecamp แนะนำให้ตั้งชื่อขึ้นต้นด้วย ~

งานงอก?

เมื่อทำไปเรื่อยๆ เราจะค้นพบว่า Tasks จะเพิ่มขึ้นมากกว่าตอนแรกที่ประเมิน เป็นเรื่องธรรมดา เพราะเราเข้าใจโปรเจ็กมากขึ้น (ทำให้ทีมเค้าไม่ประเมินงานจาก Task ที่เสร็จ เพราะบอกไม่ได้ว่าทำให้เกิดผลลัพธ์จริงๆ หรือเปล่า)

งาน เหมือนการขึ้นภูเขา

ทีม Basecamp ใช้วิธีเปรียบเทียบว่า งานมี 2 กลุ่ม กลุ่มแรกคือช่วงขึ้นเขา ยังไม่รู้ว่ามีอะไรอยู่ข้างหน้าบ้าง ไม่สามารถสรุปทุก Task ได้ กับ อีกกลุ่มคือช่วงลงเขา มั่นใจแล้วว่ามีงานอะไรทั้งหมดรออยู่

ยกตัวอย่าง เหมือนเราจะจัดงานปาร์ตี้ ถามว่าจะซื้ออะไรบ้าง ใช้เวลาทำเท่าไหร่ แบบนี้จะตอบไม่ได้

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

พอเอา Scope มาวางบนตำแหน่งเขา ทำให้ทีมเห็นภาพรวมว่า ที่ทำอยู่ตอนนี้ อยู่ในระยะไหน ↓

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

เนี้ยบแค่ไหนถึงพอ ?

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

หากดีกว่าเวอร์ชั่นปัจจุบัน (ตัวอักษรสีแดง ↓) แม้ไม่เนี้ยบอย่างในอุดมคติ ก็ควรพอและจบเฟสนี้ได้

ทุบ Scope ?

ทีม Basecamp ไม่ใช้คำว่าตัดสโคป (Cutting) แต่ใช้คำว่าทุบ (Hammering) ไปเลย เพราะทุกครั้งที่ออกฟีเจอร์ใหม่ ก็จะเกิดสโคปใหม่ๆ งอกมาเรื่อยๆ เราควรมองว่าทุกสิ่งเป็น Nice-to-have ไว้ก่อน อะไรที่ไม่มีแล้วโปรเจ็กไม่ล่ม อย่าเพิ่งไปทำ

ถ้าอยากทำฟีเจอร์ใหม่เพิ่มจริงๆ ก็ไปเริ่มต้นที่ Shape – Pitch – Bet ใหม่อีกรอบ อย่าเนียนเติมในเฟสปัจจุบัน

จะทำให้เราไม่มี หนี้งาน อันหนักอึ้งที่เกิดจากการรับปากคนอื่นไปก่อนว่า เดี๋ยวเพิ่มให้คร้าบ

บทสรุป

แนวทางการทำงานนี้ แม้จะน่าสนใจ แต่ก็ต้องลองไปปรับใช้ดู ทีมขนาดเล็กอาจไม่ต้องเสียเวลาทำครบทั้ง Shape – Pitch – Bet – Build ก็ได้ คิดแล้วทำเลยก็ได้

แต่เมื่อทีมใหญ่ขึ้น การแบ่งคนไปทำฝั่ง Shape แยกกับฝั่ง Build ก็จะทำให้รอบการทำงานเป็นเหมือนรูปด้านล่างนี้ ซึ่งแปลว่า เราจะสามารถออกฟีเจอร์ใหม่เทสเรียบร้อยได้ในทุก 2 เดือน ↓

เริ่มเอาไปใช้ยังไงดี?

1. ลองแบ่งคน ไปทำโปรเจ็ก 6 สัปดาห์แบบไม่มีการแทรกงานดู ให้ทีมรับผิดชอบที่เป้าหมาย แทนการมอบหมายงานยิบย่อย
2. หรือลองเริ่มที่กระบวนการ Shape – ขึ้นโครงก่อนส่งต่อทีม ให้ทีมทำงานได้ราบรื่นขึ้น
3. หรือลองขยาย Sprint จาก 2 สัปดาห์ เป็น 4-6 สัปดาห์ จะได้ลดเวลา Grooming / Retro / หรือเวลาประชุมยิบย่อยออกไป ให้ทีมมีเวลาโฟกัสงานมากขึ้น แล้วเมื่อเริ่มโล่ง คนก็จะเริ่ม Shape งานได้โดยปริยาย

หากสนใจรายละเอียดที่มากกว่าที่ผมทดไว้ สามารถดูที่เว็บ Shape Up ได้เลยนะครับ เค้าเปิดให้อ่านทั้งเล่มฟรีออนไลน์ หรือจะสั่งซื้อเป็นเล่มก็ให้ส่งมาไทยได้ ไม่นานครับ

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