วันนี้มาทำความรู้จักกับ Software Prototyping อีกแบบหนึ่งกันครับ

Evolutionary Prototyping

แก่นของเจ้าตัวนี้คือ “Software is never complete.” ดูแล้วไม่ดีเลยใช่มั้ยครับกับประโยคนี้ “ซอฟท์แวร์ไม่มีวันสมบูรณ์” มันหมายความว่างานเราไม่ดีรึเปล่า? จริงๆแล้วไม่ใช่ครับ ถ้าเรามองโลกในแง่ดีซักนิดเราจะเห็นความหมายดีๆจากมัน … “ไม่สมบูรณ์” ก็คือ “มีทางที่จะปรับปรุงได้” ถ้า “ไม่มีวันสมบูรณ์” ก็แปลว่า “เราปรับปรุงและพัฒนามันได้ตลอดไป” (ทำใจให้มองแบบนี้กันได้มั้ยเนี่ยะ?)

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

1. Prototype ที่ทำขึ้นมาแล้วจะถูกนำมาใช้จริงในซอฟท์แวร์ของเรา คราวนี้ไม่ทิ้งครับ
2. เริ่มทำกับงานที่มี Requirement ค่อนข้างจะชัดเจนก่อน
3. ในบางครั้งเราจำเป็นต้องส่งเจ้า Prototype ตัวนี้แหละไปให้ลูกค้าลองใช้งานเบื้องต้นดูก่อนดังนั้นงานที่ทำขึ้นมาต้องเป็น Working Prototype ที่ใช้งานได้จริงครับ

ทั้งหมดนี้แตกต่างจาก Throwaway Prototyping แบบคนละขั้วเลยนะครับ เพื่อนๆรู้สึกถึงความจริงจังและเป็นทางการที่มากขึ้นมั้ยครับ? นี่ก็เป็นที่มาของการที่เราต้องคำนึงถึงมาตรฐานและคุณภาพของ Evolutionary Prototyping ด้วยครับ ไม่ว่าจะเป็นการออกแบบ การวางโครงสร้างของโค๊ด การทำ Testing ที่ดีพอสมควรก่อนจะพูดได้ว่า Prototype เราเรียบร้อยแล้ว

เทียบตัวอย่างจากการเขียน Ebook ของผมก่อนนะครับ ขั้นตอนที่สองที่ผมเปิด OpenOffice Writer มาแล้วก็เริ่มออกแบบหน้าปก ผมประยุกต์ใช้ Evolutionary Prototyping ตัวนี้แหละครับ หลักการสามอย่างในตอนนั้นคือ

1. ผมตั้งใจไว้แล้วว่างานนี้ผมจะเอาแบบหน้าปกที่ผมลองทำมาใช้จริงในหนังสือของผมแล้วค่อยๆทำเพิ่มขึ้นไป (ไม่ทิ้งสิ่งที่ทำไปแล้ว)
2. หลังจากที่ใช้ Throwaway Prototyping มาในขั้นแรก ผมรู้แล้วว่าหนังสือของผมจะมีเนื้อหาอะไรบ้าง เรียงลำดับก่อนหลังยังไงบ้าง (Requirement เริ่มชัดเจนแล้ว)
3. หนังสือผมอ่านได้จริง โอเคแหละ เนื้อหายังไม่สมบูรณ์เพราะยังมีแต่หน้าปกครับ แต่มันก็เริ่มจับต้องได้มากขึ้น อย่างน้อยก็มากกว่ากระดาษหนึ่งแผ่นที่ผมเขียนไว้เนอะ ขอเวลาผมอีกสองสามวัน บทแรกของหนังสือผมคลอดแน่นอนและคราวนี้ผมก็จะส่งให้ใครต่อใครเริ่มอ่านได้แล้วครับ (ใช้งานได้จริงและมั่นใจที่จะส่งให้ลูกค้าลองใช้งานได้)

Evolutionary Prototyping กับ Automatic Draft Checking System

ถ้าโยงเทคนิคนี้กลับไปที่ตัวอย่างของเราตั้งแต่บทความแรก (Automatic Draft Checking System) ผมเข้าใจว่าในช่วงปีที่สอง Evolutionary Prototyping เริ่มเข้ามามีบทบาท ลองดูจากรูปนี้นะครับ

