Mời hợp tác kinh doanh phần mềm quản trị bệnh viện

Công ty CP GTID là đơn vị phần mềm chuyên sâu trong lĩnh vực sản xuất và cung cấp giải pháp phần mềm. Đến nay chúng tôi đã triển khai thành công hệ thống phần mềm Quản trị bệnh viện cho một số bệnh viện lớn tại Hà nội. Hiện nay chúng tôi đang có nhu cầu tìm kiếm các đối tác (đơn vị, tổ chức hoặc cá nhân) phối hợp cùng triển khai phần mềm Quản trị bệnh viện. Chúng tôi cam kết luôn hỗ trợ tối đa mọi nguồn lực để quá trình hợp tác được ổn định và lâu dài.
Mọi thông tin chi tiết xin liên hệ với chúng tôi theo liên lạc sau:
- A.Hải - Phòng Kinh doanh - Công ty GTID
- Địa chỉ: Số 36/131 – Thái Hà – Đống Đa – Hà nội
- Điện thoại: 04 62938929 - 0904270335
- Email: Sales@gtid.com.vn

Chừng nào bạn còn đọc được bài viết này, thì lời mời hợp tác vẫn còn hiệu lực.

Xin trân trọng cảm ơn và gửi lời chào trân trọng, hợp tác!


1. Giới thiệu về “Hệ thống Quản trị Bệnh viện” - HMSYS

1.1. Giới thiệu chung

- HMSYS là một hệ thống tổng hợp, dữ liệu tập trung hoạt động trên môi trường mạng máy tính với sự ổn định và chế độ bảo mật cao,
- HMSYS có khả năng giúp các nhà quản lý nâng cao hiệu quả kinh tế, rút ngắn thời gian, công sức trong công tác quản lý tránh những lãng phí về công sức và tiền của một cách không cần thiết,
- HMSYS giúp cho bệnh nhân đến khám chữa bệnh được sử dụng những dịch vụ hiện đại và tốt nhất trong khoảng thời gian nhanh nhất,
- HMSYS là một hệ thống lớn được chia thành các phân hệ (module) nhỏ, có thể hoạt động độc lập, phù hợp với nhu cầu của từng bệnh viện,

Đối với lãnh đạo viện, HMSYS tạo ra được một cái nhìn khái quát và nhanh nhất về tình hình
khám chữa bệnh trong bệnh viện, nắm được nguồn tài chính đi vào một cách rõ ràng và theo dõi được quá trình điều trị của bệnh nhân nội trú


1.2. Một số lợi ích đem lại
- Hệ thống này giúp cho việc quản lý bệnh viện một cách thống nhất và có hệ thống. Ban giám đốc có thể theo dõi, kiểm soát hoạt động của bệnh viện thông qua hệ thống máy tính. Các chức năng của chương trình có sự liên quan mật thiết với nhau. Chương trình cho phép kiểm soát chặt chẽ mọi chi phí cho từng bệnh nhân như chi phí về khám bệnh, xét nghiệm, dịch vụ, thuốc, vật tư khác.... Ban lãnh đạo bệnh viện có thể kiểm soát tức thời mọi chi phí trong ngày cho các bệnh nhân. Hồ sơ của bệnh nhân luôn được lưu trữ tạo điều kiện cho việc tra cứu, thuận lợi cho quá trình khám, chữa bệnh.

- Hệ thống quản trị vật tư tiêu hao tại khoa bao gồm các công việc quản lý liên quan đến vật tư tiêu hao như vật tư tiêu dùng cho nhân viên, vật tư tiêu hao cho các công việc chuyên môn, vật tư tiêu dùng cho bệnh nhân,... Sự kết hợp chặt chẽ giữa số liệu của các phần hệ khám bệnh, bệnh án nội trú, xuất nhập vật tư, thuốc men khiến cho hệ thống được theo dõi một cách chặt chẽ, chính xác và số liệu luôn được kiểm soát tức thời.

- Phần viện phí của hệ thống làm cho quá trình thanh toán chi phí khám chữa bệnh với các bệnh nhân một cách nhanh chóng và chính xác.


1.3. Phân hệ “Quản lý phòng khám”

• Tiếp nhận đăng ký khám bệnh của bệnh nhân,
• Tính tiền và in biên lai thu tiền khám bệnh cho bệnh nhân,
• Quản lý biên lai thu tiền khám bệnh,
• Tiếp nhận đăng ký yêu cầu xét nghiệm của bệnh nhân,
• Tính tiền và in biên lai thu tiền xét nghiệm cho bệnh nhân,
• Quản lý biên lai thu tiền xét nghiệm,
• Tiếp nhận đăng ký yêu cầu dịch vụ của bệnh nhân,
• Tính tiền và in biên lai thu tiền dịch vụ cho bệnh nhân,
• Quản lý biên lai thu tiền dịch vụ,
• Quản lý biên lai thu tiền BHYT ngoại trú,
• Quản lý biên lai thanh toán viện phí,
• Quản lý biên lai thu tiền ký quỹ,
• Quản lý biên lai hoàn ký quỹ,
• Quản lý biên lai thu tiền BHYT nội trú,
• In biên lai thanh toán,
• Nhật ký khám bệnh,
• Nhật ký khám bệnh theo tỉnh,
• Nhật ký yêu cầu xét nghiệm,
• Nhật ký yêu cầu dịch vụ,
• Báo cáo tổng hợp khám bệnh,
• Báo cáo tổng hợp xét nghiệm,
• Báo cáo tổng hợp xét nghiệm theo nhóm,
• Báo cáo tổng hợp dịch vụ,
• Báo cáo biên lai thanh toán,
• Báo cáo biên lai huỷ,
• Báo cáo chi tiết biên lai thanh toán,
• Báo cáo chi tiết biên lai thu tiền xét nghiệm,
• Báo cáo chi tiết biên lai thu tiền dịch vụ,
• Báo cáo chi tiết miễn giảm xét nghiệm,
• Báo cáo tổng hợp miễn giảm.

1.4. Phân hệ “Quản lý hồ sơ bệnh án và viện phí nội trú”

• Lập và theo dõi hồ sơ bệnh án nội trú,
• Quản lý ngày giường bệnh nhân nội trú,
• Quản lý phiếu theo dõi,
• Quản lý phiếu chăm sóc,
• Quản lý phiếu sơ kết,
• Quản lý phiếu khám chuyên khoa,
• Quản lý tờ điều trị,
• Quản lý tờ theo dõi truyền dịch,
• Phiếu thanh toán điều trị nội trú,
• Phiếu thanh toán điều trị nội trú (BHYT thanh toán),
• Phiếu thanh toán điều trị nội trú (BHYT không thanh toán),
• Phiếu thanh toán điều trị nội trú (Bệnh nhân thanh toán),
• Thông báo chi phí,
• Công khai chi phí ngày,
• Tổng hợp chi phí nội trú,
• Tổng hợp chi phí nội trú theo khoa,
• Báo cáo bệnh nhân vào viện,
• Báo cáo bệnh nhân ra viện,
• Báo cáo bệnh nhân trốn viện,
• Báo cáo thanh toán viện phí nội trú,
• Báo cáo thu tạm giữ,
• Báo cáo hoàn ký quỹ,
• Báo cáo miễn giảm viện phí nội trú,
• Báo cáo chi tiết xét nghiệm,
• Báo cáo chi tiết dịch vụ,
• Báo cáo chi tiết giường,
• Báo cáo chi tiết vật tư, thuốc,
• Báo cáo tổng hợp xét nghiệm,
• Báo cáo tổng hợp dịch vụ,
• Báo cáo tổng hợp giường,
• Báo cáo tổng hợp giường theo khoa,
• Báo cáo tổng hợp dịch vụ theo khoa.

