Chủ Nhật, tháng 9 24, 2006

Behind Closed Doors - Secrets of Great Management

Don’t waste your time reading this book: Behind Closed Doors - Secrets of Great Management. Reading these following notes and the Appendix is good enough. To me, it’s not an interesting book in management. “Peopleware” or “The One Minute Manager” are the better.

 

1. Week One: Learning about the People

+ Great management is about leading and developing people and managing tasks.
+ You need to learn three things when you enter a new organization or job:
    • Who the people are—their strengths and interests—and what they are working on
    • The stated mission of the group and how the group provides value
    • How your group fits into the larger organization
--> one-on-one meeting, used open-ended questions
+ Walking Around and Listening (MBWAL) A half hour to walk around the department, even though had a “getting to know you” pizza lunch scheduled
+ Don’t offer help if you can’t deliver it
+ Multitasking: Wasting Mental Cycles
    • Working on two tasks (not projects or teams) can improve productivity because when a person is stuck on one task, they can switch to the other.
    • Productivity may increase when a person has two related tasks, but it plummets as the number of projects increases.
+ Gather Data about Current Work: Understand all the work that they do: project work, ad hoc work, periodic work, ongoing work, and management work

2. Week Two: Bringing Order to the Chaos

+ Redirect people to more important, focus on the funded work.
+ Create the Project Portfolio: Match the Work to the Goals
+ Categorize all the projects
+ Management isn’t for everyone:
    • If you find it’s not for you, or it’s not for you yet, it’s okay to step back into a technical role.
    • The best managers practice management and practice technical leadership, moving between both types of jobs before they decide to focus on one or the other.
+ Stepping Back from Management:
    • Do I want to control more of the technical decisions?
    • Am I more interested in fixing technical problems than people problems?
If you answer "yes" to both questions
+ If you think management might be for you, ask yourself:
    • Do I like working with people?
    • Do I like coaching and mentoring people?
    • Am I willing to learn how to provide feedback and have difficult conversations with people when I need to?
+ Matching the Roles with the People
+ Poor performance might be the result of insufficient skills. But it might be something else:
    • Performance also depends on the environment
    • Quality of management.
+ Hire the best:
    • Analyze the job
    • Source candidates  
    • Winnow the candidates  
    • Develop behavior description questions: Behavior description questions such as “Tell me about a time when. . . ” help candidates explain how  they’ve worked in the past rather than how they wish they work
    • Phone screen before in-person interviewing
    • Develop an audition
    • Interview candidates with an interview team
    • Involve as many people as possible when selecting new team members and team leaders
    • Listen to the interview team’s assessment
+ Plan to Integrate New Team Members
    • Create and use a checklist for new hires.
    • Spend time setting the context on the first day
    • Assign a buddy
    • Expect to re-form teams.
+ Big Visible Charts (BVCs): People know what to do and do it when managers use techniques that help people see the status of the work, planned, in progress, and completed.
+ Managing the Project Portfolio
    • Prioritize the work
    • Staff the most important work
    • Assign people to one project at a time
    • Plan to replan

3. Week Three: Build the team

+ How Is a Group Different from a Team?
It’s great to be a team, but not every workgroup needs to function as a team. The difference is in six characteristics.[5]
Teams:
    • are usually small—they have five to ten members.
    • are committed to a common purpose or goal.
    • have an agreed-upon approach to the work.
    • have complementary skills.
    • have interrelated or interdependent interim goals.
    • make commitments about tasks to each other.
+ Here’s the agenda for our first meeting:
    • Rumors, Gossip, News (5 minutes)
    • Issues of the day (the problem we’ll be working on this week)
    • Set our goals as a management team (50 minutes)
    • Action items from previous weeks (we won’t have any this first time)
+ Failure to Give Feedback: Costs More than Money
    Managers who fail to give feedback lose trust and productivity. When managers fail to give feedback, problems fester and resentment builds.
    • Loss of trust: Surprising a team member with a long list of performance complaints at a performance review isn’t helpful.
    • Loss of productivity: Most people want to do a good job.
    • Simmering resentment: People who work closely together know who is doing a good job and which team members are skating by.   
