Xtreme Programming

Thấy mấy chú ở PAN SOFT máu me thằng XP này quá, tớ cũng bỏ công đi tìm hiểu vậy. Lọ mọ sục sạo trên internet cũng vác về được bài báo này, post đây để mọi người cùng đọc:

Giới thiệu chung



Cho tới nay, hai vấn đề lớn đặt ra cho những người hoạt động trong lĩnh vực Công nghệ phần mềm (CNPM) vẫn là:

* Làm sao có thể rút ngắn được thời gian phát triển sản phẩm mà vẫn thỏa mãn được yêu cầu của khách hàng ?

* Làm sao có thể đáp ứng được sự thay đổi liên tục về yêu cầu phần mềm ?

Giải pháp cho hai vấn đề này có thể xem xét từ hai khía cạnh sau: Công cụ và phương pháp luận. Về mặt công cụ, với sự ra đời của các ngôn ngữ lập trình hướng đối tượng mạnh như Java, C++ và các ngôn ngữ mô hình hóa như UML đã đáp ứng được phần nào nhu cầu của những người phát triển phần mềm. Về mặt phương pháp luận, các tiêu chuẩn chất lượng như ISO9001 hay CMM đã giúp cho các doanh nghiệp phát triển phần mềm, định hướng được việc xây dựng quy trình phát triển phần mềm. Đặc biệt, phương pháp luận RUP (Rational Unified Process) có thể coi là một ví dụ điển hình và cụ thể về quy trình phát triển phần mềm.

Các phương pháp luận này, tuy đã giúp cho các doanh nghiệp phần mềm có được những quy trình phát triển phần mềm có tính dự báo cao và ổn định, nhưng vẫn chưa đáp ứng được hai vấn đề đặt ra ở trên. Từ đầu năm 2000, một cuộc cách mạng mới về phương pháp luận phát triển phần mềm đã bắt đầu với sự ra đời của các phương pháp luận hạng nhẹ (lightweight methods) như eXtreme Programming (XP), Crystal, Adaptive Software Development, ... Các phương pháp này được gọi là hạng nhẹ để tương phản với các phương pháp hạng nặng (heavyweight methods) thiết lập dựa trên các tiêu chuẩn ISO9001, CMM hay RUP. Trong số các phương pháp hạng nhẹ, XP đã nhận được sự quan tâm nhiều nhất vì nó đã đề ra hai mục tiêu rất rõ ràng và cần thiết cho CNPM:

* Phát triển sản phẩm một cách nhanh chóng: Với sự phát triển hiện nay của nền kinh tế dựa trên Công nghệ thông tin, doanh nghiệp nào đưa sản phẩm ra thị trường nhanh nhất sẽ chiếm được thị phần có lợi nhất. Phương pháp XP sẽ giúp cho các nhà phát triển phần mềm rút ngắn thời gian phát triển sản phẩm.

* Phát triển sản phẩm đúng theo yêu cầu của khách hàng: thực tế cho thấy rằng nhiều sản phẩm phần mềm tuy được phát triển một cách công phu nhưng lại không đáp ứng được nhu cầu của người sử dụng. Phương pháp XP đã đưa ra các cơ chế cho phép sản phẩm phát triển luôn phù hợp với yêu cầu của người sử dụng.

Trong phạm vi bài báo này, chúng tôi sẽ giới thiệu một cách tổng quan về phương pháp phát triển phần mềm eXtreme Programming.

Các nguyên tắc cơ bản của XP

XP được thiết lập dựa trên bốn nguyên tắc sau:

Trao đổi (Communication): XP chú trọng việc trao đổi thông tin một cách 'trong suốt' giữa các thành viên trong nhóm phát triển. Đề cao việc trao đổi trực tiếp, giảm việc trao đổi gián tiếp hay hinh thức thông qua các văn bản.

* Với XP, khách hàng tham gia trực tiếp vào việc thực hiện dự án với tư cách là một thành viên chính thức của nhóm phát triển. Khách hàng sẽ giúp nhóm phát triển hiểu và nắm bắt được và kịp thời các yêu cầu của người sử dụng (cũng như sự thay đổi về yêu cầu) trong suốt quá trình thực hiện dự án.

* Tất cả các thành viên đều tham gia vào mọi hoạt động trong quá trình phát triển phần mềm. Điều này sẽ nâng cao tính năng động của toàn bộ nhóm phát triển.

Phản hồi (Feedback): Phản hồi sớm và liên tục từ khách hàng cũng như từ nhóm phát triển giúp cho dự án luôn đi theo đúng hướng. XP đều đặn giao sản phẩm cho khách hàng để kiểm tra, theo đó khách hàng có thể 'làm mịn' và hoàn thiện yêu cầu sản phẩm dựa trên các kết quả cụ thể. Với sự trợ giúp của khách hàng, XP xây dựng một tập các phép thử phụ vụ cho việc kiểm định (acceptation test) một cách liên tục trong suốt quá trình phát triển phần mềm.

Đơn giản (Simplicity): XP đảm bảo chỉ phát triển những chức năng mà khách hàng yêu cầu. Phần thiết kế và mã nguồn được thiết lập một cách đơn giản nhất, cho phép có được đặc tính 'mở' cao nhằm đáp ứng với các thay đổi liên tục và luôn duy trì được một tốc độ phát triển nhanh trong suốt quá trình phát triển phần mềm.

Dũng cảm (Courage): XP cho rằng phải có lòng dũng cảm thì mỗi thành viên mới thực hiện được các nguyên tắc kể trên. Tuy XP không chỉ ra một cách rõ ràng, nhưng cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan trọng để thực hiện có hiệu quả phương pháp phát triển phần mềm XP.

12 Quy cách làm việc của XP

Phương pháp XP đã đề ra 12 quy cách (practices) làm việc để thực hiện các nguyên tắc phát triển phần mềm đã nêu ở trên. Theo các chuyên gia trong CNPM, các quy cách làm việc đề ra bởi XP không có gì là mới. Thực chất, những quy cách này là những kinh nghiệm hay nhất thu được trong quá trình phát triển CNPM, đặc biệt là CNPM với công nghệ hướng đối tượng.

Lập kế hoạch (Planning process):
Với XP, khách hàng tham gia trực tiếp vào quá trình lập kế hoạch phát triển phần mềm. Vai trò của khách hàng và nhóm phát triển được định ra một cách rõ ràng.

Trách nhiệm của khách hàng:

* Mô tả tính năng phần mềm cần phát triển thông qua các "câu chuyện" (user story). User story có ý nghĩa tương tự như use case trong UML nhưng mức độ mô tả thì không chi tiết bằng.

* Phân loại các user story theo mức độ quan trọng từ quan điểm người sử dụng (dựa trên giá trị kinh doanh-business value). Từ đó sẽ định ra tính năng nào cần phải phát triển và phát triển theo thứ tự như thế nào.

* Định ra thời điểm và chu kỳ bàn giao sản phẩm

Trách nhiệm của nhóm phát triển:

* Ước lượng yêu cầu kỹ thuật (để phát triển) cho từng user story (ước lượng độ phức tạp).

* Ước lượng thời gian, nhân công cũng như giá thành để phát triển từng user story.

Với sự phân công trách nhiệm như vậy, bản kế hoạch sẽ luôn thỏa mãn được yêu cầu của khách hàng cũng như nhóm phát triển.

Bàn giao từng phần (Small releases)

Theo quy cách này, nhóm phát triển sẽ phát triển dần dần phần mềm, từ đơn giản đến phức tạp. Từng phần sẽ được chuyển giao cho khách hàng để có được ngay sự phản hồi của khách hàng. Từ đó sẽ có thể điều chỉnh ngay được sản phẩm cho phù hợp với yêu cầu của khách hàng. Khách hàng cũng có điều kiện để bổ sung hay thay đổi yêu cầu phần mềm.

Tham gia trực tiếp của khách hàng (On-site customer)

Với XP, khách hàng sẽ tham gia cách trực tiếp trong suốt quá trình phát triển phần mềm. Sự tham gia này sẽ giúp cho nhóm phát triển có điều kiện tham khảo trực tiếp ý kiến của khách hàng, trao đổi về hệ thống cần được phát triển, tránh được nhầm lẫn trong cách hiểu về hệ thống cần phát triển. Mục tiêu cuối cùng là sản phẩm làm ra phù hợp với yêu cầu của khách hàng.

Lập trình đôi (Pair programming)

Tất cả các phần chương trình do một hay nhiều nhóm hai người viết. Hai người này sẽ sử dụng chung một máy tính, cùng đồng thời viết chương trình. Quy cách này sẽ giúp cho có được giải pháp lập trình tốt hơn, chương trình sẽ có chất lượng và hiệu quả hơn.

Thiết kế đơn giản (Simple design)

XP khuyến khích tìm kiếm giải pháp đơn giản khi thiết kế phần mềm. Chỉ thiết kế phần mềm thoả mãn yêu cầu hiện tại của khách hàng, không nên tìm kiếm một giải pháp cho một hệ thống tương lai. Theo đó, chỉ cần một thiết kế làm sao cho chương trình chạy được và thỏa mãn yêu cầu của khách hàng.

Tổ chức lại chương trình (Refactoring)

Quan điểm của XP là chất lượng phần mềm được thể hiện bằng chất lượng của mã nguồn (code). Một chương trình được viết rõ ràng, đơn giản thì sẽ dễ bảo dưỡng và thay đổi. XP khuyến khích tổ chức (viết) lại chương trình một cách đều đặn để nâng cao tính sáng sủa của chương trình, dễ bổ sung các chức năng mới, nâng cao hiệu suất của chương trình.

