คู่มือ Developer Advocacy

เวอร์ชันล่าสุดของ “Developer Evangelist Handbook” ที่ Christian Heilmann เผยแพร่ครั้งแรกเมื่อ 15 ปีก่อน

• Developer Advocacy / Evangelism คืออะไร?

→ ให้นิยาม

→ แนวคิดที่ถูกต้อง: คนที่สร้างความเปลี่ยนแปลงให้กับนักพัฒนา

→ บทบาทและการใช้จุดแข็ง

• การทำงานร่วมกับบริษัทของตนเอง

→ เตรียมรับมือกับอคติ: เป็นบทบาทเฉพาะที่คร่อมหลายหน้าที่ อย่าท้อแท้

→ รับมือกับการเปลี่ยนแปลงในบริษัท: ปฏิบัติตามกระบวนการทางกฎหมาย ไม่มีคำว่า “off-the-record” อย่าตัดสินใจด้วยอารมณ์หรือคาดเดาเอง

→ อยู่เคียงข้างนักพัฒนาภายในองค์กร: จงรับฟัง

→ ทำงานร่วมกับ PR และการตลาด: ไม่ใช่คู่แข่งกัน ต้องสื่อสารกันอย่างต่อเนื่อง

→ การถูกมองว่าเป็นช่องทางภายนอก: บอกให้สมาชิกในทีมรู้ว่าคุณเชื่อมต่อกับช่องทางใดบ้าง

→ ฝึกสอน Advocate คนอื่นและนักพัฒนา: จัดการอบรมและบรรยายภายใน พร้อมแชร์ฟีดแบ็กจากภายนอก

→ แชร์เทคนิคที่มีประโยชน์: สื่อสารภายในเกี่ยวกับเทคนิคที่ได้เรียนรู้

→ สร้างสมดุลระหว่างช่องทางส่วนตัวกับช่องทางทางการ

→ ลดบทบาทของแบรนด์: แยกตัวเองออกจากแบรนด์บริษัท และโฟกัสแค่การทำให้นักพัฒนาสามารถลองเล่นกับผลิตภัณฑ์ได้

• การทำงานร่วมกับคู่แข่ง

→ เมื่อทำงานร่วมกับคู่แข่ง:

✓ เป็นคนที่สนใจสิ่งที่น่าสนใจอย่างเป็นอิสระ ไม่ว่าจะเป็นผลิตภัณฑ์ของบริษัทไหนก็ตาม

✓ คุ้นเคยกับสิ่งใหม่ๆ อยู่เสมอ

→ ให้ความเคารพคู่แข่ง: เป็น DA ที่ยอดเยี่ยมและเป็นนักหาเรื่องไปพร้อมกันไม่ได้

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

→ รู้จักคู่แข่ง: ถ้าจะพูดเชิงเปรียบเทียบ ก็ต้องรู้จักก่อน

→ ลองสร้างและใช้งานตัวอย่างด้วยผลิตภัณฑ์คู่แข่ง: เพื่อเปรียบเทียบและเข้าใจความแตกต่างได้

• การเตรียมตัวสำหรับ Outreach

→ ตรวจสอบข้อเท็จจริงให้ถูกต้อง: ถามทีมผลิตภัณฑ์ให้ละเอียดเกี่ยวกับสเปก ฟีเจอร์ และสิ่งที่ทำไม่ได้

→ รู้จักผู้ฟังและความต้องการของพวกเขา

→ เตรียมผู้เชี่ยวชาญไว้ช่วยสนับสนุน:

✓ จดคำถามที่ตอบไม่ได้ไว้ แล้วติดตามภายหลัง

✓ อย่าสัญญาสิ่งที่ไม่มั่นใจว่าทีมผลิตภัณฑ์จะให้ได้

→ เลือกสื่อที่เหมาะสม: สไลด์ วิดีโอ ออดิโอ live coding ตัวอย่างออนไลน์แบบทีละขั้นตอน..

→ เตรียมรับมือกับความล้มเหลว:

✓ มีสำเนาสไลด์ทั้งแบบ local และออนไลน์

✓ สำรองไว้ใน USB แยกต่างหาก

