Trong phần 1 của loạt bài này , chúng ta đã khám phá các phương pháp và khuôn khổ mà tôi thấy hữu ích trong việc xây dựng và phát triển các công ty khởi nghiệp phần mềm. Mục đích của bài đăng này là để minh họa cách bạn có thể áp dụng các kỹ thuật này để giảm thiểu nỗ lực lãng phí và cách lập kế hoạch cho hoạt động kinh doanh phần mềm chuyển thành cơ sở hạ tầng đám mây của bạn.

Điều kiện tiên quyết để tiến về phía trước

• Bạn đã đọc phần 1 của bộ truyện
• Bạn đã quen thuộc với các khuôn khổ / phương pháp mà chúng tôi khám phá bên dưới bằng cách xem các liên kết video được chia sẻ trong phần 1

Sơ đồ trên minh họa các khái niệm chính của các phương pháp nói trên. Đối với bài đăng này, chúng tôi sẽ có một số niềm vui khi phát minh ra một công ty khởi nghiệp hẹn hò trực tuyến hư cấu và “mở rộng quy mô của nó”. Chúng tôi sẽ minh họa việc áp dụng các nguyên tắc này và mối quan hệ từ chiến lược công ty, đến sản phẩm và nhu cầu tăng trưởng cũng như cách chúng cung cấp thông tin cho thiết kế cơ sở hạ tầng đám mây của chúng tôi.

Xác định vấn đề chúng ta đang giải quyết và cho ai

Giả sử bạn và những người khác đã chán cảnh cô đơn và các giải pháp hiện có không giải quyết được. Bạn đã từng dự đám cưới, thực sự là quá nhiều, bạn đã từng đến các quán bar, thậm chí đã thử các ứng dụng phổ biến nhưng vẫn cảm thấy thiếu thiếu thứ gì đó. Bạn đam mê vấn đề này và tin rằng bạn là đội giúp giải quyết nỗi cô đơn của mọi người, kể cả của chính bạn. Trước tiên hãy phân tích các chiến lược tiềm năng của các giải pháp khác.

từ chối trách nhiệm

Tôi chưa bao giờ sử dụng một ứng dụng hẹn hò trực tuyến nên tôi chỉ “đoán” xem chúng bao gồm những tính năng và chức năng gì. Sử dụng những gì trên truyền hình hoặc trong các tiêu đề về các ứng dụng phổ biến khác nhau, chúng tôi có thể giả vờ xây dựng một đối thủ cạnh tranh. Nếu các giả định của tôi không phù hợp hoặc nếu chúng ta không khám phá mọi loại mối quan hệ, tôi yêu cầu bạn tạm ngừng hoài nghi để minh họa cho các khái niệm này .

eHarmony

Dịch vụ này có một lý thuyết rằng bằng cách kết hợp dựa trên hồ sơ tính cách khoa học, mọi người sẽ cảm thấy ít bị đe dọa hơn. Chiến lược của họ là lấy cá tính làm yếu tố chính, họ sẽ thu hút những người kém tự tin về ngoại hình, những người vẫn còn cô đơn, tận dụng một thị trường chưa được khai thác.

bùi nhùi

Dịch vụ này có lý thuyết rằng nhiều người cô đơn nhưng không tìm kiếm các mối quan hệ lâu dài. Chiến lược của họ là trở thành một sự thay thế cho các kết nối thông thường và chiếm lấy phần thị trường này.

Kêu vo vo

Dịch vụ này có lý thuyết rằng phụ nữ sẽ cảm thấy thoải mái hơn trên nền tảng nếu họ có thể chọn người mà họ tương tác. Chiến lược của họ là để phụ nữ quyết định có gửi tin nhắn đầu tiên sau trận đấu hay không.

eTumble — MỚI!

Giả định của chúng tôi là mọi người đều cô đơn và các giải pháp trên thị trường vẫn chưa giải quyết được sự cô đơn trên phạm vi toàn cầu . Chúng tôi tin rằng giải pháp chiến thắng là sự kết hợp của cả ba giải pháp trên. Trong thâm tâm, chúng tôi nghi ngờ rằng những người tìm kiếm mối quan hệ thông thường sẽ thích có cơ hội kết nối cá nhân sâu sắc hơn thông qua sự phù hợp về tính cách ban đầu, nhưng phụ nữ đưa ra lựa chọn có nên tương tác hay không.

