เป็น guideline คร่าว ๆ เอาไว้ค่อยปรับปรุงให้ละเอียดและชัดเจนขึ้นอีกที เพราะมีคนถามผมเยอะว่าการทำงานระหว่างฝั่งเจ้าของงานกับฝั่งผู้พัฒนาระบบฯ ควรมี ‘อะไร’ บ้างนอกเหนือจากสิ่งที่ทั่ว ๆ ไปคุ้นเคยกัน เพื่อให้การทำงาน งาน และการว่าจ้างมีคุณภาพและประสิทธิภาพ โดยโมเมนตัมโฟกัสไปที่ด้าน development / programming และการจัดการ มากหน่อย ไม่ได้เน้นด้านออกแบบหรือสถาปัตยกรรมฯ นัก และไม่ได้อิงกับหลักการด้าน outsourcing / subcontract management อะไรครับ เอาจากประสบการณ์ล้วน ๆ โดยมานั่งคิดเล่น ๆ ว่าควรมีอะไรบ้างแล้วก็ลิสต์ออกมาครับ
ดังนั้นหากใครมีไอเดียอะไรเชิญเสนอเต็มที่เลยนะครับ ผิด-ถูกอย่างไรตรงไหนหรือมีอะไรเพิ่มจะได้ปรับและเสริม ๆ กันไปครับ 
หากการว่าจ้างพัฒนาระบบฯ สามารถมีครบ 20 ข้อนี้ก็…สุดยอดไปเลย 
แฮปปี้กันถ้วนหน้า
และขอแจ้งอีกนิดว่าผมเขียนบทความนี้โดยมีทัศนคติเอนเอียงเข้าข้าง ‘เจ้าของงาน’ มากกว่า ‘ผู้พัฒนาระบบฯ’ นะครับ ^_^ และระหว่างเขียนก็นึกถึงงานที่เจอบ่อย ๆ คือด้าน enterprise architecture / application ดังนั้นบางประเด็นอาจดูขาด ๆ ปริ่ม ๆ และ ล้น ๆ ได้
Standard And Guideline For Developer
1. Naming
มาตรฐานและแนวทางสำหรับการตั้งชื่อและระเบียบการตั้งชื่อ เช่น ชื่อคอลัมน์ ตาราง ตัวแปร เมธอด ฟังก์ชั่น คลาส อินเตอร์เฟส ไดเร็กทอรี่ แพ็กเกจ ฯลฯ ซึ่งรวมถึงชนิดตัวแปร นอกจากนี้ควรทำ mapping เช่น ระหว่างชื่อคอลัมน์กับชื่อแอททริบิวต์ เป็นต้น และควรมีเอกสารหรือเว็บเพจอธิบายตัวย่อ ศัพท์เฉพาะ แปลคำไทยเป็นอังกฤษ แปลคำอังกฤษเป็นไทย เป็นต้น
2. Business Logic Separation
มาตรฐานและแนวทางสำหรับการแยกเอกสาร, โค้ด, subsystem, คอมโพเน้นต์ ฯ ในส่วน business logic ให้เป็นอิสระจากซอฟต์แวร์และสภาพแวดล้อมของซอฟต์แวร์ให้มากที่สุด และควรเป็นอิสระจากสภาพแวดล้อมอื่น เช่น ของแอพพลิเคชั่น ทรานแซกชั่นเซิร์ฟเวอร์ และควรแยกส่วนอิมพลีเม้นต์ด้าน business logic ให้เป็นอิสระหรือให้อยู่คนละที่กับอินเตอร์เฟส
3. Business Logic Connection
มาตรฐานและแนวทางสำหรับการออกแบบและเขียนโค้ดเชื่อมต่อเพื่อเรียกใช้ส่วน business logic ซึ่งควรมีมาตรฐาน มีคุณภาพ และมีประสิทธิภาพ ควรทำเอกสารเช่น API ให้ละเอียด อธิบายอินเตอร์เฟสให้ละเอียด ไม่ควรให้ทีมที่ทำส่วนการเรียกใช้ business logic ได้เข้าถึงสิ่งต่าง ๆ ที่เกี่ยวข้องกับ business logic โดยตรง (เช่น ส่วนอิมพลีเม้นต์ เอกสาร เป็นต้น) เด็ดขาด ควรติดต่อผ่านอินเตอร์เฟสเท่านั้น หรือควรมีการกำหนด policy ทั้งในระดับโค้ด ส่วนออกแบบ ระเบียบปฏิบัติ
จุด ‘joint’ ส่วนนี้สำคัญมาก ควรมีการมอนิเตอร์ อาจด้วยการทำ logging หรือ testing ให้ละเอียด เพื่อตรวจด้าน security, performance, reliability เป็นต้น
4. Web Process
มาตรฐานและแนวทางการแบ่งกลุ่ม (partition) เว็บแอพพลิเคชั่นให้เป็นระเบียบ เช่น แบ่งเป็นเว็บย่อย เป็นโมดูล เป็นต้น แล้วกำหนด ‘Web Application Flow’ ให้เป็นระเบียบเป็นมาตรฐาน เช่น อาจใช้แพทเทิร์น เช่น MVC (Model View and Controller) หรือหากใช้เฟรมเวิร์กใดก็ควรให้ส่วนการประมวผลต่าง ๆ มีมาตรฐานเหมือนกัน ตรวจจับว่ามีโปรแกรมเมอร์คนใดเขียนโปรแกรมไม่ตรงตามมาตรฐานหรือไม่ตรงตาม architecture หรือไม่ เพราะ Web Process มีผลต่อ security, testing, performance, reliability, modifiability ซึ่งหาก flow ของงานในส่วนต่าง ๆ ของเว็บมีมาตรฐานจะช่วยลด bug ได้มาก ทำให้ test สะดวกและ modify ได้ง่าย
5. Transaction Management
มาตรฐานและแนวทางสำหรับการจัดการทรานแซกชั่น โดยคำนึงถึง performance, reliability, modifiability และ availability เป็นสำคัญ ห้ามมักง่ายด้วยการเลือกวิธีที่เขียนโปรแกรมง่ายเข้าว่า การออกแบบและเขียนโปรแกรมด้านนี้ยากมาก จำเป็นต้องระบุ domain expert ที่มีความรู้และเข้าใจอย่างแท้จริงคอยช่วยให้คำแนะนำ และต้อง test ส่วนนี้ให้ละเอียด ซึ่งควรลงไปเปิดโค้ดเพื่อดูคุณภาพการเขียนโค้ดส่วนนี้ด้วย
6. Transaction Monitoring and Tracking
มาตรฐานและแนวทางสำหรับการทำ debug, log และกำหนดวิธีมาตฐานในการมอนิเตอร์และติดตามทรานแซกชั่น สำหรับระบบฯ ขนาดใหญ่ในส่วนนี้อาจทำได้ยากมาก อาจจำเป็นต้องใช้ tool ซึ่งมักมีราคาแพงมาก กลไกด้านนี้มีความสำคัญและจำเป็นมาก เพราะหากมองไม่เห็นว่าภายในเป็นอย่างไรก็ไม่สามารถทราบได้อย่างแท้จริงว่าระบบฯ นั้นแท้จริงทำอย่างไร การทำ performance test เป็นเพียงการตรวจอาการของโรคเท่านั้น ซึ่งเป็นวิธีปลายทาง
7. Authentication & Authorization
มาตรฐานและแนวทางที่ควรคำนึงถึง security, performance, modifiability และ scalability ไม่ใช่เลือกใช้วิธีที่เขียนโปรแกรมง่ายเข้าว่า และควรใช้ฟีจเจอร์ของ middleware (หากมี) ให้เต็มที่ แต่ก็ต้องคำนึงถึงด้าน vendor dependent ด้วยเช่นกัน นอกจากนี้ต้องออกแบบและเขียนโปรแกรมโดยคำนึงถึงด้านอื่น ๆ ด้วย เช่น security propagation, single sign on (ใช้วิธีที่เป็นมาตรฐาน มีประสิทธิภาพ โดยไม่ใช่เลือกใช้วิธีที่เขียนโปรแกรมง่ายเข้าว่า), data confidentiality (เช่นรหัสผ่าน)
8. Database Access (Persistence Mechanism)
มาตรฐานและแนวทางด้านการเชื่อมต่อกับระบบฐานข้อมูล เช่น ส่วน ฮาร์ดแวร์, connection pool, database driver, database user, database connection, thread / synchronization / concurrency control, security propagation, transaction context propagation, database manipulation (insert, update, delete, select), database definition (เช่น การสร้างตาราง คีย์ อินเด็กซ์ เป็นต้น) เป็นต้น และหากมีใช้ ORM พวกไฟล์คอนฟิกุเรชั่น เช่น XML ต้องจัดเก็บให้เป็นระเบียบ ออกแบบและเขียนโปรแกรมโดยคำนึงหลัก Object-Orientation ให้มาก ๆ แต่ต้องให้สัมพันธ์กับทรัพยากร สภาพแวดล้อม และการจัดการอื่น ๆ ประกอบ เช่น transaction management, data security เป็นต้น
9. Data Design
มาตรฐานและแนวทางด้านการออกแบบโครงสร้างข้อมูลทั้งด้าน Object Data Model และ Entity Relationship Model (ER Diagram) และด้าน Object-to-Relational Mapping (OR Mapping / ORM) ในส่วนนี้ควรมีเอกสารและคอมเม้นต์อธิบายให้ละเอียด ห้ามพึ่งพา tool ช่วยการ generate มากจนเกินไป ควร customize ด้วยมืออีกทีและเขียนคอมเม้นต์และทำเอกสารให้ละเอียด ห้ามเลือกใช้วิธีที่เขียนโปรแกรมง่ายเข้าว่า ให้คำนึงถึงด้าน performance, reliability และ modifiability เป็นสำคัญ หากมีใช้ ORM พวกไฟล์คอนฟิกุเรชั่น เช่น XML ต้องจัดเก็บให้เป็นระเบียบ ออกแบบและเขียนโปรแกรมโดยคำนึงหลัก Object-Orientation ให้มาก ๆ แต่ต้องให้สัมพันธ์กับทรัพยากร สภาพแวดล้อม และการจัดการอื่น ๆ ประกอบ เช่น transaction management, data security เป็นต้น
10. Data Transfer Object (DTO) and Data Granularity
มาตรานและแนวทางสำหรับข้อมูลที่จะรับส่งกันระหว่าง เลเยอร์, tier, subsystem, คอมโพเน้นต์, แอพพลิเคชั่น, เซอร์วิส, thread ฯลฯ ว่าจะใช้ชนิดข้อมูลใด และมีระดับของขนาด (data granularity) เท่าใด ซึ่งรวมถึงจำนวนพารามิเตอร์และชนิดข้อมูลด้วย เช่น จะใช้ชนิดข้อมูลหรือโครงสร้างข้อมูลที่มีอยู่แล้วในภาษาโปรแกรมนั้น ๆ หากใช้จะใช้ชนิดใด ด้วยเหตุผลอะไร หรือจะสร้างชนิดข้อมูลขึ้นมาใหม่ หรือสร้างอินเตอร์เฟสหรือคลาสใหม่ จะให้ผู้รับสามารถ modify / alter ข้อมูลได้ด้วยหรือไม่หรือจะเซ็ตให้เป็น read-only object นอกจากนี้ต้องคำนึงถึงด้าน object serialization / de-serialization, object state, communication channel และช่องทางในการรับส่งด้วย ซึ่งทั้งหมดนี้ต้องสัมพันธ์กับพฤติกรรมของซอฟต์แวร์ และหรือพฤติกรรมการใช้งานของผู้ใช้ หรือไคลเอ็นต์ด้วย (ไคลเอ็นต์ไม่จำเป็นต้องเป็นคน)
11. Web Service
มาตรฐานและแนวทางทั้งเอกสาร โค้ด XML และคอมเม้นต์ ซึ่งต้องระวังหากใช้ tool ในการ generate เพราะควรปรับแต่งอีกครั้งด้วยมือ ควรมีมาตรฐานทั้งการตั้งชื่อ ชนิดข้อมูล จำนวนข้อมูล ลักษณะข้อมูล ขนาดข้อมูล ความปลอดภัย SLA ฯลฯ และควรมี template สำหรับการเขียนโค้ดทั้งส่วนบริการและส่วนเรียกใช้บริการ เพื่อให้โปรแกรมเมอร์ทุกคนเขียนโปรแกรมมีมาตรฐานเหมือนกัน
12. Messaging Service or Asynchronous Call
มาตรฐานและแนวทางส่วนคอมโพเน้นต์ที่ถูกเรียกใช้แบบ asynchronous call และส่วนที่จะเรียกใช้คอมโพเน้นต์ผ่าน asynchronous call และควรกำหนดมาตรฐานและแนวทางทั้งด้านชื่อ (เช่น topic, queue) การ lookup คอมโพเน้นต์ SLA ชนิด message ชนิดข้อมูล ฯลฯ และควรระบุด้วยว่าเลือกใช้วิธี native call (เช่นใช้ proprietary library และ ภาษาโปรแกรม) หรือใช้วิธีกลาง ๆ (เช่นใช้ JMS: Java Messaging Service แบบที่มักใช้ใน Java)
13. Session and Cache Management
มาตรฐานและแนวทางด้าน session และ cache เช่น การตั้งชื่อ การจัดการ ขนาดหน่วยความจำ ชนิดข้อมูลที่จัดเก็บ expire time idletime start time ฯลฯ ซึ่งรวมถึงการจัดการ session และ cache ให้สอดคล้องกันในแต่ละส่วน เช่นในระดับเว็บเซิร์ฟเวอร์ แอพพลิเคชั่นเซิร์ฟเวอร์ ทรานแซกชั่นเซิร์ฟเวอร์ ดาต้าเบสเซิร์ฟเวอร์ เป็นต้น และยังรวมถึงมาตรฐานการเขียนโปรแกรมในส่วนการสร้าง เรียกใช้ และลบ session และ cache ด้วย เพราะส่งผลต่อคุณภาพด้าน reliability, availability, modifiability, performance, scalability มาก
14. Testing
มาตรฐานและแนวทางสำหรับการ test ตั้งแต่การเขียน test case / script, test unit, UAT จนถึงระเบียบขั้นตอนการ test ซึ่งควรลงไปจนถึงระดับโปรแกรมเมอร์ว่าควร test อย่างไร test อะไรบ้างและแค่ไหน กำหนดขอบเขตและแบ่งเป็นสัดส่วนให้ชัดเจน กำหนดบทบาทหน้าที่และ map กับคนให้เรียบร้อย สำหรับการ test ควร test ให้ครอบคลุม ไม่ควรทำแค่ functional test เพียงอย่างเดียว เพราะจะทำให้ไม่สามารถเห็นการทำงานภายในซอฟต์แวร์ได้เลย ดังนั้นจึงควร test ในมิติอื่นด้วย เช่น reliability test, performance test ส่วนเทคนิคการ test นั้นมีมากมายเป็นสิบ ๆ ซึ่งเป็นหน้าที่ของ tester, test manager, test engineer แต่โปรแกรมเมอร์ก็ควรมีส่วนร่วมในการ test ด้วยเช่นกันโดยทำหน้าที่ในส่วน unit test ซึ่งโปรแกรมเมอร์ควรเขียน unit test ด้วยตัวเอง และต้องระบุด้วยว่า unit test นั้นสัมพันธ์กับโค้ดส่วนไหนบ้าง และสัมพันธ์กับ requirements ใด (เพื่อให้สามารถทำ requirements traceability, defect management, risk management, change management, impact analysis ได้) ดังนั้นในการทำงานหากให้ดีควรมีโอกาสได้พบเจอโปรแกรมเมอร์ผู้เขียนโค้ดจริง ๆ ด้วย จะได้พูดคุย สอบถาม จับผิด ตรวจสอบกันได้ และหลอกถามให้ละเอียดว่าการ test จริง ๆ ในทีมทำกันอย่างไร (ถ้าเป็นไปได้) Software Testing ถือเป็นศาสตร์ที่ยากมากต้องมีความเข้าใจสูง มีความละเอียดและใส่ใจสูง ซึ่ง best practice คือ จะทำอย่างไรที่จะทดสอบด้านสถาปัตยกรรมฯ (Architectural Test) ให้ได้ เพราะ architectural test นั้นเป็นการเจาะเข้าไป test ถึงภายในตัวซอฟต์แวร์กันจริง ๆ เป็นการ test คุณภาพการทำงานของกลไกฯ (architectural mechanism) ต่าง ๆ กันจริง ๆ ไม่ใช่ test แค่เปลือกอย่าง functional test หรือ UAT ที่มักทำ ๆ กันเท่านั้น ซึ่งรวมถึงการทำ load test, stress test ที่มัก test ด้าน performance เป็นหลักเท่านั้น การ test จำเป็นต้องพึ่งทั้งความรู้ด้านทฤษฏีและเครื่องมือ ซึ่งเครื่องมือก็คือ tool ด้าน software testing การ test ที่ดีคือควร test ด้วยมือให้น้อยที่สุด เพื่อลดความผิดพลาดและความไม่เที่ยงตรง แต่ tool ด้าน testing มักมีราคาแพง ดังนั้นจึงควรเผื่องบประมาณด้านนี้ไว้ด้วย และบริษัทไอทีในบ้านเรามีน้อยรายที่ชำนาญด้าน software testing จริง ๆ (ที่มิใช่เก่งแต่ใช้ tool) ดังนั้นการให้ความสำคัญกับการพัฒนาบุคลากรด้านนี้จึงจำเป็นมาก
15. Service Level Agreement (SLA)
มาตรฐานและแนวทางการสร้างข้อตกลงในการให้บริการของบริษัทไอทีที่ถูกว่าจ้าง การกำหนด SLA ควรเข้มงวดและมีผู้เชี่ยวชาญด้านกฏหมายให้คำปรึกษา แต่ต้องมองถึงความเป็นจริงประกอบด้วย เช่น งบประมาณ ระยะเวลา ทีมงาน (ทั้งฝั่งผู้ว่าจ้างและผู้รับจ้าง) ทรัพยากร สภาพแวดล้อม เป็นต้น เพราะไม่ใช่ว่าจะมาเขียนให้ละเอียดและเข้มงวดมาก ๆ จนไม่ดูว่าโครงการมีงบประมาณน้อย หรือมีเวลาน้อยมาก เป็นต้น แต่ไม่ควรเขียนแบบขอไปทีหรือแค่พอให้มี แต่ไม่ได้มีการติดตามอย่างจริงจัง ถ้าอย่างนั้นไม่มีจะดีกว่า แต่ทุกการว่าจ้างควรมีการทำ SLA เสมอ แม้แต่การพัฒนาระบบฯ ใช้กันเองภายในบริษัทก็ควรทำ SLA ระหว่างฝ่ายเจ้าของระบบฯ กับฝ่ายไอทีที่พัฒนาระบบฯ ให้ นอกจากนี้ SLA ควรสอดคล้องกับสัญญาว่าจ้างและการให้บริการหลังการขาย / ติดตั้ง (maintainance) ซึ่งควรกำหนดระเบียบขั้นตอนปฏิบัติ (procedure) ให้ละเอียด เช่น กรณีเกิดเหตุการณ์ฉุกเฉินขึ้น ต้องทำอย่างไร อะไรบ้าง ใครบ้าง ติดต่อใคร ใครรับเรื่อง ใครแก้ไข กระทบส่วนใดบ้าง ค่าใช้จ่ายประเมินเบื้องต้นล่วงหน้าและที่หน้างานจริง เป็นต้น
16. Background and Business Process
มาตรฐานและแนวทางการอธิบายระบบงาน (business model) เบื้องต้น ซึ่งจะช่วยให้ทีมพัฒนาฯ มีความเข้าใจระบงานมากยิ่งขึ้น ดังนั้นหากทำได้ละเอียด เข้าใจง่าย ไม่ยาวจนเกินไป หรือมีการจัดอบรมก่อนเริ่มงานได้ยิ่งดี สำหรับ business model ประกอบด้วยรายละเอียดมากมาย เช่น business structure, business workers, business processes, business rules, business units, business goals เป็นต้น แต่ให้นึกง่าย ๆ ว่า business model ก็คล้ายกับตำราที่สอนให้เข้าใจระบบงานนั้น ๆ เช่น หนังสือระบบงานบัญชี (ไม่ใช่ระบบโปรแกรมบัญชี) หนังสืออธิบายระบบงานลอจิสติก เป็นต้น พบว่าปัญหาที่เกิดขึ้นบ่อยในแทบทุกโครงการการพัฒนาระบบฯ คือมี requirements change ทั้งเก่า-ใหม่เกิดขึ้นเรื่อย ๆ ตลอดโครงการ แม้แต่วันที่ใกล้จะส่งงานก็ยังอายมีได้ สาเหตุหลักหนึ่งคือมักไม่ได้ทำ business modeling อย่างละเอียดดีพอ และมักเริ่มต้นโครงการด้วยเฟส Requirements เพราะหากทีมงานยังไม่เข้าใจระบบงานดีพอ จะให้ไปเก็บ requirements ได้อย่างไร? ส่วนการแก้ตัวด้วยเหตุผลว่า “ก็ช่วงแรกของเฟส Requirements คือการเรียนรู้ระบบงานปัจจุบัน” การเรียนรู้ระบบงานมักถูกกระทำอย่างลวก ๆ และมักถูกกระทำโดยผู้ไม่มีวุฒิภาวะหรือเป็นพวกเทคนิคจัดมีความบกพร่องหรือไม่ชำนาญด้านการสื่อสารและด้าน business analysis เนื่องจาก business model มีรายละเอียดมาก ดังนั้นเฟสแรกของโครงการจึงควรเริ่มด้วยเฟส Business Modeling ก่อน ส่วนจะสั้นหรือยาวแค่ไหนก็ขึ้นกับงานนั้น ๆ นอกจากนี้ยังพบว่าการทำ business modeling ที่ไม่ดี หรือรวมถึงการไม่ทำเลยมักก่อให้เกิดปัญหาด้าน requirements change ระหว่างทำโครงการ ซึ่งอาจส่งผลกระทบต่อโครงสร้างโดยรวมหรือส่วนสำคัญต่าง ๆ ได้ เนื่องจากสาเหตุคือ การทำ business modeling ที่ดี ควรมีการทำ business process re-engineering ด้วยเสมอ นั่นคือสร้างการรับรู้ให้คนทำงานและผู้ใช้ก่อน แล้วปรับปรุงกระบวนการทำงานบางจุด เช่น จุดที่ต้องทำ business automation เพื่อที่พอพัฒนาระบบฯ มาแล้วจะได้สัมพันธ์กัน ไม่ใช่พัฒนาระบบฯ โดยอิงตามกระบวนการทำงานแบบเดิมทุกอย่าง พอผู้ใช้ลองใช้จริงก็จะพบปัญหาโน่นนี่จุกจิกตามมาเสมอ ดังนั้นจึงควรมีการกำหนดระเบียบมาตรฐานและแนวทางในการทำ business modeling อย่างละเอียด เพราะเมื่อทั้งฝั่งเจ้าของงานและฝั่งพัฒนาระบบฯ เข้าใจที่มาที่ไปและระบบงานอย่างละเอียด (หมายถึงมี domain knowledge เป็นไปในทิศทางเดียวกัน) ก็จะช่วยให้การทำงานสะดวก รวดเร็ว ถูกต้อง ลดข้อผิดพลาด ลด requirements change ลงได้มาก และสุดท้ายควรระบุคนที่จะเป็น business domain expert ด้วยเสมอ และสมมติฐานคือ ไม่มีใครเข้าใจระบบงานของเราดีไปกว่าเราเอง ดังนั้น business domain expert จึงควรเป็นคนของฝั่งเจ้าของงานนั่นแหละ ซึ่งนั่นคือ business modeling ต้องเป็นการร่วมมือทำด้วยกันทั้งสองฝั่ง ไม่ใช่ฝั่งเจ้าของงานทำแต่พูด ให้ข้อมูล และประสานงาน เท่านั้น แต่ต้องลงมาร่วมทำด้วย!
17. Coding, Documentation and Comment
มาตรฐานและแนวทางการเขียนโปรแกรม เอกสาร และคอมเม้นต์ โดยให้มองว่าเมื่อเห็นโค้ด เอกสาร และคอมเม้นต์แล้ว จะแทบไม่รู้เลยว่าใครเป็นคนเขียน เพราะเขียนมีมาตรฐานเหมือนกัน ทำให้ดูแลง่าย และพยายามอย่าให้ความสำคัญกับเอกสารมากจนเกินไป จงให้ความสำคัญกับมาตรฐานการเขียนโค้ดและคอมเม้นต์ให้มาก ๆ เช่น การตั้งชื่อ การเว้นวรรค การย่อหน้า การเขียนคอมเม้นต์แบบต่าง ๆ การเขียนลูป การเขียนเงื่อนไข การอธิบายอัลกอริธึม โค้ดทุกตัว (ทุกคลาส หรือทุกไฟล์) ควรระบุด้วยว่าใครเขียน สร้างเมื่อไร ปรับปรุงล่าสุดเมื่อไร โค้ดนี้ทำหน้าที่อะไร สัมพันธ์กับ requirement ใดบ้าง (เพื่อให้สามารถทำ requirements traceability, defect management, risk management, change management, impact analysis ได้) นอกจากนี้การใช้ซอฟต์แวร์ด้าน version control ไม่ได้ช่วยสิ่งต่าง ๆ ที่กล่าวได้ทั้งหมดเสมอไป เพราะสิ่งสำคัญคือวินัยและการตรวจสอบอย่างละเอียด โดยเฉพาะโค้ดเป็นสิ่งที่น่าห่วงอย่างยิ่ง ไม่ควรทดสอบแต่ระบบฯ เท่านั้น แต่ควรมีการทดสอบหรือการทำ code walk through ด้วย โดยสุ่มตรวจคุณภาพการเขียนโค้ดและคอมเม้นต์ด้วย ดังนั้นจึงควรมีแนวทางหรือ template ในการเขียนโค้ดส่วนต่าง ๆ ให้โปรแกรมเมอร์มาก ๆ เช่น template และแนวทางสำหรับการเขียนส่วน: get database connection, insert / update / delete / select data, exception handling, SQL (โดยเฉพาะคำสั่ง SELECTง), thread, call asynchronous component, call web service, call CORBA object, validate parameter, check user’s login, file I/O, event handling, transaction: begin / commit / rollback, pass by value, pass by reference, call back method, propagate transaction context, propagate security context / credential data, OR mapping, object locking, object life-cycle management (acquire and detach / release object), AJAX, JavaScript, loop, convert / format data ฯลฯ เพราะต้องตระหนักเสมอว่าอย่าคิดว่าโปรแกมเมอร์ทุกคนในทีมหรือที่จ้างเขียนโปรแกรมเหล่านี้ชำนาญและมีมาตรฐานด้านคุณภาพเหมือนกันหมด ดังนั้นหากมี template และแนวทาง หรือตัวอย่างให้จะช่วยให้โปรแกรมเมอร์เขียนโปรแกรมได้เร็วขึ้น มีมาตรฐาน และยังตรวจสอบคุณภาพ และ test ง่ายขึ้นด้วย
18. Exception or Error Handling
มาตรฐานและแนวทางการจัดการและการเขียนโปรแกรมด้าน exception ประเด็นนี้สำคัญมาก ซึ่งข้อผิดพลาดสำคัญคือไม่ควรให้โปรแกรมเมอร์คิดและออกแบบส่วนนี้เอง แต่ควรมี SA หรือ architect ออกแบบและกำหนดมาตรฐานและแนวทางการเขียนโปรแกรมจัดการให้ดู เช่น อาจเขียนเป็น template เพราะโค้ดด้านนี้มักเขียนโปรแกรมง่าย แต่การออกแบบเพื่อจัดการจริง ๆ นั้นไม่ง่าย เวลางานกระชั้นมักพบว่าโปรแกรมเมอร์มักเขียนโค้ดส่วนนี้แบบลวก ๆ หรือเขียนในลักษณะไม่รู้ลึกจริง ๆ หรือรู้เท่าไม่ถึงการณ์ หรือพึ่งพาเฟรมเวิร์กมากเกินไปจนจัดการผิดพลาดและ exception หรือ error อาจหลุดได้ ควรกำหนดรายละเอียด exception หรือ error เช่น error code, error name, user error message (ข้อความที่ผู้ใช้อ่านแล้วเข้าใจไม่ใช้ศัพท์เทคนิคมาก), system error message (ข้อความเทคนิคเพื่อการ debug และการจัดการ), contact support, help guideline เป็นต้น
19. User Manual, System Manual / Support
มาตรฐานและแนวทางสำหรับการทำเอกสารการใช้งานและการดูแลระบบ ให้คิดเสียว่าเหมือนกำลังเขียนตำราเพื่อจะจำหน่ายจริง ๆ ดังนั้นในเอกสารควรเนื้อหาอะไรบ้างเพื่อความสมบูรณ์ และยังประโยชน์ต่อผู้อ่านให้มากที่สุด เช่น คุณภาพด้านภาษา สำนวน สัดส่วนข้อความกับรูปภาพ คุณภาพของรูปภาพ เนื้อหา การอ้างอิง ความเข้าใจง่าย เนื้อหาครอบคลุม และที่สำคัญในแต่ละหน้าหรือหัวข้อควรสามารถระบุได้ว่าสอดคล้องกับ requirements ใด (เพื่อให้สามารถทำ requirements traceability, defect management, risk management, change management, impact analysis ได้)
20. Communication Between Company and Vendor / Outsourcer
มาตรฐานและแนวทางการสื่อสารภายในองค์กรและระหว่างองค์กร ควรกำหนดระเบียบให้ชัดเจน กำหนดโปรโตคอลและขั้นตอนรวมถึงบทบาทและ map กับคนให้เรียบร้อย กำหนด contact point ให้ชัดเจน เส้นทางการสื่อสาร (communication path) ควรมีหลายรูปแบบ เช่น แบบที่มีระเบียบเคร่งครัด แบบเร่งด่วน แบบเป็นทางการ แบบไม่เป็นทางการ เป็นต้น เพราะการสื่อสารแสดงถึงวัฒนธรรมองค์กรและการทำงาน และยังสามารถสะท้อนถึงการออกแบบสถาปัตยกรรมซอฟต์แวร์เลยทีเดียว ทักษะด้านการสื่อสารเช่น การพูด ฟัง เขียน บุคลิก สรุป จิตวิทยาการสื่อสาร ศิลปะการสื่อสาร การเข้าใจวัฒนธรรมหรือเรียนรู้และเข้าใจผู้ฟัง เป็นต้น ดังนั้นพยายามหลีกเลี่ยงการระบุ contact person หรือบุคคลที่จะให้ทำหน้าที่สื่อสารที่ขาดทักษะหรือบกพร่องด้านการสื่อสาร แม้ว่าบุคคลนั้นอาจมีตำแหน่งสูง มีบทบาทสำคัญในโครงการ มีความรู้ความเข้าใจในงาน เป็นโปรแกรมเมอร เป็นต้น และพยายามหลีกเลี่ยงบุคคลที่ไม่มีวุฒิภาวะหรือมีน้อยหรือพูดจากภาษาคนไม่ค่อยเป็น พูดเป็นแต่ศัพท์เทคนิค หรือพูดภาษาคนเป็นและเก่งแต่กลับไม่รู้เรื่องเทคนิคอะไรเลย ไปทำหน้าที่สื่อสาร พูดคุย เพราะจะทำให้สารบิดเบี้ยวจนสื่อและเข้าใจกันผิดพลาดบิดเบี้ยวไปด้วย ในการทำงานจึงควรกำหนดมาตรฐานและระเบียบการสื่อสารระหว่างภายในองค์กรกันเองและระหว่างองค์กรให้ดีเป็นที่เข้าใจกันทุกฝ่ายตั้งแต่เริ่มต้นโครงการ และต้องมีผู้ควบคุมติดตามด้วย เพราะการสื่อสารที่ดีจะช่วยให้งานสำเร็จลุล่วงได้ด้วยดีอย่างคาดไม่ถึง
ความเห็นล่าสุด