เรามั่นใจว่า Requirement ของหน้าจอนี้เริ่มนิ่งพอสมควรแล้ว เราก็เริ่มทำให้ปุ่ม Check Drafts ซึ่งเป็น Feature ที่สำคัญที่สุดทำงานได้ แล้วส่งให้ลูกค้าลองทดสอบดู ถ้าลูกค้ามี Feedback กลับมา เราก็ปรับแก้กันไป แต่ถ้าทุกอย่างตรงใจลูกค้าแล้ว เราก็ต่อยอดไปทำปุ่ม Import หรือ Search ต่อไปครับ

ผ่านไปซัก 2-3 เดือน หน้าจอนี้อาจจะสมบูรณ์ขึ้นมากพอจนทำให้ลูกค้ามั่นใจที่จะเอาไปใช้กับงานจริงๆของเค้าแบบชั่วคราวระหว่างที่รอระบบจริง แบบนี้เราเรียกว่า “Working Prototype” ครับ

Throwaway หรือ Evolutionary

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

ในช่วงที่เรากำลังเก็บ Requirement หรือวิเคราะห์ Requirement อยู่นั้น เราสามารถเลือกใช้ Throwaway Prototyping มาช่วยตรงนี้ได้ครับ นั่นรวมถึงเรื่องการทดสอบทดลองความเหมาะสมเทคโนโลยีต่างๆกับงานของเราด้วย


หลังจาก Requirement มีความชัดเจนแน่นอนมากขึ้นแล้ว ในช่วง Coding/Testing เราก็ใช้ Evolutionary Prototyping ในการพัฒนาระบบของเราโดยเลือกทำจาก Requirement ที่มีความชัดเจนและสำคัญมากที่สุดก่อน

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

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

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

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

ส่งท้าย

เขียนเรื่อง Software Prototyping มาติดต่อกันสามบทความแล้ว หวังว่าเพื่อนๆคงได้แนวทาง แนวคิดในการประยุกต์ใช้เทคนิคนี้กับงานได้นะครับ ในชีวิตจริงผมเองก็ใช้อยู่ตลอดครับ ทั้ง Throwaway (ส่วนมากจะเป็น GUI Builder) กับ Evolutionary ซึ่งผมมองว่ามันช่วยได้มากจริงๆ ทั้งในเรื่องการเขียน Requirement ที่สมบูรณ์ขึ้น การทดลองมองหาเทคโนโลยีใหม่ๆที่เหมาะกับงาน ร่วมถึงการเขียน Working Prototype เพื่อส่งให้ลูกค้าลองใช้ลองเล่นและเก็บ Feedback

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

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

Nothing is particularly hard if you divide it into small jobs.

~ Henry Ford ผู้ก่อตั้งบริษัทฟอร์ด มอเตอร์ ? ผู้ผลิตรถยนต์ฟอร์ด

“ไม่มีงานไหนยากเกินไปถ้าเราแบ่งให้มันเล็กลง” … ประโยคนี้คือหลักการการบริหารงานของ Henry Ford สุดยอดปรมาจารย์ด้านการบริหารและธุรกิจ ผู้ได้รับการยกย่องในฐานะหนึ่งใน CEO ที่เก่งที่สุดตลอดกาล ในเมื่อ Henry Ford สร้างสิ่งที่ยิ่งใหญ่ด้วยการทำงานชิ้นเล็กๆทีละน้อยได้ ในโลกของ Software Development เราก็ทำได้เหมือนกันครับ … Software Prototyping คือผู้ช่วยของเรา

Prototype แปลเป็นไทยได้ว่า “สิ่งที่เป็นต้นแบบ” เมื่อมารวมกับคำว่า Software ก็เลยกลายเป็น “ซอฟท์แวร์ต้นแบบ” ง่ายมั้ยครับ ฮ่าๆ เรื่องจริงมันก็ง่ายๆแบบนี้แหละฮะ การทำ Software Prototyping ก็คือการสร้างสิ่งที่เป็นต้นแบบ (เล็กๆ) ซึ่งเป็นแนวทางและตัวอย่างสำหรับการสร้างสิ่งที่เป็นของจริง (ใหญ่ๆ) นั่นเอง

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

