Đây là một kĩ thuật dùng cho cá nhân phản tư (reflection) hoặc nhóm Scrum dùng cho phiên họp rà soát – cải tiến (retrospective). Vừa kết thúc một dự án, vừa xong một Sprint, vừa trải qua một hội thảo hay khóa học, ta đều có thể sử dụng để thực hiện suy tưởng-cải tiến.

Cách làm:

1. Vẽ lên tờ giấy khổ lớn (A2) ba vòng tròn đồng tâm

2. Dùng tờ giấy ghi chú (post-it notes) màu vàng viết về những điều vừa quan sát được, vừa trải nghiệm (nghe thấy, đọc thấy, nhìn thấy, trải qua …). Dán vào khu vực ngoài cùng.

3. Dùng giấy xanh viết ra những điều thể hiện rõ tâm trạng, cảm xúc của bạn về những điều trên (“tôi thấy rất thích|bực|ghét|phấn khích … bởi vì…”). Trong cùng thời gian, hãy nghĩ sâu hơn về những thứ trong danh mục các tờ dán màu vàng. Không nhất thiết phải viết ra tất cả. Hãy tuân thủ khung thời gian (khoảng 5-10 phút tùy bạn đặt). Nếu làm trong nhóm, hãy chia sẻ với nhau những cảm xúc này.

4. Dùng giấy xanh lá cây (hoặc màu khác mà bạn có), viết ra những điều mới mẻ bạn nhận ra, những điều bạn ngộ nhận, những điều có thể làm tốt hơn. Nếu làm việc trong nhóm, hãy thảo luận về những điều này. Nhớ tuân thủ khung thời gian (khoảng gấp đôi thời gian của bên trên).

5. Dùng giấy dán màu đỏ viết ra những điều bạn định làm trong tuần tới (hoặc Sprint tới) căn cứ trên những điều đã học được, nhằm mục đích cải tiến, hoặc đổi mới. Chú ý tới tính khả thi của hành động, các tiêu chuẩn để kết thúc công việc (khi nào thì xong, ai review, …). Trong khung thời gian tương đương bước 4.

Như bạn đã thấy, bằng kĩ thuật này, ta tự do nhìn sâu vào những trải nghiệm vừa qua; càng vào vòng trong, ta càng tiệm cận các giải pháp, cải tiến. Đây là một kĩ thuật reflection dễ làm, dễ dùng và hiệu quả rất cao, đặc biệt trong các nhóm học tập (theo nghĩa rộng nhất có thể).

Viết ra như một phần của thú vui tư duy.

Để cho bớt dài thêm bài viết, các phần trích dẫn, liên kết tôi để dạng hyperlink,

bác nào muốn kiểm chứng, đọc thêm thì nhấn vào xem thêm chi tiết.

Trở về từ talkshow của ông Phạm Toàn ở L’Espace về bộ sách triết học cho trẻ con “Thú vui tư duy”, mở máy ra thì bị anh Facebook hỏi một câu rất xách mé “trong đầu mày nghĩ gì?”. Thế là trả lời, nguyên văn là thế này:

“Dạy học cốt ở cái đúng, không phải hấp dẫn” – T

Theo như tôi hiểu được trong ngữ cảnh của câu nói ấy ở L’Espace, ông Toàn đặc biệt nhấn mạnh đến việc phải tìm cái đúng để dạy, vì dạy cái sai mà hấp dẫn sẽ di hại khôn lường. Đây là nguyên lí hết sức căn bản trong giáo dục. Ông có lấy ví dụ trường hợp hỏa hoạn: nếu có lửa cháy cái thư viện đang ngồi (ở L’Espace) thì phải hô to, dứt khoát “đi đằng này, từng người một!” , chứ không phải nói theo kiểu lịch sự (theo ‘thông lệ’ của trung tâm Văn hóa Pháp), nicely “kính các anh chị, anh chị vui lòng xếp hàng một, đi lại nhẹ nhàng qua lối này vì có lửa đang cháy … “ 😀

Nhiều người trẻ và không còn trẻ trong hội thảo đã có những sự tán đồng nhất định đối với quan điểm này cùng ông Toàn vì chính họ là nạn nhân của những thời kì dạy toàn cái sai…
Có cụ nào đó dạy rằng “hãy nhìn vào hành động để đánh giá một ai đó”. Tôi thấy ông Toàn không bao giờ là người coi thường phương pháp, thậm chí “CÁCH” còn rất được đề cao (như là sự phân biệt giữa giáo dục truyền thống và hiện đại). Nhìn vào các hành động của ông Toàn thì thấy ông rất coi trọng tâm lí học, phương pháp, thao tác .. trong xây dựng sách giáo khoa và thực tiễn giảng dạy; những câu hỏi như “dạy sao cho dễ hiểu?”, “dạy và học sao cho hấp dẫn?” … luôn là những thứ được đặt làm nền tảng cho các bài học. Cứ lấy sách Cánh Buồm ra xem thì sẽ rõ.
Cùng một cái gốc chung với ông Toàn, ông Hồ Ngọc Đại có công thức tóm tắt công nghệ giáo dục ngắn gọn chỉ với hai từ: CÁI &CÁCH . Hai cái đó hữu cơ trong một, không thể tách rời. Câu nói của ông Toàn không đi ra khỏi quỹ đạo của hai chữ ấy.

