TRUNGTQ

Think Big, Act Small, Fail Fast and Learn Rapidly

NAVIGATION - SEARCH

'Ma trận Eisenhower' - Để sống cuộc đời hiệu quả như một tổng thống Mỹ

Dwight Eisenhower đã sống một cuộc đời hiệu quả nhất mà ít ai có thể tưởng tượng được...

'Ma trận Eisenhower' - Để sống cuộc đời hiệu quả như một tổng thống Mỹ

 

Eisenhower là Tổng thống thứ 34 của Hoa Kỳ, ông phục vụ hai nhiệm kỳ liên tiếp từ năm 1953 đến năm 1961.

Trong thời gian đương nhiệm tại Nhà Trắng, ông đã đưa ra chương trình trực tiếp dẫn đến sự phát triển của hệ thống Xa lộ liên tiểu bang Hoa Kỳ, sự ra đời của Internet (DARPA ), chương trình thăm dò không gian (NASA), và việc sử dụng hòa bình các nguồn năng lượng thay thế (Luật Năng lượng nguyên tử - Atomic Energy Act).

Trước khi trở thành Tổng thống, Eisenhower là vị tướng năm sao trong quân đội Hoa Kỳ, từng là Tư lệnh tối cao của lực lượng đồng minh châu Âu trong Thế chiến II, và chịu trách nhiệm lập kế hoạch và tham gia chiến trường tại Bắc Phi, Pháp, và Đức.

Ngoài ra trong sự nghiệp của mình, ông còn giữ chức Hiệu trưởng của Đại học Columbia, trở thành Tư lệnh tối cao đầu tiên của NATO, và bằng cách nào đó ông vẫn sắp xếp được thời gian để theo đuổi sở thích chơi golf và vẽ tranh sơn dầu của mình.

 

Eisenhower có một khả năng phi thường để duy trì năng suất làm việc của mình không phải chỉ trong nhiều tuần hoặc nhiều tháng, mà là trong nhiều thập kỷ. Vì lý do đó, không ngạc nhiên khi mà các phương pháp quản lý thời gian, công việc và năng suất làm việc của ông đã được nhiều người bỏ công để nghiên cứu.

Chiến lược làm việc hiệu quả nổi tiếng nhất của ông đã được đặt tên là Eisenhower Box (Ma trận Eisenhower) và đó là một công cụ ra quyết định đơn giản mà bạn có thể áp dụng ngay từ bây giờ.

Chúng ta hãy tìm hiểu xem làm thế nào để có thể làm việc năng suất hơn và Eisenhower Box hoạt động ra sao.

Ma trận Eisenhower: Làm thế nào để làm việc năng suất hơn

Áp dụng chiến lược của Eisenhower thực ra rất đơn giản. Sử dụng ma trận dưới đây, bạn sẽ phân tách các hành động của mình theo 4 khả năng.

1. Khẩn cấpquan trọng (nhiệm vụ cần phải làm ngay lập tức).

2. Quan trọngnhưngkhông phải khẩn cấp (nhiệm vụ được lên kế hoạch để làm sau).

3. Khẩn cấpnhưngkhông quan trọng (nhiệm vụ sẽ được giao phó cho người khác).

4. Không khẩn cấpcũngkhông quan trọng (nhiệm vụ sẽ được loại bỏ).

Điều tuyệt vời về ma trận này đó là nó có thể được sử dụng cho cả những kế hoạch lớn. Ví dụ, “Tôi nên sử dụng thời gian như thế nào mỗi tuần?" và những kế hoạch nhỏ hơn, “Tôi nên làm gì trong ngày hôm nay?".

Dưới đây là một ví dụ về Eisenhower Box áp dụng cho một ngày:

 

Sự khác biệt giữa khẩn cấp và quan trọng

"Việc quan trọng thường không khẩn cấp và việc khẩn cấp thường không quan trọng" - Dwight Eisenhower

