Các công ty khởi nghiệp phần mềm ngày nay có lợi thế đáng kể so với các công ty thậm chí từ 5 đến 10 năm trước, một phần là do sự gia tăng của các nhà cung cấp dịch vụ lưu trữ đám mây siêu quy mô như Google Cloud Platform (GCP), Amazon Web Services (AWS) và Microsoft Azure. Với rất nhiều dịch vụ được quản lý có sẵn chỉ bằng một nút bấm, họ có thể nhanh chóng tạo nguyên mẫu cho giải pháp của mình và đưa nó ra thị trường trong thời gian kỷ lục và ở quy mô gần như vô tận. Mặc dù ngày nay có vẻ đơn giản hơn, nhưng việc chuẩn bị cho một công ty khởi nghiệp mở rộng quy mô trên đám mây vẫn cần được cân nhắc cẩn thận.

Tôi may mắn được là thành viên của nhiều tổ chức công nghệ khác nhau trong hơn 20 năm, từ các công ty khởi nghiệp mới thành lập, đến các công ty được tài trợ bởi quỹ đầu tư mạo hiểm và vốn cổ phần tư nhân, và thậm chí cả các tập đoàn toàn cầu đã IPO. Học hỏi từ rất nhiều người tài năng và những người cố vấn trong suốt chặng đường, tôi “nhặt nhạnh” những bài học kinh nghiệm, công cụ, kỹ thuật và quy trình để thực hiện.

Trong một nỗ lực để "trả nó về phía trước", tôi muốn chia sẻ một số bài học kinh nghiệm. Bài viết đầu tiên trong loạt bài này sẽ giới thiệu các khái niệm và tài nguyên mà tôi thấy hữu ích cho việc xây dựng và mở rộng quy mô khởi động phần mềm. Trong bài viết thứ hai , chúng tôi sẽ thiết kế một công ty khởi nghiệp hẹn hò trực tuyến hư cấu để minh họa cách những phần này khớp với nhau. Trong bài viết thứ ba , chúng tôi minh họa cách cuối cùng chúng cung cấp thông tin cho kiến ​​trúc đám mây của bạn bằng GCP.

• Phần 1: giới thiệu cơ sở và phương pháp luận
• Phần 2: triển khai các phương pháp với khởi động hư cấu
• Phần 3: thiết kế và mở rộng cơ sở hạ tầng đám mây

Đầu năm 2020, tôi quyết định thử một cái gì đó mới; thay vì xây dựng và phát triển các công ty khởi nghiệp phần mềm, tôi bắt đầu tư vấn và hỗ trợ họ bằng cách tham gia một đối tác đám mây có nguồn gốc từ Israel tên là DoiT International . Công ty của chúng tôi hoạt động hoàn toàn từ xa và kể từ đó đã phát triển từ khoảng 50 người lên gần 500 người trên toàn cầu chỉ trong hơn hai năm, hỗ trợ hơn 1 tỷ USD cho mức tiêu thụ đám mây hàng năm. Tôi luôn kinh ngạc về việc chúng ta đã bảo tồn văn hóa của mình tốt như thế nào thông qua tốc độ phát triển nhanh chóng như vậy trong khi thu hút và giữ chân rất nhiều người tài.

Hàng nghìn tổ chức chọn DoiT làm đối tác dịch vụ đám mây của họ. Họ được hưởng lợi từ dịch vụ tư vấn và hỗ trợ miễn phí cũng như công cụ phần mềm hiện đại được thiết kế để thực hiện đúng lời hứa ban đầu về đám mây — tập trung vào sản phẩm và khách hàng của bạn và đừng lo lắng về phần còn lại. Mặc dù chúng tôi muốn nghĩ rằng điều đó thật đơn giản, nhưng điều đó thường xảy ra trước khi khách hàng của chúng tôi có đội ngũ kỹ thuật có tay nghề cao.