Nhưng ông bàn thêm gốc là “CÁI”. Ví dụ, đất nước này thiếu nền tảng triết học phương Tây trầm trọng, vì CÁI duy nhất được biết tới là triết học (nếu có thể gọi đấy là triết học) Mạc văn Lê…
Thôi kể chuyện hội thảo đến đấy thôi, chuển sang cái “thú vui tư duy nho nhỏ” của tôi. Cũng liên quan đến CÁI và CÁCH.

1. DO THE RIGHT THING, AND DO IT RIGHT.

Đây là câu thuộc nằm lòng của nhiều nhà kinh doanh và quản lí. Phải tìm cái đúng mà làm, rồi làm nó một cách đúng đắn. Tức là nếu có cả CÁI và CÁCH thì bi-si-nít-xờ sẽ thành công rực rỡ.

Đây là bài học vỡ lòng trong nhiều sách dạy kinh doanh và quản lí. Nó liên quan đến hai chữ quan trọng mà không phải ai cũng phân biệt được, và khi dịch ra tiếng Việt thì nhiều khi cứ dịch như nhau: EFFICIENT và EFFECTIVE

Tra từ điển Webster thì nó là thế này:

Efficient:

1: being or involving the immediate agent in producing an effect <the efficient action of heat in changing water to steam>

2: productive of desired effects; especially : productive without waste <an efficient worker>

Effective:

1

a : producing a decided, decisive, or desired effect <an effective policy>

b : impressive, striking <a gold lamé fabric studded with effective…precious stones — Stanley Marcus>

2: ready for service or action <effective manpower>

3: actual <the need to increase effective demand for goods>

4: being in effect : operative <the tax becomes effective next year>

5 of a rate of interest : equal to the rate of simple interest that yields the same amount when the interest is paid once at the end of the interest period as a quoted rate of interest does when calculated at compound interest over the same period — compare nominal

Còn đây là hình vẽ trong sách nhập môn quản lý – “Essentials of Contemporary Management” của Gareth Jones và Jennifer George:

Effectiveness (người người gọi là Hiệu quả) chỉ cái đúng đắn trong sự lựa chọn cái để làm: vision, chiến lược, mục tiêu, sản phẩm v.v. thuộc loại này. Tìm cái gì để “Một vốn bốn lời” là có được Effectiveness.

Efficiency (có người dịch là Hiệu lực, năng suất, hầu hết hồn nhiên dịch ra là ‘hiệu quả’), chỉ khía cạnh phương pháp, cách thức đạt được kết quả. Chi ít tiền hơn để đạt được một mục tiêu thì là “hiệu quả” hơn.

Nhiều công ty đã đóng cửa, thua lỗ hay bị hoen ố hình ảnh vì đầu tư không đúng chỗ ngay cả khi họ sở hữu những bộ óc “có sạn” , một núi tiền khổng lồ sẵn sàng rót vào các chiến dịch truyền thông\quảng cáo, hay một núi know-how đã được tích lũy qua hàng chục năm chinh chiến trên thương trường ác liệt. Có thể họ chỉ có được Efficiency nhưng không có Effectiveness.

Mong đợi của của các nhà quản lí luôn luôn nằm ở góc trên bên tay phải của ma trận trên: vừa effective, vừa efficient. Gọi chung là ước vọng 2E.

Tuy vậy, thế “giới này quả là rộng lớn, và chúng ta có rất nhiều việc phải làm” với hai chữ EFFECTIVE và EFFICIENT này 🙂

2. Về sự phức hợp (Comlexity)
Thế giới ngày nay cực kì phức hợp. Sự phức hợp có trong hầu như ở những công việc đơn giản nhất hằng ngày. Ví dụ, “nên dạy trẻ con ứng xử thế nào với đèn đỏ khi đi trên đường Hà Nội?”, thử trả lời đi, bạn sẽ thấy nó cực kì rắc rối.

Ma trận Stacey là một công cụ tốt cho những nhà quản lí, những chiến lược gia nhìn nhận, phân tích, đánh giá tình hình và đưa ra các quyết định đúng đắn trong nhiều tình huống khác nhau. Nó trông như thế này:

Nguồn: Stacey RD. Strategic management and organisational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002.

Tạm tán phét về mấy vùng trong ma trận Stacey:

