Bí kíp quản lý nhóm làm việc hiệu quả cao

 

 

John Baldoni – Harvard Business Publishing Nguyễn Tuyến dịch – theo Tuần Việt Nam

Làm việc nhóm có hiệu quả cao, đặc biệt những người đã có một thời gian dài cùng làm việc thường tôn trọng và trung thành với quy tắc của riêng họ. Mặt nào đó, điều này là bí quyết tạo ra hiệu quả, song mặt khác, một khi nhóm này phớt lờ mệnh lệnh trực tiếp từ người quản lý, điều đó có thể gây ra những rắc rối.

Người quản lý của những nhóm như vậy được ca ngợi với năng suất làm việc hiệu quả, nhưng cũng vất vả khi phải làm việc với thái độ làm những gì họ muốn khi họ muốn làm của nhóm. Điều này gây ra sự bất hoà ảnh hưởng xấu đến tính hiệu quả của tổ chức.

Thách thức với nhà quản lý là phải gắn chặt với những nguyên tắc cũng như tăng cường sự tôn trọng đối với năng lực và thành công của toàn nhóm. Dưới đây là một số gợi ý cho việc tận dụng sự hiệu quả của toàn nhóm nhưng vẫn duy trì được sự thống nhất của cơ cấu.

 

Ngợi khen: Công nhận những gì đội đã đạt được. Hãy làm cho mỗi cá nhân trong đội biết bạn tôn trọng họ và công việc của họ như thế nào. Hãy hết lòng để làm họ cảm thấy họ được chào đón. Hãy khen ngợi những thành công của họ ở mức cao. Tóm lại, hãy làm cả nhóm cảm thấy rằng họ đặc biệt. Phần thưởng chỉ phản ánh việc doanh nghiệp đánh giá cao đóng góp của đội như thế nào.

Truyền đạt giá trị: Điều quan trọng đối với thành công là sự liên kết trong nhóm, cùng nhau hướng tới cái tốt hơn. Nguyên tắc tương tự cũng áp dụng cho những nhóm làm việc trong tổ chức. Hãy nói rõ rằng không có nhóm nào được đặt lên trên toàn công ty. Nhưng cùng lúc đó cũng phải công nhận sự thật rằng những cá nhân sẽ trung thành, gắn kết với các thành viên trong nhóm hơn với thành viên của các nhóm khác. Một ông chủ thông minh sẽ tìm ra cách để thúc đẩy sự gắn kết của nhóm để đem lại lợi ích cho toàn doanh nghiệp bằng cách đặt nhóm làm việc vào vị trí mà thành công của nhóm sẽ được phản ánh tốt trên toàn doanh nghiệp.

Tôn trọng cách làm việc: Nhóm làm việc hiệu quả cao thích làm việc theo cách của riêng họ. Đây là nguyên nhân chính cho thành công của họ. Cho phép cả nhóm cũng như với mỗi cá nhân chỉ ra những điều cần thiết cho bản thân nhóm và tiến hành ý tưởng theo cách của riêng mình. Tuy nhiên, hãy nói rõ rằng cho dù nhóm làm gì đi nữa thì cũng phải hoàn thành công việc đúng hạn và trong phạm vi ngân sách. Ngoài ra, hãy yêu cầu cả nhóm minh bạch với những kết quả tốt cũng như xấu.

Cố gắng đạt được sự cân bằng giữa sáng tạo và nguyên tắc: Bạn muốn thử thách toàn nhóm để họ suy nghĩ và hành động sáng tạo bởi vì nhóm có năng lực làm những việc theo một cách khác để tạo ra thành công. Cùng lúc đó, sự sáng tạo của nhóm phải phục vụ cho mục tiêu và chiến lược của tổ chức. Đó là, cả nhóm có thể “tự do” về mặt phương pháp nhưng phải giữ vững mục tiêu chung. Các dự án mà nhóm tiến hành phải bổ sung hoàn thiện nhiệm vụ của tổ chức.

Hãy đối mặt với sự thật. Khi hoàn cảnh thúc ép, một nhóm làm việc hiệu quả cao cần phải có được quyền hạn cần thiết để thành công. Hãy coi nhóm này là nhóm phù hợp nhất trong số các nhóm tương đương nhau. Tất cả các thành viên cần phải được đối xử công bằng nhưng những người có nhiều đóng góp hơn thì xứng đáng được đối xử đặc biệt hơn. Vì vậy thường thì thành công chung của nhóm làm việc hiệu quả giúp toàn tổ chức thành công.

