คู่มือรูปแบบเอกสารทางการ

แผนก

เทคโนโลยี

สารบัญ


วัตถุประสงค์

คู่มือนี้กำหนด รูปแบบและโครงสร้างที่แน่นอน ที่เอกสารทางการของ Kiluth ทั้งหมดต้องปฏิบัติตาม เพื่อให้แน่ใจว่ามีความสอดคล้อง อ่านง่าย และเข้ากันได้กับระบบเอกสารของเรา (Quartz wiki)

ผลลัพธ์
ทุกเอกสารปฏิบัติตามโครงสร้างเดียวกัน ทำให้ง่ายต่อการนำทาง ดูแลรักษา และแปล

ตำแหน่งไฟล์และการตั้งชื่อ

รูปแบบตำแหน่ง

เอกสารทั้งหมดอยู่ใน: kiluth-docs/content/<locale>/<department>/<Document Name>/index.md

#ส่วนประกอบตัวอย่างหมายเหตุ
1Localeen, th, cn, es, jpLocales ถูกกำหนดค่าใน quartz/i18n/locales.ts ปัจจุบัน: en (English), th (Thai) Locales ในอนาคตจะถูกเพิ่มตามความจำเป็น
2Departmentaccount-management, delivery, hr, technology, finance, legal, marketing, creativeชื่อโฟลเดอร์แผนกใช้ kebab-case
3Document NameScope Definition & Price Assessment Guidelineชื่อโฟลเดอร์ตรงกับชื่อเอกสารทุกประการ (ช่องว่าง การใช้ตัวพิมพ์ใหญ่ถูกเก็บไว้)
4Fileเสมอ index.mdโฟลเดอร์เอกสารแต่ละโฟลเดอร์มีไฟล์ index.md หนึ่งไฟล์

ข้อตกลงการตั้งชื่อ

  • ชื่อโฟลเดอร์เอกสารตรงกับชื่อเอกสารทุกประการ (ช่องว่าง การใช้ตัวพิมพ์ใหญ่ถูกเก็บไว้)
  • ใช้ title case สำหรับชื่อเอกสาร (เช่น “Onboarding Guideline” ไม่ใช่ “onboarding guideline”)

โครงสร้างเอกสาร

ด้านบนของไฟล์ (ลำดับที่จำเป็น)

ทุกเอกสารต้องเริ่มด้วยลำดับนี้ทุกประการ:

#องค์ประกอบรูปแบบ
1YAML frontmatter---
title: Document Title
---
2บรรทัดว่าง(บรรทัดว่าง)
3H1 heading# Document Title (ทำซ้ำชื่อ)
4บรรทัดว่าง(บรรทัดว่าง)
5บล็อกแผนกแผนก
<blank line>
ชื่อแผนก

ตัวอย่าง:

---
title: แนวทางการเริ่มงาน
---
 
# แนวทางการเริ่มงาน
 
แผนก
 
[[th/hr/|ทรัพยากรบุคคล]]

สารบัญ (มีอยู่เสมอ)

#ข้อกำหนด
1รวมส่วนสารบัญเสมอ
2ใช้หัวข้อที่เหมาะสมกับ locale: ## Table of Contents (EN), ## สารบัญ (TH), ฯลฯ
3ใช้รูปแบบ ตาราง 2 คอลัมน์
4คอลัมน์แรก: # (หรือว่าง)
5คอลัมน์ที่สอง: Section (EN), ส่วนประกอบ (TH), หรือการแปลที่เหมาะสมสำหรับ locales อื่น

ตัวอย่าง (ภาษาอังกฤษ):

## Table of Contents
 