• Vùng SIMPLE: là vùng xanh da trời gần gốc tọa độ nhất. Trong những tình huống đơn giản (biết chắc nó là cái gì, dễ đồng ý với nhau về việc đó), các quyết định đơn giản là Rational (dựa hoàn toàn được vào lí tính, vào logic, và “phương pháp”). Cứ đi là đến, công thức rồi! Sẽ có cả 2E.
• Vùng COMPLICATED: là vùng có màu xám và màu đỏ. Ở đấy bắt đầu tiềm ẩn rủi ro, phải vận dụng nhiều “phương pháp” mới có được sự đúng đắn.
• Vùng COMPLEX: cái vùng to đùng ở trung tâm ma trận. Cái vùng mà sự hiểu biết của con người rất khác nhau về nó, và biết rất ít thông tin về nó. Ở đây sự phán xét (judgement) hay biện pháp chính trị (political) không phải là chìa khóa để có quyết định đúng đắn, giống như ở vùng COMPLICATED. Làm thế nào đây?
• Vùng CHAOS: Vùng này là vùng “nên quên đi cho nó lành!”, vì ta chẳng biết gì cả, hãy để cho “chúa” làm việc của người 😀

Thật đen đủi, có quá nhiều sự việc mà chúng ta đối diện hằng ngày không thuộc vùng SIMPLE, cũng chẳng thuộc vùng COMPLICATED. Làm sao bây giờ, huhu…

3. Lean Startup (Khởi sự Tinh gọn): Tìm cái đúng mà làm

Vài năm nay đồng chí Eric Ries trở nên nổi như cồn nhờ vào cái mô hình cho Tech Startup (trước hết là những công ty khởi sự từ IT, sau tới các ngành khác). Lean không có gì mới, nhưng kết hợp Lean, Agile và các ý tưởng về bi-di-nít-xờ cùng với ong-tờ-rơ-pờ-rơ-nơ-síp để ra được cái Lean Startup một cách tài tình như thế thì Eric Ries nổi như rứa cũng phải thôi.

Sách của ông này đây:

Ảnh : TheBln.com

Ồ, cái anh Lean Startup này có liên quan gì đến CÁI và CÁCH ?

Có đấy, hình dưới đây nói lên nhiều điều:

Theo Eric Ries, The Lean Startup – Google Tech Talk

Lean Startup là một cách tiếp cận để sống trong vùng Phức hợp, khi cả yếu tố giải pháp (kĩ thuật) và sản phẩm (yêu cầu) đều không rõ ràng. Để sống được, Tech Startups rất hay phải đi tìm các sản phẩm chưa từng có (để tạo lợi thế cạnh tranh cho người đi sau), để làm được việc đó, có khi lại phải dùng các công nghệ (hay innovation) chưa từng có (cái ai cũng có và làm được thì nhiều người làm rồi). Vậy nên toàn là UNKNOWN và UNCERTAINTY. Trong bối cảnh như vậy thì không thể làm việc theo kiểu “tớ biết hết rồi” được. Phải để khách hàng kiểm định giả thuyết, lean startups phải là các tổ chức học tập liên tục để “biết” được cái cần làm là gì dựa trên các dữ liệu thực tiễn (empirical). Cách tiếp cận truyền thống có thể đơn giản hóa theo kiểu “Khảo sát kĩ thị trường> lập kế hoạch > Thực thi > Kiểm soát” không hiệu quả vì nó dựa trên những điều giả định (prescriptive) tiềm ẩn rất nhiều sai sót. Lean Startup dùng từ khóa unknown để khai mở cách tiếp cận mới: vì không biết nên phải vừa đi vừa dò, từng bước nhỏ thôi (baby steps), đi đến đâu xác minh đến đó, rồi cải tiến và xác định bước tiếp theo. Kể cả Requirement lẫn Technology, phải liên tục tìm kiếm cái đúng đắn để làm thông qua các vòng phản hồi ngắn (short feedback life cycle). Nếu coi Requirement (hay Customer) là CÁI, và Technology (hay solution) là CÁCH (hay phương tiện), thì Lean Startup có được một đường lối để luôn luôn suy nghĩ và kiểm định hai thứ này. Đây là một cách tiếp cận đương đại, hiệu quả [và thời thượng nữa] về 2E.

4. Scrum – phải có CÁCH đúng, để có được CÁI đúng

Trong tài liệu mới nhất cùng viết với nhau của hai đồng tác giả của Scrum, “Software in 30 days”, Jeff Sutherland và Ken Schwaber có viết cả một Chương 2 để biện luận cho cái này: “RIGHT APPROACH, RIGHT RESULTS”, với đầy đủ các dữ liệu chặt chẽ từ thực tế phát triển phần mềm.

