10 bước để tạo MVP trong 6 tuần.

Hành trình khởi nghiệp.

Một startup là một điều rất khó để làm. Về cơ bản, vì bạn phải làm nhiều việc khác nhau cùng một lúc: trường hợp kinh doanh, tiếp thị, cao độ, nghiên cứu thị trường, thiết kế, nghiên cứu đối thủ, giấy tờ pháp lý, rất nhiều giao tiếp và trò chuyện, tìm kiếm tài năng. Nhiệm vụ dễ dàng hơn rất nhiều nếu bạn có một nhóm xuất sắc, có thể tổ chức và phân phối các nhiệm vụ như một nhóm có hiệu suất cao. Nhưng ngay cả đối với một nhóm các đồng nghiệp đam mê và phối hợp hoàn hảo, đó là một điều cực kỳ khó để làm (tôi sẽ nói rằng gần như không thể làm cho đúng!).

Hành trình càng trở nên thách thức hơn nếu bạn siêu chặt chẽ với tiền bạc và tài nguyên. Mọi thứ nên được thực hiện nhanh chóng và nó nên được thực hiện với một lần bắn, không có cơ hội cho sai lầm. Nghe có vẻ như một cuộc phiêu lưu tuyệt vời, phải không? Đó là lý do tại sao nó rất xứng đáng khi niềm đam mê và sự kiên trì đạt được kết quả.

MVP

MVP là Sản phẩm có giá trị tối thiểu, một số người gọi nó là Sản phẩm khả thi tối thiểu và thông minh về mặt cảm xúc trong số chúng tôi gọi nó là MLP, Sản phẩm đáng yêu tối thiểu, cho câu chuyện này tôi sẽ sử dụng Sản phẩm có giá trị tối thiểu. Tôi thích tung ra thị trường với một sản phẩm tạo ra giá trị dựa trên nhu cầu thực sự của mọi người - một nơi tốt để xây dựng và phát triển

Ngày nay, mọi người đặt một ý nghĩa khác cho MVP so với những gì Frank Robinson đã định nghĩa ban đầu vào năm 2001 http://www.syncdev.com/minimum-viable-product/.

Một số người thậm chí tin rằng, MVP không còn là trọng tâm thực sự nữa, có lẽ không liên quan:

  • https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02
  • https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-lovitable-51800164ae0c
  • https://blog.leanstack.com/dont-start-with-an-mvp-aa883de5cd18

Nhưng hãy nói rằng, MVP này là sản phẩm ban đầu, tạo ra giá trị hữu hình cho khách hàng của bạn. Nó có thể là một trang web, một whitepaper hoặc một nền tảng phần mềm khổng lồ. Đây là thử nghiệm được cân nhắc kỹ lưỡng nên là một bước tiến vững chắc vào thị trường mà bạn muốn tham gia.

Câu chuyện MVP 6 tuần của chúng tôi!

Tại Madappgang, một ngày nọ chúng tôi gặp một trường hợp thực tế về một nhiệm vụ khởi nghiệp cực kỳ thử thách. ÔngDonnavan doanh nhân, người sáng lập dự án Creator Connect, muốn chúng tôi tạo ra một MVP trong 6 tuần. Mục tiêu của dự án, mang đến cho mọi tài năng nghệ thuật một nền tảng để tạo ra, kết nối và cộng tác chỉ bằng một nút bấm. Dưới đây là các yêu cầu chính:

  • Nó phải là ứng dụng iOS gốc, để phát triển và mở rộng nhanh chóng và dễ dàng sau khi phát hành MVP, thiết kế bao gồm 163 màn hình
  • Nên cung cấp liên lạc nhắn tin thời gian thực
  • Nên có một công cụ kiểm duyệt để kiểm soát và chặn nội dung xấu và người dùng
  • Nên có một luồng thanh toán tích hợp
  • Có thể tạo dữ liệu biểu đồ liên quan với đề cập và hashtag
  • Nó nên được thực hiện và phát hành trong 6 tuần

Bài học kinh nghiệm

Nhiệm vụ này trông giống như một công việc 6 tháng, không phải 6 tuần. Nhưng nếu bạn nhìn vào điểm đầu tiên trong nền tảng của chúng tôi, bạn sẽ hiểu, tại sao nó không ngăn cản chúng tôi. Chúng tôi tin tưởng sâu sắc, rằng không có trường hợp là không thể!

