จัดระเบียบการทำงานกันดีไหม

จากประสบการณ์ทำงานกับ Agency และ กับบริษัททั้งหลาย ที่ผมได้ร่วมงานมา ประสบการณ์ดีดี และ ปัญหาที่ผมได้พบนั้นก็มี case ต่าง ๆ มากมายหลายสิ่งอยู่ (หลายสิ่งอยู่ = สำเนียงแถวบ้านผมน่ะ ความหมายประมาณ “หลายสิ่งเหมือนกัน” ตามภาษาภาคกลาง) ผมอยากจะยกสิ่งที่ผมเคยร่ำเรียนมา หรือ concept ที่ผมพอจำได้เลือนลาง หรือ อาจเสริมลงไปบ้างเล็ก ๆ น้อย ๆ มาเป็นตัวอย่างในการคิด การลำดับการทำงานให้มีประสิทธิภาพ อาจจะเป็นประโยชน์ หรือ ไม่เป็นประโยชน์ ก็ต้องขอขอบคุณ และ ขออภัยไว้ล่วงหน้า และ ก็อยากให้เพื่อน ๆ พี่ ๆ น้อง ๆ หรือ ผู้ที่เป็นมิตรรักแฟนเพลง ThaiCSS แสดงความคิดเห็นกันให้หูดับตับแลบ กันที่บทความนี้ ถือเสียว่าเป็น การฉลอง section ใหม่ ที่ผมขอพรเปิดขึ้นมาละกัน

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

เคยบ้างไหมที่ต้องทำงานมากมายกับ requirement ที่ส่งมาเรื่อย ๆ ไม่มีวันหมด เคยบ้างไหมที่ไม่รู้ว่าจะเอาอะไรไปถามเพื่อจำกัดขอบเขตงานของลูกค้า ในการเข้าไปเสนองาน หรือ เมื่อมีข้อแก้ไข หรือ เพิ่มเติมจากสิ่งที่คุยกันไว้ในครั้งแรก ผมเชื่อว่าทุกคนคงคุ้นเคยดี (หรือว่าผมคุ้นเคยคนเดียวฟะ) ทุกวันนี้คำกล่าวที่ว่า “everyone can crafted the site” นั้นคงจะใช้ไม่ได้อีกแล้ว ซึ่งคงอีกไม่นานในบ้านเราคงจะเกิดความเปลี่ยนแปลงครั้งใหญ่ในแวดวงการทำงานของพวกเรา ซึ่งน่าจะเป็นการเปลี่ยนแปลงไปในทางที่ดีขึ้น ได้ยกระดับการทำงานของทุกคนอีกระดับหนึ่ง เนื่องจากหลาย ๆ หน่วยงานเริ่มที่จะให้ความสำคัญกับ Web Standards กันมากขึ้นกว่าเดิมแล้วนั่นเป็นสัญญาณ และ การทำ Flow งานที่ดีก็จะเป็นประโยชน์อย่างหนึ่งทั้งกับการทำ Website ด้วย Web Standards หรือ ไม่เกี่ยวข้องอะไรกับ Web Standards เลยก็ตาม

Step 1: เริ่มต้นด้วยการกำหนดกรอบขอบเขต และ จุดหมายปลายทางของงาน

เราจะทำงานโดยไม่มีจุดหมายปลายทางไม่ได้ เพราะถ้าเราสรุปจุดหมายปลายทางไม่ได้ นั่นหมายถึงเราจะเดินไปเรื่อย ๆ ไม่มีวันจบ ไม่รู้ว่าจะทำอะไร ความสับสนก็จะเริ่มทวีคูณ ซึ่งต่างจากการเดินไปเรื่อย ๆ โดยมีจุดหมายเป็นลำดับ ๆ ไป เมื่อเรามีที่ไป หรือ check point ต่าง ๆ ระหว่างการเดินทางแล้ว เราจะรู้ และ กำหนดลำดับตัวเองได้ว่าควรจะทำอะไรก่อน – หลัง หรือว่า ใน check point/จุดหมายปลายทาง ต่อไป เราจะต้องเตรียมอะไรเพื่อรับมือ ซึ่งหมายถึงการ จัด scope งานให้เห็นกรอบขอบเขตที่แน่ชัด จัดลำดับช่วง และ เวลาให้เหมาะสม ควรจะเก็บ requirement ให้ละเอียดเท่าที่จะทำได้ เป็นไปได้การเจรจาเก็บรายละเอียด requirement ของลูกค้าควรพยายามไม่ให้เกิน 3 ครั้ง ไม่เช่นนั้นจะบานปลาย (เพราะจะเป็นการบีบให้ทั้งสองฝ่าย ต่างกำหนดรายละเอียดความต้องการ และ ขอบเขตข้อจำกัดของงานได้เร็วขึ้น) เช่นเดียวกัน ก่อนที่เราจะเป็นลูกค้าใครเราก็ต้องเขียน requirement ของเราให้แน่ชัดเหมือนกัน ว่าเราต้องการอะไร เนื้อทั้งหมดมีอะไรบ้าง อยากจะนำเสนออะไร เพื่อให้เหล่า Freelance Designer/Agency นั้นเอาสิ่งที่เราต้องการนำเสนอนั้นไปทำให้เป็นรูปเป็นร่างได้ตามที่เราต้องการ ผมจะยกตัวอย่างให้เห็นพอเป็นรูปร่าง

