พอดีมีแรงบันดาลใจให้อยากแปล blog อันหนึ่งซึ่งเคยมีเพื่อนที่บริษัทส่งมาให้เมื่อนานมาแล้ว เนื้อหามันก็มีว่า
โพสท์นี้มาจากบทสนทนาจริงระหว่างผมกับเพื่อนคนหนึ่งที่ทำจากอยู่บริษัท System Integration ขนาดยักษ์แห่งหนึ่ง บริษัทเขาก็เหมือนกับหลายๆบริษัทตอนนี้ ที่ใช้คำฮิตคำใหม่ว่า Agile ไปโฆษณาจนเกร่อบนเวปของบริษัท แต่ความเป็นจริงหาได้เป็นเช่นนั้นไม่ ความเข้าใจกับคำว่า Agile ของบริษัทยักษ์ใหญ่เหล่านี้กับนิยามของ Agile ที่แท้จริงนั้นต่างกันลิบลับ
บริษัทเหล่านี้ทำโปรเจคเป็นร้อยๆโปรเจคพร้อมๆักัน บ้างก็เป็น Agile จริงแต่ก็มีหลายทีมที่ไม่ใช่
สิ่งที่ตามมาคือความจริงที่เจ็บปวดของทีมที่ทำ Agile ต้องเผชิญ เมื่ออยู่ในองค์กรณ์ซึ่งยังใหม่กับ Agile หรือทำ Agile ไปเพียงแค่เพราะเหตุผลทางการตลาดเท่านั้น
เรื่องมันก็มีอยู่ว่า …
คุณรู้สึกดีมากๆ คุณได้พบปะผู้คุยกับผู้คนหลายหลากในแวดวงซอฟต์แวร์ที่รู้จัก Agile แบบผิวเผิน และคุณรู้สึกดีที่ได้บอกเขาเหล่านั้นว่าคุณกำลังทำ Agile ในโปรเจคของคุณอย่างไร คุณบอกเขาถึงความมหัศจรรย์ของการที่ Agile สามารถทำให้คุณส่งมอบมูลค่าทางธุรกิจให้กับลูกค้าได้จริงๆ บอกเขาถึงความสุขที่คุณได้กลับมาจากการมีสมดุลย์ของงานและชีวิตครอบครัวเมื่อคุณปฏิบัตตามแนวทางของ Agile อย่างเคร่งครัด บอกเขาว่าคุณรู้สึกผูกพันธ์และทุ่มเทให้กับโปรเจค บอกเขาว่าคุณมีทีมที่ยอดเยี่ยมและป็นมืออาชีพ
ก็ดูจะโอนะ
จุดสุดยอดของเรื่องมาเกิดขึ้นตอนบ่ายวันศุกร์วันหนึ่ง เมื่อพวกที่บริษัทตราหน้าว่าไม่ทุ่มเทให้กับการทำงาน ได้รับซองขาวเชิญให้ออก และแน่นอนว่าทีมคุณก็เป็นหนึ่งในนั้น
คุณทำอะไรไม่ถูก ได้แต่ถามตัวเองว่าทำไม ทำไมถึงเป็นเรา กูเนี่ยนะไม่ทุ่มเท ในอดีตทีผ่านมาที่เราพัฒนาซอฟต์แวร์แบบผิดๆมาตลอด ครั้งนี้เป็นครั้งแรกที่เรามาถูกทาง ทำไม ทำไม
เหตุผลคือบริษัทดันคิดว่าคุณไม่ทุ่มเทให้ทั้งกับงานและบริษัท
Agile ช่วยแสดงให้เห็นว่าคุณทุ่มเทให้กับงานหรือเปล่า
แล้วไ้อ้บริษัทพวกนี้มันเอาอะไรมาิคิดว่าคุณไม่ทุ่มเท คือมันเป็นอย่างนี้
- คุณทำงานวันละ(แค่) 8 ชั่วโมงในขณะที่คุณอื่นๆที่เขาทุ่มเทกับเขากลับดึกดื่นทำกันวันละ 12-16 ชั่วโมง วันไหน CEO กลับดึกก็จะเจอพวกเนี้ยอยู่ดึกทำงานกันหักโหมอย่างบ้าคลั่ง มันก็เห็นๆไม่ใช่เหรอว่าคนที่อยู่ดึกก็ต้องเป็นพวกที่ทุ่มเทให้กับบริษัทมากกว่าพวกที่กลับบ้านตรงเวลาและไปเล่นเทินนิสในวันสุดสัปดาห์
- คุณดูเหมือนจะคอยไปทำให้คนอื่นๆเสียเวลาทำงานตลอดเวลา ทุกครั้งที่ผู้บริหารระดับสูงผ่านมา ไม่มีคนมานั่งมองจอคุณ คุณก็ไปนั่งมองจอคนอื่นอยู่
- คุณไม่มี design doc เป็นปึ๊งกองอยู่บนโต๊ะ บนโต๊ะมีแต่ post-it อะไรก็ไม่รู้เต็มไปหมด ดูเหมือนคุณจะมัวแต่เสียเวลาทำอะไรไร้สาระ แทนที่จะมานั่งเขียน spec และเอาไปให้คุณ architect แห่งหอคอยงาช้างตรวจ
- คุณดูเหมือนจะคอยโทษคนอื่นตลอดที่ทำให้คุณทำงานไม่ได้ คุณต้องการให้ลูกค้ามาเป็นส่วนหนึ่งกับทีม ต้องให้เขามาเสียเวลาตรวจดูสิ่งที่คุณทำ คุณไม่สามารถที่จะตั้งสมมุติฐานกับ Use Case ที่ไม่ชัดเจนเพื่อที่จะให้งานเดินไปข้างหน้าได้
- คุณดูเหมือนไม่ค่อยจะรู้ว่าใครเขียนโค้ดส่วนใหน คุณคอยแต่จะอ้างแทนทีมที่ไม่ทุ่มเทของคุณว่าโค้ดเป็นของทีมไม่ใช่ของคนใดคนหนึ่ง สุดท้ายเวลามีปัญหา ก็ไม่สามารถจะโทษใครได้ และคุณก็ไม่ยอมโทษใคร
- คุณกับทีมคุณดูเหมือนจะไม่ได้ใส่ใจกับเทคโนโลยีเท่าไหร่ ดูเหมือนคุณไม่สนใจที่จะเรียนรู้อะไรใหม่ ชอบแต่จะอ้างว่าไม่จำเป็นจะต้องขี่ช้างจับตั๊กแตน
- คุณดูเหมือนจะไม่มี expert ในทีมเลย ทุกคนทำงานกับทุกส่วนเปะปะไปหมด เราไม่รู้จะติดต่อใครเมื่อฟังก์ชันใดฟังก์ชันหนึ่งมีปัญหา ไม่มีผู้เชี่ยวชาญ ไม่มีการแบ่งงาน เราไม่เข้าใจว่าแล้วคุณจะวัดผลงานในทีมคุณได้อย่างไร
- ตอนเช้าทุกเช้าก็ต้องเสียเวลามายืนคุยบ้าบออะไรก็ไม่รู้ เฮฮาอย่างกับมีปาร์ตี้ ในขณะที่ทีมอื่นๆเขาก็ก้มหน้าก้มตาทำงาน
ด้วยเหตุผลที่กล่าวมาข้างต้น บริษัทได้ข้อสรุปว่าคุณไม่เคยคิดจะทุ่มเทให้กับบริษัท เืมื่อถึงเวลาที่จะต้องปรับลดพนักงาน พวกที่ไม่ทุ่มเทก็ต้องไปก่อนมันก็แน่นอนอยู่แล้ว
….
แล้วท่านผู้อ่านใช้ Agile กันหรือเปล่า ระวังให้ดีนะครับโดยเฉพาะถ้าท่านอยู่ในองค์กรณ์ที่ไม่ได้เข้าใจ Agile จริงๆ
โชคดีครับ
แปลและเรียบเรียงจาก http://vikashazrati.wordpress.com/2008/01/06/do-you-follow-agile-you-are-fired/
กรุณาใช้ท่าทำเป็นยุ่ง ด่วนครับ
สำหรับผมคิดว่าจุดขายหลักของ Agile เลยคือ การ Release Early, Release Often แบบนี้ลูกค้าจะปลื้มมาก แล้วจะได้ผลมากถ้าลูกค้าของเราคือหัวหน้าเราด้วย (ถึงไม่ได้บอก ขอทายว่า หัวหน้าจากเรื่องไม่ใช่คนที่ใช้ระบบ เป็นคนมา “ตรวจงาน” เฉยๆ ดูแต่การทำงาน ไม่ได้ดูผลงาน)
สิ่งที่ลูกค้าจะเห็นเต็มๆ เลยกับการใช้ Agile คือ ได้ สัมผัส กับระบบทุกๆ สองสัปดาห์ แล้วก็ได้เห็นบั๊กตัวใหญ่ๆ ถูกแก้ในอีกสองสัปดาห์ ถ้าทีมไหนทำเวปแล้วทำ Continuous Integration บางทีก็ให้ลูกค้าเข้ามาเล่นเวปที่ Deploy ได้ตลอดเวลาเลย ลูกค้าเห็นงี้ ก็จะไม่ค่อยสนใจเรื่องวิธีการทำงานละครับ เวลาโทรมา ก็จะชม / บ่น เกี่ยวกับตัวโปรแกรมมากกว่า
จุดหลักก็คือทำยังไงให้คำชมของลูกค้าเราไปถึงหัวหน้าล่ะครับ
ปล. เจ็บจี๊ดกับข้อ (1) มากครับ ผมล่ะเกลียดวัฒนธรรมอยู่ดึกมากเลย มันทำให้คนเราไม่พยายามปรับปรุงวิธีการทำงานอ่ะ
ข้อ 3,4,5 นี่เจอกับตัวมาแล้วครับ
ถ้าเจ้านายใหญ่ไม่ซื้อ idea ก็ลำบากนะครับ
ที่เคยเจอ PM เค้าซื้อ แต่ทีมอื่นรอบข้างไม่ Agile ด้วย ทำให้เรา agile ไม่พอตามไปด้วย มีผลเลยทีเดียว
เราต้องคอยให้ความรู้ ปลูกปรัชญา ซึ่งต่างทีมกันก็ทำได้ไม่เต็มที่ แล้วไม่มีใครอยากเปลี่ยนการทำงานแบบเดิมที่ตัวเองชิน
พอทีมเรา agile ไม่พอก็เหมือนว่าเราต่างกับระบบเก่าไม่มาก
พยายามจะเอาผลลัพธ์ที่ดีกว่าเดิมเข้าพิสูจน์เหมือนกันครับ แต่กลับอ้างผลงานได้ไม่เต็มที่ เพราะปัจจัยภายนอก ณ เวลานั้นก็เปลี่ยนตามไปด้วย ก็เลยเป็นข้อสงสัยของเค้า
บารมี วัยวุฒิ บุคลิก ตำแหน่ง สำคัญมากสำหรับขาย agile ในองค์กรนะครับ สำหรับบริษัทไทยด้วยยิ่งจำเป็นครับ
ก็เข้าใจได้ในแบบนึงนะครับ มันเหมือนเป็นการตรวจ process มากกว่าตรวจงานจริงๆ ว่าคุณทำตาม standard ของบริษัทมากน้อยขนาดไหน มากกว่าจะมา focus ลงไปที่ตัวงานและคุณภาพของการสื่อสารครับ
น่าจะเป็นปัญหาการบริหาร perception จะทำยังไงให้คนอื่นเห็นว่าวิธีนี้มัน productive แต่คนที่โตมาด้วยระบบแบบนึง จะให้แก้หัวคิดไปยอมรับระบบการทำงานอีกแบบนี่ก็ไม่ง่ายเลย
ในมุมมองของผม ผมเห็นด้วยครับที่ผลของมันออกมาเป็นแบบนี้เพราะทางบริษัทไม่เข้าใจ Agile แต่ในทางกลับกัน ก็เป็นหน้าที่ของทีมที่ทำ Agile ที่จะต้องอธิบายถึงประโยชน์ของการทำ Agile เมื่อเทียบกับ process แบบเดิมๆ (ถ้า process เดิมไม่มีปัญหาก็คุยยากละ) เพราะหลายคนที่นำ Agile ไปใช้ในองค์กรก็พูดเป็นเสียงเดียวกันว่า ผู้บริหารต้องสนับสนุน ไม่งั้นมันไม่เกิด หรือไม่ก็เกิดอยู่บนความไม่เชื่อใจหรือจ้องจับผิด ผลที่ออกมาก็ตามตัวอย่างนี้แหละครับ แต่ทำยังไงละที่ผู้บริหารจะเห็นคุณค่าของสิ่งที่เราจะทำ ก็ต้องอธิบายด้วยภาษาของผู้บริหารไง
สำหรับผู้บริหารแล้ว สิ่งที่เค้าสนใจคือเรื่องของ ประโยชน์ที่องค์กรจะได้รับเมื่อจะลงมือเปลี่ยนแปลงอะไรซักอย่าง เช่นทำแล้ว product ออกสู่ตลาดต้องเร็วขึ้น คุณภาพของ product ควรจะดีขึ้น ลดต้นทุนอย่างเห็นได้ชัด ฯลฯ เป็นต้น ซึ่งทางด้านการพัฒนาซอฟท์แวร์แล้ว สิ่งที่จะสะท้อนไปยังเป้าหมายที่ว่าก็คือประสิทธิภาพของการทำงานของทีมพัฒนาซะเป็นส่วนใหญ่ เมื่อจะนำ Agile ไปใช้ เราก็ต้องหากันก่อนว่าการทำงานของเรามันมีปัญหารึเปล่า ถ้าเอา Agile มาใช้มันจะแก้ปัญหาได้ไหม จะเพิ่ม productivity ได้ไหม และสิ่งสำคัญที่ทางผู้บริหารต้องการเห็นก็คือผลลัพธ์ที่วัดได้จริงที่สอดคล้องกับประโยชน์หรือเป้าหมายขององค์กรนั้นๆ
Practice ของ Agile ทุกข้อมีส่วนที่จะช่วยให้เกิดประโยชน์กับ business value ขององค์กรอยู่แล้ว แต่ก่อนที่จะเริ่มลงมือทำ (โดยเฉพาะเมื่อมีฝ่ายบริหารเข้ามาเกี่ยวข้องด้วย) ก็ต้องวางกรอบกันให้ชัดว่าทำแล้วได้อะไร อะไรคือ priority หลักที่ต้องทำ อะไรคือปัญหาใหญ่ที่เจอกันตอนนี้ แล้ว Practice ไหนของ Agile ที่เหมาะกับปัญหาและ business value นั้นๆ ก็เลือกมาทำ เมื่อกำหนดได้แล้ว ก็ต้องกำหนดวิธีการวัดผลเพื่อ evaluate ว่าทำแล้วดีขึ้นจริง
ผมคิดว่า ถ้าการนำเสนอ Agile โดยมุ่งเป้าไปที่คุณค่าที่องค์กรจะได้รับต่อการเปลี่ยนแปลงและสามารถพิสูจน์ออกมาได้ว่า product ที่ได้เป็นไปตามเป้าหมายที่วัดได้จริงแล้ว เหตุผลทั้ง 8 ข้อที่ยกมากล่าวอ้างนั้นจะมีคำอธิบายได้ทั้งหมดจากผลงาน (แต่มันต้องดีขึ้นนะ ไม่ใช่แย่ลง) เมื่อเป็นแบบนั้น ผมคิดว่าทีมที่โดนไล่ออก น่าจะเป็นทีมที่ใช้เวลาทำงานมากกว่าแต่ผลลัพธ์ออกมาพอๆ กันหรือแย่กว่ามากกว่านะ
ผมคงไม่ไล่ทีละข้อละ เพราะเป็นไปได้ที่ทีมอาจจะนำเอา practice ไปใช้อย่างผิดๆ เช่น “คุณดูเหมือนจะคอยโทษคนอื่นตลอดที่ทำให้คุณทำงานไม่ได้” มันออกจะเป็นข้อสรุปที่จะต้องดูในรายละเอียด ผมคิดว่าคงไม่มีประโยชน์ที่จะลงรายละเอียดสำหรับคนที่รู้ใน practice ของ Agile อยู่แล้ว
สำหรับคนที่สนใจรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่ผมว่ามา มันอยู่ในหนังสือชื่อ Agile Adoption Patterns ครับ เล่มนี้จะพูดเรื่องทำยังไงที่จะนำ practice ต่างๆของ Agile ไปใช้งานให้เกิดประโยชน์ต่อองค์กรตรงตาม business objective และมีคุณค่าต่อ business value โดยมองหาจาก bad smell ต่างๆ เช่น business smell หรือ process smell จากนั้นจึงนำเสนอ practice ต่างๆ ของ Agile ในรูปแบบของ Patterns โดยให้ความสำคัญกับ practice ที่เหมาะกับการแก้ปัญหานั้นๆ ก่อน แล้ววัดผล จากนั้นค่อยแก้ปัญหาถัดๆ ไป ประมาณนั้นครับ
link ของหนังสือจาก amazon ครับ http://www.amazon.com/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521 ใครสนใจก็ลองหามาอ่านดูครับ
ว่าจะแนะเล่มนี้อยู่เหมือนกันครับ
เป็นเล่มที่ unique ดีครับเทียบกับเล่มอื่นๆ +1
Agile Adoption Patterns น่าสนใจครับ ไว้จะไปหามาอ่านดู
เห็นด้วยกับ “บารมี วัยวุฒิ บุคลิก ตำแหน่ง” อย่างมากๆ เลยครับ ถึงไม่ใช่บริษัทไทยก็จำเป็นมากครับ
“ผมคิดว่าทีมที่โดนไล่ออก น่าจะเป็นทีมที่ใช้เวลาทำงานมากกว่าแต่ผลลัพธ์ออกมาพอๆ กันหรือแย่กว่ามากกว่านะ”
–> เห็นด้วยครับ ผมคิดว่าจุดใหญ่ของเรื่องนี้เลย คือ คนที่มีอำนาจตัดสิน ใส่ใจวิธีการทำงาน (กลับดึก คร่ำเคร่ง ดูเป็นการเป็นงาน ฯลฯ) มากกว่า ผลงาน (โปรแกรม เวป ฯลฯ) ครับ คงต้องกลอุบายล่อหลอกให้วิธีให้การวัดผลอิงกับ ผลงาน มากกว่า การทำงานล่ะมั๊งครับ
เคยลองใช้ Agile แบบค่อยๆ ใส่เข้ามาทีละ Practice ครับ เริ่มจาก 0 แล้วโหวตอันที่ในทีมคิดว่า น่าจะเป็นประโยชน์ที่สุดเข้ามาทีละอันสองอัน จบแต่ละรอบให้ในทีมโหวตว่า มันได้ผมตามที่อยากได้มั๊ย อันไหนดี ก็เก็บไว้ อันไหนไม่ค่อยดี ก็ค่อยๆ คัดทิ้งไป น่าจะคล้ายๆ กับในหนังสือที่แนะนำนะครับ เดี๋ยวไปลองอ่านดูนะ
ถ้าโดนไล่ออกสงสัยต้องออกไปทำ web hosting เอง หรือไม่งั้นก็ affiliate เต็มตัว