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

ข้อกำหนดเบื้องต้นสำหรับการก้าวไปข้างหน้า

• คุณได้อ่านตอนที่ 1ของซีรีส์แล้ว
• คุณคุ้นเคยกับกรอบ/วิธีการที่เราสำรวจด้านล่างโดยดูลิงก์วิดีโอที่แชร์ในตอนที่ 1

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

ระบุปัญหาที่เรากำลังแก้ไขและเพื่อใคร

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

ข้อจำกัดความรับผิดชอบ

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

อีฮาร์โมนี

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

เชื้อจุดไฟ

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

บัมเบิล

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

eTumble — ใหม่!

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

แนวทางปฏิบัติของ Lean Startup แนะนำให้ดำเนินการเหมือน "การทดลองครั้งยิ่งใหญ่" โดยตั้งสมมติฐานที่ชัดเจนจากนั้นสังเกต (ไม่ถาม)พฤติกรรมของผู้ใช้ ในขณะที่ทำซ้ำอย่างรวดเร็ว บ่อยครั้งที่เราล้างความคิดโดยใช้ผืนผ้าใบ "แบบลีน" แต่เราจะถือว่าทีมของเราได้ดำเนินการข้างต้นแล้ว มาเริ่มกันเลย!

โดยเริ่มจากวิสัยทัศน์และกลยุทธ์

การวิเคราะห์ SWOT

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

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

กำหนดแผนกลยุทธ์เบื้องต้นโดยใช้ OGSM

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

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

ยัน UX

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

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

“เราเชื่อว่า [ผู้ใช้หลายล้านคน] จะเข้าร่วมบริการของเราหาก [ผู้หญิง] [รู้สึกปลอดภัยกว่าที่จะมีปฏิสัมพันธ์] กับ [เฉพาะที่พวกเขาเลือกที่จะเริ่มการสนทนาหลังการแข่งขัน]”

สิ่งนี้แปลอย่างหลวม ๆว่า "เราเชื่อว่า [ผลลัพธ์ทางธุรกิจ] จะสำเร็จได้หาก [ผู้ใช้] ได้รับ [ประโยชน์] ด้วย [คุณสมบัติ]" ตามที่อธิบายไว้ใน Lean UX canvas บางครั้งฉันแลกเปลี่ยนรูปแบบนี้กับรูปแบบอื่นที่กำหนดไว้ในหลักการ Agile ของ “การค้นพบผลิตภัณฑ์” แต่หลักฐานเหมือนกัน นั่นคือ การ สื่อสาร ที่มีโครงสร้าง

คุณสามารถดูลักษณะการวนซ้ำของวิธีการเหล่านี้ได้เมื่อคุณรวมเข้าด้วยกัน หากคุณยังไม่ได้ดู เราขอแนะนำให้คุณดูวิดีโอเกี่ยวกับ Lean UX ในตอนที่ 1 ของซีรีส์นี้

ออกแบบผลิตภัณฑ์

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

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

เราไม่จำเป็นต้องมีคุณลักษณะทั้งหมดที่มีอยู่ใน OGSM ของเราทันทีเพื่อทดสอบทฤษฎีของเรา แต่ตอนนี้มีความเข้าใจแบบองค์รวมว่าเรากำลังมุ่งหน้าไปที่ใด ต่อไป เราจะจัดลำดับความสำคัญของสิ่งที่ MVP ของเราต้องนำเสนอเพื่อเพิ่มมูลค่าสูงสุดแก่ผู้ใช้ ในขณะที่เราทำซ้ำอย่างรวดเร็วหลังจากนั้น สำหรับสิ่งนี้ เราจะใช้ประโยชน์จากUser Story Mapping

การทำแผนที่เรื่องราวของผู้ใช้

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

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

สถาปัตยกรรมแบบจำลอง C4

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

เพื่อความกระชับของบทความนี้ เราจะแสดงตัวอย่างบางส่วนของสถาปัตยกรรมของเราสำหรับ eTumble แม้ว่าจะมี 4 ระดับถึง C 4การปฏิบัติมาตรฐานคือการอธิบายให้ลึกเท่าที่จำเป็นเท่านั้น ระดับ "รหัส" ซึ่งโดยปกติจะเป็นสัญกรณ์ UML จะถูกข้ามไป

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

บ่อยครั้งที่ฉันจะเริ่มร่างแนวคิดบนกระดาษเพื่อคิดผ่านการออกแบบ เมื่อมีความคิดทั่วไปเกี่ยวกับสิ่งที่จำเป็นแล้ว ฉันจะแสดงรายการองค์ประกอบของสถาปัตยกรรมเพื่อล้างรายละเอียด ตัวอย่างเช่น เรารู้ว่าเราต้องการฐานข้อมูล แต่กลยุทธ์ของเราเกี่ยวข้องกับการเล่นทั่วโลก เราจำเป็นต้องตัดสินใจว่าจะเริ่มด้วย Postgres หรือ MySQL สำหรับการเปิดตัว และอาจยากเพียงใดในภายหลังในการโยกย้ายไปยังระบบแบบกระจายเช่น Cockroach DB หรือ Cloud Spanner ของ GCP

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