1.5. Phân hệ “Quản lý vật tư, thuốc”

• Quản lý phiếu xuất thuốc cho bệnh nhân,
• Quản lý phiếu xuất vật tư cho nhân viên,
• Quản lý phiếu xuất vật tư cho xét nghiệm,
• Quản lý phiếu xuất vật tư tiêu hao,
• Quản lý phiếu xuất trả vật tư, thuốc,
• Quản lý phiếu yêu cầu lĩnh thuốc, vật tư,
• Quản lý phiếu lĩnh thuốc, vật tư,
• Theo dõi nhập xuất tồn thuốc, vật tư,
• Nhật ký xuất thuốc cho bệnh nhân,
• Nhật ký xuất thuốc cho bệnh nhân theo khoa,
• Nhật ký xuất thuốc cho bệnh nhân theo hình thức,
• Nhật ký lĩnh thuốc, vật tư,
• Nhật ký xuất vật tư cho nhân viên,
• Nhật ký xuất vật tư cho xét nghiệm,
• Nhật ký xuất vật tư tiêu hao,
• Nhật ký xuất trả thuốc,
• Tổng hợp xuất thuốc cho bệnh nhân,
• Tổng hợp xuất thuốc cho bệnh nhân theo khoa,
• Tổng hợp xuất thuốc cho bệnh nhân theo hình thức,
• Tổng hợp lĩnh thuốc, vật tư,
• Tổng hợp xuất vật tư cho nhân viên,
• Tổng hợp xuất vật tư cho xét nghiệm,
• Tổng hợp xuất vật tư tiêu hao,
• Tổng hợp xuất trả thuốc,
• Báo cáo chi tiết xuất vật tư,
• Báo cáo xuất nhập tồn,
• Báo cáo chi tiết buồng,
• Báo cáo tổng hợp buồng.

1.6. Phân hệ “Quản lý kết quả xét nghiệm”

• Quản lý mã bệnh phẩm,
• Quản lý kết quả xét nghiệm,
• In kết quả xét nghiệm,
• Báo cáo tổng hợp kết quả xét nghiệm.

1.7. Phân hệ khai báo hệ thống, cấp phát quyền sử dụng

• Khai báo danh mục khu vực,
• Khai báo danh mục phòng khám,
• Khai báo danh mục buồng bệnh,
• Khai báo danh mục hình thức,
• Khai báo danh mục lý do thu,
• Khai báo danh mục xét nghiệm,
• Khai báo danh mục xét nghiệm thành phần,
• Khai báo danh mục dịch vụ,
• Khai báo danh mục loại gường,
• Khai báo danh mục nhóm vật tư,
• Khai báo danh mục vật tư chi tiết,
• Khai báo nhóm báo cáo ngoại trú,
• Khai báo nhóm báo cáo nội trú,
• Quản trị người dùng,
• Sao lưu dự phòng dữ liệu,
• Khôi phục dữ liệu đã sao lưu,
• Tự động sửa lỗi dữ liệu.

1.8. Phân hệ báo cáo tổng hợp dùng cho lãnh đạo

• Báo cáo tổng hợp khám bệnh,
• Báo cáo tổng hợp xét nghiệm,
• Báo cáo tổng hợp dịch vụ,
• Báo cáo tổng hợp vật tư, thuốc men,
• Báo cáo tổng hợp bệnh nhân vào viện,
• Báo cáo tổng hợp bệnh nhân ra viện.

Why some people almost always are successfull

Like everyone else I´ve spent some time thinking about why some people are so successful in life. And what factors in success that are under more personal control than others.

Successful people might be intelligent. Or have had a socially well connected upbringings. Or be naturally energetic and open and positive.

But a lot of the factors that make some people more successful at almost anything in life are very much under their control. And much can be improved in anyone’s life by learning from the people that have gone before us.

Here are some of the thoughts on success that I´ve come up with from reading/watching documentaries throughout the years about people such as Michael Jordan, Thomas Edison, Eleanor Roosevelt and Henry Ford. The following factors of success are just a few and I´m quite sure there are a lot more.

They make decisions and take action
Right or wrong action, they take it. Either way it’s always better than making no decisions and taking no action at all. As Franklin Roosevelt said:

“It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.”

They do things even when they don´t feel like it
I think this is a pretty huge factor. A lot of us back down when we don´t want to do something, even though it may eventually bring us to a wonderful experience or goal. Successful people may not always like doing some of the things they have to do. But they do them anyway. And in the longer run that makes all the difference.

They do the most productive thing right now
Instead of trapping themselves in doing productive but not so important tasks or projects they realise what’s most important and do that. And after they´re done with that they do what´s most important again. Instead of just doing a lot of things, they think and plan before they act and try to focus as much as possible of their thoughts and actions on those few very important things.

They do one thing at a time
Many of them don´t seem to multi-task. Some reasons for avoiding that may be that it creates internal confusion, wastes time and spreads the multi-tasker too thinly. Instead, they do one thing and focus on that until it is done. Then they do the next thing until it is done. Focusing 100% on one task at a time will get it done quicker and better.

They have a positive attitude
A negative attitude can be very damaging and limiting to one´s life. A positive one can open new doors every day. It can open your mind to new ideas and input and create or sustain great relationships. It helps you through the hard times as a successful person often sees an opportunity within what others would merely see as a problem.

Have a look at Take The Postivity Challenge for more thoughts and practical tips for creating a more positive attitude.

They have redefined failure
While a lot of people see failure as a way to rationalizing the feeling of wanting to giving up or as a sign that it´s actually time to do something else successful people tend to see it more as useful feedback. They may not like to fail, but they don´t fear it – or at least they have little fear of it - and they know that if they fail they´ve been there before and they can start over again and succeed. This is of course a very useful belief and keeps successful people going while the rest have already given up.

They don´t let fear hold them back
They overcome fear and slay that dragon whenever they face it. Or they may have defined or redefined reality so that fear is substantially decreased or even gone in some areas of their life.

Doing this enables you to take action on your thoughts. This pulls down the barriers in the mind and create new roads and opens up to whole new possibilities. Have a look at 5 Life-Changing Keys to Overcoming Your Fear for more on both slaying your dragons and redefining your reality to contain less fear.

They have found a purpose in life
They are internally driven rather than externally driven. They do what they have a burning desire to do rather than conforming to what others think they should do. Even if what the others think may be positive and successful stuff.

The Michael Jordans, the Edisons and the Stephen Kings have figured out what they want to do in life and are doing it (or did it).

The purpose, I think, is largely why they can keep on going and be motivated while others may tire or just go and do something else that they find more purposeful. The successes love their purpose and when they aligned with it then it seems to push them forward with enthusiasm and energy through life.

They don´t get distracted
When others get too caught up in everyday life to do what they really want to do the successes don´t. They can really focus on actually doing what´s important and what needs to be done. Again, this seems to go back to having a purpose and more clear sense of direction in life.

They value their time highly and plan it out well
A lot of people don´t value their time that much. Successful people have a purpose in life and therefore they do. They have so much they want and an inner urge to do it and therefore need to plan well to use their days effectively.

They´ve got awesome communication-skills
So very much of what we do in life has to do with other people. So it seems quite obvious that to be successful you´ll probably have to have good or great communication-skills (or hire someone that has such skills).

People skills is fortunately something anyone can improve and develop. Have a look at Do You Do these 10 Mistakes in a Conversation and How to Make a Great First Impression for some useful tips.

They have an open mind and are willing to learn
Successful people take the time to study and learn – and often seem to really like doing it - what is necessary to improve their skills. They are open to thoughts, suggestions, solutions, new information and change rather than thinking they already know everything, that there is not much more to learn and that everything should be as it has always been.