หลังจากได้แนวทางมาแล้ว ผมเริ่มเปิดโปรแกรม Open Office Writer (ตอนนั้นไม่ได้ใช้ Microsoft Word ครับ) แล้วก็เริ่มเขียนเลยครับ หน้าแรกคือ … หน้าปกครับ ความคิดเริ่มพุ่งพล่านอีกแล้ว จะวางกรอบหน้าปกยังไง? จะเอาตัวอักษรแบบไหนดีนะ? แล้วสีหละ? เมื่อคิดแล้วมองไม่เห็นภาพ ผมก็ลุยเลยครับ ลองทำจริงไปเลย ตอนนั้นหน้าปกผมมีหลายรูปแบบมาก ทำไป แก้ไป พิจารณาไปด้วยว่า อันนี้เหมาะรึยัง? พอเริ่มเห็นภาพเห็นของจริงก็ง่ายต่อการตัดสินใจครับ ไม่นานนัก (จริงๆก็หลายชั่วโมงนะ) ผมก็เลือกแบบได้แล้วก็เริ่มทำต่อที่สารบัญและเนื้อหา ตอนนี้หนังสือผมก็เริ่มหนาขึ้นๆ จนเสร็จ … นี่ก็ Prototype อีกแบบหนึ่งครับ

มองเห็นภาพนะครับ

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

Throwaway Prototyping

ความหมายของ Prototype แบบนี้คือแบบที่ใช้แล้วทิ้ง (แบบไม่ต้องเสียดาย) หลังจากที่เราได้เรียนรู้และใช้ประโยชน์จากมันแล้วครับ นี่เป็นรูปแบบที่ผมเลือกใช้ตอนที่อยากรู้ว่าหนังสือของผมควรจะมีอะไรอยู่ในนั้นบ้าง ผมเลือกที่จะขีดๆเขียนๆหัวข้อ เนื้อหาที่คิดว่าควรจะมี ลองสลับเรียงหนึ่ง สอง สามไปเรื่อยจนเป็นที่พอใจ แล้วก็เริ่มเปิด Open Office Writer แล้วก็ร่างสิ่งที่อยากได้ลงในไฟล์ จากนั้นกระดาษแผ่นนั้นก็หมดความหมายสำหรับผมและหนังสือของผม

ทำไมผมถึงเลือกใช้ Throwaway Prototyping … สำคัญที่สุดเลยคือง่ายและเร็วครับ ไม่ต้องมีรูปแบบ ไม่ต้องสนใจเรื่องของคุณภาพ ไม่ต้องยึดติดกับอะไรทั้งนั้น อยากทำอะไรก็ทำครับ เพราะแบบนี้มันเลยเป็นที่นิยมมากสำหรับใครก็ตามที่อยากรู้ว่า “เอ๊ะ ตกลงแล้วเราอยากได้อะไรกันแน่เนี่ย” … ประโยคนี้คุ้นๆมั้ยครับ ผมกำลังจะชี้ให้เห็นว่ามันเหมือนกับตอนที่เราคุยกับลูกค้าเรื่อง Requirement เลย มองในมุมของ Software Development ประโยชน์ที่ชัดเจนของ Throwaway ข้อแรกคือช่วยเราได้อย่างมากในกระบวนการการเก็บ Requirement จากลูกค้า ช่วยให้เราเขียน Requirement Document ได้ชัดเจน กระจ่างและครบถ้วนด้วยครับ

เทคนิคของ Throwaway Prototyping ที่เด่นๆก็เช่น ง่ายสุดเลยครับ Paper Prototyping ซึ่งเป็นการวาด/ขีด/เขียนสิ่งที่เป็นต้นแบบของงานลงในกระดาษ แล้วก็เอาให้ลูกค้าดูเพื่อสร้างความเข้าใจร่วมกันใน Requirement แต่ละตัว วิธีนี้เหมาะมากกับงานที่มีหน้าตาให้ลูกค้าจับต้องได้อย่างพวก User Interface ทั้งหลาย จากรูปผมลองออกแบบหน้าจอหนึ่งในระบบ Automatic Draft Checking จากบทความที่แล้วดูครับ

