Vụ nói dối CTO để thoát khỏi khủng hoảng
(GrumpyOldDev.com)- Dự án lớn cho một khách hàng của doanh nghiệp Fortune 500 bắt đầu với sự phụ thuộc vào sản phẩm của vendor, nhưng thực tế đó là phần mềm gần như bán thành phẩm cần tùy biến rất nặng
- Việc tích hợp vendor đồng thời tạo ra nhược điểm của cả gói phần mềm kém linh hoạt lẫn phát triển tùy chỉnh, dẫn đến một cuộc death march tích hợp nhằm kịp ra mắt vào tháng 10 sau khi bàn giao trong tháng 8
- Thiết kế lưu toàn bộ giao dịch của khách hàng trong một tài liệu JSON khổng lồ đã gây ra vấn đề hiệu năng, và giới hạn 16MB cho mỗi tài liệu của MongoDB khi đó lộ ra là một rào cản chí mạng trong quá trình chuyển đổi dữ liệu thực tế
- Công ty che giấu vấn đề với khách hàng và vendor, lùi ngày phát hành một tháng, rồi trong khoảng 2 tháng triển khai một bản viết lại kiểu skunkworks bằng đội ngũ nội bộ chỉ 3 người để thay thế phần tích hợp vendor
- Khi CTO yêu cầu làm việc trong kỳ nghỉ ngay trước Giáng sinh, trưởng nhóm đã báo cáo như thể công việc vẫn đang được tiến hành mỗi ngày dù thực tế đã xong, để các lập trình viên được nghỉ ngơi; cả nhóm vẫn kịp lịch kiểm thử và phát hành trong tháng 1
Thiết kế sai lầm bắt đầu từ sản phẩm của vendor
- Tại một công ty thuộc Fortune 500, CTO hứa sẽ bàn giao một dự án lớn cho một khách hàng quan trọng có quan hệ cá nhân với mình
- Phần cốt lõi được thuê ngoài cho một nhà cung cấp dịch vụ công nghệ lớn, và vendor khẳng định họ có một sản phẩm có thể xử lý phần lớn công việc nặng
- Trên thực tế, sản phẩm chỉ tương đối phù hợp với yêu cầu, nên cần tùy biến rất nhiều mới tạo ra được hành vi cần thiết
- Kết quả là nhược điểm của phần mềm vendor và phần mềm tùy chỉnh cùng xuất hiện
- Nó trở thành một gói phần mềm kém linh hoạt bị ép phải làm những việc khác với mục đích thiết kế ban đầu
- Nó bị fork khỏi codebase chính của vendor, khiến chi phí bảo trì tăng cao và có nguy cơ một ngày nào đó bị ngừng hỗ trợ
- Những người tham gia dự án đều thấy cách làm này không ổn, nhưng trong bối cảnh hệ thống báo cáo trực tiếp dưới quyền CTO thay đổi liên tục, các cuộc họp tình trạng thường trôi theo kiểu “ý tưởng hay đấy, sếp”
Trễ tiến độ và cấu trúc dữ liệu chí mạng
- Đội phát triển nội bộ tự xây các phần khác của dự án, còn vendor suốt mùa hè đều hứa rằng sản phẩm của họ sắp sẵn sàng để tích hợp
- Khi sản phẩm của vendor được bàn giao vào tháng 8, một cuộc death march tích hợp để kịp ra mắt vào tháng 10 bắt đầu
- Đến tháng 9, các lỗi ở mức có thể chặn phát hành đã lộ ra
- Sản phẩm của vendor lưu toàn bộ giao dịch của mỗi khách hàng dưới dạng các bản ghi JSON trong một tài liệu JSON khổng lồ duy nhất
- Càng tích lũy dữ liệu thử nghiệm, hiệu năng càng chậm dần
- Mỗi khi thêm giao dịch mới, hệ thống phải đọc toàn bộ tài liệu JSON từ cơ sở dữ liệu rồi gắn bản ghi mới vào cuối
- Vendor nói rằng thêm index vào các trường giao dịch sẽ giải quyết được, và cách này có vẻ hữu ích trong thời gian ngắn
Giới hạn 16MB của MongoDB và bản viết lại bị che giấu
- Vấn đề lớn hơn là cơ sở dữ liệu mà vendor chọn là MongoDB, và khi đó MongoDB có giới hạn 16MB cho mỗi tài liệu
- Tới tháng 10, khi đội chuyển đổi bắt đầu nạp dữ liệu khách hàng thật, họ bắt đầu vướng phải giới hạn 16MB
- Công ty quyết định đi vào vận hành muộn hơn một tháng mà không tiết lộ giới hạn này cho khách hàng
- Đồng thời, họ bắt đầu một dự án skunkworks để thay thế phần tích hợp vendor
- Họ cũng không nói cho vendor biết việc này
- Có nghĩa là họ đã che giấu tình hình cốt lõi với cả khách hàng lẫn đối tác công nghệ
- Ban đầu phía vendor có khoảng 70 người tham gia, nhưng công việc thay thế nội bộ chỉ được giao cho 3 người
- 1 người thiết kế cơ sở dữ liệu
- 1 người xây backend giao tiếp với cơ sở dữ liệu
- 1 người xây business logic và web service
Quyết định ngay trước kỳ death march ngày lễ
- Khách hàng được thông báo rằng một phiên bản mới để kiểm thử sẽ được cung cấp vào tháng 1 và sẽ sửa những lỗi nghiêm trọng nhất đã được chấp nhận khi bắt đầu vận hành trước đó
- Nhưng họ không được biết rằng toàn bộ hệ thống cốt lõi đang được viết lại chỉ trong khoảng 2 tháng
- Dự án ban đầu mất hơn một năm mới tới lúc phát hành, nhưng bản viết lại phải do 3 người thực hiện, bao gồm cả giai đoạn nghỉ lễ
- Vào khoảng giữa tháng 12, những người tham gia dự án được thông báo làm việc trong kỳ nghỉ không phải dưới dạng đề nghị mà là mệnh lệnh
- Hầu hết thành viên trong nhóm đã rơi vào trạng thái burnout sau 6 tháng làm 60–80 giờ mỗi tuần
- Phát hành phần mềm mang lại áp lực và phần thưởng tương tự một buổi biểu diễn sân khấu
- Kết quả của nhiều tháng hoặc nhiều năm chuẩn bị sẽ chạm tới người dùng thực sự vào ngày phát hành
- Lập trình viên nhận được cảm giác thành tựu rất mạnh từ việc “mình đã làm được” và từ phản ứng của người dùng
- Việc phát hành phần mềm có thể giống như một buổi biểu diễn trực tiếp dành cho những người hướng nội
Một tuần báo cáo gian với CTO để cả đội được nghỉ
- Khi Giáng sinh đến gần, nhóm 3 người đã gần như hoàn thành phần mềm thay thế chỉ sau một tháng
- Vẫn còn một số tính năng cần hoàn thiện, nhưng nếu nhóm không bị burnout thì họ có thể kịp lịch kiểm thử tháng 1
- Khi CTO ra lệnh hủy kỳ nghỉ, trưởng nhóm bề ngoài trả lời “OK”
- Nhưng trên thực tế, anh ấy nói với 3 lập trình viên: “Nghỉ một tuần đi. Để tôi lo.”
- Mỗi sáng, trưởng nhóm tham gia cuộc họp tình trạng bắt buộc và báo cáo với CTO như thể nhóm vẫn đang thực hiện những công việc thực ra đã xong từ tháng trước
- “Cả nhóm đang làm việc rất chăm chỉ. Hôm nay chúng tôi đã đạt mốc tích hợp #73”
- “Hôm qua cả nhóm đã có tiến triển tốt và hoàn thành thêm một web service nữa”
- Một tuần sau, các lập trình viên quay lại với trạng thái được nạp lại năng lượng
- Cả nhóm kịp lịch tháng 1, hoàn tất một đợt phát hành tốt, và trong chốc lát cảm thấy mình như những ngôi sao rock
- Dù cảm giác đó gần với Herman’s Hermits hơn là The Beatles, họ vẫn hồi tưởng rằng nó rất tuyệt
1 bình luận
Ý kiến trên Hacker News
Nếu bạn là kiểu người hủy kỳ nghỉ và tiếp tục làm việc với lý do “ưu tiên deadline”, thì với tư cách người từng trải, tôi muốn nói rằng đừng ngốc nữa
Khi công sức làm việc chăm chỉ được ghi nhận thì đặc biệt khó dừng lại, nhưng cuối cùng bạn sẽ hối tiếc về toàn bộ quãng thời gian đó
Nếu cấu trúc của công ty là nghiễm nhiên lôi ngày nghỉ và kỳ nghỉ của nhân viên ra dùng để bán được sản phẩm, thì bạn đang góp phần tạo nên một thế giới đầy vấn đề như hiện nay
Nếu nhiều người làm vậy thì sẽ càng có thêm nhiều người phải làm vậy; còn nếu không ai làm và mọi người hành xử như thể chính yêu cầu đó là vô lý, thì công ty sẽ phải đưa ra ước tính thực tế, dù túi tiền của CEO có đau đi nữa
Hãy thông báo kế hoạch nghỉ phép, bố trí người thay thế, đưa vào lịch nhóm, bàn giao rồi cứ thế nghỉ
Dự án đến rồi đi, lịch trình cũng tự trễ
Một khi bắt đầu dời kỳ nghỉ theo lịch dự án, bạn sẽ không bao giờ đi nghỉ được
Ngoại lệ chỉ là những vai trò có giai đoạn bận rộn đã được biết rõ như cuối năm, cuối quý, mùa thuế, nơi việc biến mất đúng lúc đó là không phù hợp
Anh họ tôi đã làm việc gần như mỗi ngày đến 1 giờ sáng từ tháng 9/2023 đến tháng 1/2024 để hoàn tất một dự án được quản lý tệ hại, chỉ nghỉ đúng Giáng sinh, mà ngay cả việc đó cũng là do giám đốc cho phép vì đó là ngày lễ tôn giáo và sợ nhân viên kiện
Anh ấy bỏ lỡ nhiều việc quan trọng và sụt khoảng 20 pound vì căng thẳng
Công ty có deadline gấp để chuyển sang hệ thống mới, họ đã biết việc này từ 5 năm trước nhưng mãi đến năm trước đó mới bắt đầu
Nếu không kịp deadline, họ sẽ tốn hàng triệu đô la chi phí ngoài hợp đồng; cuối cùng nhóm đã kịp deadline, nhưng phần thưởng vài tuần sau đó là bị sa thải với lý do vị trí không còn nữa
Giờ anh ấy đã ngoài 50 và đang tìm việc vào thời điểm tệ nhất để xin việc
Họ nghiện cảm giác mình có giá trị và quan trọng, và tan làm rồi cũng chẳng có việc gì khác để làm
Một vài trường hợp, chính nhân viên được trao thưởng cũng chịu một phần trách nhiệm cho mớ hỗn loạn đó
Phải đến khoảng câu chuyện thứ tư, các quản lý cấp cao trong phòng mới nhận ra công ty có vấn đề mang tính cấu trúc
Nếu có người trẻ nào đang đọc, việc những câu chuyện như thế này diễn biến ra sao phụ thuộc rất lớn vào công ty và vận may
Ở một công ty lành mạnh, cách triển khai bằng outsourcing có lẽ đã không được bắt đầu ngay từ đầu
Vì đó là một kiểu thất bại quá hiển nhiên mà người có kinh nghiệm có thể dự đoán kết quả trước khi bắt đầu
Ở thời điểm sớm hơn, mọi người đã không nói dối CTO rằng mọi thứ đang ổn, mà sẽ nói rằng nó không ổn
Nếu cần một cách thông minh hơn hoặc sáng tạo hơn để cứu dự án, họ đã điều chỉnh cùng CTO, và có thể cả với khách hàng
Cũng sẽ không có chuyện ép một nhóm vốn đã burnout làm nhiều giờ vào ngày nghỉ
Quản lý hoặc lead sẽ đối đầu với cấp trên vì thành công của dự án và sức khỏe của nhóm, và nếu cần sẽ khẳng định rằng nhóm phải được nghỉ vào ngày lễ
Trong một tổ chức “tạm lành mạnh”, quản lý có thể cố tình mơ hồ hoặc lược bớt thông tin, và điều đó tốt hay không còn tùy tình huống
Nhưng nếu như trong câu chuyện này, quản lý hoặc lead liên tục nói dối trắng trợn lên trên theo tuyến chỉ huy, thì dù công ty có lành mạnh hay không, điều đó thường bị xem là rất tệ
Dĩ nhiên, những tình huống như thế này sau đó khoanh tay đánh giá thì dễ hơn nhiều
Khi ở vị trí khó khăn hoặc trong trạng thái làm việc quá sức, ai cũng có thể mắc sai lầm, nhưng việc xem và học từ các kịch bản như vậy vẫn có ý nghĩa để có thể phản ứng tốt hơn nếu lại bị ném vào một tình huống khắc nghiệt tương tự
Nếu bạn đang ở một công ty như vậy, tốt nhất nên bắt đầu tìm việc mới
Cấp trên mục ruỗng đến mức này thì không thể sửa, và họ cũng sẽ không đưa bạn lên làm CTO đâu
Trong 25 năm đi làm vừa qua tôi chưa từng thấy một lần nào
Mất một năm rưỡi để sửa, và trong thời gian đó cũng không thể đảo ngược giao dịch chỉ vì “đồ lót” đã được giao
Thực tế chúng tôi không bán đồ lót mà chỉ bán dịch vụ mạng, nhưng vẫn phải chờ hệ thống đóng quy trình đơn hàng rồi mới có thể giúp khách hàng
Thành viên hội đồng quản trị đó rời đi sau một năm, và chắc hẳn khá hài lòng vì đã lừa được vị CEO ngu ngốc
Cuối cùng tôi bị sa thải ở đó, và tôi chẳng có chút cảm thông nào với cái công ty lúng túng ấy
Họ là những kẻ ngốc cố outsource một “giải pháp” nhưng chỉ làm mọi người khổ thêm
Có những vấn đề thực sự cần được giải quyết, nhưng một nửa chỉ là rác để tạo cảm giác “không tự làm trong nhà nên tiết kiệm tiền”
Cuối cùng lại phải tiếp tục trả phí hợp đồng để duy trì thứ rác mà ngay từ đầu mình đã không tạo ra
Ý là nói đúng sự thật thay vì che giấu vấn đề, nhưng chuyện đó thật sự hiếm
Cứ nhìn memo bảo mật của Microsoft là thấy
Không có death march vào ngày nghỉ thì nếu bạn làm ở ngân hàng hoặc FAANG, điều đó đúng ở một mức nào đó
Nếu là công ty có “văn hóa startup” thì tốt nhất quên đi
Thực tế khi lợi ích cá nhân bị đặt vào thế liên quan, thái độ với công việc thay đổi khá nhanh, nhưng tôi nghĩ không có nhiều công ty cho bạn cơ hội để có và chứng kiến điều đó
Tôi từng nhiều lần âm thầm bẻ cong quy tắc lúc nửa đêm để làm cho xong việc cần làm, và nhiều người giỏi cũng đã đi con đường đó
Thậm chí tôi còn thấy chuyện này ở ngân hàng
Miễn là bạn không đặt cược tài chính lớn hơn giá trị của công ty hoặc đội nhóm, thì nhiều việc có thể được bỏ qua
Hoặc bạn làm được rồi thăng chức, hoặc vì đã tự giảm khả năng thăng chức của mình nên bạn sẽ đi tìm việc mới
Đoạn “sản phẩm của vendor lưu mọi giao dịch của khách hàng dưới dạng các bản ghi JSON bên trong một tài liệu JSON khổng lồ, và để thêm giao dịch mới thì phải đọc toàn bộ tài liệu JSON từ cơ sở dữ liệu rồi gắn bản ghi mới vào cuối” nghe như điên rồ mới là bình thường
Tương tự, tôi từng giúp thẩm định kỹ thuật một đối tượng đầu tư tiềm năng cho một quỹ, và bảng người dùng của startup đó cũng chứa cả dữ liệu vé/đặt chỗ
Vì mỗi vé là một cột, nên nếu người dùng năng động nhất có 5 vé trong toàn bộ lịch sử thì cần 5 cột
Lúc rà soát thì đã có hơn 500 cột, và họ đang tìm vốn đầu tư để “mở rộng”
Tất nhiên đây là vấn đề có thể giải quyết, nhưng như bạn đoán, mọi thứ đều được thiết kế theo kiểu đảo ngược méo mó, và đó là khoảnh khắc “cái quái gì thế này” rõ ràng nhất
Họ không gọi được vốn
Toàn bộ cơ sở dữ liệu khách hàng và sản phẩm, kèm mật khẩu dạng plaintext, được lưu trong một file
.jscông khai duy nhất nặng vài megabyte, và với tốc độ Internet đầu những năm 2000, ứng dụng phải tải xong file đó trước khi làm được bất cứ thứ gìHơn nữa ứng dụng là một file khổng lồ duy nhất, còn trong thư mục thì đầy những tên như
index.1.js,index.final.js,index.newest.js,index.45.jsTôi có đủ kinh nghiệm để biết best practice là gì, nên đã gặp CEO để khiến CTO bị sa thải, rồi bắt đầu làm lại với
git,mysql, logic phía server và cấu trúc thật sựRồi cái Windows server đang chạy toàn bộ thứ này bị hack và biến thành server khiêu dâm; tôi thậm chí chưa từng thấy server đó và cũng không có quyền admin, nhưng không hiểu sao lại thành trách nhiệm của tôi
Vài công việc đầu đời đúng là rất có tính giáo dục
Một senior engineer hay khoe mình xuất thân từ Stanford đã thiết kế hệ thống đó
Tôi tranh luận dài dòng dựa trên dữ liệu vận hành thực tế rằng nếu ra mắt thì nó sẽ không scale, nhưng không ai nghe, và chỉ vài tuần sau khi ra mắt nó sập
Không lâu sau tôi chuyển đội, và tệ nhất là senior engineer đó cuối cùng được thăng chức, còn hệ thống thì bị chuyển giao cho một đội hoàn toàn mới để họ vật lộn
Toàn bộ thiết kế hệ thống thật khủng khiếp, và bạn có thể đoán vì sao
Mua chuộc ban điều hành bằng những bữa tối và chuyến đi hào nhoáng, rồi bàn giao một sản phẩm nát để sau này vẫn tiếp tục cần đến họ
Trong chính câu chuyện này, CTO chẳng biết gì cả
Từ góc nhìn của ông ấy, rốt cuộc mọi thứ trông như đã diễn ra tốt đẹp
Trừ các developer làm 80 giờ/tuần ra thì đây là chiến thắng cho tất cả
Mọi thứ trong câu chuyện này đều hỏng, bao gồm cả cách tiếp cận của nhân vật chính
Team lead cho mọi người nghỉ phép rồi nói dối để che giấu chuyện đó là hoàn toàn không thể chấp nhận được, và khá nằm trong vùng công ty có thể sa thải
Thực tế có vẻ còn có thể sa thải có lý do chính đáng
Tuy nhiên cấp trên có vẻ lệch quỹ đạo đến mức có lẽ họ sẽ bỏ qua, thậm chí còn khen ngợi
Trông như đó là hành động phù hợp với môi trường mà anh ta đang ở
Nếu khuyên một team lead mới, thì ở đây chẳng có gì đáng tự hào cả; lựa chọn tốt hơn là làm ầm lên rằng mọi người đang làm quá giờ, và yêu cầu vendor bị áp dụng các tiêu chuẩn bình thường hoặc phạm vi dự án được xem xét lại cho phù hợp với tuần làm việc bình thường
Nếu cứ xoay xở cho tình huống kiểu này chạy được, chẳng có lợi ích gì mà chỉ khiến người ta burnout hoặc bị sa thải
Trừ khi thật sự tuyệt vọng vì phải nuôi gia đình, team lead có trách nhiệm bảo vệ giờ làm việc hợp lý của đội trước những yêu cầu điên rồ
Đó là ngọn đồi đáng chấp nhận bị sa thải, không phải ngọn đồi để nói dối
Vì vậy nếu không ảnh hưởng đến kết quả, việc team lead cho mọi người nghỉ phép và thậm chí nói dối cũng hoàn toàn có thể chấp nhận được
Nếu chia sẻ thì ban quản lý sẽ làm gì? Họ sẽ kéo dự án lên sớm hơn nữa
Với những kẻ muốn bắt người khác làm việc cật lực hơn vì vinh quang của bản thân, cần phải cho họ một cú
Rốt cuộc là cứu ngày của ai?
Vendor tệ hại đã bàn giao rác rưởi?
CTO rõ ràng là vây quanh mình bằng yes-man và hoàn toàn không biết chuyện gì đang diễn ra trong công ty?
Các developer làm đến mòn xương nhưng rồi thành “không sao, tôi đã cho các bạn nghỉ một tuần rồi mà”?
Nhân vật chính đã nói dối mọi người để đáp ứng một deadline tùy tiện của một công ty không quan tâm đến nhân viên?
Câu chuyện này khiến tôi rùng mình ở từng khoảnh khắc
Tôi là người làm việc chăm chỉ, và đôi khi cũng làm thêm để việc ra mắt cho khách hàng diễn ra suôn sẻ, nhưng câu chuyện này là sự điên rồ thuần túy
Việc thỉnh thoảng bỏ thêm thời gian là vì có quan hệ tin cậy với sếp, và biết rằng mình luôn có thể nói sự thật
Thực ra đó là khái niệm cốt lõi của văn hóa không đổ lỗi, và chỉ khả thi khi mọi người đều nói sự thật
Nói dối điên cuồng để đáp ứng deadline của một CTO ngu ngốc đúng nghĩa là mất trí
Nếu đang ở trong tình huống như vậy thì nên thoát ra ngay và tìm một công việc tốt hơn
“Niềm tự hào và cảm giác thành tựu” cùng với burnout à?
Chữ “chúng tôi” trong đoạn “đã kịp lịch tháng 1, ra mắt xuất sắc, và trong chốc lát trở thành rockstar” rõ ràng nghĩa là tôi
Có thể là tôi đã may mắn, nhưng tôi chưa từng bị sa thải vì nói thật, và sự thật thì dễ căn chỉnh hơn
Kiểu như nói: “Có lỗi trong một thư viện bên thứ ba nằm trên đường găng. Chúng ta có thể làm cho lỗi khó gặp hơn, nhưng không thể sửa cho đến khi nhà cung cấp sửa”, hoặc “Do người dùng tăng, vấn đề hiệu năng lộ ra sớm hơn dự kiến. Trong 2 tháng sửa lỗi, chúng ta có thể chi gấp ba cho hạ tầng để giảm nhẹ, hoặc mất khách hàng vì hiệu năng”, hoặc “Khách hàng lớn nhất chỉ sau khi nhận bản lặp đầu tiên mới biết họ muốn gì. Nó hoàn toàn khác với thứ chúng ta tưởng mình sẽ xây. Ta có thể xây cái đó rồi kiếm tiền, hoặc cứ đuổi theo giấc mơ rồi chết”
Xin nhắc lại, có thể tôi đã may mắn, nhưng sự trung thực đã vận hành tốt với tôi
Vì vậy, như những người khác đã nói, hãy nói “tôi sẽ xem xét” rồi từ từ đẩy ra, hoặc điều họ sang việc lặt vặt
Lựa chọn thứ hai là ngậm miệng và nhìn họ chật vật trong thời gian dài rồi thất bại
Thường mất khoảng 1 năm, nhưng tôi cũng từng thấy chuyện bị gấp lại trong 2–3 tháng và ban lãnh đạo thực tế bị cắt ở quý sau
Nếu ai đó hỏi ý kiến, bạn có thể giải thích các mối lo một cách ngoại giao; nhưng nếu họ không hỏi, bạn cũng có thể im lặng
Điểm cốt lõi là liệu bạn có chủ động chỉ ra vấn đề trong kế hoạch mà một người cấp cao hơn bạn đang định lấy công hay không
Ngay khoảnh khắc bạn nói ra, họ sẽ cảm thấy phán đoán của mình bị nghi ngờ và xem đó là công kích cá nhân
Làm điều đó mà không tạo kẻ thù là cực kỳ khó; kẻ thù thì ở lại lâu, và thiệt hại từ một kẻ thù khó bù đắp bằng nhiều người bạn
Vì vậy phải chơi trò chơi đó
Việc nhân vật chính đang nói dối về những việc đã hoàn thành rồi là một chi tiết thật sự quan trọng
Mỗi sáng, anh ta vào cuộc họp trạng thái death march bắt buộc với CTO và nói “đội đang làm việc chăm chỉ”, “hôm nay đã đạt điểm tích hợp mốc #73”, “hôm qua có tiến triển tốt và đã hoàn tất thêm một web service”, nhưng thực ra đó là những việc đã hoàn thành từ tháng trước
Nhìn từ một góc độ nào đó, việc này giống hứa thấp, giao cao
Nếu anh ta nói dối rằng một việc chưa xong đã xong thì sẽ khó chịu hơn nhiều
Chắc chắn nguy hiểm hơn, và khi đội quay lại, việc nói “đây là các ticket, tôi đã nói với CTO là xong rồi nên làm gấp đi” cũng sẽ không tốt cho đội
Tương tác giữa lập trình viên và ban quản lý chịu ảnh hưởng nặng nề bởi bất cân xứng thông tin và thiếu lòng tin
Hiện tôi đang làm một dự án cập nhật codebase chạy trên một compiler rất cũ
Đã làm 1 năm, các mảng lớn của hệ thống đã xong, nhưng vẫn còn một phần khá quan trọng
Ban quản lý không hiểu quá trình và cũng không chắc dự án cuối cùng sẽ thành công
Dự án phần mềm, đặc biệt là công việc chuyển đổi, có lịch sử thất bại dài, nên tôi không trách họ vì lo lắng
Các cuộc họp tiến độ từ hằng tuần nay đã tăng lên 2 lần/tuần, có vẻ họ nghĩ như vậy sẽ nhanh hơn
Thường họ không trực tiếp tham dự, mà một quản lý cấp trung đóng vai trò người truyền đạt
Từ góc nhìn lập trình viên, hiển nhiên việc này sẽ làm được, và cá nhân tôi chưa từng nghi ngờ khả năng thành công
Chỉ là hệ thống lớn và cũ nên thời gian không chắc chắn
Phần còn lại tính bằng vài tháng chứ không phải vài năm; tôi cũng biết quy luật 80/20, nhưng chúng tôi đã đi sâu vào phần 20% đó rồi
Với ban quản lý, nó chỉ là trạng thái nhị phân hoàn thành/chưa hoàn thành nên khó đo tiến độ, và họ không có “lòng tin” vào những gì chúng tôi nói
Tôi hiểu điều đó
Nếu chúng tôi chẳng làm gì trong suốt 1 năm mà chỉ họp, họ cũng đã không biết
Đây là hợp đồng giá cố định nên chúng tôi không có lý do để kéo dài, nhưng rủi ro thì toàn bộ thuộc về họ
Họ đã chi rất nhiều tiền và đang bất an
Dựa trên lời khuyên của chuyên gia kỹ thuật bên ngoài, họ đã đưa ra các quyết định kỹ thuật tốt, nhưng vẫn thiếu sự chắc chắn
Cuối cùng nếu dự án thất bại, họ là bên chịu đòn, còn chúng tôi thì tương đối ít hơn
Không có giải pháp dễ dàng
Không thể chỉ nói rằng các quản lý phải có kỹ thuật, và công nghệ đó cũng không phải hoạt động kinh doanh cốt lõi của họ
Gọi thêm tư vấn viên cũng sẽ không làm họ thấy ấm lòng hơn
Điều tốt nhất chúng tôi có thể làm là tiếp tục đẩy và bàn giao
Dù là các khối kéo dài một tháng cũng được, cứ phân rã và chia mọi thứ thành các tác vụ con
Không cần hoàn hảo, có chỗ thô cũng không sao
Tôi khuyên nên đặt cho mỗi khối một cái tên thân thiện và vui vui
Ví dụ những tên điệu nhảy cổ điển như tango, chacha, waltz là tốt
Hãy lên lịch họp với các quản lý, bao gồm cả quản lý cấp cao, và yêu cầu các quản lý cấp trung dự thính daily standup
Bắt mọi người đứng để cuộc họp kết thúc ngắn gọn, và theo dõi tiến độ so với các công việc trong danh sách
Một việc được thêm vào hoặc chậm một chút sẽ không làm mọi người ngạc nhiên nếu tổng thể vẫn đang tiến gần
Cả hai ta đều biết triển khai thực tế là một cửa ải lớn, nhưng không cần nói với họ cho đến khi sẵn sàng
Trễ tiến độ khiến ban quản lý bất an, điều đó dễ hiểu, nhưng họp nhiều hơn không làm nó nhanh lên
PM kiểm tra 30 phút mỗi ngày và nói “tôi sẽ hỗ trợ và cung cấp những gì cần thiết để đưa dự án trở lại đúng hướng” không giúp ích gì
Thứ cần thiết chỉ là ít họp hơn
Chướng ngại duy nhất là thời gian, và lý do thời gian trở thành chướng ngại ngay từ đầu cũng là vì cấp trên đã khăng khăng với lịch trình phi thực tế
Rốt cuộc, bằng cách thể hiện rằng họ không tin lập trình viên, họ cũng đang không tin vào năng lực quản lý của chính mình trong việc tuyển đúng lập trình viên
Họ đang làm rất tệ một phần cốt lõi trong công việc của mình
Một dự án kéo dài 1 năm không nên ở trạng thái nhị phân hoàn thành/chưa hoàn thành
Cần có chỉ số tiến độ có thể xử lý được
Lãnh đạo cấp cao nhất không cần phải có kỹ thuật, nhưng ở đâu đó trong hệ thống cấp bậc nhất định phải có người có thể dịch tiến độ sang một định dạng dễ hiểu
Có hai điều biết chắc về nhà cung cấp này khiến khó mà tha thứ
Một là họ đã khiến logic cốt lõi phụ thuộc vào việc phình to bản ghi Mongo vô hạn, và điều còn lại là nếu ba người chỉ nhỉnh hơn mức trung bình một chút cố ý nỗ lực thì có thể thay thế nó trong khoảng 3 tháng
Việc nhà cung cấp đó đạt đến trạng thái giao dịch với khách hàng Fortune 500 cho thấy các tổ chức tương tự khách hàng này cảm thấy bất lực đến mức nào trước cả những công việc phần mềm không quá lớn
Thực ra phạm vi dự án đó trông như thứ mà vài người ở đây cũng có thể làm như một dự án sở thích
Vì vậy cũng dễ hiểu vì sao Retool được các lãnh đạo kỹ thuật ưa chuộng nhưng chưa chắc được các kỹ sư thích
Tôi tò mò không biết có cách tiếp cận sản phẩm nào khác để lấp khoảng cách tương tự không
Nhờ bảng tính, bất cứ ai ở cấp thấp trong tổ chức cũng có thể tạo một nguyên mẫu công cụ thô sơ nhưng gần như chạy được trong vài ngày mà không phải làm việc với người khác trong tổ chức
Trước bảng tính, bạn phải thuyết phục cấp trên để bộ phận IT nhận yêu cầu, và chỉ riêng quá trình đó đã mất ít nhất 3 tháng
Sau đó còn phải đợi thêm vài quý nữa mới nhận được một bản triển khai thô sơ, gần như chạy được, viết bằng thứ như Cobol hay C nhưng không khớp với yêu cầu
Vài lập trình viên và vài nhân viên hỗ trợ đã đi gặp người dùng, còn các lập trình viên thì đã dành 6 tháng để xây dựng một công cụ mới nhằm giải quyết một vấn đề lớn
Nhưng hôm đó lại là lần đầu tiên người dùng cuối được thấy nó
Không lâu sau, chúng tôi đang vượt qua ranh giới tiểu bang để quay về, còn các lập trình viên thì cụp đuôi
Theo tôi biết, dự án đó không bao giờ được ai nhắc đến nữa
Kiểu giao hết việc cho nhân viên mới làm rồi tính phí theo đơn giá giờ của lập trình viên cấp cao
Tôi ước mọi người ngừng dùng ảnh header do AI tạo
Nó làm mất tập trung ngay từ đầu
Đó là code ở phía sau màn hình à?
Và cả trên lưng ghế phía sau cũng có code nữa sao? Hay người đang ngồi là một chiếc iPad khổng lồ?
Nếu dùng ảnh AI thì ít nhất cũng nên cố để nó không trông hoàn toàn kỳ quái và điên rồ
Những hình kiểu này đúng nghĩa chỉ mất vài giây để tạo, vậy đây là tấm đẹp nhất trong số đã chọn sao?