Akrasia trong phát triển phần mềm: xung đột giữa cám dỗ ngắn hạn và kỷ luật dài hạn trong Agile và DevOps.

Dự án phần mềm bị trì hoãn và vấn đề "akrasia"

Published on: August 15, 2025
Last updated: August 26, 2025 Xem trên toàn màn hình

Recommended for you

20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 9/359
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ù” 9/688
09 Aug 2019 Nghịch lý Icarus - Nghịch lý nói hay làm dở (Good idea, bad execution) 7/591
11 Sep 2022 Từ truyện “Thầy bói xem voi” tới quản trị bằng Tư Duy Hệ Thống 6/219
11 Sep 2024 Mindset, skillset, toolset là gì? 6/415
04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 6/676
01 Mar 2021 Ý nghĩa và bài học rút ra từ truyện thầy bói xem voi 6/534
19 Sep 2025 Agile vs. Ego: Làm Gì Khi Một Thành Viên Trong Nhóm Nổi Loạn 5/37
05 Dec 2022 Hỏi 5 lần (5 WHYs) – Kỹ thuật "đào" tận gốc cốt lõi vấn đề 5/158
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)? 5/387
14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 5/407
07 Aug 2019 Câu chuyện thanh gỗ ngắn và bài học kinh doanh cho Doanh nghiệp 5/392
23 Jun 2024 Người trí tuệ không tranh cãi ĐÚNG/SAI 5/387
10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 5/214
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 5/491
01 Apr 2023 Bí quyết đàm phán tạo ra giá trị từ câu chuyện Chia Cam 4/506
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 4/635
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 4/174
03 Jul 2025 20 "NGHỊCH LÝ" NHƯNG "THUẬN LÝ" TRONG CUỘC SỐNG 4/44
19 Jul 2023 3 cấp độ của thất bại và bí quyết "cái khó ló cái khôn" 4/79
01 Apr 2025 CTO ra quyết định như thế nào? 3/30
15 Mar 2024 Tê liệt vì suy nghĩ quá nhiều (Analysis Paralysis) là gì? 3/218
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? 3/38
28 Feb 2025 “Học giỏi” hay “giỏi học”? 3/125
16 May 2024 Nghịch lý Allais: Khi con người không “lý trí” như kinh tế học tưởng 3/95
08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 3/234
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? 3/418
03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 3/489
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 3/402
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ả 3/499
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 3/748
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 2/240
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ì 2/106
02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 2/319
14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 2/161
03 May 2022 Mô hình Hybrid Agile là gì? 2/455
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 2/473
08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 2/186
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? 2/56
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? 2/44
09 Dec 2024 10 nghịch lý quản trị khiến tổ chức mãi loay hoay 2/110
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? 2/57
13 Aug 2025 Hội chứng "imposter syndrome" là gì? 2/60
12 Aug 2025 Hội chứng Imposter Syndrome: Vì sao Quản Lý Dự Án giỏi lại luôn nghĩ mình không đủ giỏi? 2/60
05 Sep 2025 “Lời Khuyên”: Thuận lý thì ít, nghịch lý thì nhiều. Suy nghĩ không giống nhau thì không nên khuyên nhau. 2/27
08 Sep 2025 Tâm Lý Phản Kháng (Reactance): Vì Sao Càng Cấm, Người Ta Càng Muốn Làm? 2/42
11 Sep 2025 Lightning Decision Jam: Quy trình Siêu tốc để Giải quyết Mọi Vấn đề 2/3
16 Aug 2025 Hoài nghi khoa học với 20 thuật ngữ bi quan về hiệu quả của Scrum 1/26
16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 1/34
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? 1/82
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? 1/79
24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 1/278
02 May 2024 "Viên đạn bọc đường" là gì? Làm sao để nhận diện "viên đạn bọc đường"? 1/319
03 Sep 2020 Hiệu ứng rắn hổ mang, Luật Goodhart, Campbell & Chuyện thi cử 1/193
10 Sep 2024 Tại sao những thứ chúng ta muốn lại ít khi có được? 1/196
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)? 1/301
16 Feb 2024 Nghịch lý của sự hoàn hảo: AI có thể quá tốt để sử dụng? /164
01 Sep 2023 Định luật Goodhart và định luật Campbell - Nghịch lý về thành tích /192
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 /139
21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì /246
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 /604
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 /94
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 /76
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 /103

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.

Xem bài gốc tại đây

A A A A

[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"showAds\":true,\"showQuickNoticeBar\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"2\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"David Knott \",\"sourceValue\":\"https://www.linkedin.com/pulse/software-development-problem-akrasia-david-knott-tnrqe/\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":true,\"isAutoNumbering\":false,\"isShowKeyHeadingWithIcon\":false}]"},{"bannerInfo":"[{\"isBannerBrightnessAdjust\":false,\"bannerBrightnessLevel\":\"\",\"isRandomBannerDisplay\":true}]"},{"termSettingInfo":"[{\"showTermsOnPage\":true,\"displaySequentialTermNumber\":true}]"}]

Nguồn

{content}