Một số lưu ý khi đưa ra yêu cầu trên diễn đàn

tuhocvba

Administrator
Thành viên BQT
Mọi người nên học một khóa VBA để có tư duy lập trình. Nhờ đó khi đứng trước một vấn đề cũng có thể hình dung được trình tự công việc là gì. Từ đó truyền đạt nội dung yêu cầu một cách khoa học.

Dữ liệu đầu vào, hay Input: Đây là nội dung quan trọng. Sẽ thế nào nếu bạn đưa ra file input 1 có định dạng khác với file input 2. Người code là người không hiểu nội dung công việc của các bạn, do đó khi đưa ra file input, mặc dù nghiên cứu quy luật, đặc tính của file input này nhưng vẫn có thể có sai sót. Nhất là nếu bạn chỉ đưa ra một file input.

Trong tương lai khi bạn có một file input mà cấu trúc dữ liệu có khác biệt, Tool không chạy được, việc sửa code lúc này sẽ rất mất thời gian.

Trong thực tế đã có trường hợp mà người nhờ vả cũng không ngờ input có trường hợp như thế. Khi sử dụng Tool do kết quả sai khác, kiểm tra lại file input mới phát hiện ra có vấn đề. Trường hợp này bên phía yêu cầu sẽ thông báo với phía code, đây là tình huống không mong muốn. Tất nhiên phía code sẽ hỗ trợ cập nhật Tool, và người yêu cầu phải trả thêm tiền.

Bạn càng đưa ra nhiều file input khác nhau, người code sẽ lấy đó làm cơ sở so sánh chúng để tìm ra quy luật. Ngoài ra nếu có gì cần chú ý, bạn cũng nên thông báo cho người code. Việc đó sẽ hạn chế được những sai sót không đáng có.

Dữ liệu đầu ra, hay output. Đây là nội dung kết quả Tool xuất ra, là nội dung mà bạn mong muốn. Bạn cần mô tả bằng file demo định dạng output mà bạn muốn. Nếu có chú ý gì đặc biệt, cần chỉ rõ ra. Vì nội dung một file sẽ có những góc khuất mà người code có thể bỏ sót do không để ý. Đây không phải là công việc của họ, đây là công việc của bạn, bạn là người hiểu rõ nhất mình muốn gì, cần thể hiện kết quả như thế nào. Do đó, nếu không nói rõ ràng, sai sót có thể xảy ra.

Cuối cùng là logic. Điều kiện như thế nào thì làm công việc gì đó. Chẳng hạn để ghi nội dung đánh giá, thì cách đánh giá đó là như thế nào, dựa vào đâu để phán đoán. Nếu như không rõ ràng logic, nó chẳng khác nào bạn bảo một người đi đi mà không nói đi đâu, khi trời mưa thì có đi hay không?...

Khi nhận được các câu hỏi nhằm làm rõ vấn đề, để hạn chế sai sót, các bạn thường lại nghĩ rằng mình không được hoan nghênh và phản ứng tiêu cực. Cuối cùng người code lãnh hậu quả, do không nhận đầy đủ thông tin, nên sản phẩm làm ra không đáp ứng được mong mỏi của người dùng, phải sửa code trong khi chi phí thường các bạn không muốn trả thêm, nhất là với những nhờ vả thông thường không có trả công, thì người code sẽ bất mãn đến nhường nào.

Học viết code, có thể bạn chưa code giỏi, nhưng ít nhất bạn hiểu được cần phải đưa thông tin như thế nào để người khác làm việc được. Ngoài ra, khi trao đổi thông tin, thường để tiện lợi, các bạn nhắn qua zalo, facebook, các tin nhắn này nhanh chóng trôi đi. Nếu post lên diễn đàn, thì thông tin có hệ thống hơn, dễ tra cứu hơn.

Người code vừa phải hiểu yêu cầu của bạn là gì, vừa phải đưa ra giải pháp để giải quyết vấn đề của bạn, thực sự khối lượng việc là rất nhiều. Cho nên, ngay cả cách truyền đạt thông tin cũng phải đưa thông tin làm sao để họ dễ xử lý thông tin.

Có rất nhiều người nhờ code và trả công, nhưng không phải cứ trả công thì công việc sẽ được tiến hành. Bởi vì, tiền các bạn có là hữu hạn. Khi phát sinh thời gian do làm việc thiếu hiệu quả, các bạn không sẵn sàng trả thêm tiền.

Ngay cả trường hợp các bạn sẵn sàng trả thêm tiền, nhưng nếu làm việc với một người đưa thông tin tù mù, không khoa học, phải code đi code lại nhiều lần, cảm xúc làm việc cũng mất đi, không muốn làm việc cùng với người như thế. Vì vậy các bạn lưu ý. Tôi sẽ dừng dự án nếu dự án thể hiện sử dụng thời gian không hiệu quả.
 
Top