08 Kinh nghiệm làm sản phẩm trên Cloud

Với xu hướng chuyển đổi ứng dụng lên Cloud, ngoài việc chuyển đổi các hạ tầng, ứng dụng có sẵn lên cloud thì việc tìm các sản phẩm dịch vụ chạy trên Cloud theo mô hình Software as a Service (SaaS) và trả tiền theo “Xài nhiêu, trả nhiêu” (Pay As You Go). Đây có thể là thiên đường cho các startup công nghệ, cho các bạn developer yêu thích làm sản phẩm… Nhưng thường thì người ta chỉ thấy thiên đường khi đã chết.

Bài này iGà chia sẻ các bài học kinh nghiệm hay các pain points mà các bạn có thể gặp phải trong quá trình làm sản phẩm công nghệ nói chung và sản phẩm đó trên cloud nói riêng. Mong cũng nhận được chia sẻ từ các bạn trong phần comment.

1/ Good thing today is better than perfect tomorrow

Điều đầu tiên và khó khăn nhất của các bạn làm startup về công nghệ đó là đội ngũ tổ chức. Nếu đội ngũ thiên về Tech quá thì luôn nghĩ chuyện gì cũng có thể làm được mà quên đi cái gọi là thị trường. Còn nếu đội ngũ là dân làm Business thì biết thị trường cần gì, ko xem trọng phần Tech nghĩ chuyện gì chỉ cần đầu tư và hoạch định đúng sẽ thành công.

Con người là yếu tố tạo ra sự khác biệt. Khó khăn lớn nhất là có sự đồng lòng (team buy-in) về chung một mục tiêu. Cần có sự rõ ràng ngay từ lúc mới bắt đầu về sự kỳ vọng các bên, về vai trò trách nhiệm, cũng như quyền hạn.

Khi mới bắt đầu đừng có kỳ vọng thứ gì đó hoành trang như rồng như phượng. Có thể nghĩ lớn, một roadmap to đùng, nhưng bắt đầu làm cái gì đó nhỏ và dễ dàng deliver. Từ đó tạo sự tự tin và gắn bó đội ngũ.

Đừng để “giấc mơ con đè nát cuộc đời con” sự kỳ vọng quá hoàn hảo sẽ khiến release chậm và thậm chí ko release ra được. Không có thứ gì là hoàn hảo hết, thậm chí những thiết bị iPhone đầu tiên ra đời cũng bị lỗi về sóng hay facebook còn bị hack lộ hàng triệu mật khẩu người dùng và các mật khẩu này lưu trong cơ sở dữ liệu là plain-text chứ ko phải hash gì cả.

Release fast, fail fast & quick fix, quick win.

Làm về sản phẩm (product development), con người là yếu tố quan trọng, sự ăn ý của đội ngũ là bí quyết thành công. Phương thức tổ chức làm việc dựa trên các vòng lặp sprint của Agile và lấy communication là trọng tâm. iGà

2/ Don’t boil the Ocean

Đây là câu nói của AWS Vietnam Country Manager nói với iGà. Câu này thực sự khiến iGà rất ấn tượng. Trong một bức tranh tổng thể, mình cần định vị mình nằm ở đâu. Khi mình làm tất cả, điều này có thể là mình chẳng làm gì, hoặc là chẳng làm gì ra hồn. Hãy lựa chọn 01 điều gì đó làm thật sắc, thật bén để khi nghĩ đến điều này người ta sẽ nghĩ đến mình đầu tiên.

Định vị là điều tối quan trọng khi bắt đầu làm sản phẩm. Mới bắt đầu bạn không thể vẽ một con khủng long hay chạy 42km marathon, hãy đặt mục tiêu nhưng hành động chọn từng phần, dựa vào kết quả từng chu kỳ ngắn (1 tháng, 1 tuần, hoặc thậm chí từng ngày) để hoạch định tốc độ và fillgap cho các milestone tiếp theo.

Pick one thing, deliver it and elaborate. Communication is a key.

3/ Expect Success, but plan for Failure

Nghe điều này có vẻ nực cười, nhưng kinh nghiệm của iGà đó là mình thường Plan cho toàn các ngữ cảnh tích cực (positive assumptions) mà quên đi rằng thị trường, con người, công nghệ luôn biến đổi. Có một điều chưa bao giờ thay đổi đó là sự thay đổi.

Khi gặp các thay đổi đột suất mà ko có trong sự dự đoán (risk register), với các startup non trẻ dễ bị hoảng loạn, chỉ trích nhau, rồi gây ra sự đổ vỡ. Đây là giai đoạn va chạm quan điểm cá nhân rất nhiều và nếu không thực hiện việc này một cách tốt đẹp thì sẽ ko thực sự xây dựng được điều gì. Mọi thứ sẽ dừng lại.

Hãy luôn có các kế hoạch dự phòng, trong quản lý dự án chuyên nghiệp gọi là Contingency Plan. Hãy thậm chí kết hợp nhiều yếu tố negative assumptions để xem cách thức mình xử lý như thế nào. Từ đó trong thâm tâm mình luôn có sự kỳ vọng và bức tranh thực tế.

Negative thinking in a way of problem solving is a Positivie thinking – iGà