Việc khẩn cấp là những việc mà bạn cảm thấy cần phải giải quyết ngay lập tức như: email, điện thoại, tin nhắn, tin tức mới. Trong khi đó, theo lời Brett McKay nói thì “Những việc quan trọng là những việc làm đóng góp vào nhiệm vụ, giá trị và mục tiêu mang tính chất dài hạn”.

Nếu tách biệt sự khác nhau giữa chúng một lần thì khá đơn giản, nhưng tiến hành một cách liên tục có thể gặp khó khăn. Điều tuyệt vời của ma trận Eisenhower là nó cung cấp một bộ khung rõ ràng cho các quyết định lặp đi lặp lại liên tục. Và cũng giống như bất cứ điều gì khác trong cuộc sống, kiên nhẫn là điều tối quan trọng.

Dưới đây là một số quan sát khác mà tôi đã thực hiện từ việc sử dụng phương pháp này.

Loại bỏ trước khi tối ưu hóa

Vài năm trước, khi tôi đang đọc một tài liệu về lập trình máy tính thì tình cờ đọc được một câu trích dẫn khá thú vị:

“Chẳng có code nào nhanh hơn là không code” - Kevlin Henney

Hiểu theo nghĩa khác, cách nhanh nhất để hoàn thành một việc nào đó, cho dù là dùng máy tính để đọc một dòng lệnh hay loại đi một dòng nhiệm vụ trong danh sách công việc phải làm của bạn – là bỏ qua luôn nhiệm vụ đó.

Không có cách nào làm một công việc nhanh bằng việc không làm gì cả. Đó không phải là lý do khiến ta trở nên lười biếng mà là một gợi ý khiến ta có thể ra quyết định khó khăn và loại bỏ bất kỳ nhiệm vụ nào không giúp bạn hoàn thành nhiệm vụ và mục tiêu của mình.

Thông thường, chúng ta lấy năng suất công việc, quản lý thời gian và sự tối ưu hóa như một lý do để lảng tránh những câu hỏi hóc búa: “Thật sự tôi có phải làm điều đó không?”.

Quả là dễ dàng hơn rất nhiều khi duy trì sự bận rộn và tự động viên bản thân rằng ta chỉ cần làm việc hiệu quả hơn một chút hoặc “Ở lại làm việc muộn hơn một chút” hơn là phải chịu đựng sự bứt rứt khi bỏ đi công việc dễ chịu mà bạn đang làm, nhưng đó không phải là cách sử dụng hiệu quả nhất thời gian của bạn.

Như Tim Ferriss từng nói: “Bận rộn hình thành nên sự lười biếng, lười suy nghĩ và hành động bừa bãi“.

Phương pháp của Eisenhower đặc biệt hữu ích vì nó buộc chúng ta đặt ra câu hỏi liệu một hành động có thật sự cần thiết, từ đó dần dần chúng ta tiến tới “Bỏ đi” nhiệm vụ đó chứ không phải còn lặp lại nó một cách vô thức.

Thành thật mà nói, nếu ta cứ đơn giản loại bỏ tất cả những điều khiến ta lãng phí thời gian mỗi ngày thì có lẽ sẽ không cần bất kỳ lời khuyên nào nào nữa.

You can do it!

You can do it!

Phương pháp này có này sẽ giúp tôi hoàn thành mục tiêu chứ?

Một lưu ý cuối cùng: Sẽ rất khó khăn để loại bỏ những công việc khiến bạn lãng phí thời gian nếu bạn không chắc chắn bạn đang muốn làm điều gì.

Có hai câu hỏi sau đây có thể giúp làm rõ toàn bộ quá trình đằng sau phương pháp của Eisenhower:

1. Tôi đang làm việc vì cái gì?

2. Các giá trị cốt lõi định hướng cuộc sống của tôi là gì?

Trả lời những câu hỏi này sẽ giúp chúng ta phân loại rõ từng nhiệm vụ trong cuộc sống thành các nhóm khác nhau. Quyết định những việc phải làm và những việc phải bỏ đi sẽ trở nên dễ dàng hơn nhiều khi bạn hiểu rõ đâu là thứ quan trọng nhất đối với bạn.