Kiểm thử (Testing)

XP yêu cầu rất cao trong khâu kiểm thử và kiểm định chương trình. Với mỗi phần của chương trình, lập trình viên phải viết chương trình kiểm thử cho phần đó trước khi thực sự bắt đầu khi viết chương trình (cho phần đó). Khách hàng sẽ chịu trách nhiệm thực hiện kiểm định sản phẩm.

Tích hợp liên tục (Continuous integration)

Việc tích hợp sẽ được tiến hành một cách liên tục. Khi một đoạn chương trình mới được phát triển, đã vượt qua phần kiểm thử, thì sẽ được tích hợp ngay vào hệ thống. Điều này sẽ giúp cho việc phát hiện và sửa lỗi thích hợp nhanh hơn và rẻ hơn. Trong một ngày có thể thực hiện nhiều lần tích hợp hệ thống.

Sở hữu tập thể (Collective ownership)

Tất cả mã nguồn đều thuộc quyền sở hữu của mọi thành viên trong nhóm phát triển. Theo đó, mã nguồn có thể được sửa đổi ngay khi cần. Với cách quản lý thông thường, mỗi phần mã nguồn thường do một người quản lý, nên khi cần sửa đổi thì phải cần sự thông qua chủ sở hữu, đôi khi điều này gây mất nhiều thời gian.

Chuẩn lập trình (Coding standards)

Để chương trình (mã nguồn) có thể hiểu được một cách dễ dàng, nhất là đối với các quy cách lập trình đôi và sở hữu tập thể, nhóm phát triển phải thống nhất cách viết chương trình. Cần phải có một quy định cụ thể, rõ ràng về cách viết (ví dụ, cách đặt tên biến, cách bổ sung chú thích, ..v.v.) để làm sao tất cả đều hiểu được.

Metaphor (Metaphor)

Nhóm phát triển XP dùng chung một hệ thống các thuật ngữ để biểu diễn hệ thống cần phát triển. Các thuật ngữ này sẽ được dùng trong khi trao đổi giữa các thành viên trong nhóm cũng như khi trao đổi với khách hàng.

Không làm việc quá giờ (40 -hour week)

Hiện tượng làm việc quá giờ rất phổ biến trong giới phát triển phần mềm. Thực tế cho thấy khi người lao động làm việc quá giờ thường hay mệt mỏi, dẫn đến làm việc không hiệu quả, chất lượng sản phẩm giảm. XP khuyến cáo không nên làm việc quá giờ, chỉ làm đúng giờ quy định để đảm bảo chất lượng sản phẩm.

Điều kiện để áp dụng XP

Nhóm phát triển nhỏ hơn 10 người. XP có thể áp dụng một cách có hiệu quả trong các nhóm phát triển có số lượng nhỏ hơn 10 người ( quá 10 người thì việc trao đổi giữa các thành viên sẽ rất khó thực hiện được một cách hữu hiệu). XP đặc biệt có hiệu quả trong việc phát triển các phần mềm có yêu cầu luôn thay đổi, khách hàng không định trước được một cách rõ ràng yêu cầu phần mềm.

Đối với các dự án lớn, người ta có thể phân chia công việc cho từng nhóm nhỏ XP. Tuy nhiên, cho đến nay các tác giả của XP chưa đưa ra phương án nào để quản lý, phối hợp hoạt động của các nhóm này. Theo tôi, trong trường hợp này, có thể dựa vào ISO9001 hay CMM để kết lập một quy trình quản lý hoạt động của các nhóm nhỏ XP.

Làm việc theo nhóm

XP đòi hỏi phải có tính năng làm việc tập thể rất cao. Mọi thành viên phải có thái độ hợp tác trong quá trình làm việc bởi vì mọi hoạt động của XP đều mang tính tập thể.

Tính kỷ luật

Mọi thành viên phải tự giác chấp hành các quy định của nhóm phát triển. Ví dụ, tất cả đều phải viết chương trình theo một quy định đã thống nhất. Có như vậy thì chương trình (mã nguồn) mới có thể trong suốt và dễ hiểu với tất cả nhóm, dẫn đến dễ sửa đổi và thêm chức năng mới vào chương trình.

Trình độ thành viên

Với XP, mọi thành viên sẽ tham gia vào mọi hoạt động trong quá trình phát triển phần mềm. Do vậy, các thành viên cần phải được trang bị kiến thức tốt về nhiều mặt và cần có nhiều kinh nghiệm trong nhiều lĩnh vực khác nhau.

Vai trò của khách hàng

Sự tham gia trực tiếp của khách hàng trong suốt quá trình thực hiện dự án phần mềm là một yếu tố không thể thiếu cho sự thành bại của dự án. Khách hàng tham gia với tư cách là một thành viên biên chế của nhóm phát triển sẽ giúp cho nhóm luôn phát triển sản phẩm theo đúng yêu cầu của khách hàng cũng như thỏa mãn được các yêu cầu khách của khách hàng (ví dụ như thời điểm bàn giao sản phẩm, giá thành sản phẩm, ..v.v.)

Thảo luận

Cho đến nay phần lớn các nhà phát triển phần mềm làm việc theo cách 'lập trình-sửa lỗi' (code-and-fixe), hay nói một cách khác là phát triển phần mềm không theo một quy trình nào cả. Một số doanh nghiệp chú trọng tới một tương lai lâu dài đã áp dụng các tiêu chuẩn chất lượng như ISO9001 hay CMM để xây dựng các quy trình phát triển phần mềm phù hợp với đặc điểm riêng của mình. Các quy trình này thường có tính ổn định và dự báo cao. Theo đó, mọi hoạt động liên quan tới phát triển phần mềm đều được kế hoạch hóa và định trước. Tuy nhiên các quy trình này cũng hay bị chỉ trích là quá chú trọng tới quản lý, nặng nề về các quy định và soạn thảo tài lịêu khiến cho tốc độ phát triển phần mềm chậm, đặc biệt là không đáp ứng được các thay đổi nhanh về yêu cầu phần mềm.

Extreme Programming cũng như các phương pháp hạng nhẹ (lightweight methods) khác như Crystal, Adaptive Software Development đưa ra các giải pháp mới cho việc thiết lập các quy trình phát triển phần mềm. Khác với các phương pháp hạng nặng (heavyweight methods) xây dựng dựa trên các tiêu chuẩn ISO9001, CMM hay RUP, các phương pháp hạng nhẹ đơn giản, dễ áp dụng và không cần có sự đầu tư lớn về kinh phí cũng như thời gian. Đặc biệt, các phương pháp này thường có tính mềm dẻo và thích ứng cao, rất thích hợp với các doanh nghiệp phát triển phần mềm trong các môi trường không ổn định và yêu cầu phần mềm thay đổi liên tục.

Như đã trình bày ở trên, các quy cách làm việc của XP tương đối đơn giản và rất gần với các hoạt động hàng ngày của các nhóm phát triển phần mềm. Việc áp dụng một số quy cách của XP sẽ không đạt yêu cầu cần phải có một cuộc 'cách mạng' về quy trình sản xuất trong doanh nghiệp. Áp dụng toàn bộ hay một số các quy cách của XP là một câu hỏi đặt ra cho từng nhóm phát triển.

Mặc dù mới ra đời khoảng 5 năm gần đây, XP đã được nhắc tới như một phương pháp phát triển phần mềm mới, đầy triển vọng, nhất là cho các ứng dụng trong thời đại Internet. XP thành công vì mục đích hàng đầu của nó là nhằm thoả mãn yêu cầu của khách hàng. XP được thiết kế để phát triển phần mềm nhanh, đúng theo yêu cầu của khách hàng và bàn giao đúng thời điểm khách hàng muốn.
(htvinh@ifi.edu.vn)

Hiện nay tài liệu về XP khá nhiều, chỉ cần vô Google gõ Extreme Programming thì có thể choáng ngợp với 431.000 kết quả . Tiện thể ở đây tớ giới thiệu với các bạn 1 số ebook về XP khá hay. Các description mô tả bằng tiếng Anh, mấy u chịu khó translate vậy

1. Extreme Programming Installed:
Modesty limits what we can say here. Unquestionably, however, this is the finest book so far by these three authors. XP Installed addresses the practical issues of running an XP project. Highly recommended, of course. Explains the core principles of Extreme Programming and details each step of the development cycle. Teaches readers how to work with an on-site customer, define requirements with user stories, estimate the time and cost of each story, and perform constant integration and frequent iterations.
Download here

2. Planning Extreme Programming:
The Extreme Programming (XP) paradigm has developers doing things like programming in pairs, writing tests to verify all code, and continuously refactoring designs for improved performance. Written by two of its inventors, Planning Extreme Programming shows you how to implement XP by using a simple, effective process. This remarkably short (yet remarkably useful) title will give any XP manager or programmer a perspective on delivering software that meets the needs of customers better.

At fewer than 150 pages, Planning Extreme Programming is notably concise, and that's probably the whole point. Most shops today work on Internet time, which doesn't wait for extensive project analysis and design documents. In XP, you create working software from the very start. This book is an essential guide to anyone who's working in XP shops or who might be interested in what this innovative, iterative software process can offer
Download here

3. Extreme Programming Explained:
This is it! The first official XP book, Kent's own manifesto explaining the thought and history behind the XP discipline. The whole site's about XP, I needn't go on here. The site wouldn't exist, I wouldn't be doing this, were it not for Kent's "turning all the knobs up to ten" with XP. The book intends to describe what XP is, its guiding principles, and how it works. Simply written, the book avoids case studies and concrete details in demonstrating the efficacy of XP. Instead, it demonstrates how XP relies on simplicity, unit testing, programming in pairs, communal ownership of code, and customer input on software to motivate code improvement during the development process. As the author notes, these principles are not new, but when they're combined their synergy fosters a new and arguably better way to build and maintain software. Throughout the book, the author presents and explains these principles, such as "rapid feedback" and "play to win," which form the basis of XP.
Download here

