Posted by: siamnobita | 09/12/2009

ว่าด้วยเรื่องของ Program Specification

ขอพักแนว technical ว่าด้วยเรื่อง performance tuning มาคุย(บ่น) เรื่องงานเอกสารเพื่อประกอบกระบวนการ Software Development Life Cycle ที่มักเรียกกันสั้น ๆ ว่า Program Spec. นี้สักหน่อย

เรื่องของเรื่องมีอยู่ว่า ที่บริษัททำการทบทวนเอกสารที่จำเป็นต่อการพัฒนาระบบงานครั้งใหญ่ มีการประชุมซึ่งผมดันต้องมาเป็นหนึ่งในสมาชิกที่เข้าประชุมด้วย ผมเอง ขอสารภาพว่า เป็นคนที่ขี้เกียจทำงานเอกสารอย่างมากมาย จึงเสนอให้ยกเลิกเจ้า Program Spec. ตัวนี้เสียที เพราะไม่เคยสร้างประโยชน์ที่แท้จริงอะไรเลย (ยกเว้นอาจเพิ่ม man-days เพื่อนำไปเรียกเก็บเงินจากลูกค้าได้) ผลก็คือผมเป็นเสียงเดียวที่เห็นด้วยกับข้อเสนอนี้ (ฮา) ดังนั้น โดยหลักประชาธิปไตยที่ไม่ฟังเหตุผลของเสียงข้างน้อย ผมก็ต้องก้มหน้าก้มตาทำเอกสารไร้ค่าชิ้นนี้ต่อไป

เหตุผลของเสียงข้างมาก คือ เอกสารชิ้นนี้มีความจำเป็น เพื่อใช้ในการติดต่อสื่อสารกันระหว่าง System Analyst (SA) หรือคนออกแบบโปรแกรม กับ Programmer (PG) หรือคนเขียนโปรแกรม เมื่อมีปัญหาในตัวโปรแกรมที่เขียนขึ้น ทั้งสองฝ่ายจะได้ไม่ต้องเถียงกัน ยึดตัว program spec นี้เป็นหลัก และอีกเหตุผลสำคัญก็คือ บริษัทไหน ๆ เขาก็เขียนกันทั้งนั้น โดยเฉพาะบริษัทฝรั่งใหญ่ ๆ โต ๆ ทั้งหลาย เรียกว่า ต้องมีไม่งั้นไม่ professional ว่างั้นเหอะ

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

จากประสบการณ์ของผม โปรเจ็คต์ที่จบได้สวย ๆ ไม่ว่าจะมี program spec หรือไม่ ก็ไม่มีข้อขัดแย้งระหว่าง SA กับ PG ขณะเดียวกัน โปรเจ็คต์ที่จบได้ห่วยหรือไม่มีทางจบแน่นอน ก็มักจะเกิดข้อขัดแย้งระหว่าง SA กับ PG ขึ้นแล้วสุดท้ายก็มาลงที่ Program Spec ว่า SA ไม่ยอมทำ หรือทำไม่ดี เขียนไม่ละเอียด (โอ้ พระเจ้า จะเอาละเอียดขนาดนั้น ตูเขียนโปรแกรมให้เองเลยดีกว่ามั้ง)

ประเด็นของผมก็คือ ข้อขัดแย้งระหว่าง SA กับ PG มีความสัมพันธ์โดยตรงกับความสำเร็จล้มเหลวของโปรเจ็คต์ เห็นได้ชัดเจน (แต่ประมาณ ไก่เกิดก่อนไข่ หรือไข่เกิดก่อนไก่ บอกไม่ได้ว่าอะไรเกิดก่อน) แต่ program spec ไม่ได้เกี่ยวอะไรด้วย เธอเป็นเพียงแพะที่น่าสงสารเท่านั้น

หาก SA กับ PG สามารถสื่อสารกันด้วยความเข้าใจ และมีพื้นฐานอยู่บนความเชื่อใจและวางใจซึ่งกันและกัน ข้อขัดแย้งย่อมไม่เกิดขึ้น ผมมี keyword อยู่สองคำ คือความเข้าใจ และความเชื่อใจ หากคนสองคนคุยกันภาษาเดียวกัน (สื่อสารสองทาง) แต่ยังไม่เข้าใจกัน แล้วคิดว่า คนหนึ่งไม่พูดไม่จา เขียนหนังสือส่งให้อีกคนอ่าน (สื่อสารทางเดียว) คนอ่านเค้าจะอ่านเข้าใจหรือครับ program spec ไม่ช่วยเรื่องความเข้าใจแน่นอน จริงอยู่ที่ว่าบางครั้งคำพูดอาจไม่เพียงพอสำหรับการสื่อสาร ต้องอาศัยภาษามือ ภาพประกอบช่วย แต่ไม่ได้หมายความว่านั่นต้องเป็นprogram spec เขียนขึ้นกระดานก็ได้ ชี้ ๆ เอาบน prototype ก็ได้

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