Ma trận Eisenhower không phải là một chiến lược hoàn hảo, nhưng có thể nó là một công cụ ra quyết định hữu ích, giúp tăng hiệu quả công việc và loại bỏ những hoạt động gây lãng phí thời gian và không giúp chúng ta hoàn thành mục tiêu của mình.

LINK: http://cafebiz.vn/quan-tri/ma-tran-eisenhower-de-song-cuoc-doi-hieu-qua-nhu-mot-tong-thong-my-20150511160117046.chn

Cách đặt mục tiêu SMART theo 5 nguyên tắc

Tại sao mình viết bài này ? Vì mình thấy có nhiều bạn có mục tiêu, nhưng chưa biết cách đặt mục tiêu sao cho hiểu quả.
Bài viết nay có phải của bạn ? Không, chỉ là mình vừa học qua, các bạn cũng có thể lên google tra, sẽ thấy rất nhiều bài viết về điều này, nhưng mình thấy những bài đó nhiều chữ quá, đọc hoa cả mắt, nên mình viết gọn lại thế này.

Mục tiêu SMART (Thông minh) là gì?
S.M.A.R.T là tên viết tắt các chữ đầu của 5 bước:
Và để có một mục tiêu thông minh thì khi đặt mục tiêu bạn phải hội đủ 5 yếu tố sau .
S - Specific : Cụ thể, dễ hiểu.
M - Measurable : Đo lường được
A - Attainable : Có thể đạt được
R - Relevant : Thực tế
T - Time-Bound : Thời gian hoàn thành

Ví dụ :

  • (1) Mình nặng 95 kg, mục tiêu của mình là tới năm 2016 giảm còn 71kg . ( Đây chưa phải là mục tiêu, nó không rõ ràng )
    Phải là :
  • (2) Hôm nay ngày 03/02/2015, mình nặng 95 kg, mỗi tháng mình sẽ giảm 2kg, đến ngày 03/02/2016 mình sẽ giảm 24 kg còn nặng 71kg.
  • (2) nhìn sơ qua cũng giống như (1), nhưng khác ở chỗ là nó rõ ràng, cụ thể mỗi tháng giảm bao nhiêu, có mốc thời gian từng tháng, còn ở (1), bạn lấy mốc thời gian theo năm, vậy ngày nào ? tháng nào? bạn sẽ bắt đầu giảm cân ? .

Và giờ mục tiêu của mình đơn giản là chỉ cần mỗi buổi sáng dậy lúc 5:00 và tập thể dục là thấy vui rồi

Top 10 Things Every Developer Must Do

Oh wow! I am revisiting this article after six years. Things have changed quite a bit since then.

-------------------------------------------------------------------------------------

Over the 18 years of my software development career, I have seen many mistakes that developers repeat again and again. 

Here is my top 10 list and more.



1. Missing Documentation

I have seen developers who do not like to write documentation. Obviously, there are tight deadlines and deliverables but it does not take too much time to write about the functionality you are implementing. If you spend one hour for every seven hours of code you write, it will go a long way, and eventually it will save you a lot more time.

OK, let's try to understand this with an example.

In the code sample below, you can see a method called MessySample. I created two ArrayList objects and added some integer and string values to it. Once added, the code simply displays the output.

private void MessySample()  

{  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

    int bs = obj2.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

} 


Technically, there is nothing wrong with this code.

 

The only problem is, there is no proper documentation. Unless I go through the code, I don't know what this method is doing. Also proper naming conventions and readable variables can help. If another programmer writes code and uses the same name variables, obj1 and obj2, and at some point, you try to find all variable references with the same name, you may end up going through some unwanted code. Here is the same code but documented:

/// <summary>  

/// This is a MessySample method that shows how we can write messy code  

/// </summary>  

private void MessySample()  