อีกวิธีหนึ่งที่นิยมกันก็คือ GUI Builder วิธีนี้ลึกล้ำกว่า Paper Prototyping นิดนึงโดยเป็นการสร้างหน้าตา User Interface หลอกๆขึ้นมาพร้อมกับอธิบายขั้นตอนการทำงาน (Workflow) ของระบบด้วยปุ่ม Click Dummy ครับ ปุ่มพวกนี้เมื่อกดแล้วจะพาเราไปสู่ขั้นตอนต่อไปของระบบโดยที่ไม่มีการทำงานอะไรจริงๆนะครับ เช่น จากรูปผมเลือกแบบที่ต้องการจะตรวจสอบแล้วก็กดปุ่ม Check Drafts มันก็จะมี Pop up ที่เป็น Progress Bar แสดงขึ้นมาโดยไม่มีการทำงานจริงนะครับ

ประโยชน์ของ GUI Builder คือมันช่วยเราตรวจสอบความเข้าใจเรื่องการทำงานโดยรวมและขั้นตอนต่างๆของระบบทั้งของลูกค้าและตัวเรา มันจะช่วยทำให้ทั้งสองฝ่ายเข้าใจตรงกันว่าระบบนั้นต้องมีหน้าตาออกมาเป็นยังไง รูปนี้สวยดีนะครับ (ฮ่าๆ ชมผลงานตัวเอง) ถ้าเพื่อนๆชอบเหมือนผม ลองใช้บริการจากเวปไซต์นี้ดูครับ ช่วยเราทำ User Interface Prototype ได้ดีเยี่ยมเลยหละ

ทั้งสองวิธีนี้ถือว่าเร็วและง่ายครับ โอเคหละ วิธีแรกง่ายกว่าแน่ๆ ผมใช้เวลาคิดและวาดรูปประมาณ 10 นาที สำหรับวิธีที่สองผมใช้เวลาทำ User Interface ประมาณครึ่งชั่วโมงครับ … ถือว่าเร็วนะ

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

1. หลังจากที่ได้ Requirement เบื้องต้นมาแล้ว เราจะเริ่มออกแบบ Prototype ตามข้อมูลที่ได้มาครับ อาจจะวาดรูปเอาหรือสร้างหน้าจอหลอกๆขึ้นมาก็แล้วแต่ความเหมาะสม
2. นำ Prototype ที่ได้ไปเสนอลูกค้าเพื่อเก็บข้อมูลเพิ่มเติม ข้อมูลที่เราอยากได้ก็คงมี Requirement นี้ทำงานยังไง? รูปร่างหน้าตาที่เหมาะสมเป็นไปตาม Prototype รึเปล่า? แล้วก็นอกจากนี้แล้ว มี Requirement อื่นๆอะไรอีกบ้างที่เกี่ยวข้องกับระบบ? หลายครั้งเมื่อลูกค้าเห็นหน้าตาคร่าวๆของระบบแล้ว Requirement จะเพิ่มมาอย่างน่าอัศจรรย์ครับ ฮ่าๆ
3. หลังจากได้ข้อมูลมาครบถ้วนแล้ว เราก็ปรับปรุง แก้ไข เพิ่มเติม Prototype ให้เป็นไปตามนั้นแล้วก็นำไปเสนอลูกค้าอีกรอบ เพื่อเก็บข้อมูลเพิ่มเติมครับ ทำแบบนี้ไปจนกว่าลูกค้าและเราจะตกลงกันได้ในเรื่อง Requirement ครับ
4. เขียน Requirement Document ฉบับสมบูรณ์ซึ่งเป็นฉบับที่ทั้งลูกค้าและเราจะต้องเซ็นอนุมัติ (Sign Off) ก่อนเริ่มพัฒนาระบบครับ
5. เมื่อตกลงกันได้แล้ว เราก็เริ่มพัฒนาระบบจริงเลยครับ
   