4/ A Goal without plan is just a Wish

Hãy chia nhỏ mục tiêu thành các mục tiêu nhỏ hơn và nhỏ hơn và gán điều đó cho từng con người cụ thể. Luôn motivate team member hiẻu rõ về sứ mệnh bản thân trong bức tranh quan trọng của đội nhóm. Team buy-in là điều cốt lõi của thành công.

Kinh nghiệm của iGà là luôn nhắc lại mục tiêu của cả đội, và nhắc đi nhắc lại mục tiêu từng cá nhân, trong mỗi buổi stand-up meeting với team. Điều này khiến cho mọi người luôn nhìn rõ đích đi và tầm quan trọng.

Khi con người cảm thấy mình có giá trị họ sẽ luôn hào hứng và vui vẻ trong công việc, hơn là cảm giác thúc ép làm cái gì đó không phải điều mình thích thú.

Nhưng thực sự iGà thấy plan thôi là chưa đủ, leader cần làm việc chặt chẽ với team member để là chất kết dính giữa các kết quả, là chốt chặn chất lượng của sản phẩm.

Make a realistic plan with team buy-in, apply and communicate the plan to the team DAILY.

People is more important than Plan. Plan can be changed based on project situation, but dont change the objectives.

5/ Mute during development, Noise during catch-up

Phần lớn thời gian xây dựng sản phẩm là R&D, thử sai và nghiên cứu các phép thử công nghệ nhằm đạt kết quả mong đợi. Trong quá trình này ồn ào là kẻ thù của sự tập trung. Nhưng khi tranh luận hay catchup giữa các session cần có sự trao đổi và chia sẻ.

Catchup là hoạt động ko chỉ để báo cáo kết quả công việc, các issue, và next steps. Catchup còn là khoảng thời gian để team cùng chia sẻ về công việc, về các chủ đề ngoài công việc để giúp không khí làm việc thân thiện và thoải mái.

Làm sản phẩm đôi khi bất đồng quan điểm giữa các tuyến rất cao, cảm xúc là kẻ thù lớn nhất, đặc biệt với các deep technician. Việc không kiểm soát cảm xúc ở cử chỉ và lời nói dễ phá vỡ sự tôn trọng, tin tưởng. Hãy tạo các ground rules một cách tự nhiên trong đội trươcs khi điều này xảy ra. Là một leader giỏi bạn luôn cần phải nghĩ một cách xa nhất có thể để có sự chuẩn bị từ bây giờ.

6/ Khắc nghiệt lúc ban đầu, nhưng cần rộng lượng khi có sai lầm

Một số leader thường dễ dàng lúc ban đầu khiến tốc độ và sự kỷ luật trong đội kém, dẫn đến kết quả công việc ko đều đặn, thiếu ổn định baseline đội nhóm. Việc push hard, tạo động lực cho các công việc khó ban đầu giúp team không chủ quan.

Dont start with comfortable zone.

Nhưng chính vì chọn vào điểm cốt lõi, điểm cần giải quyết quan trọng nhất nên có thể có nhiều sai lầm tạo ra ở nhiều cấp độ. Để prevent chuyện này leader cần sát cánh team member trong quá trình nghiên cứu và phát triển, khi có chuyện xảy ra cũng bao dung và làm sao để không bị lặp lại.

Mistakes are meant for learning, not Repeating

7/ Always verifying the annoucements

Thú thật khi phát triển các sản phẩm trên Cloud, cụ thể AWS. Triết lý đầu tiên cần thấm nhuần là “Pay As You Go”, việc ứng dụng cần phát triển mở rộng linh hoạt theo nhu cầu sử dụng, tính tiền theo kiểu xài nhiêu trả nhiêu. Để hiện thực điều này các bạn cần hoạch định rất kỹ và kiểm thử các tính năng về performance & cost. Việc đọc các tài liệu FAQ hay xem pricing sẽ chưa phải tất cả khi các bạn thực sự làm về nó, vì nhiều thứ chỉ khi chạy thật các bạn mới hiểu cảm nhận nó thế nào.

Chạy sản phẩm trên Cloud sẽ là tiết kiệm nếu mình biết cách dùng và kiểm soát nó, nhưng nếu ko biết thì sẽ còn tốn kém hơn cả truyền thống. Luôn nhớ keep monitoring trong thời gian đầu để xem human behavior và system behavior.

Keep monitoring system and see cost category (using AWS cost explorer). Understand human behavior and system behavior.

8/ Product is just a first gate, A quality product and projected is main gate

Nhiều startup cứ nghĩ có product là xong, nhưng đây mới chỉ là bắt đầu. Hãy luôn giữ đôi chân ở mặt đất và ko ngừng nghiên cứu, nâng cao chất lượng sản phẩm. Có dự án và triển khai dự án thành công mới là milestone đầu tiên.

Đừng thỏa mãn ở nhứng release đầu tiên, tiếp tục phát triển, keep delivering, keep growing.

 

Mong nhận được nhiều chia sẻ từ các bạn khi phát triển sản phẩm trên Cloud trong phần bình luận bên dưới nhé.

Share to be shared,

iGà

[email protected]

Topics #aws #cost explorer #dev #pay as you go #product development #saas