Như vậy, theo quan điểm của hai ông Schwaber và Sutherland, Scrum là một CÁI về phần CÁCH để có được các CÁI khác đúng đắn trong phát triển phần mềm. Gần giống với trường hợp của Lean Startup như đã nói ở trên. Software thuộc về thế giới Complex là chủ yếu, còn Scrum có thể phát huy trong khu vực nà. Cách xác định CÁI và CÁCH của  họ được minh họa bằng Stacey Graph dưới đây:

Nguồn: Ken Schwaber, Scrum for Vietnam 

5. Thế nào là ĐÚNG (RIGHT)? Đâu có đơn giản thế?

Cả cái mệnh đề “do the right thing, then do things right”, cho đến “right approach, right results” đều dùng một từ quá khó: ĐÚNG.

Nhận biết được cái gì đúng là cực khó. Đây cũng là phân vùng mà Triết học (không kể là Triết học ‘Người nhớn’ hay là Triết học ‘Trẻ con’) bận tâm như một trong các vấn đề cơ bản. Xin được rời xa bi-di-nít để được dẫn ra đây hai quan điểm “cổ điển” (“cổ điển” – classic không có nghĩa là cũ, và cũng không có nghĩa là không còn giá trị ở “hiện tại” nữa) về chuyện này:

Jeremy Bentham, John Stuart Mill và những hậu duệ theo quan điểm vị lợi (utilitarianism) cho việc đúng là việc mang lại nhiều lợi cho nhiều người nhất trong bối cảnh. Có nghĩa là không có cái đúng tự thân, đúng hay không là ở sự vận dụng cái TÙY.

Emmanuel Kant thì lại không cho là như thế: cái gì đúng không phụ thuộc vào việc nó làm gì với ai mà bởi vì nó đúng tự thân.

Hai cái trường phái này vẫn còn tồn tại, ảnh hưởng, và gây nhiều tranh cãi liên miên cho tới ngày nay. Chắc là sẽ không có ngày kết thúc. Đây cũng là những chủ đề nổi bật trong các bài giảng về triết học hoặc công lí của các trường đại học ngày nay (xem bài giảng của GS Micheal Sandel của trường Harvard tại đây).

Xem ra việc đánh giá cái gì là đúng, sai có phần không đơn giản như ta nghĩ.

Xin dừng đột ngột chuyện triết học ở đây để chuyển về chủ đề cuối cùng:

6. Triết học thì can hệ gì vào công việc (là nghĩa rộng của từ bi-di-nít-xờ: business = ‘sự bận’ = ‘có việc’)?

Quay trở lại cái hình của Stacey ở trên cùng. Trên trục hoành, càng xa dần cái gốc, sự không chắc chắn. Cái chuyện RIGHT hay WRONG trong thế giới phức hợp là rất không chắc chắn. Ở những khu vực như vậy, khả năng “judgement” (năng lực phán đoán) càng trở nên quan trọng. Thật đáng tiếc cho các nhà quản lí, các nhà kĩ thuật , khả năng này lại cần rất nhiều tri thức về khoa lịch sử, nhân văn và triết học … để bồi đắp, chứ không phải là các thứ về logic, hay công thức toán học (là những thứ được dạy nhiều trong trường kinh doanh hay công nghệ).

Với xuất phát điểm như vậy, Ikujiro Nonaka và Hirotaka Takeuchi chủ trương một thế hệ lãnh đạo mới của thế kỉ XXI (bối cảnh của thời đại tri thức, nơi ‘sinh sống’ của các tổ chức sáng tạo tri thức – knowledge-creating company, và quản lí dựa vào tri thức – knowledge-based management) phải là “Wise Leader” với kĩ năng lãnh đạo “Phronetic Leadership” có nội dung quan trọng về phronesis (practical wisdom – dịch thô thiển ra là “sự khôn ngoan thực tiễn”) – một phạm trù triết học có xuất xứ từ thời Aristotle.  Các cấu thành của Phronesis của nhà lãnh đạo kiểu mới này gồm:

1. khả năng phán đoán (judge) cái tốt
2. khả năng tham gia bối cảnh chung với người khác để tạo nên BA(không gian sáng tạo tri thức)
3. khả năng nắm bắt bản chất (essence) của tình huống & sự vật cụ thể
4. khả năng sử dụng ngôn ngữ, khái niệm & mô tả để đưa cái cụ thể vào tổng thể và ngược lại
5. khả năng sử dụng hữu hiệu quyền lực chính trị để biến khái niệm thành hiện thực vì lợi ích chung
6. khả năng khuyến khích phronesis của người khác để xây dựng tổ chức linh hoạt.

Để dễ hình dung, người lãnh đạo theo mô tả của Nonaka phải là một nhà-tư-tưởng-vận-động-viên, người có khả năng tư duy sâu sắc và năng lực hành động mạnh mẽ, như minh họa của hình dưới đây:

Nguồn: Nonaka.