Một xu hướng mà tôi đã nhận thấy gần đây là sự tăng trưởng ở các công ty khởi nghiệp phần mềm ở giai đoạn đầu áp dụng công nghệ đám mây, những công ty này có thể không có các nhóm lớn hoặc chuyên môn sâu về đám mây. Bản thân là một doanh nhân phần mềm, tôi hy vọng rằng việc chia sẻ những bài học rút ra từ “kiếp trước” của tôi và tại DoiT sẽ giúp hành trình của bạn thành công hơn nữa.

Những ngày đầu

Rời xa công nghệ một bước, trước tiên chúng ta hãy khám phá hành trình từ việc xác định vấn đề đến xây dựng một công ty chuyên giải quyết vấn đề đó và hơn thế nữa. Có một số phương pháp và khuôn khổ phổ biến ngoài các phương pháp hay nhất về đám mây mà bạn có thể đánh giá cao khi tổ chức của mình trưởng thành.

Bản thân mỗi kỹ thuật được minh họa ở trên đều có tính lặp lại , nhưng như chúng ta sẽ thấy trong phần tiếp theo của loạt bài này, đầu ra của mỗi kỹ thuật sẽ thông báo cho các kỹ thuật khác.

TL;DR; Tài nguyên trực tuyến hữu ích

Thay vì giải thích các kỹ thuật và khái niệm ở trên, tôi khuyên bạn nên xem các video này để điền vào chỗ trống và đóng vai trò là nền tảng để chúng ta áp dụng chúng vào thực tế.

• Tôi có nên xây dựng một công ty khởi nghiệp (14 phút)— Michael Seibel, Y Combinator
• Chiến lược so với lập kế hoạch (9 phút) — HBR [sử dụng kế hoạch 1 trang như OGSM]
• Tóm tắt Khởi nghiệp Tinh gọn (13 phút)— Eric Ries
• Xác thực ý tưởng kinh doanh của bạn (9 phút)— Eric Ries
• Lean UX (60 phút)— Jeff Gothelf
• Sử dụng canvas Lean UX (15 phút)— Jeff Gothelf
• Sản phẩm xây dựng (59 phút)— Michael Seibel, Y Combinator
• Cách lập kế hoạch MVP (13 phút)— Michael Seibel, Y Combinator
• Lập sơ đồ câu chuyện người dùng (50 phút)— Jeff Patton
• Hướng dẫn cơ bản về lập bản đồ câu chuyện người dùng — Nick Muldoon, Easy Agile
• Kiến trúc phần mềm với Mô hình C4 (35 phút)— Simon Brown
• Xây dựng văn hóa thử nghiệm tại Spotify (47 phút)— Ben Dressler
• DevOps vs SRE (44 phút)— Seth Vargo, Google

Khi bạn đã nhận ra một vấn đề mà bạn cảm thấy bắt buộc phải giải quyết, nó sẽ giúp bạn vẽ nên một bức tranh về nơi bạn sẽ đến và một số chỉ số chính mà bạn đang đi đúng hướng để mang lại giá trị. Điều này tương tự như cách Amazon yêu cầu các nhóm soạn thảo thông cáo báo chí mô tả những gì họ sẽ xây dựng trong tương lai, trước khi họ được chấp thuận xây dựng nó.

Khoảng 10 năm trước, trong một buổi lập kế hoạch kéo dài cả ngày, một người cố vấn đã đưa công ty của anh ấy lên sàn chứng khoán và sau đó bán cho Oracle với giá gần 2 tỷ USD, đã giới thiệu cho tôi về Khung OGSM . Nó là viết tắt của Mục tiêu, Mục tiêu, Chiến lược và Biện pháp. Nó buộc bạn phải vẽ ra một bức tranh chính xác về vị trí của bạn trong 3–5 năm tới, một số mục tiêu có thể đo lường được trong quá trình thực hiện, đồng thời đi sâu vào các chiến lược và chiến thuật ngắn hạn để hoàn thành chúng.