Đúng với niềm tin của chúng tôi, chúng tôi đã làm điều đó. Đó là đáng chú ý khó khăn, rủi ro và thách thức. Và đây là những bài học chúng tôi đã học.

Giao tiếp nhiều

Thoạt nhìn có vẻ là một gợi ý tồi, nhưng thực tế không phải vậy. Thông tin sai lệch là lý do chính cho các dự án thất bại. Giao tiếp đúng trong nhóm là số một và nó cần phải nhanh chóng và hiệu quả. Vì vậy, nó có nghĩa là gì để có giao tiếp tốt? Đầu tiên, CEO / người sáng lập nên là một phần của nhóm. Chúng tôi đang sử dụng phương pháp scrum để di chuyển nhanh và điều phối công việc của mình, vì vậy chúng tôi cần dành thời gian để đảm bảo người sáng lập / người sáng lập hiểu cách Scrum hoạt động. Mọi người có thể nghĩ rằng nó có vẻ dễ dàng: chỉ cần di chuyển các nhiệm vụ theo hàng từ trái sang phải, nhưng vấn đề là Scrum không phải là một cuộc họp hàng ngày, lập kế hoạch chạy nước rút, ước tính nhiệm vụ, cuộc họp hồi cứu, ưu tiên tồn đọng và quan trọng là nhanh chóng cuộc trò chuyện để lái xe vận tốc. Người sáng lập nên ở cùng một trang với mọi người trong nhóm và là Chủ sở hữu sản phẩm thực sự. Chủ sở hữu sản phẩm có vai trò nòng cốt trong quy trình Scrum và để đóng vai trò, Giám đốc điều hành cần hiểu các quy tắc và ý nghĩa của mọi nghi thức. May mắn thay, chúng tôi có một cuốn sách tuyệt vời để giúp chúng tôi điều hướng, một hướng dẫn nhanh chóng và dễ hiểu để đưa những người không có kỹ thuật lên tàu. Nhóm: Nghệ thuật thực hiện hai lần công việc trong một nửa thời gian

Sử dụng công nghệ cho tốc độ

Có hàng tá công nghệ trên thị trường để giúp đẩy nhanh quá trình. Chỉ cần lưu ý, một số giải pháp có thể khó mở rộng sau MVP và một số giải pháp không phù hợp với nhau. Hãy suy nghĩ cẩn thận, đừng lặp lại chính mình vì lợi ích của sự quen thuộc và tương tự, đừng cố gắng phát minh lại bánh xe. Hãy thực tế, hiểu nhu cầu dự án của bạn và lắng nghe kinh nghiệm của nhóm. Các công nghệ chính đã giúp chúng tôi thực hiện dự án này:

  • Ứng dụng AWS, GraphQL
  • S3 với CloudFront
  • AWS lambdas (Golang và Nodejs)
  • Nhận dạng bởi MadAppGang
  • Sự can thiệp

Ưu tiên tồn đọng

Dành thời gian với nhóm và soạn thảo hồ sơ tồn đọng. Backlog là con đường của bạn và là cách duy nhất để đo vận tốc của bạn. Sau 1 lần chạy nước rút, bạn sẽ tìm thấy tốc độ của mình, hiểu vận tốc của mình và sẽ có thể dự đoán các mốc phát hành. Trong trường hợp của chúng tôi, sau lần chạy nước rút đầu tiên, chúng tôi nhận ra rằng chúng tôi cần thêm 2 nhà phát triển để phát hành MVP kịp thời.

Sự hy sinh

