Tanasanee Phienthrakul

Tanasanee Phienthrakul

E-mail: This e-mail address is being protected from spambots. You need JavaScript enabled to view it

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

ขอขอบคุณ อ.สุรเดช จิตประไพศาลกุล สำหรับตัวอย่างดีๆ ที่ทำให้ตั้งใจว่าจะเล่าทุกอย่างที่ต้องการเมื่อคิดจะมีบ้านสักหลัง...

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

 

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

 

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

 

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

 

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

 

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

 

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

--------------------------------------------------
1Watts S. Humphrey, “PSP: A Self-Improvement Process for Software Engineering,” Addison Wesley, NJ, 2005

Memmber Login

Login

Blog Calendar

« April 2014 »
Mon Tue Wed Thu Fri Sat Sun
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
| + - | RTL - LTR