เราใช้ประโยชน์จาก Throwaway Prototyping ได้มากกว่าเรื่อง Requirement ครับ ผมเองเคยใช้เทคนิคนี้ในการพิสูจน์ว่าเรื่องต่างๆทำได้หรือไม่ได้ในทางเทคนิค ตอนนั้นผมเคยสงสัยว่า Web Application ที่เป็น ASP.Net เนี่ยะ มันสร้างรายงาน Excel ที่มี Line Chart อยู่ด้วยได้มั้ย? ผมรู้อยู่แล้วครับว่า Web Application ตัวที่ผมมีอยู่มันซับซ้อนมากเลย จะแก้อะไรทีค่อนข้างจะยุ่งยากและเสี่ยงต่อการทำให้ Code พัง ผมเลยเลือกที่จะสร้าง Project Web Application เล็กๆขึ้นมาเพื่อทดสอบเรื่องนี้โดยเฉพาะ วิธีนี้ง่ายและเร็วกว่าเยอะเลยครับ ไม่นานผมก็ได้ Prototype Code ขึ้นมาชุดหนึ่งที่ทำงานได้ตามต้องการเป๊ะ จากนั้นผมค่อยเริ่มประยุกต์ใช้วิธีการนี้เข้าไปใน Code จริงแล้วเจ้า Prototype ก็หมดความหมายไป

ถ้าโยงกลับไปถึง Automatic Draft Checking ของเรา ผมสัณนิฐานว่าช่วงปีแรกงานหลักน่าจะเป็นการทำ Prototype เพื่อหา Requirement ที่แท้จริงไปพร้อมๆกับการลองผิดลองถูกกับเทคโนโลยีต่างๆไปด้วย Throwaway Prototyping เป็นพระเอกในช่วงปีแรกเลยครับ

ทั้งหมดนี้คือ Throwaway Prototyping ที่ใช้ได้เรื่อยๆเพราะง่าย เร็วและราคาถูกครับ บทความหน้าผมจะแนะนำ Prototype อีกแบบที่เหมาะกับงานที่ต่างไปจากนี้รวมถึงแนวทางที่จะใช้ประโยชน์จาก Prototype ทั้งสองแบบใน Software Development Project ครับ

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

The Best Scene from Love Actually

… To me you are perfect … And my wasted heart will love you …

Merry Christmas

~ Mark and Juliet from Love Actually (2003)

ปล. ไม่รู้ว่าเป็นคำคมตรงไหนเหมือนกันครับ อยู่ดีๆก็คิดถึงฉากนี้ขึ้นมา … ซึ้งที่สุดในเรื่องแล้ว ผมเชื่อว่าหลายๆคนก็คงคิดตรงกัน ลองตามไปดูที่นี่ครับว่าซึ้งยังไง สำหรับผมเอง ผู้ชายเท่ห์มากๆๆ … โดยเฉพาะคำพูดที่ว่า “Enough, Enough Now” … สุดๆไปเลย

สำหรับเพื่อนๆที่ไม่เคยดู ที่มาที่ไปของฉากนี้คือ ผู้หญิง (Keira Knightley) กำลังจะ … ไม่เอาดีกว่า เล่าไปเดี๋ยวเสียอรรถรสในการรับชมหมด แนะนำว่าควรหามาดูอย่างยิ่งครับ สนุกมาก

Complicated Job

ในสมัยก่อนการตรวจสอบแบบก่อสร้างอาคารต่างๆเป็นเรื่องที่ต้องใช้ผู้เชี่ยวชาญ แรงงานคน และเวลามากทีเดียวกว่าจะสรุปได้ว่าแบบของอาคารนี้ถูกต้องตามมาตรฐานและกฎหมายหรือไม่ ช่วงประมาณปี 1994 ในขณะที่เศรษฐกิจเอเชียกำลังรุ่งเรืองสุดขีด ประเทศสิงคโปร์ก็มีโครงการก่อสร้างและปรับปรุงอาคารต่างๆเยอะแยะมากมาย (ถึงแม้ประเทศจะเล็กนิดเดียวก็ตาม) เรื่องนี้สร้างปัญหาใหญ่ให้กับรัฐบาลของสิงคโปร์ในเรื่องความล่าช้าในการตรวจสอบและอนุมัติแบบ บางโครงการต้องใช้เวลาถึง 9 เดือนเลยก็มี แบบนี้เอกชนก็ไม่ค่อยจะชอบเท่าไรเพราะว่าโอกาสทางธุรกิจนั้นรอไม่ได้ รัฐบาลเลยคิดหาทางแก้ไขปัญหานี้โดยเร็วซึ่งความต้องการทางธุรกิจ (Business Requirement) ก็เกิดขึ้นตรงนี้นี่เอง