Là chủ sở hữu sản phẩm, rất có thể bạn sẽ tin rằng mọi tính năng đều cần thiết, nhiều hơn thế - nhưng tất cả chúng ta đều biết rằng các ứng dụng thành công nhất chỉ cần làm 1 hoặc 2 điều thực sự tốt, ít hơn là nhiều. Hãy sẵn sàng loại bỏ các tính năng không cần thiết cho bản phát hành MVP. Chỉ cần trung thực với chính mình, trung thực về nhu cầu thực sự của khách hàng và lắng nghe nhóm. MVP của bạn không nên hoàn hảo. Bạn càng nhanh nhận được phản hồi từ người dùng của mình, bạn càng có cơ hội làm điều gì đó thực sự có giá trị cho người dùng của mình. Kế hoạch ban đầu của bạn chỉ là dự đoán của bạn về những gì họ cần, thực tế luôn khác. Chúng tôi đã xóa một danh sách lớn các tính năng để thực hiện MVP trong 6 tháng:

  • Không có thanh toán và luồng thanh toán
  • Không có khả năng theo dõi người dùng
  • Đơn giản hóa newsfeed
  • Không có thông báo
  • Đơn giản hóa trên tàu
  • Không có hình ảnh trong các cuộc trò chuyện thời gian thực
  • Không chia sẻ
  • Không xử lý lỗi (người dùng thấy các lỗi thân thiện với nhà phát triển :-))
  • Một quá trình tải lên hình ảnh thực sự đơn giản

Đừng cố chấp

Chúng tôi đã có một kỹ sư QA trong dự án từ ngày 0. Cô ấy đã thực hiện các bài kiểm tra tự động UI, tích hợp liên tục và thực hiện kiểm tra thủ công trên mỗi bản phát hành nội bộ. Thật không may, phần lớn mọi người thường bỏ qua quá trình thử nghiệm cho MVPs. Chủ yếu là vì họ nghĩ rằng, thử nghiệm chỉ là về việc có một ứng dụng cuối cùng không có lỗi. Thực tế là khá khác nhau một chút. Số lần hiển thị đầu tiên được tính. Tham khảo cuốn sách Scrum, có một câu chuyện tuyệt vời về nó.

Tại Nhật Bản, các công ty như Honda, Toyota và Nissan sản xuất một chiếc xe sang trọng trung bình cứ sau 17 giờ. Trong khi đó, các nhà sản xuất xe hơi ở Đức, như Audi, BMW và Mercedes phải mất 57 giờ để tạo ra một chiếc xe sang trọng. Những chiếc xe được sản xuất bởi các nhà sản xuất Nhật Bản trung bình chỉ có 34 lỗi trong mỗi 100 xe trong khi các nhà sản xuất Đức đang tạo ra những chiếc xe có trung bình 78,7 lỗi trên mỗi 100 xe. Sự khác biệt là khi ai đó trên dây chuyền sản xuất của Toyota phát hiện ra lỗi, anh ta sẽ dừng toàn bộ dây chuyền sản xuất và mọi người sẽ cùng nhau khắc phục khuyết điểm đó. Phương pháp này cũng cung cấp phản hồi trực tiếp đến nơi tạo ra khuyết điểm đó và một quy trình có thể được đưa ra để nó không xảy ra lần nữa. Trong khi tại BMW, lỗi được khắc phục trong xe hơi sau khi chúng ra khỏi dây chuyền sản xuất vào cuối. Để sao lưu điều này, Jeff cũng tham khảo nghiên cứu được thực hiện bởi Palm cho thấy rằng nếu một lỗi trong phần mềm được khắc phục sau sáu tuần kể từ khi phát hiện ra, nó sẽ mất thời gian sửa chữa lâu hơn 24 lần so với khi nó được phát hiện tại thời điểm nó được phát hiện .

Bạn phải thành lập một nhóm đầy đủ

Làm việc trong các khung thời gian giới hạn đòi hỏi bạn phải hiệu quả nhất có thể. Có phụ thuộc bên ngoài lãng phí rất nhiều thời gian. Ví dụ: nếu bạn đã có một thiết kế có sẵn, và nhóm đã bắt đầu thực hiện nó. Và sau đó bạn nhận ra mình đang thiếu một màn hình, hoặc bạn cần soạn một phiên bản đơn giản hóa mới của màn hình vì bạn đã tước một số chức năng. Bạn có khả năng có thể bị chặn trong khi bạn đang tìm kiếm nhà thiết kế của mình, người hiện có thể ngoại tuyến trong một kỳ nghỉ ở vùng núi. Vì vậy, hãy nhớ giữ tất cả các đồng đội cùng nhau, ít nhất là trong khi thực hiện MVP!

Hãy sẵn sàng cho kế hoạch B

