คำถามที่คนอยากรู้ แต่ตอบยังไงให้ถูก ถ้างานที่อยากได้ มันเป็นงานที่สามารถประเมินได้ง่าย เช่นเอาน๊อตใส่รูแล้วขันสามรอบ งานแบบนี้ค่อนข้างประเมินง่าย เพราะเรารู้ flow รู้ speed รู้ความสามารถของคนที่ทำว่าทำได้กี่ตัวต่อนาที และยิ่งรู้จำนวนคน แบบนี้ก็ยังพอประเมินได้บ้าง แต่ว่า งานแบบเขียนโปรแกรม มันต่างออกไปอย่างมาก มันทำให้การประเมินทำได้ยากแบบที่ ถ้าจะให้ประเมินได้ถูก มันต้องมีสักคนที่เจ็บตัว ไม่ว่าจะเป็นกลุ่ม Developer ที่ถ้าประเมินวันมาน้อยเกินไป ก็ต้องทำงานกันหามรุ่งหามค่ำ และก็อย่างที่รู้ๆกันว่า OT มันมีแค่ทำงานล่วงเวลา แต่ค่าล่วงเวลามันไม่มี หรือถ้ามันไม่ทันจริงๆในที่สุด คนที่เจ็บก็ต้องเป็น Business เพราะส่วนมากจะไปสร้าง commitment เอาไว้ โดยเฉพาะอย่างยิ่ง ถ้ามีการตลาดเข้ามาเกี่ยวด้วยจะยิ่งเจ็บหนัก…

Feature นี้ใช้เวลาเท่าไร?
Feature นี้ใช้เวลาเท่าไร?

ในกลุ่มที่ทำ Agile Team ในงาน Software Dev ปกติเราจะมีหนึ่งกิจกรรมที่มักจะนัดกันในช่วงเช้า ก่อนเริ่มต้นทำงาน เพื่อให้ได้ sync-up กันไวไว ว่าเมื่อวานแต่ละคนทำอะไรไปที่เป็นเรื่องสำคัญ และติดปัญหาอะไรหรือไม่ ต้องการความช่วยเหลือหรือเปล่า และวันนี้คิดจะทำอะไร ซึ่งโดยปกติในทีมที่มีคนราวๆ 10 คน อาจจะใช้เวลาประมาณแค่ 5 นาทีก็อาจจะจบ meeting นี้ได้เลย

เราเรียกกิจกรรมแบบนี้ว่า Standup Meeting หรือบางทีก็เรื่อง Daily Scrum หรือชื่ออื่นๆที่ถนัดและเข้ากับกระบวนการที่ใช้

และบางกรณีก็จะเจอทีมที่ชอบ update เรื่องพวกนี้กันในช่วงก่อนเลิกงานก็เป็นได้ และบางทีก็อาจจะแค่พิมพ์หากันในช่องทางเฉพาะ เพื่อให้ทีมได้มีโอกาสเลือกที่จะใช้เวลาที่ตนเองสะดวกเข้าไปอ่าน หรือแม้แต่เลือกที่จะไม่อ่านก็เป็นสิทธิ์โดยชอบเช่นกัน

ผมสังเกตได้ว่า บางทีม จะใช้เวลาในช่วง Standup นี้แบบผิดวัตถุประสงค์ คือแทนที่จะใช้ sync-up กันแล้วจบ แต่อาศัยจังหวะที่มีคนพูดถึงเรื่องที่ตัวเองมีประเด็น ก็จะ hook เรื่องนั้นออกไปนอกจุดประสงค์ และพาทีมคุยงานไปเรื่อยๆ ทำให้การ standup นั้นใช้เวลายืดยาวออกไป ถ้าโชคดีก็จะจบได้เร็วเหมือนกัน แต่รวมๆก็จะใช้เวลามากกว่าที่ควรจะเป็นไป 2–3 เท่า

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

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

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

ในอดีต จั๊ว SM ทีมผมเคยให้เราทดลอง plank ไป sync-up ไปด้วยซ้ำ เพื่อไม่ให้เราใช้เวลานานเกินไปในการ update เพราะโดยปกติเราก็นั่งด้วยกันอยู่ทั้งวัน คุยกันทั้งวันอยู่แล้ว การมีกิจกรรมนี้ก็เพียงแค่ทบทวนเรื่องสำคัญๆ ให้สมาชิกทั้งหมดรับรู้เรื่องราวในทีมให้ตรงกัน

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

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

--

--