✓ หากใช้สไลด์ไม่ได้ ต้องเตรียมให้ดำเนินต่อแบบ Q&A ได้

✓ ออนไลน์อาจใช้ไม่ได้เสมอ จึงควรมีไฟล์ local หรือ hotspot เตรียมไว้

• การหาโอกาสในการพูด

→ เข้าร่วมพอดแคสต์

→ เข้าร่วมเป็นพาเนลลิสต์: เป็นผู้เชี่ยวชาญเฉพาะด้าน หรือเป็นสมาชิกของกลุ่ม

→ เข้าร่วม barcamp/meetup: พูดสั้นๆ

→ เขียนบทความลงนิตยสารออนไลน์และสื่ออื่นๆ

→ จัด brown bag session: สัมมนาช่วงพักกลางวัน

→ ตั้งคำถามในงานคอนเฟอเรนซ์

→ เป็นวิทยากรที่คนอยากเชิญ: เปิดเผยและเผยแพร่หัวข้อบรรยายของฉัน (Term)

✓ ข้อมูลติดต่อ ประวัติล่าสุด สไลด์/วิดีโอการบรรยายล่าสุด

✓ หัวข้อที่อยากพูด เทคโนโลยีที่ใช้

✓ สิ่งที่ต้องการจากผู้จัดคอนเฟอเรนซ์ เป็นต้น

• การเดินทางและการเข้าร่วมคอนเฟอเรนซ์

→ เคล็ดลับการเดินทาง: เผื่อเวลาไว้ 1 วัน เดินทางอย่างประหยัด

→ ใครเป็นผู้จ่ายค่าใช้จ่าย?

→ เข้าร่วมกิจกรรมหลากหลายในสถานที่จัดงาน และทำความรู้จักกับวิทยากรคนอื่นๆ

→ ใช้โซเชียลมีเดียเมื่อเข้าร่วมงาน:

✓ ใส่ช่องทางโซเชียลมีเดียติดต่อไว้ในสไลด์

✓ บอกเล่าการเข้าร่วมคอนเฟอเรนซ์ด้วยแฮชแท็ก ฯลฯ

✓ แชร์เนื้อหาสนุกๆ หรือเซสชันที่ดี

✓ แชร์ต่อข่าวสารจากผู้จัดคอนเฟอเรนซ์

✓ โพสต์สไลด์ขึ้นออนไลน์และบอกให้คนรู้

→ สร้างเครือข่ายผ่านงานอีเวนต์

→ สร้างปฏิทินเพื่อติดตามการเข้าร่วมงานและบันทึกไว้

→ ใช้ประโยชน์จากกระแสของคอนเฟอเรนซ์

→ เป็นส่วนหนึ่งของคอนเฟอเรนซ์ที่คุณไปพูด

→ ปล่อยสไลด์และเอกสารที่เกี่ยวข้องทันที

→ เขียนบันทึกเกี่ยวกับคอนเฟอเรนซ์

• การบรรยายและการจัดเวิร์กช็อป

→ เป็นตัวของตัวเอง: ทรัพย์สินที่ดีที่สุดคือความเชื่อมั่นในตัวเอง

→ เชิญชวนให้เกิดการสื่อสาร

→ เตรียมสิ่งที่ผู้เข้าร่วมจะนำกลับไปใช้ต่อ (takeaways)

→ เตรียมช่วง Q&A และควบคุมให้ดีทั้งหมด

→ ซื่อสัตย์และพูดความจริงเท่านั้น: ถ้าไม่รู้คำตอบ อย่าเดา

→ สื่อสารติดตามผลหลังจบการบรรยาย

• เคล็ดลับการพรีเซนต์: การคุมเวลาและอื่นๆ

→ จะยัดทั้งหมดนี้ลงในเวลา X นาทีได้อย่างไร

→ Less is More: เริ่มจากสิ่งสำคัญเพียงอย่างเดียว (อินไซต์ ผลการวิจัย สถานะปัจจุบันของ X ฟีเจอร์ใหม่ของผลิตภัณฑ์ X) ผู้คนควรจำอะไรจากการบรรยายนี้?

→ การบรรยายของคุณสำคัญมากสำหรับคุณเท่านั้น