+ Provide Timely Feedback:
    People need information to know what they’re doing well and what they are doing that just isn’t working. Your feedback will help them tune their work
    • Provide feedback as close to the event as possible
    • Deliver feedback in private
    • Describe the behavior or result
    • Evaluations are different from feedback
    • Listen to what the other person has to say
    • Keep notes of feedback conversations
+ When Feedback Doesn’t Correct the Situation
    • Start with a verbal warning
    • Deliver a written warning
    • Implement a get-well plan: A get-well plan is a short period (four to five weeks) where the employee must show evidence that he is meeting acceptable standards.
    • Don’t underestimate the impact of poor performance

4. Week Four:  Managing Day by Day

+ Career Development: both the manager and the staffer are responsible
    • The manager initiates the career development in one-on-ones periodically. We recommend quarterly.
    • Both people verify the career development goals are still valid.
    • Both people monitor progress against goals.
    • The manager looks for opportunities to advance the team member’s career.
+ Create Individual Goals for Each Person
    Goals don’t have to address the entire year. In fact, it’s more effective to have a series of short-term goals
+ Coaching for Success
    • Coaching is a kind of helping: Coaching helps the other person see more options and choose from them.
    • Generate options: generate at least three reasonable options for solving any problem. Rather than offer options on a silver plate, collaboratively generate and discuss options with the employee.
    • Walk through implications
    • Develop an action plan: Options without actions don’t happen.
    • Follow up on progress during one-on-ones
    • Coaching goes only so far: When you find yourself coaching someone about the same issues over and over, decide whether the person
has the ability to learn from your coaching. The failure may be due to your coaching or the other person’s abilities. You may be missing an underlying issue. It’s also possible that the person is in the wrong job.
    -> If you believe someone needs coaching to be successful, and he or she isn’t interested, don’t coach. Move into corrective feedback and possibly a get-well plan.
+ Rule of Three: is a guideline for making better decisions
    • One alternative is a trap. There’s only one solution, and if it doesn’t work, you’re out of luck and out of options.
    • Two alternatives is a dilemma. Two alternatives is false choice: there’s only this or that.
    • Three alternatives provide a real choice. With three alternatives you can make a real choice
    Nothing is more dangerous than an idea if it's the only one you have. (Emil-Auguste Chartier, Propos sur la religion, 1938)
+ Learning to Influence
    • Emphasize mutual benefit: participate in your urgent project will benefit them, not just you
    • Appeal to greater goals: Enlist support by emphasizing the greater good.
    • Horse trade: Maybe you are in a position to help another manager with an issue she is facing. You may have machines, lab time, skills, or some other resource that she needs. Offer a straight-up trade.
    • Reciprocate: Next time around, you may be the one who has resources to help someone else.

5. Week Five:  Discovering Lurking Problems

+ Sustainable Pace
    • They’re burnt-out people: They’re on a short fuse, and they make stupid mistakes. Sometimes their decisions are not just suspect, they appear downright wrong.
    • Working at a sustainable pace of 40 hours a week isn’t molly-coddling. It’s a smart business decision, and it’s your
job to make it happen.
+ Solving Problems as a Management Team
    • Engage group creativity
    • Describe the problem
    • Collect data
    • Write it down
    • Brainstorm possible solutions
    • Document the decision
    • Look for areas where you can act: Even when a full solution involves areas outside your control, don’t rely on others to start working on the issue
    • Develop an action plan: People don’t implement solutions that don’t have action plans.

6. Week Six:   Building Capability