Khuyến cáo của Nonaka có thể rất lạ đời:”nhà kinh doanh và lãnh đạo cần phải có hiểu biết sâu sắc về khoa xã hội, nhân văn và triết học”.

Đấy, cái liên quan giữa kinh doanh và triết học là như vậy đấy!

7. Kết

Thú vui tư duy của tôi sẽ còn nối dài vô tận cho tới khi nào xuống mồ. Còn bài này thì phải dừng lại cái đã, khối việc cơm gáo gạo tiền đang đắp đống chờ giải quyết.

Có một điều tôi vẫn băn khoăn về câu trích ở đầu bài “do the right thing, then do it right” có phải là câu của chúa không nữa? Vì tôi thấy nó ở trong giáo dục, trong kinh doanh, trong quản lí, trong Scrum như đã kể ở trên. Và còn chỗ nào nữa mà nó không đúng?

Ai mà biết được?

Nhưng thôi, xin cảm ơn những người đã nhảy vào đầu tôi để có được bài viết dài nhằng không giống phong cách viết bình thường trên blog này. Cũng xin trân trọng bác nào đã đầy bao dung dung và kiên nhẫn để đọc tới dòng này của một bài viết cực kì hổ lốn như cái tiêu đề của nó. Em lượn đây

tiếp   theo bài trước

#2:

Theo ROBERT N. CHARETTE, thế giới có thể đã tránh được HÀNG TỈ ĐÔ LA mỗi năm

Bảng dưới đây cho thấy sự tốn kém vì các lỗi thường gặp trong các dự án IT:

Ảnh: “The Hall of Shame” , IEEE Spectrum

Theo tác giả bài viết, các nguyên nhân phổ biến là:

• Mục tiêu không thực tế hoặc không rõ ràng
• Ước tính không chính xác về nguồn lực
• Các yêu cầu hệ thống không được định nghĩa tốt
• Yếu kém cỏi trong báo cáo trạng thái dự án
• Rủi ro không được quản lí
• Yếu kém trong giao tiếp giữa khách hàng, nhà phát triển và người dùng
• Sử dụng các công nghệ còn non nớt
• Không có khả năng xử lí được sự phức tạp của dự án
• Các cách thức thực hành phát triển không hệ thống
• Yếu kém trong quản lí dự án
• Các vấn đề chính trị giữa các bên liên quan (stakeholders)
• Sức ép thương mại

Hãy đọc khảo sát cực kì chi tiết này ở đây: http://spectrum.ieee.org/computing/software/why-software-fails

Liệu chúng ta có lại vấp phải những sai lầm tương tự?

Gartner khuyến cáo: từ bỏ waterfall, GO AGILE!

Trong một entry trước, tôi đã có dịp chia sẻ một số hình ảnh của 5S, Kanban ở một trung tâm dịch vụ của Ford Motor tại Hà Nội.

Vừa rồi đi Pleiku lại chộp được mấy hình ảnh về Kaizen/5S ở thủy điện IALY. Có thể thấy Lean vào nước ta từ khá sớm. Nhưng có vẻ như chỉ dừng lại ở việc áp dụng 5S và Kaizen. Không biết Kaizen có phát huy tác dụng không (ở FPT thì rõ là không thấy phát huy mấy), nhưng tác dụng của 5S thì thấy rõ, cứ gọi là “sạch bong kin kít”.

Xem hình ảnh dưới đây:

Kĩ thuật SpeedBoatlà một kĩ thuật rất hữu dụng và thú vị để nhận biết độ hài lòng của khách hàng về một dịch vụ mình cung cấp.

Trong AgileTour 2012 tại HCM, Joe Justice đã dùng kĩ thuật này để thực hiện Retrospective cho ngày hội thảo thứ nhất. Dựa trên các phản hồi từ người tham dự, ban tổ chức và Speaker cố gắng làm tốt hơn để mọi người hài lòng hơn ở ngày hội thảo thứ hai, hoặc lần tổ chức AgileTour sau.

Kĩ thuật này cũng có thể được dùng cho các nhóm Scrum trong buổi họp cải tiến Sprint (Sprint Retrospective).

Cách thực hiện rất đơn giản:

1. Vẽ một chiếc thuyền bơi trên mặt nước, với một chiếc mỏ neo phía sau, và một số tảng đá bên dưới lòng mặt nước phía trước (nhìn ảnh mẫu bên dưới).

2. Lục soát trong tất cả các yếu tố ảnh hưởng tới tiến độ đạt được mục tiêu Sprint, ghi ra giấy dán các thứ làm tốt, chưa tốt, cản trở, và dán vào các vùng tương ứng (xem hình bên dưới).

