Để có thể sử dụng được Macro, nâng cao hiệu suất công việc, cho nên tôi và các quản trị viên ở đây đã học cách xây dựng một chương trình VBA.
Tuy nhiên, nếu chúng ta không xây dựng macro theo trình tự đúng, macro không thể cho được hiệu suất tốt.
Chúng ta tuyệt đối không tạo chương trình VBA ngay lập tức.
Có người vì sốt ruột muốn nâng cao hiệu suất công việc cho nên ngay lập tức bắt tay vào viết macro.
Tuy nhiên chúng ta không nên làm như thế. Tại sao lại như vậy là bởi vì, chương trình là một công trình tổng thể, để đi đường dài, chúng ta cần có thiết kế và kế hoạch.
Vứt bỏ đi quy trình chuẩn bị trước khi tạo macro, có những người tạo macro liền một mạch rồi cũng ra được chương trình. Tạo macro như vậy cũng giống như uống một hơi hết một cốc nước, và tôi muốn trình bày lý do tại sao chúng ta không nên làm như vậy.
Ngay sau khi làm rõ “Muốn làm gì”-chúng ta mới tạo macro
Trước khi tạo macro, việc làm rõ yêu cầu “Bạn muốn làm gì” là điều cực kỳ quan trọng. Tại sao lại như vậy là vì, nếu không làm rõ yêu cầu, thì sau đó rất có thể sẽ phát sinh những việc như là sửa lại macro, thậm chí là làm lại hoàn toàn macro.
Ví dụ: Đầu tiên họ nói muốn tạo chương trình làm cái này, chúng ta không hiểu rõ ý đồ và mục đích, thứ chúng ta tạo ra xong kết cục họ lại nói, họ thật ra là muốn như thế này, như thế kia. Cuối cùng, bạn sẽ phải làm lại hoặc sửa lại. Việc như thế thật là mất thời gian.
Thực tế, ngay bản thân chúng ta là người code, đôi khi chúng ta tạo chương trình cho chính mình, cứ tưởng là hiểu rõ tường tận mà không phác thảo ra, đến khi làm xong lại muốn sửa lại chỗ này chỗ kia: Tôi muốn thay đổi lại form output, tôi muốn thêm trường thông tin xyz vào đây….
Như thế là chúng ta đã lãng phí thời gian một cách vô ích.
Vì vậy, nếu tự bản thân làm phát sinh thời gian và tự bản thân phải sửa, thì tự làm tự chịu và lần sau rút kinh nghiệm. Nhưng nếu ai đó nhờ hoặc thuê làm, để tránh mất thời gian, thì việc làm rõ yêu cầu là vô cùng quan trọng.
Để tránh làm mất thời gian quý báu của mình, hãy nhớ rõ, phải làm rõ “Muốn làm gì” truớc khi viết code. Đây là bước đầu tiên khi bắt tay làm chương trình VBA.
Tổ chức dữ liệu kém, sẽ khó code
Để dễ hình dung, bạn đọc hãy vào Box Chia sẻ dự án hoàn thành và ý tưởng, tìm tới topic “Phân công nhiệm vụ coi thi”.
Link:
Yêu cầu output ra như này là một chuyện, chương trình muốn xử lý thì phải tổ chứ lại dữ liệu để người code dễ code.
Ngoài ra, data vốn dĩ ban đầu là như thế nào cũng cần làm rõ. Có người thuyết minh là dữ liệu cột này không trùng nhau, nhưng data demo đưa lên thì lại trùng nhau.
Có người thuyết minh tên sheet làm việc là ABC, file demo đưa lên, tên sheet lại là XYZ. Thật là phiền hà cho người code vô cùng.
Nếu không làm rõ đuợc data ban đầu, chúng ta không thể tổ chức được dữ liệu tốt.
Tất nhiên, ở mức độ nào đó, bạn nói rằng, không cần tổ chức dữ liệu, data dù bla bla như nào, tôi vẫn code được. Tuy nhiên đó không phải là người code giỏi. Và không ai khuyến khích nhân viên làm việc theo cách đó.
Phần trên, tôi tham khảo và dịch từ bài viết này :
Bây giờ, quay trở lại chuyện diễn đàn. Những thành viên nói diễn đàn làm việc cứng nhắc thật ra là những người làm việc chưa chuyên nghiệp.
Yêu cầu trình bày cho mọi người đều hiểu là yêu cầu chính đáng. Một công ty muốn tồn tại trăm năm, thì văn hóa của công ty ấy phải là mọi thứ đều dễ hiểu. Anh có kiến thức nhưng chỉ giải quyết việc của anh, mọi người không hiểu gì, thì anh không được đánh giá cao.
Anh chỉ giải quyết được việc của anh, không tạo ra bản hướng dẫn công việc, để bất cứ ai cũng làm được việc mà anh đang làm, thì anh không được đánh giá cao.
Sẽ có người cho rằng, đó là bí kíp cá nhân, nếu nói vậy, thì anh nên tự mở công ty riêng, nơi đó, mọi nhân viên đều che giấu kỹ thuật cá nhân, anh A nghỉ ốm là công ty chết, không ai làm thay được anh A. Hoặc là cách làm của anh A không theo trình tự chung mà cả nhóm đã thống nhất cách làm đó là ít sai sót và dễ làm đối với bất cứ ai. Vậy là anh A mà nghỉ, thứ việc dở dang của anh A đang làm sẽ không ai làm thay được.
Tương tự, trên diễn đàn, bạn cũng đi thu thập kiến thức cho bản thân, vậy thì hà cớ gì bạn phải che giấu bí kíp mình có mà không chia sẻ ra để mọi người cùng góp ý cho hoàn thiện hơn.
Các quản trị viên khi xác nhận yêu cầu đều sử dụng cấu trúc: Tôi hiểu như thế này có đúng không…
Có nghĩa là, vừa xác nhận với người yêu cầu, vừa là để người khác nhìn vào hiểu logic. Bất cứ ai làm thay tiếp cũng được, nếu mai họ bận đi công tác hoặc ốm.
Với những người đang tham gia diễn đàn, tôi chúc các bạn có được nhiều kiến thức và cùng nhau chia sẻ kiến thức nhiều hơn và tuân thủ định hướng của diễn đàn.
Định hướng của diễn đàn là không thay đổi: Mọi thứ trở nên dễ hiểu.
Làm sao để người ngu nhất cũng hiểu được như thế là bạn đã trình bày thành công.
Tuy nhiên, nếu chúng ta không xây dựng macro theo trình tự đúng, macro không thể cho được hiệu suất tốt.
Chúng ta tuyệt đối không tạo chương trình VBA ngay lập tức.
Có người vì sốt ruột muốn nâng cao hiệu suất công việc cho nên ngay lập tức bắt tay vào viết macro.
Tuy nhiên chúng ta không nên làm như thế. Tại sao lại như vậy là bởi vì, chương trình là một công trình tổng thể, để đi đường dài, chúng ta cần có thiết kế và kế hoạch.
Vứt bỏ đi quy trình chuẩn bị trước khi tạo macro, có những người tạo macro liền một mạch rồi cũng ra được chương trình. Tạo macro như vậy cũng giống như uống một hơi hết một cốc nước, và tôi muốn trình bày lý do tại sao chúng ta không nên làm như vậy.
Ngay sau khi làm rõ “Muốn làm gì”-chúng ta mới tạo macro
Trước khi tạo macro, việc làm rõ yêu cầu “Bạn muốn làm gì” là điều cực kỳ quan trọng. Tại sao lại như vậy là vì, nếu không làm rõ yêu cầu, thì sau đó rất có thể sẽ phát sinh những việc như là sửa lại macro, thậm chí là làm lại hoàn toàn macro.
Ví dụ: Đầu tiên họ nói muốn tạo chương trình làm cái này, chúng ta không hiểu rõ ý đồ và mục đích, thứ chúng ta tạo ra xong kết cục họ lại nói, họ thật ra là muốn như thế này, như thế kia. Cuối cùng, bạn sẽ phải làm lại hoặc sửa lại. Việc như thế thật là mất thời gian.
Thực tế, ngay bản thân chúng ta là người code, đôi khi chúng ta tạo chương trình cho chính mình, cứ tưởng là hiểu rõ tường tận mà không phác thảo ra, đến khi làm xong lại muốn sửa lại chỗ này chỗ kia: Tôi muốn thay đổi lại form output, tôi muốn thêm trường thông tin xyz vào đây….
Như thế là chúng ta đã lãng phí thời gian một cách vô ích.
Vì vậy, nếu tự bản thân làm phát sinh thời gian và tự bản thân phải sửa, thì tự làm tự chịu và lần sau rút kinh nghiệm. Nhưng nếu ai đó nhờ hoặc thuê làm, để tránh mất thời gian, thì việc làm rõ yêu cầu là vô cùng quan trọng.
Để tránh làm mất thời gian quý báu của mình, hãy nhớ rõ, phải làm rõ “Muốn làm gì” truớc khi viết code. Đây là bước đầu tiên khi bắt tay làm chương trình VBA.
Tổ chức dữ liệu kém, sẽ khó code
Để dễ hình dung, bạn đọc hãy vào Box Chia sẻ dự án hoàn thành và ý tưởng, tìm tới topic “Phân công nhiệm vụ coi thi”.
Link:
Bạn cần đăng nhập để thấy link
Yêu cầu output ra như này là một chuyện, chương trình muốn xử lý thì phải tổ chứ lại dữ liệu để người code dễ code.
Ngoài ra, data vốn dĩ ban đầu là như thế nào cũng cần làm rõ. Có người thuyết minh là dữ liệu cột này không trùng nhau, nhưng data demo đưa lên thì lại trùng nhau.
Có người thuyết minh tên sheet làm việc là ABC, file demo đưa lên, tên sheet lại là XYZ. Thật là phiền hà cho người code vô cùng.
Nếu không làm rõ đuợc data ban đầu, chúng ta không thể tổ chức được dữ liệu tốt.
Tất nhiên, ở mức độ nào đó, bạn nói rằng, không cần tổ chức dữ liệu, data dù bla bla như nào, tôi vẫn code được. Tuy nhiên đó không phải là người code giỏi. Và không ai khuyến khích nhân viên làm việc theo cách đó.
Phần trên, tôi tham khảo và dịch từ bài viết này :
Bạn cần đăng nhập để thấy link
Bây giờ, quay trở lại chuyện diễn đàn. Những thành viên nói diễn đàn làm việc cứng nhắc thật ra là những người làm việc chưa chuyên nghiệp.
Yêu cầu trình bày cho mọi người đều hiểu là yêu cầu chính đáng. Một công ty muốn tồn tại trăm năm, thì văn hóa của công ty ấy phải là mọi thứ đều dễ hiểu. Anh có kiến thức nhưng chỉ giải quyết việc của anh, mọi người không hiểu gì, thì anh không được đánh giá cao.
Anh chỉ giải quyết được việc của anh, không tạo ra bản hướng dẫn công việc, để bất cứ ai cũng làm được việc mà anh đang làm, thì anh không được đánh giá cao.
Sẽ có người cho rằng, đó là bí kíp cá nhân, nếu nói vậy, thì anh nên tự mở công ty riêng, nơi đó, mọi nhân viên đều che giấu kỹ thuật cá nhân, anh A nghỉ ốm là công ty chết, không ai làm thay được anh A. Hoặc là cách làm của anh A không theo trình tự chung mà cả nhóm đã thống nhất cách làm đó là ít sai sót và dễ làm đối với bất cứ ai. Vậy là anh A mà nghỉ, thứ việc dở dang của anh A đang làm sẽ không ai làm thay được.
Tương tự, trên diễn đàn, bạn cũng đi thu thập kiến thức cho bản thân, vậy thì hà cớ gì bạn phải che giấu bí kíp mình có mà không chia sẻ ra để mọi người cùng góp ý cho hoàn thiện hơn.
Các quản trị viên khi xác nhận yêu cầu đều sử dụng cấu trúc: Tôi hiểu như thế này có đúng không…
Có nghĩa là, vừa xác nhận với người yêu cầu, vừa là để người khác nhìn vào hiểu logic. Bất cứ ai làm thay tiếp cũng được, nếu mai họ bận đi công tác hoặc ốm.
Với những người đang tham gia diễn đàn, tôi chúc các bạn có được nhiều kiến thức và cùng nhau chia sẻ kiến thức nhiều hơn và tuân thủ định hướng của diễn đàn.
Định hướng của diễn đàn là không thay đổi: Mọi thứ trở nên dễ hiểu.
Làm sao để người ngu nhất cũng hiểu được như thế là bạn đã trình bày thành công.