เป้าหมายหลักของรัฐบาลสิงคโปร์คือลดเวลาที่ใช้ในการตรวจแบบลงจาก 9 เดือนให้เหลือ … 10 วัน … เป็น Project Objective ที่โหดน่าดูใช่มั้ยครับ? ตัวเลือกที่จะทำให้ความต้องการนี้เป็นจริงขึ้นมามีอยู่ 3 ทางคือ

1. ให้เอกชนทำเอง … ออกแบบเอง ตรวจแบบเอง รัฐบาลไม่ทำให้ ทางเลือกนี้ก็จะช่วยลดงานและเวลาได้เยอะมากๆ แต่ปัญหาคือว่ามาตรฐานจะควบคุมได้มั้ย? แล้วถ้ามีความผิดพลาดเกิดขึ้นผลเสียหายมันดูจะไม่คุ้มเลยกับสิ่งที่ได้มาเนอะ
2. เพิ่มจำนวนคนของรัฐบาลเข้าไป … ก็ง่ายๆดีครับ ต้องการลดเวลาก็เพิ่มคนทำงานเข้าไป แต่ปัญหาที่ตามมาก็มีเยอะอยู่ ก็เรื่องเกี่ยวกับคนๆทั้งหลายแหละครับ แรกสุดคือผู้เชี่ยวชาญและแรงงานที่มีจำกัด ความผิดพลาดที่เกิดขึ้นจากมนุษย์ ความต้องการด้านต่างๆ เช่น เงินเดือน สวัสดิการ โบนัส ความก้าวหน้าด้านอาชีพ อื่นๆครับ รัฐบาลชั่งน้ำหนักดูแล้ว ไม่คุ้ม
3. ใช้ IT เข้ามาช่วย … ดูแล้วก็ดีครับ ไม่ต้องใช้คนเยอะ ความผิดพลาดก็(น่าจะ)ลดลงได้ แต่ปัญหาที่ตามมาคือ ณ เวลานั้นไม่มีใครตอบได้ว่าทางเทคนิคแล้ว IT จะช่วยแก้ปัญหานี้ได้จริงหรือไม่ นั่นคือไม่มีใครบอกได้ว่าระบบ Automatic Building Draft Checking จะทำขึ้นมาได้แล้วใช้ได้ผลดีจริงๆ

เมื่อชั่งน้ำหนักตัวเลือกทั้งสามแล้ว รัฐบาลก็ตัดสินใจว่าจ้างให้บริษัทแห่งหนึ่งพัฒนาระบบนี้ขึ้นมาจริงๆ ตอนนั้นโครงการนี้ถือว่าเป็นเรื่องใหญ่เลยนะครับสำหรับวงการ IT และ Construction ของสิงคโปร์ บริษัทนี้มีความกดดันพอสมควรที่ต้องทำงานที่ไม่มีใครรู้ว่าเป็นไปได้หรือไม่ ด้วยข้อจำกัดทั้งเรื่องรูปร่างหน้าตาของระบบและเทคโนโลยีที่จะใช้เอง Project Manager มองเห็นแล้วว่าถ้าดันทุรังพัฒนาระบบไปแบบตาบอดคลำช้างโอกาสจะล้มเหลวมีมาก เขาเลยตัดสินใจเลือกใช้วิธี Software Prototyping เข้ามาจัดการกับ Project ยักษ์นี้ครับ เขาทำยังไง?