+ You have an obligation to provide feedback—it’s information your employees need to be successful in their jobs.
Coaching is a choice; sometimes yours, and sometimes the employee’s.
+ You always have the option not to coach. You can choose to give your team member feedback (information about the past), without providing advice on options for future behavior.
+ Once you have four people or more in your group, you can’t perform technical work and still be a great manager.
+ Learning to Delegate
    • Managers need to focus on managerial work.
    • Decide what you can delegate: decide which tasks are strategic and which are tactical, tactical work is ripe for delegation.
    • Understand who has the skills to do the work.
    • Consider delegating an investment
    • Consider the specific results you want: Communicate the task parameters including time and quality to the person to whom you’re delegating. + Focus on the results rather than methods. How-to direction is micromanagement.
    • Decide how the two of you will monitor progress. Establish periodic checks on progress.
+ Notice and Appreciate Changes and Contributions
    • Notice people doing something right: Look for opportunities to comment on what people are doing well.
    • Appreciate, don’t thank.
    • Choose your venue: When you appreciate someone, decide whether you will appreciate privately or publicly.
+ How Many People Can You Manage?
    • We strongly recommend managers avoid technical work that’s on the critical path—it’s a nowin situation.
+ Building Self-awareness:
    • Managers need to be aware of their own emotional state and how their words and behavior affect other people.
    • It’s perfectly normal to become frustrated or upset with issues at work. It’s not okay to yell, scream, swear, rant, rave, or threaten (despite some high-profile examples of this behavior).
    • Even facial expressions can have unintended consequences.
    • We don’t advocate keeping a poker face at all times. People expect managers to have emotions. But let the messenger