Bạn kết thúc với một kế hoạch kinh doanh trên một trang, một tài liệu sống mà bạn xem lại và tinh chỉnh, mà toàn bộ nhóm có thể tập hợp xung quanh và sắp xếp trọng tâm của tất cả các hoạt động. Ví dụ: nếu một số hoạt động không phù hợp với chiến lược được xác định để đạt được mục tiêu, bạn sẽ đặt câu hỏi liệu hoạt động đó có thực sự đáng làm hay không hoặc liệu bạn có cập nhật chiến lược của mình hay không.

Một số người có thể thắc mắc sự khác biệt so với một khung Mục tiêu và Kết quả chính (OKR) phổ biến khác là gì. OGSM hướng tới tương lai nhiều năm, trong khi OKR chủ yếu tập trung vào các mục tiêu ngắn hạn. Tùy thuộc vào giai đoạn của công ty bạn, việc giới thiệu OKR có thể hợp lý, nhưng thường thì một tầm nhìn dài hạn duy nhất mà mọi người có thể tập hợp lại chính là “Sao Bắc Đẩu” cần thiết.

Có nhiều kỹ thuật khác như phân tích SWOT, 5 Lực lượng của Porter, Thẻ điểm Cân bằng hoặc 3 Chân trời của McKinsey, có thể đưa vào kế hoạch chiến lược tổng thể của bạn, nhưng OGSM vẫn là công cụ lựa chọn của cá nhân tôi để thu hẹp sự tập trung của nhóm vào những vấn đề quan trọng và chia sẻ tầm nhìn lớn hơn.

ý tưởng

Các nguyên tắc và quy trình hướng dẫn sớm trong hành trình của bạn có thể giúp gắn kết các nhóm khi bạn phát triển. Tôi tin rằng văn hóa dựa trên dữ liệu và tư duy đo lường mọi thứ phải là một phần trong văn hóa của bạn và phải xuất phát từ cấp cao nhất, và hiển nhiên trong mọi tương tác.

Một số tài nguyên yêu thích của tôi củng cố văn hóa thử nghiệm này bao gồm Khởi nghiệp tinh gọn (và Canvas tinh gọn) của Eric Ries và Lean UX của Jeff Gothelf. Gần như mọi cố vấn và vườn ươm khởi nghiệp đều khuyên các nhà sáng lập đo lường mọi thứ, lặp lại nhanh chóng và xây dựng một sản phẩm khả thi tối thiểu (MVP) để thử nghiệm ý tưởng của họ với thị trường. Tất cả những điều này đều cộng hưởng với các nguyên tắc “Lean”.

Jeff Gothelf áp dụng các nguyên tắc “Tinh gọn” theo hướng mà tôi yêu thích vì nó áp dụng cho mọi nhóm, bộ phận và ý tưởng trong các tổ chức thuộc mọi quy mô. Tiền đề là “chúng tôi không biết gì cả” và để tìm hiểu [khách hàng muốn gì] và điều gì thực sự giải quyết được vấn đề, chúng tôi áp dụng phương pháp khoa học — hình thành tuyên bố giả thuyết, kiểm tra nó trong khi đo lường, phân tích kết quả và điều chỉnh khi cần thiết . Giá trị của phương pháp này là giảm thiểu nỗ lực lãng phí và xác nhận rằng bạn đang giải quyết đúng vấn đề nhanh hơn.

Thiết kế

Khi tôi chứng kiến ​​mọi người bỏ qua việc ghi lại hệ thống và kiến ​​trúc phần mềm của họ, điều đó khiến tôi nhớ đến một người đang cố gắng xây một ngôi nhà bằng một đống gỗ. Chắc chắn cuối cùng bạn có thể tìm ra nó, nhưng bạn sẽ nhanh hơn nhiều với ít sai lầm hơn nếu bạn có một kế hoạch. Hai trong số các kỹ thuật thiết kế sản phẩm yêu thích của tôi bao gồm Lập bản đồ câu chuyện người dùng và Mô hình C4 .

