ข้ามไปยังเนื้อหา

บริการ Odoo · บริการพัฒนาโมดูล Odoo

พัฒนาโมดูล Odoo ตามมาตรฐานของ Odoo

เมื่อการตั้งค่าไปต่อไม่ได้จริง ๆ โมดูลที่มาแทนควรเป็นสิ่งที่ทีมคอร์ของ Odoo คุ้นเคย ทั้งรูปแบบ ORM มาตรฐาน กฎสิทธิ์การเข้าถึงที่ถูกต้อง และชุดทดสอบที่รันใน CI ได้

พาร์ทเนอร์อย่างเป็นทางการของ Odooให้บริการไทยและอังกฤษขอบเขตคงที่ทุกระยะ

—— จุดที่เจ็บที่สุด

ปัญหาที่งานนี้ แก้ได้จริง

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

เวิร์กโฟลว์ที่เกือบจะพอดี

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

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

งานปรับแต่งเดิมที่ขวางการอัปเกรดทุกครั้ง

นักพัฒนารายก่อนแก้ไฟล์คอร์โดยตรง หรือคัดลอกมาทั้งโมดูลเพื่อแก้ฟังก์ชันเดียว ทำให้ทุกครั้งที่อัปเกรดเวอร์ชันต้องมีอะไรพัง และการแก้เฉพาะหน้าแต่ละครั้งก็ฝังปัญหาครั้งถัดไปเอาไว้

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

หน้าจอที่ช้าลงหลังเริ่มใช้งานจริง

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

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

โค้ดที่มีคนเข้าใจอยู่คนเดียว

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

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

ความต้องการที่เปลี่ยนกลางทาง

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

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

—— เรียนรู้จากโครงการอื่น

ข้อผิดพลาดที่เราพบบ่อย และวิธีหลีกเลี่ยง

จ้างเขียนโค้ดในสิ่งที่ติ๊กตั้งค่าได้

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

แก้ซอร์สโค้ดคอร์ของ Odoo โดยตรง

การแก้คอร์คือทางลัดที่เร็วที่สุดในการเปลี่ยนพฤติกรรมระบบ และเป็นวิธีที่มัดคุณติดกับเวอร์ชันเดียวตลอดไปแน่นอนที่สุด เมื่อคอร์ถูกแก้ ทุกการอัปเดตกลายเป็นงาน merge และบั๊กทุกตัวมีบ้านที่เป็นไปได้สองหลัง เราเปลี่ยนพฤติกรรมผ่านกลไกสืบทอดของ Odoo เท่านั้น คอร์คงอยู่ตามที่ Odoo ปล่อยมาทุกประการ

สร้างใหม่ในสิ่งที่ OCA ดูแลอยู่แล้ว

Odoo Community Association (OCA) เผยแพร่โมดูลที่ผ่านการรีวิวจากเพื่อนนักพัฒนาหลายพันตัว ครอบคลุมช่องว่างที่พบบ่อย ทั้งรูปแบบรายงาน เวิร์กโฟลว์ทางเลือก และเครื่องมือทางเทคนิค การจ่ายเงินสร้างขึ้นใหม่ตั้งแต่ศูนย์เท่ากับซื้อภาระดูแลที่ชุมชนแบกอยู่แล้วมาไว้เอง เราค้น OCA ก่อนเขียนอะไรเสมอ และต่อยอดจากโมดูลที่มีอยู่เมื่อมันเข้ากับงานจริง

ปล่อยโค้ดตรงเข้าระบบจริง

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

โมดูลยักษ์ก้อนเดียวทำทุกอย่าง

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

—— รูปแบบการเริ่มงาน

สามวิธี ในการเริ่มต้นกับเรา

ทางเลือก · 01

พัฒนาโมดูลตามขอบเขตที่ตกลง

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

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

งานพัฒนาต่อเนื่องรายเดือน

สำหรับบริษัทที่ใช้ Odoo อยู่แล้วและมีงานแก้ไขเล็ก ๆ ไหลเข้ามาเรื่อย ๆ เช่น รายงานใหม่ ตรรกะของฟิลด์ หรือการปรับเวิร์กโฟลว์ โดยไม่ต้องทำสัญญาใหม่ทีละงาน

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

กู้งานปรับแต่งที่ติดค้าง

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

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

พาร์ทเนอร์วางระบบของคุณ

พาร์ทเนอร์ตัวจริง ไม่ใช่ ตัวแทนขายไลเซนส์

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

3สำนักงาน ไทย สหรัฐฯ อินเดีย
2ภาษาให้บริการ โดยเจ้าของภาษา
9บริการ Odoo ตั้งแต่วางแผนถึงดูแล
0การส่งต่องานระหว่างทีมขายกับทีมส่งมอบ

