โปรเจ็คมีกี่แบบ

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

หนึ่งในเรื่อง “รู้งี้” ของผมคือ ประเภทหรือลักษณะของโปรเจ็ค ซึ่งแบ่งได้ง่ายๆ 3 ประเภท คือ

1. Clean Slate

คือโปรเจ็คที่เริ่มต้นใหม่เอี่ยม ไม่มีข้อเปรียบเทียบ ลูกค้าไม่เคยใช้งานระบบใดๆ มาก่อน ถ้าไม่ใช่การเริ่มต้นธุรกิจใหม่ หรือเริ่มใช้เทคโนโลยีเป็นครั้งแรก ก็จะเป็นพวก paperless คือเปลี่ยนจากระบบอนาล็อกมาเป็นดิจิตัล โปรเจ็คประเภทนี้เรียกได้ว่าเป็นโปรเจ็คในฝันของโปรเจ็คแมเนเจอร์และทีมงานทุกคน ทุกอย่างเริ่มต้นสดๆ ไม่มีข้อจำกัดใดๆ ลูกค้าน่ารักให้ข้อมูลเชิงลึกได้ละเอียด และไม่เรื่องมาก ที่สำคัญสามารถเลือกใช้เทคโนโลยีใหม่ล่าสุดที่อยากเล่นอยากลองได้เต็มที่ มักไม่มีข้อจำกัดเรื่องกรอบเวลามากมายนัก คือสามารถต่อรองได้มากบ้างน้อยบ้าง ถ้าไปสมัครงานบริษัทไหนแล้วเขาบอกว่าจะได้ทำโปรเจ็คประเภทนี้สมควรรีบคว้าไว้ทันที ที่สำคัญมักเป็นโปรเจ็คที่ให้ประสบการณ์และความทรงจำที่ดีอีกด้วย วิธีสังเกตโปรเจ็คแบบนี้คือ มักจะมีคำใบ้มากับชื่อโปรเจ็ค เช่น Mobile XXX, XXX web, e-XXX ฯลฯ

วิธีการจัดการโปรเจ็คประเภทนี้ให้ง่าย ราบรื่นและจบสวย คือการ ทำงานร่วมกับลูกค้าใกล้ชิดและต่อเนื่อง สร้าง fast feedback loop เพื่อฟังผลสะท้อนจากลูกค้าให้รวดเร็ว และตอบสนองให้ได้มากที่สุด ลูกค้าจะแฮปปี้ และให้ความร่วมมือดี ที่สำคัญโฟกัสที่ปัญหาของลูกค้าโดยเฉพาะ pain point ต่างๆ ไม่ต้องพยายามควบคุมเรื่องเวลามากเกินไป เพราะสามารถอะลุ่มอล่วยได้ มากบ้างน้อยบ้าง แต่ถ้าไม่ตอบโจทย์อาจมีโอกาสเกิดอาการโปรเจ็คล้มได้ง่ายๆ เหมือนกัน เพราะไม่มีข้อผูกมัดว่าจะต้องทำให้สำเร็จให้ได้ ความสัมพันธ์กับลูกค้าจึงเป็นหัวใจของความสำเร็จของโปรเจ็คประเภทนี้

2. Enhancement

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

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

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