Con người không phải máy móc. Đừng bỏ tất cả trứng vào một giỏ. Nhà phát triển là người (đôi khi thật khó tin :-)). Họ có thể có một sự thay đổi trong hoàn cảnh cá nhân, họ có thể bị bệnh, v.v. Vì vậy, hãy sẵn sàng kết nối với các nhà phát triển khác như một kế hoạch dự phòng. Tại MadAppGang, chúng tôi cố tình liên quan đến các nhà phát triển thay thế để thực hiện đánh giá mã và ngang hàng mọi lúc. Nó giải quyết được hai vấn đề. Một đánh giá bên ngoài giúp chúng tôi cải thiện mã và dự án. Hơn nữa, nếu nhà phát triển chính không thể làm việc vì một số lý do, nhà phát triển thay thế không yêu cầu thời gian lên tàu. Cô ấy hoặc anh ấy có thể nhảy vào và bắt đầu viết mã ngay lập tức.

Tin vào chính mình

Làm việc trong môi trường căng thẳng có thể gây hại cho sức khỏe tinh thần của bạn. Biết chính mình, hiểu giới hạn của bạn, nhu cầu của bạn và hiểu lãnh đạo. hãy nhớ nếu bạn ngừng tin tưởng vào những gì bạn đang làm, đừng hy vọng phần còn lại của đội sẽ duy trì động lực. Hỗ trợ và giúp đỡ mọi người, là tấm gương tốt cho mọi người, trở thành người lãnh đạo. Bạn có thể đã đọc hoặc ít nhất nghe thấy cuốn sách mang tính biểu tượng này, nó có thể xuất hiện bộ dụng cụ nhưng một số khái niệm đơn giản hoạt động thực sự tốt cho tôi. Tìm nguồn cảm hứng của riêng bạn và giữ nó lên mỗi ngày. Tập thể dục, tắm nước lạnh, ăn uống tốt, thiền, thử các nghi thức biết ơn - họ thật tuyệt vời khi luôn mạnh mẽ khi bị căng thẳng và sống tích cực. Lãnh đạo là một thách thức nhưng đó là cơ hội tuyệt vời để bạn trở thành một người tốt hơn! Làm thế nào để chiến thắng bạn bè và gây ảnh hưởng đến mọi người

Làm việc chăm chỉ

Nghe có vẻ rõ ràng. Nhưng có một số lượng lớn các trường hợp khi các đội (hoặc một phần của đội), giữ nhịp điệu giống nhau, để lưu trữ các kết quả nổi bật. Mọi người trong nhóm nên hiểu, để đạt được kết quả xuất sắc dưới áp lực thời gian lớn như vậy, toàn đội cần phải đồng ý làm việc chăm chỉ ngay từ đầu. Tôi thực sự đánh giá cao đội MadAppGang của chúng tôi, những người đã tình nguyện hy sinh những ngày cuối tuần và thời gian rảnh rỗi, thay đổi lịch trình của họ và thúc đẩy mọi nỗ lực để cung cấp MVP kịp thời. Điều quan trọng là cho phép cân bằng tự nhiên, nhóm của bạn sẽ cảm thấy thoải mái khi họ có thể có thời gian chết sau khi kéo nhau và đẩy mạnh.

Tìm nhà phát triển tốt

Tất cả mọi thứ, chúng ta đang nói ở đây, thực sự chỉ có thể với một nhóm đặc biệt, một nhóm chia sẻ ý tưởng của bạn có một quy trình làm việc tốt và có tinh thần đồng đội thực sự và niềm đam mê cho công việc của họ. Cuối cùng, nếu bạn tạo ra một môi trường làm việc tích cực tốt cho nhóm của mình, bạn tin tưởng mọi người, cung cấp sự linh hoạt, cho phép con người trở thành con người, sau đó những người tốt sẽ đến, cùng nhau tạo dựng, cùng nhau xây dựng và ở lại với nhau. Hãy cho chúng tôi biết về hành trình khởi nghiệp và học hỏi của bạn, bí quyết xây dựng đội ngũ tuyệt vời của bạn là gì?! Vui lòng tham khảo blog của chúng tôi để tìm hiểu thêm về việc chọn một nhóm phát triển tốt.

Đọc thêm những câu chuyện hay trên blog của chúng tôi: https://madappgang.com/blog