Cuối cùng, một nhà quản lý thông minh sẽ tạo điều kiện cho một nhóm làm việc hiệu quả cao để họ thành công. Những người quản lý có kinh nghiệm biết giới hạn mà họ có thể giữ cho tất cả các nhóm, chứ không chỉ riêng gì một nhóm hiệu quả cao, vừa duy trì được niềm tự hào của riêng từng nhóm vừa mang lại lợi ích cho toàn tổ chức.

 

Mười cuốn sách gối đầu giường cho các nhà đầu tư

 

(Theo VNBOURSE )

Khi bắt đầu bắt tay vào đầu tư, niềm đam mê là một trong những luồng ánh sáng rực rỡ nhất soi đường cho bạn vượt qua khu rừng rậm thông tin ngoài kia. Song nếu bạn không xem xét đến khía cạnh lịch sử hay các phân tích chi tiết hơn về một vấn đề nhất định, bạn vẫn sẽ lạc lối. Dưới đây là một vài cuốn sách khá cổ điển về đầu tư nhưng luôn luôn là những tác phẩm đáng để tất cả các nhà đầu tư đọc và ngẫm nghĩ!

“Nhà đầu tư thông minh” (The Intelligent Investor) (1949) của Benjamin Graham

 

Chưa từng bao giờ có lập luận nào phủ nhận niềm tin Benjamin Graham chính là cha đẻ của đầu tư giá trị. Những ý tưởng của ông về các phân tích an toàn đã đặt nền tảng cho vô số các thế hệ nhà đầu tư, trong đó có cả học trò xuất sắc nhất của ông Warren Buffett. Được xuất bản năm 1949, “Nhà đầu tư thông minh” được nhiều độc giả tìm đọc hơn một cuốn sách khác của ông ra đời năm 1934 với nhan đề “Phân tích chứng khoán” (Security Analysis). “Phân tích chứng khoán” có thể được nhắc đến và trích dẫn khá nhiều song ít người thật sự đọc nó. Cuốn “Nhà đầu tư thông minh” sẽ không nói cho bạn cách chọn lựa một cổ phiếu, nhưng nó dạy bạn những quy tắc, nguyên lý rõ ràng và đúng đắn (đã được thời gian kiểm chứng) mà tất cả các nhà đầu tư đều có thể sử dụng. Hơn nữa, bạn sẽ thấy nó thật sự là một tác phẩm đáng để đọc với lời bình luận của Warren Buffett: “Cuốn sách dạy đầu tư hay nhất từng được viết”.

“Cổ phiếu bình thường và lợi nhuận bất thường” (Common Stocks And Uncommon Profits) (1958) của Philip Fisher

Một trong những người tiên phong trên thế giới về phân tích tài chính, Philip Fisher đã có những ảnh hưởng rất lớn đối với thuyết đầu tư hiện đại. Ý tưởng cơ bản về phân tích một cổ phiếu dựa trên tiềm năng tăng trưởng được nhiều người công nhận là thành quả của Fisher. “Cổ phiếu bình thường và lợi nhuận bất thường” hướng dẫn các nhà đầu tư cách phân tích chất lượng của một hoạt động kinh doanh và khả năng sinh lời của nó. Được xuất bản lần đầu tiên vào những năm 1950, những bài học mà Fisher đưa ra cho đến hơn nửa thế kỉ sau vẫn còn nguyên giá trị.

“Cổ phiếu cho dài hạn” (Stocks For The Long Run) (1994) của Jeremy Siegel

Là một giáo sư của trường kinh doanh Wharton, Jeremy Siegel đưa ra khái niệm về việc đầu tư cổ phiếu trong thời gian dài. Ông tiến hành các nghiên cứu sâu rộng trong suốt hơn hai thập kỉ để chứng minh rằng không chỉ cổ phiếu vượt qua mọi công cụ tài chính khác về lợi nhuận đạt được, mà cổ phiếu còn là hình thức đầu tư an toàn nhất và dễ dự đoán nhất khi đối mặt với những tác động của lạm phát.

“Học cách kiếm tiền” (Learn To Earn) (1995), “Trên đỉnh phố Wall” (One Up On Wall Street) (1989) và “Chiến thắng thị trường” (Beating The Street) (1994) của Peter Lynch