—— งานที่เสร็จหน้าตาเป็นอย่างไร

ผลลัพธ์ที่คุณ ตรวจสอบได้เอง

โค้ดที่ทีมของคุณอ่านได้

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

การตรวจรับที่เห็นกับตา

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

ปล่อยเวอร์ชันได้โดยไม่ต้องลุ้น

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

เส้นทางอัปเกรดที่ยังเปิดอยู่

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

—— วิธีการทำงาน

ขั้นตอนการทำงานเป็นอย่างไร

  1. ข้อกำหนดเป็นลายลักษณ์อักษร

    ตกลงพฤติกรรม กรณีขอบ และเกณฑ์การยอมรับก่อนเขียนโค้ดบรรทัดแรก การแก้ความคลุมเครือในขั้นนี้ถูกกว่าแก้ในโค้ดมาก

  2. พัฒนาพร้อมชุดทดสอบ

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

  3. ส่งมอบ

    ส่งมอบซอร์สโค้ด ชุดทดสอบ และ README เข้าที่เก็บโค้ดของคุณ ทีมของคุณดูแลต่อได้โดยไม่ต้องโทรหาเรา

—— ทำไมต้องเรา

สิ่งที่คุณจะได้รับ ซึ่งหาไม่ได้จากที่อื่น

ทำไมต้องเรา · 01

ใช้รูปแบบมาตรฐานของ Odoo

ใช้ ORM มาตรฐาน กฎระดับเรคคอร์ดที่ถูกต้อง และรองรับหลายบริษัทอย่างเหมาะสม นักพัฒนา Odoo คนไหนก็รับช่วงต่อได้

ทำไมต้องเรา · 02

มีชุดทดสอบ ไม่ใช่แค่คำสัญญา

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

ทำไมต้องเรา · 03

ไม่ผูกมัดกับผู้ให้บริการ

โค้ดอยู่ในที่เก็บโค้ดภายใต้บัญชีของคุณตั้งแต่คอมมิตแรก

ยังไม่แน่ใจว่าจะเริ่มตรงไหน? คุยสั้น ๆ ก็รู้คำตอบ

ปรึกษาผู้เชี่ยวชาญ Odoo

—— ทำไมต้องเป็นเรา

การทำงานกับเรา เป็นแบบนี้จริง ๆ

โค้ดเขียนโดย Odoo Partner อย่างเป็นทางการ

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

ที่ปรึกษาคนเดียวตั้งแต่ข้อกำหนดถึงวันใช้งานจริง

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

ขอบเขตงานเขียนชัด ตายตัวเป็นรายเฟส

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

ไทยและอังกฤษแบบเจ้าของภาษา

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

สามสำนักงาน ครอบคลุมเวลาทำงานของคุณ

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

เราค้านแทนคุณเมื่อโค้ดไม่จำเป็น

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

คำแนะนำไม่มีวาระเรื่องไลเซนส์แอบแฝง

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

สร้างงานแบบที่คุณเปลี่ยนตัวเราได้

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

—— อธิบายระดับพาร์ทเนอร์

ระดับพาร์ทเนอร์ Odoo บอกอะไรและไม่บอกอะไร

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

Learning Partner

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

เราอยู่ตรงนี้

Official Partner

มีที่ปรึกษาที่ผ่านการรับรองและส่งมอบงานจริงต่อเนื่อง เราอยู่ระดับนี้ ลงทะเบียนผ่านโปรแกรมอินเดีย และส่งมอบจากไทย สหรัฐฯ และอินเดีย

Silver & Gold

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

—— เหมาะกับใคร

ออกแบบตามขนาดธุรกิจคุณ ไม่ใช่ย่อส่วนมาให้

ธุรกิจกำลังเติบโต (5–100 คน)

สำหรับบริษัทขนาด 5 ถึง 100 คน งานพัฒนาควรเป็นมีดผ่าตัด ไม่ใช่การสร้างแพลตฟอร์ม คือโมดูลเล็ก ๆ หนึ่งหรือสองตัวที่ปิดช่องว่างจริง ในราคาที่รู้ก่อนเริ่มงาน

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

ธุรกิจขนาดกลาง (100–500 คน)

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

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

—— ความเสี่ยง

สิ่งที่มักผิดพลาด และวิธีที่เราป้องกัน

ความเสี่ยง · 01

โมดูลที่ไม่มีชุดทดสอบ

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

ความเสี่ยง · 02

พัฒนาจากข้อตกลงปากเปล่า