มีอีกเรื่องที่ผมอยากเอามาวิเคราะห์ คือความละเอียดของ Program Spec หลาย ๆ ครั้งเมื่อปัญหาเกิดขึ้น ความละเอียดของ Program Spec ถูก request ถึงขั้นต้องเอา code บางส่วนมาใส่ไว้ให้เลย PG จะได้ copy ไปแปะ โปรแกรมจะได้ทำงานได้ตามที่ SA ต้องการ ให้เขียนสดแค่บางส่วนซึ่งทดสอบไม่ได้ แล้วหวังจะให้ code นั้นไม่มี bug ผมว่าคนที่พูดแบบนี้ ไม่เคยเขียนโปรแกรมครับ code ที่ปลอด bug ต้องผ่านการทดสอบบนข้อมูลเสมือนจริงจนครบทุกกรณีที่เป็นไปได้ สุดยอด SA ขนาดไหน ก็ไม่ไหวหรอกครับ สุดท้าย PG ก็ต้องนำ code นั้นไปปรับปรุงแก้ไขให้ถูกต้องอีกครั้งอยู่ดี แล้วอะไรจะเกิดขึ้นครับ มีทั้ง code ที่ใช้งานจริง กับ code ที่อยู่ใน spec แบบนี้ เขาเรียก denormalize นะครับ เกิด update anomalies แน่นอน แถมไม่มีประโยชน์ในแง่ query performance ด้วย ทำไปทำไมครับ

เพิ่งนึกได้ เค้าบอกผมอีกด้วยว่า Program Spec มีประโยชน์อีกในแง่เวลาต้องกลับมาแก้ไขโปรแกรม โดยคนอื่นที่ไม่ได้เป็นคนเขียน จะได้เข้าใจการทำงานของโปรแกรม เอ่อ แน่ใจหรือครับ เอ่อ แล้วพอแก้ไขโปรแกรมเสร็จ พี่แก้ไขใน spec ด้วยหรือเปล่าครับ แล้วคนที่มาแก้ไขเป็นคนที่สาม เขาจะรู้หรือครับว่าพี่แก้ไขอะไรไป นี่ก็ denormalize เหมือนกันครับ คำอธิบายการทำงานของโปรแกรม ควรจะอยู่ในตัวโปรแกรมเอง ไม่ว่าจะโดยการ comment หรือ refactoring ก็ว่ากันไป แก้เสร็จปุ๊บ ก็ใส่ comment ไปเลย ว่าใครแก้ แก้เมื่อไหร่ แก้ทำไม โปรแกรมที่ไม่มี comment ต่อให้มี program spec ก็ไม่มีประโยชน์หรอกครับ ยังไงก็ต้องนั่งไล่ logic ของคนเขียนคนแรกอยู่ดี ว่าเขาคิดอะไรอยู่ตอนเขียน

สุดท้ายก่อนจบ blog นี้ ผมเสนอให้ใช้เป็น job assignment แทน program spec ครับ เอาไว้กรณี PG หรือ SA ขี้ลืม จะได้ติดตามงานกันได้ รายละเอียดงานก็ใส่เท่าที่จำเป็น ทำเสร็จก็ปิด job ถ้าต้องมีการแก้ไขโปรแกรมตัวเดิมอีกครั้ง ก็ออก job ใหม่ ไม่ต้องไป refer ตัวเก่า ปิดแล้วก็ปิดเลย ไม่ต้องตามไป update ให้เสียเวลา แต่ผมคงต้องรอจนกว่าจะมีบริษัทเป็นของตัวเองมั้ง กว่าจะได้ใช้ concept นี้ ในการทำงานจริง เฮ้อออออออ ยาว ๆ สักที


Responses

  1. กำลังงง ๆ กับเรื่องนี้อยู่เลยครับ ระบบเล็กก็ต้องทำด้วย เซ็ง


ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 / เปลี่ยนแปลง )

Google+ photo

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

Connecting to %s

หมวดหมู่

%d bloggers like this: