มักมีคนพูดว่า คนที่คิดได้เฉียบคมจะไม่ปล่อยความรู้สึกผิดปกติเล็ก ๆ ผ่านไปง่าย ๆ
ฟังดูดีมาก
จนกระทั่งเอานิสัยนั้นมาใช้กับการทำเว็บไซต์คอนเทนต์
“ทำไมบทความนี้ยังไม่ขึ้น?” “ทำไมหน้าภาษาต่างประเทศแทบไม่เดิน?” “ทำไมคนอ่านไม่กระจายไปบทความใหม่?” “หน้าตาเว็บก็ดีขึ้นเยอะแล้ว ทำไมตรงนี้ยังตันอยู่?”
ถ้าไล่ตามคำว่า “มันแปลก ๆ” ทุกครั้งไปเรื่อย ๆ สุดท้ายสิ่งที่ทำจะไม่ใช่การเขียนบล็อกเป็นหลักแล้ว
มันคือการซ่อมบำรุงโรงงานคอนเทนต์
คำแนะนำเรื่องเว็บคอนเทนต์จำนวนมากจบที่ “เขียนให้เยอะ”, “ทำต่อเนื่อง”, “เรียน SEO”
แต่พอเริ่มเดินระบบในปริมาณมาก ปัญหาจะมีลักษณะเหมือนโรงงานมากขึ้นเรื่อย ๆ
งานที่หนักที่สุดไม่ใช่การเขียนบทความ แต่คือการสร้างท่อที่ทำให้บทความถูกสร้าง เผยแพร่ ถูกค้นพบ ถูกอ่าน ไหลไปบทความอื่น และสร้างรายได้
เมื่อมาถึงจุดนี้ บางทีสิ่งที่อยากได้ไม่ใช่ทักษะใหม่เพิ่ม แต่คืออยากให้ผลตอบแทนตามทักษะที่สะสมมาทันเสียที
1. แค่บทความเดียวก็เป็นงานใหญ่แล้ว
“ทำบล็อกก็แค่เขียนบทความ”
ประโยคเบามาก
แต่งานจริงไม่เบาเลย
เลือกหัวข้อ ค้นข้อมูล วางโครง เขียน ตรวจข้อเท็จจริง ตั้งชื่อเรื่อง เตรียมภาพ ใส่ลิงก์ ลง CMS จัดรูปแบบ ดูบนมือถือ เผยแพร่ ช่วยให้เสิร์ชเอนจินค้นพบ ดูทราฟฟิก กลับมาแก้เมื่อจำเป็น
แล้วทำใหม่กับบทความถัดไป
ถ้าตั้งใจทำให้ดี บทความเดียวอาจกินเวลาครึ่งวันหรือเกือบทั้งวันได้ง่าย ๆ
ที่โหดที่สุดคือ ทำเสร็จหนึ่งบทความไม่ได้ทำให้งานพรุ่งนี้ลดลง
เพิ่งเสร็จ หายใจได้สามนาที สายพานก็ส่งชิ้นถัดไปมาแล้ว
บล็อกแบบใช้แรงคนกลายเป็นโรงงานที่มีคนงานคนเดียว
2. ศัตรูตัวจริงของบล็อกแบบดั้งเดิมคือ “ต้นทุนที่กลับมาทุกบทความ”
การเริ่มบล็อกส่วนตัวไม่ได้ยากมาก
ติดตั้ง CMS เลือกธีม จัดหน้าตาให้ดูได้
ส่วนใหญ่เป็นต้นทุนครั้งแรก
ภาระจริงอยู่หลังจากนั้น เพราะต้นทุนการผลิตกลับมาทุกครั้งที่ทำบทความใหม่
ค้นข้อมูล เขียน แก้ไข จัดหน้า อัปโหลด ตรวจ อัปเดต
เชิงโครงสร้างคือ
ต้นทุนคงที่เริ่มต้นค่อนข้างต่ำ แต่ต้นทุนต่อบทความค่อนข้างสูง
นี่แหละที่ทำให้เหนื่อย
ถ้าใช้เวลาเกือบทั้งวันกับหนึ่งบทความ แต่ผ่านไปหลายเดือนรายได้ต่อเดือนแทบไม่ขยับ การหยุดไม่ได้แปลว่าขาดวินัยเสมอไป
ถ้าเวลาที่ใส่กับเงินที่กลับมาไม่สมดุลกันมาก การถอนตัวก็อาจมีเหตุผล
พูดว่า “คนที่ทำต่อจะชนะ” นั้นง่าย
แต่ถ้าระบบทำให้การทำต่อแพงมาก ก็ควรตั้งคำถามกับระบบด้วย
3. โรงงานบทความกลับด้านโครงสร้างต้นทุน
ทางเลือกไม่ได้มีแค่ “เขียนให้เร็วขึ้น”
แต่คือ
บีบกระบวนการทั้งหมดให้เข้าไปอยู่ใน pipeline เดียวให้มากที่สุด
คำถามและบทสนทนาในชีวิตประจำวันกลายเป็นวัตถุดิบ เปลี่ยนเป็นบทความ ลบข้อมูลส่วนบุคคล จัดโครงสร้างให้เหมือนกัน ทำหลายภาษา ตรวจคุณภาพ ส่งไฟล์เข้า GitHub เข้าสู่ขั้นตอนเผยแพร่ ช่วยให้เสิร์ชเอนจินค้นพบ เชื่อมกับการอ่านต่อและการสร้างรายได้
มนุษย์ไม่ต้องนั่งลงทุกวันแล้วบอกว่า “วันนี้จะผลิตคอนเทนต์”
การคิดตามปกติกลายเป็นแหล่งวัตถุดิบเอง
โครงสร้างต้นทุนจึงกลับด้าน
ต้นทุนคงที่เริ่มต้นสูงขึ้น แต่ต้นทุนต่อบทความเพิ่มเติมลดลงได้
ช่วงแรกเหนื่อยมาก
ต้องสร้าง pipeline ตั้งกฎ ทำระบบตรวจคุณภาพ สร้างทางเผยแพร่ พังแล้วต้องซ่อม
แต่การแก้รากของระบบหนึ่งครั้งใช้กับบทความในอนาคตทั้งหมดได้
ประหยัดแรงคนสองชั่วโมงในบทความหนึ่ง ก็ช่วยแค่บทความนั้น
แต่แก้บั๊กการเผยแพร่ที่ราก อาจช่วยบทความในอนาคตหลายพันบทความ
นี่คือความต่างสำคัญ
4. อัตโนมัติแล้วสบายไหม? ไม่ แค่เปลี่ยนชนิดของนรก
คำว่า “อัตโนมัติ” ฟังดูมองโลกดีเกินไปนิดหนึ่ง
“อัตโนมัติแล้วก็คงสบายใช่ไหม?”
ไม่
ที่ถูกกว่าคือ
นรกของงานมือ เปลี่ยนเป็นนรกของการดูแลซอฟต์แวร์
บล็อกแบบใช้มือมีปัญหาง่าย ๆ ว่า
“บทความวันนี้ยังไม่ได้เขียน”
แต่ pipeline อัตโนมัติจะเป็น
“บทความสร้างแล้ว” “อยู่ใน GitHub” “การตรวจเหมือนจะผ่าน” “แต่หน้า production ไม่มี” “ทำไม?”
และบั๊กหนึ่งตัวอาจกระทบหลายบทความพร้อมกัน
ขยายการผลิตได้ ก็ขยายความล้มเหลวได้เช่นกัน
ทันใดนั้นมี QA, การควบคุมกระบวนการ, bottleneck, คิว และงานแก้ซ้ำ
เริ่มจากเขียนบล็อก
ไม่รู้เมื่อไรในหัวมีฝ่ายผลิตเกิดขึ้นมา
5. Bottleneck จะย้ายที่ตลอด
เมื่อการสร้างบทความเร็วขึ้น ข้อจำกัดถัดไปจะโผล่ขึ้นมา
แบบย่อคือ
สร้าง → เก็บ → ตรวจ → เผยแพร่ → HTML production → sitemap → ถูกค้นพบ → ทราฟฟิก → การอ่านต่อ → รายได้
ตอนแรกปัญหาคือ “บทความไม่พอ”
พอบทความเยอะ ปัญหาเป็น “ขึ้นครบจริงหรือเปล่า”
พอขึ้นแล้ว ปัญหาเป็น “เสิร์ชเอนจินเจอไหม”
พอเริ่มเจอ ก็เป็น “คนอ่านไปถึงบทความใหม่และบทความหางยาวไหม”
จากนั้น “ทำไมบางภาษาไม่โต”, “ทำไมทราฟฟิกกองอยู่ไม่กี่หน้า”, “มีโฆษณาและ affiliate แล้ว แต่ประสิทธิภาพดีไหม”
ดูเหมือนปัญหาเพิ่มขึ้น
จริง ๆ มักตรงกันข้าม
เพราะแก้ bottleneck ก่อนหน้าได้แล้ว จึงมองเห็น bottleneck ถัดไป
นี่คือการย้ายจุดตัน ไม่จำเป็นต้องแปลว่าหยุดนิ่ง
6. “บทความไม่ขึ้น” ไม่ใช่ปัญหา optimization แต่เป็นปัญหาประตู
ปัญหาแต่ละอย่างมีลำดับความสำคัญไม่เท่ากัน
เช่น
- การอ่านต่อยังต่ำ
- ทราฟฟิกต่างประเทศโตช้า
- รายได้ยังน้อย
นี่คือปัญหา optimization
ระบบทำงานแล้ว เพียงแต่อยากให้ดีขึ้น
แต่ถ้า
บทความมีอยู่แล้วแต่ไม่ไปถึง production
นี่คนละเรื่อง
ประตูไม่เปิด
สินค้าผลิตแล้ว ชั้นวางมีแล้ว จุดจ่ายเงินมีแล้ว โฆษณามีแล้ว
แต่โกดังไม่ส่งของออกไปหน้าร้าน
ตอนนี้ไปแต่งป้ายโปรโมชั่นไม่ใช่สิ่งสำคัญ
ดังนั้นความล่าช้าหรือการตกหล่นของการเผยแพร่ควรมีลำดับสูง
7. ตีทุกอย่างพร้อมกันเร็ว แต่จะไม่รู้ว่าอะไรได้ผล
งานจริงแทบไม่มีโอกาสแก้ทีละอย่างสวย ๆ
ซ่อมการเผยแพร่พร้อมกับปรับ discovery แก้ internal link ทำทราฟฟิกต่างประเทศ เพิ่มโฆษณาและ affiliate
ทำขนานกันเร็ว
แต่มีผลข้างเคียง
หนึ่งสัปดาห์ต่อมาทราฟฟิกขึ้น
อะไรเป็นสาเหตุ?
เมื่อวานแก้ sitemap วันก่อนแก้ลิงก์ภายใน ก่อนหน้านั้นแก้หน้าหลายภาษา พร้อมกันนั้นก็ปรับ monetization
พอตัวเลขขึ้น ทุกมาตรการยกมือ
“ผมทำครับ”
กลายเป็นต้องประชุม
ยิ่งทำเร็ว ยิ่งควรมีบันทึกการเปลี่ยนแปลงง่าย ๆ
เปลี่ยนอะไร เมื่อไร และตั้งใจให้ metric ไหนขยับ
ไม่ต้องหยุดความเร็วทั้งหมด
แค่มีร่องรอยพอให้เรียนรู้จากความเร็วได้
8. สู้กับระบบมาหนึ่งเดือนครึ่ง ช้าไหม
หนึ่งเดือนครึ่งรู้สึกนาน ถ้าแตะโปรเจกต์ทุกวัน
จะเริ่มคิดว่า “ทำไมยังไม่เสร็จ”
แต่ต้องดูว่ากำลังสร้างอะไร
ไม่ได้แค่ปรับหน้าตา สะสมคอนเทนต์ เพิ่มหลายภาษา ใส่โฆษณา ใส่ affiliate ดูทราฟฟิกจากการค้นหา ดูผู้ใช้ในประเทศและต่างประเทศ ปรับการอ่านต่อ แกะปัญหาเส้นทางเผยแพร่
ถ้าทำทั้งหมดพร้อมกัน นี่ไม่ใช่ “ทำบล็อกหนึ่งเดือนครึ่ง”
แต่มันคือ
สร้างระบบปฏิบัติการสื่อขนาดเล็ก พร้อม debug ด้วยทราฟฟิกจริง
ใช่ มันใช้เวลา
แต่ต่างจากวนอยู่ปัญหาเดิมหกสัปดาห์
ถ้า bottleneck เคลื่อนไปลึกขึ้นในระบบ แปลว่ามีความคืบหน้า
9. ระหว่างความสามารถกับผลตอบแทนมี pipeline ยาวมาก
ตรงนี้น่าหงุดหงิดที่สุด
ความสามารถเพิ่มแล้ว
สร้างคอนเทนต์ได้ จัดโครงสร้างได้ เห็นความผิดปกติได้ ทำอัตโนมัติได้ ทำหลายภาษาได้ ปรับปรุงได้
แล้ววันนี้จะกลายเป็นรายได้เลยไหม?
ไม่จำเป็น
ตรงกลางมีสายยาว
ความสามารถ → ระบบ → สต็อกคอนเทนต์ → เผยแพร่ → ถูกค้นพบ → ทราฟฟิก → ความเชื่อใจ → การอ่านต่อ → รายได้ → ผลตอบแทน
จุดใดจุดหนึ่งตัน ความสามารถก็ยังไม่กลายเป็นเงิน
ดังนั้นความรู้สึกว่า “พัฒนาความสามารถมาพอแล้ว อยากให้ผลตอบแทนตามมาบ้าง” เป็นเรื่องเข้าใจได้
เว็บไซต์คอนเทนต์มี delay
บทความเก่าอาจถูกค้นพบทีหลัง หน้าภาษาอื่นอาจมีทราฟฟิกต่างประเทศขึ้นมาทันที internal link อาจชุบชีวิตบทความเก่า affiliate จะทำงานก็ต่อเมื่อทราฟฟิกที่เหมาะสมมาถึง
เวลาผลิตกับเวลารับผลตอบแทนไม่ตรงกัน
ต่างจากเงินเดือนมาก
ถ้าค่าใช้ชีวิตพื้นฐานมีแหล่งรายได้อื่นรองรับ delay นี้จะทนได้ง่ายขึ้น
ไม่ต้องบังคับให้เว็บทำเงินเดี๋ยวนี้
ปล่อยให้มันโตเป็นสินทรัพย์ได้
10. Metric ถัดไปไม่ใช่แค่ “มีบทความกี่บท”
จำนวนบทความดูง่าย
เพิ่มแล้วรู้สึกดี
แต่เมื่อโรงงานคอนเทนต์โตขึ้น คำถามสำคัญก็เปลี่ยน
เช่น
- ตั้งแต่สร้างจนถึง production ใช้เวลานานเท่าไร
- มีการเผยแพร่ตกหล่นกี่ครั้ง
- URL ใหม่ใช้เวลานานเท่าไรจึงถูกค้นพบ
- มีบทความและภาษากี่ส่วนที่มีคนอ่านจริง
- บทความหนึ่งส่งคนไปอีกบทความบ่อยแค่ไหน
- ทราฟฟิกระหว่างประเทศและภาษาเอียงแค่ไหน
- บทความเก่าโดยไม่เพิ่มงานมือยังสร้างทราฟฟิกเท่าไร
- หนึ่งพันวิวสร้างรายได้เท่าไร
- หลังแต่ละการเปลี่ยน metric ใดขยับจริง
ตัวเลขเหล่านี้บอกว่า “ผลิตได้เยอะ” กลายเป็น “ของที่ผลิตทำงานจริงเยอะ” หรือยัง
บทความคือสต็อก
แต่สต็อกที่ไม่ขึ้น ไม่ถูกพบ ไม่ถูกอ่าน และไม่เชื่อมต่อ ก็ยังไม่ได้ทำงาน
เป้าหมายสุดท้ายของโรงงานบทความไม่ใช่ผลิตบทความ
แต่คือ
เพิ่มจำนวนบทความที่ทำงานต่อได้โดยไม่ต้องเพิ่มแรงคน
สรุป: อย่าปรับแต่คนเขียน ให้ปรับระบบที่ทำให้บทความเกิดขึ้น
เขียนหนึ่งบทความเหนื่อย
ถ้าคำตอบมีแค่ “เขียนให้เร็วขึ้น” สุดท้ายจะชนเพดาน
ยังมีอีกทาง
แทนที่จะอัปเกรดคนเขียนไปเรื่อย ๆ
อัปเกรดระบบที่สร้าง เผยแพร่ และกระจายบทความ
ช่วงแรกยังเหนื่อยมาก
เพื่อหนีจากนรกงานมือ ต้องเข้าไปในนรกสร้างระบบก่อน
ช่วงหนึ่งจะเกิดสถานการณ์ประหลาดว่า
“ทำงานเพิ่มวันนี้ เพื่อให้อนาคตทำงานน้อยลง”
ฟังดูงง
แต่นั่นคือ leverage
แก้ปัญหารากหนึ่งครั้งวันนี้ อาจช่วยบทความทั้งหมดในอนาคต
และนิสัยที่ไม่ปล่อย “มันแปลก ๆ” ผ่านไป จะมีพลังมากในช่วงนี้
ความรู้สึกผิดปกติไม่ใช่แค่ความรำคาญ
มันคือเซ็นเซอร์ที่ชี้ไปยัง bottleneck ถัดไป
งานถัดไปไม่จำเป็นต้องทำให้เซ็นเซอร์นี้คมขึ้นเรื่อย ๆ
งานถัดไปคือปล่อยให้ระบบที่ซ่อมมานานเริ่มทำงานแทนเราเสียที
ความสามารถโตมามากพอแล้ว
ต่อไปให้สินทรัพย์และผลตอบแทนค่อย ๆ ตามมา