ความต้องการแบบปากเปล่าจบที่การเถียงกันว่าตกลงอะไรไว้ เราพัฒนาตามข้อกำหนดที่เขียนและลงนาม พร้อมเกณฑ์การตรวจรับ

ความเสี่ยง · 03

โค้ดที่ถูกกักไว้ในคลังของผู้ขาย

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

—— ค่าบริการ

ค่าใช้จ่ายเป็นอย่างไร

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

ผลงานจากทีมวิศวกรของเราเอง

TechAfterMe Dashboard — AI Dashboard Builder

สร้างแดชบอร์ดจากทุกโมเดลใน Odoo โดยไม่ต้องเขียนโค้ด กราฟ 12+ แบบ ฟิลเตอร์สด และส่งออกได้ ข้อมูลไม่ออกจากเซิร์ฟเวอร์ของคุณ

$493.11 จ่ายครั้งเดียว

ดูรายละเอียด

—— รุ่นและโฮสติ้ง

Community, Enterprise และ ที่ที่ระบบทำงาน

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

ไลเซนส์ $0

Odoo Community

โอเพนซอร์สและใช้งานได้ฟรี ครอบคลุมงานขาย จัดซื้อ สต็อก ใบแจ้งหนี้ การผลิต และอื่น ๆ คุณจ่ายค่าวางระบบ ไม่ใช่ค่าเช่า

คิดต่อผู้ใช้ เรียกเก็บโดย Odoo

Odoo Enterprise

เพิ่ม Studio ระบบบัญชีขั้นสูงและ localisation แอปมือถือ และการซัพพอร์ตอย่างเป็นทางการ Odoo เรียกเก็บโดยตรง เราไม่บวกเพิ่ม

Odoo.sh · VPS · on-premise

เซิร์ฟเวอร์ของคุณหรือคลาวด์

Odoo.sh, VPS ที่เราดูแล หรือฮาร์ดแวร์ของคุณเอง เราแนะนำตามข้อกำหนดและงบประมาณ แล้วบันทึกการตัดสินใจไว้ให้ย้ายได้เสมอ

—— เครื่องมือที่เกี่ยวข้อง

งานบริการนี้ เกี่ยวข้องกับอะไรบ้าง

PythonOWL (JavaScript)XML Viewsรายงาน QWebPostgreSQLREST & XML-RPC APIโมดูล OCAGit และ CI

—— บริการที่เกี่ยวข้อง

ดูบริการอื่น ๆ ของเรา

—— คำถามที่พบบ่อย

คำถามที่ลูกค้ามักถามเกี่ยวกับบริการนี้

พัฒนาสำหรับ Odoo เวอร์ชันใดบ้าง

ตั้งแต่ Odoo 16 จนถึงเวอร์ชันปัจจุบัน ทั้ง Community และ Enterprise หากเก่ากว่านั้น เรามักแนะนำให้ตั้งงบอัปเกรดแทน เพราะการพัฒนาฟีเจอร์ใหม่บนเวอร์ชันที่หมดการสนับสนุนคือการจ่ายเงินสองรอบ

เผยแพร่บน Odoo App Store ให้ได้หรือไม่

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

พัฒนาโมดูลหนึ่งตัวใช้เวลานานแค่ไหน

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

ใช้ Odoo Studio หรือเขียนโค้ดจริง

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

นักพัฒนาในทีมของเราทำงานร่วมกับคุณได้ไหม

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

Odoo ออกเวอร์ชันใหม่แล้วโมดูลที่สั่งทำจะพังไหม

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

ต้องมีไลเซนส์ Enterprise ไหมถึงจะใช้โมดูลที่สั่งทำได้

ไม่ต้อง โมดูลที่สั่งทำรันบน Odoo Community ได้ ซึ่งไม่มีค่าไลเซนส์เลย หากความต้องการของคุณไปแตะฟีเจอร์เฉพาะ Enterprise เช่น Studio โลคัลไลเซชันบางตัว หรือโฮสติ้ง Odoo.sh เราจะบอกตั้งแต่ต้น ค่า Enterprise นั้น Odoo เรียกเก็บกับคุณโดยตรง และเราไม่บวกเพิ่มเด็ดขาด

พร้อมหรือยัง?

มาดูกันว่า Odoo เหมาะกับธุรกิจของคุณจริงหรือไม่

คุยกันสั้น ๆ พร้อมคำตอบตรงไปตรงมา ถ้ามันไม่ใช่ระบบที่เหมาะกับคุณ เราจะบอกตามตรง

LINE myprofitbook · WhatsApp · Bangkok · New York · Delhi NCR
บริการพัฒนาโมดูล Odoo | OdooReply