✓ มันเป็นเพียงหนึ่งในหลายๆ อย่าง

✓ การบรรยายของคุณจะถูกบันทึกและเผยแพร่ไปหลายที่

✓ ผู้คนจำเนื้อหาทั้งหมดไม่ได้

✓ ผู้คนไม่ได้ต้องการคุณเพื่อเข้าถึงข้อมูลนั้น เพราะหาได้ง่ายทางออนไลน์

→ จัดเตรียมข้อมูลเพิ่มเติม

→ live coding ? สิ่งที่ต้องระวัง

→ หลีกเลี่ยงคำถาม

→ สิ่งที่ควรตัดออก: สไลด์สารบัญ ข้อมูลบริษัท การแนะนำตัว มุกตลกและ meme ต่างๆ

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

→ เตรียมสรุปการบรรยาย

• สิ่งที่ไม่ควรพูดบนเวทีและทางเลือกที่ใช้แทนได้

→ “อันนี้ง่ายมาก” : “ถ้าจะทำสิ่งนี้ ก็แค่ต้องผ่านไม่กี่ขั้นตอน”, “เครื่องมือเหล่านี้มีเอกสารที่ดีมาก ดังนั้นคุณก็...”

→ “ขอทวนสั้นๆ สำหรับคนที่อาจยังไม่ทราบ” : “ขอกล่าวอีกครั้งว่า X คือ..”, “อย่างที่ทราบกัน X คือ...”

→ “ใครๆ ก็ทำได้” : “ถ้าทำแบบนี้ งานส่วนที่เหลือจะสนุกขึ้นมาก” “มันได้ผลมาก ลองทำดูแล้วบอกต่อคนอื่นด้วย”

→ “ไม่ต้องกังวล เพราะ X จะแก้ปัญหานี้ให้เอง” : “X ช่วยแก้ปัญหาที่เกี่ยวกับ Y ดังนั้นคุณจึงสร้าง Z ได้”

“X ถูกสร้างมาเพื่อให้ Y ง่ายขึ้น และมีการใช้งานจริงอยู่แล้ว ผลลัพธ์ก็น่าส่งเสริมมาก”

→ “อย่างที่ทุกคนรู้อยู่แล้ว” : “ช่วงนี้มีการพูดถึงเรื่องนี้มาก และ X (ลิงก์) อธิบายไว้ได้ดี”..

→ “อย่างที่เราเรียนกันในโรงเรียน” : “นี่เป็นส่วนหนึ่งของหลักสูตรวิทยาการคอมพิวเตอร์ และมันก็มีเหตุผลรองรับ”

→ “Y (ผลิตภัณฑ์ของเรา) ดีกว่า X (คู่แข่ง) มาก” : “นี่คือวิธีทำโดยใช้ X ส่วนเราเลือกแนวทางอื่น และเหตุผลมีดังนี้”

“ปัญหานี้มีทางแก้หลายแบบ และเราทราบว่า X ไม่มีฟีเจอร์บางอย่างที่อาจทำให้มีประสิทธิภาพมากขึ้น..”

→ “ทำได้ด้วยโค้ดแค่ไม่กี่บรรทัด” : “อย่างที่เห็น คุณเริ่มต้นได้ด้วยโค้ดไม่กี่บรรทัด ผมย่อให้สั้นเพื่อสาธิตตรงนี้ และซอร์สโค้ดอยู่ที่ X”

→ “ถ้าอยากเป็นผู้เชี่ยวชาญ (professional) ให้ทำ X” : “ข้อดีของ X คือ Y จึงทำให้มันเป็นเครื่องมือระดับมืออาชีพในการใช้งาน

→ นอกจากนี้ ลองย้อนดูการบรรยาย/วิดีโอของตัวเอง แล้วคิดว่า “ถ้าฉันไม่รู้เรื่องนี้มาก่อน ฉันจะรู้สึกอย่างไรเมื่อได้ยินคำพูดนี้” จากนั้นตัดหรือพูดใหม่

• การเขียนโพสต์และบทความที่ยอดเยี่ยม