4. Extreme Programming Explored:
You know what XP is, how to get it up and running, and how to plan projects using it. Now it's time to expand your use of Extreme Programming and learn the best practices of this popular discipline.

In Extreme Programming Explored, you can read about best practices as learned from the concrete experience of successful XP developers. Author and programmer Bill Wake provides answers to practical questions about XP implementation. Using hands-on examples--including code samples written in the Java programming language--this book demonstrates the day-to-day mechanics of working on an XP team and shows well-defined methods for carrying out a successful XP project.
Download here

5. Extreme Programming Adventures in C#:
Apply what you know about extreme programming and object-oriented design to learning C# and the Microsoft® .NET Framework on the fly. Author Ron Jeffries, a leading voice and practitioner in the extreme programming movement, demonstrates how to apply its key concepts—including the use of customer stories, customer acceptance tests, and "Spikes"—and the fundamental techniques of Simple Design, Test-Driven Development, and Refactoring to create practical, .NET-ready applications. You’ll also learn how to use NUnit, a unit-testing tool for .NET languages. This essential, high-level reference provides the expert guidance, hands-on insights, and downloadable code you need to build an XML editor, a database application, a Web service, and other useful applications—quickly extending your extreme programming expertise to .NET and helping you deliver business value right away.
Download here

Thôi nghiền ngẫm 5 cuốn đấy cũng đủ để tẩu hỏa nhập ma rồi, mọi người cứ bình tĩnh mà ngâm cứu ha

Theo Blog HoangThanhTu

Read more »

Những bài học từ một dự án phần mềm

Lượm lặt từ 1 blog trên net. Đọc cũng thấy hay, có thêm vài kinh nghiệm. Mà sao giống cái accounting mình đang làm vậy ta!

Đây là một câu chuyện có thật về một dự án phần mềm trải qua 4 năm và tiêu tốn 35 triệu USD mà không đem lại kết quả nào, và có kế hoạch kéo dài thêm ít nhất là 4 năm nữa. Dự án này diễn ra tại một công ty sản xuất dụng cụ thể thao vào hàng đầu trên thế giới, doanh thu khoảng hơn chục tỷ USD một năm, có trụ sở tại Tây Bắc Mỹ, tạm gọi là công ty N.

Trên phương diện là một study case, đây là một dự án khá độc đáo, và có thể dùng làm bài học điển hình về nhiều khía cạnh khác nhau của một dự án phần mềm, nhất là dành cho các doanh nghiệp sản xuất, dịch vụ đang có ý định ứng dụng công nghệ thông tin vào quy trình sản xuất và hoạt động của mình. Bài viết này hướng tới các đối tượng là

• Giám đốc Công nghệ Thông tin của doanh nghiệp (CIO – Chief Information Technology Officer)
  
• Quản trị Dự án (Project Manager)
  
• Kiến trúc sư phần mềm (Software Architect)
  

và sẽ phân tích qua các khía cạnh sau đây của dự án:

• Quy trình Quản lý (Management Process)
  
• Quy trình phát triển phần mềm (Software Development Process)
  
• Kiến trúc phần mềm (Software Architecture).
  

I. Giới thiệu tổng quát về dự án và tổ chức nhân sự

Dự án này là một dự án xây dựng một hệ thống enterprise software nhằm mục đích phối hợp (collaborate) hoạt động giữa các bộ phận trong hệ thống sản xuất giày dép (Footwear Production) của công ty N trên khắp thế giới, bao gồm:

• Hệ thống quản lý tài liệu Thiết kế giày dép (Footwear production documents), bao gồm tài liệu, bản vẽ mẫu giày dép, tài liệu về nguyên vật liệu, màu sắc, công nghệ ...
  
• Hệ thống quản lý dự án sản xuất (Project Management) để quản lý các dự án cho từng mẫu giày dép, từ thiết kế qua tới thử nghiệm, sản xuất, tiêu thụ ...
  

Hệ thống phối hợp hoạt động giữa các bộ phận khác nhau của công ty N, từ Bộ phận Thiết kế mẫu sản phẩm ở Bắc Mỹ đến các Nhà máy sản xuất giày dép đặt tại châu Á và các Nhà cung cấp nguyên vật liệu trên khắp thế giới, bao gồm:

• Lưu chuyển và quản lý một cách tự động việc đưa mẫu thiết kế từ Bắc Mỹ đến sản xuất thử nghiệm tại châu Á
  
• Thử nghiệm, thu thập thông tin về sản phẩm mẫu, cải tiến, sản xuất chính thức và tiêu thụ, tự động theo dõi hệ thống lưu chuyển nguyên vật liệu và vận tải sản phẩm.
  

Trước đây, công ty đã có thời kỳ sử dụng mainframe computer và COBOL, sau đó tới thời kỳ sử dụng Power Builder và SAP để quản lý một số phần rất nhỏ trong quy trình sản xuất. Hiện nay, công ty muốn xây dựng một hệ thống hoàn chỉnh, toàn diện với những công nghệ mới hiện nay.

Công nghệ được sử dụng trong dự án là J2EE và Oracle database. Application Server là Apache Webserver kết nối với Tomcat servlet engine. Dự án này không phải được xây dựng hoàn toàn từ đầu (build from scratch), mà dựa trên một enterprise platform khá nổi tiếng trong loại phần mềm PDM/PLM (Product Data Management/Product Lifecycle Management) và Enterprise Collaboration Software, có tên là Windchill. Windchill là một sản phẩm J2EE của công ty PTC (Parametric Technology Corp.), trụ sở chính tại bang Massachusetts, Mỹ. Đây là một phần mềm nền tảng (platform), cung cấp toàn bộ cơ sở hạ tầng và các chức năng căn bản cho một hệ thống enterprise software.

Các công ty sản xuất có nhu cầu xây dựng B2B enterprise software để phối hợp hoạt động giữa các bộ phận khác nhau trong công ty, hoặc với các công ty khác, với các nhà cung cấp và khách hàng thường sẽ ít khi xây dựng từ đầu, mà sẽ mua Windchill (hoặc các sản phẩm tương tự, ví dụ như Matrix One, EDS, SAP, People Soft, IBM Dassault ...) về, cải biến và cài đặt thêm (customization) trên platform có sẵn để phù hợp với đặc điểm riêng của doanh nghiệp, và đưa vào sử dụng. Hiện có khoảng hơn 3000 công ty sản xuất lớn trên thế giới đang sử dụng Windchill để điều hành hoạt động của toàn bộ doanh nghiệp, trong đó có nhiều tên tuổi đáng kể như NASA, Boeing, Airbus, Lockheed Martin, Rolls Royce, DaimlerChrysler, Ferrari, Toyota, Bose ... Mỗi dự án triển khai Windchill cho một doanh nghiệp kéo dài vào khoảng từ 6 tháng đến 2 năm (Một thời gian tương đối ngắn cho việc triển khai Enterprise Software, bao gồm cài đặt hệ thống, cải biến và cài đặt thêm, performance tuning, administrator training, user training, chạy thử nghiệm và chạy chính thức).

Từ 4 năm nay, Công ty sản xuất hàng thể thao N cố gắng sử dụng Windchill làm nền cho hệ thống enterprise software của mình, và đã chi hơn 35 triệu USD cùng nhiều nhân tài vật lực vào dự án này..

Bộ phận Sản xuất giày dép (Footwear Production) của công ty N có bộ phận IT riêng của mình, nhưng để triển khai dự án, công ty thuê các chuyên gia tư vấn về Công nghệ thông tin để tiến hành. Đây là cách làm việc rất phổ biến ở Mỹ, vì việc phát triển phần mềm hoặc cài đặt các hệ thống mới chỉ mang tính chất thời vụ, nhưng lại đòi hỏi trình độ chuyên môn cao. Mặt khác, khi hệ thống đã hoàn thành, thì việc vận hành và bảo trì chỉ đòi hỏi trình độ chuyên môn tương đối thấp. Vì thế các công ty sản xuất và dịch vụ chỉ duy trì một đội ngũ IT với trình độ vừa phải, lương thấp để bảo trì và vận hành hệ thống, và khi có nhu cầu làm mới, thì sẽ thuê chuyên viên tư vấn với giá cao, nhưng chỉ trong thời gian thực hiện dự án. Cách làm này giúp cho công ty tiết kiệm chi phí hoạt động, và bảo đảm tính chuyên môn hóa cao (Giả sử là công ty thuê được chuyên gia tư vấn tốt, và tổ chức làm việc theo nhóm một cách có hiệu quả).

Trong quản lý dự án, công ty N sử dụng

1. Một Quản trị dự án (Project Manager) là nhân viên chính thức của N (Permanent full time employee).
   
2. Các nhân viên trong Dự án được chia làm ba nhóm chính:
   

• Nhóm Chuyên gia sản xuất giày dép (Domain expert – Trong trường hợp này, domain là footwear production. Nhóm còn gọi là Footwear Expert)
  
• Nhóm Phân tích Hệ thống kinh doanh (Business System Analyst)
  
• Nhóm Chuyên gia phần mềm (Application Engineer).

Nhóm Chuyên gia sản xuất giày dép là những nhân viên chính thức của công ty N, công việc hàng ngày là thiết kế mẫu giày dép, giao dịch với các nhà máy ở châu Á và công ty cung cấp nguyên vật liệu trên khắp thế giới, là những người sẽ cung cấp thông tin về quy trình, phương pháp và logic làm việc của công việc footwear production cho Dự án.