3. Cả nhóm đứng quanh bảng SpeedBoat, phân tích kĩ các điểm ghi trên giấy dán, tập trung vào các phần ở bên dưới mặt nước và phía sau thuyền để cải tiến. Chọn ra các điểm khả thi, lên danh sách các hành động để cải tiến, đưa vào kế hoạch cải tiến cho Sprint sau (có thể đưa luôn vào Sprint Backlog ở Sprint sau).

Steve Denning đã có một số phân tích chi tiết về việc ban lãnh đạo Saleforce.com (một trong những công ty sáng tạo và có bước phát triển tốt nhất hiện nay) đã giới thiệu Scrum vào tổ chức như là một trong các thay đổi đột phá và căn bản để đạt được bước nhảy vọt trong đổi mới và phát triển. Theo đó ông nhận ra rằng, Marc Benioff – cùng Saleforce.com đã tránh được sáu lỗi thường gặp mà các công ty hay mắc phải:

#1: Giới thiệu Scrum chỉ đơn giản là một quy trình nghiệp vụ đơn thuần.

Thay vì thế, họ coi sự thay đổi này là bước chuyển đổi căn bản (fundamental transformation) về cách làm việc trong tổ chức. Với cách tư duy mới, giao tiếp kiểu mới và hành động kiểu mới ở cả cấp độ quản lí lẫn nhân viên.

#2: Nhà quản lí là chủ cuộc chơi

Thay vì áp đặt từ trên xuống, sự thay đổi sang Scrum cần cam kết chặt chẽ từ dưới lên để thay đổi công việc. Nhà quản lí đóng vai trò hỗ trợ cho sự chuyển đổi rộng khắp của tổ chức với tất cả nguồn lực và khả họ có thể dành cho sự thay đổi.

#3: Cứng nhắc áp dụng một phương pháp luận đã bám rễ và thành công ở đâu đó

Thay vào đó, Saleforce.com được xây dựng dựa trên những gì họ học được từ các tổ chức khác, nhưng thích ứng với các điều kiện và ràng buộc của họ.

#4: Quản lí vi mô sự thay đổi

Thay vì các kiểm soát chi tiết, Saleforce.com mô hình hóa tư tưởng quản lí kiểu định hướng-thiết lập và trao quyền.

#5: Giữ bí mật các quết định quản lí then chốt

Thay vào đó, họ minh bạch hóa thông tin ở mức tối đa.

#6: Dè xẻn trong huấn luyện và đào tạo

Thay vì tiết kiệm từng xu cho đào tạo và huấn luyện, Saleforce.com tập trung một nguồn lực khổng lồ cho các khóa huấn luyện và đào tạo cần thiết. Từ việc gửi đi đào tạo, mua sách, tạo lập wiki nội bộ cho toàn bộ quá trình chuyển đổi.

Nguồn: http://www.forbes.com/sites/stevedenning/2011/04/18/six-common-mistakes-that-salesforce-com-didnt-make/

____________

Xem thêm thêm chi tiết về việc chuyển đổi của Saleforce.com, được trình bày tại hội thảo Scrum Gathering tại Chicago 2008:

Steve Dening, tác giả của Radical Management khái quát cốt lõi của Scrum dưới mười gạch đầu dòng sau đây:

1. Tổ chức công việc trong các chu kỳ ngắn,
2. Nhà  quản lý không làm gián đoạn các nhóm trong một chu kỳ làm việc;
3. Nhóm  báo cáo cho khách hàng, không báo cáo người quản lý;
4. Nhóm ước tính cần bao nhiêu thời gian để làm việc;
5. Nhóm  quyết định bao nhiêu việc sẽ làm trong mỗi phân đoạn;
6. Nhóm  quyết định làm việc như thế nào trong mỗi phân đoạn;
7. Nhóm tự đo lường hiệu suất của riêng mình:
8. Xác định mục tiêu công việc trước khi mỗi chu kỳ bắt đầu;
9. Xác định mục tiêu công việc qua những câu chuyện của người sử dụng (user stories) ;
10. Loại bỏ những trở ngại một cách hệ thống.

Tất cả các điều trên không có gì mới. Sự mới mẻ là ở chỗ chúng được kết hợp với nhau một cách chặt chẽ và tài tình để hoàn thành công việc.

Trong buổi nói chuyện PMPTalks #3 sáng chủ nhật vừa rồi với các bác ở VietPMP, có một nhận định rất thú vị về Scrum management . Bác ấy (thật đáng tiếc là quên mất tên của bác, hình như bác Thắng) nhận thấy, Scrum tiếp cận management ở mức High-level, để từ đó tạo ra cơ hội tự do lựa chọn các biện pháp, phương thức quản lí cụ thể; do vậy nó rất linh hoạt.

Bác ấy là người mới nghe Scrum, mà đã có nhận định vô cùng sắc sảo như vậy. Thật khâm phục!

