การเริ่มต้นซอฟต์แวร์ในปัจจุบันมีข้อได้เปรียบที่สำคัญกว่าเมื่อ 5-10 ปีที่แล้ว ส่วนหนึ่งเป็นเพราะการเพิ่มจำนวนของผู้ให้บริการโฮสติ้งบนคลาวด์แบบไฮเปอร์สเกล เช่น Google Cloud Platform (GCP), Amazon Web Services (AWS) และ Microsoft Azure ด้วยบริการที่มีการจัดการมากมายเพียงคลิกเดียว พวกเขาสามารถสร้างต้นแบบโซลูชันของตนได้อย่างรวดเร็วและนำออกสู่ตลาดในเวลาบันทึกและในระดับที่แทบจะไม่มีที่สิ้นสุด แม้ว่าวันนี้อาจดูเรียบง่าย แต่การเตรียมการเริ่มต้นสำหรับการปรับขนาดบนคลาวด์ยังคงต้องพิจารณาอย่างรอบคอบ

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

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

• ตอนที่ 1: ความเป็นมาและวิธีการเบื้องต้น
• ส่วนที่ 2: การนำวิธีการไปใช้กับการเริ่มต้นที่สมมติขึ้น
• ส่วนที่ 3: การออกแบบและปรับขนาดโครงสร้างพื้นฐานระบบคลาวด์

ต้นปี 2020 ฉันตัดสินใจลองอะไรใหม่ๆ แทนที่จะสร้างและขยายธุรกิจสตาร์ทอัพ ด้านซอฟต์แวร์ ฉันเริ่มให้คำปรึกษาและสนับสนุนพวกเขาโดยเข้าร่วมเป็นพันธมิตรระบบคลาวด์ที่มีรากเหง้าในอิสราเอลชื่อDoiT International บริษัทของเราทำงานจากระยะไกลอย่างเต็มที่และเติบโตขึ้นจากพนักงานประมาณ 50 คนเป็นเกือบ 500 คนทั่วโลกภายในเวลาเพียงสองปี โดยสนับสนุนการใช้ระบบคลาวด์มากกว่า 1 พันล้านดอลลาร์ต่อปี ฉันรู้สึกทึ่งอยู่เสมอว่าเรารักษาวัฒนธรรมของเราไว้ได้ดีเพียงใดผ่านการเติบโตอย่างรวดเร็ว ในขณะที่ดึงดูดและรักษาผู้มีความสามารถไว้มากมาย

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

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

ยุคแรกๆ

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

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

TL;DR; แหล่งข้อมูลออนไลน์ที่เป็นประโยชน์

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

• ฉันควรสร้างสตาร์ทอัพ (14 นาที)— Michael Seibel, Y Combinator
• กลยุทธ์ vs การวางแผน (9 นาที) — HBR [ใช้แผน 1 หน้า เช่น OGSM]
• สรุป Lean Startup (13 นาที) — Eric Ries
• ตรวจสอบความคิดทางธุรกิจของคุณ (9 นาที)— Eric Ries
• Lean UX (60 นาที)— Jeff Gothelf
• การใช้ Lean UX canvas (15 นาที)— Jeff Gothelf
• ผลิตภัณฑ์ก่อสร้าง (59 นาที)— Michael Seibel, Y Combinator
• วิธีวางแผน MVP (13 นาที)— Michael Seibel, Y Combinator
• การทำแผนที่เรื่องราวของผู้ใช้ (50 นาที)— Jeff Patton
• สุดยอดคู่มือการทำแผนที่เรื่องราวของผู้ใช้ — Nick Muldoon, Easy Agile
• สถาปัตยกรรมซอฟต์แวร์ด้วยโมเดล C4 (35 นาที)— Simon Brown
• สร้างวัฒนธรรมแห่งการทดลองที่ Spotify (47 นาที)— Ben Dressler
• DevOps กับ SRE (44 นาที)— Seth Vargo, Google

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

ประมาณ 10 ปีที่แล้ว ระหว่างเซสชั่นการวางแผนตลอดทั้งวัน ที่ปรึกษาคนหนึ่งซึ่งได้เปิดบริษัทของเขาสู่สาธารณะ แล้วขายให้กับ Oracle ในราคาเกือบ 2 พันล้านดอลลาร์ แนะนำให้ฉันรู้จักกับOGSM Framework ย่อมาจากวัตถุประสงค์ เป้าหมาย กลยุทธ์ และมาตรการ มันบังคับให้คุณต้องวาดภาพอย่างรัดกุมว่าคุณจะอยู่ที่ไหนในอนาคต 3-5 ปี เป้าหมายที่สามารถวัดผลได้ระหว่างทาง ในขณะที่เจาะลึกลงไปในกลยุทธ์และกลวิธีระยะสั้นเพื่อบรรลุเป้าหมาย

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

บางคนอาจสงสัยว่าความแตกต่างจากกรอบวัตถุประสงค์และผลลัพธ์หลัก (OKR) ที่ได้รับความนิยมอื่นคืออะไร OGSM มองออกไปในอนาคตข้างหน้า ในขณะที่ OKR ส่วนใหญ่มุ่งเน้นไปที่เป้าหมายระยะสั้น ขึ้นอยู่กับขั้นตอนของบริษัทของคุณ การแนะนำ OKR อาจสมเหตุสมผล แต่บ่อยครั้งที่วิสัยทัศน์ระยะยาวเดียวที่ทุกคนสามารถสนับสนุนได้คือสิ่งที่จำเป็นต้องมี “ดาวเหนือ”

