The Future of Software Testing (again)

หัวข้อเดิมกับเพื่อนกลุ่มใหม่ …?ที่ผมเตรียมไว้จะเป็นเรื่องที่เกี่ยวกับมุมมองทางธุรกิจซะเกือบครึ่งเลยครับ เพราะส่วนตัวแล้วมันเป็นเรื่องน่าสนใจมากว่าข้างนอกเค้ามีการจัดการพวกธุรกิจ Startup กันอย่างไร กว่าจะมาเป็น Food on the Table (ชื่อแปลกๆมั้ย) กว่าจะมาเป็น IMVU.com หรือ Grockit นั้นมีกระบวนการอะไรอยู่เบื้องหลังบ้าง นั่นคือสองหัวข้อแรกที่เราจะคุยกันครับ


ที่เหลือจะเป็นเรื่อง Technical บ้างแล้ว เริ่มด้วยกระบวนการทำ Software Testing ของ Google ไล่จากตำแหน่ง Engineer ของ Google กระบวนการทำ Test Plan และ Risk-Based Testing ในแบบของ Google ครับ ปิดท้ายด้วย Cloud computing and testing ที่เราจะมาดูกันในภาพกว้างๆว่า Cloud computing คืออะไรและมันกำลังเป็น Trend ที่น่าสนใจอย่างไรในมุมของ Software Development

  1. การเปลี่ยนแปลงของธุรกิจที่ส่งผลต่อ Software Development Project
  2. แนวคิดใหม่ๆในการทำ Software Development และ Software Testing
  3. ว่าด้วยเรื่องของ Google
  4. Cloud computing and testing


ทั้งหมดนี้จะว่าไปแล้วมันก็ค่อนข้างจะไกลตัวอยู่ซักหน่อยและไม่ง่ายที่จะปรับใช้กับการทำงานในบ้านเรา ว่าแล้วก็ขอปรับเปลี่ยนผังรายการเล็กน้อยด้วยการเพิ่มหัวข้อที่ 5. Sharing and Discussion เข้ามาครับ?มันคือช่วงเวลาที่ทุกคนจะได้แชร์ประสบการณ์ ปัญหา และความท้าทายที่เจอในเรื่องที่เกี่ยวกับ Software Testing โดยเฉพาะ

  • เช่น Dev ทำงานเสร็จช้า สุดท้ายมาตัดเวลาเทส
  • เช่น Requirement เปลี่ยนตลอดเวลา แก้ Test case กี่รอบก็ตามไม่เคยทัน …
  • เช่น เสียเวลาเถียงกับ Dev เพราะ “นี่มัน Feature ไม่ใช่ Bug” …
  • เช่น เอ่อ Test process คืออะไร? ผมไม่เคยรู้จัก ฮ่าๆๆ
  • อะไรอีกหละ ผมว่ามีอีกเยอะแหละ


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

ChapterpieceMeeting55-1

สถานที่ก็เหมือนเดิมนะครับ Art Element: School of Art แล้วเจอกันครับ :)

มาเล่าความคืบหน้าของการเตรียมตัวครับ … เรียบเรียงอยู่นาน คิดว่าการจะพูดเฉพาะเรื่องที่เกี่ยวกับ 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