Câu nói đó đã mất nhiều năm tôi mới thực sự tin vào nó.
Tôi từng ngồi trong những cuộc họp nơi chính sản phẩm của mình được đem ra thảo luận, gật gù trong khi các kỹ sư nói về API, cấu trúc cơ sở dữ liệu và quy trình triển khai. Tôi hiểu có lẽ khoảng một phần tư những gì họ nói. Ba phần tư còn lại nghe chẳng khác nào một ngoại ngữ được nói với tốc độ cao.
Và trong một thời gian dài, tôi cho rằng khoảng cách đó có nghĩa là mình không đủ khả năng để chỉ đạo dự án.
Đây là điều tôi phải trả giá mới học được: khoảng cách đó là hoàn toàn bình thường, và nó không phải thứ khiến các dự án thất bại. Thứ khiến dự án thất bại là giả vờ như khoảng cách đó không tồn tại.
Nếu bạn là một nhà sáng lập không chuyên về công nghệ đang đọc bài viết này, có lẽ bạn đã quá quen với cảm giác đó. Ai đó yêu cầu bạn viết đặc tả sản phẩm, và bạn nhận ra mình thậm chí không thể mô tả điều mình muốn bằng chính hệ từ vựng mà họ sử dụng.
Hoặc bạn nhận được một timeline với những thuật ngữ như “sprint” và “milestone”, nhưng không có cách nào để biết liệu timeline đó có thực tế hay không.
Hoặc bạn phê duyệt một giai đoạn công việc, rồi ba tuần sau không thể xác định liệu thứ đội ngũ bàn giao có đúng với những gì bạn yêu cầu hay không, đơn giản vì bạn không chắc mình phải đánh giá nó như thế nào.
Không điều nào trong số đó có nghĩa là bạn không đủ năng lực để điều hành công ty.
Nó chỉ có nghĩa là bạn không phù hợp để giả vờ mình là một developer.
Hai chuyện đó hoàn toàn khác nhau, và giữ chúng tách biệt là một trong những thói quen hữu ích nhất mà tôi từng học được.
Hãy để tôi giải thích cách sự phân tách đó vận hành trên thực tế khi bạn hợp tác với một đội ngũ outsourcing như DevVina, bởi tôi cho rằng cách bạn nhìn nhận vấn đề quan trọng hơn rất nhiều so với việc sử dụng công cụ nào.
Đầu tiên, hãy ngừng cố gắng chuyển tầm nhìn của bạn thành các yêu cầu kỹ thuật.
Đó không phải công việc của bạn, và khi cố làm điều đó, phần lớn thời gian bạn sẽ làm không tốt.
Bạn sẽ dùng những cụm từ như “chúng ta cần một nền tảng có khả năng mở rộng” chỉ vì đã nghe chúng ở đâu đó. Những người ở phía bên kia sẽ lịch sự ghi lại câu đó, rồi tất cả mọi người sẽ nghĩ rằng một quyết định đã được đưa ra, trong khi thực tế chẳng có gì được quyết định cả.
Thay vào đó, hãy mô tả kết quả bạn muốn bằng ngôn ngữ đời thường.
Người dùng cần có thể làm gì, từ thời điểm họ truy cập cho đến khi họ rời đi với cảm giác hài lòng?
Vấn đề nào trong cuộc sống hằng ngày của họ sẽ biến mất?
Thành công trông như thế nào theo cách mà bạn có thể giải thích cho một người bạn trong lúc uống cà phê?
Mô tả đó là điểm khởi đầu tốt hơn rất nhiều so với một danh sách các thuật ngữ kỹ thuật mà bạn chỉ nhớ mang máng.
Một đối tác tốt sẽ giúp bạn chuyển những điều đó thành ngôn ngữ kỹ thuật. Họ đặt ra những câu hỏi mà bạn thậm chí chưa biết mình cần phải hỏi. Và họ sẽ phản biện khi mong muốn được diễn đạt bằng ngôn ngữ đời thường của bạn hàm ý một thứ gì đó đắt đỏ hoặc dễ phát sinh vấn đề.
Sự phản biện đó là một món quà, không phải trở ngại.
Nó cho thấy họ thực sự đang suy nghĩ về dự án của bạn thay vì chỉ đơn giản là gửi hóa đơn.
Thứ hai, hãy học cách nhìn timeline với một chút hoài nghi.
Các dự án outsourcing thường thất bại vì kỳ vọng chứ không phải vì code.
Code hoặc được viết, hoặc không được viết. Và khi nó không được viết, nguyên nhân gần như luôn là vì phạm vi công việc chưa bao giờ được xác định rõ ràng.
Vì vậy, trước khi ký bất cứ thứ gì, hãy hỏi rõ những gì được bao gồm và những gì không.
Hãy hỏi điều gì sẽ xảy ra khi bạn thay đổi quyết định giữa chừng, bởi bạn sẽ thay đổi, và giả vờ rằng mình sẽ không thay đổi là một sai lầm tốn kém.
Một ví dụ cụ thể.
Bạn yêu cầu một hệ thống đăng nhập.
Trong đầu bạn, điều đó có nghĩa là một ô nhập email, một ô nhập mật khẩu và một nút bấm.
Trong đầu một developer, nó có thể bao gồm quy trình đặt lại mật khẩu, quản lý phiên đăng nhập, giới hạn số lần thử, khôi phục tài khoản và có thể cả xác thực hai yếu tố nếu người dùng của bạn quan tâm đến bảo mật.
Không ai trong hai người sai.
Chỉ là hai bên đang mô tả những tầng khác nhau của cùng một thứ.
Một đội ngũ giúp bạn hiểu rõ khoảng cách đó trước khi bắt đầu là một đội ngũ mà bạn có thể hợp tác lâu dài.
Thứ ba, hãy cảm thấy thoải mái khi đóng vai trò Product Owner thay vì Tech Lead.
Bạn quyết định điều gì quan trọng và thứ tự ưu tiên của nó.
Họ quyết định cách xây dựng nó.
Khi hai vai trò này bị trộn lẫn, bạn sẽ thấy những nhà sáng lập cố micromanage các buổi code review mà họ không thể hiểu, trong khi các developer âm thầm đưa ra những quyết định về sản phẩm vốn đáng lẽ phải thuộc về bạn.
Hãy giữ ranh giới rõ ràng và mọi thứ sẽ vận hành trơn tru hơn rất nhiều.
Điều đó có nghĩa là bạn cần tập nói:
“Tôi không hiểu điều đó, hãy giải thích theo một cách khác.”
Những lần đầu tiên nói câu này cần một chút can đảm, bởi bạn lo rằng nó khiến mình trông yếu thế.
Không phải vậy.
Nó khiến bạn trông giống một người đủ quan tâm để thực sự hiểu mình đang trả tiền cho điều gì.
Mọi người có chuyên môn kỹ thuật mà tôi từng làm việc cùng đều tôn trọng câu hỏi đó hơn rất nhiều so với một cái gật đầu giả vờ hiểu.
Thứ tư, hãy lên kế hoạch cho phần bảo trì mà bạn chưa nghĩ đến.
Rất nhiều nhà sáng lập hình dung phần mềm như một sản phẩm chỉ cần xây dựng một lần.
Bạn trả tiền một lần, nhận sản phẩm, rồi chuyển sang việc khác.
Thực tế là phần mềm là một thứ sống.
Nó cần máy chủ, các bản cập nhật, bản vá bảo mật và một người xử lý khi cổng thanh toán thay đổi quy định.
Hãy đưa những khoản này vào ngân sách ngay từ đầu, nếu không bạn sẽ bị động sau sáu tháng.
Có một sự đánh đổi mà tôi không thấy nhiều người thẳng thắn thừa nhận.
Outsourcing hoạt động phát triển có nghĩa là bạn không sở hữu đội ngũ theo cách bạn sẽ sở hữu nếu tuyển người in-house.
Những người xây dựng phiên bản đầu tiên có thể không phải là những người bảo trì sản phẩm sau này, và việc bàn giao đó có chi phí.
Một đối tác tốt sẽ quản lý việc này hiệu quả thông qua tài liệu đầy đủ và chia sẻ bối cảnh.
Nhưng đó vẫn là một chi phí có thật, và bạn nên biết nó tồn tại ngay từ đầu thay vì chỉ phát hiện ra sau này.
Đổi lại, bạn có được sự linh hoạt.
Bạn có thể tăng quy mô đội ngũ khi chuẩn bị ra mắt và thu gọn khi bước vào một quý ít việc mà không phải đối mặt với cảm giác áy náy và thủ tục phức tạp của việc sa thải nhân sự.
Bạn có thể tiếp cận những kỹ năng mà mình sẽ không bao giờ tuyển full-time, chẳng hạn như chuyên gia về một framework cụ thể hoặc chuyên gia đánh giá bảo mật.
Và bạn có thể bắt đầu nhanh hơn, vào đúng giai đoạn mà tốc độ quan trọng nhất — khi bạn vẫn đang kiểm chứng xem liệu có thực sự có người muốn sử dụng thứ mình đang xây dựng hay không.
Bây giờ, hãy để tôi nói thẳng về những gì DevVina làm tốt trong mô hình hợp tác này, dựa trên cách công ty định vị dịch vụ của mình và cách một đối tác outsourcing tốt nên vận hành.
DevVina hoạt động như một phần mở rộng của đội ngũ thay vì một “hộp đen” nhận yêu cầu rồi ném code qua một bức tường.
Sự khác biệt đó cực kỳ quan trọng đối với một nhà sáng lập không chuyên về công nghệ, bởi nó có nghĩa là bạn luôn có một con người để trao đổi về ưu tiên, rủi ro và những đánh đổi trong suốt dự án, chứ không chỉ nói chuyện với họ ở đầu và cuối dự án.
Hệ quả thực tế là bạn nên phỏng vấn đội ngũ theo cách bạn sẽ phỏng vấn một co-founder, bởi ở một khía cạnh rất thực tế, họ chính là người đồng hành với bạn trong việc biến ý tưởng thành sản phẩm.
Hãy hỏi họ xử lý các yêu cầu chưa rõ ràng như thế nào.
Hãy hỏi lần gần nhất một khách hàng thay đổi hướng đi giữa chừng trong quá trình xây dựng sản phẩm, họ đã xử lý ra sao.
Hãy hỏi ai là người bạn thực sự sẽ trao đổi hằng tuần và liệu người đó có thể giải thích các quyết định kỹ thuật bằng ngôn ngữ đời thường hay không.
Câu trả lời cho những câu hỏi đó cho bạn biết nhiều hơn bất kỳ portfolio nào.
Bạn cũng nên hỏi về quy trình trước khi hỏi về giá.
Giá cả rất quan trọng, nhưng một đội ngũ có quy trình rõ ràng sẽ khiến bạn tốn ít tiền hơn về lâu dài so với một đội ngũ giá rẻ nhưng không có quy trình.
Bởi đội ngũ giá rẻ sẽ tiêu tốn thời gian của bạn vào những hiểu lầm và việc làm lại.
Thời gian là nguồn lực duy nhất bạn không thể mua lại.
Hãy để tôi phác thảo một hình dung cơ bản về một lần hợp tác đầu tiên lành mạnh, để bạn có một tiêu chuẩn tham chiếu.
Nó bắt đầu bằng một giai đoạn discovery, nơi bạn nói chuyện chứ chưa viết code.
Đội ngũ tìm hiểu thị trường, người dùng và các giới hạn của bạn.
Sau đó, họ đưa ra một đề xuất trong đó diễn đạt lại mục tiêu của bạn bằng ngôn ngữ của chính họ, và bạn kiểm tra xem cách diễn đạt đó có thực sự phản ánh điều bạn muốn hay không.
Nếu không, hãy sửa lại trước khi bất kỳ công việc thực tế nào bắt đầu.
Giai đoạn này nên có chi phí vừa phải và mang tính hợp tác, chứ không nên có cảm giác như một buổi chào hàng.
Chỉ sau đó các giai đoạn xây dựng thực tế mới bắt đầu, và ngay cả khi đó, chúng cũng nên khởi đầu từ quy mô nhỏ.
Một phiên bản đầu tiên tập trung vào tính năng cốt lõi, chứ không phải toàn bộ tầm nhìn lớn lao.
Bạn thử nghiệm nó với người dùng thật.
Bạn tìm hiểu xem họ thực sự sử dụng sản phẩm như thế nào — và điều đó gần như không bao giờ giống hoàn toàn với những gì bạn dự đoán.
Sau đó, bạn tiếp tục cải tiến.
Nghe có vẻ chậm, nhưng đây lại là cách nhanh nhất để xây dựng một thứ mà mọi người thực sự sử dụng, bởi nó ngăn bạn dành hàng tháng để trau chuốt những tính năng chẳng ai cần.
Tôi từng mắc sai lầm khi bỏ qua phiên bản đầu tiên nhỏ gọn đó vì nó có vẻ quá khiêm tốn so với tham vọng của mình.
Tôi muốn có sản phẩm hoàn chỉnh hoặc không có gì cả.
Kết quả là một quá trình xây dựng kéo dài, một hóa đơn lớn và một lần ra mắt cho thấy toàn bộ giả định ban đầu thực ra đã sai một chút.
Đội ngũ không có lỗi.
Họ đã xây dựng đúng thứ tôi yêu cầu.
Chỉ là tôi đã yêu cầu sai thứ, và tôi yêu cầu quá nhiều thứ cùng một lúc.
Nhỏ nhưng thực tế luôn thắng lớn nhưng chỉ tồn tại trong tưởng tượng.
Vì vậy, nếu bạn đang đọc bài viết này và có một ý tưởng đã ấp ủ từ lâu, rào cản có lẽ không nằm ở ý tưởng.
Nó nằm ở cảm giác rằng bạn không thể biến ý tưởng thành hiện thực vì bạn không thể tự xây dựng nó.
Cảm giác đó hoàn toàn dễ hiểu, nhưng nó cũng có thể được tháo gỡ.
Bạn không cần phải trở thành một developer.
Bạn cần trở thành một người biết cách lựa chọn và sử dụng dịch vụ phát triển phần mềm tốt hơn — và đó là một kỹ năng bạn có thể học ngay trong quá trình làm việc, từng cuộc trò chuyện một.
Hãy bắt đầu bằng việc viết ra những gì người dùng cần có thể làm, bằng những câu mà một đứa trẻ mười hai tuổi cũng có thể hiểu.
Sau đó, hãy tìm một đối tác mà bạn có thể nói chuyện một cách thẳng thắn, thừa nhận những điều mình chưa biết và để họ gánh phần trách nhiệm kỹ thuật trong khi bạn tập trung vào tầm nhìn.
Sự phân chia công việc đó không phải là một sự thỏa hiệp.
Đó chính là cách để một nhà sáng lập không chuyên về công nghệ có thể thực sự xây dựng phần mềm.
Nếu bạn muốn xem một mối quan hệ hợp tác như vậy diễn ra trên thực tế như thế nào, DevVina có những người có thể hướng dẫn bạn từng bước mà không khiến bạn cảm thấy mình ngốc nghếch chỉ vì không biết các thuật ngữ chuyên ngành.
Điều đó quan trọng hơn bất kỳ framework hay ngôn ngữ lập trình nào.
Hãy bắt đầu bước đầu tiên khi bạn sẵn sàng, và hãy nhớ rằng bạn không cần hiểu động cơ để lái một chiếc xe.
Bạn chỉ cần biết mình muốn đi đâu và thành thật về những điều mình chưa biết trên hành trình.
Hãy xem cách chúng tôi hợp tác trên website và mang theo ý tưởng ban đầu của bạn, đúng như những gì nó đang có.
#nontechnicalfounder #softwareoutsourcing #devvina #startuplife