know you’re upset about the news, not at them.
-> When managers are self-aware, they can respond to events rather than react in emotional outbursts.
+ Manage Yourself
    • Physical displays, especially around subordinates, scare people: people not to bring you any news, especially bad news.
    • Awareness is the first step
    • Notice triggers
    • Choose your response
    • Manage your emotions: People who cannot or will not manage themselves should not manage other people.[
    • Obtain feedback about how you appear to others.  
+ Develop the People in Your Group Every Week
Great managers help each person develop his or her career. Supporting people to build their careers, lets them know you care about them, not just what they produce.
    • Understand what people want. Ask people about their career goals in one-on-ones. Not everyone wants to progress up the hierarchical ladder.
    • Create an action plan and follow it
    • Look for opportunities to practice new skills
    • Don’t hold people back: Sometimes career development means helping someone find a new position. Holding someone back to make your job easier backfires in the long term.
    • Create a transition plan.
    • Separate career development from evaluation: Career development benefits the individual and the organization. But it shouldn’t be part of an individual’s yearly evaluation or rating.
    • Career development is different from remedial development.

7. Week Seven:  Dealing with Corporate Realities without Rolling Over

+ Digging Yourself into a Hole
Sometimes we make our own problems. We don’t want to ruffle the bosses’ feathers, and we shrink from saying “no” directly. When you hear yourself saying these words, you know you are digging yourself a hole that will be hard to climb out of:
    • We’ll try.
    • We should be able to do that.
    • Let’s hope for the best.
    • We’ll just do. . . .
    • We’ll have to make. . . .
    • We’ll multitask.
    • We’ll find resources somewhere.
--> I will work with my team to see what we can achieve. DO NOT promise anything before talking with your team
+ Manage Your Boss, Stand Up for Your Team
    • Understand the other person’s context: don’t blame the other person (in this case, a senior manager) for wanting what they want.
    • Avoid premature decisions: be firm, stating that you can’t commit until you discuss what is possible with your team.
+ Leading Your Team Through A Change In Priorities
    • Replace rumors with facts
    • Set your team’s expectations about how you will respond to the change
    • Replan with your team

Notes:
+ Make goals SMART: Specific, Measurable, Attainable, Relevant, and Time-bound.
    • Here’s an example of a goal that isn’t SMART: “Improve product quality.” 
    • Here’s a SMART version of that goal: “Decrease the total number of released defects in the next release by 10%.” 

Chủ Nhật, tháng 9 03, 2006

Một vài ứng dụng AJAX ấn tượng

Zoho Office Suite & Productivity Tools:  http://www.zoho.com/

Writely: http://www.writely.com/

Google Tools (map, mail, spreadsheets, translate, etc...):  http://maps.google.com/

Windows Live™ Spaces: http://spaces.live.com/  

Flickr: http://www.flickr.com

Netvibes (personalized pages): http://www.netvibes.com/

Webnote: http://www.aypwip.org/webnote/

Thứ Bảy, tháng 9 02, 2006

Quality vs. Schedule

Hẳn ai làm trong ngành phần mềm đều biết đến áp lực về thời gian và chất lượng: chất lượng sản phẩm phải tốt nhất, nhưng thời gian hoàn thành thì luôn bị rút ngắn.

Mỗi lần nhắc đến vấn đề này, tôi lại nhớ đến một nhận định của cô bạn làm trong ngành phần mềm khá lâu rồi: 

            “Thời gian và chất lượng sản phẩm chẳng khác gì tiền và giỏ hàng đi chợ của một cô dâu mới về nhà chồng”.

 

Làm thế nào để vừa lòng nhà chồng khi số tiền đi chợ thì ít nhưng bữa cơm nhất định phải tươm tất. Tất nhiên là chẳng có cách nào khác ngoài việc bỏ thêm tiền riêng của cô ấy vào tiền đi chợ. Tôi lấy làm ngạc nhiên khi nghe cô ta so sánh như vậy: tôi luôn nghĩ rằng cái vấn đề “mẹ chồng nàng dâu” ấy đã “đi vào dĩ vãng” từ lâu lắm rồi chứ. Vì không đồng ý, tôi đã làm một cuộc khảo sát nhỏ với tất cả những bạn bè quen biết (và tất nhiên cả những người quen của người quen nữa…). Và tôi đã đúng: Các nàng dâu bây giờ không hề chịu áp lực về tiền bạc và chất lượng bữa ăn. Họ hoàn toàn tự quyết định việc chi tiêu cho bữa ăn như thế nào là hợp lý nhất.

Khi phát hiện ra phán đoán ban đầu của mình là đúng, thay vì thích thú tôi lại cảm thấy phiền não vì lại xuất hiện một câu hỏi khác: Tại sao cái quan điểm cổ hủ ấy đã bị xã hội đào thải rồi, nay lại sống dậy và len lỏi vào trong tư tưởng của hầu hết các nhà quản lý dự án hiện nay?

Cách tốt nhất để khiến người khác làm việc hiệu quả là luôn đặt họ dưới áp lực về thời gian hoàn thành công việc. 

Chính cái tư tưởng này đặt một áp lực lớn lên các lập trình viên. Để có được chất lượng sản phẩm như mong đợi, họ buộc phải tăng thời gian làm việc: đó là những lúc làm việc overtime, cuối tuần hay đem cả công việc về nhà làm…

 

Vậy, hệ lụy của nó là gì?

-          Chất lượng sản phẩm không đạt được như mong đợi, vì rằng người bị đặt dưới áp lực thời gian không hề làm việc tốt hơn, họ chỉ làm việc nhanh hơn.

-          Niềm yêu thích và sự thỏa mãn đối với công việc giảm đi dần, và kết quả là sự ra đi của người nhân viên đó.

 

Trong một buổi ăn tối cùng bạn bè thuở còn học đại học, sau một lát truyện phím chúng tôi lại qua ra bàn chuyện công việc. Tôi mang nhận định này ra thảo luận. Cũng may trong buổi tối đó không chỉ có dân IT, thành phần khá đa dạng: hai người là quản lý dự án, ba lập trình viên và một vài người làm kinh doanh.

-          “Hừm, nếu không có áp lực thời gian thì làm sao quản lý được những tay lười biếng chứ. Tao đã  từng quản lý những nhân viên mà lúc nào cũng trễ nải dù công việc là khó hay dễ“, một tay quản lý dự án phản đối.

-          Và hắn lập tức có ủng hộ, “Deadline của dự án là thứ mà không thể không đạt được, do đó đôi khi cần phải tạo cả những áp lực thời gian giả tạo lên nhân viên của mình. Nghệ thuật quản lý là gì? Đó là kicking ass”, tay quản lý dự án còn lại nói.

 

Lập tức, có nhiều ý kiến phản đối:

-           “Áp lực thời gian ư, nó hoàn toàn không tốt. Tôi đã từng phải viết ra những đoạn mã vội vàng để kịp thời gian, và tất nhiên chúng tiềm tàng những lỗi. Còn overtime ư, nó chẳng giúp ích được bao nhiêu cả”, “Những đoạn mã viết dưới áp lực về thời gian không thể là đoạn mã tốt”, hắn kết luận.

-          “Rõ ràng như vậy! Không những thế, khi viết tiếp các thiết kế hay những đoạn mã tồi, tôi mất đi hoàn toàn cảm giác thú vị trong công việc”.

 

Sau một hồi chăm chú lắng nghe, với các luận cứ của cả hai bên, một trong những người làm kinh doanh mới lên tiếng nhằm dung hòa hai quan điểm trái ngược trên (có lẽ là hắn muốn đổi đề tài nhàm chán này):

-          “Quyết định có đặt áp lực thời gian lên một công việc cũng giống như việc bạn quyết định có phạt con trẻ khi chúng nghịch ngợm vậy. Nếu lúc nào cũng áp dụng, chắc chắn sẽ bị phản tác dụng”.

 

Tôi thật sự bị lạc vào mê hồn trận của những quan điểm trái ngược nhau, nhưng có lẽ đây là một nhận định đúng.  Nếu không thì sao người ta lại cho rằng quản lý là một nghệ thuật, chứ không phải là một ngành khoa học.

 

-          “Này! Thế các dự án phần mềm lúc nào cũng phải có deadline cố định sao? Các lập trình viên không thể tham gia vào việc quyết định thời hạn ra release của sản phẩm à?”, một cô bạn học kinh tế hỏi.

Một câu hỏi thật hay và gợi ta nhiều suy nghĩ. Sau này, tôi được biết một số công ty ở Nhật (Hitachi software, Fujitsu) đã thành công khi cho phép nhóm phát triển dự án từ chối việc ra release sản phẩm khi nhóm này cho rằng sản phẩm chưa đạt được chất lượng mong muốn.

 

Vậy, ta thử tìm hiểu xem nếu dự án không có áp lực về thời gian thì có được những lợi điểm gì?

 

Thời gian hoàn thành dự án:

Trước tiên, chúng ta hãy khảo sát bảng số liệu dưới đây. Jeffẻy-Lawrence đã khảo sát productivity của 24 dự án phần mềm dưới các áp lực thời gian khác nhau:

 

Productivity by Estimation Approach

(Full Result)

EFFORT ESTIMATE           AVERAGE               NUMBER OF

PREPARED BY                 PRODUCTIVITY        PROJECTS

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

Programmer alone                      8.0                                19

Supervisor alone                        6.6                                23

Programmer & supervisor            7.8                                16

Systems analyst                        9.5                                21

(No estimate)                             12.0                              24

(bảng số liệu này được lấy từ Peopleware - Productive Projects and Teams)

 

Kết quả khảo sát cho ta thấy rằng dự án không có bất kì một áp lực nào về thời gian lại có productivity cao nhất.

Hỡi các nhà quản lý dự án, định luật Parkinson không đúng với các lập trình viên làm việc trí óc đâu!

 

Nhóm phát triển dự án:

Khi không chịu áp lực về thời gian, họ mạnh dạn áp dụng những kỹ thuật mới, dám loại bỏ đi những thiết kế tồi. Và kết quả của nó là những bài học, những kinh nghiệm quý báu mà chẳng có sách vở nào giúp bạn được. Kiến thức và kinh nghiệm làm việc của cả nhóm tăng lên sau mỗi dự án, không những thế niềm yêu thích và cảm giác thú vị trong công việc cũng tăng theo.

Ngược lại, chuyện gì sẽ xảy ra trong mộ môi trường luôn có áp lực về thời gian. Nhân viên của bạn rất sợ mắc lỗi, họ luôn hướng mọi giải pháp theo những gì mà họ đã làm hoặc ít nhất là đã biết. Chẳng có một ý tưởng mới, táo bạo gì trong công việc. Một môi trường như vậy sẽ làm thui chột tài năng và giết chết đi mọi cảm hứng.

Tôi có người bạn gặp phải một vấn đề nan giải: nhân viên của anh ấy cứ lần lượt rời khỏi nhóm mặc dù anh ta đã có chính sách đãi ngộ thích đáng. Sau thời gian tìm hiểu, anh ta nhận ra rằng nguyên nhân chính là vì tính chất công việc luôn đặt dưới áp lực thời gian, làm cho các nhân viên đó không dám áp dụng những cái mới, và dần dần họ không còn cảm giác thú vị với dự án nữa, việc ra đi là một sự tất yếu. Và hẳn ai đã làm quản lý đều biết rằng để tìm và đào tạo được một nhân viên mới không hề đơn giản tí nào.

 

Hỡi các nhà quản lý dự án, hãy sáng suốt lên!

 Nếu không thì bạn thắng trong những trận đánh nhỏ, nhưng lại thất bại trong cả cuộc chiến.

 

Chất lượng sản phẩm:

Tôi vẫn còn nhớ cái cảm giác lần đầu tiên học lập trình, cái cảm giác vui sướng khi hoàn thành một chương trình; hay một niềm tự hào khi tìm ra được một thiết kế hay, một đoạn mã đơn giản hơn khi ngồi refactoring các đoạn mã. Cái cảm giác ấy hiện nay vẫn còn, và tôi cũng tin chắc rằng không chỉ có mình tôi có cảm giác đó. Đấy là sự thú vị của nghề lập trình.

Vì vậy, tôi hoàn toàn đồng ý với nhận đinh sau:

Một developer luôn gắn lòng tự trọng bản thân vào chất lượng sản phẩm họ sáng tạo ra.

Vì thế mà trong quá trình phát triển, các developer luôn định hình ra các tiêu chí về chất lượng sản phẩm riêng của họ, các tiêu chí này luôn cao hơn so với quan niệm của nhà quản lý cũng như sự chấp nhận của thị trường.

Trong khi đó các nhà quản lý lại không như vậy, dưới áp lực cần phải bàn giao sản phẩm đúng hạn, họ chỉ xem chất lượng là một thuộc tính của sản phẩm, nó thay đổi tùy vào đòi hỏi của thị trường. Chất lượng sản phẩm chẳng khác gì một nồi canh, khi có nhiều người dùng thì đổ thêm nước vào. Đi làm dự án nhiều, hẳn bạn thường phải nghe những lời phàn nàn thế này:

-          “Tại sao cứ phải luôn cải tiến mã lệnh vậy?”

-          “Thiết kế như vậy là tốt rồi, chúng ta không có nhiều thời gian”.

-          “Vấn đề này không cần tốn nhiều thời gian như vậy”.

-          “Tôi không cần biết nó có rắc rối gì, các anh phải có được sản phẩm vào tháng tư”

-         

Các nhận định này vô hình chung đã áp đặt một áp lực về thời gian lên nhóm phát triển sản phẩm, và tất nhiên họ buộc phải hi sinh chất lượng để lấy thời gian, cái mà không một lập trình viên nào cảm thấy hài lòng cả.

Các nhà quản lý dự án, xin chú ý:

Tiêu chí chất lượng sản phẩm mà các developers đưa ra luôn cao hơn mong muốn của bạn.

Hãy cho họ một cơ hội quyết định chúng.

 

Ai là người ước lượng thời gian hoàn thành sản phẩm?

Không tạo áp lực thời gian hoàn toàn không có nghĩ là để dự án “trôi nổi” vô định, kết thúc khi nào nó kết thúc. Mọi công việc đều phải được ước lượng thời gian hoàn thành, và không ai ước lượng tốt hơn chính bản thân những người thực hiện nó.

-          “Hừm! Nhân viên của tao luôn ước lượng lớn hơn thời gian cần thiết nhiều”. Tôi nhận ngay một lời phản đối khi đưa ra nhận định trên.

Nhưng lần này tôi nghĩ hắn đúng, rõ ràng ước lượng là công việc đòi hỏi có nhiều kinh nghiệm.

Hãy để việc ước lượng cho nhóm phát triển sản phẩm dưới sự tư vấn của một nhân viên nhiều kinh nghiệm

Hẳn ai cũng từng nghe Modern Talking hát: “You can win if you want. If you want it you will win”. Thật vậy, mọi người đều nỗ lực khi bản thân họ muốn vậy. Developer cũng không ngoại lệ, họ sẽ có khuynh hướng làm việc tốt hơn để đạt được thời gian do chính mình ước lượng.

 

Lời kết

Hãy tưởng tượng một ngày nọ bạn tỉnh giấc và thấy mình đang đi trên dây, tay cầm sào giữ thăng bằng: đi nhanh quá thì ngã mà đi chậm quá cũng không xong, đứng lại thì càng không được. Hẳn là lúc đó bạn đang quản lý dự án đấy, rồi chuyện gì xảy ra đây nếu bạn lại thêm chứng bệnh sợ độ cao…

Thứ Sáu, tháng 9 01, 2006

Làm thể nào để Google đánh chỉ mục cho blog của bạn

Trong những năm gần đây, một dạng trao đổi thông tin mới ra đời và phát triển với tốc độ rất nhanh, đó là blog (hay weblog). Blog thoạt đầu được phát triển như một dạng nhật ký trực tuyến với những suy nghĩ cá nhân được đưa lên web. Hiện nay, ứng dụng blog trở nên phong phú hơn, và dễ thấy nhất là việc dùng blog làm một kênh thông tin trong nội bộ cũng như bên ngoài công ty.

Một trong các dịch vụ blog miễn phí khá nổi tiếng là dịch vụ Blogger của Google (www.blogger.com), nó cho phép bạn tạo và duy trì các blog trên máy chủ Blogger. Trong bài viết này tôi xin không trình bày cách tạo một blog trên Blogger vì nó chỉ thông qua một vài thao tác đơn giản và có khá nhiều bài viết đã trình bày. Thay vào đó, bài viết sẽ hướng dẫn bạn cách đưa blog vào google sitemap, để Google có thể đánh chỉ mục blog của bạn, nhằm gia tăng cơ hội cho blog của bạn xuất hiện dưới kết quả tìm kiếm của Google.

Trước hết chúng ta hãy tìm hiểu qua về Google Sitemaps: Google Sitemaps hiện đang ở bản beta, được Google phát triển với mục đích cung cấp một cách thức đơn giản cho người dùng có thể mô tả web site của họ. Thông qua việc cung cấp cho Google sitemap của site (cấu trúc site, các trang web quan trọng cũng như mức độ thay đổi của chúng…), bạn đã hướng dẫn cho các "spiders" của Google cách đọc thông tin và đánh chỉ mục cho web site của bạn.

Dưới đây là hướng dẫn chi tiết cách đưa blog vào google sitemap:

Bước # 1: Đăng nhập vào Google Sitemaps (http://www.google.com/webmasters/sitemaps/siteoverview) thông qua tài khoản Google của bạn

Ngay ở đầu trang bạn sẽ thấy ô nhập liệu để nhập site cần đánh chỉ mục. Hãy nhập vào đó địa chỉ URL của blog của bạn (ví dụ: http://khanhle.blogspot.com/)

Sau đó nhấn nút “OK”. Blog của bạn sẽ được thêm vào tài khoản như hình dưới:

Bước # 2: Xác thực quyền của bạn trên blog vừa nhập.

Kích vào siêu liên kết “Verify”, bạn sẽ chuyển đến trang có hình dưới:

Google cung cấp hai phương pháp xác thực. Tuy nhiên ta chọn phương pháp thứ hai “Add META tag”, vì đây là phương pháp duy nhất mà Google Blogger hỗ trợ.

Sau khi chọn, trang web sẽ sinh ra mã META tag, ta sẽ chép đoạn mã này vào phần template của blog.

Bước # 3: Dán META tag vào template của blog

Đăng nhập vào www.blogger.com . Vào blog của bạn, di chuyển đến tab “Template”.
Chèn đoạn mã META tag vào như ví dụ dưới:

Lưu lại thay đổi bằng cách kích vào nút “Save Template”

Kích vào nút “Republish Index only”. Sau đó đợi vài giây cho đến khi blog của bạn được published hoàn toàn.

Bước # 4: Trở về lại Google sitemap để kết thúc quá trình xác thực.

Trở về lại Google sitemap, ta có: “I’ve added the META tag in the home page of http://khanhle.blogspot.com/”.

Nhấn vào nút “Verify” để kết thúc quá trình xác thực

Bước # 5: Đến bước này blog của bạn đã được đưa vào Google sitemap. Tuy nhiên, bạn cần phải cung cấp cho Google URL sitemap của blog của bạn. Ta sẽ dùng site feed (ATOM xml) của blog làm site map.

Trở về hình ở bước một và nhấn vào siêu liên kết “Add a Sitemap”, bạn có được:

Chọn “Add General Web sitemap”

Cung cấp địa chỉ URL của blog của bạn, đó là địa chỉ của file atom.xml. Ví dụ http://khanhle.blogspot.com/atom.xml (*):

Nhấn vào nút “Add Web Sitemap”.

Bạn sẽ nhận được thông điệp xác nhận của Google:

“You have added a Sitemap to http://khanhle.blogspot.com/. Reports may take several hours to update. Thank you for your patience!”

Chúc mừng! Bạn đã kết thúc quá trình đưa blog vào Google sitemap. Bây giời thì bạn chỉ còn phải đợi Google đánh chỉ mục cho blog của bạn.

(*) Chú ý: Nếu bạn chưa kích hoạt chức năng “Site Feed” của blog của bạn, thì bạn phải thực hiện trước khi thực hiện bước này. Dưới đây là hướng dẫn:

Đăng nhập vào www.blogger.com . Vào blog của bạn, di chuyển đến tab “Setting” > “Site Feed”. Và thực hiện như hình dưới:


Bước # 6: Kiểm tra kết quả đánh chỉ mục của Google

Sau khoảng vài giờ hoặc một ngày, bạn hãy kiểm tra tài khoản trên Google sitemap xem blog của bạn đã được Google đánh chỉ mục chưa. Nếu Google đã kiểm tra blog của bạn, bạn sẽ có kết quả tương tự hình dưới:


Tùy thuộc vào lượng tin, nội dung cũng như số lượng người truy cập vào blog của bạn mà cơ hội blog URL có thể xuất hiện dưới kết quả tìm kiếm của Google. Tuy nhiên, nếu từ khóa là tên của bạn hoặc các từ riêng biệt chỉ xuất hiện trên blog của bạn thì khả năng blog của bạn nằm trong 10 kết suất đầu tiên của Google là gần như chắc chắn.

Ví dụ sau đây kết quả của sử dụng tìm kiếm thông qua Google với từ khóa “le canh khanh”:

Nếu blog của bạn khá nổi tiếng với nhiều người vào xem và bình luận thì cơ hội cơ hội cho nó xuất hiện dưới nhiều từ khóa khác nhau là hoàn toàn có thể, còn không thì thông qua tên bạn bè bạn cũng dễ dàng tìm ra blog của bạn.