Hầu hết mọi người đều mong chờ Scrum là một silver bullet, hay ít ra là môt phương pháp đầy đủ chỉ cho nhà quản lí biết phải làm gì để thành công; một cái lí thuyết tốt là lí thuyết dễ áp dụng, thậm chí áp dụng máy móc vẫn được. Scrum rõ ràng không phải loại này rồi.

Craig Larman, tác giả của nhiều đầu sách nổi tiếng về Agile có dùng một từ rất đắt về Scrum: nó là một “silent framework”. Nó im lặng trong việc thể hiện các “điều cần làm”, “cách nên làm” đối với hầu hết các đầu việc trong phát triển phần mềm: từ thu nhận và phân tích, tài liệu hóa các yêu cầu, cho đến thiết kế, cài đặt và kiểm thử cũng vậy. Người dùng Scrum có quyền tối đa để lựa chọn các cách thức phù hợp. Về các practice, Scrum hầu như không nói gì cả.

Nó High-level như vậy đấy.

Là người dịch Scrum Guide ra tiếng Việt qua ba phiên bản, tôi đã trực tiếp thấy việc các tác giả SCrum đã cố gắng gỡ bỏ các yếu tố “mô tả” như thế nào khỏi đặc tả Scrum. Những “công cụ” và “kĩ thuật” rất tốt như “burndown\up chart”, “release planning” v.v. là những thứ rất lợi hại trong thực tiễn thi hành Agile\Scrum; nhưng không phải vì thế mà nó có chân trong Scrum Guide. Họ đã dỡ bỏ chúng đi để Scrum framework ngày càng trở nên đơn giản, ngày càng “lặng lẽ” hơn.

Cũng chính vì sự lặng lẽ vậy mà Scrum trở nên linh hoạt và thành công, bởi lẽ nhờ đó, người dùng có cơ hội thử, rồi kiểm nghiệm cách thức phù hợp nhất với họ. Có nhóm sẽ thấy User Story rất hữu ích, nhưng có công ty  thấy use case mới phù hợp v.v. Đây là tinh thần thực nghiệm (empirical) vốn là nền tảng cơ bản của Scrum. Phải dựa trên điều kiện thực tiễn ta mới biết được nên làm như thế nào tiếp theo. Scrum không mô tả trước (prescriptive) điều gì, mà để rộng cửa cho người dùng bồi da đắp thịt vào một cái khung sườn tuy đơn giản mà vững chắc. Cùng với ba chân (Minh bạch, Thanh tra, Thích nghi) hỗ trợ đắc lực cho tiến trình quản lí thực nghiệm (empirical process control), cái khung Scrum như là một nền móng kiến trúc vững chắc cho các ngôi nhà quản lí hiệu quả trong thực tiễn.

Có thể chính sự im lặng đó là chất “vàng” đáng giá nhất của Scrum.

#1.

Ảnh: IEEE

Đây là một vụ rất ồn ào, tốn giấy mực của báo chí: Dự án Sentinel của FBI

• Mục đích: số hóa các dữ liệu điều tra của FBI, dùng cho 30.000 nhân viên FBI
• Ước tính ban đầu: 451M, hoàn thành và cài đặt vào 2009.
• Đơn vị phát triển: Lockheed Martin.
• Mô hình: waterfall-based.
• Khởi công: 2006

Đến tháng 8-2010, đã chi 405M/451M nhưng mới chỉ đạt được 50% tiến độ; chưa dùng được gì.

Do tốn kém và trì trệ, FBI kết thúc hợp đồng với Lockheed Martin, thay CIO, để lại 50% công việc dang dở.

Công ty kiểm toán độc lập Mitre ước tính FBI cần thêm 35M nữa, cùng với 6 năm nữa để hoàn thành dự án.

Thời điểm đó CTO mới quyết định chuyển dự án sang Scrum, và họ hoàn tất khối lượng công việc với chỉ 30M trong vòng 1 năm, tiết kiệm 90% chi phí.

Nguồn: Ken Schwaber và Jeff Sutherland, “Software in 30 days”.

***

Biên tập viên John Foley của Information Week có bình luận về vụ này (tại đây), và rút ra năm bài học:

1. Chuyên gia ở khu vực tư nhân rất đáng giá

2. Agile rất được việc

3. Các phần mềm thương mại đóng vai trò quan trọng

4. Agile rất tiết kiệm

5. Đừng cài đặt phần mềm mới lên phần cứng đã lạc hậu

tiếp #2

Là tác giả của  tài liệu Scrum trong Nhà thờ, tôi [Arline Sutherland] đã được mời tới nói chuyện về cách sử dụng Scrum trong các khu vực ngoài IT. Thật khó để tìm thấy một khu vực nào khác biệt phát triển phần mềm hơn là một nhà thờ!