Freelance Designer/Agency

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

• จำนวน หน้าหลัก ๆ (เพราะจะได้จำนวนเทมเพลท หลัก ๆ ที่ต้องทำ)
• ขนาดตัวหนังสือ สีตัวหนังสือที่ต้องใช้ Link และ หรือ ตัวบ่งจำเพาะต่าง ๆ
• ระยะห่างระหว่างบรรทัด ระยะห่างระหว่างตัวอักษร (สำคัญนะกับเวปญี่ปุ่น)
• Theme ของเวป
• มีอะไรที่ลูกค้าอยากได้เป็นพิเศษหรือไม่ ถ้ามีเราทำได้หรือไม่ ถ้าทำไม่ได้จะแก้ไขอย่างไร
• อื่น ๆ ตามความเหมาะสม

ควรบันทึกมาโดยละเอียด เพื่อการเขียน flow ของงาน

ลูกค้า (Client)

สรุปให้ได้ว่า สิ่งที่เราต้องทำอะไรบ้าง จะนำเสนออะไรบ้าง อะไรที่อยากให้ Freelance Designer/Agency ให้คำแนะนำคุณ เช่น

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

ควรบันทึกสิ่งที่คุณได้ตกลง หรือ ได้คำแนะนำไว้ เพื่อตรวจตราการเขียน Flow ของ site ในครั้งต่อไป หรือ ถ้าเขียน Flow ได้เองเลยยิ่งดีใหญ่ เพราะจะประหยัดเวลากันไปได้เยอะเลยครับ

เมื่อเริ่มการสนทนาครั้งที่สอง Freelance Designer/Agency ก็ควรจะนำ requirement ที่ได้ขอนั้นไปเขียน flow ของ site คร่าว ๆ ได้แล้ว และ ต้องสมารถที่จะรู้จุดประสงค์จุดหมายปลายทางที่เราจะเดินไปได้แล้ว และ นำมาให้ลูกค้าได้ดูว่า ตรงตามความต้องการของเขาหรือไม่ จากนั้น ลูกค้าตรวจตรา site flow นั้น ๆ ว่าตรงตามความต้องการไหม ขาดเหลืออะไรให้บอก หรือ สมบูรณ์เราก็จะได้ว่า schedule ต่อกันเลย

ในกรณีที่ยังไม่สมบูรณ์ ให้คุยให้เรียบร้อยอยากให้ลด อยากให้เพิ่มเติมอะไร ขาดตกอะไรหรือไม่ แล้วแก้ให้ตรวจในครั้งต่อไปเพื่อที่จะจัด schedule กันต่อ และ เริ่มงาน นี่คือ case ที่ผมยกตัวอย่างนะครับ บางท่านการเก็บ requirement อาจจะมากกว่า 3 ครั้งก็ได้ แต่แก่นหลัก ๆ ของ Step แรกนี้คือ ต้องการ Site Flow ที่ถูกต้องสมบูรณ์ที่สุดก่อน เมื่อเราได้ Site Flow ที่สมบูรณ์แล้ว เราก็จะได้กรอบขอบเขต และ มองเห็นปลายทางที่เราจะเดินไปหาแล้วต่อไปเรามาจะมาปักหมุด check point กัน (กรณีที่เป็นงานเล็ก ๆ อาจจะไม่จำเป็นต้องกำหนด check point กัน)

Step 2 : กำหนดระยะเวลาการทำงาน และ จุดตรวจเชคงาน (Check Point)

เมื่อเราล้อมคอกเสร็จแล้ว (ได้ขอบเขตของงานแล้ว) เราก็ต้องเตรียมตัวเพาะเลี้ยงสิ่งที่เราต้องการจะให้เจริญงอกงามเพื่อเปิดร้านลาบ ก้อยต่อไป อ่ะนั่นนอกเรื่องไป เราก็ต้องเตรียมลงมือทำงาน เตรียมบรรจุเนื้อหากันได้แล้ว ในกรณีที่งานนั้นเป็นงาน Web Site ที่มีตั้งแต่ 2 ระดับขึ้นไป หรือ มีระบบ Application เข้ามาเกี่ยวข้อง สมควรที่จะต้องกำหนด Check Point ผมขอเรียกว่าระดับ ละกันนะครับ ซึ่งในที่นี้ผมหมายถึง จากหน้าแรกไปยังหน้าย่อยต่าง ๆ นั้น ต้องผ่านเข้าไปอีกกี่ระดับ เช่น ดังรูปตัวอย่างข้างล่างนี้

