มาเล่าความคืบหน้าของการเตรียมตัวครับ … เรียบเรียงอยู่นาน คิดว่าการจะพูดเฉพาะเรื่องที่เกี่ยวกับ Software Testing อย่างเดียวมันจะดูกลวงๆขาดๆอะไรไป ผมเลยลองคิดถึงรากฐานที่มาของการเปลี่ยนแปลงหรือการพัฒนาไปของการทำ Software Testing ด้วยครับ ที่เห็นชัดเจนรากฐานที่ว่าคือการเปลี่ยนแปลงไปในโลกของธุรกิจโดยรวม ส่งผลให้กระบวนการทำงานแบบเดิมนั้นล้าสมัยไป ช่วงแรกสุดก็เลยจะขอเปิดด้วย (1.1) การทำงานแบบเดิมๆ (1.2) ปัจจัยที่จะทำให้ตัวผลักดันให้เกิดการเปลี่ยนแปลงทางธุรกิจ และ (1.3) แนวคิด-แนวปฏิบัติใหม่ๆที่กำลังได้รับความสนใจครับ ตรงนี้จะเริ่มโยงเข้าหา Software Testing ล่ะ



CM5-Part1

ช่วงที่สองจะเป็นกระบวนการทำงานแบบใหม่ที่ต่อยอดมาจากแนวคิดช่วงแรกครับ แบ่งเป็นสองส่วนที่ทำงานประสานกันได้อย่างลงตัวครับ (2.1) อะไรคือ Pretotyping หว่า ผมจะเล่าแนวคิดในการทำธุรกิจแบบใหม่ที่คิดค้นโดย Alberto Savoia (Engineering Director จาก Google) ให้ฟัง ตามมาด้วย (2.2) FrAgile มันคือ? เพื่อนๆรู้จัก Agile Development อยู่แล้วหละ แต่ FrAgile มันคืออะไร? มันเกี่ยวอะไรกับ Pretotyping จะได้รู้กันครับ


CM5-Part2-1

ช่วงที่สาม อันนี้ก็น่าสนใจมากสำหรับผม เป็นส่วนที่ผมอ่านหนังสือและบทความเยอะที่สุดแล้ว ? โดยสรุปรวมเลยครับ เราจะได้รู้กันว่า Google มีหลักการในการทำ Software Development อย่างไร, มีการจัดโครงสร้างองค์กรยังไง, Tester เค้ามีหน้าที่อะไรบ้าง ตลอดจนถึงกระบวนการเขียน Test Plan ด้วย ACC (อันนี้เจ๋งสุดๆ), หลักการทำ Exploratory Testing ด้วย Test Tours (จะพาไปเที่ยวไหนเนี่ยะ) และแนะนำเล็กๆน้อยๆถึง Test Tools ที่ Google ใช้และเปิดเป็น Open Source projects ครับ เยอะจัง


ช่วงที่สี่ ยังเป็นวุ้นอยู่ ฮ่าๆๆ ? ตั้งใจจะพูดถึงเรื่อง Cloud Computing and Testing กับ Model-Based Testing แต่ยังไม่ได้ร่างหัวข้อเลย หาข้อมูลไว้แล้วครับ ยังไม่ได้สรุปออกมาให้เป็นระเบียบ ? จะพยายามทำให้เสร็จทันเวลาครับ


ป.ล. เพื่อนๆเชื่อป่าวว่า Google มี Tester มากกว่า Developer???:mrgreen:

Chapterpiece.Meeting.5 is coming.

Posted by kannique On April - 22 - 2012ADD COMMENTS

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


The Future of Software Testing

ช่วงแรก … เป็นเรื่องที่เกี่ยวข้องโดยตรงกับชื่อกิจกรรม The Future of Software Testing แต่จะเน้นไปที่เรื่องราวทั่วไปของการเปลี่ยนแปลงใน Software Industry แนวคิดใหม่ที่ชื่อว่า “Pretotyping” ซึ่งมีผลกระทบอย่างมากต่อคำว่า “Testing” ตอนนี้เราจะมาดูกันด้วยว่า Google เค้ามีกระบวนการ Testing อย่างไร … และปิดท้ายด้วยเรื่องของ Cloud Computing + Model-Based Testing ในภาพกว้างครับ


