ขยายการดำเนินงานด้วยทีมเล็ก: จัดการโครงการหลายสิบโครงการ

เมื่อธุรกิจขนาดเล็กเติบโต จำนวนโครงการที่ดำเนินอยู่จะถึงจุดที่เกินกว่าจะจำรายละเอียดทั้งหมดได้ ต้องติดตามคำสั่งซื้อในหลายมาร์เก็ตเพลซ บำรุงรักษาโครงสร้างพื้นฐานเป็นประจำ และพัฒนาฟีเจอร์ใหม่ ลูกค้ายังสอบถามเรื่องการจัดส่ง การปฏิบัติตามกฎระเบียบ และประมาณการ ทุกอย่างเป็นงานที่ต้องทำ แต่เวลาที่มีไม่ได้เพิ่มตามจำนวนโครงการ

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

บทความนี้อธิบายแนวทางที่เราใช้ ทั้งเครื่องมือที่เลือกแล้วใช้งานได้ดีในระยะยาว หลักการดำเนินงานที่ลดภาระการประสานงาน และความตึงเครียดระหว่างการสร้างสิ่งใหม่กับการรักษาระบบเดิมให้ทำงานได้

ความตึงเครียดหลัก

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

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

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

การเลือกเครื่องมือ

หลักการของเราคือกำหนดมาตรฐานภายในชุดเทคโนโลยีอย่างจริงจัง และลดจำนวนชุดที่ต้องดูแล เครื่องมือที่เพิ่มแต่ละตัวคือจุดที่อาจเสีย สิ่งที่ต้องเรียนรู้ และส่วนที่ต้องพึ่งพาซึ่งอาจทำให้งานอื่นหยุดชะงักเมื่อมีปัญหา ต้นทุนของเครื่องมือจึงไม่ได้อยู่ที่ค่าลิขสิทธิ์ แต่อยู่ที่สมาธิที่ต้องใช้ดูแลทุกอย่างที่เกี่ยวข้องอย่างต่อเนื่อง

ด้านโครงสร้างพื้นฐาน เราใช้ Docker กับผู้ให้บริการรายเดียว ไม่ใช้ Kubernetes สถาปัตยกรรมหลายคลาวด์ หรือ service mesh เพราะ Docker Compose บน VPS ที่มีสเปกเหมาะสมรองรับภาระงานทั้งหมดที่เราดูแลอยู่ได้ พร้อมเอกสารที่ชัดเจนให้กู้คืนจากความขัดข้องได้ง่าย โครงสร้างพื้นฐานที่ซับซ้อนกว่านี้จะใช้สมาธิในการบำรุงรักษามากกว่าประโยชน์ที่ประหยัดได้ในด้านอื่น

ด้านการพัฒนาแอปพลิเคชัน เราใช้เทคโนโลยีมาตรฐานเพียงไม่กี่ตัว ได้แก่ TypeScript สำหรับ frontend ของเว็บ Python สำหรับบริการ backend และไปป์ไลน์ข้อมูล PostgreSQL ซึ่งมักใช้ร่วมกับ TimescaleDB สำหรับจัดเก็บข้อมูลถาวร และ Redis สำหรับคิวกับแคช โครงการใหม่ใช้ชุดนี้เป็นค่าเริ่มต้น เว้นแต่มีเหตุผลที่หนักแน่นให้เปลี่ยน ต้องระบุเหตุผลนั้นอย่างชัดเจนและชั่งน้ำหนักกับต้นทุนการดูแลชุดเทคโนโลยีที่ต่างจากมาตรฐานในระยะยาว

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

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

สื่อสารแบบไม่ต้องตอบพร้อมกันเป็นหลัก

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

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