Peter Lynch bắt đầu trở nên nổi tiếng vào thập niên 80 thế kỉ trước với chức danh giám đốc của “kì tích” Fidelity Magellan Fund. “Học cách kiếm tiền” là ấn phẩm nhắm đến đối tượng độc giả là thể hệ trẻ, trong đó giải thích rất nhiều các nguyên tắc căn bản của kinh doanh. “Trên đỉnh phố Wall” lại là cẩm nang phân tích ích lợi của phương thức đầu tư theo định hướng cá nhân, và “Chiến thắng thị trường” tập trung vào cách thức Peter Lynch đã sử dụng để chọn ra các cổ phiếu chiến thắng (hay thậm chí cả những trường hợp ông bỏ lỡ các nhà vô địch đó) khi ông là giám đốc điều hành của quỹ đầu tư Magellan Fund. Cả ba tác phẩm đều có cách tiếp cận đặc trưng của con người tài ba này, người luôn tin tưởng tuyệt đối vào nguyên tắc: Nếu chịu khó thường xuyên làm “bài tập về nhà” với công việc đầu tư của mình, các nhà đầu tư cá nhân sẽ có thể ngang ngửa hay thậm chí vượt mặt các chuyên gia.

“Bước đi ngẫu nhiên trên phố Wall” (A Random Walk Down Wall Street) (1973) của Burton G. Malkiel

Cuốn sách này chính là tác phẩm đóng vai trò quyết định cho việc truyền bá quan điểm thị trường chứng khoán là hiệu quả và giá cả trên thị trường này tuân theo nguyên lý “bước chân ngẫu nhiên”. Điều đó có nghĩa là bạn sẽ không bao giờ có thể chiến thắng được thị trường. Theo Malkiel, không một phân tích nào, kể cả cơ bản hay kĩ thuật, có thể giúp bạn làm được điều đó. Giống như bất kì một học giả chuẩn mực nào khác, Malkiel bảo vệ các luận điểm của mình với hàng tập dày các công trình nghiên cứu và số liệu. Sẽ là một sự nói giảm nói tránh khi cho rằng các quan điểm này gây nhiều tranh cãi. Trên thực tế, không ít người coi chúng chỉ như là một sự báng bổ. Thế nhưng cho dù bạn có đồng ý với quan điểm của Malkiel hay không, đọc cuốn sách này và xem xét cách thức Malkiel tiếp cận các vấn đề trên thị trường chứng khoán sẽ đem lại cho bạn không ít kiến thức bổ ích.

“Các bài viết của Warren Buffett: Bài học cho các doanh nghiệp Hoa Kì” (The Essays Of Warren Buffett: Lessons For Corporate America) (2001) của Warren Buffett và Lawrence Cunningham

Mặc dù Buffett hiếm khi bình luận về khối lượng tài sản ông đang nắm giữ, nhà đầu tư được coi là vĩ đại nhất thế giới này lại rất thích thảo luận các nguyên tắc đầu tư của mình. Cuốn sách này thực chất là tập hợp các lá thư mà Buffett viết cho các cổ đông trong vài thập kỉ qua. Chúng đích xác là một công trình tổng kết kĩ thuật đầu tư của ông vua đầu tư chứng khoán thế giới. Một cuốn sách khác khá hay về Buffett là “Phong cách Warren Buffett” (The Warren Buffett Way) của Robert Hagstrom.

“Làm giàu qua chứng khoán” (How To Make Money In Stocks) (tái bản lần ba năm 2001) của William J. O’Neil

Bill O’Neil là người sáng lập thời báo “Investor’s Business Daily”, một tờ báo tài chính số ra hàng ngày và sáng tạo ra phương pháp CANSLIM. Nếu bạn quan tâm đến cách thức làm thế nào để lựa chọn được cổ phiếu, đây thật sự là một phương pháp tuyệt vời để bắt đầu. Rất nhiều cuốn sách chỉ nói chung chung mà không đi vào chi tiết cụ thể, nhưng “Làm giàu qua chứng khoán” không mắc phải lỗi lầm đó. Cuốn sách này sẽ cung cấp cho bạn một phương pháp hữu hình dễ hiểu mà bạn có thể ngay lập tức ứng dụng vào công việc phân tích chứng khoán của mình.

“Cha giàu cha nghèo” (Rich dad poor dad) (1997) của Robert T. Kiyosaki

Cuốn sách này là những bài học về tiền bạc người cha giàu có dạy cho lũ trẻ, mà theo như tác giả, những bài học này thường bị các bậc phụ huynh nghèo hay trung lưu bỏ qua. Thông điệp của Robert Kiyosaki rất đơn giản, nhưng chứa đựng một bài học tài chính quan trọng có thể thúc đẩy bạn đầu tư: người cha nghèo kiếm tiền bằng cách làm việc cật lực vì tiền, còn người cha giàu kiếm tiền bằng cách khiến những người tài giỏi làm việc cho mình. Chúng tôi không thể tìm ra một cuốn sách dạy tài chính nào hay hơn thế dành cho con cái của bạn, thậm chí cho chính bạn.