Trong hai năm qua, tôi đã làm việc tại Scrum Inc., nơi chúng tôi không phát triển phần mềm và sử dụng Scrum để làm mọi việc. Nó thực sự không giống như một nhà thờ chút nào. Vì vậy, tôi đã thực sự ngạc nhiên, như khi tôi đã đọc lại Scrum trong Nhà thờ, để nhận ra rằng các giáo đoàn tôi phục vụ và Scrum Inc. có nhiều thử thách tương tự.

Một vấn đề tôi gặp phải trong mỗi giáo đoàn tôi phục vụ là: bởi vì các nhân viên làm việc bán thời gian và những người làm việc có lịch trình rất khác nhau, không thể có cuộc họp hàng ngày có mặt tất cả mọi người. Nhân viên làm việc ngày Chủ nhật, sẽ nghỉ vài ngày trong tuần. Những người khác làm việc từ 9:00-5:00, thứ Hai đến Thứ Sáu. Người làm việc Bán thời gian có nghĩa là không ở đó toàn bộ thời gian để làm việc.

Trong nhà thờ, chúng tôi quyết định tổ chức họp đứng hàng ngày (daily standup) mỗi sáng bất kể là có mặt những ai. Vì vậy, mỗi buổi sáng, từ Thứ Hai đến Thứ Sáu, tất cả các nhân viên trong tòa nhà tập hợp lại. Sau một thời gian, một số nhân viên toàn thời gian có ngày nghỉ trong tuần bắt đầu xuất hiện ở các buổi họp vào ngày nghỉ của họ.

Tại Scrum Inc., chúng tôi cũng vật lộn với việc làm sao để có đủ mọi người tại buổi họp đứng hàng ngày. Chúng tôi có hai nhân viên bán thời gian. Jeff di chuyển triền miên, chủ yếu là ở châu Âu. Một trong chúng tôi sống và làm việc ở Washingotn D.C., phần còn lại thì ở Boston.

Nhờ có Google Hangout và Skype, việc họp đối với nhiều người phân tán về lịch biểu hoặc địa lí trở nên dễ dàng hơn. Tuy nhiên, khi một hoặc nhiều người trong chúng tôi triển khai một khóa học hoặc tư vấn, chúng tôi không thể có được một cuộc họp hàng ngày, thậm chí chỉ 15 phút.

Scrum hoạt động tốt nhất khi Team ngồi chung địa điểm và tất cả mọi người làm việc cùng một lịch trình. Nhưng thế giới thực hiếm khi làm việc như thế. Không có quy định về việc làm thế nào để thích ứng với những hoàn cảnh như vậy, nhưng dưới đây là một số kỹ thuật chúng tôi thấy rất hữu ích:

1. Nếu một thành viên trong nhóm không thể họp hàng ngày, yêu cầu họ gửi email báo cáo đến Scrum Master để nó có thể được cập nhật, và sau đó gửi email về những điểm chính từ buổi họp hằng ngày cho cả nhóm. (Chỉ cần các điểm chính, không cần một “biên bản họp” dài dòng làm gì).

2. Lên lịch các cuộc họp mặt-đối-mặt định kì. Không có gì thay thế được việc ở trong cùng một không gian cùng một lúc, cho các cuộc đàm thoại với dòng nước mát lanh, để nghe những gì người ta đã làm cuối tuần qua, để chia sẻ một bữa ăn, và ghi nhận những sự kiện quan trọng như sinh nhật và dịp kỉ niệm ở công ty. Bố trí một ngân sách du lịch để mọi người sống và làm việc ở xa có thể xích lại với nhau một cách thường xuyên.

3. Sử dụng một bảng Scrum ảo. Trong khi chúng ta biết rằng các ghi chú dán trên tường là tốt nhất, ta vẫn có thể nghĩ tới công cụ linh hoạt tốt gần bằng thế để phục vụ công việc. Mỗi thành viên của nhóm có thể thể truy cập vào tất cả các ngày, mỗi ngày. (Chúng tôi thích Tracker Pivotal).

4. Hãy để ý đến sự mù thông tin. Khi gặp vấn đề gì, gửi email đến tất cả mọi người trong nhóm. Hãy chắc chắn rằng tất cả các công việc được ghi nhận trong backlog để mọi người biết những gì đang xảy ra. Nếu một tài liệu là kết quả của một story, hãy đính kèm nó vì vậy tất cả có thể đọc được. Nếu có một cuộc họp, hãy viết các bản tóm tắt ngắn gọn.

Trong bản chất, Scrum đặt con người lên ưu tiên số một, tạo ra một đội nhóm, về sự hoàn hảo, và niềm vui khi làm việc! Con người chúng ta có thể là một thứ khó tính dễ bị kích thích; chúng ta cũng có thể là một người vui vẻ hào phóng làm việc để làm cho cuộc sống của chúng ta và thế giới này một nơi tốt hơn.

Theo Arline Sutherland, ScrumInc.com