ในทางปฏิบัติ เราตัดสินใจเป็นลายลักษณ์อักษร เมื่อมีการตัดสินใจสำคัญด้านเทคนิคหรือการดำเนินงาน เช่น เลือกฐานข้อมูล เปลี่ยนกระบวนการนำระบบขึ้นใช้งาน หรือปรับเวิร์กโฟลว์ของลูกค้า เราบันทึกเหตุผล ทางเลือกที่พิจารณา และผลลัพธ์ที่คาดหวัง เอกสารนี้ไม่ได้ทำไว้ให้คนรุ่นหลัง แต่ใช้เมื่อคำถามเดิมเกิดขึ้นอีก ซึ่งในทีมเล็กที่ดูแลหลายโครงการเกิดบ่อยกว่าที่คิด

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

สร้างเองหรือซื้อ

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

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

เกณฑ์ที่สองคือปัญหานั้นต้องอาศัยความรู้เฉพาะเกี่ยวกับข้อมูลหรือระบบของเรา ซึ่งเครื่องมือภายนอกไม่มีหรือไม่ ไปป์ไลน์ข้อมูล ตรรกะธุรกิจ และการเชื่อมต่อระหว่างระบบที่เราควบคุมเหมาะกับการสร้างเอง ส่วนหน้าที่ทั่วไปอย่างส่งอีเมล ประมวลผลการชำระเงิน ยืนยันตัวตน และแดชบอร์ดเฝ้าติดตาม เหมาะกับการซื้อ เว้นแต่ตัวเลือกเชิงพาณิชย์ไม่เหมาะจริง ๆ

เกณฑ์ที่สามคือเรายอมส่งข้อมูลที่เกี่ยวข้องให้บริการของบุคคลที่สามหรือไม่ ข้อมูลการดำเนินงานบางอย่าง เช่น รายละเอียดคำสั่งซื้อ ข้อมูลลูกค้า และข้อมูลการเงิน ไม่ควรผ่านบริการที่บันทึก วิเคราะห์ หรือใช้ข้อมูลเพื่อประโยชน์ของตนเอง การติดตั้งและดูแลระบบเองจึงสมเหตุผลด้านความเป็นส่วนตัว แม้ตัวเลือกเชิงพาณิชย์จะเหนือกว่าทางเทคนิค เราจึงดูแลระบบวิเคราะห์ข้อมูล backend ของ Supabase และชุดระบบเฝ้าติดตามเอง

แต่การตัดสินใจสร้างที่มีต้นทุนสูงที่สุดของเราไม่ได้ดูผิดชัดเจนในตอนแรก ดูเป็นเครื่องมือเฉพาะที่เหมาะกับความต้องการ ต้นทุนปรากฏหลังผ่านไปสิบแปดเดือน เมื่อต้องอัปเดตตามส่วนที่ระบบพึ่งพา เมื่อสมาชิกใหม่ต้องทำความเข้าใจโค้ดที่ไม่มีเอกสารภายนอก หรือเมื่อข้อผิดพลาดขวางการส่งงานลูกค้าแต่ไม่มีช่องทางขอความช่วยเหลือ บทเรียนจึงไม่ใช่ห้ามสร้างเอง แต่ต้องประเมินต้นทุนตลอดอายุการใช้งานอย่างตรงไปตรงมา ไม่ใช่แค่ต้นทุนการสร้าง

มองภาพรวมของกลุ่มโครงการ

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

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

โครงการที่ยังไม่เติบโตทบต้นต้องประเมินให้ชัดว่าลงทุนเพิ่มแล้วแนวโน้มจะดีขึ้นหรือถึงเวลายอมรับผลลัพธ์และย้ายทรัพยากร ทีมเล็กที่ดูแลหลายโครงการเสี่ยงต่ออคติต้นทุนจมเป็นพิเศษ คือยังลงทุนในโครงการที่ไม่ได้ผลเพราะเสียดายแรงที่ลงไปแล้ว การมองภาพรวมช่วยให้เห็นปัญหานี้ เพราะบังคับให้เปรียบเทียบว่าเวลาที่ใช้ประคองโครงการซึ่งหยุดนิ่งคือเวลาที่ไม่เหลือให้โครงการที่เติบโตทบต้นได้

คอขวดที่แท้จริง

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

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

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

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