Các phương pháp Khởi nghiệp tinh gọn khuyên bạn nên vận hành giống như một “thử nghiệm lớn”, đưa ra các giả định táo bạo và sau đó quan sát (không hỏi) hành vi của người dùng, đồng thời lặp lại nhanh chóng. Thông thường, chúng tôi đưa ra các ý tưởng bằng cách sử dụng canvas “Lean” , nhưng chúng tôi sẽ cho rằng nhóm của chúng tôi đã thực hiện điều đó ở trên. Bắt đầu nào!

Bắt đầu với một tầm nhìn và chiến lược

phân tích sự làm việc quá nhiều

Bằng cách thừa nhận cả lực lượng bên trong (điểm mạnh, điểm yếu) và bên ngoài (cơ hội, mối đe dọa), bạn có thể tận dụng phân tích SWOT để xác định rõ hơn những gì phải xảy ra để thành công.

Phân tích này cung cấp thông tin cho thiết kế sản phẩm của bạn khi bạn kiểm tra các giả thuyết về cách giải quyết những thăng trầm không thể tránh khỏi. Ví dụ: nếu tỷ lệ người dùng rời bỏ cao là một mối đe dọa, thì bạn có thể ưu tiên các tính năng giúp thu hút mọi người quay lại nền tảng của bạn. Với một điểm yếu là thiếu kinh nghiệm tâm lý trong nhóm, bạn biết đấy khi thuê hoặc thu hút các cố vấn, những người sẽ nhắm mục tiêu. Nếu nhóm có kinh nghiệm hạn chế với các ứng dụng cạnh tranh thì bạn biết nhiệm vụ là sử dụng chúng và hẹn hò — thắng, thắng.

Xác định kế hoạch chiến lược ban đầu bằng OGSM

Ở giai đoạn đầu, mục tiêu của bạn sẽ là nhanh chóng tung ra một sản phẩm khả thi tối thiểu (MVP) để bắt đầu quan sát hành vi của người dùng và thử nghiệm lặp đi lặp lại các giả thuyết. Trong thế giới phần mềm, chúng tôi thường nói đùa rằng nguyên mẫu luôn được đưa vào sản xuất, bất chấp ý định tốt nhất của chúng tôi. Đầu tư một vài ngày để cùng nhóm của bạn động não nhằm ghi lại các chiến lược và biện pháp có thể giảm thiểu việc làm lại và tăng tốc độ thiết kế và phát triển sản phẩm của bạn —hãy cùng khám phá cách thực hiện bên dưới.

Lưu ý trong ví dụ OGSM ở trên, chúng tôi đã bắt đầu xác định các nhu cầu về nhóm, sản phẩm, số liệu và cơ sở hạ tầng trong tương lai của mình. Chúng tôi sẽ cần kiến ​​thức chuyên môn về ứng dụng di động, máy học và phát triển API. Chúng tôi cũng sẽ cần dịch ngôn ngữ, làm xáo trộn văn bản và hình ảnh cũng như chấp nhận thanh toán trực tuyến. Đối với khán giả toàn cầu, chúng tôi cần đáp ứng các yêu cầu về quyền riêng tư và quy định, đặc biệt là ở Liên minh Châu Âu.

Trải nghiệm người dùng tinh gọn

Lean UX được biết đến nhiều hơn trong các nhóm sản phẩm, đó là nơi mà tác giả Jeff Gothelf đã có những khởi đầu khiêm tốn của mình. Tôi tin rằng hiệu quả của việc truyền đạt bất kỳ ý tưởng nào thông qua các tuyên bố giả thuyết sẽ đảm bảo nhận thức được trong toàn tổ chức chứ không chỉ các nhóm sản phẩm. Tôi nghĩ rằng Lean UX thuộc về chiến lược và tầm nhìn và được sử dụng khắp nơi.

