3 ความเข้าใจผิดทั่วไปที่ผู้ก่อตั้ง Fintech มีเกี่ยวกับทีมวิศวกรรม

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

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

ความเข้าใจผิด #1: การวางแผนซอฟต์แวร์เหมือนกับการวางแผนการก่อสร้าง

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

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

นี่คือเหตุผลที่กรอบการทำงานแบบ Agile มีอยู่ในการพัฒนาซอฟต์แวร์ – พวกมันช่วยให้คุณปรับแผนหลังจากการทำซ้ำแต่ละครั้ง

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

ความเข้าใจผิด #2: คุณสร้างผลิตภัณฑ์ครั้งเดียว แล้วก็เสร็จสิ้น

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

ตลาดของคุณเปลี่ยนแปลงตลอดเวลา ลูกค้าของคุณกำลังพัฒนา และคู่แข่งของคุณกำลังสร้างนวัตกรรม – ดังนั้น คุณจำเป็นต้องพัฒนาผลิตภัณฑ์อย่างต่อเนื่องเพื่อรักษาความสามารถในการแข่งขัน นอกจากนี้ คุณไม่ควรลืมเกี่ยวกับการบำรุงรักษาพื้นฐานเพื่อแก้ไขข้อบกพร่องและปรับปรุง 

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

วิธีแก้ไข: มีข้อตกลงว่าทีมเทคนิคสามารถลงทุนเวลา 30% ของพวกเขาในช่วงหนึ่งปีในงานทางเทคนิค ข้อตกลงนี้ไม่สามารถละเมิดได้ หากคุณละเมิด คุณต้องชดเชย หากคุณเพิกเฉย คุณจะเพิ่มความเสี่ยงด้านความปลอดภัยอย่างมาก

ความเข้าใจผิด #3: ต้นทุนการพัฒนาควรคงที่

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

ตัวอย่างเช่น เมื่อสร้างเวอร์ชันแรกของผลิตภัณฑ์ของคุณ การสร้างฟีเจอร์การเข้าสู่ระบบอย่างง่ายอาจใช้เวลาหนึ่งสัปดาห์และมีค่าใช้จ่ายประมาณ $2,000 สองปีต่อมา การใช้ฟีเจอร์เดียวกันอาจใช้เวลาหกสัปดาห์และ $12,000

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

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

ตัวขับเคลื่อนที่แท้จริงของคุณภาพผลิตภัณฑ์

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

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

บทสรุป

ผลิตภัณฑ์ฟินเทคไม่เคยเป็น "สร้างครั้งเดียวแล้วลืม" พวกมันเป็นระบบที่มีชีวิต – เต็มไปด้วยความไม่แน่นอน ความต้องการที่เปลี่ยนแปลง ความซับซ้อนที่เพิ่มขึ้น และความเสี่ยงด้านความปลอดภัยอย่างต่อเนื่อง ผู้ก่อตั้งที่ยอมรับความเป็นจริงนี้ วางแผนสำหรับการพัฒนาอย่างต่อเนื่อง และปฏิบัติต่อวิศวกรเป็นพันธมิตรเชิงกลยุทธ์จะสร้างผลิตภัณฑ์ที่ดีกว่า เร็วกว่า และมีเรื่องน่าประหลาดใจน้อยกว่ามาก \n \n

\