B
bvtvba
Guest
Lần đầu tiên bạn làm ra được một cái macro là khi nào? Đó chắc hẳn là niềm vui sướng, tôi nghĩ bất cứ ai cũng sẽ nhờ chương trình VBA mà mình làm ra đầu tiên là gì, nó tương tự như mối tình đầu của chúng ta, và chúng ta không thể nào quên được. VBA đầu tiên tôi làm là phục vụ công việc của mình và sau đó nó mang lại cho tôi rất nhiều rắc rối.
Tôi không phải là người làm ra VBA để bán. Thật ra tôi rất ủng hộ việc bán công sức như thế. Một bên cần mua và một bên có khả năng đáp ứng và bán. Nếu là quan hệ mua bán thì nó vui lắm, người code dù phải xác nhận cực nhọc để làm rõ mong muốn người dùng, thì cũng sẽ cảm thấy vui vẻ. Bên nào vi phạm hợp đồng, như là tự ý thay đổi nội dung đã thống nhất khi đang code thì phạt. Hoặc bên code không làm theo hợp đồng, không đưa ra output đúng kỳ hạn, thì phạt.
Quan hệ bằng tiền như thế, rõ ràng như thế, ai nấy đều vui vẻ.
Tuy nhiên còn loại quan hệ khác, đó là quan hệ nhờ vả trên diễn đàn, có lẽ bài viết về chủ đề này cũng đã nhiều, tôi không bàn thêm.
Và một loại quan hệ khác đó là VBA trong công sở.
Thời gian giành cho công việc của mọi người chiếm phần lớn thời gian trong cuộc đời của mọi người trong giai đoạn trưởng thành và đi làm. Này nhé, một ngày có 24 tiếng, thì tối thiểu bạn đã giành cho công sở những 10 tiếng đấy, bao gồm: 8 tiếng làm việc, thường là 1 tiếng nghỉ trưa, thời gian đi tới công sở và từ công sở về nhà giả sử mỗi chiều là 30 phút thì bạn đã mất 1 tiếng di chuyển. Tôi chưa nói có hôm bạn làm thêm giờ, thì thời gian cho công sở còn nhiều hơn 10 tiếng.
Tôi thừa nhận những người đến với VBA phần lớn vì đam mê. Sống bằng đam mê thì vui lắm, người ta không vụ lợi. Thế nhưng trong môi trường công sở, nếu cứ vô tư bằng đam mê, bạn sẽ không được nhìn nhận.
Cả nhóm đang làm việc cật lực để kịp tiến độ, còn bạn thì mải mê suy nghĩ về VBA. Ngay lập tức bạn sẽ bị nói, tại sao việc không làm đi, ngồi ngẩn ngơ thế thì đến bao giờ mới xong.
Cái VBA mà bạn đang nghĩ thì không biết bao giờ mới nghĩ xong, rồi làm ra chạy có đúng không, có lỗi phát sinh nào đó mà không kiểm soát được thì làm thế nào, trong khi nếu làm bằng tay thì người ta tính được, công việc ấy, chừng này con người làm, thì chiều ngày mốt sẽ xong, kịp tiến độ. Tuy nhiên trong chừng này con người đó, có một người ngẩn ngơ không tập trung, thì công việc sẽ không kịp.
Vì vậy, bài học rút ra là: Bạn chỉ nên nghĩ về VBA khi không ảnh hưởng tới công việc khác của nhóm.
Làm ra một chương trình VBA cho người khác dùng, thật ra là rất khó. Bạn phải tính toán được thao tác người dùng, data input. Ngay cả hai bên đã thống nhất nội dung, phải như thế này, phải thao tác thế kia, người dùng vẫn có thể có sai sót. Vì vậy, Tool nào cũng cần có hướng dẫn sử dụng. Các chỗ quan trọng được làm nổi bật lên để người ta chú ý. Bởi vì nếu Tool đó chạy sai, chưa cần biết lý do là gì, công việc có lỗi, thì mức độ tin cậy sẽ giảm xuống.
Bài học rút ra là: Tool nên có hướng dẫn sử dụng thật chi tiết.
Bây giờ bạn sẽ hỏi tôi, vậy thời gian đâu để làm ra Tool cho người khác dùng với mức độ tỉ mỉ cao như thế? Chúng ta có công việc của chúng ta, chúng ta đâu thể ngồi làm Tool cho người khác dùng một cách tỉ mỉ như thế nếu như chúng ta không được cung cấp thời gian. Vì vậy, khả năng bạn code VBA thì tốt rồi, ai cũng biết, nhưng để khả năng ấy được sử dụng cho nhóm khác, thì đòi hỏi người quản lý phải biết sắp xếp. Anh quản lý nhóm A có người X giỏi macro sẽ thương lượng với anh quản lý nhóm B có nhu cầu dùng macro. Nhóm A hiện nay ít việc, có thể cho anh X sang hỗ trợ làm macro với yêu cầu thời gian anh X làm cho nhóm B được tính vào thời gian làm việc của nhóm A.
Ban đầu nhóm A làm 800 giờ. Nhóm B làm 1000 giờ.
Nay chuyển giao 200 giờ cho người X của nhóm A làm macro, kết quả được sửa lại:
Nhóm A có số giờ làm là 1000 giờ. Nhóm B có số giờ làm là 800 giờ.
Người X được cung cấp thời gian để làm macro thì anh ta sẽ chuyên tâm làm hơn là ngồi thậm thụt làm theo đam mê mà có khi còn bị kỷ luật.
Bài học rút ra là: Phải cung cấp thời gian cho người code VBA.
Tốc độ và không lỗi, cái nào quan trọng hơn?
Trước khi bạn làm ra macro, người ta không biết có macro hay không, vì thế khi lập kế hoạch công việc đã phải tính làm sao để công việc ấy xong. Họ (những người quản lý) đã phải tính toán thời gian trước khi giao kỳ hạn công việc cho nhân viên. Vì vậy nếu bạn làm nhanh, mà công ty không có việc gì khác, thì chỉ có bạn được lợi. Bạn được hưởng thành quả ngay lập tức, có thể ngồi ngẩn ngơ chờ máy chạy ra kết quả trong tích tắc. Vì vậy tôi không nghĩ tốc độ là quan trọng.
Nhưng có một thứ cực kỳ khó chịu trong công việc, đó là lỗi.
Dù qui trình công việc đã phân ra giai đoạn check (kiểm tra) rất cụ thể. Nhưng khi việc gấp, kỳ hạn nhanh, hoặc nhân viên phải làm khối lượng việc lớn, thì việc check rất dễ sai sót. Cho nên tôi nghĩ, vai trò của VBA được đánh giá cao đó chính là đưa ra output không có lỗi.
Muốn như vậy, khi code VBA phải tính toán được các tình huống có khả năng phát sinh lỗi từ data input, để đưa ra cảnh báo giúp người dùng chỉnh sửa lại dữ liệu.
Bài học rút ra: Output không sai quan trọng hơn tốc độ.
Người ta thống kê rằng, trong các công ty Nhật, cứ 100 người thì có 2-3 người sử dụng được VBA. Con số này trong các công ty Việt Nam có lẽ là còn ít hơn nhiều.(Vui chút: Nếu thống kê theo tiêu chí, cứ 100 người thì có 50 người uống được 2 cốc bia, thì chắc công ty Việt Nam sẽ áp đảo.)
Vì vậy, những người biết VBA thật sự là nổi bật trong tổ chức. Nhưng cũng chính vì vậy, bạn lại phải thận trọng. Là con người, bao giờ cũng có ganh ghét, đố kỵ, cho nên không biết chừng, có nhiều người âm thầm chỉ mong bạn ngã xuống bất kỳ lúc nào. Vì vậy, khiêm tốn là cực kỳ quan trọng.
Như trên tôi đã trình bày, code cho người khác dùng là cực kỳ mất thời gian. Vì vậy nếu bạn có tool nào đó mà bạn đang sử dụng tốt, bạn tính toán được các khả năng lỗi nhưng chưa có thời gian code can thiệp, thì hãy cứ dùng cho bản thân mình thôi. Mình code, mình tự chỉnh data.
Đưa cho người khác dùng, họ không biết, có lỗi thì họ gọi, thậm chí còn chê bai. Vậy, hãy kiềm chế bản thân, đừng khoe khoang, thứ bạn thu được không phải là ngưỡng mộ, chẳng có ánh hào quang nào ở đây, thứ bạn thu được là chê bai, code thế mà cũng code.
Bài học: Chỉ khi họ nhờ bạn hoặc có chỉ thị từ cấp trên yêu cầu bạn giúp đỡ, và cung cấp cho bạn thời gian, có nội dung thống nhất giữa hai bên, và bạn code đúng như nội dung thống nhất đó.
Tôi không phải là người làm ra VBA để bán. Thật ra tôi rất ủng hộ việc bán công sức như thế. Một bên cần mua và một bên có khả năng đáp ứng và bán. Nếu là quan hệ mua bán thì nó vui lắm, người code dù phải xác nhận cực nhọc để làm rõ mong muốn người dùng, thì cũng sẽ cảm thấy vui vẻ. Bên nào vi phạm hợp đồng, như là tự ý thay đổi nội dung đã thống nhất khi đang code thì phạt. Hoặc bên code không làm theo hợp đồng, không đưa ra output đúng kỳ hạn, thì phạt.
Quan hệ bằng tiền như thế, rõ ràng như thế, ai nấy đều vui vẻ.
Tuy nhiên còn loại quan hệ khác, đó là quan hệ nhờ vả trên diễn đàn, có lẽ bài viết về chủ đề này cũng đã nhiều, tôi không bàn thêm.
Và một loại quan hệ khác đó là VBA trong công sở.
Thời gian giành cho công việc của mọi người chiếm phần lớn thời gian trong cuộc đời của mọi người trong giai đoạn trưởng thành và đi làm. Này nhé, một ngày có 24 tiếng, thì tối thiểu bạn đã giành cho công sở những 10 tiếng đấy, bao gồm: 8 tiếng làm việc, thường là 1 tiếng nghỉ trưa, thời gian đi tới công sở và từ công sở về nhà giả sử mỗi chiều là 30 phút thì bạn đã mất 1 tiếng di chuyển. Tôi chưa nói có hôm bạn làm thêm giờ, thì thời gian cho công sở còn nhiều hơn 10 tiếng.
Tôi thừa nhận những người đến với VBA phần lớn vì đam mê. Sống bằng đam mê thì vui lắm, người ta không vụ lợi. Thế nhưng trong môi trường công sở, nếu cứ vô tư bằng đam mê, bạn sẽ không được nhìn nhận.
Cả nhóm đang làm việc cật lực để kịp tiến độ, còn bạn thì mải mê suy nghĩ về VBA. Ngay lập tức bạn sẽ bị nói, tại sao việc không làm đi, ngồi ngẩn ngơ thế thì đến bao giờ mới xong.
Cái VBA mà bạn đang nghĩ thì không biết bao giờ mới nghĩ xong, rồi làm ra chạy có đúng không, có lỗi phát sinh nào đó mà không kiểm soát được thì làm thế nào, trong khi nếu làm bằng tay thì người ta tính được, công việc ấy, chừng này con người làm, thì chiều ngày mốt sẽ xong, kịp tiến độ. Tuy nhiên trong chừng này con người đó, có một người ngẩn ngơ không tập trung, thì công việc sẽ không kịp.
Vì vậy, bài học rút ra là: Bạn chỉ nên nghĩ về VBA khi không ảnh hưởng tới công việc khác của nhóm.
Làm ra một chương trình VBA cho người khác dùng, thật ra là rất khó. Bạn phải tính toán được thao tác người dùng, data input. Ngay cả hai bên đã thống nhất nội dung, phải như thế này, phải thao tác thế kia, người dùng vẫn có thể có sai sót. Vì vậy, Tool nào cũng cần có hướng dẫn sử dụng. Các chỗ quan trọng được làm nổi bật lên để người ta chú ý. Bởi vì nếu Tool đó chạy sai, chưa cần biết lý do là gì, công việc có lỗi, thì mức độ tin cậy sẽ giảm xuống.
Bài học rút ra là: Tool nên có hướng dẫn sử dụng thật chi tiết.
Bây giờ bạn sẽ hỏi tôi, vậy thời gian đâu để làm ra Tool cho người khác dùng với mức độ tỉ mỉ cao như thế? Chúng ta có công việc của chúng ta, chúng ta đâu thể ngồi làm Tool cho người khác dùng một cách tỉ mỉ như thế nếu như chúng ta không được cung cấp thời gian. Vì vậy, khả năng bạn code VBA thì tốt rồi, ai cũng biết, nhưng để khả năng ấy được sử dụng cho nhóm khác, thì đòi hỏi người quản lý phải biết sắp xếp. Anh quản lý nhóm A có người X giỏi macro sẽ thương lượng với anh quản lý nhóm B có nhu cầu dùng macro. Nhóm A hiện nay ít việc, có thể cho anh X sang hỗ trợ làm macro với yêu cầu thời gian anh X làm cho nhóm B được tính vào thời gian làm việc của nhóm A.
Ban đầu nhóm A làm 800 giờ. Nhóm B làm 1000 giờ.
Nay chuyển giao 200 giờ cho người X của nhóm A làm macro, kết quả được sửa lại:
Nhóm A có số giờ làm là 1000 giờ. Nhóm B có số giờ làm là 800 giờ.
Người X được cung cấp thời gian để làm macro thì anh ta sẽ chuyên tâm làm hơn là ngồi thậm thụt làm theo đam mê mà có khi còn bị kỷ luật.
Bài học rút ra là: Phải cung cấp thời gian cho người code VBA.
Tốc độ và không lỗi, cái nào quan trọng hơn?
Trước khi bạn làm ra macro, người ta không biết có macro hay không, vì thế khi lập kế hoạch công việc đã phải tính làm sao để công việc ấy xong. Họ (những người quản lý) đã phải tính toán thời gian trước khi giao kỳ hạn công việc cho nhân viên. Vì vậy nếu bạn làm nhanh, mà công ty không có việc gì khác, thì chỉ có bạn được lợi. Bạn được hưởng thành quả ngay lập tức, có thể ngồi ngẩn ngơ chờ máy chạy ra kết quả trong tích tắc. Vì vậy tôi không nghĩ tốc độ là quan trọng.
Nhưng có một thứ cực kỳ khó chịu trong công việc, đó là lỗi.
Dù qui trình công việc đã phân ra giai đoạn check (kiểm tra) rất cụ thể. Nhưng khi việc gấp, kỳ hạn nhanh, hoặc nhân viên phải làm khối lượng việc lớn, thì việc check rất dễ sai sót. Cho nên tôi nghĩ, vai trò của VBA được đánh giá cao đó chính là đưa ra output không có lỗi.
Muốn như vậy, khi code VBA phải tính toán được các tình huống có khả năng phát sinh lỗi từ data input, để đưa ra cảnh báo giúp người dùng chỉnh sửa lại dữ liệu.
Bài học rút ra: Output không sai quan trọng hơn tốc độ.
Người ta thống kê rằng, trong các công ty Nhật, cứ 100 người thì có 2-3 người sử dụng được VBA. Con số này trong các công ty Việt Nam có lẽ là còn ít hơn nhiều.(Vui chút: Nếu thống kê theo tiêu chí, cứ 100 người thì có 50 người uống được 2 cốc bia, thì chắc công ty Việt Nam sẽ áp đảo.)
Vì vậy, những người biết VBA thật sự là nổi bật trong tổ chức. Nhưng cũng chính vì vậy, bạn lại phải thận trọng. Là con người, bao giờ cũng có ganh ghét, đố kỵ, cho nên không biết chừng, có nhiều người âm thầm chỉ mong bạn ngã xuống bất kỳ lúc nào. Vì vậy, khiêm tốn là cực kỳ quan trọng.
Như trên tôi đã trình bày, code cho người khác dùng là cực kỳ mất thời gian. Vì vậy nếu bạn có tool nào đó mà bạn đang sử dụng tốt, bạn tính toán được các khả năng lỗi nhưng chưa có thời gian code can thiệp, thì hãy cứ dùng cho bản thân mình thôi. Mình code, mình tự chỉnh data.
Đưa cho người khác dùng, họ không biết, có lỗi thì họ gọi, thậm chí còn chê bai. Vậy, hãy kiềm chế bản thân, đừng khoe khoang, thứ bạn thu được không phải là ngưỡng mộ, chẳng có ánh hào quang nào ở đây, thứ bạn thu được là chê bai, code thế mà cũng code.
Bài học: Chỉ khi họ nhờ bạn hoặc có chỉ thị từ cấp trên yêu cầu bạn giúp đỡ, và cung cấp cho bạn thời gian, có nội dung thống nhất giữa hai bên, và bạn code đúng như nội dung thống nhất đó.