Nhóm Chuyên gia Phần mềm (Application Engineer) có nhiệm vụ dựa trên những thông tin về quy trình, phương pháp và logic làm việc để xây dựng phần mềm tự động hóa những công việc đó. Trong nhóm này, các vị trí Senior đều là các chuyên viên tư vấn, và ở những vị trí lập trình, có xen lẫn những nhân viên tư vấn có kinh nghiệm và nhân viên chính thức của N.

Trong những dự án phức tạp, đòi hỏi có sự giao tiếp chặt chẽ, chính xác giữa nhóm cung cấp thông tin về sản xuất, dịch vụ với nhóm làm ra phần mềm, thường sẽ có một nhóm trung gian gọi là Nhóm Phân tích Hệ thống sản xuất (Business System Analyst), đóng vai trò trao đổi thông tin giữa Nhóm Domain Expert và Nhóm Application Engineer. Trong Công nghệ Phần mềm, thông thường những chuyên gia sản xuất, dịch vụ và những Chuyên gia Phần mềm nhìn công việc và hệ thống từ những góc nhìn khác nhau, và sử dụng những thứ ngôn ngữ khác nhau để mô tả về hệ thống. Do đó, những chuyên gia trong nhóm Phân tích Hệ thống sản xuất phải vừa có kiến thức về sản xuất lẫn kiến thức về làm phần mềm (về độ am hiểu chuyên môn sâu thì không cần thiết phải như các nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm, nhưng phải am hiểu các khái niệm cơ bản và thuật ngữ) để có thể làm trung gian giữa hai nhóm. Trong nhóm Phân tích Hệ thống sản xuất có cả chuyên viên tư vấn lẫn nhân viên chính thức của công ty N.

Điểm yếu nhất trong ba nhóm của công ty N là Nhóm Phân tích Hệ thống sản xuất. Nhóm này (hoàn toàn trái ngược với yêu cầu) không có một khái niệm gì cả về sản xuất giày lẫn về sản xuất phần mềm. Điều này làm nảy sinh ra tình trạng hoạt động không hiệu quả trong quy trình quản lý và quy trình làm phần mềm.

II. Những điểm yếu trong quy trình quản lý (Management Process)

Công ty N không có một phương pháp chuẩn (methodology) nào trong việc quản lý dự án phần mềm. Dựa trên quá trình thu thập thông tin, chưa xây dựng thành Use Case, chưa qua phân tích và làm specification, mới chỉ dựa trên một vài mục đích, nhận định, công ty đã đưa ra một số giới hạn về thời gian, nhân lực, ngân sách, mà không có căn cứ cụ thể.

Về mặt quản lý, công ty hoàn toàn không có phương pháp cụ thể về việc phân chia trách nhiệm, quyền hạn giữa các nhóm và các thành viên trong các nhóm. Điều này dẫn đến tình trạng có những lúc công việc bị ách tắc hoặc sai lệch, nhưng không tìm được nguyên nhân chính một cách kịp thời, và không quy được trách nhiệm cho đối tượng nào cần phải sửa chữa hoặc có hình thức xử lý.

Công ty cũng hoàn toàn không có một hệ thống hợp lý để theo dõi quá trình làm việc, theo dõi về ngân sách và tiến độ để có thể điều chỉnh cho phù hợp. Điều này dẫn đến các giai đoạn của dự án thường xuyên bị chậm deadline và vượt quá ngân sách dự tính.

Do không có Phương pháp chính thức (formal methodology) để đánh giá về khả năng, trình độ cũng như tốc độ làm việc của từng nhóm và từng nhân viên trong dự án, và do không có đủ trình độ về Chuyên môn Sản xuất giày dép và Chuyên môn về Công nghệ Phần mềm để có thể nhận định được về năng lực và kết quả làm việc thực sự của nhân viên, nên Quản trị Dự án (Project Manager) và Ban Lãnh đạo Dự án thu thập thông tin bằng cách nói chuyện với nhân viên này trong dự án để tìm hiểu về nhân viên kia, họp với nhóm này để lấy thông tin về nhóm kia trong dự án, và dẫn đến những đánh giá chủ quan, cảm tính và thường không chính xác. Sự đời ở đâu cũng thế, những kẻ nói giỏi và những kẻ hay nói thường là làm ăn không ra gì, và thông tin thường là sai lệch. Vì thế Ban Lãnh đạo Dự án hoàn toàn không có một nhận thức chính xác về trình độ nhân viên, tiến trình của dự án, và không nắm bắt được chi tiết những gì đang thực sự xảy ra trong dự án.

Công ty N thực hiện khâu tổ chức thực hiện dự án một cách hết sức máy móc. Hàng tuần, có những cuộc họp cố định vào thứ hai để báo cáo tiến độ công việc, vào thứ ba để xem xét thiết kế phần mềm và thứ năm để trao đổi thông tin giữa các nhóm Chuyên gia Sản xuất, Chuyên gia Phân tích Hệ thống Sản xuất và Chuyên gia Phần mềm. Ngoài ra còn rất nhiều cuộc họp phụ khác. Một tuần làm việc có 40 tiếng, đã có một vài lần tôi phải tham gia họp 30 tiếng một tuần, và có một vài ngày tôi phải ngồi 6 tiếng trong phòng họp.

Mặc dù có cuộc họp để báo cáo tiến độ công việc, nhưng vì thiếu một phương pháp tốt để theo dõi, phân tích, đánh giá tình hình và phân chia trách nhiệm, nên những cuộc họp này chỉ giúp cho Quản trị Dự án nhận ra những gì đã làm được, những gì còn lâu mới xong, mà không biết tại sao, có cách nào làm nhanh hơn không, đâu là vị trí khó khăn tại thời điểm này của dự án ...

Cuộc họp về xem xét thiết kế phần mềm cũng không có tác dụng gì bổ ích mấy, vì công ty N đã tốn 4 năm và chi phí hơn 35 triệu USD để xây dựng một hệ thống phần mềm có nhiều vấn đề về mặt thiết kế (tôi sẽ phân tích kỹ hơn trong phần liên quan tới Kiến trúc phần mềm). Đại khái cũng như trong xây dựng, khi người ta đã vẽ ra một thiết kế có vấn đề và xây nên một vài phần móng có vấn đề, thì việc xây thêm và gia cố cũng khó mà dẫn đến một kiến trúc gì thực sự tốt và có giá trị sử dụng được. Vì thế, các cuộc họp này chỉ nhằm đưa ra những giải pháp chắp vá, tạm thời để tạo ra những chức năng có liệt kê trong danh sách mục đích xây dựng phần mềm.

Nhưng những cuộc họp về trao đổi thông tin giữa các nhóm làm việc mới thực sự là thảm họa. Có một quy định hết sức máy móc là Nhóm Chuyên gia Sản xuất chỉ được nói chuyện với Nhóm Phân tích Hệ thống sản xuất, rồi nhóm này sẽ đi nói lại với Nhóm Chuyên gia Phần mềm. Nhóm Chuyên gia Phần mềm cần hỏi thông tin gì, cũng chỉ được phép nói chuyện với Nhóm Chuyên gia Phân tích, rồi nhóm này sẽ đi hỏi Nhóm Chuyên gia Sản xuất và truyền đạt lại.

Trong khi đó, như đã nói, Nhóm Chuyên gia Phân tích lại bao gồm những người không có khái niệm gì về cả Sản xuất giày lẫn Sản xuất Phần mềm, nên Nhóm Phân tích chỉ đóng vai trò như Nhóm đưa tin giữa hai nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm. Hơn nữa, do không có trình độ chuyên môn, nên nhóm Phân tích không đọc được Use Case Diagram để trao đổi với nhóm Phần mềm, mà cũng không biết các thuật ngữ như size-range, color-bucket ... để nói chuyện với nhóm Sản xuất. Như vậy, hoàn toàn không có một thứ ngôn ngữ chính xác để trao đổi về mặt phân tích yêu cầu, thu thập thông tin và thiết kế hệ thống cho toàn bộ dự án. Ngoài ra, cách tổ chức trao đổi thông tin cũng kỳ quặc: Trong thứ năm của một tuần, Nhóm Phần mềm họp với Nhóm Phân tích, bàn đi bàn lại một hồi, rút ra là có một số vấn đề sau đây chúng ta chưa biết. Nhóm Phân tích sẽ đem vấn đề đó đi hỏi nhóm Sản xuất vào cuộc họp thứ năm tuần kế tiếp. Và trong cuộc họp ngày thứ năm của tuần tiếp sau nữa, Nhóm Phân tích sẽ đem câu trả lời về cho Nhóm Phần mềm. Như vậy là mất 3 tuần cho một câu hỏi và trả lời, và việc này diễn ra trong 4 năm nay, mặc dù đi bộ từ khu nhà của Nhóm Phần mềm xuống Nhóm Sản xuất mất đúng 3 phút, và tất cả các nhân viên trong dự án đều có điện thoại và e-mail. Đó là chưa kể đến sự thiếu hiểu biết chuyên môn của Nhóm Phân tích dẫn đến việc trình bày sai, thiếu phương pháp ghi chép tài liệu (documentation methodology), nên có những vấn đề phải hỏi đi hỏi lại.