Mỗi chiến lược, và sau đó là chiến thuật (tính năng), trong kế hoạch OGSM ở trên về cơ bản là một giả thuyết. Chúng ta càng diễn đạt các ý tưởng của mình theo cấu trúc này, thì chúng càng trở nên khả thi và tập trung hơn. Ví dụ: chiến lược mà chúng tôi sẽ đạt được mục tiêu của mình bằng cách “cung cấp một nơi an toàn hơn để tương tác” có thể được diễn đạt như sau:

“Chúng tôi tin rằng [hàng triệu người dùng] sẽ tham gia dịch vụ của chúng tôi nếu [phụ nữ] [cảm thấy an toàn hơn khi tương tác] với [chỉ họ chọn bắt đầu cuộc trò chuyện sau trận đấu].”

Điều này có nghĩa đại khái là “Chúng tôi tin rằng [kết quả kinh doanh] sẽ đạt được nếu [người dùng] đạt được [lợi ích] với [tính năng].” như được mô tả trong khung vẽ Lean UX. Đôi khi, tôi trao đổi định dạng này với một định dạng khác được xác định trong các nguyên tắc linh hoạt “Khám phá sản phẩm”, nhưng tiền đề là như nhau — giao tiếp có cấu trúc .

Bạn có thể thấy bản chất lặp đi lặp lại của các phương pháp này khi bạn kết hợp chúng. Nếu bạn chưa xem, tôi khuyến khích bạn xem lại các video về Lean UX trong phần 1 của loạt bài này .

Thiết kế sản phẩm

Liên quan đến các nguyên tắc của “Tinh gọn”, một khi bạn có những giả định hoặc giả thuyết táo bạo về vấn đề bạn đang giải quyết, bạn đang giải quyết vấn đề đó cho ai và bạn dự định giải quyết nó như thế nào, bạn phải nhanh chóng lặp lại và kiểm tra chúng.

Thay vì hỏi người dùng, tốt nhất bạn nên quan sát hành vi của họ để xác thực các giả định của mình, đó là lý do tại sao nên khởi chạy MVP. Trong một sản phẩm trực tiếp, bạn cũng có thể tận dụng các công cụ kiểm tra A/B hoặc cờ/chuyển đổi tính năng.

Chúng tôi không cần tất cả các tính năng có trong OGSM ngay lập tức để kiểm tra các lý thuyết của mình, nhưng giờ đây chúng tôi đã có hiểu biết tổng thể về nơi chúng tôi đang hướng tới. Tiếp theo, chúng tôi ưu tiên những gì MVP của chúng tôi phải cung cấp để tối đa hóa giá trị người dùng khi chúng tôi lặp lại nhanh chóng sau đó. Đối với điều này, chúng ta sẽ tận dụng User Story Mapping .

ánh xạ câu chuyện người dùng

Những gì bạn thấy ở trên đã là phiên bản sáu! Bắt đầu với một cái nhìn tổng thể, tôi đã nhanh chóng vạch ra hành trình tổng thể của người dùng. Sau đó, tôi xáo trộn các hộp và sắp xếp lại thứ tự ưu tiên cho các câu chuyện của người dùng để xác định số lượng nhỏ nhất mà chúng tôi có thể phân phối để kiểm tra kết quả mong muốn cho đối tượng mục tiêu.

Khi bạn kiểm tra các giả thuyết trong quá trình thực hiện, bạn sẽ áp dụng các khám phá của mình và tiếp tục chỉnh sửa các “tài liệu sống” này một cách nhanh chóng, thay vì lãng phí thời gian vào các thông số kỹ thuật chi tiết trì trệ.

Kiến trúc mô hình C4

Bây giờ chúng tôi có thông tin để giúp chúng tôi xác định kiến ​​trúc hệ thống và phần mềm của mình, tuy nhiên việc làm như vậy theo cách tiêu chuẩn hóa thường bị bỏ qua. Đảm bảo bạn có kế hoạch (hoặc bản thiết kế) về những gì bạn đang xây dựng để giao tiếp hiệu quả với các bên liên quan khác. Mặc dù UML vẫn là một tiêu chuẩn lâu đời, nhưng Mô hình C4 trọng lượng nhẹ hơn là những gì tôi khuyên dùng ngày hôm nay.

