Thực thi hiện đại hóa kiến trúc: Khi nào ước tính trở thành hạn chót?
(domainanalysis.io)- Hiện đại hóa phần mềm legacy khó xác định toàn bộ phạm vi chỉ dựa trên thông tin nhìn thấy trước khi bắt tay làm, nên cần xem ước tính ban đầu là mốc tham chiếu có thể điều chỉnh, không phải hạn chót
- Giống như sửa ô tô, ban đầu có thể đưa ra báo giá kiểu $18,000·30 ngày, nhưng sau khi tháo dỡ và kiểm tra, nếu phát hiện hư hại ẩn thì cần báo giá bổ sung và phê duyệt lại
- Các dự án hiện đại hóa cũng sẽ xuất hiện độ phức tạp ẩn, chẳng hạn tích hợp thất bại hoặc hành vi không lường trước; khi đó, cố ép theo ước tính ban đầu sẽ va chạm với thực tế
- Lãnh đạo lành mạnh không hỏi “sao không thấy trước”, mà hỏi về độ phức tạp, giải pháp, trade-off, phương án vòng tránh, rồi quyết định tiếp tục hay dừng
- Trong bối cảnh phức tạp, cần lặp lại việc thử, thử nghiệm và khám phá hơn là bám vào một cuốn quy tắc cố định; lãnh đạo nên tạo môi trường để các mẫu hình lộ diện thay vì kiểm soát quá mức
Ước tính là mốc định hướng tiến độ, không phải hạn chót
- Trong hiện đại hóa phần mềm phức tạp, nếu xem ước tính như hạn chót đã chốt, nó sẽ xung đột với thực tế lộ ra trong quá trình làm việc
- Ước tính ban đầu được lập dựa trên thông tin nhìn thấy từ bên ngoài và kinh nghiệm, nhưng sau khi công việc bắt đầu, những độ phức tạp mới có thể xuất hiện
- “Ước tính” là giá trị gần đúng của con số thực tế; trong hiện đại hóa phức tạp, rất khó dự đoán hoàn hảo mọi kết quả trước khi bắt đầu
Ví dụ sửa ô tô: hư hại không nhìn thấy và báo giá bổ sung
- Trong sửa ô tô, giám định viên bảo hiểm trước tiên gửi ước tính thiệt hại cho xưởng sửa chữa, và xưởng sửa chữa cũng gửi báo giá riêng cho công ty bảo hiểm
- Ví dụ, giám định viên bảo hiểm ước tính thiệt hại $15,000
- Xưởng sửa chữa ước tính thiệt hại $18,000 và thời gian sửa 30 ngày
- Giám định viên bảo hiểm và chuyên gia của xưởng cùng đánh giá thiệt hại; khi công ty bảo hiểm phê duyệt báo giá mới thì việc sửa chữa bắt đầu
- Trong quá trình sửa, có thể phát hiện những hư hại ban đầu không nhìn thấy
- Khi tháo các bộ phận, có thể lộ ra hư hại bổ sung
- Có thể kiểm tra hư hại ở unibody frame bằng máy kéo nắn khung
- Cần kiểm tra không chỉ điểm va chạm mà cả việc tác động có truyền ra phía sau khung hay không
- Nếu hư hại bổ sung cần thêm $20,000, xưởng sửa chữa sẽ gửi yêu cầu sửa chữa bổ sung cho công ty bảo hiểm, và công ty bảo hiểm quyết định tiếp tục sửa hay xử lý như tổn thất toàn bộ (total loss)
- Cách công ty bảo hiểm từ chối khoản bổ sung $20,000 chỉ vì báo giá ban đầu là $18,000 không phù hợp với quy trình sửa chữa thực tế
Trong hiện đại hóa legacy, độ phức tạp ẩn cũng lộ ra
- Hiện đại hóa phần mềm legacy thuộc lĩnh vực phần mềm phức tạp
- Có thể lập ước tính ban đầu dựa trên những vấn đề trông có vẻ rõ ràng từ bên ngoài, nhưng trong quá trình làm việc thực tế, nhiều độ phức tạp hơn sẽ xuất hiện
- Giống như việc phát hiện hư hại ẩn hoặc hư hại khung xe trong sửa ô tô, hiện đại hóa cũng có thể phát sinh vấn đề không có trong ước tính ban đầu
- Trong tình huống như vậy, thay vì bị trói vào ước tính ban đầu, cần xác định bước tiếp theo thông qua phê duyệt bổ sung và đánh giá lại
Những câu hỏi mà lãnh đạo tốt đặt ra
- Trong môi trường phát triển phần mềm lành mạnh, khi vấn đề lộ ra, người ta đặt những câu hỏi cần thiết cho phán đoán thay vì đổ lỗi
- Vấn đề này phức tạp đến mức nào?
- Có những cách giải quyết nào?
- Trade-off của từng cách là gì?
- Có phương án vòng tránh hoặc giải pháp thay thế nào không?
- Ngược lại, nếu câu chuyện trôi về “tại sao không thấy trước độ phức tạp này”, “tại sao mất lâu như vậy”, “tại sao không giữ được ngày ước tính ban đầu”, thì đội ngũ sẽ bị trói vào ngày ước tính ban đầu
- Với dự án hiện đại hóa, có cả trường hợp tiếp tục lẫn trường hợp dừng
- Nếu chi phí bổ sung được phê duyệt, dự án chuyển sang bước tiếp theo và lặp lại quá trình này để tiến gần hơn tới hoàn tất
- Nếu chi phí lớn hơn giá trị mang lại, dự án có thể bị dừng
- Quyết định phân định giữa tiếp tục và dừng không hề dễ, và có thể dùng framework cùng workshop ra quyết định để xác định hướng đi
Khác biệt giữa bối cảnh rắc rối và bối cảnh phức tạp
- Trong Cynefin framework của A Leader’s Framework for Decision Making, sửa ô tô hoặc bảo dưỡng xe máy có thể gần với bối cảnh rắc rối (complicated context)
- Trong sửa ô tô, chuyên gia nghe về tình huống tai nạn, rồi phân tích và kiểm thử nhiều yếu tố như hư hại không nhìn thấy hay hư hại khung xe để quyết định hành động tốt nhất
- Trong bối cảnh phức tạp (complex context), chỉ sau khi thử mới có thể phán đoán đúng sai
- Một tích hợp tưởng sẽ hoạt động có thể thất bại
- Có thể phát hiện một hành vi mới chưa biết và phải phản ánh điều đó vào giải pháp
- Hiện đại hóa hệ thống legacy phức tạp không có lộ trình cố định hay cuốn quy tắc phải tuân theo
- Hiện đại hóa là quá trình lặp lại việc thử, thử nghiệm, khám phá, giải quyết rồi chuyển sang mảnh tiếp theo
Những cú bóng xoáy không phải ngoại lệ mà là thực tế
- Nếu hiện đại hóa ứng dụng nằm giữa complex và complicated, cần có bảng điều khiển phù hợp để đánh giá tiến độ và thành công
- Áp dụng một quy trình ước tính đơn giản cho bối cảnh phức tạp giống như cố dùng búa để xử lý mọi con vít và đai ốc bánh xe
- Những cú bóng xoáy bất ngờ trong dự án hiện đại hóa là thực tế
- Không thể dự đoán trước mọi kết quả
- Dù phân tích trước nhiều đến đâu, bạn cũng không đạt được mô hình dữ liệu hoàn hảo
- Gần như ở mỗi bước đều phát sinh học hỏi mới
- Mô hình dữ liệu phải thay đổi theo độ phức tạp được phát hiện
- Khi ước tính thay đổi, thay vì tức giận, quy trách nhiệm hoặc bám vào phân tích để ép khớp lịch trình, cần tìm cách tiến về phía trước
Cách văn hóa tổ chức xử lý những cú bóng xoáy
- Mô hình văn hóa tổ chức của Ron Westrum phân biệt cách tổ chức đối xử với người báo tin về cú bóng xoáy và với thất bại
- Tổ chức Power-Oriented bắn người đưa tin về cú bóng xoáy, và thất bại dẫn tới việc tìm vật tế thần
- Tổ chức Rule-Oriented phớt lờ người đưa tin về cú bóng xoáy, và xem thất bại là vấn đề thực thi định nghĩa
- Tổ chức Performance-Oriented huấn luyện người đưa tin về cú bóng xoáy, và biến thất bại thành quá trình khám phá
- Nếu vấn đề cần giải quyết vẫn còn liên quan và đáp ứng nhu cầu kinh doanh, cần tiến từng bước một
- Đối tượng cuối cùng của phần mềm được hiện đại hóa là người dùng
Lĩnh vực phức tạp cần quản lý theo hướng thử nghiệm
- Lãnh đạo không nhận ra lĩnh vực phức tạp có thể trở nên nôn nóng khi kết quả mong muốn không xuất hiện nhanh chóng
- Trong lĩnh vực phức tạp, năng lực chịu đựng thất bại rất quan trọng, và thất bại là yếu tố thiết yếu của việc hiểu biết thông qua thử nghiệm
- Kiểm soát tổ chức quá mức sẽ chặn mất cơ hội để các mẫu hình hữu ích lộ diện
- Lãnh đạo cố cưỡng ép trật tự lên bối cảnh phức tạp sẽ thất bại
- Lãnh đạo biết dựng sân khấu, lùi lại một bước, để các mẫu hình lộ diện và đánh giá mẫu hình nào là mong muốn có thể thành công
1 bình luận
Ý kiến trên Hacker News
Tôi từng trải qua thời kỳ ban lãnh đạo coi ước tính như hạn chót, liên tục thay đổi đặc tả nhưng hoàn toàn không muốn nghe vì sao con số có thể thay đổi
Khi đó, với mọi việc không hề nhỏ nhặt, tôi chọn phản ứng kiểu “con nai đứng trước đèn pha”. Nếu nói: “Việc này có thể khá lớn đấy. Tôi nghĩ ai đó trong nhóm cần dành khoảng một giờ để xem thực sự cần những gì”, thì quản lý lúc nào cũng hỏi “dù chỉ là ước chừng cũng được”. Khi ấy tôi đưa ra một con số đủ lớn để họ bật khỏi ghế, và con số đó sẽ được ghi nhớ. Sau đó, dù đã thẩm định một giờ, tôi cố gắng không đưa con số nào khác ngoài con số ước chừng đó, rồi cuối cùng hoàn thành “sớm hơn kế hoạch” để trông có vẻ tốt
Với quản lý giỏi thì hoàn toàn không cần chiến lược này, điều đó thật tuyệt, nhưng với những người không có ý định học năng lực cần có cho công việc của mình thì tôi phải ứng phó như vậy. Các cuộc họp cũng trở nên thú vị hơn nhiều
Nhóm thiết kế, nhóm frontend, nhóm backend, nhóm QA đều phóng đại như vậy, rồi quản lý dự án lại nâng tổng đó thêm 150~200%, và quản lý khách hàng cùng đội sales cũng cộng thêm 150~200% nữa trước khi tính chi phí
Kết quả là việc bảo trì một website mà một đội chuyên trách gồm 8~10 lập trình viên web/full-stack decent hoàn toàn có thể gánh được lại tốn gần 1 triệu USD mỗi tháng. Nếu bỏ phần hỗ trợ 24/7, tôi nghĩ vài lập trình viên Rails hoặc Django giỏi, thậm chí một người cùng một designer đồ họa bán thời gian, cũng có thể làm được
Vài năm sau khách hàng nhận ra tình hình, ban lãnh đạo công ty làm mọi thứ hỏng bét hoàn toàn, khiến khoảng 100 người mất việc và mất các quyền lợi chưa được thanh toán. Hôm đó bản thân tôi cũng mất khoảng 26.000 USD
Tổng sức chứa chẳng hạn là 40 point, và sẽ thay đổi đôi chút khi thành viên rời đi hoặc gia nhập. Velocity là thông lượng trung bình tính theo point trên đơn vị người-ngày
Volatility là mức độ sprint bị thay đổi. Bỏ một ticket 5 point và đưa vào một ticket 3 point cùng một ticket 2 point có thể ổn, nhưng nếu trong sprint 2 tuần mà làm việc đó 12 lần thì dù tổng lượng vẫn dưới 40 point, sprint cũng không thể kết thúc được
Chúng tôi chụp snapshot sprint hằng ngày để xem lượng ticket được thêm/xóa, và có thể cho quản lý thấy rằng khi độ biến động thấp thì gần như luôn hoàn thành, nhưng khi cao thì sẽ thất bại bất kể có vượt Velocity hay không. Lý do là không có thời gian để lập kế hoạch đúng cách và làm rõ yêu cầu. Việc buộc nhóm sản phẩm nhìn xa hơn 2 tuần có hiệu quả ở một mức nào đó
Những kỹ sư đưa ra ước tính bị thổi phồng quá mức cho các tác vụ đơn giản cũng thường có khả năng là người hiệu suất thấp. Cách đó có thể hiệu quả với người không đánh giá việc giao hàng chậm hoặc quản lý không hiểu tình hình, nhưng quản lý hiểu chuyện sẽ nhận ra rất nhanh
Thay vì một giá trị cố định duy nhất, nên đưa kèm khoảng sai số, như “3 tháng, ±4 tuần”. Hầu hết kỹ sư đều biết ước tính của mình có khoảng sai số, nhưng không hiểu sao lại được rèn cho quên nói điều đó ra
Từ góc độ quản lý, kích thước khoảng sai số cũng cho thấy ngay mức độ tự tin vào ước tính và giúp thảo luận về rủi ro. Có thể có những cuộc trao đổi như: “Hiện sai số hai phía là 30%, nguyên nhân lớn nhất là gì, và liệu có thể điều tra vài ngày để giảm dần từng phần không?”
Tôi không hiểu nổi một nghề gọi là kỹ thuật mà lại không thể nói đúng cách về rủi ro, xác suất, khoảng tin cậy. Đây cũng không chỉ là trách nhiệm của quản lý
Có thể thông cảm cho quản lý thiếu kinh nghiệm hoặc người tạm thời lấp chỗ của ai đó vì họ chưa quen với sự bất định, nhưng trong các trường hợp khác thì không có lý do bào chữa
Bài viết này nói về các dự án hiện đại hóa, và những dự án như vậy có deadline lỏng vì phần mềm hiện có vẫn chạy trong lúc phát triển bản thay thế
Dù có áp lực ngân sách, cam kết và kỳ vọng của người dùng về tính năng mới, việc bản thay thế chậm một ngày không phải là thảm họa
Ngược lại, nếu phóng tàu thăm dò vũ trụ mà vị trí hành tinh không còn phù hợp để hỗ trợ hấp dẫn, con tàu sẽ không tới được đích. Nếu một công ty sản xuất dụng cụ nhỏ có doanh thu 100 triệu USD/năm ký hợp đồng với Ford để giao khuôn cho dây chuyền sản xuất F150 năm 2026 trước tháng 3, và nếu trễ sẽ bị phạt 20.000 USD mỗi phút, thì đến tháng 2 họ không thể nói “có chuyện bất ngờ nên không làm được”. Chỉ nên ký khi chắc chắn có thể làm được
Ford hay NASA sẽ không ngạc nhiên dù việc báo giá tốn hàng chục nghìn USD. Họ đưa ECO, và dù một chi tiết trông như có thể làm thủ công trong 30 phút cần 3 tuần và 8.000 USD, họ hiểu trong đó bao gồm rủi ro deadline, giai đoạn tiếp nhận, giai đoạn kiểm tra, kế hoạch dự phòng, v.v.
Nhưng nếu trong nhóm hiện đại hóa của OP mà nói “do thông tin chưa đầy đủ, một việc 30 phút đổi chữ trên nút có thể mất tối đa 3 tuần và 8.000 USD” thì sẽ bị đuổi thẳng. Ước tính lạc quan được tưởng thưởng, ước tính bi quan bị kìm nén, còn ước tính chính xác trở nên không quan trọng. Kết cục là lúc nào cũng trễ lịch mà chẳng ai thấy quá ngạc nhiên
Có thể bao gồm bảo trì để đáp ứng thay đổi phần cứng, nâng cấp hệ điều hành, tính năng mới. Tôi từng thấy những dự án chạy song song kiểu này hơn 10 năm
Năm 1505, Michelangelo ước tính sẽ mất 5 năm để hoàn thành lăng mộ của Giáo hoàng Julius II
Trên thực tế mất khoảng 40 năm vì những việc phụ nhỏ như vẽ trần Nhà nguyện Sistine
Không giữ được deadline dựa trên ước tính, trong khi quy mô dự án bị thu hẹp đáng kể. Nguyên nhân là Giáo hoàng Julius II qua đời trước khi hoàn thành, cùng với các yêu cầu thay đổi từ khách hàng Julius và những người thừa kế, vấn đề chuỗi cung ứng, đàm phán lại hợp đồng, tranh chấp lao động, thiếu lao động lành nghề, và cạn vốn do thời gian kéo dài
Vậy nên ít nhất từ năm 1505 chuyện này đã tồn tại. Điều thú vị là vị giáo hoàng đó thậm chí cũng không được chôn trong lăng mộ ấy
Tôi học được một điều quan trọng từ sớm trong sự nghiệp. Con số đưa ra đầu tiên là thứ người ta nhớ
Đáng tiếc là thực tế thường đúng như vậy, và mọi người sẽ cứ nói “chẳng phải ban đầu đã nói là X sao?”. “Đúng, nhưng giờ đã có thêm thông tin mới” không phải lúc nào cũng hiệu quả
Những người biết điều này cũng gặp tác dụng phụ là né tránh đưa ra con số
Scotty: “Tất nhiên rồi, thưa thuyền trưởng. Như vậy tôi mới giữ được danh tiếng là người tạo ra phép màu chứ”
Ví dụ đổi ngày→tuần, tuần→tháng, tháng→quý. Nếu việc đáng lẽ mất một ngày, tôi sẽ nói là 3 tuần. Nghe có vẻ nhiều, nhưng cuối cùng vì quan liêu, quy trình và nợ kỹ thuật, đa phần cũng kết thúc quanh mức đó
Có đoạn nói rằng “Bạn có tưởng tượng được công ty bảo hiểm cãi với xưởng sửa chữa rằng ước tính ban đầu là 18.000 đô la nên họ sẽ không trả thêm 20.000 đô la không? Vô lý đúng không? Tôi cũng thấy vậy. May là thực tế không vận hành như thế”, nhưng trong bảo hiểm thì chuyện đó xảy ra suốt
Không chỉ bảo hiểm ô tô, nhà cửa mà bảo hiểm y tế cũng vậy. Nhiều trường hợp được thương lượng về mức hợp lý, nhưng không phải lúc nào cũng thế, nên giọng điệu tự tin rằng “thực tế không vận hành như thế” khá đáng ngạc nhiên
Dù xử lý tổn thất toàn bộ có thể đắt hơn, nhưng trần chi phí rõ ràng và có thể đóng hồ sơ bồi thường. Công ty bảo hiểm ghét các hồ sơ bồi thường còn mở
Trường hợp sau, trong bảo hiểm ô tô còn gọi là “mức giá ưu tiên”, là một hợp đồng khung theo đó một số loại công việc nhất định được tính phí theo mức giá thương lượng cố định
Điều này rất khác với một báo giá có tính ràng buộc. Báo giá ràng buộc thường là báo giá một lần cho một công việc cụ thể, trong đó người ước tính chịu rủi ro và cam kết hoàn thành với mức giá đó dù công việc phức tạp hơn dự kiến rất nhiều
Một mẹo là, nếu có thể, hãy luôn chỉ ước tính cho phạm vi cố định, và loại trừ các yếu tố chưa biết không thể biết trước
Đừng ước tính “triển khai tính năng X”, mà hãy ước tính “engine của tính năng X”. Khi phát hiện thêm việc, hãy thêm chúng thành các mốc đã được phát hiện như “refactor mã hiện có”, “tích hợp tính năng X+Y”
Tuy nhiên cách đặt tên và cách hiểu này phải được truyền lên cấp trên thì mới có tác dụng. Nếu ai đó đổi mốc “engine của tính năng X” thành “hoàn tất tính năng X” với cùng một ước tính thì hỏng
Tôi cũng từng thấy một vấn đề liên quan: lãnh đạo coi deadline là “động lực”. Giống như những người muốn sưởi nhà lên 72F nhưng lại đặt thermostat ở 80F “cho nhanh hơn”
Có lần, những người dự một cuộc họp lãnh đạo quên mất rằng tôi, một kỹ sư cấp thấp, cũng được mời tham dự. Khi có người thừa nhận rất khó giữ deadline X và hỏi liệu có nên đổi sang một ngày thực tế hơn không, một PM cấp cao trả lời: “Chúng ta tuyệt đối không dời deadline! Engineering sẽ dùng hết thời gian được cho!”
Trong trường hợp đó, engineering đã trả lại thời gian khi tôi rời khỏi đội đó
Việc nhiều đội engineering dùng hết thời gian được cho cũng là sự thật
Nhưng thay vì biến ước tính và kế hoạch thành deadline cứng trước mặt kỹ sư, nhà quản lý nên chuẩn bị cho tổ chức ứng phó với khả năng vượt thời gian. Khi thời điểm hoàn thành dự kiến đến gần, nếu developer có thể giải thích phần nào mất nhiều thời gian hơn và vì sao, thì nên hiểu điều đó một cách hợp lý
Nhà quản lý cũng phải đảm bảo khách hàng, sales và quản lý cấp cao không coi thời điểm hoàn thành đã lên kế hoạch là deadline. Nếu phải cam kết, deadline hướng tới khách hàng nên nằm sau thời điểm hoàn thành dự kiến một khoảng đáng kể
Radiator điện thực ra cũng có thể có hiệu quả tương tự. Vì nó sẽ không tắt ngay chỉ vì không khí gần radiator đã ấm lên
Sau khi trải qua quá nhiều lần “ước tính đoán đại” biến thành deadline cứng, tôi đang thúc đẩy cách tiếp cận No Estimates với các bên liên quan
Ban đầu tất nhiên sẽ có phản kháng. Để giải tỏa lo ngại, sẽ hữu ích nếu giải thích rằng những ước tính đủ chính xác để có thể dùng chính đáng cho lập kế hoạch thực ra chỉ khả thi trong hai trường hợp
A) Khi phần việc còn lại gần như là bản sao của việc đã làm trước đó. Ví dụ provision trung tâm dữ liệu thứ hai cho cùng một hệ thống
B) Khi đội đánh giá rằng phần việc tính năng mới còn lại đã bước vào tứ phân vị cuối cùng, và đã được xác định rõ, bao gồm cả các rủi ro còn lại có thể cản trở thành công
Ước tính vi mô tạo điều kiện cho quản lý vi mô. Một đội lành mạnh sẽ tìm các việc có ưu tiên cao nhất dựa trên rủi ro đối với thành công của dự án và thực hiện theo thứ tự từ cao xuống thấp
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
Tôi chú ý đến một công thức thú vị từng thấy trên HN. Trông hào nhoáng và hay ho, nhưng cũng như các cách ước tính khác, nó không có tính đúng đắn hình thức; chỉ là một công thức tùy ý dựa trên kinh nghiệm cá nhân
https://news.ycombinator.com/item?id=37965582
Toán ước tính của tôi: R = t × [1.1^ln(n+p) + 1.3^X]
R là thời gian thực tế cần, t là thời gian ngắn nhất có thể khi không cần giao tiếp, n là số người tham gia vào quá trình, bao gồm cả khách hàng và tổ chức phát triển, p là khoảng cách giao tiếp dài nhất trong dự án, X là số công cụ, thư viện, kỹ thuật mới được dùng trong quá trình
Ví dụ, một dự án do một developer viết mã mất 2 tuần (t=2), tổng cộng 5 người liên quan (n=5), có 1 công cụ mới (X=1), khoảng cách giao tiếp dài nhất là 4, thì 2×(1.1^ln(5+4) + 1.3^1) = 4,5 tuần
Không chỉ các ẩn số đã biết, mà cả ẩn số chưa biết cũng phải được cộng vào số lượng X
Đáng buồn là ước lượng thực chất là đàm phán. Người đưa ra con số trước thường thua vì “cái nhăn mặt”
“Ước lượng thế nào?” “Tôi không rõ.” “Cứ nói đại khái cũng được.”
“Vậy anh/chị muốn đến khi nào?”
Đây là cái bẫy mà các quản lý mới lần nào cũng mắc. Hễ bạn đưa ra câu trả lời là bingo. Lúc đó họ sẽ cho bạn thấy “cái nhăn mặt”. Hít một hơi qua kẽ răng, nhăn mặt rồi nói: “À, cái đó hoàn toàn phi thực tế. Rốt cuộc con số đó từ đâu ra vậy?”, sau đó đưa ra một con số cao gấp mấy lần hoặc đề xuất cắt giảm khối lượng công việc. Kiểu như: “Ôi trời, trong khoảng thời gian đó thì phải rất may mắn và cắt tính năng Y ở dự án khác mới chỉ làm được tính năng X thôi”
Dù làm gì thì điều quan trọng là đừng đưa ra con số trước. Cũng như chơi poker hay mua ô tô, cần một thời gian để quen cảm giác. Thời gian, ngay cả ở các tập đoàn lớn, cũng là tiền, và phải được đối xử như vậy. Trò chơi tổng bằng không
Ở nơi tôi làm việc, dưới danh nghĩa hiệu quả, các ước lượng liên tục bị hạ thấp, và công việc chuyển sang kỳ sau cũng không được phép
Tôi đã ở trong trạng thái gần như crunch hơn một năm mà không có thời gian hồi phục. Tôi cứ hy vọng mọi thứ sẽ khá hơn, nhưng dường như nó chỉ tệ đi. Hơn nữa, mọi người liên tục bị luân chuyển sang các mảng khác của sản phẩm, không có lựa chọn nào khác. Tôi vẫn còn chạy tiếp được, nhưng về mặt tinh thần thì cảm giác đã kiệt sức hoàn toàn