{  

    // Create an ArrayList object to store integer items  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    // Create an ArrayList object to store string items  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

    // Apply binary search  

    int bs = obj2.BinarySearch("Raj Kumar");  

    // Display index on the console  

    Console.WriteLine(bs);  

    // Send ArrayList items to the console  

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

}  



 

2. Messy Code

Keep it clean. Don't be messy. Writing code is an art. Make it cleaner. Make it pretty. Format it. This part is more about focusing on naming conventions and proper representation of your methods, properties, and variables.

Here is my original code sample. As you can see from the code below, I have two ArrayList objects and the code adds some integer and string values to them. 

private void MessySample()  

{  

    ArrayList obj = new ArrayList();  

    obj.Add(32);  

    obj.Add(21);  

    obj.Add(45);  

    obj.Add(11);  

    obj.Add(89);  

    ArrayList obj2 = new ArrayList();  

    obj2.Add("Mahesh Chand");  

    obj2.Add("Praveen Kumar");  

    obj2.Add("Raj Kumar");  

    obj2.Add("Dinesh Beniwal");  

   

    int bs = obj2.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

   

    foreach (object o in obj2)  

    {  

        Console.WriteLine(o);  

    }  

}  

 

The following code is a clean code with proper comments and naming conventions. As one of the comments suggests, if you use the proper method, variable, and other object names, you will need very little or no documentation. From the code below, I can clearly see that numberList is an array of numbers and authorsArray is a an array of author names.

/// <summary>  

/// This method is a clean sample that shows how to write  

/// clean code.  

/// </summary>  

private void CleanSample()  

{  

    // Dynamic ArrayList with no size limit  

    ArrayList numberList = new ArrayList();  

    // Add 5 Integer Items to ArrayList  

    numberList.Add(32);  

    numberList.Add(21);  

    numberList.Add(45);  

    numberList.Add(11);  

    numberList.Add(89);  

   

    // Create Authors Array List to store authors  

    ArrayList authorsArray = new ArrayList();  

    // Add Author names  

    authorsArray.Add("Mahesh Chand");  

    authorsArray.Add("Praveen Kumar");  

    authorsArray.Add("Raj Kumar");  

    authorsArray.Add("Dinesh Beniwal");  

   

    // Display and apply binary search  

    Console.WriteLine("====== Binary Search ArrayList ============");  

    int bs = authorsArray.BinarySearch("Raj Kumar");  

    Console.WriteLine(bs);  

   

    // Display authors to the console  

    foreach (object author in authorsArray)  

    {  

        Console.WriteLine(author);  

    }  

}  



 

  1. Copy, But With Love

    Code sharing, code reusability, and open source are very common practices today. Thank Google, C# Corner, MSDN, CodeProject, StackOverflow and other online websites for providing tons of free code. It would be foolish for us not to use the same code that is already written and available.

 

So copy, but copy with love. The first thing you need to do is understand the code and verify it. There is so much code out there. Some code is written by experts. Some code is written by amateurs. You must test your code. Once tested, you may also want to check with the terms and conditions and licensing of the code. Sometimes, you may not realize it, but a person who has shared code may want you to use his copyright terms. 

  1. Think Outside of the Box

    If you are involved in a project that was already developed by some other developers, do not just follow what other developers have written. Before you follow the same steps, think if the way the prior code was implemented is the right way to do it. I may have shared some code on C# Corner but that does not mean I have written the most efficient code. You may come up with better ideas.

 

For example, on many websites, you may find code that is written using C# 2.0. The same code is applicable today as well, but in C# 5.0, you may write the same code in an optimal way.

5. Testing! Testing! Testing!

This is one of the areas where I find most developers who are rushing to deliver their code are not testing it thoroughly. Not only must you functional test your code, but also stress test it. This I have seen over and over: When a new functionality is added to a project, there may be chances that the code may have affected other areas. You as a developer need to test that all areas are tested well before it is given to your Integration Manager or deployed on the Test Server.   