→ Simple is not stupid: การเขียนให้เข้าใจง่ายและเรียบง่ายนั้นยากมาก ใช้คำง่ายๆ คำที่ผู้ชมจำนวนมากเข้าใจได้ และประโยคที่กระชับ

→ พูดให้ตรงประเด็น อย่า sugar-coat

→ ความยาวของบทความสำคัญ บทความเทคนิคสำหรับออนไลน์ควรสั้นและส่งสารเฉพาะแก่น ถ้ายาวเกินไปให้แยกเป็นหลายบทความ

→ เพิ่มสื่อที่เกี่ยวข้องให้หลากหลาย เช่น วิดีโอ ออดิโอ สไลด์ รูปภาพ

→ จัดโครงสร้างเนื้อหาด้วย heading หลายระดับ เป็นต้น

→ เนื้อหาก็ควรมีอายุการใช้งานที่ชัดเจน

→ อ้างอิงแหล่งข้อมูลอื่นเพื่อยืนยันข้อเท็จจริง

→ การเขียนเชิงรุก (Pre-emptive) - ทำให้ผลิตภัณฑ์ของคุณดึงดูดความสนใจจากนักพัฒนา ส่วน “การขาย” เป็นหน้าที่ของทีมเซลส์

• การเขียนโค้ดตัวอย่างที่ยอดเยี่ยม

→ แก้ปัญหาผ่านตัวอย่าง

→ แสดงตัวอย่างที่ใช้งานได้จริง

→ อธิบายสภาพแวดล้อมที่ต้องใช้

→ เขียนโค้ดที่ Copy & Paste ได้

→ เปิดให้ดาวน์โหลดตัวอย่าง

→ เขียนตัวอย่างที่สะอาดและฉลาด

→ โฮสต์โค้ดและเดโม

✓ การจัดการเวอร์ชันคือเพื่อนของคุณ

✓ โฮสต์แบบอัตโนมัติ

✓ ใช้ code sandbox

✓ สภาพแวดล้อมสำหรับ live coding

• การเตรียมสไลด์ประกอบการบรรยายที่ยอดเยี่ยม

→ รู้ให้ชัดว่าคุณรู้อะไรอยู่บ้าง

→ เริ่มจากเนื้อหา ไม่ใช่จากสไลด์

→ เริ่มเขียนในรูปแบบข้อความที่พกพาได้

→ เคล็ดลับทำสไลด์ให้เร็ว: แตก bullet ออกเป็นส่วนย่อย

→ เลือกและเตรียมเครื่องมือพรีเซนต์ที่เหมาะกับการบรรยาย

✓ ต้องปรับเปลี่ยนได้ไม่ว่าจะเป็น 16:9 หรือ 4:3

✓ ต้องครอปและ resize รูปภาพได้ง่าย

✓ ต้องย้ายวัตถุบนหน้าจอได้อย่างอิสระ

✓ ควบคุมระยะไกลได้

✓ เปลี่ยนไปยังสไลด์ชุดอื่นได้อย่างลื่นไหล

✓ รองรับเต็มหน้าจอ

✓ แสดงทีละรายการได้

• การทำสไลด์สำหรับการพูดที่ยอดเยี่ยม

→ อย่าเขียนเป็นบันทึกคำพูด แต่ให้อธิบายด้วยประโยคสั้นๆ / รูปภาพ / สกรีนช็อต / กราฟ

→ ค้นหาและใช้รูปภาพที่ดี

→ ทำให้โค้ดตัวอย่างอ่านง่าย

→ เคล็ดลับการใช้เสียงและวิดีโอ

→ ใช้แอนิเมชันเฉพาะจุดที่จำเป็น (อย่าให้วิบวับเกินไป)

→ กระชับ - ถ้าเป็นไปได้ให้ครอบคลุมเพียงหัวข้อเดียว

→ คำนึงถึงผู้ฟัง

→ กรณีที่มีเทมเพลตของบริษัทหรือคอนเฟอเรนซ์

→ ปรับเนื้อหาทุกอย่างให้เป็นของคุณเองก่อนใช้: อย่านำสื่อที่ได้จากคนอื่นมาใช้ซ้ำตรงๆ

→ แชร์และสนุกกับมัน