“Hiểu biết thông thường về quỹ tương hỗ” (Common Sense On Mutual Funds) (1999) của John Bogle

John Bogle, người sáng lập ra Vanguard Group, là người đóng vai trò quan trọng trong việc thúc đẩy phát triển các quỹ đầu tư chỉ số và trong việc chống lại các quỹ tương hỗ được quản lý quá nóng. Trong cuốn sách này, Bogle mở đầu với các bài học về chiến lược đầu tư và sau đó là sự chỉ trích đối với các quỹ tương hỗ về các khoản phí cao ngất ngưởng các quỹ này thu từ các nhà đầu tư. Nếu bạn là chủ một quỹ tương hỗ, bạn nên đọc cuốn sách này.

“Tăng trưởng phi lý” (Irrational Exuberance) (2000) của Robert J. Shiller

Được lấy tên từ lời bình luận rất nổi tiếng năm 1996 của Cựu Chủ tịch Cục dự trữ liên bang Mĩ (FED) Alan Greenspan về sự bất hợp lý của thị trường chứng khoán, cuốn sách của Shiller, xuất bản tháng 3/2001, đã lạnh lùng đưa ra lời cảnh báo về nguy cơ bùng nổ của quả bong bóng dotcom (bong bóng cổ phiếu của các công ty hoạt động kinh doanh trên mạng Internet). Nhà kinh tế của trường đại học Yale này đã đập tan mọi luận điểm cho rằng thị trường đang tăng trưởng rất hợp lý và chứng minh cho quan điểm của mình trên cơ sở phân tích tâm lý cảm xúc của thị trường, sự kì vọng và hành vi của đám đông. Rất mỉa mai, cuốn sách này được xuất hiện gần như chính xác vào đúng thời điểm thị trường lên đến đỉnh.

Càng đọc nhiều biết nhiều, bạn càng có nhiều cơ hội áp dụng các lời khuyên của một vài chuyên gia vào chiến lược đầu tư của riêng mình. Những cuốn sách được liệt kê ở trên chỉ là những gợi ý ban đầu cho bạn, nhưng chắc chắn rằng chúng cũng là mười trong số những cuốn sách vĩ đại nhất về đề tài này.

 

What is software project management? – by Bob Lloyd – Helium

What is software project management? – by Bob Lloyd – Helium

Project management for software development has always relied on the traditional skills of managing the resources required to produce a product.  By negotiating agreed schedules with the appropriate people and resources, the aim is to produce software with the right functionality at the right time and at the right cost.

When we plan to build a house, or a car, or some other tangible product, the project management process is well-understood and by and large, we can draw on our past projects to predict reasonable well, how the current project will go.  We know that the foundations will go in before the walls, that the windows will go in fairly late, and so on.

And yet the software industry has a long record of late projects, budget overruns, poor functionality, unreliable systems, and cancelled projects.  Why should that be?  Is it simply that software project managers are doing a poor job? That they are not exerting enough pressure?  It’s a little more complicated than that.

The work of a project manager involves steering the development of a product from its inception as a product proposal, perhaps as a vague idea of a product that customers would welcome or a desperate need on the part of key clients, through to the final release and installation.  It’s a complex job combining negotiations over resources, plans, skills needed, political influences, financial control, and many other aspects.

The project manager will work with both technical and non-technical people.  Among the former group will be technical architects and software designers, programmers, test engineers, installations engineers, security specialists and may include third party companies as well.  Amongst the latter group will be project sponsors, business analysts, marketing personnel, sales managers, and senior management.  Each will have their own specific agenda and their own vision of what the project should be.

The project manager gets involved when the project has been roughly scoped out but the scope itself, indeed many of the requirements, will change in the course of the project.  Any project manager who think that they are dealing with static requirements will quickly realise the dynamic nature of software systems.

The technical people will have a range of tools at their disposal for helping them analyse, design and build the software system and they will be experts in how the system will run and interface with other systems.  They will understand the platform in detail and all the relevant technologies and they will be the source of estimates which will be used in plans.

The project manager will liaise with these engineers and receive information from them regularly both about any problems of development, but also progress against the agreed plan.  There will always be pressure on the project manager to cut timescales, reduce costs, increase productivity, and perhaps even cut functionality and this will lead to arguments with the developers, even where they are totally committed to the project.  Negotiating these differences is a key skill.