หนังสือและบทความที่ผมอ่านครับ ถ้าเผื่อมีเวลาก็ลองอ่านดูได้นะ

  1. ?http://googletesting.blogspot.com/?… บล็อกที่คนใน Google มาเขียนให้อ่านว่า Google มีกระบวนการทำงานยังไงบ้าง เน้นไปที่ Software Testing ครับ ผมชอบคนนี้ครับ James Whittaker เค้า (เคย) เป็น Engineering Director ของ Google ครับ มีแนวคิดแปลกดี
  2. http://www.pretotyping.org/?… Alberto Savioa ก็เป็น Engineering Director จาก Google เหมือนกัน ?เค้าเป็นคนคิดคำว่า “Pretotyping” และเขียนหนังสือเล่มนี้ น่าสนใจมาก ลองอ่านดูครับ แป๊บเดียวจบ
  3. http://gettingreal.37signals.com/toc.php?… หนังสือเล่มนี้อ่านสองรอบแล้วก็ไม่เบื่อครับ คนเขียนคือ Jason Fried ผมว่าเค้าเป็นคนหัวคิดทันสมัยและแหวกแนวดีนะ อ่านแล้วได้มุมมอง Software Development แบบใหม่ๆเยอะครับ ไม่ใช่แค่เรื่อง Testing
  4. http://www.testingexperience.com/?… เป็นแมกกาซีนโดยเฉพาะสำหรับ Software Testing ผมดาวน์โหลดมาหมดอะ เปิดทุกเล่ม แต่ไม่ได้อ่านทุกบทความนะครับ ตายกันพอดี ฮ่าๆๆ
  5. http://www.amazon.com/How-We-Test-Software-Microsoft/dp/0735624259?… How Microsoft Tests Software เล่มนี้ก็อ่านครับ ตอนแรกตั้งใจ หลังๆเปิดผ่าน ไม่ค่อยประทับใจเท่าไร เลยขออนุญาติตัดหัวข้อนี้ออกด้วยนะครับ
  6. ดูวิดีโอใน Youtube … ก็ search ชื่อเลยครับ James Whittaker, Alberto Savioa, Jason Fried และอื่นๆ เช่น Cloud Computing, Model-Based Testing

ChapterpieceMeeting5complete

What’s Next?

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


แล้วเจอกันเสาร์ที่ 28 บ่ายโมงครับ ขอบคุณเจ้าของสถานที่มากๆด้วยครับ :)


การเดินทาง

สุดท้ายขอฝากวิธีเดินทางไปยังจุดนัดหมายที่?Art Element: School of Art?อย่างละเอียดครับ

แบบประหยัดก็รถเมล์

  1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
  2. จากนั้นเดินตรงไปแยกคลองเตยแล้วเลี้ยวซ้ายจะเจอป้ายรถเมล์ให้ขึ้นรถเมล์
  3. สาย 22 / 45 / 46 /115 / 116 / 149 / 507 ได้หลายสายครับ บอกเค้าลงตรงป้ายองค์การโทรศัพท์ (รถมันจะผ่านจุดสังเกตทางด้านซ้ายมือเรียงลำดับดังนี้?1.โชว์รูม BMW 2.สี่แยกเกษมราษฎร์ 3.คาร์ฟูร์ พระรามสี่ ฝั่งขวาเป็นโลตัส 4 สถานีโทรทัศน์ช่องสาม ตึกมาลีนนท์)
  4. พอถึงตึกมาลีนนท์ก็กดกริ่งลงได้เลยครับ
  5. จากนั้นให้เดินข้ามถนนเข้ามาที่ซอยอุทัยฟาร์มซึ่งจะอยู่ระหว่างองค์การโทรศัพท์กับตึก Green Tower ถ้าข้ามสะพานลอยให้หน้าเข้าป้ายรถเมล์แล้วเลี้ยวมาทางขวามือแล้วเดินตรงมาจะเจอซอยแรกเลยครับ (ก่อนถึงตึก Green Tower)
  6. เดินเข้ามาประมาณ 50 เมตรก็เจอแล้วครับ อยู่ทางซ้ายมือ

แบบด่วนก็มอเตอร์ไซค์

  1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
  2. จากนั้นเดินตรงไปแยกคลองเตย เจอวินมอเตอร์ไซค์ ขึ้นเลยบอกว่าไปซอยอุทัยฟาร์มตรงตึก Green Tower ครับ 30 บาท

แบบมาเป็นกลุ่มก็แท๊กซี่

  1. ลง MRT ศูนย์ประชุมสิริกิต์แล้วออกประตูตลาดคลองเตยครับ
  2. เรียก Taxi แล้วดูตามแผนที่ครับ บอกว่าไปตรงข้ามช่อง 3

