ในช่วงหลังมานี้ ผมได้รับการติดต่อว่าจ้างสำหรับการพัฒนา S/W ที่เป็นลักษณะของ Product และเป็น Core product สำหรับธุรกิจของผู้ว่าจ้าง อยู่ค่อนข้างมาก ผมจึงคิดว่าคงมีหลายๆทีม ที่มีไอเดียพัฒนา Tech Product หรือ Product ที่มี IT เป็น Core แต่ยังไม่มีทีม Developer และต้องการที่จะว่าจ้าง S/W developer team เพื่อพัฒนา

ในบทความน้ีจึงจะอธิบายถึง ลักษณะของการว่าจ้างที่ผมคิดว่าค่อนข้างจะเหมาะสมมากๆสำหรับการว่าจ้างพัฒนา Product ที่จะใช้เป็น Core ของธุรกิจ ซึ่งไม่ได้จำกัดเพียงแต่ Startup เท่านั้น แต่ยังเหมาะสมกับ Enterprise ที่ต้องการพัฒนา Product บางอย่างด้วย โดยขอเรียกว่า การว่าจ้างในลักษณะของ Partner ซึ่งผมคิดว่าจะช่วยให้ได้ออกมาเป็น Product ที่ดีมากๆ และดีกว่าการว่าจ้างแบบเดิมๆ แน่นอน แต่ในส่วนของเรื่องค่าใช้จ่ายจะมากหรือน้อยกว่า การว่าจ้างแบบเดิมๆ ก็อาจจะขึ้นอยู่กับการบริหารจัดการระหว่างการพัฒนา Project นั้น และจะอธิบายข้อดี ข้อเสียของการว่าจ้างแบบ Partner ในความคิดเห็นของผมให้พิจารณากัน เชื่อว่าจะเป็นประโยชน์ไม่มากก็น้อยสำหรับคนที่ต้องการทำ Startup หรือ Project manager ของบริษัทที่มีไอเดียอยากพัฒนา Product ของตัวเอง

การว่าจ้างในลักษณะของ Partner

การว่าจ้างในลักษณะนี้นั้น มันคือ วิธีในการหา Partner ที่เป็นทีม Developer นั่นเอง ซึ่งสามารถทำได้โดย อาจจะว่าจ้างโดยเสนอหุ้นของ Product นั้นให้ตามสัดส่วนที่ตกลงกัน พร้อมกับจ่ายเงินค่าพัฒนาเป็นรายเดือน โดยขอลดราคา Manday ลงจากราคาปกติที่บริษัท S/W นั้นคิดกับทางลูกค้าปกติ เพราะถ้าให้แต่หุ้นอย่างเดียว แน่นอนว่า หาคนมาทำให้ยากแน่ๆ เว้นแต่ว่า คนนั้นจะชอบ ไอเดีย ธุรกิจของคุณ และเห็นว่ามีโอกาสจริงๆ ซึ่งบอกเลยว่าเปอร์เซ็นต์น้อยมากๆๆๆๆๆๆๆ (แต่อาจจะมีหลายคนที่แย้งว่าหุ้นเป็นสิ่งสำคัญควรจะคิดให้มากๆก่อนจะให้กับใคร อันนี้มีทางแก้ครับ อาจจะทำ Option การแบ่งหุ้นเป็น ค่อยๆแบ่ง เมื่อถึง criteria ที่กำหนด เป็นต้น)

ซึ่งถ้าสามารถเจรจาให้เกิดดีลในลักษณะนี้ได้ แน่นอนว่า Product ต้องออกมาดีแน่ๆ เพราะ Developer ก็มีส่วนได้ส่วนเสียโดยตรงกับ Product ที่พัฒนา ยิ่งมีความเป็นเจ้าของด้วยแล้ว ความรู้สึก ความใส่ใจที่มีต่อ Product นั้นก็จะยิ่งมากขึ้นไปอีก และนอกจากนั้นถ้าได้ทีม Developer ที่มีความสามารถจะยิ่งได้ประโยชน์อีกมากมายในหลายๆเรื่องแน่ๆ ซึ่งจะอธิบายข้อดีต่อไป พร้อมทั้งข้อเสียที่อาจเกิดขึ้นได้ (แน่นอนว่าไม่มีอะไรที่มีแต่ข้อดี ^^)

ข้อดี

  • รองรับการเปลี่ยนแปลงของ Requirement ได้ดี

