
Dự án phần mềm bị trì hoãn và vấn đề "akrasia"
Last updated: August 26, 2025 Xem trên toàn màn hình



- 10 Sep 2023
Định luật Murphy giải thích tại sao chúng ta luôn gặp xui xẻo vào những lúc tưởng thuận lợi 667
- 04 Jan 2023
Phát triển phần mềm linh hoạt theo mô hình Big Bang 590
- 15 Apr 2023
Nghịch lý từ câu chuyện “một chén gạo dưỡng ơn, một đấu gạo gây thù” 541
- 18 May 2021
Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 523
- 09 Aug 2019
Nghịch lý Icarus - Nghịch lý nói hay làm dở (Good idea, bad execution) 467
- 01 Mar 2021
Ý nghĩa và bài học rút ra từ truyện thầy bói xem voi 434
- 03 Mar 2020
Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 424
- 18 Jul 2020
Lợi ích cận biên (Marginal Utility) là gì? Qui luật lợi ích cận biên giảm dần 419
- 09 Aug 2022
Hiệu ứng “rắn hổ mang” (Cobra effect): Khi giải pháp trở thành vấn đề, tưởng vui lại hóa xui 415
- 12 Apr 2023
Phương pháp 6 chiếc mũ tư duy là gì? Vận dụng trong điều hành cuộc họp hiệu quả 411
- 03 May 2022
Mô hình Hybrid Agile là gì? 409
- 18 Mar 2021
Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 384
- 01 Apr 2023
Bí quyết đàm phán tạo ra giá trị từ câu chuyện Chia Cam 372
- 07 Aug 2019
Câu chuyện thanh gỗ ngắn và bài học kinh doanh cho Doanh nghiệp 343
- 02 Aug 2023
Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 328
- 22 May 2022
Tư duy ngoài hộp (Thinking out of box) là gì? Tại sao quan trọng với sự phát triển của doanh nghiệp? 319
- 20 Jul 2021
Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 311
- 02 Aug 2021
Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 306
- 11 Sep 2024
Mindset, skillset, toolset là gì? 304
- 01 Aug 2023
Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 296
- 14 Apr 2019
Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 270
- 28 Jun 2024
Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 258
- 23 Jun 2024
Người trí tuệ không tranh cãi ĐÚNG/SAI 199
- 08 Jan 2022
Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 191
- 02 Oct 2023
Ngôi Chùa Trăm Năm và Viên Gạch Vỡ: Bài Học Thấm Thía Về Lỗi Nhỏ Trong Bức Tranh Lớn 187
- 01 Sep 2023
Định luật Goodhart và định luật Campbell - Nghịch lý về thành tích 181
- 03 Sep 2020
Hiệu ứng rắn hổ mang, Luật Goodhart, Campbell & Chuyện thi cử 180
- 11 Sep 2022
Từ truyện “Thầy bói xem voi” tới quản trị bằng Tư Duy Hệ Thống 179
- 10 May 2021
Phát triển Phần mềm Tinh gọn (Lean Software Development) 176
- 02 May 2024
"Viên đạn bọc đường" là gì? Làm sao để nhận diện "viên đạn bọc đường"? 174
- 10 Sep 2024
Tại sao những thứ chúng ta muốn lại ít khi có được? 171
- 08 Feb 2021
Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 162
- 24 Mar 2019
Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 154
- 14 Dec 2022
Phương pháp kiểm tra Fagan Inspection là gì? 152
- 09 Jan 2025
10 Nghịch Lý Cuộc Sống Từ Phim Upstream (nghịch hành nhân sinh): Đối Mặt Rủi Ro Trong Thời Đại VUCA 152
- 15 Mar 2024
Tê liệt vì suy nghĩ quá nhiều (Analysis Paralysis) là gì? 148
- 21 Apr 2020
Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 140
- 16 Feb 2024
Nghịch lý của sự hoàn hảo: AI có thể quá tốt để sử dụng? 135
- 11 Sep 2020
Nghịch lý kinh doanh tại Mỹ: Chăm sóc khách hàng không tốt, nhưng công ty lại lãi lớn 128
- 05 Dec 2022
Hỏi 5 lần (5 WHYs) – Kỹ thuật "đào" tận gốc cốt lõi vấn đề 126
- 01 Nov 2023
Lòng Tham Vi Tế: Khi Chúng Ta Chạy Theo Miễn Phí Mà Không Biết Đang Đánh Đổi Điều Gì 94
- 09 Dec 2024
10 nghịch lý quản trị khiến tổ chức mãi loay hoay 91
- 10 Aug 2020
Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 90
- 22 Jul 2020
Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 86
- 18 Jan 2025
Echoist là kiểu người gì? Echoist khác với người hướng nội và người ái kỷ như thế nào? 74
- 08 May 2024
Ghosting và Thao Túng Tâm Lý: Những Điều Gen Z Cần Biết để Bảo Vệ Bản Thân 70
- 28 Feb 2025
“Học giỏi” hay “giỏi học”? 70
- 16 May 2024
Nghịch lý Allais: Khi con người không “lý trí” như kinh tế học tưởng 61
- 19 Jul 2023
3 cấp độ của thất bại và bí quyết "cái khó ló cái khôn" 58
- 11 Mar 2025
Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 49
- 01 May 2025
Vì Sao Các Cửa Hàng Trung Quốc Không Vội Vã Phục Vụ Khách Hàng? 46
- 02 May 2025
Vì sao học giỏi mà vẫn nghèo, học dốt lại thành đạt trong cuộc sống? 41
- 02 Apr 2025
Anti-Hiring Là Gì? Tại sao các doanh nhân tinh gọn lại nói “KHÔNG” với tuyển dụng? 34
- 03 Jul 2025
20 "NGHỊCH LÝ" NHƯNG "THUẬN LÝ" TRONG CUỘC SỐNG 30
- 16 Apr 2025
Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 25
- 06 Dec 2025
Sức mạnh của phương pháp 30-for-30: Bạn đã bao giờ cam kết 30 ngày liên tục cho một mục tiêu? 24
- 01 Apr 2025
CTO ra quyết định như thế nào? 21
- 13 Aug 2025
Hội chứng "imposter syndrome" là gì? 8
- 16 Aug 2025
Hoài nghi khoa học với 20 thuật ngữ bi quan về hiệu quả của Scrum 7
Tại sao chúng ta lại ăn thêm một miếng bánh? Tại sao chúng ta bỏ qua buổi tập ở phòng gym? Tại sao chúng ta xem thêm một tập chương trình TV trong khi biết rằng mình nên học tập?
Trong triết học, đó là vấn đề của akrasia – hay còn gọi là sự yếu đuối của ý chí. Nói đơn giản, câu hỏi là: nếu chúng ta biết rằng mình nên làm một việc nào đó (hoặc không nên làm), và chúng ta cũng muốn làm việc đó (hoặc muốn tránh việc đó), thì làm sao lại có thể trì hoãn (hoặc chọn làm điều ngược lại)? Tại sao chúng ta lại làm những điều có hại cho bản thân, ngay cả khi biết rõ nó có hại?
Thoạt nhìn, đây có vẻ là loại câu hỏi chỉ triết gia mới bận tâm. Chẳng phải câu trả lời quá rõ ràng sao? Chúng ta ăn thêm bánh vì thích, và trong khoảnh khắc đó, niềm vui quan trọng hơn sức khỏe lâu dài. Chúng ta bỏ buổi tập gym vì nó giống như lao động nặng nhọc, nhất là khi so với việc nằm thêm trên giường hay uống thêm một tách cà phê. Và chúng ta xem TV thay vì học vì bị cuốn vào chương trình — và luôn có thể hẹn sang ngày mai.
Nhưng, giống như nhiều câu hỏi triết học khác, vấn đề akrasia càng trở nên đáng quan tâm khi ta suy nghĩ nhiều hơn. Ai thực sự kiểm soát ở đây? Điều gì xảy ra khi chúng ta nghe theo bản năng tốt đẹp và làm điều có lợi cho mình? Chúng ta đã khiến điều đó xảy ra bằng cách nào? Và làm sao để khiến nó xảy ra thường xuyên hơn?
Tôi không dám khẳng định mình biết câu trả lời chung cho vấn đề akrasia, nhưng tôi tin rằng ta thường thấy nó trong thế giới công nghệ doanh nghiệp (enterprise technology) – và trong bối cảnh cụ thể đó, có lẽ ta tìm ra vài lời giải.
Một trong những điều gây thất vọng nhất của công nghệ doanh nghiệp là chúng ta đã biết cách tốt để tổ chức công việc xây dựng và vận hành hệ thống máy tính từ nhiều năm nay. Những cách này có nhiều nhãn khác nhau, như Agile, DevOps và Product Management. Đôi khi chúng ta phát minh thêm nhãn mới (như Platform Engineering hoặc Site Reliability Engineering), và đôi khi các khái niệm mới này gây rối. Nhưng theo tôi, tất cả có thể rút gọn thành một số chân lý cơ bản: phần mềm đạt hiệu quả tốt nhất khi được phát triển bởi các nhóm nhỏ, ổn định, gồm những chuyên gia có quyền chủ động, có thời gian và không gian để quan tâm đến chất lượng sản phẩm cũng như hiệu suất khi đưa vào vận hành, biết quản lý công việc một cách linh hoạt, và tự áp dụng các công cụ – phần mềm và dữ liệu – vào chính quy trình nghề nghiệp của mình. (Chúng ta có thể tranh luận nhiều năm về việc mô tả này có chính xác không, nhưng tôi hy vọng nó nêu bật được cốt lõi của vấn đề.)
Và thế nhưng, dù đã biết những chân lý này, hầu hết việc phát triển và quản lý phần mềm lại không được tổ chức như vậy. Các tập đoàn lớn vẫn triển khai những chương trình khổng lồ, đơn khối (monolithic programmes), dựa trên niềm tin rằng có thể xây dựng kế hoạch chi tiết cho phát triển phần mềm trong nhiều tháng hoặc nhiều năm. Những chương trình này vẫn được coi là các dự án hoàn chỉnh, tạo ra sản phẩm cuối cùng chỉ cần bảo trì tối thiểu sau khi chạy thật. Tổ chức vẫn tiến hành những đợt thu thập yêu cầu kéo dài, với niềm tin rằng có thể đặc tả hành vi của hệ thống phần mềm trước khi viết một dòng code nào. Các lập trình viên không được tin tưởng và đối xử như tài sản quý, mà chỉ như cỗ máy gõ code, có nhiệm vụ “chuyển yêu cầu thành phần mềm”. Chúng ta vẫn làm tất cả những điều này, dù biết rằng chúng có hại cho mọi người liên quan.
May mắn thay, việc chẩn đoán dạng akrasia số hóa (digital akrasia) này khá đơn giản, dù việc khắc phục thì khó khăn hơn nhiều. Trong đa số trường hợp, vấn đề này bắt nguồn từ sự kết hợp giữa thiếu hiểu biết (ignorance) và trực giác (intuition). Thiếu hiểu biết, vì dù chúng ta đã xây dựng hệ thống phần mềm hàng thập kỷ, hầu hết những người tài trợ cho việc phát triển chưa bao giờ có kinh nghiệm trực tiếp lập trình. Trực giác, vì họ lại có kinh nghiệm trực tiếp với những thứ được xây dựng khác – như đường xá, cầu cống, tòa nhà (dù chỉ ở vai trò người lái xe, người dùng hay cư dân). Khi được hỏi nên tổ chức công việc thế nào để xây dựng một thứ phức tạp và tốn kém, không phải quá phi lý khi họ nghĩ nên tổ chức giống một dự án xây dựng.
Trong vài tuần qua tôi đã viết về những vấn đề kỹ thuật thú vị, phần lớn vì tôi đang tuyển dụng Chief Engineer đầu tiên của Chính phủ Anh (chỉ còn vài ngày nữa! Hãy ứng tuyển!). Nhiều vấn đề mang tính kỹ thuật, nhưng một số thú vị nhất lại mang tính hành vi. Một trong những điều mà vị Chief Engineer cần làm – cũng như tất cả lãnh đạo công nghệ – là giáo dục và vận động cho những cách làm đã được chứng minh hiệu quả, đồng thời giải thích vì sao việc xây dựng phần mềm không giống việc xây cầu.
Điều này không dễ. Nó cần sự kiên nhẫn, khả năng truyền đạt, và đầu tư thời gian để xây dựng niềm tin. Nó cũng cần dũng khí, sẵn sàng thách thức, và sự kiên định để duy trì niềm tin khi mọi thứ đi sai hướng. Sẽ có những ngày rất khó khăn. Nhưng nếu chúng ta không làm, thì chính chúng ta cũng rơi vào một dạng akrasia riêng.