แบบขับรถมาเอง

  1. มาตามเส้นทางข้างบน
  2. จอดรถที่ตึก Green Tower หน้าปากซอย ชั่วโมงละ 20 บาทครับ


เมื่อต้นปีผมตั้งกระทู้ถามเพื่อนๆใน Group ว่า “สำหรับ Meeting ครั้งหน้า อยากคุยเรื่องอะไรดี?” คำตอบที่ได้ดูเหมือนหลายคนจะชอบเรื่อง Software Testing ผมก็เลยขอจับเรื่องนี้มาเป็นหัวข้อสำหรับ Meeting ครั้งที่ 5 นี้ซะเลย


ความตั้งใจของผมมีว่าผมจะไม่พูดถึงเรื่องทั่วไปของ Software Testing เช่น Unit test, Integration test คืออะไร หรือเรื่องที่เป็น Technical มากๆ เช่น จะเขียน Automated test case ด้วย tool ตัวไหนดี สาเหตุเพราะผมก็ไม่ได้เชี่ยวชาญเรื่องพวกนี้ขนาดนั้นครับ ฮ่าๆๆ แต่สิ่งที่ผมให้ความสนใจมากกว่าก็ตามชื่อ Meeting เลยครับ … The Future of Software Testing


ตอนนี้ผมอ่านหนังสือและบทความเกี่ยวกับ Software Testing อยู่ครับ มีหลายเรื่องที่ผมคิดว่าน่าสนใจมาก ก็เลยอยากเล่าให้ฟัง แค่นั้นเอง ฮ่าๆ ลองดูนะครับว่าผมจะมีอะไรมาฝากกันบ้าง


ChapterpieceMeeting5


ถ้าเพื่อนๆสนใจ ลงทะเบียนที่นี่แล้วเจอกันได้ที่เดิมครับ วันเสาร์ที่ 28 เมษายน 2555 เวลา 13.00-17.00 มีที่นั่งว่าง 12 ที่ครับผม :)


ในปีค.ค. 1980 บริษัทฟอร์ด มอเตอร์มีโครงการผลิตรถยนต์รุ่นใหม่ออกมาเพื่อขยายโอกาสทางการตลาด The First Generation of Ford Taurus เริ่มโครงการในปี 1980 จนกระทั่งปี 1985 รถยนต์รุ่นนี้ก็ออกวางขาย ผลลัพธ์ที่ได้นั้นเกินคาดเพราะ Ford Taurus กลายเป็นรถยนต์ที่ขายดีที่สุดในสหรัฐอเมริกาในช่วงปลายศตวรรษที่ 80 ไปเลย เมื่อดูลึกลงไปในรายละเอียดแล้ว โครงการนี้น่าสนใจมากเพราะเป็นครั้งแรกของฟอร์ด มอเตอร์ที่ประยุกต์ใช้หลักการ Cross-Functional Team และ Concurrent Engineering แถมมีการทำงานกันอย่างใกล้ชิดระหว่างทีมออกแบบและพัฒนา, ทีมธุรกิจ, Vendor, และ Contractor โดยทุกทีมทำงานร่วมกันเพื่อบรรลุจุดประสงค์เดียวกันนั่นคือ ทำงานเพื่อตอบสนองความต้องการของลูกค้าให้ได้ดีที่สุด แต่ไม่น่าเชื่อว่า Project Manager ที่ดูแลโครงการนี้โดนไล่ออก เพียงเพราะโครงการนี้เสร็จช้าไปจากกำหนดการเดิมแค่ 3 เดือน


จนมาถึงในช่วงปี 1990 ช่วงที่ตลาดรถยนต์ในสหรัฐอเมริกามีการแข่งขันที่รุนแรงขึ้นเพราะการมาของรถยนต์ญี่ปุ่น (ราคาถูก คุณภาพรับได้) บริษัท ฟอร์ด มอเตอร์ก็มีความคิดจะเข็น Taurus รุ่นสองออกมาเพื่อแข่งขันกับรถยนต์นำเข้าจากญี่ปุ่น แต่ครั้งนี้ไม่เหมือนเก่าซะแล้ว … Project Manager คนใหม่เรียนรู้จากประสบการณ์ว่าถ้าแกทำโครงการนี้เสร็จช้ากว่ากำหนด แกเด้งแน่ … ดังนั้นเขาจึงทำทุกอย่างให้งานเสร็จตรงเวลา ไม่สนใจ Vendor ไม่สนใจ Team Spirit ไม่สนใจความต้องการที่แท้จริง (และเปลี่ยนแปลงไปอย่างรวดเร็ว) ของลูกค้า สนอย่างเดียว งานต้องเสร็จตรงเวลา ซึ่งสุดท้ายแล้วเขาก็ทำได้นะ ?The Second Generation of Ford Taurus ออกวางขายในปี 1996 ได้ตามแผนที่วางไว้ แต่ … ลูกค้าไม่ปลื้ม รถยนต์รุ่นนี้ขายไม่ออก สุดท้ายที่ลงทุนไปเหมือนจะเสียเปล่า แทนที่ฟอร์ด มอเตอร์จะใช้โอกาสนี้ดึงฐานลูกค้ากลับมา กลับกลายเป็นว่าเจ๊งหนักกว่าเก่า


