แค่การพัฒนาซอร์ฟแวร์ (Just a Software Development)

DinoQ Entrepreneur Platform 2016/08 ( info@dinoq.com )

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

พัฒนาได้เร็ว แก้ไขปรับเปลี่ยนได้ง่าย มีแค่นี้จริงๆ

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

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

และการที่ให้ผู้ใช้สัมผัสแอพพลิเคชันเราบ่อยขึ้น เป็นการเพิ่มความมั่นใจได้ว่าแอพพลิเคชันเราจะพัฒนาได้ตรงความต้องการของผู้ใช้มากขึ้น

การพัฒนาแอพพลิเคชันใดๆ ประกอบมาจากส่วนประกอบหลักๆคล้ายๆกัน คือ 1. ความต้องการ 2. การออกแบบ และสุดท้าย 3. การพัฒนาและใช้งาน โดยทั้งสามส่วนประกอบหลักนี้จะสามารถแยกย่อยรายละเอียดได้อีก

เล่าเรื่องความต้องการ

เราลองมาดูส่วนแรกสุดกันก่อน นะครับ นั่นคือ ความต้องการนั่นเอง มันคือความต้องการของผู้ใช้, หัวหน้างาน หรือแม้กระทั่งผู้บริหาร เพื่อที่จะได้จัดหา หรือจัดทำแอพพลิเคชันมาใช้งานเพื่อตอบปัญหาของความต้องการนั้นๆ

ลองมาดูนะครับ ว่าไอ้ความต้องการนี่มันประกอบไปด้วยอะไรบ้าง

1. ความต้องการเชิงธุรกิจ ปกติหัวใจของทุกๆธุรกิจคือผลิตภัณฑ์ ดังนั้นความต้องการโดยมากจะมาจากกระบวนการรอบๆผลิตภัณฑ์นี่แหละ ไม่ว่าเป็น การผลิต การขาย การขนย้าย และอื่นๆ โดยจะเห็นว่ากระบวนการเหล่านี้ใช้ไปนานๆปีเข้าก็มีคนออกเป็นมาตรฐาน เช่น ระบบ ERP (Enterprise Resource Planing), ระบบ CRM (Customer Relationship Management) และอื่นๆ อีกมาก ในหลายๆปีก่อน การทำธุรกิจจะอิงกับมาตรฐานเหล่านี้ แต่ในปัจจุบัน การแข่งขันธุรกิจสูงขึ้น องค์กรต่างๆที่ต้องการโอกาสทางธุรกิจที่ดีกว่ามักจะออกแบบกระบวนการทางธุรกิจนี้ขึ้นใหม่ ใส่นวัตกรรมเข้าไปให้มีโอกาสได้เปรียบมากกว่าองค์กรอื่นๆ ดังนั้นยุคนี้จึงเป็นยุคที่ค่อนข้างไร้มาตรฐาน กระบวนการเป็นได้ทุกแบบขึ้นอยู่กับนโยบายขององค์กร และคนที่ให้ความต้องการต้องพึงระลึกอยู่เสมอว่าสิ่งที่ให้ไปเป็นความต้องการใหม่ที่ใส่นวัตกรรมเข้าไปแล้ว ไม่ใช่ความต้องการที่ยังอิงกับกระบวนการเดิม
2. ความต้องการเชิงเทคนิค เช่น ระบบต้องสามารถรองรับคนมากๆได้ ระบบต้องมีความปลอดภัยระดับสูง ระบบต้องทำงานได้ตลอดเวลา หากระบบหลักมีปัญหาต้องมีระบบสำรอง ซึ่งในอนาคตของพวกนี้จะไม่ใช่ของที่องค์กรควรใส่ใจมากอีกต่อไป ควรยกภาระเหล่านี้ให้ไปอยู่กับคนที่ให้บริการระบบ หรือแพลตฟอร์ม

และความต้องการใดๆของผู้ใช้งานมักเป็นความต้องการที่จะประยุกต์ใช้แอพพลิเคชันเพื่อให้เกิดผลตามข้อต่างๆด้านล่าง

1. ทำให้สามารถแก้ปัญหางานปัจจุบันได้
2. ทำให้งานปัจจุบันที่ดีอยู่แล้ว ทำให้ได้ผลดียิ่งขึ้นไปอีก
3. ทำให้สามารถทำงานที่เป็นไปไม่ได้ ให้สามารถเป็นไปได้

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

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

องค์กรขนาดใหญ่จะมีหน่วยงาน และกระบวนการค่อนข้างซับซ้อนในการแปลงความต้องการไปเป็นแอพพลิเคชัน หัวใจหลักในการทำมี 2 อย่างหลักๆคือ 1. การวิเคราะห์หาความต้องการของแอพพลิเคชันที่แท้จริง กับ 2. การกำหนดมาตรฐาน กรอบการทำงานที่สอดคล้องกับภาพรวมองค์กร หรือหน่วยงานควบคุม

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

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

สรุปคือ ความต้องการไม่ค่อยชัดเจนหรอก และมันก็เปลี่ยนไปเรื่อยๆแหละ

เล่าเรื่องการออกแบบ

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