Bằng cách viết ra mọi thứ, bạn đảm bảo sự hiểu biết chung và quy trách nhiệm cho mọi người về việc thực hiện những gì đã thỏa thuận.

Vài năm trước, tôi được mời làm diễn giả cho hội nghị thượng đỉnh CTO hàng năm cho công ty cổ phần tư nhân (PE), Francisco Partners . Tôi đã tham gia các phiên khác và một trong những phiên hấp dẫn nhất là một trong những đối tác tư vấn cho các CTO và giám đốc điều hành danh mục đầu tư khác về việc theo dõi các số liệu trong tổ chức sản phẩm của họ. Một trong những thước đo khiến tôi ngạc nhiên, nhưng bây giờ hoàn toàn có ý nghĩa, là đo lường số lượng công việc làm lại để đánh giá hiệu quả của các nhà quản lý sản phẩm. Kể từ đó, tôi đã hỏi các nhà lãnh đạo kỹ thuật khác xem họ có đo lường việc làm lại hay không và hầu hết đều đánh giá cao điều đó nhưng vẫn chưa làm.

Làm lại là một số liệu quan trọng mà bạn có thể tác động bằng cách dành thời gian để hiểu khách hàng và ưu tiên cung cấp giá trị tức thời nhất cho họ. Đây chính xác là điều mà bài tập ánh xạ câu chuyện người dùng giúp tạo điều kiện thuận lợi trong khi buộc các bên liên quan khác nhau phải hợp tác. Lập luận của tôi cho điều đó, ở bất kỳ giai đoạn nào của công ty, là việc di chuyển xung quanh một vài ô trên bảng trắng dùng chung sẽ rẻ hơn và nhanh hơn nhiều so với việc khởi động các chu kỳ phát triển mà sau đó phải làm lại.

Tôi là người đầu tiên thừa nhận rằng tôi đã có một số sơ đồ kiến ​​trúc xấu xí trong ngày của mình; Tôi đã chứng kiến ​​nhiều hơn thế. Điều quan trọng là dành thời gian để viết ra kiến ​​trúc của bạn và mối quan hệ của nó với các hệ thống khác. Mô hình C4 là một trong những cách tốt nhất để thực hiện điều đó theo cách tiêu chuẩn mà không yêu cầu kiến ​​thức về UML. Như được mô tả trong các liên kết video ở trên, thông lệ tiêu chuẩn là thiết kế sâu tối đa 3 cấp độ (chế độ xem thành phần). Có những sản phẩm như IcePanel giúp việc này trở nên dễ dàng hơn hoặc nhiều plugin hoặc công cụ khác nhau trên các nền tảng khác. Nó nhanh hơn bạn nghĩ, và chúng tôi sẽ minh họa điều này trong phần tiếp theo của loạt bài này.

Xây dựng

Giả sử nhóm của bạn thành thạo trong giai đoạn này. Khi bạn phát triển, việc áp dụng một khuôn khổ được xác định rõ ràng để triển khai các hệ tư tưởng Agile có thể giúp bạn mở rộng quy mô. Nếu bạn tuân theo các nguyên tắc “Tinh gọn” và thay đổi các ưu tiên của mình dựa trên việc học hỏi, thì bạn đã đi đúng hướng. Khi trọng tâm của tổ chức chuyển từ tốc độ và đổi mới sang tăng trưởng và ổn định, hãy chú ý đến các điểm uốn và thành phần nhóm trên đường đi.

vận hành

Cùng với việc hoàn thiện các phương pháp phát triển sản phẩm của mình, bạn cũng sẽ muốn duy trì văn hóa chia sẻ trách nhiệm. Đây là lúc các nguyên tắc DevOps phát huy tác dụng. Google đã chia sẻ việc triển khai DevOps của họ có tên là Kỹ thuật độ tin cậy của trang web (SRE) và nhiều tổ chức đã áp dụng các phương pháp này.

