ได้เวลาออกผจญภัยอีกครั้ง หลังจากที่อยู่ Ookbee และ Ookbee Mall ได้สองปีกว่า
วันแรกที่เข้าไปสัมภาษณ์ มีคุณทอมมี่ (เคยเป็น CEO TARAD Rakuten) คุณเลล่า และผู้บริหารทางฝั่ง Ookbee พี่หมู พี่เตี๊ยะ พี่มิก พี่บี พี่ชาญ ฯลฯ เอ้ย ทำไมเข้าเยอะจัง มารู้อีกที อ่อ เขามาฟังพี่หนุ่มพรีเซ้นบริษัทสยามชำนาญกิจด้วย แหะๆ
ตั้งแต่ออกมาจาก TARAD Rakuten ในปี 2012 ก็เป็นครั้งสุดท้ายที่ผมได้เจอคุณทอมมี่ จน 3 ปี ผ่านไป พี่หนุ่มชวนมาเจอกับคุณทอมมี่อีกครั้ง เพราะแกกำลังหา Lead Developer ที่จะไปช่วยทำบริษัทใหม่ที่ชื่อว่า Ookbee Mall (Thailand) Co.,Ltd.
Ookbee Mall เป็นบริษัท Startup ที่เกิดจากการร่วมทุนระหว่างบริษัทไทย คือ Ookbee และบริษัทญี่ปุ่น คือ Transcosmos เพื่อทำธุรกิจ E-Commerce ในประเทศไทย
ซึ่งจุดเด่นของการร่วมทุนกันทำ คือ Ookbee มีชื่อเสียงในไทยและมีฐานสมาชิกที่ใหญ่มาก ส่วน Transcosmos เอง ก็มี Partner กับบริษัท Supplier ที่ขายสินค้าทั้งไทยและญี่ปุ่นเยอะมากเช่นกัน
จริงๆเริ่มงาน 1 พฤศจิกายน 2557 แต่คุณทอมมี่บอกให้ไปเที่ยวด้วยกันก่อน กลายเป็นว่า 29 ตุลาคม 2557 คือวันแรกที่ผมเข้าไปทำงาน ผ่านกิจกรรม Ookbee Corporate Outing จ้าา เที่ยวมันตั้งแต่วันแรกเลย ไปแบบไม่รู้จักใคร ค่อยๆคุยทำความรู้จักไปทีละคนสองคน สนุกดีครับ รู้จักกันเร็วดี ได้เมาด้วยกันก่อนจะส่งอีเมลคุยงานกัน
การทำงานในช่วงแรก มีเพียงผมคนเดียวที่เป็นพนักงานของบริษัทนี้ ถ้าไม่นับ CEO และ AVP ชาวญี่ปุ่นสองคน .. หน้าที่ผมตอนนั้นก็คือ Research Technology ที่จะใช้ทำ E-Commerce Platform พร้อมกับคอยส่ง Daily Report ความคืบหน้าให้อยู่เรื่อยๆ และมี Weekly Meeting
จนผ่านไประยะหนึ่ง เริ่มมี Financial Manager (พี่โจ๊ก), HR Manager (พี่แนน) และ IT Manager (พี่ศักดิ์) บริษัทจึงได้เริ่มลงรายละเอียดของกลยุทธ การตลาด รวมถึงระบบ จนออกมาเป็น www.ookbeemall.com แบบที่เปิดให้บริการกับทุกคนในเดือนตุลาคม 2558 (หรือไม่เคยใช้วะ ฮาาา)
ที่นี่เปรียบเสมือนโรงเรียนแห่งหนึ่งที่เปิดโอกาสให้ผมได้ลองใช้ความรู้ ใช้ชีวิต เพื่อทดสอบอะไรหลายๆอย่าง ทั้งการสร้าง การแก้ปัญหา ได้เรียนรู้ไปพร้อมๆกับการขยายตัวของบริษัท
แต่ด้วยการแข่งขัน E-commerce ในประเทศไทยที่สูงมาก เปลี่ยนแปลงเร็ว รวมถึงมีผู้เล่นรายใหญ่จากต่างประเทศเข้ามา ก็ถึงวันที่ผู้บริหารได้ตัดสินใจยกเลิกการให้บริการของ Ookbee Mall ลง ทุกคนในบริษัทก็อยู่ในสภาวะ “งงเด้” แต่ทุกคนก็พอเข้าใจได้ถึงสาเหตุของการตัดสินใจนี้
(Facebook: Natavudh Moo Pungchacharoenpong)
มีหลายคนเข้ามาคุยด้วย ถามไถ่ ปลอบใจ ซึ่งผมเองก็ได้แต่ขอบคุณและเล่าถึงเรื่องตนเองมากกว่า คงตอบอะไรเรื่อง Ookbee Mall มากไม่ได้ เพราะไม่รู้ข้อมูลการตัดสินใจของผู้บริหาร
แต่จะว่าไปก็เป็นประสบการณ์แปลกใหม่ดีที่เพิ่งได้เจอ ทั้งชีวิตเคยแต่ต้องสร้าง ทำให้คงอยู่ และพัฒนาต่อไปเรื่อยๆ แต่คราวนี้ต้องค่อยๆเก็บข้อมูล ลดทอนระบบลง ลดค่าใช้จ่าย ไปจนถึงต้องทำลายสิ่งที่ทำมาเองกับมือ เพื่อปิดระบบอย่างสมบูรณ์
ถึงตรงนี้ เล่าเรื่องราวของบริษัทมามากแล้ว เลยอยากบันทึกสิ่งที่ได้เรียนรู้จากการทำงานที่ Ookbee Mall ไว้ เผื่อกลับมาอ่านอีกครั้ง และเผื่อมีประโยชน์กับใครหลายๆคน
เรื่องระหว่างผมและทุกๆ คน
เป็นหัวข้อแรกที่ผมอยากเขียนถึง เผื่อพี่ๆน้องๆที่บริษัทจะเข้ามาอ่านเจอ ผมอยากจะขอบคุณพี่ๆ น้องๆ เพื่อนๆ ทุกคนที่ร่วมทำงานกันมา ทั้งที่อยู่ด้วยกันจนวันสุดท้าย หรือแม้แต่ออกไปก่อนหน้านี้ อย่างน้อยก็ได้มีประสบการณ์ มีเวลาดีๆ ร่วมกัน
และผมต้องขอโทษทุกๆคน หากผมทำให้ไม่พอใจ ทั้งที่ตั้งใจและไม่ได้ตั้งใจ เนื่องจากผมค่อนข้างขี้หงุดหงิด แข็งกระด้าง ก็พยายามที่จะปรับปรุงตัวอยู่เรื่อยๆนะ ระหว่างที่เป็นก็มักเลี่ยงด้วยการไม่คุยและเงียบๆ เพื่อเอาตัวเองออกจากสภาวะนั้น เลยอาจจะทำให้ใครหลายๆคนไม่ค่อยพอใจ รวมไปถึงการไม่ค่อยอธิบายอะไรมากนัก เลยทำให้ทุกคนมักไม่กล้าคุยกับผม และเลี่ยงที่จะไปคุยกับคนอื่นในทีม เช่น พี่ศักดิ์ พี่หมี น้องอัยส์ แล้วให้เขามาคุยกับผมอีกที .. ข้อนี้ผมคงต้องพยายามปรับอีกเยอะ
บางทีก็มีคนสงสัยนะว่าระหว่างการคุย และการเขียน ทำไมผมเขียนแล้วดูดีกว่าการคุย เพราะการเขียนผมได้คิดก่อน บางทีผมเขียนไปเพลินๆ มาอ่านอีกที ผมก็พบนิสัยไม่ดีของตัวเองที่ทำให้สิ่งที่จะสื่อสารมันผิดเพี้ยนไป ต้องคอยเขียนแล้วแก้อยู่เป็นประจำ ส่วนการคุยต่อหน้าผมก็จะผิดพลาดเยอะ ยกเว้นคุยแบบมีหัวข้อชัดเจนหรือคุยเรื่องที่ชอบหรือพรีเซ้นงาน อันนี้ไม่มีปัญหาอะไร
อีกเรื่องคือ ผมยึดถือกับความผิด และความถูก มากเกินไป จนลืมไปว่านี่คือมนุษย์ปุถุชน มีเกิดแก่เจ็บตาย มีร้ายมีดี ผมเพิ่งค้นพบจากคำสอนพุทธทาสเมื่อเร็วๆนี้เองว่า เราควรมองว่าโลกนี้ว่าทุกสิ่งมันเป็นของมันเช่นนี้เอง ทั้งเหตุการณ์และคนที่ทำให้เราพอใจและไม่พอใจ
และยิ่งการแสดงออกของผมที่ดูจะเถรตรงเกินไป ว่าพอใจและไม่พอใจอะไร โดยสิ่งที่ไม่พอใจ ผมก็ไม่แคร์สิ่งเหล่านั้นเลย ซึ่งจริงๆแล้วผมก็ไปอ่านเจอจากไหนสักแห่งว่าการแสดงว่าไม่พอใจแต่แสดงออกว่าพอใจ ไม่ใช่การ fake แต่เป็นการแสดงความเป็นผู้ใหญ่ในตัวเรา เพื่อให้ทุกอย่างราบรื่น
การทำงานร่วมกัน
เป็นอีกเรื่องหนึ่งที่มีผลจากหลายปัจจัย ตั้งแต่วิธีการทำงานของแต่ละคน ความรอบคอบ รวมไปถึงความไม่ดีของผมในหัวข้อแรกด้วย แต่ก็พอจะสรุปเป็นบทเรียนของผม ได้ ดังนี้
- มีความรอบคอบในการทำงานให้มากๆ จะสามารถลดข้อผิดพลาดที่จะตามมาภายหลังได้ เรื่องบางเรื่อง อาจไม่ได้ผิดพลาด หรือมองผ่านมันไปเพราะคิดว่าเพียงเล็กน้อย แต่เหล่านี้อาจทำให้การสื่อสารเข้าใจผิด และอาจต้องทำให้แก้ไขนาน
- ไม่ส่งต่องานแบบมักง่าย ส่งไปแบบไม่ได้ตรวจทาน ข้อมูลไม่ครบ มีข้อผิดพลาด มันจะทำให้เพิ่มเวลาการสื่อสารมากขึ้น เพิ่มอารมณ์ของผู้รับงานไปทำต่อมากขึ้น จริงๆ หัวข้อนี้ผมพบแทบทุกที่ในการทำงาน เหมือนสักแต่ว่าทำให้พ้นตัวไป ปิดงานตัวเองได้ก็จบ แล้วปลายทางก็ได้ของชุบขี้คนส่งมาชิ้นหนึ่ง ที่ต้องเอาไปล้างกว่าจะใช้งานได้ ซึ่งงานล้างมันไม่ยาก แต่เสียเวลา และการที่ต้องมาดมขี้ จับขี้ มันก็เสียอารมณ์
- ลดการทำงานแบบ Functional แบบที่งานของใครของมัน ทำแค่นี้จบแค่นี้ จริงๆแล้วมันคือทัศนคิตที่ใช้แก้ไขข้อไม่ส่งงานแบบมักง่าย ซึ่งถ้าทุกคนที่ทำงานร่วมกัน เข้าใจงานตั้งแต่ต้นจนจบ เข้าใจว่าแต่ละส่วนที่เกี่ยวข้องต้องทำอะไร และเห็นใจ ใส่ใจเขา ใส่ใจเรา ไม่ใส่ใจเฉพาะตัวเอง งานตัวเอง มีความโปร่งใสและเต็มที่ซึ่งกันและกัน ทุกอย่างมันจะราบรื่นมาก
- มีการ Sync งานกันตลอดเวลา เช่น Morning Meeting ทุกวัน และทุกคนต้องได้พูด, เอกสาร Task งาน แชร์ถึงกัน, ข้อมูล Result งาน แชร์ถึงกัน
- ทุกคนในบริษัทควรเข้าใจการทำงานของบริษัท และเข้าใจในระบบ การทำงานของระบบ หรือผลิตภัณฑ์ของตัวเอง เพื่อที่จะขาย จะแนะนำ จะแก้ปัญหาให้คนอื่นๆได้ ไม่ใช่หน้าที่ใครคนใดคนหนึ่งหรือคนที่รู้ส่วนนั้นเท่านั้น
Prestashop
ช่วงเริ่มทำงาน ต้องทำ Research ระบบที่จะมาทำเป็น E-Commerce Platform ผมได้รับ requirement มาระดับหนึ่ง ซึ่งถ้าเขียนเองคนเดียว คงใช้เวลานานแน่ๆ เลยกลับไปดูพวก Open Source ซึ่งตอนแรกจะใช้ Magento แต่ด้วยระบบใหญ่มาก มีซับซ้อนทั้งทางฝั่งคนทำและผู้ใช้งาน เลยมองเบอร์สองคือ Prestashop ที่ดูจะเป็นมิตรกว่า
- Prestashop คนไทยยังใช้น้อย เพราะข้ามไปเล่น Magento ที่ตัวท็อปเลย หรือเล่นตัวง่ายๆ อย่าง osCommerce, OpenCart, Zencart แทน ดังนั้นหาผู้รู้ได้น้อยมาก ต้องไปเปิดข้อมูลจากเว็บฝรั่งแทน แต่ฝรั่งก็ยังมีข้อมูลไม่มากนักโดยเฉพาะเชิงลึก
- มันไม่ได้เหมาะกับระบบใหญ่มากนัก คำว่าใหญ่คือ เอาไปทำ Market Place น่าจะมีปัญหา เพราะไปอ่านบอร์ดของฝรั่งจะเริ่มมีปัญหาที่สินค้าหลักแสนชิ้น ซึ่งผมลอง optimize ดูก็ยังพอรับได้ประมาณ 5หมื่นชิ้น หรือ 1แสน SKUs รับโหลดใช้งานที่พีคสุด 1,200 user/minute ก็อืดมากก แม้ยังไม่ถึงกับล่ม
- ระบบกิน CPU มาก ดังนั้นหากใช้ Cloud Computing ให้เลือกประเภทที่เน้น CPU
- ระบบแคมเปญการลดราคา หรือใช้งาน Point มีโมดูลรองรับลูกเล่นได้เท่าที่ตลาดเล่นกันอยู่ตอนนี้ เช่น ซื้อหนึ่งแถมหนึ่ง ซื้อแล้วลด ลดยกแคตตาล็อก ลดยกเว็บไซต์ ลดตามคูปอง ฯลฯ
- ระบบ Report มันเหมือนจะมีเยอะ แต่ไม่เพียงพอ ถ้าผู้บริหารจะดูเชิงลึก และนำไปวิเคราะห์ ดังนั้น ควรทำระบบ Report เพิ่มเอง แยกออกไปต่างหาก จะทำได้ง่ายกว่าและอิสระกว่า
- ทำ Caching เพื่อลดใช้งาน Memory ง่ายและเร็วกว่าไปแก้ Algorithm เพราะแก้ Algorithm จะเกี่ยวเนื่องกันยาวหลายส่วนมากๆ
- SQL Query หลายส่วนยังทำงานได้ไม่ดี เหมือนถูกเขียนมาเพื่อรองรับสินค้าไม่มากนัก ต้อง Optimize เยอะ โดยเฉพาะ Search
- SQL Query หลายตัวเรียกใช้เว่อวังอลังการมาก บางทีเรียกแค่ชื่อสินค้า รูป และคำอธิบายโดยย่อ แต่พี่แกก็เรียกฟังก์ชั่นเดียวกับหน้า Product คือโหลดมาหมด ด้วยสารพัด Condition ดังนั้นควรต้อง Override และเขียนฟังก์ชั่นใหม่เอง สำหรับเรียกใช้ข้อมูลและ Condition ตามเท่าที่จะใช้จริงๆ ก็เข้าใจนะว่าต้องการ reuse code แต่มันไม่เหมาะกับเนื้องาน
- หน้า UI ในระบบหลังบ้านก็ทำได้ไม่ดีมาก ถูกเขียนมาเพื่อรองรับสินค้าไม่มาก เช่น ใช้ List Box แสดงสินค้า ซึ่งถ้าเจอสินค้าแสนชิ้น ก็หายากและโหลดนาน กินทั้งทรัพยากรและลำบากคนใช้
- สามารถทำ Override Code ได้ ไม่ต้องแก้ไข Code หลัก ก็สะดวกดี แต่ที่ต้องระวังคือ เวลาลงโมดูลต่างๆ มันก็มาเขียน Override ด้วย บางทีโมดูลเขียนมาไม่ดี มันก็ทับที่เราแก้ไขมั่วซั่ว เกิด Error ได้
- Prestashop version 1.7 เป็นต้นไป ปรับจาก Hard Code ไปใช้ Symfony Framework แล้ว ดังนั้น Template เดิมแทบจะใช้ไม่ได้เลย ต้องทำใหม่, แต่ก็ยอมเถอะ มันดีกว่ามากเลย
- ระบบ API คือการดึง Database ออกมาให้เรา คือ มีไว้เป็นหน้าด่านเพื่อความปลอดภัย แต่ไม่ได้ช่วยอำนวยความสะดวกอะไรเท่าไร ดังนั้น ออกแบบ Database แล้วแปลงของมันมาใส่ จากนั้นทำ API ขึ้นเองจะสะดวกกว่า
- ฟังชั่น Optimization ในระบบหลังบ้าน ช่วยได้ระดับหนึ่งเท่านั้น อย่าไปคาดหวังมันมาก แล้วที่สำคัญ ค้นหาข้อมูลก็มีแต่ให้ปรับผ่านฟังชั่นนี้ ไม่มีสอนโมโปรแกรมเลย ข้อมูลน้อยมากๆ ต้องศึกษาเอง
Amazon Web Service
- EC2 เลือกแพคเกตดีๆ คุ้มค่าใช้จ่ายมากกว่าที่คิด อย่าง Prestashop เรารู้แล้วว่ากิน CPU มาก และเราลดการใช้ Memory ลงได้ เราก็เลือกประเภท “Compute Optimized” เช่น c4.xlarge ถูกกว่า m4.xlarge ประมาณ 0.019$ แต่ได้ ECU เยอะกว่า 3 ตัว อะไรประมาณนั้น (One ECU provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor)
- EC2 ทำ Auto Scaling + Load Balancing ต้องวางแผนเรื่องการ Deploy ดีๆ เช่น Server Start ขึ้นมาสามตัว ทำอย่างไรให้สามตัวนั้นมีไฟล์เท่ากัน ซึ่งถ้าเป็น Static File อย่าง image,css ให้ย้ายไป S3 แต่ไฟล์ PHP ผมใช้ AWS CLI ทำการ Sync บางไฟล์ที่แก้ไขบ่อยๆ เช่น Theme, Override, Landing Page ซึ่งทำ Cronjob เป็นเวลาเลยครับ
- เพื่อประหยัดเงินบริษัท ใช้ AWS CLI สั่งให้ปิด Server ที่ใช้งานภายในลงตอนบริษัทปิด และทำการเปิดใหม่เมื่อถึงเวลาเข้างาน
- ใช้ Replica ของ RDS ช่วยชีวิต Database ได้เยอะเลย เอาไว้ทำ Slave Database เพื่อใช้อ่านอย่างเดียว ปรับ config, ตั้งค่า Security ก็ง่าย แต่ก็เสียเงินอีกเท่าตัวนึงเท่ากับ RDS ปกติ แต่เนื่องจาก Master ทำงานไม่เยอะ จึงไปลดขนาด RDS Master ได้ แล้วเพิ่มขนาด Slave แทน
- ใช้ Redis ผ่าน ElastiCache สะดวกกว่าติดตั้งใช้เองใน EC2 Server และมันไม่ต้องไปแย่ง CPU, Memory กับ HTTP ด้วย
- จะอย่างไรก็ตามแต่ ก็ควร Tuning Apache ด้วยนะ ใช้มาตรฐานของมันก็เอาไม่อยู่ ถ้าแก้ปัญหาด้วยลงทุนเพิ่ม Server ก็เสียดายเงินอ่ะ
- CloudWatch ไม่ใช่ Monitor ทั้งหมดของชีวิต บางอย่างดูกราฟมันอย่างเดียวก็ไม่รู้ เช่นพวกการใช้งาน CPU, Memory ในแต่ละ Process, แต่มีมันไว้ก็ดี เสียเงินเล็กน้อย ช่วยให้เรามี Monitor ตัวนึงคอยแจ้งเตือนได้
- จะทำ CloudFront ไปทำ S3 ก่อนนะ
- ลองใช้ S3fs เพื่อจำลอง S3 ให้เป็นโฟลเดอร์เก็บไฟล์ใน Server พบว่ามันมันหลุดบ่อยมาก ถ้า sync file เยอะๆ นานๆ
- เอาไฟล์ Themeไปไว้ใน S3 พบว่าช้ามาก ไม่ควรเอาไฟล์ที่จะต้องใช้ประมวลผลไปไว้ใน S3, และถ้าใช้ฟังชั่น CND Optimization ใน Prestashop มันจะเรียกโฟลเดอร์ img,js,css,theme มาจาก S3 ซึ่งมันไม่ควรเอา Theme เข้าไปอ่ะ ดังนั้นถ้าจะใช้ฟังก์ชั่นนี้ ต้องแก้โค้ดให้ไม่เอา Theme
- สุดท้าย วิธีที่ดีที่สุด คือ กลับไปทำเอง โดย S3 เฉพาะรูปพอ และแก้โค้ดโหลดรูปไปที่ URL S3 และเพิ่มโค้ดตอนอัพโหลดรูปให้ไปไว้ที่ S3 ด้วย เท่านั้นจบ!
Payment System
- ฟังการนำเสนอและติดตามข่าว Omise มาตลอด เขาทำได้ดีนะ แต่บริษัทไม่ได้ใช้ ฮาาา
- Omise ทำ Plugin for Prestashop ให้แล้ว แต่เราไม่ทันได้ใช้ซะแล้ว ฮืออ
- LinePay ดูไม่น่ามีคนใช้เยอะ แต่คนก็ใช้เยอะ
- เอกสาร LinePay อ่านงงๆ ว่าต้องทำอะไรบ้างวะ
- Code ที่แจกตามเน็ตของ LinePay, 2C2P ถ้าหาเจอ ต้องแก้ เพราะมันเก่าระดับ 2ปี+ ไม่เป็นไปตามเอกสาร
- ยังรู้สึกสนุกกับการทำระบบ Payment
จริงๆ มีเรื่องราวที่ได้อะไรมากกว่านี้เยอะแยะ แต่เขียนไว้เท่าที่นึกออกเท่านี้ หลายเรื่องก็แตกเป็นบล็อกได้เป็นเรื่องๆ เลยทีเดียว
จู่ๆก็นึกถึงเรื่องราวหลายอย่างในชีวิต และก็นึกถึงเพลงพี่ตูน
ชีวิตมันต้องเดินตามหาความฝัน หกล้มคลุกคลานเท่าไหร่
มันจะไปจบที่ตรงไหน แต่จะยังไงก็ต้องไปให้ถึง
ที่สุดถ้ามันจะไม่คุ้ม แต่มันก็ดีที่อย่างน้อยได้จดจำว่าครั้งนึงเคยก้าวไป
แค่คนที่เชื่อในความฝัน จะเหน็ดจะเหนื่อยก็ยังต้องเดินต่อไป
แสดงว่า PrestaShop เอาไฟล์ css, js มาทำอะไรสักอย่างใน php ก่อนสินะ มันถึงช้า
ถ้าเปิดโหมด Minify and Compress มีเอาไปใช้และทำ+เช็ค caching