Có hai trường hợp điển hình. Một lần có một chuyên gia phần mềm hỏi “Trong thiết kế mẫu, người ta quản lý cỡ giày như thế nào, theo giá trị chính xác (exact size, nghĩa là từng con số 5,6,7,8,9 ..), hay theo khoảng cỡ (size-range, tức là 5-7, 8-10 , 11-12 ...). Sau vài tuần trao đổi đi, trao đổi lại, Nhóm Phân tích không đưa ra được câu trả lời cụ thể. Chuyên gia phần mềm đành phải làm một câu hỏi có nhiều chọn lựa (multi-choice question), gồm có a) Quản lý theo giá trị chính xác, b) Quản lý theo khoảng cỡ, c) Quản lý theo kiểu khác, đề nghị viết rõ, rồi đưa cho Nhóm Phân tích đi hỏi Nhóm Sản xuất, đề nghị khoanh vào a hoặc b hoặc c, thì mới có câu trả lời là a).

Nếu không có quy định quá máy móc là Nhóm Phần mềm không được giao tiếp với Nhóm Sản xuất , hoặc nếu Nhóm Phân tích biết chuyên môn cơ bản và biết sử dụng thuật ngữ, thì tình trạng không đến nỗi thế.

Trường hợp thứ hai là có lần có chuyên gia phần mềm hỏi: “Về mặt quản lý vận tải, trong một lần gửi hàng, có thể có hàng hóa của nhiều đơn đặt hàng được gửi cùng một chuyến hay không?”.

Trước đây công ty N không có hệ thống theo dõi vận tải, mọi giao dịch được làm bằng giấy tờ. Thay vì đi hỏi trực tiếp những người từ trước đến nay vẫn theo dõi việc vận tải bằng sổ sách, Ban Quản trị Dự án họp nhau đoán già đoán non, và cho rằng việc theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải là quá khó(?), nên cho rằng phần mềm chỉ cần theo dõi mỗi chuyến vận tải là một đơn đặt hàng thôi, bất chấp ý kiến của Nhóm Phần mềm là về mặt công nghệ không có gì khó, và ý kiến của Nhóm Sản xuất là trước nay vẫn có nhiều trường hợp một chuyến hàng chứa nhiều đơn đặt hàng. Sau khi Nhóm Phần mềm cài đặt xong Hệ thống theo dõi Đơn đặt hàng và Vận tải, công ty N cử một nhóm 3 người sang châu Á để đưa cho các nhà máy ở châu Á sử dụng thử và thu thập ý kiến phản hồi, thì mới nhận ra là phải làm hệ thống theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải. Kết quả là toàn bộ công việc trong hai tháng trời phải bỏ đi hoàn toàn, làm lại từ đầu.

Một hiện tượng khác điển hình cho sự thiếu cả Kiến thức lý thuyết lẫn Kinh nghiệm thực tế trong Quản lý Dự án phần mềm của Ban Lãnh đạo Dự án là mỗi khi dự án chậm so với thời hạn, Ban Lãnh đạo Dự án lại thuê thêm lập trình viên vào, nhằm cứu vãn tiến độ công việc. Bất kỳ một nhân viên quản trị dự án phần mềm nào khi mới tập tọng vào nghề cũng phải nghe qua định luật Brooks: “Thêm người vào một Dự án phần mềm bị chậm thì chỉ làm cho nó chậm hơn.” Định luật này được Brooks chứng minh bằng mô hình toán học một cách chính xác, và đã được kiểm nghiệm qua rất nhiều dự án phần mềm trong thực tế.

III. Những điểm yếu trong quy trình phát triển phần mềm (Software Development Process)

Công ty N sử dụng một Quy trình Phát triển phần mềm chuẩn trong Công nghệ Phần mềm là Rational Unified Process (RUP). Hiện tại, trong ngành Công nghệ Phần mềm, đại đa số các Dự án Phần mềm lớn và phức tạp đều sử dụng RUP làm Quy trình Phát triển phần mềm. Quy trình này gồm có 4 giai đoạn:

• Khởi đầu (Inception)
  
• Dự thảo chi tiết (Elaboration)
  
• Thực hiện xây dựng (Construction)
  
• Chuyển giao (Transition).
  

Nhưng một quy trình tốt không bảo đảm cho sự thành công của một dự án phần mềm. Phương pháp tiến hành các bước trong các giai đoạn của một dự án là một yếu tố hết sức quan trọng. Trong toàn bộ ba giai đoạn đầu của dự án, công ty N đều phạm phải các sai lầm hết sức cơ bản. Giai đoạn bốn (Transition) chưa bao giờ có, vì chưa bao giờ có sản phẩm chính thức đưa vào sử dụng, nên chưa có sai lầm. Suốt 4 năm từ lúc bắt đầu Dự án cho đến nay, sau khi tiêu tốn hơn 35 triệu USD, công ty N mới đưa ra được một vài kết quả thử nghiệm:

- Hệ thống Quản lý Vật liệu (Material Management). Nghe tên thì như vậy, nhưng thực chất đây là một hệ thống cho phép ghi đối tượng về vật liệu vào database, thêm, xóa, sửa, tìm kiếm ..., nghĩa là các chức năng thông thường của một chương trình quản lý cơ bản bất kỳ cái gì.

- Hệ thống Quản lý màu sắc (Color Management) : Đây là một hệ thống cho phép thêm, xóa, sửa, tìm kiếm màu sắc trong database.

- Hệ thống quản lý Dự án (Project Management), thực ra chỉ là một hệ thống tạo thêm, xóa, sửa, tìm kiếm tài liệu cho các dự án, chứ không có quản lý tiến trình (workflow management) và theo dõi tiến độ dự án (project progress tracking), đang trong giai đoạn chạy thử nghiệm và có đầy lỗi.

Theo Blog HoangThanhTu

Read more »

Phỏng vấn viên: Thử thách và khám phá

Nhiệm vụ của một phỏng vấn viên (PVV) là đưa các bảng câu hỏi đến từng nhóm đối tượng đã được khoanh vùng cùng với những tiêu chí nhất định tuỳ theo yêu cầu của từng dự án.

Công việc của một PVV bắt đầu vào cuộc khi được nhóm trưởng giao việc. Nhiều kế hoạch, hàng loạt các thao tác được lên dây cót, chuẩn bị chu đáo để "mua" được vài giờ thực tế hiệu quả.

Để có thể đối phó, xử lý tốt các vấn đề phát sinh, đòi hỏi PVV phải sức khoẻ dẻo dai bởi công việc đòi hỏi đi ra ngoài nhiều, điều kiện thời tiết thay đổi... Đồng thời áp lực thời gian hoàn thành công việc, chỉ tiêu, chất lượng khá nặng nên tinh thần không vững, chắc chắn sẽ "out" từ trở ngại đầu tiên.

Ra "trận" phải có "bài"

Trước tiên mỗi PVV được tham gia buổi huấn luyện về sản phẩm và đối tượng cần nghiên cứu. Khi có được chỉ tiêu công việc rồi là thời điểm mỗi nhân viên tự biên tự diễn, tự trang bị cho mình kỹ năng làm sao mang về kết quả điều tra nhiều phần trăm thực tế.

Dù có kinh nghiệm trong nghề cũng vẫn cần luyện lại khả năng giao tiếp, thuyết phục của bản thân thông qua những tình huống từ thực tế công việc trước đây. Nếu đối tượng là người dân lao động thì phải có cách nói sao cho rõ ràng dễ hiểu.

Trường hợp "bí" quá thì "bài": "Cháu là sinh viên đi làm thêm..." cùng nét mặt tâm trạng cũng được áp dụng. Còn dự án có đối tượng là khách VIP, là sếp của các đơn vị thì tác phong, trang phục khi diện kiến không thể xem nhẹ. Phải thể hiện để họ thấy được sự chuyên nghiệp cũng như không được có chút sai sót về thông tin sản phẩm khi đối tượng phỏng vấn ngược lại. Và phải ghi nhớ việc gọi điện thoại xin một cuộc hẹn nếu không thì cơ hội gặp cũng "bói" không ra.

Phải làm gì khi nghe không rõ hay không hiểu cũng là tình huống các PVV phải tập dượt kỹ. Nếu yêu cầu trả lời lại sẽ gây sự khó chịu, làm giảm độ nhiệt tình. Trong khi, thông tin nghiên cứu luôn phải trung thực nên không thể suy diễn hay cứ viết đại khái theo cách hiểu của mình.

Miệng Tô Tần, chân bộ đội

Thời gian làm việc của PVV khá linh động và phần lớn PVV chọn làm bán thời gian, mỗi buổi kéo dài khoảng 5 giờ. Tuy nhiên, để có được kết quả mong đợi sau vài tiếng thì thực sự "đổ mồ hôi, sôi nước mắt". Dưới đây là một buổi làm việc của Nguyễn Đào Thiên YÁ khi làm PVV cho Cty TNS.

10 giờ 30: Phóng xe thẳng tiến chợ Bến Thành vì hôm nay tìm hiểu về nhu cầu sử dụng internet của các tiểu thương nơi đây. Nắng cháy da nhưng chịu vậy vì phải tranh thủ phỏng vấn lúc họ nghỉ trưa. Nghe tụi bạn đồn bảo bán hàng ở chợ hơi bị kiêu, không dễ gần nên cũng có chút ngán thật. Nhưng bấm bụng đi vì đây là đối tượng bắt buộc, không thể thay đổi. Mà mỗi bản khảo sát lần này mất chừng 3 phút là cùng. Tự an ủi biết đâu với mình lại khác.

11 giờ 00: Gửi xe, đeo bảng tên nhân viên công ty. Chuẩn bị luôn tờ giấy giới thiệu trình quản lý chợ tránh tai nạn nghề nghiệp do sự hiểu nhầm và nhất là nghĩ mình làm điều gì mờ ám. Lật tờ phiếu đầu tiên - "mong người mở hàng mau mắn, dễ tính".