มีเทคนิคอื่นๆ อีกมากมาย เช่น การวิเคราะห์ SWOT, 5 Forces ของ Porter, Balanced Scorecard หรือ 3 Horizons ของ McKinsey ที่อาจป้อนเข้าสู่แผนกลยุทธ์โดยรวมของคุณ แต่ OGSM ยังคงเป็นเครื่องมือส่วนตัวของฉันในการจำกัดโฟกัสของทีมในสิ่งที่สำคัญและแบ่งปัน วิสัยทัศน์ที่ใหญ่ขึ้น

ความคิด

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

แหล่งข้อมูลที่ฉันชื่นชอบสองสามแหล่งที่สนับสนุนวัฒนธรรมการทดลองนี้ ได้แก่ Lean Startup (และ Lean Canvas) โดย Eric Ries และ Lean UX โดย Jeff Gothelf ที่ปรึกษาและผู้บ่มเพาะสตาร์ทอัพเกือบทุกคนแนะนำให้ผู้ก่อตั้งวัดผลทุกอย่าง ทำซ้ำอย่างรวดเร็ว และสร้างผลิตภัณฑ์ที่มีศักยภาพขั้นต่ำ (MVP) เพื่อทดสอบแนวคิดของพวกเขากับตลาด ทั้งหมดนี้สอดคล้องกับหลักการ "ลีน"

Jeff Gothelf นำหลักการ "ลีน" มาใช้ในแนวทางที่ผมชอบ เพราะนำไปใช้กับทุกทีม แผนก และทุกแนวคิดในองค์กรทุกขนาด สมมติฐานคือ "เราไม่รู้อะไรเลย" และเพื่อที่จะเรียนรู้ [สิ่งที่ลูกค้าต้องการ] และสิ่งที่ช่วยแก้ปัญหาได้อย่างแท้จริง เราใช้วิธีการทางวิทยาศาสตร์ - ตั้งสมมติฐาน ทดสอบในขณะที่วัดผล วิเคราะห์ผลลัพธ์ และแก้ไขหลักสูตรตามความจำเป็น . คุณค่าของแนวทางนี้คือการลดความพยายามที่สูญเปล่าให้เหลือน้อยที่สุด และเป็นการยืนยันว่าคุณกำลังแก้ปัญหาที่ถูกต้องได้เร็วขึ้น

ออกแบบ

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

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

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

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

ฉันเป็นคนแรกที่ยอมรับว่าฉันมีไดอะแกรมสถาปัตยกรรมที่น่าเกลียดในสมัยของฉัน ฉันได้เห็นมากขึ้น สิ่งสำคัญคือต้องใช้เวลาในการเขียนสถาปัตยกรรมของคุณและความสัมพันธ์กับระบบอื่นๆ โมเดลC4เป็นหนึ่งในวิธีที่ดีที่สุดในการดำเนินการตามมาตรฐานโดยไม่ต้องใช้ความรู้ UML ตามที่อธิบายไว้ในลิงก์วิดีโอด้านบน แนวทางปฏิบัติมาตรฐานคือการออกแบบความลึกสูงสุด 3 ระดับ (มุมมองคอมโพเนนต์) มีผลิตภัณฑ์เช่นIcePanelที่ทำให้ง่ายขึ้น หรือปลั๊กอินหรือเครื่องมือต่างๆ บนแพลตฟอร์มอื่นๆ มันเร็วกว่าที่คุณคิด และเราจะอธิบายสิ่งนี้ในบทความถัดไปในชุดข้อมูลนี้

สร้าง

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

ดำเนินการ

นอกเหนือจากการพัฒนาแนวทางปฏิบัติในการพัฒนาผลิตภัณฑ์ของคุณแล้ว คุณยังต้องการรักษาวัฒนธรรมของความรับผิดชอบร่วมกัน นี่คือที่มาของหลักการ DevOps Google ได้แชร์การใช้งาน DevOps ที่เรียกว่าSite Reliability Engineering (SRE) และหลายองค์กรได้นำแนวทางปฏิบัติเหล่านี้ไปใช้

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

การวางแผนเพื่อการเติบโต

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

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

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

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

อีกแนวคิดหนึ่งที่ฉันพบว่ามีประโยชน์สำหรับการปรับขนาดองค์กรหรือผลิตภัณฑ์คือAKF Partners Scale Cube ฉันได้เรียนรู้เกี่ยวกับสิ่งนี้เป็นครั้งแรกเมื่อหลายปีก่อนเมื่อมีการอ้างอิงในหนังสือชื่อ “ The Art of Scalability ” ที่ฉันซื้อให้หัวหน้าทีมของฉันในการเริ่มต้นครั้งก่อน — มันยังเป็นอีกหนึ่งข้อมูลอ้างอิงที่มีประโยชน์ทุกเมื่อ โดยข้ามไปยังบทที่เกี่ยวข้องได้ตามต้องการ

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

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

ขอบคุณที่อ่านมาถึงตรงนี้ และฉันหวังว่าคุณจะสนุกกับ ตอน ที่2