ถึงตรงนี้ถามเพื่อนๆว่า … โครงการไหนประสบความสำเร็จครับ?

  1. The First Generation of Ford Taurus: Triple Constraints (Scope, Schedule, Cost) ไม่ได้ตามแผนที่วางไว้เพราะส่งงานช้าไป 3 เดือน แต่สินค้าขายดี บริษัทกำไรมากมาย
  2. The Second Generation of Ford Taurus: Triple Constraints (Scope, Schedule, Cost) ได้ตามแผนเป๊ะเลย ไม่พลาดแม้แต่ข้อเดียว แต่สินค้าขายไม่ออก บริษัทเจ๊ง

ถ้าตอบว่าข้อสอง … ผมแนะนำว่าไม่ต้องอ่านต่อเลยครับ ส่วนที่เหลือของบทความนี้ไม่มีประโยชน์กับท่านเลย ฮ่าๆๆ … แต่ถ้าตอบว่าข้อแรกผมก็โล่งใจครับ

Triple Constraints != Success

ถ้าเราเอาโครงการที่สองเป็นตัวอย่างนะครับ การนิยามคำว่า Project Success ว่า “ทำงานเสร็จครบ (Scope) ในเวลา (Schedule) และงบประมาณ (Cost) ที่กำหนด” มันไม่ใช่อีกต่อไปแล้วเพราะ


มันไม่ได้เป็นการการันตีความพึงพอใจของลูกค้า — นั่นหมายความว่าลูกค้าอาจจะไม่ยอมรับในตัวสินค้าของเราก็ได้ … อาจจะมีคนสงสัยว่า อ่าว แล้วทำไมแต่ก่อนทำได้แค่ Triple Constraints ก็พอแล้วหละ? ยุคสมัยมันเปลี่ยนแปลงไปแล้วครับ สมัยก่อน (ซัก 30-40 ปีที่แล้ว) ทำอะไรออกมาก็ขายได้ครับ คู่แข่งมันน้อย ช่วงนั้นความต้องการของลูกค้าเป็นเรื่องจิ๋วๆอะ สำคัญที่สุดคือผลิตสินค้าออกมาให้ได้เยอะเหอะ ขายหมดแน่นอน เรื่องความสำเร็จทางธุรกิจเลยเป็นเรื่องที่การันตีได้ด้วย Triple Constraints … เดี๋ยวนี้ซิ ด้วยความที่โลกแคบลง ความก้าวหน้าทางเทคโนโลยี หรืออะไรก็ตามแต่ ทำให้มีคู่แข่งทางธุรกิจเยอะแยะมากมาย สินค้าแต่ละประเภทมีหลายยี่ห้อ หลายรุ่น ให้เลือกกันไม่หวาดไม่ไหว ทั้งหมดเป็นการสร้างสภาพแวดล้อมที่ลูกค้ามีความต้องการเป็นของตัวเอง เฉพาะตัว เฉพาะกลุ่มเพิ่มขึ้นทุกวัน แถมความต้องการนี้เปลี่ยนแปลงอย่างรวดเร็วและตลอดเวลา แค่ Triple Constraints ไม่พอซะแล้วครับ


มันไม่ได้เป็นการการันตีว่าลูกค้าจะมองเห็นถึงคุณค่า (Value) ในสินค้าของเรา — คำว่าคุณค่าหรือ Value นั้นมาจากสมการข้างล่างครับ

Value = Benefits/Price …?หรือ

Value = Quality Received/Expectations