Read here: Why Every Developer Should be a Good Tester

 

  1. Debug! Don't Guess

    Don't trust yourself unless you're an experienced programmer. Don't guess what your code would do unless you have already used that code before. Always debug the code before even running it. When I write a piece of code for the first time, I go line by line, add my debug variables and use debugger to step through line-by-line and variable-by-variable to see if the values of these variables are passing my tests. You can avoid this if you use #7.

    7. Write Test Cases

    Visual Studio 2010 and later versions come with a very powerful tool to write test cases for your project. Use it. You can also use third-party open source products such as Nunit. 

    8. One Thing at a Time

    I have seen some programmers write code for one week straight and then do the testing. Write code based on a smaller unit of functionality and test it before you move to the next functionality.

    9. Think Modular

    I remember the days when a code file would have thousands of lines and just keep going and going. If possible, try to break down your code into chunks based on the function, and create a method or a class as applicable. Use proper Object Oriented Programming best practices. Use proper design patterns. Make a good use of libraries, classes, functions, and other modern programming language features that are available to you. 
  2. Do Not Trust Your Testing Team

    Do not rely on your testing team and think that they will find all the bugs. You are the one who knows code and functionality more than anybody else. You test it and then hand it over to the testing team.

    11.    Why don't you add one ;).

    What is your list? Please share!


    12. Good Team Player

    Building software is teamwork. One person can build small software, but when you work on large projects, it is a team effort. A developer must be a good team player. It does not matter how smart or expert you are, if you are not helping your team and not sharing with others, the project will suffer.

 

  1. Ask Questions. Ask Again and Again

    Some developers (I was the same in my early career) think asking questions of a client or manager will make them look foolish or stupid. This is not true at all. I would rather explain the same thing four times than get something that is not right. So make sure you get the requirements right before starting to write code.

 

  1. Be Ahead. Give 110 Percent

    This is from my personal experience. I was named the "crack programmer," "coder on crack," and other names for solving problems instantly. Most of the time, I got the requirements and they were done before the deadlines. So when my manager would come ask, "Is that feature done?" My answer would be, "Yes, it is live already."  

    There are three ways to work:

    1. Do what you were told to do.
    2. Do less than what you were told to do and still be working on it.
    3. Do more than what you were told to do.

    Do not assume that your boss knows more than you. He/She may know more than you but it does not mean that you cannot give your ideas or suggestions. You may have better ideas. Even if they are not better, it does no harm to open up and let him/her know.

    15. Got any advice? Share with us here . . . 

 

LINK: http://www.c-sharpcorner.com/blogs/top-10-things-every-developer-must-do

Top 8 Things You Should Not Say To a Developer

8 điều bạn không lên nói với nhà phát triển (Developer)

Last week, I wrote an article, Top 10 Things You Should Never Say To Your Boss. This week, I am writing the other side of the coin and focusing on the team owners and what they should not say to their developers.

I've been working in the software industry for 17 years. Most of the points discussed here are based on my personal experience. The article is written for business owners, project owners, technical managers, team leaders and seniors who manage a team of developers.

One thing worth mentioning is that most bosses have bosses. If an employee is trying to do something that is in the best interests of the boss's employer it is actually the boss that should obey the employee. That is of course an over-simplification; it is a general concept, not a rule.


Here is a list of my things not to say to a developer.

I don't have time for this.

So you're busy and you really don't have time for your developer. I suggest you find some time. By not giving time enough to your developer, you're actually hurting the project and hence yourself.

There are many possible solutions. A really good boss is creative, flexible and open to alternatives. One solution is to get it in writing and when you do, give it the attention it deserves. It could be that a developer has already tried to communicate in writing. If so and you tell them you do not have time then that leaves the employee without a reasonable solution. The problem might be personal or the problem might be a problem for the company, either way ignoring it has consequences. 

Just do it the way I like it

Coding is not food. Your taste does not matter as long as the developer is doing his/her job. These days, the technology and features are being released rapidly. You should encourage your developers to adapt the latest features, trends and technologies that benefit the organization and project. It is your responsibility to know what is best and that is not easy to do. You need to analyze the costs and benefits of the latest features, trends and technologies. It is reasonable to restrain developers from using something just because it is new but it can also be a mistake to avoid converting to something new. The longer you delay implementing something new, the more it could cost to do the conversion.