รัฐบาลบอกมาว่าต้องทำให้เสร็จภายใน 4 ปี (ดูเหมือนยาว แต่งานมันยากจริงครับ) เขาเลือกที่จะบอกรัฐบาลไปว่า “ผมขอ 2 ปีแรกก่อนแล้วจะบอกว่าระบบนี้ทำได้หรือไม่ได้” รัฐบาลก็ตกลงแล้วจัดสรรงบประมาณมาให้แค่ 2 ปีแรกก่อน เอาหละ กับเวลาที่มี 2 ปีและเงินจำนวนนี้เขาทำยังไงบ้าง ที่เขาคิดคือไม่วางแผนทำเป็น Project เดียวเพราะว่าความไม่แน่นอนในงานมีมากเหลือเกิน โอกาสที่จะผิดพลาดและล้มเหลวมีสูงอยู่ ดังนั้นเขาจึงตัดงานออกมาเป็น 2 ส่วนต่อเนื่องกัน 1 ส่วน 1 Project แต่ละ Project ก็มี Objective และ Scope ของตัวเองที่ชัดเจน Project แรกจะเน้นไปที่การศึกษาและทดลองเทคโนโลยีที่มีความเป็นไปได้ทั้งหมดเพื่อเฟ้นหาเทคโนโลยีที่เหมาะสมที่สุดที่จะใช้กับระบบ เมื่อผ่านไป 1 ปีก็จะมีการ Review ครั้งใหญ่เพื่อดูความเป็นไปได้ที่จะนำเทคโนโลยีนั้นๆไปต่อยอด … เอาหละ 1 ปีแรกที่ผ่านไปเขาได้คำตอบแล้วว่า งานนี้มีหวัง

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

เขากลับไปบอกรัฐบาลว่า “งานนี้พร้อมลุยครับท่าน” เขาได้เวลามาอีก 2 ปีพร้อมงบประมาณก้อนใหญ่เพื่อทำความฝันให้เป็นความจริง จากที่เคยมีแต่ความไม่แน่นอนทั้งเรื่องความต้องการและเทคโนโลยี ตอนนี้ทุกอย่างเป็นรูปเป็นร่างมากขึ้นแล้วครับ เขาไม่เลือกที่จะแบ่งงานเป็น Project ย่อยๆแล้ว เอา Project เดียวนี่แหละ 2 ปีไปเลย วาง Objective และ Scope ให้ชัดเจน …

ผ่านไปอีก 2 ปี รัฐบาลก็ได้ระบบ Automatic Building Draft Checking มาใช้สมใจอยากครับ

Software Prototyping

เก่งนะครับ Project Manager คนนี้ จัดการ Project ที่ซับซ้อนให้ลุล่วงไปได้อย่างสวยงาม สังเกตเห็นแนวคิดในการวางแผน Project ของเค้ามั้ยครับ? ผมมองว่าตรงนี้นี่เองที่เป็นส่วนสำคัญที่ทำให้งานเสร็จได้ ใช่ครับ ผมกำลังพูดถึงการแบ่งงานทั้งหมดออกเป็นสาม Project ย่อยที่มี Objective และ Scope ของตัวเองที่ชัดเจน แนวคิดนี้เรียกว่า Software Prototyping ครับ

การเลือกทำงานทั้งหมดเป็น Project ใหญ่ที่มีระยะเวลายาวสี่ปีนั้นเสี่ยงมากครับ เพราะว่าในตอนนั้น Requirement และความเป็นไปได้ของงานนั้นยังไม่ชัดเจนเลย การวางแผนให้ละเอียดรอบคอบแทบจะเป็นไปไม่ได้ เช่น ความไม่ชัดเจนนี้ส่งผลให้การทำ Work Breakdown Structure และการ Estimate ระยะเวลาที่จะใช้ก็ยากขึ้นมาก

แต่พอแบ่งงานใหญ่ออกเป็นงานที่เล็กลงแล้ว ทำให้ Scope ของงานมีความชัดเจนมากขึ้นเยอะเลยครับ อย่าง Project แรกในปีที่ 1 นั้นก็เน้นไปที่การศึกษาหาเทคโนโลยีที่พอจะเอามาปรับใช้กับงานได้ ควบคู่ไปกับการเก็บ Requirement จริงๆจากผู้ใช้ (ก็หน่วยงานของรัฐบาลสิงคโปร์ครับ) ไปด้วย เมื่อ Project แรกเสร็จก็มีการรีวิวผลของมันอย่างละเอียดเข้มข้นเพื่อดูว่า สุดท้ายแล้วเราควรจะลงทุนกับโครงการ Automatic Building Draft Checking อีกต่อไปหรือไม่ สิ่งที่ต้องดูก็พวกความเป็นไปได้ทางเทคนิค ความคุ้มค่าทางธุรกิจและความคุ้มค่าทางการเงินครับ

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

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

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

ล้มเพื่อลุก

And why do we fall, Bruce? So we can learn to pick ourselves up.

~ Thomas Wayne from Batman Begins (2005)