การที่จะทำให้ลูกค้ายอมรับในสินค้าของเรานั้น เราต้องสร้าง Value จากสิ่งที่เรานำเสนอให้ได้ครับ น่าเสียดายที่น้อยนักที่จะมีการพูดเรื่อง Value ที่ต้องการจาก Project ในช่วงแรกของการวางแผน ส่วนใหญ่ก็พูดกันแต่ว่า Scope คืออะไร Schedule และ Cost เป็นยังไง แต่ก็พอเข้าใจได้นะครับเพราะการหาคำนิยามของ Value เป็นเรื่องยากมาก ต่อให้ถามตัวลูกค้าเองก็เหอะ … พี่ครับ พี่อยากได้อะไรจากสินค้าตัวนี้ครับ … เอ่อ ผมอยากได้อะไรที่มันมีคุณภาพดี มีลูกเล่นเยอะๆหน่อย แล้วราคาไม่แพง รู้มาแค่นี้ก็ยากนะครับที่จะสร้าง Value ที่จับต้องได้ให้กับ Project ของเรา และมันจะยิ่งยากเข้าไปใหญ่เพราะถามลูกค้า 10 คนเราอาจจะได้คำตอบ 11 แบบที่ไม่ซ้ำกันเลย มันก็เป็นหน้าที่ของทุกคนใน Project ครับที่ต้องสร้างมันขึ้นมาด้วยข้อมูลที่มี ด้วยความเข้าใจในตัวสินค้าของเรา และด้วยวิสัยทัศน์ของผู้นำทีม ผู้นำบริษัท แล้วสรุปรวบยอดออกมาเป็น Requirement/Feature ของสินค้าเรา ออกมาเป็น Technology ที่เลือกใช้ ออกมาเป็น Product Design ที่ดึงดูดสายตา ออกมาเป็น Product ที่เป็นมิตรต่อสิ่งแวดล้อม ออกมาเป็นสินค้าที่มีราคาสมเหตุสมผล และอื่นๆ … ปล. Apple โคตรเก่งเรื่องนี้เลยอะ


มันไม่ได้เป็นการการันตีว่าลูกค้าจะกลับมาใช้บริการของเราอีก — ยุคนี้สมัยนี้บริษัทยักษ์ใหญ่หลายต่อหลายแห่งเปลี่ยนมุมมองการทำธุรกิจจากขาย Product/Service มาขาย Solution กันหมดแล้วครับ ไม่ว่าจะเป็น Amazon จากเดิมที่เป็นแค่เวปขายหนังสือ ตอนนี้เปลี่ยนมาเป็นยักษ์ใหญ่ในธุรกิจ Cloud services/solutions แล้ว หรือจะเป็น FedEx ซึ่งเปลี่ยนจากแค่คนส่งของมาเป็นผู้ให้บริการเรื่อง Inventory Management และ Delivery แก่ธุรกิจต่างๆมากมาย ที่ต้องทำแบบนี้ส่วนหนึ่งผมคิดว่าเพราะต้องการเป็น Partner ระยะยาวกับลูกค้า มองตรงนี้สิ่งที่สำคัญที่สุดคือความพึงพอใจของลูกค้า (Customer Satisfaction) ในการบริการของทั้ง Amazon และ FedEx ครับ เรื่อง Triple Constraints กลายเป็นเรื่องเล็กไปเลยเพราะในระยะยาวแล้วลูกค้าจะไม่มองแค่ 3 เรื่องนั้นหรอกครับ เค้าจะมองว่า Amazon และ FedEx ตอบสนองความต้องการของเค้าได้มากแค่ไหน มีความยืดหยุ่นแค่ไหนในการร่วมธุรกิจด้วย สินค้าที่ได้มีคุณภาพแค่ไหน มีทีมงาน Support ที่ดีและเป็นมืออาชีพแค่ไหน … อื่นๆอีกเยอะมากครับ


สิ่งที่ปรากฎอยู่ตรงนี้ทำให้เราต้องมองย้อนกลับไปที่รากของคำว่า Project ครับ ถามว่า Project เกิดขึ้นได้อย่างไร? คำตอบแบบรวบยอดคือ Project เป็นเครื่องมือของบริษัทในการทำธุรกิจ แล้วธุรกิจคืออะไร ต้องการอะไร ต้องการ Triple Constraints ใช่หรือไม่ คำตอบคงไม่ใช่หรอก ธุรกิจต้องการกำไร กำไรจะได้มาจากไหน ง่ายที่สุดคือการที่ลูกค้ามองเห็นคุณค่าของสิ่งที่ธุรกิจนำเสนอ สินค้าขายได้ … และนี่เป็นที่มาของนิยามใหม่ของคำว่า Project Success ว่า “โครงการนี้ต้องตอบสนองความคาดหวังทางธุรกิจ (Business Expectation/Business Value) และรักษาไว้ซึ่ง Triple Constraints และปัจจัยความสำเร็จอื่นๆ (อันนี้เดี๋ยวเล่าให้ฟังข้างล่างครับ)”


