Ở tập trước mình có làm một bài dạng tổng kết lại các kiến thức cho dân không chuyên (non-tech) từ nhiều bài trước là "No-Code – Tối ưu website không cần can thiệp code". Tuần này mình sẽ chia sẻ thêm những mục mà các bạn cần phải nhờ Dev (người lập trình, phát triển website của bạn) hỗ trợ tối ưu thêm cho bạn.
Mục đích bài này là giúp bạn biết cách làm việc với Dev hiệu quả hơn, tiết kiệm thời gian hơn mà vẫn đáp ứng kì vọng so với điều kiện thực tế.
Trong điều kiện lý tưởng, mã nguồn website ổn, mình nhập liệu theo checklist ổn và tiêu chuẩn công nghệ không bao giờ thay đổi thì chắc chả bao giờ phải nhờ tới ai rồi ^^.
Mà thực tế thì không như vậy, Đời không như là mơ.. nên đời thường giết chết mông mơ... Nói chung sẽ có lúc bạn muốn tối ưu, nâng cấp và cũng sẽ có lúc bạn cần phải xây dựng cái mã nguồn hoàn toàn mới để website của mình.. bằng chị bằng em.
Mình tạm liệt kê ra vài ý để bạn tự nhận diện được thời điểm mình cần đi nhờ Dev:
Đại khái là bạn thấy bắt đầu ngoài tầm với và những gì bạn đang có rồi đó.
Như ở bài đầu tiên mình có nói, bạn phải biết mình thực sự muốn gì. Đi nhờ mà còn không xác định rõ mình nhờ gì thì hơi.. sai sai từ đầu rồi .
Mình thấy đa phần mọi người đều nói rất chung chung, dĩ nhiên khi đi hỏi thì mỗi Dev cũng sẽ trả lời chung chung như cách bạn hỏi.
Túm lại, bạn ít nhất nên cụ thể hóa bằng các gạch đầu dòng dạng như sau:
Tùy vào nhu cầu, thời gian và ngân sách của bạn mà bạn có thể bổ sung vào yêu cầu ban đầu để mọi việc diễn ra thuận lợi và nhanh chóng hơn.
Với những yêu cầu càng cụ thể thì một Dev có kinh nghiệm sẽ dễ dàng đánh giá mức độ khả thi dựa trên các chỉ tiêu được đề ra ở trên.
Mọi kì vọng, mục tiêu bạn đặt ra thường luôn có ràng buộc nhất định, vì vậy đa phần nó sẽ không bao giờ có thể đạt được 100% trong thực tế. Kinh nghiệm của mình là nếu Dev nào chưa hỏi hoặc hiểu rõ hết các mong muốn, ràng buộc của bạn mà gật đầu làm ngay thì thường là.. fail luôn.
Bình thường, họ sẽ phải dành kha khá thời gian (tùy độ phức tạp của mã nguồn website hiện tại) để đọc, phân tích sơ bộ rồi mới cho đánh giá mức độ khả thi được. Còn lại thì đi vào chi tiết triển khai vẫn phải mò mẫm, phân tích & đánh giá tiếp.
Tuy nhiên, đa phần đánh giá ban đầu thường sẽ như sau:
Nói chung vẫn là câu "đời không như là mơ..".
Bản thân mình lúc đi thuê các bạn làm video cũng vậy, vừa muốn kịch bản hay, hiệu ứng bắt mắt, ứng dụng 3D model, chèn được thông điệp quảng cáo và phải sớm có sản phẩm trong 15 ngày tới mà.. giá cả phải chăng nữa (hehe.. mong muốn chính đáng mà).
Khi mình nhận được các option báo giá và thời gian từ họ xong, mình vẫn phải tự hỏi lại các kì vọng mình thực sự mong muốn ban đầu xem cái nào phù hợp nhất điều kiện hiện tại để chọn. Vậy nên mình mới rút kinh nghiệm và chia sẻ mục "chuẩn bị" ở trên cho bạn đó.
Nói đâu xa, vừa tháng rồi mình cực kì ngứa ngáy muốn tối ưu thêm tốc độ website trang chủ của mình lên 30% nữa.
Rồi nghĩ lại mục tiêu tháng này đang là tăng người dùng app hơn, kiếm thêm tí tiền nộp cho vợ.
Giờ mà dành thời gian cả tháng và mớ chi phí cho Dev tối ưu nữa thì chả được đồng nào, không khéo.. bị âm thì ra đường ở luôn.
Lan man hơi xa rồi, quay xe nàooo…
Những việc mình gợi ý ở trên chỉ giúp bạn giảm thiểu rủi ro và làm việc hiệu quả hơn với Dev dựa trên kinh nghiệm của mình thôi. Mình cũng chỉ là người trần mắt thịt nên không thể biết hết được.
Bài tới đây cũng hơi bị dài rồi, mọi người thấy mình có thiếu sót gì, hoặc có câu hỏi cứ gõ bên dưới, mình biết sẽ trả lời thêm và bổ sung vào bài viết nhé.
Chúc mọi người cuối tuần vui vẻ!
Trong phần trước, mình đã chia sẻ với mọi người những khó khăn khi team…
Xin chào, tiếp tục loạt bài về trải nghiệm của mình trong việc xây dựng…
Cắm đầu cắm cổ dọn dẹp deadline và dọn nhà trước Tết nên ngâm bài…
Nếu bạn yêu thích phát triển sản phẩm với nhiều thử thách và cơ hội…
Trong phần 1, mình đã giải thích lý do tại sao EGANY chọn AWS làm…
Trong giới công nghệ hiện nay, Amazon Web Service không còn là một cái gì…