| # | Section |
| --- | --- |
| 1 | [Purpose](#purpose) |
| 2 | [Scope](#scope) |

ตัวอย่าง (ไทย):

## สารบัญ
 
| # | ส่วนประกอบ |
| --- | --- |
| 1 | [วัตถุประสงค์](#วัตถุประสงค์) |
| 2 | [ขอบเขต](#ขอบเขต) |

หมายเหตุ: เมื่อเพิ่ม locale ใหม่ ให้แปล “Table of Contents” และ “Section” อย่างเหมาะสมสำหรับภาษานั้น

ตัวคั่นส่วน

ใช้ horizontal rules (---) ระหว่างส่วนหลักเพื่อการแยกทางสายตา


กฎการจัดรูปแบบเนื้อหา

รายการ → ตาราง (กฎของบ้าน)

อย่าใช้ bullet points หรือรายการแบบมีหมายเลขในเนื้อหา แปลงเป็นตารางเสมอ

#เดิมแปลงเป็น
1รายการ bulletตารางที่มีคอลัมน์ #
2รายการแบบมีหมายเลขตารางที่มีคอลัมน์ #
3รายการเช็กลิสต์ตารางที่มี ในเซลล์

ตัวอย่าง (ก่อน):

- Item 1
- Item 2
- Item 3

ตัวอย่าง (หลัง):

| # | Item |
| --- | --- |
| 1 | Item 1 |
| 2 | Item 2 |
| 3 | Item 3 |

บล็อกผลลัพธ์

ใช้ ตาราง 1 คอลัมน์ สำหรับข้อความผลลัพธ์:

| __Outcome__ |
| --- |
| <one-sentence outcome> |

เทียบเท่าไทย:

| __ผลลัพธ์__ |
| --- |
| <หนึ่งประโยค> |

การแตกแขนงจุดตัดสินใจ

ใช้ ตาราง 2 คอลัมน์ สำหรับจุดตัดสินใจ:

OutcomeAction
QualifiedProceed to handoff…
Not qualifiedRecord reason…

เทียบเท่าไทย:

ผลลัพธ์การดำเนินการ
ผ่านดำเนินการต่อ…
ไม่ผ่านบันทึกเหตุผล…

ส่วนมาตรฐาน

Operating Model (ข้อความมาตรฐาน)

เอกสารกระบวนการทุกฉบับรวมส่วน “Operating Model” พร้อม ถ้อยคำที่เหมือนกัน:

#Operating Model
1Asana คือระบบหลัก (system of record) สำหรับการติดตามงาน การอนุมัติ และการส่งต่องาน
2ใช้จุดตรวจสอบและจุดตัดสินใจ: ไม่ไปขั้นถัดไปจนกว่าขั้นก่อนจะ “เสร็จ”, และกรณีแตกแขนงต้องระบุให้ชัดเจน
3ลำดับการส่งต่องาน (handoff order): เอกสาร upstream กำหนดสิ่งที่ต้องส่งมอบ/เกณฑ์จบขั้น; เอกสาร downstream กำหนดวิธีทำงานหลังรับมอบ

ข้อความนี้ เหมือนกันในทุกเอกสาร (EN และ TH)

ส่วนทั่วไป

เอกสารส่วนใหญ่รวมส่วนเหล่านี้ (ลำดับอาจแตกต่าง):

#ส่วนเมื่อไหร่ควรรวม
1Purposeเสมอ
2Scopeเมื่อขอบเขตต้องการความชัดเจน
3Definitionsเมื่อคำศัพท์หลักต้องการคำอธิบาย
4Operating Modelสำหรับเอกสารกระบวนการ/workflow
5Roles & Responsibilitiesเมื่อมีหลายบทบาทเกี่ยวข้อง
6Step-by-Step Processสำหรับเอกสาร workflow
7Asana Card Templatesเมื่อ handoffs ต้องการเทมเพลต
8Checklistไม่บังคับ (เฉพาะเมื่อกระบวนการมี handoffs/steps หลายอย่าง)

เทมเพลตการ์ด Asana

เมื่อไหร่ควรรวม

รวมเทมเพลตการ์ด Asana inline ที่ handoffs เกิดขึ้น (ไม่ใช่ในส่วนแยก)

รูปแบบ

ใช้รูปแบบตาราง:

| | เทมเพลตการ์ด Asana |
| --- | --- |
| Title | [Task title] |
| Assignee | [Role/Department] |
| Description | เนื้อหาหลายบรรทัดที่นี่<br>• Bullet point<br>• Another bullet |

การจัดรูปแบบฟิลด์ Description

#กฎตัวอย่าง
1ใช้ <br> สำหรับ line breaksLine 1<br>Line 2
2ใช้ สำหรับ bullets ภายในเซลล์• Item 1<br>• Item 2
3เก็บเนื้อหาให้กระชับและดำเนินการได้

การอ้างอิงข้ามและลิงก์

การอ้างอิงเอกสารภายใน

เมื่ออ้างอิงเอกสาร Kiluth อื่น ใช้ข้อความแบบ breadcrumb:

ดู [[th/delivery/client-acceptance-uat-and-go-live-guideline|แนวทางการตรวจรับงานของลูกค้า (UAT) และการขึ้นระบบ (Go-live)]]

สำหรับการนำทาง wiki ภายใน ใช้ไวยากรณ์ wikilink:

[[th/hr/onboarding-guideline|แนวทางการเริ่มงาน Kiluth]]

ป้ายหลักฐานการ Sign-off

ป้ายมาตรฐานสำหรับลิงก์หลักฐานการ sign-off:

ภาษารูปแบบป้าย
EnglishSign-off proof: [Link]
Thaiหลักฐานการ sign off: [ลิงก์]

เช็กลิสต์การเขียน

ก่อนทำให้เอกสารใดเสร็จสมบูรณ์ ให้ตรวจสอบ:

#รายการเช็กลิสต์
1☐ YAML frontmatter พร้อม title: มีอยู่
2☐ H1 heading ตรงกับชื่อ
3☐ บล็อกแผนกจัดรูปแบบถูกต้อง (บรรทัดว่างระหว่าง “แผนก” และชื่อ)
4☐ สารบัญมีอยู่และสมบูรณ์
5☐ รายการทั้งหมดแปลงเป็นตาราง
6☐ บล็อกผลลัพธ์ใช้รูปแบบตาราง 1 คอลัมน์
7☐ จุดตัดสินใจใช้รูปแบบตาราง 2 คอลัมน์
8☐ ส่วน Operating Model ใช้ข้อความ 3 bullet มาตรฐาน (ถ้าใช้ได้)
9☐ เทมเพลต Asana ใช้ <br> สำหรับ line breaks
10☐ ตัวคั่นส่วน (---) ระหว่างส่วนหลัก
11☐ ไม่มี bullet points หรือรายการแบบมีหมายเลขในเนื้อหา
12☐ การอ้างอิงข้ามใช้รูปแบบ breadcrumb หรือ wikilinks

หมายเหตุ

  • Workflow แบบ English-first: ทำให้เอกสาร EN เสร็จสมบูรณ์ก่อน แล้วแปลเป็น locales อื่นโดยใช้ schema/layout เดียวกัน
  • การกำหนดค่า Locale: Locales ที่รองรับถูกกำหนดใน quartz/i18n/locales.ts เมื่อเพิ่ม locale ใหม่ (เช่น cn, es, jp) ให้อัปเดตไฟล์นั้นก่อน
  • ความสอดคล้องเหนือความสมบูรณ์แบบ: หากไม่แน่ใจ ให้ตรงกับเอกสารที่เสร็จสมบูรณ์แล้วที่มีอยู่ (เช่น HR Onboarding Guideline)
  • การเขียนแบบ Human-first: ปฏิบัติตาม “Human-First Operational Writing Standard” ของแผนก Creative สำหรับโทนและสไตล์