Competing Constraints

ที่เขียนมาทั้งหมดไม่ได้หมายความว่า Triple Constraints ไม่สำคัญนะครับ เพียงแต่ต้องการสื่อให้เห็นว่ามันจะไม่ใช่แค่ 3 อีกต่อไปแล้วครับ เพราะการเปลี่ยนแปลงไปของโลกและธุรกิจ เราจำเป็นต้องเข้าใจถึงปัจจัยสำคัญอื่นๆที่มีผลต่อความสำเร็จหรือล้มเหลวของ Project เราด้วย ซึ่งตรงนี้ก็จะแตกต่างกันไปตามสถานการณ์ แต่จะอย่างไรก็ตามเป็นทางการแล้วครับว่าเราจะมองข้ามปัจจัยทางธุรกิจ (Business Factors) ไปไม่ได้เลย … ดังนั้นรูปสามเหลี่ยมทองคำของเราอาจจะกลายเป็นแบบนี้แล้วครับ

Competing_Constraints จากแต่ก่อนเป็นรูปซ้าย ตอนนี้อาจจะกลายเป็นว่า Triple Constraints เป็นส่วนเสริมของปัจจัยทางธุรกิจไม่ว่าจะเป็น Value, Quality หรือ Image/Reputation ของบริษัท … ผมเดาเอานะว่าทุก Project ของ Apple คงมี Competing Constraints เป็นแบบนี้แหละ … แล้วที่น่าทึ่งคือเค้าทำได้ตามนั้นทั้งหมดเลย (หลังๆมานะ) … ขอเดาอีกหน่อยว่าให้ Apple ของสินค้าอะไรมาก็ขายดีอีกเพราะคุณภาพการันตีได้, ภาพลักษณ์องค์กรก็อันดับหนึ่งในโลกมนุษย์ และคุณค่าที่ลูกค้าได้รับก็มากมาย … โดยเฉพาะอย่างยิ่ง Social Value ที่ลูกค้าจะรู้สึกใช้ของ Apple แล้วมันเท่ห์ไรงี๊อะ ฮ่าๆๆ


ถามต่อไปว่า อ่าวแล้วที่เพิ่มมามีแค่ 3 หรอ? ก็ไม่ใช่อีกครับ มีอีกเยอะแยะแล้วแต่บริษัท แล้วแต่ Project ตัวอย่างเช่น Disney นะครับ สิ่งที่ยอมให้มีการเปลี่ยนแปลงได้คือ Scope, Schedule, และ Cost (สามเหลี่ยมด้านใน) โดยต้องคงสิ่งที่สำคัญกว่าไว้ นั่นคือ Safety, Aesthetic value (คุณค่าในเชิงศิลปะ), และ Quality ครับ


มีตัวอย่างให้ดูอีกอันนะครับ จาก Orange Switzerland … จะเห็นว่านอกจาก Triple Constraints ที่เราคุ้นเคยแล้ว เค้าให้ความสำคัญกับเรื่องของ Change Management, Project Team (ผมเข้าใจว่าคงเรื่องของ Team Spirit, Turnover Rate, หรือพวก Knowledge Sharing/Flowing) และ Business Expectation เช่น Adoption Rate, ROI … ในระดับต้นๆด้วย

Orange_Switzerland


โดยสรุปคือแค่ Triple Constraints ไม่เพียงพออีกต่อไปแล้ว เราต้องมั่นใจว่าสิ่งที่ลงทุนลงแรงไปใน Project จะต้องตอบสนองเป้าหมายของบริษัทได้อย่างแท้จริง และนั่นคือเราไม่สามารถมองข้าม Business Expectation/Business Value ได้อีกต่อไปครับ?
เป็นหน้าที่ของ Stakeholder ทุกคนใน Project ไม่ว่าจะเป็น Customer (คนสำคัญเลย), Project Sponsor, Product Manager, Project Manager, Business Development Manager, … ใครต่อใครต้องมานั่งจับเข่าคุยกันให้เรียบร้อยตั้งแต่เริ่มต้นว่า ผลลัพธ์สุดท้ายของ Project นี้คืออะไร


ขอบคุณที่ติดตามผลงานครับ :D