ในบางแอป คุณสามารถคัดลอก/วางได้เหมือนในIcePanelที่แสดงด้านล่าง มีการรองรับ Markdown ซึ่งจะเร็วยิ่งขึ้นเมื่อคุณคุ้นเคย

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

ปรับขนาดสิ่งต่าง ๆ ขึ้น

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

• แกน x ของเรา ( ทำซ้ำและปรับขนาดออก ) รองรับโดยแอปพลิเคชันไร้สถานะ คอนเทนเนอร์ และการโฮสต์บนคลาวด์สาธารณะ
• แกน y ( เฉพาะทาง ) ของเรารองรับโดยไมโครเซอร์วิสที่สร้างขึ้นตามวัตถุประสงค์ ซึ่งเรียกใช้โดย HTTP/RPC หรือโดยข้อความ Pub/Sub สิ่งเหล่านี้ยังช่วยกำหนดว่าคุณจะขยายทีมของคุณอย่างไร ปล่อยให้อิสระและการมีเพศสัมพันธ์แบบหลวม ๆ เพื่อเป็นเจ้าของส่วนสำคัญในระบบ สิ่งนี้มักจะสอดคล้องกับ UX พื้นฐานที่แสดงในแผนที่เรื่องราว
• แกน z ของเรา ( แยกสิ่งที่คล้ายกัน ) รองรับโดยการแบ่งตามภูมิภาค เราไม่ได้กล่าวถึงเรื่องนี้อย่างครบถ้วนในตัวอย่างที่สมมติขึ้นของเรา สมมติว่าได้รับกลยุทธ์ระดับโลกที่ข้อจำกัดด้านเขตอำนาจศาลเกี่ยวกับระบบและอธิปไตยของข้อมูล สกุลเงินต่างประเทศ ภาษา และกลยุทธ์ช่องทางการขายสู่ตลาด (GTM) ในอนาคตอาจมีอิทธิพลต่อวิธีที่เราปรับขนาดแกนนี้ อาจขึ้นอยู่กับตำแหน่งที่เราค้นหา/จัดหาผู้มีความสามารถสำหรับทีมของเรา หรือแม้แต่ตามที่ "Team Topologies" อธิบาย ภาระทางความคิดของทีม

สิ่งที่เราได้เรียนรู้และสร้างมาจนถึงปัจจุบัน:

เวลาที่ใช้ในการออกแบบ eTumble การเริ่มต้นหาคู่ออนไลน์ที่สมมติขึ้นของเรา:

• ยัน [เริ่มต้น | UX] canvas — เราไม่ได้อธิบายไว้ แต่โดยปกติแล้วนี่คือจุดที่คุณต้องเริ่มเขียนว่าคุณกำลังแก้ปัญหาอะไร คุณกำลังแก้ปัญหาเพื่อใคร และประโยชน์/คุณค่าที่คุณมอบให้ คุณอาจตรวจสอบความคิดของคุณด้วย "Smokescreen MVP" และหน้า Landing Page เป็นต้น ดูวิดีโอในส่วนที่ 1เพื่อเรียนรู้เพิ่มเติม
• การวิเคราะห์ SWOT — เราระบุข้อดีที่เราต้องการใช้ประโยชน์ และข้อเสียที่เราต้องแก้ไข โดยแจ้งแผน OGSM ของเรา (30 นาที คาดว่าหลายชั่วโมง)
• แผน OGSM — เราได้ระบุฟีเจอร์หลัก เทคโนโลยี ตัวชี้วัด และทีมที่เราต้องใช้ในการดำเนินกลยุทธ์ของเรา โดยแจ้งแผนที่เรื่องราวของเรา (1 ชม. คาดว่า 1-2 วัน)
• แผนที่เรื่องราว — เราจัดระเบียบและจัดลำดับความสำคัญของเรื่องราวของผู้ใช้ ระบุผู้สมัคร MVP ของเรา แจ้งสถาปัตยกรรมแบบองค์รวม ของเราดังที่แสดงไว้ด้านบน (3 ชม. คาดว่า 1-2 วัน)
• สถาปัตยกรรมโมเดล C4 — เราระบุระบบ ฐานข้อมูล และส่วนประกอบที่จำเป็น โดยแจ้งโครงสร้างพื้นฐานที่จำเป็น (3 ชม. คาดว่า 2-5 วัน)

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

การลงทุนครั้งนี้เพื่อทำงานร่วมกันและจดบันทึกสิ่งต่างๆ ยังลดความซับซ้อนของกระบวนการออกแบบโครงสร้างพื้นฐานระบบคลาวด์ ที่เก็บซอร์สโค้ด และการตรวจสอบ/เมตริกที่เราต้องการเพื่อรองรับ eTumble ในที่สุด เราจะสำรวจสิ่งนี้และอีกมากมายในตอนที่ 3 ของซีรีส์นี้

ขอขอบคุณที่อ่านจนถึงตอนนี้ และผมหวังว่าคุณจะสนุกกับการเจาะลึกทางเทคนิคมากขึ้นใน ตอน ที่3