อีกเรื่องที่เป็นจุดตายของโปรเจ็คประเภทนี้คือการทำ gap analysis หรือที่แปลแล้วไม่เข้าใจว่า “การวิเคราะห์ช่องว่าง” กล่าวคือเราจะต้องรู้ว่าระบบเดิมทำงานอย่างไร และการเปลี่ยนแปลงแต่ละอย่างจะส่งผลกระทบอะไรบ้าง วิธีที่ดีที่สุดและประหยัดที่สุดคือ การใช้ทีมงานเดิม ย้ำว่าทีมงานเดิมไม่ใช่โปรเจ็คแมเนเจอร์คนเดิม หรือ ผู้รับเหมาเจ้าเดิม ต้องเป็นกลุ่มคนกลุ่มเดิมที่เป็นคนสร้างระบบในครั้งแรก มาดำเนินการแก้ไข จึงจะได้ผลลัพธ์ที่ดีและราบรื่น อย่ายึดมั่นกับ เอกสาร หรือ ซอร์สโค้ด ใดๆ ทั้งสิ้น เพราะเอกสารมักไม่ถูกแก้ไขให้เป็นปัจจุบันและไม่ได้อธิบายว่า โปรแกรมถูกเขียนขึ้นมาได้อย่างไร และถึงแม้ได้ตัวโปรแกรมมาก็ไม่สามารถบอกได้ว่าทำไมจึงเลือกที่จะเขียนแบบนั้น เพราะฉะนั้นจึงมีแต่คนที่เขียนมันขึ้นมาเท่านั้นที่จะอธิบายเหตุผลเหล่านั้นได้ ถ้าหากว่าเราหาตัวทีมงานที่สร้างมันขึ้นมาไม่ได้ เราก็ต้องแปลงร่างกลายเป็นนักสืบไม่ก็นักโบราณคดี วิเคราะห์ว่าทำไมเขาถึงเขียนไว้แบบนี้ หรือบางครั้งกลายเป็นหมอดูทางในไปเลยก็มี ที่สำคัญการวิเคราะห์แบบนี้มีโอกาสผิดพลาดสูงและกินเวลามาก ประกอบกับโปรเจ็คที่มีเวลาจำกัดและเส้นตายที่เปลี่ยนแปลงได้ยาก จึงนำมาซึ่งความเครียดและอาการปวดเศียรเวียนเกล้าแก่โปรเจ็คแมเนเจอร์และทีมงานเป็นอย่างยิ่ง วิธีหนึ่งที่จะช่วยลดความเครียดนี้คือ การใช้ Unit Test ตระกูล xUnit เช่น JUnit, NUnit, TestNG ฯลฯ เพื่อช่วยในการทำความเข้าใจโค้ดเดิม และยังช่วยป้องกันผลกระทบที่ไม่พึงประสงค์ (side effect) จากส่วนที่เราแก้ไขเพิ่มเติมอีกด้วย

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

3. Modernization

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

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

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

แม้ว่าการจะสร้างระบบใหม่ให้เหมือนเดิม แต่เปลี่ยนตรงนั้นตรงนี้จะยากแล้ว แต่เมื่อใช้ความอดทนพยายามกับเวลา น้ำตา และ หยาดเหงื่อ โปรเจ็คแมเนเจอร์และทีมงานก็ฝ่าฟันมาถึงใกล้วัน go live มาถึงโค้งสุดท้ายที่เราจะต้องฝ่าฟันคือการ โอนย้ายข้อมูลจากระบบเดิมมาสู่ระบบใหม่ ที่เรียกว่า data migration ข้อมูลจำนวนมหาศาลที่ต้องมีการจับคู่ (data mapping) และแปลงรูปแบบ (data transformation) เพื่อให้เข้ากับของใหม่เป็นเรื่องน่าปวดหัวเป็นที่สุด ความที่ไม่ได้เตรียมการมาตั้งแต่ต้น อีกทั้งของเดิมและของใหม่ใช่ว่าจะเหมือนกันเสียทีเดียว มักมีความแตกต่างระหว่างของเดิมกับของใหม่มากพอดู ที่สำคัญที่สุดคือมีเวลาเพียงไม่กี่วันเท่านั้นที่จะทำได้ เพราะระบบเก่าต้องหยุดทำงานในขณะที่มีการโอนย้ายข้อมูลเรียกว่าต้องปิดบริษัทคอย งานการไม่ต้องทำ ส่วนใหญ่มีเวลาเพียงสองสามวันเท่านั้น อย่างมากก็ไม่น่าจะเกินห้าวันเจ็ดวัน ก็โดนด่าเช็ดแล้วสิ่งที่เรียกว่าเป็นจุดตายของจุดตายอีกทีคือ “ข้อมูลขยะ” ที่เรียกว่า garbage ที่จะต้องมีการตามแก้ไขที่เรียกว่า การ data patching ที่ต้องตามไปแก้ไขปรับปรุงอย่างไม่รู้จบ

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