ผมได้อ่านบทความหนึ่งของ James Slavet นักลงทุนในธุรกิจออนไลน์เกิดใหม่ (ก็พวก Groupon, Facebook และ LinkedIn) แล้วรู้สึกน่าสนใจมากครับ เป็นบทความที่พูดถึงเรื่อง Management Metrics แบบใหม่ที่เหมาะสมกับโลกยุคปัจจุบัน ใจความสำคัญอยู่ตรงนี้ครับ

Most managers only measure outputs, not inputs, …

ผมรู้สึกว่ามันก็เป็นแบบนั้นจริงๆ สังเกตได้จากการตั้งเป้าหมายที่เกี่ยวข้องกับเรื่องที่เป็นผลลัพธ์ทั้งสิ้น เช่น ปีนี้จะได้รายได้เท่าไร กำไรเท่าไร ผู้ถือหุ้นจะได้เงินปันผลเท่าไร และอื่นๆ เอาใกล้ตัวเข้ามาหน่อยอย่าง Project Management … Metrics ที่ว่าก็คงไม่พ้น (1) ทำ Project เสร็จตาม Scope มั้ย? (2) ตรงตาม Schedule ที่กำหนดรึเปล่า? (Schedule Variance) (3) แล้วงบประมาณหละเกินมั้ย? (Cost Variance) ซึ่งทั้งหมดนี้มันเป็นผลลัพธ์ปลายทางทั้งสิ้นครับ เปรียบไปก็คล้ายกับการไปกำหนดให้ทีมฟุตบอลยิงประตูให้ได้มากกว่านี้โดยไม่ใส่ใจดูว่าเราจะปรับปรุงพัฒนากระบวนการฝึกซ้อม กระบวนการเก็บรวบรวมข้อมูลและวิเคราะห์คู่แข่ง กระบวนการเฟ้นหาตัวผู้เล่นที่เหมาะสมกับทีม และกระบวนการอื่นๆครับ


ด้วยความคิดแบบนี้ก็เลยเป็นที่มาของชื่อบทความ “คงจะไม่ใช่แค่ Scope – Schedule – Resources อีกต่อไป” ครับ ต่อไปนี้ในสำหรับ Project Management เราคงจะต้องมองหาตัววัดประสิทธิภาพและความสำเร็จของงานในมุมมองที่กว้างออกไป และต้องให้ความสนใจมากขึ้นที่ Input และ Process แล้ว Metrics แบบใหม่ๆที่ว่ามีอะไรบ้าง?


Metric 1: Flow State Percentage

พูดภาษาบ้านๆก็คือ คุณมีเวลาทำงานอย่างมีสมาธิและไม่มีคนรบกวนนานแค่ไหนต่อวัน เรื่องนี้สำคัญมากสำหรับตำแหน่งงานที่ต้องใช้สมาธิมากๆ เช่น Software Engineer ทั้งหลาย ลองดูได้จากหนังเรื่อง Social Network ในฉากที่มาร์ค ซักเกอร์เบิร์ก ใส่หูฟังใหญ่ๆนั่งทำงานอยู่แบบไม่สนใจโลกภายนอกนั่นแหละครับ น่าเสียดายที่พวกเราส่วนใหญ่มักจะโดนขัดจังหวะการเข้าฌาน (In Zone) ของเราอยู่ตลอดวัน อีเมล์ ประชุม (นี่ตัวดีเลย) Instance Messaging โทรศัพท์ และคำถามจากเพื่อนร่วมงาน เค้าศึกษากันมาแล้วครับว่าเอาอย่างหรูเลยนะ พวกเราจะมีเวลาทำงานแบบมีสมาธิจริงๆต่อวันเนี่ยประมาณ 30-50% ของเวลาทั้งหมด แต่ … แต่ ถ้านั่งอยู่ที่ออฟฟิศตัวเลขนี้จะต่ำลงมาอีกอย่างมาก ฮ่าๆๆ ก็รู้ๆกันอยู่


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


Metric 2: Meeting Promoter Score

การประชุมส่วนใหญ่ลงเอยด้วยความว่างเปล่า เสียเวลา และเสียตังค์อย่างมาก บางคนว่าจะเสียเท่าไรกันเชียวประชุมชั่วโมงเดียว … ก็จริงครับ ถ้าพี่นั่งอยู่ในห้องคนเดียวมันก็ชั่วโมงเดียวแหละ แต่นี่พี่เรียกคนอีก 20 คนเข้าห้องด้วยเนี่ยะ มันคือ 1 x 20 = 20 ชั่วโมงทำงานนะครับผม บางครั้งรู้ทั้งรู้ว่าไม่ได้อะไรแต่ที่น่าแปลกคือพวกเราก็ยังต้องเข้าประชุมกันทุกวี่ทุกวัน (ฮ่าๆ)