การออกแบบเชิงสถาปัตยกรรม(Architectute Design) ซึ่งเป็นตัวกำหนดคุณลักษณะของแอพพลิเคชันนั้นๆ ว่าให้ไปในทิศทางใด โดยกำหนดกรอบจาก 1. กรอบภาพรวมความต้องการเฉพาะตัวของแอพพลิเคชันนั้นๆ เช่น เป็นแพพลิเคชันที่มีส่วนติดต่อผู้ใช้, เป็นแอพพลิเคชันเซอร์วิส, เป็นแอพพลิเคชันที่ต้องติดต่อกับฮาร์ดแวร์ หรืออื่นๆ 2. กรอบความต้องการเพื่อให้สอดคล้องกับทิศทางองค์กร เช่น เน้นไปใช้ระบบคลาวด์, ใช้การออกแบบด้วยไมโครเซอร์วิส หรืออื่นๆ 3. กรอบความต้องการของหน่วยงานควบคุม เช่น เก็บข้อมูลการใช้งานสามปี, ต้องผ่านมาตรฐานด้านความปลอดภัย หรืออื่นๆ

การออกแบบเชิงวิศวกรรม(Application Design) เป็นการเอากรอบความต้องการในข้อแรก มาลงรายละเอียดในการพัฒนาแอพพลิเคชัน เช่น สร้างด้วยเครื่องมืออะไร แบ่งเป็นกี่โมดูล ติดตั้งงานใช้งานอย่างไร เป็นต้น

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

กลับกลายเป็นว่า ปัญหาหนักจะตกไปฝั่ง การออกแบบเชิงวิศวกรรม เพราะดันไปยึดโยงกับการสร้างระบบให้เป็นจริงให้ได้จากทั้ง ความต้องการ (ที่เรารู้ว่าไม่มีวันชัดเจน และเดี๋ยวมันก็เปลี่ยน) และ การออกแบบเชิงสถาปัตยกรรม (ที่จับต้องอะไรไม่ค่อยจะได้)

และ การออกแบบเชิงวิศวกรรมนี้ มีรายละเอียดที่ต้องลงเยอะมาก ไม่ว่าเป็น ภาษา, แพลฟอร์ม, เฟรมเวิร์ก, เครื่องมือ, เน็ตเวิร์ก, เซอร์ฟเวอร์ และอื่นๆ อีกโคตรเยอะ ซึ่งการเลือกเครื่องมือในการทำงานเหล่านี้เป็นตัวกำหนด ชะตาชีวิตของทีมพัฒนาเลยที่เดียว

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

เล่าเรื่องการพัฒนาและใช้งาน

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

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

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

สรุป รับกรรมมา รีบทำรีบแก้ปัญหา ค่อยๆปรับไป

จากที่เล่ามาทั้งหมด ผมพยายามจะเปรียบเทียบให้เห็นภาพโดยใช้รูปด้านล่าง เป็นตัวแสดงให้เห็นกระบวนการพัฒนาแอพพลิเคชันขององค์กรใหญ่ๆ ว่าต้องทำอะไรบ้าง มีทีมใหนบ้าง มีกระบวนการการทำงานอะไรบ้าง (ผมไม่อธิบายรายละเอียด นะครับ ภาพน่าจะแสดงให้เห็นชัดพอสมควร)

ภาพถัดมาจะแสดงให้เห็นว่า ถ้ามีการประยุกต์ใช้งานเทคนิค DevOps ก็จะลดหน่วยงานในส่วนผู้ดูแลระบบ ตามด้านล่าง

ถัดมาถ้าใช้ทั้ง Agile และ DevOps ก็จะลดหน่วยงานในส่วนอื่นๆ ได้มากขึ้นตามด้านล่าง

เอาหล่ะ มาถึงส่วนสำคัญแล้ว

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

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

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

จะดีใหม ถ้าไม่ต้องมีหน่วยงานวางแผน ไม่ต้องทั้งออกแบบเชิงสถาปัตยกรรม และวิศวกรรม ?

จากปัญหาดังกล่าว ทำไงดีหว่า ลองคิดตาม นะครับ

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

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

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

เป็นเครื่องมือที่ไม่ต้องอาศัยคนที่มีประสบการณ์สูงมากออกแบบ และเลือกใช้แพลตฟอร์ม หรือเฟรมเวิร์กในการพัฒนาแอพพลิเคชัน ใครๆก็พัฒนาได้

เป็นเครื่องมือที่ไม่ต้องการคนเยอะ ไม่ต้องการกระบวนการที่ซับซ้อน และไม่ต้องการทีมจำนวนมากๆ ขอแค่หนึ่งคน จบในคนเดียว

หากมีเครื่องมือดังที่กล่าวมา ก็จะได้ว่า Agile ก็ไม่จำเป็น, DevOps ก็ไม่จำเป็น, Enterprise Architect (EA) ก็ไม่จำเป็น, Solution Architect ก็ไม่จำเป็น, IT ก็ไม่จำเป็น ขอเพียงคนหนึ่งคนที่มีความรู้อยู่ระหว่างไอทีและผู้ใช้งาน ไม่ต้องเก่งมากก็พัฒนาแอพพลิเคชันได้

ดังนั้น กระบวนการในอนาคตจะเป็นดังรูปด้านล่าง

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

เอาหล่ะ ได้เวลาเลือกแล้วครับ www.dinoq.com

ดูบทความอื่นๆ กดลิ้งค์เลยครับ