ในหลายๆอุตสาหกรรม จะมีวิธีการจัดการในการผลิตผลงานออกมาแตกต่างกัน แม้แต่ในอุตสาหกรรมซอฟท์แวร์เอง ซึ่งในหลายกรณีมันจะสะท้อนออกมาอยู่ในรูปแบบการจัดการองค์กรนั้นด้วย ผมยกตัวอย่างการจัดการทีมแบบแยกตาม function เช่นทีม Dev ที่มีการแยกเป็น ทีม Backend ทีม Frontend Web ทีม Frontend iOS ทีม Frontend Android ทีม DevOps ทีม Operations Support การแบ่งทีมตาม function จะช่วยให้แต่ละทีมมี skillset เฉพาะชัดเจน และทีมจะชำนาญงานนั้นๆมาก โดยส่วนตัวผมมักจะเห็นการแบ่งทีมแบบนี้ กับการใส่งานลงไปแบบที่มองทีมเป็น pool โดยไม่ว่าใครจะอยากได้งานแบบไหน ก็จะมีทีม PM/BA/Architect ไปคุยกันมาจนเสร็จ เหลือแค่เขียนโค้ด ก็จะแยกงานตาม function แล้วโยนใส่ pool ลงไป เดี๋ยวก็เสร็จ…

ทีมที่งานที่เสร็จแล้วใช้งานได้
ทีมที่งานที่เสร็จแล้วใช้งานได้

ในฐานะ developer คนหนึ่ง ผมเคยสงสัยมาก ว่าใครเป็นคนปักวัน release ให้งานที่ผมทำ และเขารู้ได้อย่างไร ว่าผมจะทำทัน

สิ่งที่น่าเหลือเชื่อคือ ผมทำทันทุกครั้ง 😅 แต่ไม่ต้องห่วง ผมมี bug ให้ไม่น้อยอยู่แล้ว แต่ bug ก็ไม่ใช่เรื่องที่ผมสนใจที่สุด สิ่งที่ผมให้ความสำคัญคือการทำงานให้เสร็จอยู่แล้ว

Road Between Trees and a Cliff Covered With Fog · Free Stock Photo (pexels.com)

fixed time คือการจำกัดเวลาทำงาน เช่นงานนี้เรามีเวลา 1 เดือน หรือ 6 เดือน

fixed scope คือเรามีฟีเจอร์ที่ต้อง release ให้ได้ตามที่สัญญาไว้

ปกติเราจะ fixed ได้อย่างใดอย่างหนึ่ง

ยกตัวอย่างเช่น ถ้าผมจะเดินทางจาก เพชรบุรีกลับ กทม สมมุติระยะทาง 180km ถ้าผม fixed time ไว้ที่ 30 นาที นั่นแปลว่า ผม fixed scope และ time ในเวลาเดียวกัน เพราะ scope ของผมคือต้องเดินทางให้ได้ 180km ซึ่งโดยปกติ มันเป็นไปได้ยาก เพราะไม่งั้น เราอาจจะต้องลงเอยที่งานไม่เสร็จ และอาจจะต้อง delay หรือต้องยอมลด scope ลง

ลองคิดดูว่า ถ้าผมต้องเดินทาง 180km ให้ได้ใน 30 นาที ผมต้องใช้ความเร็ว 360km/h ซึ่งในความเป็นจริง ความเร็วระดับนั้น ระดับ shinkansen ยังได้ราวๆ 320km/h ถ้าเราจะขับรถ ความสามารถของรถน่าจะทำความเร็วระดับนั้นไม่ได้จริง เพราะปัจจัยแวดล้อมเช่น ถนน และกฏจราจร

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

เพิ่มคนสิ

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

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

แต่ถ้าจะ fixed time เช่นมีเวลาเดินทางแค่ 30นาที ก็ต้องยอมรับว่า เราอาจจะไปได้ 0–60 km จากจุดเริ่มต้นโดยประมาณ ซึ่งอาจจะไปไหนไม่ได้เลยด้วยซ้ำถ้ามีปัจจัยภายนอกเข้ามาเกี่ยวข้องเหมือนข้างต้น

เรื่องนี้ก็เป็นการยกตัวอย่างง่ายๆว่าทำไมเราถึงไม่ควร fixed time และ fixed scope ในงานเดียวกัน และขออภัยหากตัวอย่างไม่ได้สร้างความเข้าใจมากเพียงพอนะครับ

--

--

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

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

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

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

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

รูปไม่เกี่ยวข้องกับเนื้อหาแต่อย่างใด

แต่ที่เจอส่วนมากจะเป็นแบบ แนะนำให้ทำ หรือบอกให้ทำ หรือบางทีอาจจะสอนให้ทำ แต่ไม่ลงมือทำให้เห็นก่อน

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

พอมันเป็นเรื่องไกลตัว ก็จะมีทางเลือกไม่มากคือ 1. ทำส่งๆไปให้เสร็จ 2. ทำตามความเข้าใจ หรือหยิบเอาของที่ใกล้เคียงมาทำให้ 3. ปล่อยไหล ไม่ทำ หรืออาจจะมีอย่างอื่นด้วยก็ได้ ที่สุดท้าย หัวหน้าก็จะงงว่า อิหยังวะ!! ใช่ที่บอกไปไหมนี่

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

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

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

--

--