Often the generation of an agreed plan is seen as a major priority early in a project because business managers want to know about the resources required, where they are coming from, how much the cost, and which other projects will therefore have to wait.  There are political considerations here and project managers may be asked to compromise their own projects for the benefit of others.  They are required to defend their ground but also understand the company priorities.  So managing stakeholders is also a key skill.

Developers may follow a particular methodology for developing software.  Although projects are linear in the sense that the process moves from the first ideas through to a finished, released product, there is inevitably a considerable amount of iteration in software development.  Many aspects of software development requires prototyping, iterative testing, integration tests, redesign and rewriting of code.

In a very real sense, it is different from the linear civil or mechanical engineering projects on which much project management training is based.  So although methodologies such as PRINCE II and PMBOK may describe linear models of project control, these need significant modification to cope with the complexities of software development.  A dogmatic application of these project management methodologies will result in major difficulties and could bring down the project.

Some explanation is needed for claiming a special case for software projects.  So what are those special aspects of software that make it so much more difficult for project managers?  Why is it that well-established techniques seem to run into so many problems?

When we are building houses, bridges, cars, etc, we are using variations on a design that is known to work.  We are working in a well-understood problem domain.

We know a great deal about houses, bridges and cars.  It could be said that we also now know a great deal about databases, about websites, about financial systems but there is a deeper structural difference that is often obscured.

In the computing world, the operating system is of critical importance and it changes every year in significant ways.  As an example, on the Windows systems there are regular major updates which affect security, the operational context of software, the resources available on the machine, and so on.  Any software to be released next year has to take this into account.  There is little likelihood that the structural properties of bricks will change so dramatically during the build of a house.

Indeed it goes deeper than this.  The very tools used to build the software are themselves changing regularly.  Whereas once a great deal of software was written in a language called C++, much of it is now written in C#, and these programs need to interact.  The technical aspects of this interaction constitutes a new and less well-understood project risk.

An additional problem for project managers is the means and nature of the testing.  For small systems, testing can be relatively simple.  But for larger systems, build in layers or large scale modules, the integration becomes a critical problem.  If integration is to be done little by little, then the scheduling becomes much more complex with inter-dependencies.  Of course critical path analysis can help understand the necessary order of development but sometimes modules or layers require each other for testing to take place.

Sometimes extensive test frameworks, separate software systems, need to be written which is an additional project requirement and cost.  Sometimes a software system will behave very differently when it is stressed or fully loaded, scaled up to industrial performance.  For example, checking security on 100 users may well appear very fast but if 100,000 users are tested there could be a critical bottleneck rendering the whole system useless.

All of this means that the software project manager cannot simply rely on textbook methodologies, but needs a detailed understanding of the development process itself.  It is pointless insisting that an engineer keeps to their planned milestone when they have reached a technical problem that even Microsoft did not foresee.

This structural indeterminacy in software projects has been the subject of study by leading software engineers for many years, particular by Steve McConnell and Steve McGuire.  Some develops prefer a more “agile” approach to projects in which the developers themselves determine what is possible on the plan rather than having the involvement of project managers.  For projects where customers are willing to negotiate a drip feed of delivered improvements, this can be effective but there are questions about larger more structured projects which have to hit particular commercial deadlines.

Whatever life cycle the project uses, and there are hundreds if not thousands to choose from, they have to be customised to the project to allow the right degree of flexibility to respond to changing requirements and technical problems.  But at the same time project managers need to understand that there is a difference in the meaning of the word “quality” when talking about software.

If someone scores 98% in an examination, we say that have achieved an excellent result.  If a software engineer scores 98% it means that one line in fifty contains an error and the product cannot be shipped.  Pretty good brickwork will not stop a house from being safe and saleable.  Just pretty good programming will produce a software disaster.

So although the project manager has to produce a software product that is “good enough”, they have a difficult job scoping the acceptable level of testing.  The number of software systems with major problems illustrates the possible consequences of this kind of tactical thinking.

Software project management is a very difficult job.  Coping with indeterminacy in the production process, in the technology base, in customer requirements, in a rapidly changing market, together with the constant change in the tools available and the technical knowledge required to understand them, means that it is intellectually challenging and it is no job for the dogmatic or linear thinker.

But at the same time, the achievement in bringing together a complex project which involves people with widely differing skills to solve a unique problem in a way that no-one has ever done before, gives software projects a special appeal.