ปัญหามันอยู่ที่กระบวนการอีกเหมือนเดิมครับ บางครั้งก็มีการเรียกประชุมแบบที่ไม่มีวาระ ไม่มี Agenda เข้าไปก็ไม่รู้จะคุยอะไรกัน เรื่อยเปื่อย เลื่อนลอย บางครั้งคุยเรื่องไม่เป็นเรื่องจนหมดเวลา ส่วนเรื่องสำคัญจริงๆ … ไม่ได้คุยเพราะลืม บางครั้ง (ต้องบอกว่าส่วนใหญ่) มีคนแค่ 20% ในห้องประชุมที่พกปากเข้าไปด้วยครับ อีก 80% นั่งเงียบกริ๊บๆ (ตามกฎ 80/20 เลย) ก็ไม่เข้าใจว่าจะเรียกคนที่ไม่มีบทพูดเข้าไปทำไม ให้เค้านั่งทำงานไม่ดีกว่าหรอ? บางครั้งประชุมเสร็จแล้วก็เสร็จกันไป ผลลัพธ์คืออะไรไม่มีใครจด ใครต้องไปทำอะไรต่อจากนั้นก็ไม่รู้ ครั้งหน้ามาประชุมก็คุยกันเรื่องเดิมๆไม่ได้ไปไหนซักที


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


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


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


Metric 3: Compound Weekly Learning Rate

คนที่เคยศึกษาหรือทำงานกับ Agile Development จะรู้จัก Retrospective meeting ดีนะครับ โดยย่อมันเป็นการประชุมเพื่อระดมสมองของคนในทีมเพื่อหาแนวทางปรับปรุงพัฒนากระบวนการทำงานสำหรับ Iteration ถัดไป ส่วนมากแล้วก็จะทำกันหลังจบ Iteration ถ้า Iteration เรายาว 2 สัปดาห์ เราก็จะได้แนวทางการทำงานใหม่ๆ (ซึ่งหวังว่าจะช่วยให้งานดีขึ้น) ทุกๆ 2 สัปดาห์


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


ผมอ่านหนังสือเล่มหนึ่งของ Tony Hsieh ซึ่งเป็น CEO ของ Zappos บริษัทขายรองเท้าออนไลน์ที่ใหญ่ที่สุดในโลก (ตอนนี้โดน Amazon.com ซื้อไปล่ะ) หนังสือชื่อ “Delivering Happiness” ครับ เนื้อหาเป็นการเล่าประวัติของ Tony เองตั้งแต่เรียนจบจนถึงขาย Zappos ให้ Amazon.com ในเล่มมีการกล่าวถึงปรัชญาการทำงานของ Zappos การผลักดันให้พนักงานทุกคนคิดอะไรใหม่ๆที่ช่วยพัฒนาการทำงานของตัวเองให้ได้ทุกวัน เค้าจริงจังเรื่องนี้มากถึงขนาดเขียนลงไปเป็นกฎของบริษัทซึ่งพนักงานทุกคนต้องรับรู้และพยายามทำตามเลยทีเดียว เค้าเรียกสิ่งนี้ว่า “Culture Book” และข้อแรกก็คือนี่เลย “Deliver WOW through service” หลักการคือสร้างความรู้สึกประทับใจ (ว้าว) ให้กับทุกคนที่คุณทำงานด้วยทุกวัน ไม่ว่าจะเป็น ลูกค้า และเพื่อนร่วมงาน … และผลที่ได้คือความสำเร็จของบริษัทครับ


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


หันกลับมาดูงานเราเองอีกรอบครับ ถ้าอยากให้ Project เราประสบความสำเร็จทั้งส่งงานตาม Scope ได้ตรง Schedule ภายใต้ Resources ที่มี … ก็ต้องถามตัวเองว่าวันนี้เราได้หันมามองกระบวนการทำงานภายในของเราเองแล้วหรือยัง?


ปล. บทความนี้เป็นส่วนนำเรื่องของบทความหน้าครับ … ผมจะเล่าให้ฟังว่าในอนาคตอันใกล้นี้ Metric ของ Project Management จะเปลี่ยนไปอย่างไรครับ


ขอบคุณที่ติดตามผลงานครับ :)