What to focus on?
Now, what factors are the most important ones, where should one focus the energy? I am currently focusing on improving my ability to take action, doing what I may not feel like doing and doing the most productive thing right now. To me it seems like these three factors are very important and since they are pretty interconnected they are easy to combine.

I think what you should focus on varies a lot. And it’s up to everyone to figure that out for themselves. But if you´re anything like me you probably already know what areas you need to work on.

Copy right from PrositiveBlog

Communicating with code

Some people can sell their ideas with a brilliant speech or a slick powerpoint presentation.

I can't.

Maybe that's why I'm skeptical of ideas that are sold via brilliant speeches and slick powerpoints. Or maybe it's because it's too easy to overlook the messy details, or to get caught up in details that seem very important, but aren't. I also get very bored by endless debate.

We did a lot of things wrong during the 2.5 years of pre-launch Gmail development, but one thing we did very right was to always have live code. The first version of Gmail was literally written in a day. It wasn't very impressive -- all I did was take the Google Groups (Usenet search) code (my previous project) and stuff my email into it -- but it was live and people could use it (to search my mail...). From that day until launch, every new feature went live immediately, and most new ideas were implemented as soon as possible. This resulted in a lot of churn -- we re-wrote the frontend about six times and the backend three times by launch -- but it meant that we had direct experience with all of the features. A lot of features seemed like great ideas, until we tried them. Other things seemed like they would be big problems or very confusing, but once they were in we forgot all about the theoretical problems.

The great thing about this process was that I didn't need to sell anyone on my ideas. I would just write the code, release the feature, and watch the response. Usually, everyone (including me) would end up hating whatever it was (especially my ideas), but we always learned something from the experience, and we were able to quickly move on to other ideas.

The most dramatic example of this process was the creation of content targeted ads (now known as "AdSense", or maybe "AdSense for Content"). The idea of targeting our keyword based ads to arbitrary content on the web had been floating around the company for a long time -- it was "obvious". However, it was also "obviously bad". Most people believed that it would require some kind of fancy artificial intelligence to understand the content well enough to target ads, and even if we had that, nobody would click on the ads. I thought they were probably right.

However, we needed a way for Gmail to make money, and Sanjeev Singh kept talking about using relevant ads, even though it was obviously a "bad idea". I remained skeptical, but thought that it might be a fun experiment, so I connected to that ads database (I assure you, random engineers can no longer do this!), copied out all of the ads+keywords, and did a little bit of sorting and filtering with some unix shell commands. I then hacked up the "adult content" classifier that Matt Cutts and I had written for safe-search, linked that into the Gmail prototype, and then loaded the ads data into the classifier. My change to the classifier (which completely broke its original functionality, but this was a separate code branch) changed it from classifying pages as "adult", to classifying them according to which ad was most relevant. The resulting ad was then displayed in a little box on our Gmail prototype ui. The code was rather ugly and hackish, but more importantly, it only took a few hours to write!

I then released the feature on our unsuspecting userbase of about 100 Googlers, and then went home and went to sleep. The response when I returned the next day was not what I would classify as "positive". Someone may have used the word "blasphemous". I liked the ads though -- they were amusing and often relevant. An email from someone looking for their lost sunglasses got an ad for new sunglasses. The lunch menu had an ad for balsamic vinegar.

More importantly, I wasn't the only one who found the ads surprisingly relevant. Suddenly, content targeted ads switched from being a lowest-priority project (unstaffed, will not do) to being a top priority project, an extremely talented team was formed to build the project, and within maybe six months a live beta was launched. Google's content targeted ads are now a big business with billions of dollars in revenue (I think).

Of course none of the code from my prototype ever made it near the real product (thankfully), but that code did something that fancy arguments couldn't do (at least not my fancy arguments), it showed that the idea and product had real potential.

The point of this story, I think, is that you should consider spending less time talking, and more time prototyping, especially if you're not very good at talking or powerpoint. Your code can be a very persuasive argument.

The other point is that it's important to make prototyping new ideas, especially bad ideas, as fast and easy as possible. This can be especially difficult as a product grows. It was easy for me to stuff random broken features into Gmail when there were only about 100 users and they all worked for Google, but it's not so simple when there are 100 million users.

Fortunately for Gmail, they've recently found a rather clever solution that enables the thousands of Google engineers to add new ui features: Gmail Labs. This is also where Google's "20% time" comes in -- if you want innovation, it's critical that people are able to work on ideas that are unapproved and generally thought to be stupid. The real value of "20%" is not the time, but rather the "license" it gives to work on things that "aren't important". (perhaps I should do a post on "20% time" at some point...)

One of the best ways to enable prototyping and innovation on an established product is though an API. Twitter is possibly the best example of how well this can work. There are thousands of different Twitter clients, with new ones being written every day, and I believe a majority of Twitter messages are entered though one of these third-party clients.

Public APIs enable everyone to experiment with new ideas and create new ways of using your product. This is incredibly powerful because no matter how brilliant you and your coworkers are, there are always going to be smarter people outside of your company.

At FriendFeed, we discovered that our API does more than enable great apps, it also reveals great app developers. Gary and Ben were both writing FriendFeed apps using our API before we hired them. When hiring, you don't have to guess which people are "smart and gets things done", you can simply observe it in the wild :)

In my previous post, I asked people to describe their "ideal FriendFeed". Since then, I've been thinking about ideas for my "ideal FriendFeed". Unfortunately, it's very difficult for me to know how much I like an idea based only on words or mockups -- I really need to try it out. So in the spirit of prototyping, I've used my spare time to write a simple FriendFeed interface that prototypes some of the things I've been thinking about. This interface isn't the "future of FriendFeed", it's just a collection of ideas, some that I like, and some that I don't. One thing that's kind of cool about it (from a prototyping perspective) is that it's written entirely in Javascript running in the web browser -- it's just a single web page that uses FriendFeed's JSON APIs to fetch data. This also means that it's relatively easy for other people to copy and change -- you don't even need a server!

Trích blog Paul Buchheit