Mặc dù có thể không cần thiết phải có một nhóm hoặc chức năng riêng biệt, nhưng các nhóm nhân sự tối thiểu với các kỹ sư có xu hướng vận hành, giám sát và tự động hóa sẽ mang lại hiệu quả. Chúng ta sẽ khám phá các khái niệm này một cách chi tiết hơn khi tìm hiểu sâu hơn về ví dụ khởi động và xác định kiến ​​trúc cũng như cơ sở hạ tầng đám mây của nó.

Lập kế hoạch tăng trưởng

Khi một công ty khởi nghiệp phát triển vượt ra ngoài nhóm sáng lập nhỏ, thì sự phức tạp của giao tiếp và quản trị cũng tăng theo, như minh họa bên dưới.

Các công ty đã giải quyết những thách thức về quy mô này bằng cách nhận ra các điểm uốn trong hoạt động kinh doanh của họ và thành lập các nhóm tận tâm, chủ yếu là tự chủ để giải quyết những thách thức cụ thể.

Ví dụ, một tài nguyên tuyệt vời để mở rộng quy mô nhóm phần mềm của bạn là bài đăng trên blog này của Seth Blank , mà tôi thực sự khuyên bạn nên đọc. Blank cảnh báo rằng các quy trình, và trong một số trường hợp, ngay cả những người đã giúp đưa công ty khởi đầu vào một thời điểm nào đó có thể trở thành trở ngại cho sự phát triển và khả năng mở rộng trong tương lai của công ty, hoặc tốt nhất là hướng tới “điều tiếp theo”. Đây là nơi 3 Chân trời của McKinsey trở nên phù hợp với việc lập kế hoạch chiến lược trong tương lai. Ngược lại, một Blank khác, Steve Blank, lập luận tại sao ngày nay nó không còn giá trị nữa .

Có một tài nguyên khác gọi là “ Cấu trúc liên kết nhóm ” cung cấp mô hình thích ứng thực tế, từng bước để thiết kế tổ chức và tương tác nhóm. Trọng tâm là hợp lý hóa tổ chức và nền tảng, với những gì họ gọi là nền tảng khả thi mỏng nhất (TVP).

Một khái niệm khác mà tôi thấy hữu ích để mở rộng quy mô tổ chức hoặc sản phẩm là AKF Partners Scale Cube . Lần đầu tiên tôi biết về điều này là nhiều năm trước khi nó được đề cập đến trong một cuốn sách có tựa đề “ Nghệ thuật mở rộng quy mô ” mà tôi đã mua cho các trưởng nhóm của mình khi khởi nghiệp trước đó — đây cũng là một tài liệu tham khảo hữu ích khác bất cứ lúc nào, chuyển sang các chương có liên quan khi cần.

Tuy nhiên, gần như mọi người đều có thể đồng ý rằng khi công ty của bạn tiếp tục phát triển và hình thành các nhóm chuyên dụng, thì nhu cầu về quản trị và các quy trình, tài liệu, cố vấn và đào tạo được xác định rõ ràng cũng tăng theo. Tôi đã chứng kiến ​​nhiều tổ chức ở giai đoạn này gần đây cũng đang tìm kiếm hướng dẫn về cách tốt nhất để cấu trúc cơ sở hạ tầng đám mây của họ nhằm hỗ trợ hiệu quả cho nhiều nhóm của họ. Chúng tôi sẽ giải quyết vấn đề đó sau trong loạt bài này.

Trong phần 2 của loạt bài này , chúng ta khám phá việc kết hợp những phần này lại với nhau để thiết kế, xây dựng và mở rộng quy mô của một công ty khởi nghiệp phần mềm hẹn hò trực tuyến hư cấu.

Cảm ơn bạn đã đọc đến đây, và tôi hy vọng bạn sẽ thích phần 2 .