Những bài học, lời khuyên sáo rỗng

Tầm nửa năm trước, ở công ty, mình được đảm nhận một dự án khá lớn. Cho tới hiện tại, dự án đã hoàn thành được một thời gian và có thể nói rằng:

Nó khá thất bại.

Team của mình đã có một buổi thảo luận để cùng nhau nhìn nhận lại:

- Những điều đã đạt được

- Những điều tốt đã xảy ra

- Những điều chưa tốt đã xảy ra

- Có thể cải thiện như nào

Bởi vì đây là một dự án lớn về việc làm Product vậy nên những điều chưa tốt của dự án đem lại hệ quả khá nghiêm trọng cho toàn bộ phận. Về mặt kết quả, thời gian và công sức bị lãng phí để đổi lại một đầu ra còn không bằng hiện tại.

Trong buổi thảo luận, tụi mình rút ra được những bài học sau:

1. Cần dành nhiều nguồn lực vào giai đoạn định hướng dự án vì định hướng sai là đi hết.

2. Cân nhắc rõ tính đúng đắn của dữ liệu, nếu dữ liệu không phản ánh đúng thì chỉ nên tham khảo chứ không nên dựa hoàn toàn vào nó để quyết định.

3. Đề cao và đẩy nhanh việc xử lý rủi ro thay vì cố gắng nghiên cứu thật kỹ cách thức triển khai vì mình không bao giờ có thể kiểm soát được hoàn toàn kết quả.

Đây là 3 trong nhiều bài học team đã rút ra được từ những không biết bao nhiêu ngày áp lực, thảo luận và nghiên cứu.

Ngày hôm sau, khi nhìn lại những bài học này một lần nữa, mình nhận ra nếu không phải mình mà là người khác thì những bài học này:

Một điều hay bài học sáo rỗng, với mình, nó là những điều mà khi mình đọc hoặc nghe thì sẽ cảm thấy rằng "đương nhiên phải vậy rồi".

Ví dụ:

- "Chăm nhỉ trong công việc sẽ khiến em một ngày thành công"

- "Nên làm đúng việc hơn là làm việc đúng"

Mặc dù 3 bài học mình nói trên nghe rất sáo rỗng tuy nhiên với mình và team, nó lại rất ý nghĩa. Thắc mắc một hồi, mình nhận ra:

Nghe mình kể chuyện xem thấy bài học thuyết phục và có ấn tượng hơn không nhé.

Về lời khuyên đầu - nên tập trung vào phần định hướng.

Ở giai đoạn đầu, sau khoảng 2-3 tuần research, team mình đã đưa ra định hướng X cho sản phẩm. Và sau đó mất 8-12 tuần để triển khai theo định hướng X này.

Giai đoạn đầu team bị giục khá nhiều nên đã phải đẩy nhanh tiến độ research, bỏ qua một số bước mà mình nghĩ là "không quan trọng" để có một đề xuất đủ thuyết phục và triển khai một cách nhanh nhất.

Vậy là với việc rút ngắn 1-2 tuần ở giai đoạn định hướng. Team đã có 8-12 tuần lãng phí của hơn chục người để làm điều không nên làm.

Nếu giai đoạn đầu team có thể đọc nhiều hơn, nói chuyện với user nhiều hơn thì có thể đã chọn được hướng đi đúng hơn và không mất nhiều thời gian để làm điều không nên làm.

---

Về lời khuyên thứ hai - dữ liệu phải uy tín.

Trong ngành IT, ý tưởng mà không có dữ liệu ủng hộ thì đó chỉ là quan điểm cá nhân. Bên cạnh đó, dữ liệu cũng nên đủ lớn để có thể phản ánh đúng hành vi hay cái gì đó bạn đang nghiên cứu.

Hiểu được như vậy nên trong giai đoạn nghiên cứu mình đã cố gắng đưa ra các dữ liệu và mô phỏng để tăng tính thuyết phục của team đề xuất.

Và thực sự, nó nghe rất hợp lý và thuyết phục.

Thuyết phục đến mức team đã bỏ qua một số những lời nhận xét từ người khác về ý tưởng mà tụi mình đề xuất vì tự tin rằng đã có dữ liệu ủng hộ. Ý kiến? Cầm data ra đây mà nói chuyện =))))

Team đã quá phụ thuộc vào sự mô phỏng dữ liệu và đưa ra các con số cho ý tưởng dựa hoàn toàn vào việc mô phỏng - một điều không chắc chắn và bỏ qua các cân nhắc về quan điểm của mọi người và các yếu tố khác.

Có dữ liệu ủng hộ thì cũng ok đấy, nhưng dữ liệu có chuẩn hay không cũng là một điều phải xem xét kỹ trước khi ra những quyết định dựa theo nó.

---

Về lời khuyên thứ ba - phản ứng với rủi ro.

Khi làm sản phẩm với một thị trường rộng, gần như bạn không bao giờ có thể kiểm soát được kết quả của việc bạn làm.

Dù có nghiên cứu kỹ đến đâu, vẫn luôn có rủi ro cho việc kết quả sẽ đi lệch so với những gì bạn mong đợi. Do đó, điều quan trọng là bạn cần phản ứng thật nhanh khi nhận được các tín hiệu bất thường.

Làm về IT, khi dự án hoàn thành thì sẽ đến giai đoạn đưa sản phẩm tới user. Lúc này, hàng nghìn user sẽ thực sự dùng sản phẩm và sẽ có hàng nghìn suy nghĩ khác nhau. Đôi khi, có những suy nghĩ sẽ rất khác với những gì bạn đặt kỳ vọng cho họ.

Team mình đã nghĩ đến tới các rủi ro này. Tuy nhiên, tụi mình lại không đặt ưu tiên thực hiện các đầu việc để việc phản ứng rủi ro một cách nhanh nhất. Do đó, sau khi nhận được tín hiệu xấu từ thị trường, mất đến tận 2 tháng để team có thể đưa lên một giải pháp thay thế.

Trong 2 tháng này, sản phẩm phải đối mặt với sự tụt giảm về user, doanh thu,... Nói chung mất khá nhiều. Nếu thay vì 2 tháng mà là 2 tuần thì mọi chuyện có lẽ đã êm hơn.

Vậy là việc mình cảm thấy sáo rỗng chả qua là mình chưa biết về câu chuyện liên quan tới bài học đó.

Cá nhân mình rút ra được một cách khiến việc học và lắng nghe một cách hiệu quả hơn:

Như cách mình kể về câu chuyện của 3 bài học mình đưa ra ở bên trên.

---

Cảm ơn bạn đã đọc bài viết :)

Mình là Hoàng, có một website cá nhân nho nhỏ ở mankaistep.com viết những điều về công việc và cuộc sống. Bạn rảnh thì có thể ghé qua đọc nhé ^^