การแก้ไขปัญหาของโปรเจ็คประเภทนี้เราจะต้องเข้าใจก่อนว่า การโอนย้ายข้อมูล คือส่วนที่ยากที่สุด เพราะฉะนั้นต้องจัดการเรื่องนี้ก่อน ส่วนใหญ่ที่เดินผิดกันคือ การคิดว่าจะทำการโอนย้ายแบบ Big Bang คือกะว่าเอาครั้งเดียวเสร็จ เนื่องจากระบบยิ่งใหญ่ยิ่งมีประวัติศาสตร์ยาวนานก็ยิ่งโอนย้ายยาก วิธีการแบบค่อยเป็นค่อยไปและต่อเนื่อง (continuous) จึงปลอดภัยกว่าเป็นไหนๆ กล่าวคือ ค่อยๆ สร้างโปรแกรมใหม่มากินส่วนแบ่งของโปรแกรมเก่าอย่างช้าๆ ส่วนไหนของโปรแกรมที่โอนย้ายมาของใหม่แล้วส่วนข้อมูลก็ย้ายมาเฉพาะเท่าที่จะให้ส่วนนั้นทำงานได้ เพราะฉะนั้นจะมีการทำโปรแกรมที่คอยทำการซิงค์ข้อมูลระหว่างระบบเก่าและใหม่ให้เป็นปัจจุบันด้วย ในส่วนของโปรแกรมอาจจะมีลิงค์จากระบบใหม่ไปหน้าจอของระบบเก่า เพื่อให้ผู้ใช้ไม่จำเป็นต้องรู้ว่าส่วนไหนต้องใช้ของใหม่ส่วนไหนใช้ของเก่า เข้าจากหน้าจอเดียวกันได้เลย หรือถ้าจะให้การใช้งานราบรื่นขึ้นอีกก็ทำเป็นหน้ากากในระบบใหม่แล้วไปต่อหลังบ้านเข้าระบบเก่า การพัฒนาระบบใหม่มาแทนจะทำอย่างค่อยเป็นค่อยไปและยาวนาน โดยเมื่อจะพัฒนาเพิ่มเติมส่วนไหน ก็ไม่ไปเพิ่มที่ระบบเก่าแต่เพิ่มในระบบใหม่ขึ้นมาแทนที่ ผู้เขียนเคยได้ร่วมงานกับทีมของบริษัทข้ามชาติแห่งหนึ่ง ระบบที่พัฒนามีการทำ modernization ซ้อนๆ กันถึง 5 ยุค ตอนครบรอบ 14 ปีเพิ่งจะได้ฉลองโอกาสที่ปลดระวางโค้ดยุคแรก หมายความว่ายังมีโค้ดอีกถึง 4 ยุคที่วิ่งขนานกันไปอยู่ในโปรดักท์ชั่น กล่าวคือ modernization การเป็นส่วนหนึ่งของการทำ enhancement โดยธรรมชาติไปเลย

บทส่งท้าย

ผู้เขียนพบว่าหลายที่หลายแห่งมีปัญหาจากการ modernization แล้วหันมาหาการพัฒนาซอฟแวร์แบบอไจล์ด้วยความเชื่อว่าจะช่วยแก้ปัญหาได้ แต่ตอนเริ่มต้นมักทดลองด้วยการใช้วิธีการทำงานแบบอไจล์กับโปรเจ็คประเภท clean slate แล้วพบว่าได้ผลดี ก็ตีขลุมไปว่า อไจล์ใช้งานได้ดี หรืออาจได้ทดลองกับโปรเจ็คประเภท enhancement ด้วย แล้วพบว่าก็ได้ผลดีอยู่นั่นเอง จึงสรุปว่า อไจล์ดีจริงๆ แต่เมื่อมาเจอกับโปรเจ็คปราบเซียนประเภท modernization แล้วก็ช้ำในถึงกับกระอักเลือด บางแห่งคิดไปว่า อไจล์ดีจริงๆ แต่เรายังทำมันเข้มข้นไม่พอ แล้วก็ตะบี้ตะบันทำไป จนพังไปเป็นแถบก็มี หรือคิดว่าอไจล์ใช้งานจริงไม่ได้ แล้วหันกลับไปใช้ waterfall แบบเดิมก็มี

ที่ถูกต้องคือต้องเข้าใจก่อนว่า โปรเจ็คนั้นมีหลายประเภทและต้องมีวิธีการจัดการที่แตกต่างกันไป สำหรับการสร้างโปรเจ็คใหม่ อย่าง clean slate หรือการพัฒนาต่อยอด แบบ enhancement ถ้าหากเราระลึกถึงการทำงานแบบ modernization อยู่ตลอดเวลา ก็สามารถหลีกเลี่ยงฝันร้ายที่จะเกิดขึ้นในอนาคต และทำงานได้อย่างราบรื่น ตลอดไป.

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  เปลี่ยนแปลง )

Google photo

You are commenting using your Google account. Log Out /  เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out /  เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out /  เปลี่ยนแปลง )

Connecting to %s