Để bài viết này ngắn gọn, chúng tôi sẽ minh họa một phần ví dụ về kiến ​​trúc của chúng tôi dành cho eTumble. Mặc dù có 4 cấp độ đối với C 4 , nhưng thông lệ tiêu chuẩn là chỉ minh họa sâu theo yêu cầu; mức “Mã” thực sự sẽ là ký hiệu UML thường bị bỏ qua.

Như đã lưu ý trong tuyên bố từ chối trách nhiệm của tôi ở trên, đây là một ứng dụng hư cấu và tôi chưa bao giờ sử dụng dịch vụ hẹn hò trực tuyến nên đây là những phỏng đoán có cơ sở để minh họa quy trình.

Thường thì tôi sẽ bắt đầu phác thảo ý tưởng trên giấy để suy nghĩ về thiết kế. Khi đã có ý tưởng chung về những gì cần thiết, tôi liệt kê các yếu tố của kiến ​​trúc để đưa ra các chi tiết. Ví dụ, chúng tôi biết rằng chúng tôi sẽ cần một cơ sở dữ liệu, nhưng chiến lược của chúng tôi bao hàm một cuộc chơi toàn cầu. Chúng tôi cần quyết định xem chúng tôi có thể bắt đầu với Postgres hay MySQL để khởi chạy hay không và việc di chuyển sang một hệ thống phân tán như Cockroach DB hoặc Cloud Spanner của GCP sẽ khó khăn đến mức nào sau này.

Đôi khi, tôi gặp phải tình trạng “ngăn người viết” khi nhìn chằm chằm vào các ô và dòng trên màn hình, tôi thấy việc sử dụng bảng tính như bên dưới giúp dễ dàng di chuyển nội dung xung quanh hoặc chèn hàng khi tôi nghĩ ra nhiều thứ hơn trước khi lập biểu đồ.

Trong một số ứng dụng, bạn có thể chỉ cần sao chép/dán như trong IcePanel , được hiển thị bên dưới. Có hỗ trợ cho Markdown, thậm chí còn nhanh hơn khi bạn đã quen thuộc.

Hy vọng rằng điều này cho thấy bạn có thể chuyển những gì bạn đã viết ra thành một công cụ lập sơ đồ nhanh như thế nào — chỉ mất chưa đầy một giờ để tạo ra những sơ đồ đẹp mắt. Hãy tưởng tượng việc tương tác với các nhà thiết kế và kỹ sư bằng các thiết kế ở trên và chúng sẽ nhanh hơn (và rẻ hơn) đến mức nào.

Mở rộng mọi thứ lên

Những gợi ý trước đó rằng chúng tôi sẽ “mở rộng quy mô” có nghĩa là chúng tôi dự đoán nhu cầu trong tương lai của mình dựa trên kế hoạch chiến lược và tầm nhìn toàn cảnh của chúng tôi được minh họa trong bản đồ câu chuyện. Tôi đã đề cập đến AKF Scale Cube trước đây và bằng cách áp dụng các nguyên tắc trục xyz của nó, đã kết luận rằng quy mô toàn cầu của chúng tôi và hàng chục triệu người dùng sẽ cần một thiết kế phi trạng thái, hệ thống hướng sự kiện, kiến ​​trúc vi dịch vụ và cuối cùng là nhiều nhóm, với việc lưu trữ mở rộng nhiều vùng địa lý trên nền tảng đám mây công cộng.