One of my long time clients asked me to review one of his projects. I met the architect and the tech lead of the project and started the code review. The project was developed using .NET 4.5 and Visual Studio 2013 but what I saw was the developers still using coding that complied with .NET 1.1 and 2.0. I questioned the architect and he replied, this is the way like it. We've been doing this for a long time. It is easy to understand. The problem is that the longer they delay developing code using the latest capabilities, the more it will cost to convert when it becomes necessary. 

Just leave it. I will do it.

In my early days, I made this mistake myself. Sometimes to move things faster, you end up doing it yourself. I suggest you stop that. To scare your development and grow your organization and team, you must know how to train your developers. I know it can be very frustrating from time to time but for the long run, it will actually help you.

One of the key attributes of a good leader is an ability to create his/her own replacement. In software development, as a project owner, you must consider “what if”. What if I am sick tomorrow?

We use computers to do as much of the detailed work as possible. The philosophy is that it frees us to do the things that computers cannot do. You need to delegate to your employees everything they can do so it frees you to do the things that they cannot.

Also avoid keeping the fun stuff for you to do yourself. Employees are likely to resent that.

You're taking too much time

You must determine why a developer is taking more time than your expectations. There must be a valid reason behind it. If the developer is not skilled, it is your job to find a replacement. If a developer is not motivated, it is your job to figure out why. Again, it all falls on you. All of that can of course be difficult to do. It is easy to avoid doing it. A common way to avoid doing it is to blame the developer for not getting the work done on time and when that is done to avoid finding problems, there are consequences.

Your projects will proceed much more smoothly if you are realistic about the time required. Setting unrealistic deadlines might get the work done on time but end up being very costly later. Employers need to attempt to employ developers that are able to make reasonable estimates that can be relied on. If however a deadline is used because the employer thinks the employee is not productive then that is a problem. The ideal is to have a trustworthy employee that is trusted.

One suggestion is to maintain a record of estimates compared to actual times, especially if that is done for many developers and many projects. There are software systems and other methodologies available to help get other opinions of time estimates.

He can do faster than you

Everybody has their own pace. Everybody has their own strengths and weaknesses. Some people are fast and some are perfectionists. Some are slow but workhorses. When you hire a new employee, it is your job to determine their pace and skills and maximize what they are capable of.

Be careful about judging an employee as being faster if they only seem faster because they put in more hours. Longer hours might seem to be an advantage but it is not necessarily an advantage. If for example a developer actually puts in more hours to get something done faster then it might be a symptom of carelessness if they must do a lot of testing. An extended amount of time spent testing could result in costlier maintenance in the future if the testing begins with buggier code. It is your responsibility to determine what applies.

Do it now

Yes it is very difficult not to say this. Trust me, I've been a developer. I have worked under projects. I have managed teams and projects and now I am managing companies. There are many times, I want things now.

But I know, I am wrong. Sometimes things can't be done now.

Think of it in terms of the amount of time spent switching gears from one thing to another. You should assume that asking a developer to do something that takes 10 minutes will take an hour away from something else. That is not a problem if it is done once and/or when it is important enough but the cost could accumulate if done carelessly.

Can you use a template or this is really simple

Oh, this one pisses me off. This does not apply to a technical person. This usually comes from amateur business owners who do not understand software at all. I hear this a lot from non-technical business owners.

Oh yea, if it's that simple, why can't you do it yourself?

A student can do it

You've just not only insultated your developer, but you've also demoralized him/her. Reality is, no a student can't do it. That's why you hired an experienced developer and pay lot more than you would pay a student.

Summary

In this article, I talked about some things you should not say to a developer. I am sure you have your own list. I would like to get your feedback and your items that you don't want your boss or other people to say.

LINK: http://www.c-sharpcorner.com/UploadFile/mahesh/top-8-things-you-should-not-say-to-a-developer/