11 giờ 15: Tiếp cận chị chủ sạp khá trẻ, trình bày mục đích. Tờ giấy chìa ra thu về nhanh chóng cùng nụ cười làm mình mừng "trời nghe rồi". Đến người thứ 5 thì có dấu hiệu khó chịu. "Internet hả, ở nhà có nhưng tui không xài. Mà hỏi làm gì vậy?". Lần lượt tài ăn nói được đem ra trưng dụng. Miệng muốn mỏi thì nhận được lời đồng ý trả lời phiếu khảo sát. Toàn bộ các câu hỏi đều có chung một đáp án - chữ không viết tắt (số 0 gạch dưới) - nhanh đến chóng mặt. Quan sát xung quanh thì còn rầu hơn "các sạp kế bên tham gia nghe ngóng vòng ngoài từ nãy giờ nên chắc chắn không thể làm tiếp được". Đành bỏ qua một ít rồi chút quay lại sau.

12 giờ 30: Nhìn đồng hồ, tá hoả khi chỉ tiêu 40 phiếu chưa hoàn thành được nửa. Nghĩ lại thấy lời đồn của thiên hạ đúng thật. Chọn một bác đang nhìn mình có vẻ thắc mắc không hiểu con nhỏ đang làm gì. Chớp lấy thời cơ giải thích công việc ngay. Hợp tác vui vẻ, bác cho tha hồ hỏi. Không những thế mà còn được an ủi phần nào khi được quan tâm hỏi han. Nghĩ cứ như vừa bị đấm vừa được xoa. Thế cũng may mắn chán.

Gần 3 giờ chiều: Chân mỏi, miệng mỏi, mắt biểu tình đòi nhắm trong khi công việc vẫn chưa xong. Nhận được tin nhắn thu hồi lực lượng của chị đội tưởng. Tập trung rồi mới biết kết quả của mình xem ra khả quan hơn nhiều đồng đội. Sau gần 4 năm ăn cơm nghiên cứu thị trường, đây là lần thất bại thảm hại nhất của mình. Đợt làm tới tại chợ An Đông chắc sẽ sáng sủa hơn - cứ tin thế để có khí thế tiếp tục.

Theo Lao Động

Read more »

Những viên gạch thành công được xây từ giảng đường

Trường học không chỉ là nơi mang lại cho bạn kiến thức cần thiết, học vị, bằng cấp mà còn là cơ sở để bạn xây những viên gạch vững chắc đầu tiên cho sự nghiệp tương lai của mình. Xin đơn cử 7 “viên gạch” đầu tiên bạn nên đặt cho nền móng của mình.

1. Không đi học muộn:

Rất hiếm thầy/cô chấp nhận những sinh viên thường xuyên đi học muộn, nếu có thì bạn cũng sẽ bị trừ điểm. Sếp của bạn cũng vậy, họ rất khó chịu khi bạn luôn đến muộn hơn người khác và không hoàn thành dự án đúng thời hạn. Vì thế hãy cố gắng làm việc cùng với chiếc đồng hồ.

2. Không bỏ tiết:

Bạn sẽ được các giảng viên đánh giá cao khi tham gia lớp học đầy đủ và đúng giờ. Tương tự như vậy, sếp sẽ chú ý tới thời gian nghỉ việc của bạn để đánh giá sự chuyên cần và độ tin cậy. Vì vậy, đừng nghỉ làm nhiều trừ khi có chuyện gì khẩn cấp hoặc khi bạn bị bệnh thật sự.

3. Ghi chép bài đầy đủ:

Trong lúc nghe giảng, bạn cần có giấy và bút. Khi đi làm, bạn cũng nên ghi chép lại lúc nghe điện thoại, lúc học được điều gì mới mẻ hoặc khi ai đó cho bạn biết những thông tin mà có thể bạn cần dùng sau này.

4. Ôn lại bài:

Cuối ngày bạn nên xem lại những gì mình đã học để nhớ bài lâu và bổ sung thêm những chỗ còn thiếu sót. Kiến thức không được ôn luyện sẽ dần mai một.

5. Chú ý tới giáo sư:

Cùng một bài thi nhưng do hai giáo sư khác nhau chấm thì điểm số của bạn lại khác nhau. Tại sao vậy? Đó là do mỗi giáo sư có một cách dạy học và cho điểm khác nhau. Trong công việc, hãy chú ý xem sếp hiện tại mong chờ gì ở bạn, đâu là điều sếp cần...

6. Tham gia các hoạt động ngoại khóa:

Bạn càng tham gia nhiều hoạt động thì đầu óc tổ chức và năng suất làm vệc của bạn càng cao. Điều đó không có nghĩa là bạn phải tham gia vào tất cả các hoạt động, chỉ cần tham gia một hay hai hoạt động là đủ. Bạn cũng có thể khám phá những hoạt động mới và học thêm vài kỹ năng mới, chúng sẽ có ích cho công việc hiện tại cũng như sau này của bạn.

7. Chuẩn bị kỹ cho kỳ thi:

Kỳ thi và buổi thuyết trình dự án có nhiều điểm giống nhau. Bạn đều phải chuẩn bị kỹ cho cả hai. Thử tưởng tượng bạn sẽ ra sao nếu trong buổi thuyết trình một dự án quan trọng, bạn lại không photo đủ bản đề án? Đừng để điều này xảy ra với bạn. Chuẩn bị thật kỹ, bạn sẽ không bao giờ phải hối tiếc.

Theo Vieclam.vtv/TTO

Read more »

10 nguyên tắc bán hàng mới

Có ít nhất 10 nguyên tắc chỉ ra được nhu cầu ngày nay của khách hàng là gì cho dù đó là những mặt hàng họ mua hay những gian hàng họ xem. Kèm theo đó là 10 ví dụ về các công ty đã gặt hái thành công khi áp dụng những nguyên tắc bán hàng đó.

Nguyên tắc số 1: Tôi muốn nó theo cách của tôi

Chẳng có gì ngạc nhiên cả, bất cứ ở đâu, bất cứ khi nào, khách hàng luôn muốn những sản phẩm và dịch vụ mà họ bỏ tiền ra phải phù hợp với các yêu cầu của mình.

Hãng Scion đã để cho các khách hàng tự thiết kế những chiếc xe hơi của họ qua trang web của công ty. Khách hàng có thể tùy ý thay đổi từ nội thất, bộ truyền lực, đèn, tấm lái ngang, vô lăng, hệ thống âm thanh, tay gạt, động cơ, khớp ly hợp, gương, cho tới màu sơn - và sau đó chỉ việc đưa chiếc xe đó tới người bán theo lựa chọn của họ là xong. Thậm chí Scion còn cho phép các khách hàng có thể mặc cả trực tuyến.

Nguyên tắc số 2: Tôi muốn có dịch vụ giống thế không cần biết ở đâu

Dù là trực tuyến, qua điện thoại hay ở trong cửa hàng thì các khách hàng đều muốn có chất lượng và dịch vụ tốt như nhau. Và họ mong chờ những thông báo bắt nguồn từ nơi này thì sẽ có tương tự ở nơi khác.

Trong lĩnh vực này thì JCPenney là nhà cung cấp chuyên nghiệp. Đây là một chuỗi các nhà hàng bán lẻ qua Internet với lượng khách hàng thường xuyên đăng ký mua hàng là 35.000 lượt. JCPenney cũng là một trong số những công ty đầu tiên áp dụng bán hàng trực tuyến bằng cách khách hàng xem catalog và đặt hàng trực tuyến tại cửa hàng. Khách hàng bây giờ có thể kiểm tra những bộ quần áo mà các cửa hàng bán lẻ mang đến so với những bộ quần áo gốc tại những cửa hàng địa phương của họ, kể cả về đặc tính nếu cần. Vậy chẳng có gì ngạc nhiên khi bây giờ Internet đưa về cho công ty 6% doanh thu bán hàng, vượt xa những đối thủ cạnh tranh ban đầu.

Nguyên tắc số 3: Phải biết đến tôi

Khách hàng luôn mong muốn các công ty mà họ đã mua hàng phải biết họ cũng như điều họ muốn, luôn coi họ là khách hàng quen thuộc. Một vài hãng hàng không đang dẫn đầu nhờ cho phép những hành khách gắn bó lâu năm được lên máy bay trước, được sử dụng một số thứ miễn thuế đối với dịch vụ nhanh cũng như nhận được nhiều ưu đãi.

Nguyên tắc số 4: Hãy truyền thông tin quan trọng

Các khách hàng không cần nhiều thông tin mà họ cần những thông tin quan trọng. Họ mong chờ nội dung, thời gian, nguồn gốc và tần số truyền thông sẽ phản ánh được nhu cầu và quyền lợi của họ.

Amazon.com thực hiện hết sức thành công trong lĩnh vực này bằng cách biến đổi nội dung trang web cho phù hợp, đưa ra những lời giới thiệu cũng như những truyền thông bằng thư điện tử nhằm phản ánh những sở thích của khách hàng.

Nguyên tắc số 5: Hãy lắng nghe tôi

Các công ty phải nắm bắt được phản hồi từ khách hàng một cách nghiêm túc. Bất kể ở đâu nếu được, hãy hỏi ý kiến các khách hàng về tất cả mọi thứ, từ việc thiết kế và phát triển sản phẩm cho tới những cách tiếp thị cụ thể tốt nhất.