จากรูปคุณจะเห็นว่า ระดับของเวปมีสองระดับ และ จะมีต่อเติมเพิ่มเข้าไปอีกในส่วนของ Application ต่าง ๆ (ซึ่งต้องเขียนผังเพิ่มไปอีก ผมขอยกมาให้ดูเพียงเท่านี้ เพราะไม่เช่นนั้นภาพมันจะใหญ่เกินไป) จาก Flow ที่สมบูรณ์ที่ได้มา บวกกับ requirement ในส่วนย่อยต่าง ๆ ที่เหลือที่เราได้มาพร้อมกันนั้นเราก็จะมากำหนด scope งานกันต่อ (โดยอาจจะใช้ Gantt Chart เข้ามาช่วย แต่ของผมเป็น Guideline คร่าว ๆ นะครับ ขออนุญาติไม่ทำให้ดู) ตัวอย่างเช่น

• เราจะใช้เวลาในการ design demo กี่วัน
• ลูกค้าจะใช้เวลาตรวจกี่วัน
• การแก้ไขต่อ 1 check point ใช้เวลากี่วัน ให้กำหนดเผื่อ ๆ ไว้เลย (ให้เหมาะสมนะ)
• เวลาพัฒนา Application กี่วัน
• เวลาส่ง Site ที่เสร็จทั้งหมด ครั้งแรก
• เวลาตรวจ Site ทั้งหมดครั้งแรกกี่วัน (ตรวจ Bugs, ตรวจเนื้อหา หรือ อื่น ๆ ทั้งหมดว่าตรงกับ requirement หรือไม่)
• หลังจากตรวจ Site ที่เสร็จครั้งแรกแล้วต้อง ตรวจทานอีกกี่ครั้ง (คงไม่เกิน อีก 2 ครั้ง)
• ตรวจ Site ทั้งหมดที่แก้อีกครั้งเมื่อไหร่ ระยะเวลากี่วัน
• กำหนดเปิดตัวอย่างเป็นทางการ
• และ สุดท้ายกำหนดระยะเวลา maintenance ให้กำหนดเผื่อไว้จนกว่าระบบจะนิ่ง เพราะ bug บางอย่างต้องดูจากการใช้งานจริง

เมื่อคุณได้กำหนดระยะเวลาในการทำงานแล้ว ก็เริ่มลุยกันได้เลย

Step 3 : ลงมือทำงาน

ตรงนี้คงไม่ต้องอธิบายอะไรมากเพราะแนวทางการทำงานของแต่ละคนคงไม่เหมือนกันเป็นแน่แท้ เพียงแต่เราต้องทำออกมาให้เสร็จตาม Check Point ที่ให้ไว้เพราะเราทำ Schedule เอาไว้กับลูกค้าแล้ว

ตรงนี้ขอเสริมนิดนึงว่ามันเกี่ยวข้องกับ Web Standards อย่างไร ก็คือ เมื่อเราเก็บ requirement มาได้ดีเราก็จะทราบว่า content ที่มีนั้นมีอะไรบ้างเนื่องจากกลั่นกรองกันมาหมดแล้วใน Flow ซึ่งจะทำให้ง่ายต่อการจัดลำดับความสำคัญ, การใช้ design, การใช้ element ให้เหมาะสม

Step 4 : ตรวจเช็คงาน

ตรงนี้จะเป็นลูกค้า หรือ ตัว Freelance Designer/Agency เองก็ตกลงกัน หรือ จะช่วยกันก็ไม่เห็นเป็นไรจริงมั้ย ถ้ามี Check Point ก็ตรวจตาม Check Point ถ้าไม่มี(Job เล็ก ๆ) ก็ส่งทีเดียว แก้รวดเดียวไปเลยก็ได้ครับ ตรงนี้ต่างฝ่ายต่างต้องเตรียมกำหนด Process ในการตรวจงานของตนเองทั้งสองฝั่งเลย เช่น อาจจะตาม requirement ที่ได้มา, การทำงานของ Application สมบูรณ์แบบหรือไม่, ความสม่ำเสมอของแต่ละหน้า และ อื่น ๆ สุดแท้แต่จะตกลงกันไว้ หรือ ต่างฝ่ายต่างกำหนดขึ้นมาเอง

Step 5 : สู่การใช้งานจริง

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

Step 6 : สิ่งสุดท้าย กำหนดระยะเวลา ดูแลรักษา ปรับปรุงบ้าง

ไม่ควรมองข้ามในส่วนนี้ ควรกำหนดระยะเวลาสะสาง Website บ้าง (นี่เป็นส่วนของลูกค้านะ เจ้าของเวปน่ะ) คุณอาจจะทำได้เองโดยอ่านคู่มือที่ Freelance Designer/Agency ให้มา หรือ สอนมาก็ได้ เช่น เคลียร์ Database ที่ไม่จำเป็น หรือ ไม่ใช้แล้วบ้าง, ข้อมูลที่ไม่จำเป็นก็เอาออกไปบ้าง หรือ กำหนดระยะเวลา back up ข้อมูล ไม่ควรปล่อยปะละเลย ควรคำนึงถึงผู้ใช้ด้วย เพราะยิ่งเนื้อหาข้อมูลมีมากซับซ้อน ซ่อนเงื่อน เยอะแยะสืบค้นยาก มันจะทำให้ประสิทธิภาพของ Website ของคุณนั้นลดลง User เองก็จะเบื่อหน่าย หันไปใช้บริการของคู่แข่งก็เป็นไ้ด้นะครับ

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