• Trục x của chúng tôi ( trùng lặp và mở rộng quy mô ) được cung cấp bởi các ứng dụng không trạng thái, được chứa trong vùng chứa và dịch vụ lưu trữ đám mây công cộng.
• Trục y ( chuyên biệt ) của chúng tôi được cung cấp bởi các vi dịch vụ được xây dựng có mục đích, được kích hoạt bởi HTTP/RPC hoặc bởi thông báo Pub/Sub. Những điều này cũng giúp xác định cách bạn có thể sẽ phát triển các nhóm của mình, cho phép quyền tự chủ và liên kết lỏng lẻo để sở hữu một phần giá trị quan trọng trong hệ thống; điều này thường phù hợp với UX cơ sở được minh họa trong bản đồ câu chuyện.
• Trục z của chúng tôi ( phân chia những thứ tương tự ) được điều chỉnh theo khu vực hóa. Chúng tôi không giải quyết vấn đề này một cách đầy đủ trong ví dụ hư cấu của chúng tôi. Hãy giả sử chiến lược toàn cầu được đưa ra rằng các hạn chế về quyền tài phán đối với hệ thống và chủ quyền dữ liệu, ngoại tệ, ngôn ngữ và các chiến lược tiếp cận thị trường (GTM) của kênh bán hàng trong tương lai đều có thể ảnh hưởng đến cách chúng ta mở rộng trục này. Nó thậm chí có thể dựa trên nơi chúng tôi tìm thấy/đủ khả năng tài năng cho nhóm của mình, hoặc thậm chí như “Cấu trúc liên kết nhóm” mô tả, khối lượng nhận thức của nhóm.

Những gì chúng tôi đã học và xây dựng cho đến nay:

Thời gian dành cho việc thiết kế eTumble, công ty khởi nghiệp hẹn hò trực tuyến hư cấu của chúng tôi:

• Tinh gọn [Khởi nghiệp | UX] canvas — chúng tôi không minh họa nó, nhưng thông thường đây là điểm bạn bắt đầu viết vấn đề bạn đang giải quyết, bạn đang giải quyết cho ai và lợi ích/giá trị bạn mang lại. Ví dụ: bạn có thể xác thực ý tưởng của mình bằng một “MVP màn hình khói” và một trang đích. Xem video trong phần 1 để tìm hiểu thêm.
• Phân tích SWOT — chúng tôi đã xác định những mặt tích cực mà chúng tôi muốn khai thác và những mặt tiêu cực mà chúng tôi cần giải quyết, thông báo cho kế hoạch OGSM của chúng tôi. (30 phút; mong đợi vài giờ)
• Kế hoạch OGSM — chúng tôi đã xác định các tính năng, công nghệ, số liệu chính và nhóm mà chúng tôi sẽ cần để triển khai chiến lược của mình, thông báo bản đồ câu chuyện của chúng tôi. (1 giờ; dự kiến ​​1–2 ngày)
• Bản đồ câu chuyện — chúng tôi đã sắp xếp và sắp xếp thứ tự ưu tiên các câu chuyện của người dùng, xác định ứng cử viên MVP của chúng tôi, thông báo về kiến ​​trúc tổng thể của chúng tôi như minh họa ở trên. (3 giờ; dự kiến ​​1–2 ngày)
• Kiến trúc mô hình C4 — chúng tôi đã xác định các hệ thống, cơ sở dữ liệu và các thành phần cần thiết, thông báo cơ sở hạ tầng cần thiết của chúng tôi. (3 giờ; dự kiến ​​2–5 ngày)

Được thúc đẩy bởi những “tài liệu sống” này, giờ đây nhóm của chúng tôi và các bên liên quan có sự hiểu biết chung về lý do tại sao chúng tôi đang làm những gì chúng tôi đang làm, cách chúng tôi lên kế hoạch để giành chiến thắng (hoặc ít nhất là các lý thuyết để kiểm tra) và những gì chúng tôi sẽ xây dựng để đạt được. giải quyết vấn đề bức tranh lớn.

Việc đầu tư thời gian này để cộng tác và viết ra mọi thứ cũng giúp đơn giản hóa quy trình thiết kế cơ sở hạ tầng đám mây, kho lưu trữ mã nguồn và giám sát/chỉ số mà chúng tôi sẽ cần để cuối cùng hỗ trợ eTumble. Chúng ta sẽ khám phá điều này và hơn thế nữa trong phần 3 của loạt bài này .

Cảm ơn bạn đã đọc đến đây và tôi hy vọng bạn sẽ thích tìm hiểu sâu hơn về kỹ thuật trong phần 3 .