Gần đây Frito-Lay đã thu hút được sự quan tâm nhờ việc cải cách trong lĩnh vực này. Qua việc luôn tư vấn cho những người tiêu dùng bằng cách truyền thông trực tuyến với các chủ để luôn thay đổi như việc đóng gói, phân phối hay quảng cáo, công ty đã áp dụng việc phản hồi này để hiểu và cải tiến các chủng loại hàng hóa của mình sao cho phù hợp với phong cách tiêu dùng của các khách hàng.

Nguyên tắc số 6: Hãy làm cho việc mua bán giữa chúng ta trở nên dễ dàng

Đối với một số tổ chức, nguyên tắc này thể hiện nhiều thách thức. Lấy ví dụ, nó có thể đòi hỏi một đội ngũ nhân viên chuyên nghiệp. Việc bảo đảm suốt đời của L.L. Bean là một ví dụ tiên phong về việc áp dụng nguyên tắc này. Công ty này cho phép các khách hàng được trả lại bất kỳ món hàng nào vào bất kỳ thời điểm nào mà không đặt ra bất kỳ câu hỏi nào.

Nguyên tắc số 7: Hãy làm tôi ngạc nhiên và thích thú

Các khách hàng rất thích nhận được những thứ bất thường khiến họ phải thốt lên “Chà!”. Hãy xem Infinity, mỗi khi làm dịch vụ, công ty này thường rửa cả trong lẫn ngoài những chiếc xe hơi, và thế là trong suốt thời gian làm dịch vụ họ đưa cho các khách hàng mượn miễn phí một chiếc xe hơi có cùng kiểu dáng và cấu tạo giống như chiếc xe khách hàng đang lái.

Nguyên tắc số 8: Hãy cải cách và thay đổi

Điều này cần được thực hiện trước khi doanh thu hoặc số lượng khách hàng bắt đầu giảm xuống. Chỉ bởi vì một hãng bây giờ có một sản phẩm hoặc một dịch vụ tốt cũng không có nghĩa rằng các khách hàng vẫn sẽ coi hãng đó có uy tín trong năm năm tới được.

Nguyên tắc số 9: Phải đáng tin cậy

Trở thành một nguồn đáng tin cậy. Nguyên tắc này chính là mấu chốt quan trọng nhất trong việc các tổ chức xây dựng được những mối quan hệ tồn tại lâu dài với khách hàng. Nếu muốn chiến thắng và giữ được khách hàng thì các công ty phải chứng minh được rằng các sản phẩm, con người và cả việc truyền thông của họ xứng đáng đạt được mức độ tin tưởng cao như vậy.

Disney thực hiện điều này rất tốt. Khu giải trí này đã phát triển các khu quy hoạch và dịch vụ du lịch khiến cho các khách hàng luôn tin tưởng khi chọn đây làm nơi vui chơi cho những kỳ nghỉ thú vị hơn.

Nguyên tắc số 10: Hãy ủng hộ việc từ thiện bên cạnh chuyện kiếm tiền

Đúng như báo cáo tài chính, ngày càng nhiều những khách hàng bỏ cả một khoản tiền ra cho những nhãn hàng vô danh. Khi đó nó dẫn tới việc xây dựng một nhãn hàng nổi tiếng phản ánh được các giá trị khách hàng, ví dụ như cân nhắc những sáng kiến ủng hộ từ thiện quan trọng, trồng cây xanh và sử dụng các sản phẩm tái chế, hoặc cho nhân viên thời gian làm các công việc tình nguyện.

Theo Minh Hà
Bwportal/Knowthis.com

Read more »

Các giám đốc mới cần biết những gì?

Bạn nhận được lời mời tham gia vào đội ngũ quản lý của một công ty, bạn hoàn toàn tự tin và trả lời là “có”. Chắc chắn sẽ có đôi điều bạn cần làm trước cuộc gặp gỡ đầu tiên này.

Một khi bạn chấp nhận lời mời tham gia vào “bộ sậu” quản lý, công ty sẽ tổ chức một chương trình định hướng dành riêng cho cho bạn. Những giám đốc giỏi luôn chắc chắn rằng họ nắm vững tất cả những gì cần biết trước khi họ bước chân vào phòng hội đồng quản trị và không ngừng đưa ra các câu hỏi cụ thể để có thêm được thông tin, các cuộc họp bàn và ghé thăm nhiều nơi.

Mục đích sau cùng là thực hiện thành công các kế hoạch kinh doanh công ty đã đề ra. Dưới đây là một vài yếu tố bạn sẽ muốn và cần tìm hiểu rõ:

Các ký hiệu, thuật ngữ chuyên môn

Các ký hiệu, thuật ngữ, tên gọi, tên viết tắt chuyên ngành thường được sử dụng trong các cuộc họp ban quản lý. Điều này có thể khiến nhiều giám đốc mới trở nên bối rối, và bất đắc dĩ phải đặt câu hỏi để người diễn giải ý nghĩa trong khi mọi người khác dường như đã hiểu rõ.

Để tránh khỏi khúc mắc này, bạn hãy đề nghị được cung cấp một bạn từ điển thu nhỏ các thuật ngữ có liên quan tới công ty và tới lĩnh vực kinh doanh của công ty.

Chiến lược, các vấn đề then chốt và những nhân vật hàng đầu

Đây là ba yêu tố quan trọng nhất mà bất cứ nhà quản lý mới nào cũng cần tìm hiểu ngay khi bước chân cánh cửa công ty.

Thông thường, cách thức tốt nhất đó là dành ra hai ngày tại trụ sở công ty để gặp gỡ trực tiếp với từng nhà quản lý cấp cao, bắt đầu với CEO (Giám đốc điều hành) và các CFO (Giám đốc tài chính). Tiếp theo đó là các nhà quản lý khác trong nấc thang điều hành của công ty.

Điều này sẽ cho phép các nhà quản trị cấp cao của công ty biết hơn về bạn trước khi họ bắt đầu làm việc với bạn trong phòng họp và đem lại cho bạn cơ hội để tìm hiểu về công ty trong một nơi mà bạn có thể thoải mái đặt ra các câu hỏi.

Bạn có thể đã từng gặp gỡ CEO hay có thể là CFO trong quy trình tuyển dụng giám đốc, song cuộc gặp lần này sẽ rất khác biệt. Nó hướng tới việc cung cấp cho bạn những hiểu biết sâu hơn về các vấn đề then chốt tương thích với một vài người nào đó đóng vai trò quan trọng trong ban giám đốc.

Cuộc gặp gỡ đầu tiên nên là với CEO để bạn có được một cái nhìn tổng quan về công ty và những vấn đề then chốt công ty đang phải đối mặt, thông thường bao gồm cả những thấu hiểu sâu về chiến lược kinh doanh của công ty.

Sẽ rất hữu ích với việc bạn hỏi xem có tài liệu chiến lược kinh doanh gần đây nào của công ty mà bạn có thể xem qua trước hay liệu CEO có thể cung cấp cho bạn những thông tin giá trị nào không. Cuộc gặp gỡ với CEO sẽ đem lại cho bạn cơ hội để tìm hiểu về các con số, các mục tiêu cũng như hiểu được các phương pháp đánh giá hoạt động kinh doanh chủ yếu được sử dụng.

Bên cạnh đó, không tồi chút nào nếu bạn đề nghị CFO giới thiệu cho bạn về bản báo cáo tài chính trong quý gần đây nhất của công ty. Nếu bạn cũng có chân trong ban kiểm toán nội bộ, luôn là một ý tưởng thích hợp khi dành thời gian trò chuyện với các nhà kiểm toán nội bộ.

Tiếp theo bước khởi đầu này, bạn cần lên kế hoạch cụ thể cho ngày tiếp theo sẽ gặp gỡ những ai, ở vị trí nào. Chắc chắn bạn sẽ có rất nhiều cơ hội để đặt ra các câu hỏi khác nhau nhằm tăng thêm sự hiểu biết của mình về công ty.

Ghé thăm các địa điểm

Nhiều công ty thường tổ chức các chuyến thăm qua các địa điểm của công ty cho những giám đốc mới. Nếu không có chuyến thăm quan nào nằm trong kế hoạch định hướng cho bạn, hãy yêu cầu ít nhất một chuyến.

Ví dụ, nếu công ty có hai ngành kinh doanh chính, bạn có thể muốn ghé thăm một cơ sở hoạt động trong từng ngành. Nếu các hoạt động của công ty dễ dàng tiếp cận, chẳng hạn như ngành công nghiệp bán lẻ, bạn có thể tự mình thăm quan các cửa hàng hay các nhà kho,.... Bên cạnh đó, đừng quên ghé thăm một vài cửa hàng của các đối thủ cạnh tranh chính.

Một vấn đề cần quan tâm khi ghé thăm các địa điểm hoạt động đó là đội ngũ nhân viên thường nêu lên các vấn đề về lương thưởng, về tài chính hay phàn nàn về các chính sách của công ty. Đã xảy ra trường hợp 3 giám đốc mới của một công ty lớn ghé thăm một xưởng sản xuất trực thuộc và nhà quản lý xưởng sản xuất này phàn nàn về 3 triệu USD tiền mở rộng nhà xưởng không được cung cấp đầy đủ. Các giám đốc mới này nói với nhà quản lý rằng “đó có thể là một sai sót”.

Ngay khi ôtô của ba giám đốc mới rời bánh khỏi xưởng sản xuất, vị quản lý nọ lập tức gọi điện tới CEO của công ty và nói rằng ông đã nhận được sự giúp đỡ về ngân sách từ cấp quản trị cao nhất.