การพัฒนา Product นั้นทุกๆคน คงทราบกันดีว่า การเปลี่ยนแปลงของ requirement หลังจากพัฒนาๆ ไปนั้น เป็นเรื่องปกติที่เกิดขึ้นในทุก Project แน่นอน และผมมองว่าเป็นสิ่งที่ควรจะทำด้วยซ้ำ ซึ่งการว่าจ้างลักษณะนี้จะ สามารถเปลี่ยนแปลง requirement แทบจะตลอดเวลา เพราะ Developer ไม่จำเป็นต้องกลัวว่าการเปลี่ยนแปลง Requirement นั้นจะต้อง Charge ราคาเพิ่มหรือเปล่า ลูกค้าจะยอมจ่ายมั้ย ทำแล้วคุ้มหรือเปล่า คำถามเหล่านี้จะหายไปทันที และการเปลี่ยนแปลง requirement จะกลายเป็นเรื่องง่ายๆ ที่สามารถทำได้ตลอด เพราะว่าการเปลี่ยนแปลงแต่ละครั้ง developer เพียงแค่ดูว่า กระทบเวลาทำงานหรือเปล่า ถ้ากระทบก็แจ้งให้ทีม ทราบเพื่อพิจารณาว่าจะทำหรือไม่ เพราะถ้าเวลาทำงานเพิ่มขึ้น ก็ต้องเพิ่มงบประมาณสำหรับพัฒนา

  • ลด Overhead ในการเจรจาต่างๆ

เมื่อมีการเปลี่ยนแปลง requirement ซึ่งจากที่บอกไปข้างต้นว่า เกิดแน่ๆ และบ่อยด้วย ในการว่าจ้างแบบเดิมๆ การเปลี่ยนแต่ละครั้ง หรือ Continue Phase ต่อ จะเสียเวลาในการต่อรองราคา และเรื่องของเอกสารอีกมากมาย ซึ่งเป็น Overhead ที่เสียไปโดยไม่เกิดผลประโยชน์อะไรต่อบริษัทเลย ซึ่งในการว่าจ้างแบบ Partner เวลาที่ต้องเสียในการเจรจามีแค่ ว่า จะทำหรือไม่ทำ Feature ใหม่นี้ คุ้มค่าหรือเปล่า เวลาจะกระทบขนาดไหน ซึ่งการเจรจาเหล่านี้ ไม่เพียงแต่ใช้เวลาน้อยกว่า แต่ยังมีผลประโยชน์โดยตรงกับ Product ที่จะออกมาในอนาคตด้วย

  • Product มีคุณภาพ

จากเคยเล่าในบทความก่อนหน้า ในการพัฒนา S/W ให้ได้ผลลัพธ์ตามที่ลูกค้าต้องการนั้นสามารถทำได้หลากหลายวิธี เพราะฉะนั้นไม่แปลกว่า เราอาจจะได้ของที่ภายนอกดูดี แต่ข้างในกลวง ก็เป็นได้ แต่สำหรับการที่เราให้ Developer มีส่วนร่วมในการเป็นเจ้าของ Product นั้น แน่นอนว่าตรงนี้ การันตี ได้เลยว่า จะไม่มีทางที่จะ ทำแบบ ลวกๆ แน่นอน เพราะของที่ทำออกมานั้นก็เป็นตัวช่วยในการเติบโตของ Developer ทีมเหมือนกัน ดังนั้นยังไงก็ตามเค้าคงไม่ทำของไม่ดี ออกมาให้ตัวเองแน่ๆ จึงมั่นใจได้ว่า Product ที่ออกมาจะมีคุณภาพ และ “รูปก็สวย จูบก็หอม” แน่นอน

  • มีไอเดีย ในการพัฒนา Feature ของ Product เพิ่มขึ้นจากฝั่ง Developer

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

  • เพิ่มโอกาสความสำเร็จของ Product

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

ข้อเสียและแนวทางป้องกัน

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

  • ความเสี่ยงของการเลือก Developer Team

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

  • การลำดับความสำคัญของ Features ต่างๆ

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

สรุป

เขียนซะยาว แต่เชื่อว่าผู้อ่านน่าจะได้ แนวคิดเพิ่มเติม ที่เป็นประโยชน์ไม่มากก็น้อย ส่วนสำหรับการตัดสินใจว่า อยากจะจ้างแบบไหนอันนี้ก็ ขึ้นอยู่กับหลายๆอย่าง ทั้งงบประมาณ, รูปแบบของ Product ที่ต้องการทำ, ระยะเวลาการทำ และอีกหลายๆเรื่อง แต่ถ้าเป็น Product ที่เป็น S/W, IT ที่ต้องการการปรับปรุง พัฒนา ดูแลรักษา อยู่ตลอด และเป็นส่วนสำคัญที่สุดในการสร้างรายได้ให้กับบริษัท แนะนำว่ายังไงก็ควรจะว่าจ้างในรูปแบบของ Partner จะดีที่สุดครับ (อันนี้มองในมุมมองทั้งที่เป็นลูกค้า และ Developer เองด้วยนะครับ)

LEAVE A REPLY

Please enter your comment!
Please enter your name here