------------------------------------------------------------------------------
Resume by TuanNM : có những ý tưởng dường như rất với vẩn, nhưng khi implemented lại rất tuyệt vời, ngược lại, cũng có những idea rất tuyệt vời cho đến khi bạn chạy thử nó. Hãy cố gắng implement your idea as soon as possible, đối với các innovation app, đừng quá câu nệ thiết kế ..., việc viết lại code là chuyện hết sức bình thường. Chính tôi đã phạm sai lầm này :(.

Phương pháp học tập hiệu quả

Trong article này, tôi sẽ trình bày về những kinh nghiệm của mình trong việc tiếp cận một vấn đề cho hiệu quả, nhanh chóng nhất.

1. Xác định rõ ràng mình tìm hiểu vấn đề này để làm ji ?

Tuy cùng tìm hiểu một vấn đề, nhưng mỗi người có thể có những mục đích khác nhau, ví dụ :

- Tìm hiểu chỉ để biết rằng nó là ji, nó có tính năng abc ko ?

- Tìm hiểu để biết.

- Tìm hiểu để ứng dụng cho công việc.

- Tìm hiểu để trở thành một chuyên gia trong vấn đề đó.

- ...etc

Với mỗi loại mục đích sẽ có những phương pháp tiếp cận vấn đề khác nhau, và bạn phải ghi nhớ, đừng bao giờ quên mình tìm hiểu vấn đề đó để làm ji, nó sẽ giúp bạn loại bớt dc rất nhiều phần ko cần thiết.

Tuy nhiên, những gì tôi trình bày trong article này chủ yếu với mục đích tìm hiểu để ứng dụng, phát triển và để trở thành một cao thủ trong vấn đề đó.

2. Cố gắng tiếp cận Top-Down sớm nhất có thể.

Để tìm hiểu một vấn đề, chúng ta có 2 hướng tiếp cận Top-Down và Bottom-up, để dễ hình dung bạn có thể liên tưởng đến việc một cuốn sách, bạn tìm hiểu một vấn đề cũng tương đương việc bạn lĩnh hội dc nội dung, tư tưởng mà cuốn sách đó truyền đạt. Vậy thì cách tiếp cận Top-Down là bạn xem mục lục cuốn sách, lựa chọn phần nào đọc trước, phần nào đọc sau, phần nào đọc kỹ, phần nào đọc lướt, và phần nào ko cần đọc, bạn dừng đọc khi bạn đã hiểu đủ những gì cuốn sách đó muốn truyền đạt. Còn cách đọc Bottom-up là cách đọc từng trang, từng trang, tuần tự, sau đó bạn phải xâu chuỗi các thông tin lại với nhau để hiểu được những gì cuốn sách muốn truyền đạt. Ko khó khăn để thấy Top-down đem lại hiệu quả cao hơn rất nhiều, ko chỉ hiệu quả về mặt thời gian đọc, với Top-down bạn sẽ nhanh chóng xâu chuỗi các thông tin, hiểu dc bản chất vấn đề ngay cả khi chưa hiểu đủ vấn đề mà cuốn sách đó trình bày, thêm nữa bạn định vị dc mình đang ở đâu trong quá trình tìm hiểu nội dung cuốn sách.

Tuy nhiên, thực tế ko phải khi nào bạn cũng có ngay một cái “Mục lục” để tiếp cận Top-down, nhất là với những vấn đề hết sức mới mẻ với bạn, vậy thì việc đầu tiên là bạn hãy tìm cho mình một cái “Mục lục” sớm nhất có thể, và chi tiết cái mục lục đó dần dần.

Một cách tổng quát, bạn có thể tiếp cận vấn đề theo qui trình sau :

a. Việc đầu tiên khi tìm hiểu một vấn đề, bạn hãy bắt đầu từ những cái Top, những cái chung nhất. Nhìn chung, những câu hỏi chung nhất bạn cần phải trả lời khi bắt đầu tìm hiểu một vấn đề mới :

• Định nghĩa của vấn đề ?
• Nó ra đời phục vụ mục đích ji ?

Và có thể có thêm một số câu hỏi khác tùy thuộc vào mỗi trường hợp cụ thể. Bạn phải tự xác định, chẳng hạn “Nó dựa trên nền tảng ji ?”, “So sánh nó với xyz như thế nào ? (trong đó xyz là thứ có nhiều cái tương đồng về mục đích sử dụng với vấn đề đang tìm hiểu)”.

Có một số phương pháp giúp bạn có thể trả lời nhanh chóng vấn đề trên :

• Search google với meta key “define”, ex : “define:SOA” (ko có dấu cách) => định nghĩa của SOA, trong đó SOA là tên của vấn đề đang tìm hiểu.
• Tìm trang của Wikipedia nói về vấn đề đó, có thể search bằng google và wiki. Wikipedia là một trong những nguồn tốt nhất để nhanh chóng nắm dc overview của vấn đề.
• Đọc FAQ (Frequently Asked Question) trên trang chủ của vấn đề mình đang tìm hiểu => là một sưu tập các câu hỏi cơ bản nhất, hay dc quan tâm nhất của user tới vấn đề đó.
• Tìm trong Help của vấn đề trên tại chính trang chủ của nó.
• ...etc

Chú ý, mục đích của bạn bây giờ tạm thời là trả lời các câu hỏi chung nhất mà bạn đã liệt kê ra, vậy thì bạn hãy làm thế nào để trả lời nó sớm nhất, xong là chuyển sang giai đoạn khác, tránh đọc sâu vào 1 tài liệu mất thời gian.

b. Hãy tập cách tìm kiếm, tìm các tài liệu cơ bản nhất, phù hợp với trình độ của bạn nhất để đọc. Trên thực tế, có rất rất nhiều các tài liệu khác nhau cùng diễn giải về một vấn đề. Trong hầu hết các trường hợp, cách làm khôn ngoan là hãy dành một khoảng thời gian nhất định để tìm kiếm hàng loạt các tài liệu, sau đó lướt qua từng tài liệu để đánh giá tài liệu nào phù hợp với trình độ mình nhất, trình bày dễ hiểu nhất, sắp xếp thứ tự ưu tiên từng tài liệu để đọc, và biết loại bỏ đi những tài liệu ko tốt, và cuối cùng là đọc các tài liệu theo thứ tự ưu tiên đó. Đó cũng chính là tiếp cận Top-Down, tránh việc cứ tìm thấy tài liệu nào là chúi mũi vào đọc hiểu luôn mà ko cố gắng tìm tiếp các tài liệu khác.

Cách tìm kiếm tài liệu cơ bản như sau :

• Tìm kiếm tại help trên trang chủ của chính vấn đề đó.
• Tìm kiếm trên các bài key của một số forum NỔI BẬT về vấn đề này. Thường các forum focus vào một vấn đề sẽ có những bài dạng basic tutorial, và trong đó họ cũng cung cấp nhiều references.
• Đừng quên các tài liệu video, multimedia, slide => dễ hiểu, tính xúc tích cao. Với các loại tài liệu này có thể dùng slideshare để tìm slide, youtube để tìm video.
• Bên cạnh Google, Torrent cũng là một nguồn tìm tài liệu rất tốt, nhiều trường hợp còn tốt hơn cả Google, đặc biệt với các tài liệu dạng video, hoặc các ebook ko free.
• Nên biết rằng Google ko phải là SearchEngine tốt nhất cho mọi truy vấn, với mỗi loại tìm kiếm, có thể có những SE khác tốt hơn, bạn nên biết qua mấy ưu điểm của SE khác, như Delicious chẳng hạn. Cũng như vậy, để tìm kiếm ảnh, google image cũng ko phải là tốt nhất.
• Tìm kiếm dựa trên các references của một tài liệu đã có, đặc biết đối với các bài báo khoa học, từ có rất nhiều references tới các tài liệu liên quan.

c. Sử dụng Mindjet(*) nhằm “lên mục lục”, bạn nên sử dụng một công cụ hỗ trợ để lên mục lục, xâu chuỗi các ý thu thập dc. Theo kiến thức và kinh nghiệm của mình, tôi cho là dùng Mindmap là lựa chọn tốt nhất, và Mindjet là tool hỗ trợ Mindmap tốt nhất thế giới hiện nay. Mindjet hỗ trợ cực kỳ hiệu quả ko chỉ việc lên mục lục, nhờ việc sắp xếp các thông tin theo cách tiếp cận thông tin của não người (Mindmap – bản đồ tư duy), nó giúp ta nhớ tốt hơn, dễ dàng tổng hợp các thông tin, và tìm ra bản chất vấn đề. Với kinh nghiệm sử dụng Mindjet khá lâu, nó cũng là một tool hỗ trợ ko thể thiếu trong công việc, tôi tin là với sự hỗ trợ của Mindjet, hiệu quả của việc tìm hiểu một vấn đề có thể lên ít nhất 200%.

3. Bắt đầu từ cái cơ bản, không ngừng cố gắng hiểu bản chất vấn đề sớm nhất

Khi tiếp cận một vấn đề, hãy đi từ cái cơ bản đến cái phức tạp, không ngừng cố gắng hiểu được bản chất vấn đề càng sớm càng tốt. Thực tế là ko cần thiết phải đọc hết cả cuốn sách bạn mới hiểu được bản chất của vấn đề cuốn sách đề cập, và ngược lại, ko phải khi nào bạn đã đọc hết cuốn sách rồi tức là bạn đã hiểu được bản chất những gì cuốn sách muốn nói.

Khi bạn đã hiểu được bản chất vấn đề, thì bạn đã đạt được một milestone quan trọng trong quá trình tìm hiểu vấn đề đó, khi đó bạn có thể suy đoán, suy diễn chi tiết hơn về vấn đế, có thể đánh giá phần nào là quan trọng cần tìm hiểu kỹ, phần nào là ko quan trọng có thể bỏ qua.

Tìm đọc các so sánh của vấn đề với những vấn đề khác có nhiều tương đồng về mục đích sử dụng để nhanh chóng hiểu dc bản chất vấn đề. Ngoài ra, bạn phải ko ngừng review, xâu chuỗi các thông tin trong quá trình, tạo ra một sự logic, nhằm tìm ra dc bản chất vấn đề.

4. Dành một thời gian đủ dài và tập trung cho MỘT vấn đề.

Nhiều nghiên cứu chứng minh là hãy dành một thời gian đủ dài và tập trung cho MỘT vấn đề sẽ đạt hiệu quả hơn khá nhiều là mỗi ngày dành 1 ít thời gian, đó là xét trên việc lượng kiến thức tiếp thu / tổng thời gian dùng để học. Tuy nhiên, điều này hoàn toàn khác với kiểu trước khi thi, thức đêm 2 hôm để học bài thì sẽ đạt hiệu quả hơn là học suốt quá trình học, học theo kiểu thuộc mà ko hiểu sẽ rất nhanh quên.

5. Không ngừng thực hành, kiểm thử nếu có thể

Học cần đi đôi với thực hành, thực hành luôn là một trong những cách tốt nhất để tìm hiểu một vấn đề, thực hành sẽ giúp bạn hiểu nhanh hơn, nhớ lâu hơn, và kết quả của những bài thực hành cũng giúp bạn hiểu bản chất nhanh hơn, hóa giải những ji bạn ko chắc chắn. Thực hành đặc biệt quan trọng nếu mục đích tìm hiểu của bạn là sử dụng được cái bạn đang tìm hiểu.

6. Ghi lại những đặc điểm key, những kinh nghiệm thú vị

Hãy tìm cách ghi lại ra đâu đó những đặc điểm key, những trick, những điểm mà mình thấy thú vị, những thông tin cần thiết nhưng khó nhớ ... về vấn đề mình đang tìm hiểu. Nó cần thiết cho việc ghi nhớ, xâu chuỗi các thông tin để tìm ra bản chất vấn đề, nếu như sau này có quên do bẵng đi một thời gian ko sử dụng thì các thông tin được ghi lại này sẽ giúp bạn nhớ lại nó cực nhanh. Việc ghi lại cũng cần đảm bảo tính tra cứu một cách khoa học, ví dụ blog cũng là một lựa chọn tốt. Đừng đánh giá thấp việc ghi lại, cũng đừng nghĩ rằng nó mất thời gian. Tôi đã từng nhiều lần tìm hiểu cách make run một chương trình java từ Console, đây là một thao tác ít dùng, khó nhớ, nhưng lại cần thiết. Việc note lại rất đơn giản, và nhanh chóng vậy mà tôi đã ko làm, kết quả cứ mỗi lần cần make-run một chương trình java lại search google, rồi thử cho đến một ngày tôi quyết định note “how to make run a java program” lại.

7. Liên tục cập nhật kiến thức

Một lĩnh vực cần tìm hiểu luôn luôn có rất nhiều thứ để biết, hơn nữa chúng luôn vận động => ko bao giờ bạn có thể biết tất cả về một vấn đề => nếu bạn ngừng cập nhật bạn sẽ nhanh chóng lỗi thời, và nếu bạn lỗi thời, bạn ko phải là một chuyên gia trong lĩnh vực đó.

Cách thức giữ cho mình update trong một lĩnh vực tốt nhất và hiệu quả nhất là hãy THAM GIA CỘNG ĐỒNG CÙNG CHUYÊN MÔN.

Khi bạn chưa thực sự tham gia vào cộng đồng cùng chuyên môn, bạn mãi mãi là ếch ngồi đáy giếng, khi bạn chưa thể xác định rank của mình trong cộng đồng chuyên môn, thì bạn đừng nói với người khác rằng tôi rất giỏi về vấn đề abc gì đó.

Việc tham gia cộng đồng chuyên môn có hai mức độ :

a. Thụ động : bạn liên tục cập nhật thông tin từ cộng đồng, hoặc các nguồn tin về chuyên môn, tuy nhiên bạn chỉ đóng vai trò đọc tin, và nắm bắt các thông tin, chứ ko đóng góp thêm vào các nguồn thông tin, tương tác với cộng đồng cùng chuyên môn là tương tác 1 chiều.

b. Chủ động : bạn ko chỉ đọc tin, mà bạn con tham gia tương tác trong cộng đồng chuyên môn, bổ sung thêm thông tin vào cộng đồng.

Đừng đợi đến khi nắm hết cơ bản rồi mới tham gia cộng đồng, bạn có thể làm thao tác đó ngay khi bắt đầu tìm hiểu vấn đề, và luôn duy trì update, chẳng hạn như :

• Subscrire maillist để nhận tin, và có thể hỏi lúc nào cần thiết. Thường thì chúng ta sợ spam, nhưng Ymail và Gmail đều có filter, biết sử dụng chúng thì chúng ta sẽ ko ngại đăng kí maillist nữa. Thường trên trang chủ của vấn đề đó sẽ có maillist, tuy nhiên cũng có thêm một cách khác để tìm mail group của lĩnh vực liên quan, đó là sử dụng Google Group, để tìm các Gmail Group.
  

• Sign up account forum. Cũng nên đánh giá qua xem forum đó có tốt ko, qua tần số bài viết mới, thời gian feedback có nhanh ko, rank alexa của forum ...etc. Nói chung là chúng ta nên tham gia forum tốt nhất về lĩnh vực đó, tham gia nhiều forum cùng loại hơi mất thời gian.

• Tìm một số blog chuyên môn, lấy RSS của nó add vào Netvibes của bạn, hoặc iGoogle, hoặc Google Reader,... Việc sử dụng các công cụ đọc RSS sẽ tiết kiệm rất rất nhiều thời gian. Bạn có thể tìm blog dựa vào một số search engine chuyên search blog, ex : Google Blog, Technorati...

• Lấy RSS của một số trang magazine chuyên môn, cho vào trình đọc RSS của bạn.

• Tìm một số expert trong lĩnh vực đó, và follow họ nếu có thể (nhất là nếu họ dùng Twitter).

• Tham gia group của một số mạng xã hội như, Facebook, Linkedin. Tuy nhiên, dường như tôi thấy các group này thiên về tương tác giữa các thành viên hơn là tập trung vào chuyên môn, tuy nhiên bạn có thể biết đến thêm những expert khác trong cùng lĩnh vực quan tâm.
  

• Sẵn sàng hỏi khi cần thiết, bạn sẽ tiết kiệm dc khá nhiều thời gian, tuy nhiên, đừng nên hỏi những câu hỏi cơ bản quá, nhiều người đã hỏi rồi => khó chịu. Bởi vậy nên search qua trước, bằng Google, hoặc search trên forum đó, trong trường hợp forum đó ko hỗ trợ tính năng search, bạn có thể sử dụng metakey site của google, ex : site:muare.com máy chiếu => dùng để tìm “máy chiếu” trong forum muare.com. Ngoài ra hỏi trên Twitter cũng là một cách, nếu bạn bè của bạn cũng cùng nghiên cứu vấn đề này.

• ...etc

8. Luôn ghi nhớ “lúc nào cũng có thể tìm được cách làm tốt hơn”

Luôn tồn tại những công cụ hỗ trợ học tập mà ta chưa biết tới, hãy luôn tự hỏi “có cách nào có thể làm tốt hơn hay ko ?”. Ngay cả với Mindmap, bạn muốn sử dụng hiệu quả Mindmap cũng ko phải dễ. Ngoài ra, khi nghiên cứu về trí nhớ, người ta có thể thống kê dc một số mẹo nhằm nhớ nhanh, nhớ lâu, hiểu nhanh hơn, chẳng hạn như :

• Học kiều nhồi nhét sẽ ko đạt hiệu quả về mặt nhớ lâu.
• HIỂU bản chất vấn đề thì sẽ nhớ lâu hơn.
• Hãy tổ chức, cấu trúc hóa các thông tin tìm hiểu dc (Mindmap là công cụ khá lí tưởng).
• Hãy liên kết, so sánh vấn đề ta đang tìm hiểu đến những kiến thức mà ta đã biết.
• Hãy Visualize vấn đề của bạn lên => Mindmap là một trong những lựa chọn.
• Dạy ai đó vấn đề này, hoặc viết review về nó => rất tốt cho việc xâu chuỗi các vấn đề để hiểu bản chất, phát hiện ra các lỗ hổng kiến thức.

… và rất nhiều nữa, những phương pháp mà tôi và bạn đều chưa biết tới.

* Mindjet : là công cụ dùng để vẽ Mindmap, nó ko free, tuy nhiên có thể sử dụng các lựa chọn free khác như Xmind, FreeMind. Theo tôi, Xmind tốt hơn Freemind.

Các module, thủ tục có thể sử dụng trong nhiều dự án khác của GTID

Những module có thể tái sử dụng với những dự án khác nhau. Đây là nơi tổng hợp những module có tính tái sử dụng cao, có thể sử dụng trong nhiều dự án, chúng ta sẽ cập nhật theo thời gian, để các team khác biết, tránh thực hiện code lại những ji đã code và test rồi.
- Module phục vụ suggestion C# phía server và JS phía client(giống kiểu các SearchEngine trả về các gợi ý realtime khi ta đánh query), trả về danh sách string tương ứng với một đoạn string đầu vào. Module này đã dc viết khá tối ưu, với độ phức tạp hằng số, hoàn toàn có thể thích ứng với cả danh sách hàng triệu string mà ko vấn đề gì.

- Những thao tác phổ biến trên Array, List viết trên C#, viết dưới dạng template, có tính tái sử dụng cao, các dự án dùng C# khác sẽ ko phải code lại những hàm này :

• Tìm kiếm nhị phân trên Array, List đã sắp xếp tăng dần rồi.
• Hàm chèn một phần tử vào một danh sách đã sắp xếp mà vẫn bảo toàn tính sắp xếp của nó.
• Hàm xác định vị trí để insert 1 phần tử vào một danh sách tăng dần.
• ...

- Module xác định nước truy cập của user bằng C#, dùng khi ta muốn biết một user truy cập website của mình thuộc nước nào.

- Module quản lí tree, và forest với relation database, sử dụng giải thuật MPTT viết bằng C#, support các hầu hết thao tác cơ bản trên tree hay forest như tìm các tổ tiên, con cháu của 1 hoặc 1 nhóm node, thay đổi parent, xóa đi một node ... Giải thuật MPTT cho phép quản lí tree/forest có kích thước lớn với cơ sở dữ liệu quan hệ.

- Module counter, bộ đếm số người truy nhập trang web => có module sẵn rồi, ko phải code chức năng này.

- Module nhận feedback của người dùng, đã có sẵn, tích hợp với tool bugtracking, ko cần code module này trong mọi dự án bất kể ngôn ngữ hay platform, trừ khi chúng ta ko có trách nhiệm nhận feedback của user đối với dự án đó.

(tiếp tục cập nhật theo thời gian).

Sử dụng Netvibes để nâng cao hiệu quả công việc

Netvibes cũng là một dịch vụ Web2.0 rất phổ biến, luôn nằm trong danh sách những ứng dụng Web2.0 xuất sắc của năm trong 2-3 năm trở lại đây. Từ khi sử dụng nó, thật sự nó cải thiện hiệu quả đọc tin của mình lên rất rất nhiều, cũng là một dịch vụ 2.0 ko thể thiếu đối với mình. Netvibes là trang web đầu tiên được mở ra khi tôi bật trình duyệt, và nó cũng chỉ được đóng lại khi tôi tắt Firefox, thời gian Netvibes được mở chiếm > 95% thời gian tôi sử dụng laptop.
Netvibes sẽ thay đổi cách bạn lướt web, gia tăng hiệu quả đọc tin tức của bạn lên 10-30 lần, tiết kiệm rất nhiều thời gian hàng ngày bạn sử dụng để lướt web. Ngoài ra, Netvibes cũng là công cụ số một giúp bạn thường xuyên giữ mình update, giúp bạn có một tầm nhìn tốt hơn trong lĩnh vực bạn quan tâm.
Dưới đây là video hướng dẫn sử dụng Netvibes (các video đều có tiếng nhé).
1. Cách thức "lướt web" với Netvibes.


2. Cách để add một site quan tâm vào Netvibes với điều kiện trang đó hỗ trợ RSS, nói chung hiện ngay phần lớn các trang web thông dụng đều hỗ trợ RSS, bạn làm theo video hướng dẫn sau.


3. Bình thường thì để tạo một trang Netvibes cho riêng mình, bạn phải mất khoảng 3h đồng hồ, tuy nhiên mình đã share trang của mình tại http://netvibes.com/conquerorvn, bạn có thể làm theo hướng dẫn trong video để có một trang Netvibes của riêng mình trong vòng 40phút.


Chúc các bạn thành công.
Go Together In Development.

Sử dụng Delicious để nâng cao hiệu quả công việc

Là ITer, chúng ta thường xuyên phải bookmark lại một số link hay. Chắc chắn các bạn đều đã biết sử dụng tính năng bookmark của IE và Firefox rồi, tuy nhiên, sử dụng chúng có một số hạn chế sau :

• Ko truy nhập dc danh sách bookmark của mình khi thay đổi máy.
• Khi đang ngồi trên máy khác, cũng ko thể add thêm một link hay vào danh sách bookmark của mình.
• Khi số lượng book mark của mình bắt đầu > 100 thì việc quản lí, và tìm lại link mình đã bookmark trở lên khó khăn.
• Khi lỡ mình format cài lại hệ điều hành (một thao tác có khả năng xảy ra khá cao), chúng ta sẽ đánh mất danh sách bookmark của mình nếu quên ko backup lại.

Hôm nay mình sẽ giới thiệu với các bạn một công cụ khác, một social bookmarking no1 thế giới hiện nay, Delicious. Delicious ra đời để giải quyết tất cả các hạn chế nói trên, hiểu một cách đơn giản Delicious tổ chức lưu trữ các link online, sử dụng Delicious với một plugin cho trình duyệt là một giải pháp vượt trội so với phương pháp thông thường, từ khi sử dụng delicious, nó đã trở thành một công cụ ko thể thiếu của mình, giúp cải thiện công việc đáng kể. Ngoài ra, Delicious còn có thể cho phép ta import danh sách link thuộc bookmark trong trình duyệt, vậy tại sao bạn ko chuyển sang sử dụng Delicious từ bây giờ nhỉ, cam đoan bạn sẽ hài lòng với quyết định của mình.
Dưới đây là video hướng dẫn sử dụng Delicious, dài 13 phút (có tiếng).

Link down video.

Link Delicious plugin for firefox. Với IE cũng có plugin, bạn tự google nhé, tuy nhiên chúng ta quên dần IE đi là vừa.
Bạn có thể truy cập vào link http://delicious.com/conquerorvn để khám phá kho link của mình, dựa theo các tag để tìm link, mình tin là bạn sẽ tìm dc nhiều link thú vị

Sử dụng Delegate trong lập trình

Bên cạnh Generic Programming (Template Programming), thì Delegate cũng là một trong advanced technique trong lập trình C#. Lần trước tôi đã giới thiệu mọi người Generic Programming, lần này tôi xin giới thiệu Delegate trong C#, trong Java chưa có kỹ thuật tương tự. Nếu biết tận dụng delegate, việc code sẽ trở nên tổng quát hơn, ngắn gọn hơn, tính tái sử dụng tăng cao, và performance giảm ko đáng kể.
Hiểu một cách đơn giản, Delegate tương tự như con trỏ hàm trong C++, nó là con trỏ hàm bởi nó có thể trỏ vào các hàm khác nhau (nếu các hàm đó có cùng giao diện), và người ta có thể gọi một hàm thông qua con trỏ hàm, bằng cách cho con trỏ hàm trỏ vào hàm đó, và call con trỏ hàm cũng tương đương việc call hàm được con trỏ hàm trỏ đến.

Khai báo delegate, chú ý delegate ngang hàng với khai báo class tương tự enum và struct, hãy khai báo delegate bên ngoài class, ex :

public delegate int Compare(int inA, int inB);

Hoặc tốt nhất là khai báo khai báo dạng template, tăng tính tái sử dụng.

public delegate int Compare<T>(T inA, T inB);
public delegate int Compare<T, E>(T inA, E inB);

public delegate T DFunc0Para<T>();
public delegate T DFunc1Para<E, T>(E x);
public delegate T DFunc2Para<E, F, T>(E x, F y);
public delegate void DProc1Para<E>(E x);
public delegate void DProc2Para<E, F>(E x, F y);

Giao diện một delegate sẽ đại diện cho các hàm mà delegate này có thể trỏ tới, gồm kiểu trả về và danh sách tham số, còn tên delegate hay tên hàm ko quan trọng.

Khai báo một biến có kiểu Delegate :

Compare<string> compare;

Thực hiện trỏ một delegate tới một hàm, ex :

compare = Compare;

Call một hàm thông qua delegate :

compare("heno", "hi");

Ví dụ đơn giản :

// ham dc khai bao de cho delegate tro toi
private int CompareFunc(string x, string y)
{
   return x.CompareTo(y);
}
public void testDelegate()
{
   // khai bao bien kieu Delegate
   Compare<string> compare;

   // thuc hien tro bien delegate den ham Compare ben tren,
   // giao dien cua ham va Delegate phai tuong thich thi moi tro dc
   compare = CompareFunc;

   // thuc hien call delegate
   int val = compare("heno", "hi");
}

Một số ví dụ sử dụng delegate :
- List.RemoveAll và List.ConvertAll : List là lớp sẵn có của C#, và giao diện của RemoveAll và ConvertAll như sau :

public int RemoveAll(Predicate<T> match);
public delegate bool Predicate<T>(T obj);

public List<TOutput> ConvertAll<TOutput>(Converter<T, TOutput> converter);
public delegate TOutput Converter<TInput, TOutput>(TInput input);

Và sau đây là ví dụ đoạn code sử dụng chúng, cho thấy cách sử dụng delegate, ví dụ sau cho thấy là ta có thể truyền một function như là tham số của function khác.

public class Test{
   public void testListAndDelegate()
   {
       List<int> listNo = new List<int> (new int[]{1, 2, 3, 3, 4, 5, 6, 5, 3});

       // thuc hien xoa cac element co gia tri 3 trong listNo
       // trong do equalThree la mot function dc khai bao ben duoi
       listNo.RemoveAll(equalThree);

       // thuc hien chuyen listNo thanh mot danh sach List tuong ung
       // trong do Convert.ToString la mot function cua C# co
       // khai bao "public static string ToString(int no)"
       List<string> listStr = listNo.ConvertAll<int, string>(Convert.ToString);
   }
   private bool equalThree(int no)
   {
       return (no == 3);
   }
}

- Tìm kiếm sử dụng Delegate thay vì sử dụng IComparer :
Đây lại là một ví dụ sử dụng Template Delegate, dc dùng trong hàm LinearSearch, hàm này viết dưới dạng Template, nên có thể thích ứng với rất nhiều input khác nhau

public class CommonFunction{
   // ham nay tra ve vi tri cua phan tu thuoc array of type  tuong ung voi key of type 
   // trong do E va K la hai kieu bat ki
   // Compare la delegate da dc khai bao ben tren
   public static int linearSearch<E, K>(List list, K key, Compare<E, K> compare)
   {
       for (int i = 0; i < list.Count; i++) {
           if (compare(list[i], key) == 0) {
               return i;
           }
       }
       return CommonConstant.UNFOUND;
   }
}// end of CommonFunction
/////////////

public struct Pair{
   public int no;
   public string name;
   public Pair(int inNo, string inName){
       no = inNo;
       name = inName;
   }
}

public class Test{

    // khai nay dc khai bao de su dung nhu la tham so 
    // cho ham linearSearch ben duoi
   private int compareFunc (Pair x, int y)
   {
       return x.no.CompareTo(y);
   }

   public void testLinearSearch()
   {
       List<Pair> list = new List<Pair>();
       list.Add(new Pair(1, "Mot"));
       list.Add(new Pair(3, "Ba"));
       list.Add(new Pair(4, "Bon"));
       list.Add(new Pair(2, "Hai"));

       // tiep theo, ta muon tim index cua phan tu tuong ung voi "no" = 3,
       // ta chi can code nhu sau, compareFunc chinh la ham ben tren 
       int index = CommonFunction.linearSearch(list, 3, compareFunc);
   }

}// end of Test

7 Element of Highly Successfull Software Projects

Successfully executing a software project, requires a clearly defined plan that all parties understand and endorse. It also requires effective teamwork and people who are willing to put their shoulder against the work everyday. Once a team is ready to execute the work project, the focus needs to be on doing the right things and having systems in place to compensate for inevitable miscommunication and human errors.

Before laying out the game plan necessary for successful project execution, though, I’d like to share a broader thought about getting things done at work: Just do it! In my experience, it’s far better to take action than to procrastinate while obsessing about making things perfect. Perfection is nearly impossible to achieve, although it’s a worthy goal and one we strive for when developing software for our customers. Rather than software, I’m referring to general business decisions about priorities. I’ve seen too many organizations virtually grind to a halt over a single issue, or the inability of top managers to make a tough decision. Don’t let this happen to you. It’s better to move and get things done than to let organizational rigor mortis set in.

Few professionals readily admit to being “process oriented,” which connotes images of anal-retentive individuals who are so busy cataloguing trees they completely miss the proverbial forest. I’d like to challenge that perception. People who can follow a carefully designed process are most likely to achieve success. This is a fact CEOs understand. When asked to name the main reason for the success of their companies, 75 percent of the CEOs leading Inc magazine’s top 500 companies said “superior execution in a mundane business.”

That’s pretty mind boggling, but it makes sense when you consider that more businesses face being reduced to a commodity due to global competition. When every corner shop can offer gourmet coffee, it’s the shop whose employees remembers customers, greets them sincerely and serves orders in record time that stands out from its competition. Taking the time to focus on the little things can add up to big profits over time.

The rest of this chapter will focus on the best process for writing software and successfully launching a major software initiative. When viewed broadly, these steps are just as valid for any type of business initiative or major project. In fact, the process I advocate has a lot in common with best practices used in building anything.

Finally, as a side note, there’s been and continues to be different approaches on how to manage projects—waterfall, agile, lean, and the list goes on. While these different approaches each have their merits, as it relates to this chapter, I’m not advocating a specific method. And, while a lot more needs to be done to make projects successful, I haven’t seen a project that lacks one of the “7” elements missing and be successful.

Projects are tough. For software, Gartner Group estimates that approximately 75 percent of software projects fail due to lack of technical consideration or poor business planning. Why is it so hard? What can be done? Here are the common elements of every project that we’ve shipped:

1. Getting the right team
2. Defining the problem
3. Working effectively together
4. Communicating frequently
5. Working smart
6. Constantly improving the process
7. Understanding the end game

Miss one or two of the above, you join the majority in the 75 percent.

1. Getting the right team

The topic of human capital (recruiting, motivating, retaining, etc.) fills bookshelves at the local Barnes and Noble. And it should. Studies show that top performers out produce low performers by a factor. In software it is a factor of eight-to-ten times. I won’t try to cover this in depth but below are a few of the big rocks to get the best people:

• Get the best work. Great talent is drawn to great work. For Generation Y, get ready. Research suggests they are as committed to the work as the firm. When the work goes bad, they go (Generation Y is the age of five to the mid-20s).
• Take the time. I attended a class at Harvard. Several case studies had recruiting in the study. One of the firms, known for having the best-of-the-best talent, does 25-40 interviews. Yes, you read that right. When adding to your team, honor your interview process (don’t skip steps) and invest the time on the front end to ensure a tight fit between the new employees’ and your company’s values and performance.
• People leave people. People don’t leave companies—people leave people. Pick your leaders wisely and employee retention is simple.

2. Defining the Problem

Ever heard the adage “a problem defined is half solved”? This is especially true in software. An IBM study by Felix & Watson found that well-defined objectives were the number one factor in successful projects. Expect the following in your plan:

• Project plan. This high-level document defines the project vision and Critical Success Factors—i.e., what the project must deliver to be considered a success, and areas of responsibility.
• A requirements document. This defines “project complete.”
• A prototype, mock-up, or demo. Most people are visual. A visual tool is a clear way to communicate and take care of misunderstandings.
• A Gantt chart or Sprint Plan. A Gantt chart states who, what, when and defines interdependencies. In other methodologies, like Agile, a formal Gantt chart may be replaced by a simpler “Sprint”—a list of the highest priority development items to tackle in the next 30 days.
• A risk plan. It should define what’s likely to go wrong and what happens when it does.

Depending on the project, there may be additional documents required. For example, in software there are additional documents like a functional design specification, a logical and physical model of the problem, and test scripts to define what complete and functional means. Beginning without a clear plan is like building a house without a blueprint.

3. Working Effectively Together

Expect small teams, phased releases and frequent deliverables. An ideal project team is four to six. This size is large enough to have effective dialogue and collaborative thought, but small enough to be efficient. If the project is large, break it up into pieces tackled by teams of four-to-six people.

Working with an outside vendor introduces challenges. All are manageable. To work effectively:

• Define clear lines of responsibility. To stop turf wars before they start, clearly define the role of vendor and communicate this with your staff.
• Clearly state expectations. The documents shared in 2. Defining the Problem, puts everyone on the same page.
• Choose a central point of contact. This should happen on both ends.
• Clearly state priorities. When flushing out the functional requirements, prioritize features. When the releases are being defined, it is key to know what is a “go” vs. “no go” feature.
• Constantly communicate (see next section for more on this important topic).

4. Communicating Early and Often

In fast-moving environments—most companies today—daily huddles can keep communication consistent and effective. Intertech uses huddles. In huddles, which take no more than 15 minutes:

• Each team member gives an update. This streamlines communication and reduces one person having to retell their story throughout the day.
• The daily number is shared. This is a number that measures the bottleneck or health of the project. The number changes throughout the project. For example, in software beta testing, this could be number of outstanding bugs. If you have six data consecutive points in any direction, you have a trend.
• Each team member shares a stuck item. Sharing a stuck item brings up issues early, often and enables the slaying of monsters (problems) while they’re little.

Huddles can cascade to keep everyone on the same page. For example, if there are three project teams working on the overall project, the separate project teams have a huddle followed by a huddle of the three project leads and their superior.

It can be tempting to forgo communication tools, like huddles, when you’re in the end game and near project finish. This is when you need them most. If you’re working on a longer project, build in systems that create a frictionless environment. At Intertech, twice per year, we ask our people:

• • Name one thing we should stop doing, start doing, and continue doing.
  • Name a hassle for you, a hassle for our team, and a hassle for our customer (internal or external). A hassle is a second wasted doing something that could be avoided by making a change to how work is done.

The above help remove the “noise” that stops people from doing their work effectively.

5. Working Smart

IBM built an empire on the word “think.” Thinking is key to deploying applications on time. To get people thinking:

• Encourage team members to constantly ask “What could be done today that would have greatest impact on the future of the project?” For example, I’ve seen expensive developers without computers because a manager was “too busy” to order them a few weeks back.
• Keep meetings, including daily huddles, focused. Set meetings for first or last thing in the day or right before lunch. Cut off talkers. Honor time.
• Don’t let meetings make more work. If you have the decision makers together in a huddle and a decision needs to be made, do it.
• Remember 12-hour workdays aren’t 12-hour workdays. If projects are being completed because the modus operandi is ongoing 12-hour workdays, the real work accomplished in the day will cease to happen during the entire12 hours. People still need to eat, see their families, have friends, get their clothes cleaned, etc., and they’ll find ways to do just that even if you expect a 12-hour work day. In other words, don’t encourage an environment where “crunch time” is “business as usual”—it loses its meaning and effectiveness.
• Remember there is no silver bullet. Success is the result of series of things consistently done well. If in the heat of the project, there’s an idea, solution, team member, or vendor that has “the fix” and it sounds too good to be true (you know what’s coming) it probably is!

6. Constantly Improving the Process

Because this isn’t the last project you’ll be delivering:

• Be prepared to change. For example, in software, good software doesn’t die it just changes a lot (think of MS Word). Factor in ongoing maintenance and changes from the start.
• Follow some process. Before we can improve something, we need to understand what it is. Follow a process proscribed by your vendor then make it your own and constantly improve upon it.
• Encourage reviews. No one has the corner on good ideas. Even if you are moving fast, get buy in and check off.
• At project end, make sure that you’ve got the completed set of documentation.
• Do a post mortem. Don’t blame. Ask “What could be done to make it better?”

7. Understanding the End Game

The End Game, the time right before the project finishes, can be difficult. It’s manageable if you follow a few simple steps:

• Keep teams on track. Tell them to turn off e-mail and voice mail, and stay focused. Beyond the huddles, hold off on other meetings that may be “fluff.”

• Keep the work in a known state. With multiple people making changes to a project, ensure that the details are pulling together. For example, in software, this means building the entire application daily.

• Everyone should ask, “Is what I’m doing going to help us complete the project?” This may mean skipping helping out with interviews, sitting through all company meetings, etc.

• Ask, “Does the problem need to be fixed?” For example, in software when a project is nearing completion and there are small things that are not quite right, sometimes fixing the bug can introduce more bugs. Is the problem something you can live with and fix at a later time or is it critical?

• At the end of the project, when people are verifying the work is complete (in software this is QA), this is not the time to solicit and add more to the project. It’s the time to nail the requirements and get to done.

• If a project deliverable date needs to be changed, don’t change one bad date for another. If a revised date is set, get the team involved in setting the date, and the hit it no matter what.

Celebrate and recognize team members when the project is finished. Whether it’s formal or a beer out with the team, it matters. While there are more things we need to do to be successful in managing projects, these guidelines cover the minimum basics needed to finish on time and on schedule.

---

Trích CodeProject, một bài viết hay, có nhiều kinh nghiệm bổ ích, hi vọng trong tương lai chúng ta sẽ ko mắc phải những sai lầm cơ bản mà article này đã đề cập. Tôi đang xem xét dịch bài này sang Tiếng Việt cho anh chị em dễ đọc. Tuy nhiên, nếu đọc tiếng Anh thì version tiếng Anh có lẽ vẫn hay hơn.