Không cần phải nói, ba giám đốc mới này - những người có quá ít kiến thức về các con số kinh doanh và các quyết định tài chính - sẽ đương đầu với những đón tiếp lạnh nhạt từ hội sở công ty. Có thể thấy, những phản hồi tốt nhất trong các trường hợp này đó là bạn nói rằng đã ghi nhận vấn đề và sẽ chuyển lời tới CEO để có những quyết định tiếp theo.

Tìm hiểu về Hội đồng quản trị, về Ban giám đốc

Các bản điều lệ công ty, quy định về tổ chức, hướng dẫn hoạt động hay các quy định pháp luật địa phương luôn rất đáng để xem qua. Tuyệt vời hơn nữa là việc hỏi về những đánh giá nhân sự cấp cao gần đây nhất, qua đó bạn có được những thấu hiểu sâu hơn về cách thức hội đồng quản trị hay ban giám đốc nhìn nhận các điểm mạnh và điểm yếu của mình. Một tài liệu quan trọng khác đó là bản đánh giá hoạt động mới nhất đối với CEO.

Các cuộc phỏng vấn tuyển dụng sẽ đem lại cơ hội cho bạn được gặp gỡ một vài thành viên của ban giám đốc, của hội đồng quản trị, nhưng không phải là tất cả. Hãy cố gắng gặp gỡ càng nhiều các giám đốc ở các cấp bậc tương tự như bạn càng tốt.

Cách thức hỏi học này đòi hỏi khá nhiều thời gian và công sức vốn rất khó đáp ứng tốt trong lịch trình làm việc bận rộn của một giám đốc. Tuy nhiên, trong môi trường quản trị kinh doanh ngày nay, thật thiết yếu với những nỗ lực học hỏi thật nhanh chóng và thật sâu rộng của bạn.

Nhờ đó, bạn không chỉ có thể đóng góp nhanh chóng hơn cho công ty trên cương vị một giám đốc, mà bạn sẽ còn cảm thấy tự tin hơn khi biết rõ những gì đang thực tế diễn ra tại một công ty mà bạn vừa mới nhận lời mời làm việc.

Theo Tuyết Mai

Bwportal/Businessweek

Read more »

“Trị” cấp dưới khó bảo

Đôi khi, việc cấp dưới không chịu phục tùng khiến cấp trên phát điên. Phải làm gì để “trị” những nhân viên không chịu nghe lời. Dưới đây là 10 lời khuyên của các chuyên gia quản lý lâu năm dành cho những vị sếp bị nhân viên “qua mặt”.

1. Hãy làm trái với thông lệ

Đừng phàn nàn khi nhân viên rời công sở vào thời điểm chính xác mỗi ngày mà lẽ ra công việc đã được hoàn thành. Hãy khuyến khích họ về nhà và không làm việc quá giờ. Việc hứa hẹn với nhân viên sẽ cho họ nghỉ vào đúng giờ tan sở sẽ là một phần thưởng cho những người mà chưa làm xong những việc mà họ đã có thể làm.

2. Đừng dọa nạt

Một đặc điểm tiêu biểu của những ông chủ kém cỏi là yêu cầu mọi người làm những điều không thể. Những ông chủ kiểu này là người cuối cùng mà nhân viên muốn làm việc cùng và cũng chính là người làm tổn hại đến năng suất lao động bằng cách ca thán và phản đối liên miên. Hãy điều chỉnh mục tiêu theo hướng thực tế.

3. Hãy “giương vây”

Đừng bao giờ để nhân viên gây khó cho bạn bằng cách không làm đúng công việc của mình. Chính nhân viên phải học hỏi từ những lỗi lầm của họ.

4. Đừng cố cạnh tranh với nhân viên

Hãy nhớ rằng thời đại này là xã hội chuộng nhân tài. Chính bạn, chứ không phải nhân viên của bạn, sẽ bị thiệt hại nếu bạn thua trong cuộc cạnh tranh với nhân viên. Nhân viên chỉ phải cạnh tranh với đồng nghiệp của họ thôi.

5. Lên kế hoạch cho những cuộc tụ tập sau giờ làm việc

Những ông chủ ngẫu hứng ra quyết định về một cuộc tụ tập sau khi tan sở thường bị một số nhân viên coi là “kẻ lạm dụng”. Hãy hỏi xem các nhân viên nghĩ gì, hãy lên kế hoạch trước thật kỹ cho cuộc gặp mặt này. Điều đó sẽ giúp bạn không phải cảm thấy “bị bẽ mặt” vì những nhân viên thẳng thừng từ chối tụ tập vì đã bận việc khác, hoặc sẽ tránh cho bạn khỏi bị “nói sau lưng”.

6. Hãy lôi kéo những nhân viên tự tin về mình

Một số nhân viên rất thẳng thắn về những điều họ nghĩ và họ tự hào về bản thân khi làm tốt việc gì. Họ không bao giờ quên hỏi tại sao họ phải làm những gì được bạn yêu cầu. Họ có thể là một “của nợ” làm ảnh hưởng đến việc làm chung theo nhóm, nhưng một khi bạn nắm được họ rồi, bạn sẽ có thế trông cậy vào họ đấy.

7. Hãy chấp nhận tính cách riêng của nhân viên

Bạn nghĩ mà xem, thật khó thay đổi tính cách của bạn. Và lại càng khó hơn để thay đổi tính cách nhân viên của bạn. Vì vậy, đừng bao giờ thử thay đổi họ nhé, hãy cứ chấp nhận con người họ như là họ vẫn thế. Nhưng đừng dung tha cho những kẻ xu nịnh, nếu không họ sẽ cố “bồi thường” những lỗi lầm của mình bằng cách tâng bốc bạn lên mây xanh đó.

8. Hãy thẳng thắn

Đừng tha thứ cho thói chậm trễ, những lời bào chữa và việc làm quá giờ không cần thiết. Hãy nói thẳng với nhân viên rằng họ được tự do làm những gì họ thích, nhưng đừng tin cậy những người không thể quản lý chính mình. Hãy nói mặt đối mặt với nhân viên khi họ cư xử sai thay vì việc phàn nàn sau lưng họ.

9. Hãy giữ bình tĩnh dù có bất cứ chuyện gì xảy ra

Nổi nóng không phải là cách để đối mặt với nhân viên bởi vì họ không sợ cãi lại. Đừng cố bị cuốn vào cuộc chiến tranh cảm xúc với họ. Thay vì đó, hãy tạo một cuộc họp giữa bạn và nhân viên đó để nói chuyện nghiêm túc về vấn đề cần tranh luận.

10. Hãy chuẩn bị cho những điều tồi tệ nhất

Hãy ghi chép lại những gì bạn nói với nhân viên, và hãy lưu giữ những bức e-mail trong trường hợp bạn bị liên đới vào một cuộc tranh chấp.

Theo Tuổi Trẻ

Read more »

Khi nhân viên vắng mặt đột xuất

Việc nghỉ phép đột ngột, không báo trước của nhân viên, dù với bất kỳ lý do gì cũng khiến người lãnh đạo khó chịu và gây ảnh hưởng xấu tới hiệu quả công việc. Là một người sử dụng lao động, bạn sẽ xử sự thế nào khi đột nhiên không thấy nhân viên đi làm?

Cách làm tốt nhất là tất cả nhân viên đều phải được hướng dẫn quy trình làm đơn xin nghỉ phép. Cấp trên trực tiếp phải được hướng dẫn giải quyết các tình huống nghỉ việc đột xuất, khi nhân viên quay lại làm việc, tất nhiên cả việc ra quyết định kỷ luật nếu cảm thấy cần thiết.

Trách nhiệm của người cấp trên trực tiếp

• Đảm bảo tất cả nhân viên biết quy định về việc nghỉ phép.

• Việc đầu tiên cần làm là kiểm tra điện thoại bàn ở nhà của người nghỉ đột xuất.

• Tập hợp các chi tiết cần thiết, chính xác và kịp thời về lý do vắng mặt của nhân viên dưới quyền (ngày bắt đầu nghỉ, lý do vắng mặt, ngày quay lại làm việc, giấy tờ xác nhận nơi đến khi bỏ việc ở công ty, ví dụ đơn thuốc của bác sĩ).

• Ân cần hỏi han nhân viên khi họ quay lại làm việc để tìm hiểu rõ nguyên nhân nghỉ việc.

• Đưa ra hình thức kỷ luật nếu cần thiết.

Kiểm tra khi nhân viên quay lại làm việc

Cần hỏi han nhân viên ngay khi người đó quay lại làm việc để thể hiện rõ sự quan tâm, đồng thời thể hiện sự cứng rắn trong quản lý đối với những trường hợp nghỉ đột xuất.

Cấp trên nên đưa ra lời khuyên giúp nhân viên nghỉ việc đột xuất giải quyết khó khăn của mình nếu người đó gặp trục trặc riêng tư hay chuyện gia đình. Nếu nghi ngờ lý do nghỉ việc của những người mình phụ trách thì đây là cơ hội tốt để cấp trên giải tỏa những nghi ngờ đó.

Cũng cần nhấn mạnh rằng sự vắng mặt đột xuất của người đó đã ảnh hưởng đến quá trình làm việc của công ty, sau đó có thể gợi lại những thành tích mà nhân viên đó đã đạt được để tạo sự đối lập với việc nghỉ đột xuất đáng bị kỷ luật. Đối với số ít thiểu số nhân viên vắng mặt đột xuất với lý do không chính đáng thì khi họ nghỉ việc đột xuất lần thứ hai liên tiếp, cần có những biện pháp trừng phạt nếu thấy cần.

Điều quan trọng nhất là cấp trên phải đối xử nhất quán và công bằng với mọi người.

Theo Doanh nhân Sài Gòn Cuối tuần

Read more »