→ เคล็ดลับการบรรยายเพิ่มเติม

✓ แนะนำตัว: ทำไมฉันจึงเหมาะจะพูดเรื่องนี้ และทำไม/อยากพูดอะไร

✓ การใช้มุกตลก: ระวังอย่าโจมตีคนอื่น

✓ สร้างความเชื่อมโยงกับโลกความเป็นจริง

✓ คุมจังหวะไม่ให้เร็วเกินไป: การหยุดเล็กน้อยเป็นผลดีกับผู้ฟัง

✓ หลีกเลี่ยง “Hello World”

✓ ถ้าเป็นไปได้ให้ใช้สไลด์ชุดใหม่ และอัปเดตให้ทันสมัยเสมอ

• เช็กลิสต์เพื่อให้การบรรยายเข้าใจง่าย เข้าถึงได้ และนำไปลงมือทำได้มากขึ้น

→ สื่อประกอบการบรรยาย

✓ เป็น HTML/PPTX/PDF หรือไม่?

✓ โค้ดอยู่บนออนไลน์หรือไม่?

✓ วิดีโอ/เสียงที่ฝังไว้เล่นได้ข้ามระบบปฏิบัติการ และเล่นแบบออฟไลน์ได้หรือไม่?

→ รูปแบบ

✓ สื่อที่ฝังไว้รองรับการเข้าถึงหรือไม่? (caption, alt text, transcript ฯลฯ)

✓ ฟอนต์ใหญ่พอหรือไม่?

✓ ขนาดเหมาะกับคอนเฟอเรนซ์หรือไม่? 16x9, 4x3

✓ มี contrast มากพอที่จะมองเห็นได้แม้โปรเจ็กเตอร์มีปัญหาหรือไม่?

✓ มี safe margin เพียงพอหรือไม่ หากโปรเจ็กเตอร์ตัดขอบภาพ?

✓ ถ้าต้องไปพรีเซนต์บนเครื่องที่ไม่ใช่คอมของคุณ จำเป็นต้องมีฟอนต์สำรองหรือไม่?

→ เนื้อหา

✓ มีเนื้อหาที่รุนแรงหรืออาจ trigger คนหรือไม่?

✓ เข้าใจได้โดยไม่ต้องมีพื้นหลังเฉพาะทางหรือไม่?

✓ มีคำศัพท์ใดที่ล่าม/นักแปลควรรู้ล่วงหน้าหรือไม่?

✓ หากมีการแชร์เพียงบางส่วนหรือเพียงหนึ่งสไลด์ จะมีอะไรที่อาจถูกเข้าใจผิดหรือไม่?

✓ ระบุแหล่งที่มาและตรวจสอบลิขสิทธิ์ของสื่อและข้อมูลทั้งหมดแล้วหรือไม่?

→ การติดตามผล

✓ ทราบได้หรือไม่ว่าใครบ้างดาวน์โหลดสไลด์?

✓ ตอนท้ายสไลด์มี Call-to-Action และลิงก์ให้ดาวน์โหลดหรือไม่

→ การประกันความพร้อม

✓ สื่อทั้งหมดเข้าถึงแบบออฟไลน์ได้โดยไม่ขึ้นกับคอมพิวเตอร์หรือไม่? (รวมทั้งสไลด์/ตัวอย่าง/มีเดียทั้งหมดใน USB)

✓ มีคำอธิบายเตรียมไว้หรือไม่ หากวิดีโอ/ออดิโอเล่นไม่ได้ตามปกติ

• บันทึกทุกสิ่งที่คุณทำไว้

→ บันทึกเสียงการบรรยายทุกครั้ง

→ ถ้าเป็นไปได้ให้บันทึกวิดีโอไว้ด้วย

→ รวบรวมลิงก์ทั้งหมดที่ใช้ในการบรรยายไว้ในที่เดียว

→ เก็บรายชื่อคอนเฟอเรนซ์ทั้งหมดที่เคยไป/จะไปเข้าร่วมไว้: รวมสไลด์/บล็อก/ลิงก์/ลิงก์วิดีโอ

• รู้จักและใช้ประโยชน์จากเว็บ (Social)

→ หาเว็บคอนเทนต์ดีๆ

→ เผยแพร่คอนเทนต์เว็บซ้ำ: เขียนบล็อก บันทึกในเว็บ social bookmarking ใช้ในสไลด์ อ้างอิงใน mailing list หรือ forum ทวีตแชร์

✓ ให้เครดิตผู้สร้างต้นฉบับเสมอ

→ ทำให้คนรู้จักตัวคุณบนเว็บ

→ ใช้เว็บไซต์และผลิตภัณฑ์โซเชียลที่ทรงพลัง: Flickr, YouTube, Vimeo, Archive.org, GitHub, LinkedIn, Facebook, Meetup, Twitter

→ ใช้เว็บเป็นทั้งคลังเก็บ ช่องทางเผยแพร่ และเครื่องมือ cross-promotion

→ ปล่อย hint เกี่ยวกับผลิตภัณฑ์ ทำ teasing และเปิด preview

→ ติดตามผลลัพธ์: เพิ่ม telemetry ในเอกสาร/บล็อก สมัครติดตาม comment feed ใช้ URL shortener ที่ติดตามได้

→ สร้างเครือข่าย

→ สร้างหรือเข้าร่วม newsletter

→ สร้างหรือเข้าร่วม podcast

• การทำงานจากคอมพิวเตอร์ของฉัน

→ อุปกรณ์: ไมโครโฟนภายนอก มอนิเตอร์ กล้อง ไฟส่องสว่าง

→ บันทึก screencast และ screenshot

→ สตรีมมิง

→ เข้าร่วมแชตออนไลน์แบบเรียลไทม์

→ ข้อควรระวังและเคล็ดลับเมื่อเข้าร่วมอีเวนต์ออนไลน์แบบเรียลไทม์

• เคล็ดลับในการบันทึกการบรรยายออนไลน์ของฉัน

[xguru]

ชื่อเวอร์ชันก่อนหน้านี้คือ Developer Evangelist Handbook แต่ช่วงนี้นิยมใช้คำว่า Advocacy มากกว่า Evangelist/Evangelism จึงปรับให้สะท้อนตามนั้น

นี่ก็เป็นหนังสือที่ผมเคยใช้อ้างอิงราวกับเป็นคัมภีร์ ตอนทำงานในฐานะ developer evangelist เมื่อปี 2010

ผู้เขียนทำงานเป็นนักพัฒนามา 20 ปี และเป็นผู้มากประสบการณ์ที่ทำงานสายนี้มาตลอดราว 10 กว่าปีที่ผ่านมา ที่ Yahoo, Mozilla และ Microsoft

แม้จะมีการเรียกหลากหลายทั้ง Developer Advocate/Evangelist/Relations แต่คิดว่าน่าจะเป็นประโยชน์สำหรับทุกคนที่ทำงานเกี่ยวข้อง รวมถึงนักพัฒนาที่ต้องออกไปพูดภายนอกบ่อย ๆ ด้วย

ในส่วนของการทำสไลด์นำเสนอ ประเด็น "อย่าทำแบบไม่ปรับให้เป็นของตัวเอง และอย่าใช้ซ้ำโดยไม่ปรับแต่ง - Don't reuse without personalising" ก็เป็นสิ่งที่ผมเน้นมากเช่นกัน

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

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

[sangkyoonnam]

ขอบคุณสำหรับการสรุปที่ดีครับ ประโยค "อย่านำกลับมาใช้ซ้ำโดยไม่ปรับให้เป็นแบบเฉพาะบุคคล - Don't reuse without personalising" ฟังดูแปลตรงตัวเกินไปเล็กน้อย เลยคิดว่าในบริบทที่คุณอธิบายมา การใช้คำประมาณว่า "ทำให้เป็นของตัวเองก่อนแล้วค่อยนำกลับมาใช้" อาจจะเข้าใจง่ายกว่านะครับ

[xguru]

พอเขียนแล้วก็เป็นอย่างนั้นจริง ๆ ^^; เลยปรับสะท้อนไว้นิดหน่อยแล้วครับ ขอบคุณครับ

[sangkyoonnam]

@_@)b