“Làm; hoặc không. Đừng có cố gắng.” – Yoda
Vào đầu những năm 70, tôi và hai người bạn cũ 19 tuổi của tôi đang làm việc trong một hệ thống kế toán thời gian thực của hiệp hội những tài xế xe tải Teamster ở Chicago cho một công ty tên là ASC.
Hệ thống của chúng tôi đã được ấn định đi vào hoạt động vào một ngày nhất định. Dự án đó đã sử dụng rất nhiều tiền tính tới ngày hôm đó. Đội của tôi đã phải làm việc 60-, 70-, và 80-giờ một tuần để cố gắng cho kịp được lịch trình đó.
Một tuần trước thời hạn đưa hệ thống vào hoạt động, chúng tôi cuối cùng đã kết nối hết hệ thống lại với nhau. Có rất nhiều bug và vấn đề phải xử lý, và chúng tôi đã làm việc điên cuồng với cái danh sách đó. Khi đó chỉ có mỗi thời gian ăn và ngủ, để một mình suy nghĩ.
Frank, người quản lý của ASC là một đại tá không lực Hoa Kỳ đã nghỉ hưu. Ông ấy là kiểu quản lý quát vỗ vào mặt nhân viên. Đó là cách làm việc của ông ấy, và ông ấy đặt bạn lên đường cao tốc bằng cách thả bạn rơi tự do từ độ cao 10.000 feet mà không có dù. Chúng tôi khi ấy 19 tuổi, cũng không dám nhìn thẳng vào mắt ông ấy.
Frank nói rằng dự án đó phải hoàn thành đúng thời hạn. Đó là tất cả điều chúng tôi cần làm. Hạn chót đến và chúng tôi sẽ phải hoàn thành. Không thảo luận gì cả. Chấm hết và đi ra.
Ông chủ của tôi, Bill, là một người dễ chịu. Ông ấy đã làm việc với Frank được vài năm rồi và đã hiểu Frank có thể làm được điều gì, và không làm được điều gì. Ông ấy nói với chúng tôi rằng dù thế nào đi nữa chúng tôi phải đưa hệ thống vào hoạt động theo ngày đã định.
Vì vậy chúng tôi buộc phải đưa hệ thống vào hoạt động vào ngày hôm đó. Và đó là một thảm họa đau lòng.
Hệ thống có hàng tá những thiết bị đầu cuối truyền dữ liệu một chiều với tốc độ 300 baud, chúng kết nối trụ sở chính của Teamster ở Chicago tới các cỗ máy của chúng tôi nằm cách 30 dặm về phía bắc ở khu ngoại ô. Tuy nhiên, các thiết bị đầu cuối đã bị nghẽn lại cứ sau mỗi 30 phút. Chúng tôi đã nhìn thấy vấn đề này trước nhưng đã không thử mô phỏng lượng dữ liệu lưu thông mà những người thư ký nhập dữ liệu của hiệp hội đã đột nhiên giội bom vào hệ thống của chúng tôi.
Tình hình còn tồi tệ hơn khi các trang giấy được in từ máy điện báo đánh chữ ASR35 được kết nối với hệ thống của chúng tôi qua đường điện thoại tốc độ 110 baud cũng bị đơ khi in nửa chừng.
Giải pháp để khỏi bị đơ là phải khởi động lại. Vì vậy họ phải để cho những người đang làm việc ở thiết bị đầu cuối còn hoạt động hoàn thành nốt công việc và sau đó mới dừng lại được. Khi mọi người đã dừng thì họ gọi cho chúng tôi để khởi động lại. Những người làm trên thiết bị đầu cuối bị đơ thì phải làm lại công việc từ đầu. Và điều này xảy ra nhiều hơn một lần mỗi giờ.
Sau nửa ngày xảy ra vấn đề, người quản lý văn phòng của Teamster nói với chúng tôi đóng hệ thống đó và đừng bật lại cho đến khi chúng tôi làm cho nó hoạt động trơn tru. Trong lúc đó, họ đã mất nửa ngày làm việc và phải nhập lại toàn bộ dữ liệu đó bằng hệ thống cũ.
Chúng tôi đã nghe thấy Frank ca thán và gầm lên trong cả tòa nhà. Chúng đã tiếp tục diễn ra trong một khoảng thời gian rất rất dài. Sau đó Bill, và người phân tích hệ thống của chúng tôi Jalil, tới gặp chúng tôi và hỏi xem khi nào thì chúng tôi có thể làm cho hệ thống hoạt động ổn định được. Tôi đã nói là “bốn tuần”.
Biểu cảm trên khuôn mặt họ lúc đó thật đáng sợ và sau đó họ quyết định “Không, nó bắt buộc phải chạy vào ngày thứ Sáu.”
Vì vậy tôi nói, “Các anh hãy nhìn xem, chúng tôi mới chỉ vận hành thử hệ thống này vào tuần trước. Chúng tôi cần phải giải quyết hết các lỗi và vấn đề. Chúng tôi cần bốn tuần.”
Nhưng Bill và Jalil rất cứng rắn. “Không được, chắc chắn phải là vào thứ Sáu. Các anh ít nhất phải thử đã chứ?”
Sau đó trưởng nhóm của chúng tôi đã nói, “OK, chúng tôi sẽ thử.”
Thứ Sáu là một lựa chọn tốt, lưu lượng thông tin vào cuối tuần thấp hơn nhiều so với ngày thường. Chúng tôi có thể tìm được nhiều vấn đề hơn và sửa lỗi chúng trước khi thứ Hai tới. Ngay cả như vậy, gần như toàn bộ vấn đề lại xuất hiện lần nữa. Các vấn đề treo đơ tiếp tục xảy ra một hoặc hai lần một ngày. Ngoài ra còn xuất hiện cả những vấn đề khác nữa. Nhưng dần dần, một vài tuần sau, chúng tôi đã đưa được hệ thống tới điểm mà không còn phàn nàn nào nữa, và cuộc sống lại trở lại bình thường.
Và sau đó, như tôi đã nói với bạn ở phần giới thiệu, tất cả chúng tôi đều nghỉ việc. Và bọn họ đã có một nguy cơ khủng hoảng thực sự nằm trên tay. Họ phải thuê một nhóm các lập trình viên mới để cố gắng xử lý một lượng khổng lồ các vấn đề đưa ra từ các khách hàng.
Chúng tôi có thể trách ai trong sự sụp đổ này? Rõ ràng, phong cách quản lý của Frank là một phần của vấn đề. Sự hăm dọa của ông ấy làm cho ông ấy khó có thể lắng nghe được sự thật. Đáng lẽ Bill và Jalil cần phải thúc vào sau Frank mạnh hơn nữa. Đáng lẽ trưởng nhóm của tôi không nên chiều theo yêu cầu xử lý hết trong ngày thứ Sáu. Và đáng lẽ tôi nên lên tiếng nói “không” thay vì chỉ đứng đằng sau trưởng nhóm của chúng tôi.
Những người chuyên nghiệp dám nói sự thật với những người có quyền lực. Những người chuyên nghiệp có đủ can đảm để nói “không” với người quản lý của họ.
Bạn nói “không” với sếp bạn như thế nào? Dù gì đi nữa thì ông ta vẫn là sếp của bạn! Bạn không làm theo những gì sếp bạn nói ư?
Không. Không nếu bạn là một người chuyên nghiệp.
Những người nô lệ không được phép nói “không”. Những người lao động có thể do dự khi nói “không”. Nhưng những người chuyên nghiệp được mong đợi sẽ nói “không”. Quả thực là những người quản lý tốt khao khát ai đó sẽ nói “không” với họ. Đó là cách duy nhất mà bạn có thể thực sự hoàn thành bất cứ công việc nào.
Vai trò phản kháng
Một trong những người soát lại cuốn sách này thực sự ghét chương này. Anh ấy nói rằng nó khiến cho anh ấy gần như muốn đặt cuốn sách xuống. Anh ấy đã xây dựng các nhóm mà không có bất cứ một mối quan hệ phản kháng nào; các nhóm đó làm việc với nhau nhịp nhàng mà không có bất cứ đối đầu nào.
Tôi lấy làm hạnh phúc thay cho anh ấy, nhưng tôi băn khoăn các nhóm của anh ấy có thực sự không hề có sự đối đầu nào như anh mong muốn không. Và nếu họ thực sự như vậy, thì tôi lại băn khoăn họ có hoạt động hiệu quả như họ cần phải như vậy không. Kinh nghiệm cá nhân tôi đã chỉ ra rằng những quyết định khó khăn tốt nhất được đưa ra từ những cuộc đối đầu giữa hai bên tranh luận nhau.
Quản lý là những người có một công việc để làm, và phần lớn những người quản lý biết cách làm công việc đó tương đối tốt. Một phần của công việc đó là theo đuổi và bảo vệ những mục tiêu của họ càng quyết liệt càng tốt.
Tương tự như vậy, những lập trình viên cũng là những người với một công việc để làm, và phần lớn họ đều biết cách hoàn thành công việc của họ tương đối tốt. Nếu họ là những người chuyên nghiệp thì họ sẽ theo đuổi và bảo vệ mục tiêu của họ càng quyết liệt càng tốt.
Khi người quản lý nói với bạn là trang đăng nhập phải được sẵn sàng vào ngày mai, ông ấy đang theo đuổi và bảo vệ một trong những mục tiêu của mình. Ông ấy đang làm công việc của mình. Nếu bạn hoàn toàn biết rõ rằng việc hoàn thành trang đăng nhập vào ngày mai là điều không thể, thì nếu bạn nói “OK, tôi sẽ cố gắng.” nghĩa là bạn đang không thực hiện công việc của mình. Cách duy nhất để thực hiện công việc của bạn tại thời điểm đó, là nói “Không, điều đó là điều không thể.”
Nhưng như vậy nghĩa là bạn không phải làm theo những gì người quản lý nói ư? Không, người quản lý sẽ xem xét dựa theo cách bạn bảo vệ quan điểm của mình quyết liệt như ông ấy bảo vệ quan điểm của mình. Đó chính là cách mà sẽ đưa ra được kết quả khả dĩ tốt nhất.
Kết quả khả dĩ tốt nhất là cái đích mà bạn và người quản lý của bạn cùng chia sẻ. Thủ thuật ở đây là phải tìm được cái đích đó, và thông thường thì nó sẽ được tìm thấy thông qua thương lượng.
Thương lượng đôi khi có thể dễ chịu.
Mike: “Paula, tôi cần trang đăng nhập hoàn thành vào ngày mai.”
Paula: “Ồ, wow! Sớm vậy ư? Được, OK, tôi sẽ cố gắng.”
Mike: “OK, tuyệt. Cảm ơn cậu!”
Đó là một cuộc đối thoại ngắn dễ thương. Tránh phải đối đầu. Cả hai bên rời đi với nụ cười. Hay đấy.
Nhưng cả hai bên đang cư xử không chuyên nghiệp. Paula biết rõ rằng trang đăng nhập sẽ mất nhiều thời gian hơn để hoàn thành, vì vậy cô ấy chỉ đang nói dối thôi. Cô ấy có thể không nghĩ như vậy là một lời nói dối. Có lẽ cô ấy đã nghĩ cô ấy thực sự sẽ cố gắng, và có thể cô ấy đang giữ một hy vọng nhỏ nhoi rằng cô ấy sẽ thực sự hoàn thành công việc đúng hạn. Nhưng cuối cùng, nó vẫn là một lời nói dối.
Mike, mặt khác, đã chấp nhận câu trả lời “Tôi sẽ cố gắng” tương đương với “Được”. Điều đó thật sự là một điều ngu ngốc. Anh ấy nên biết rằng Paula đang cố gắng tránh phải đối đầu, vì vậy anh ấy nên tạo thêm áp lực bằng cách nói, “Cậu có vẻ do dự nhỉ. Cậu có chắc cậu có thể hoàn thành vào ngày mai không?”
Đây là một cuộc đối thoại dễ chịu khác.
Mike: “Paula, tôi cần trang đăng nhập hoàn thành vào ngày mai.”
Paula: “Ô, xin lỗi Mike, nhưng cần nhiều thời gian hơn thế để tôi có thể hoàn thành được.”
Mike: “Cậu nghĩ khi nào cậu có thể hoàn thành nó?”
Paula: “Khoảng hai tuần tính từ bây giờ được không?”
Mike: (viết nguệch ngoạc cái gì đó trong lịch làm việc của anh ấy) “OK, cảm ơn.”
Nếu dễ chịu như vậy thì nó cũng cực kỳ tệ hại và hoàn toàn không chuyên nghiệp. Cả hai bên đều thất bại trong việc tìm ra được giải pháp khả dĩ tốt nhất. Thay vì hỏi xem hai tuần có được không, thì Paula nên quả quyết hơn: “Tôi sẽ phải mất hai tuần đấy Mike.”
Mike, mặt khác, chỉ chấp nhận ngày hẹn đó mà không có thêm câu hỏi nào, mặc dù mục tiêu của anh ấy không đạt được. Ai đó sẽ băn khoăn liệu anh ấy có đơn giản là báo cáo lại cho sếp của mình rằng bản demo cho khách hàng sẽ phải hoãn lại bởi vì Paula không. Hành động kiên quyết thụ động như vậy cũng thật là đáng quở trách.
Trong tất cả các trường hợp này, không bên nào theo đuổi một đích đến chung chấp nhận được. Không bên nào cố gắng tìm được kết quả khả dĩ tốt nhất. Chúng ta hãy thử xem đoạn dưới.
Mike: “Paula, tôi cần trang đăng nhập hoàn thành vào ngày mai.”
Paula: “Không, Mike, công việc đó cần hai tuần.”
Mike: “Hai tuần ư? Các kiến trúc sư hệ thống đã ước lượng nó chỉ mất có ba ngày mà bây giờ đã mất tới năm ngày rồi!”
Paula: “Họ tính nhầm đấy Mike. Họ đã ước lượng trước khi nhận được các yêu cầu của hệ thống. Tôi có ít nhất hơn mười ngày công để làm việc này. Cậu không nhìn bản cập nhật ước lượng của tôi trên wiki ư?”
Mike: (trông nghiêm trọng và đang run lên bởi thất vọng) “Điều này không thể chấp nhận được Paula. Các khách hàng sẽ tới vào ngày mai để xem demo, và tôi phải cho họ thấy trang đăng nhập này hoạt động. “
Paula: “Phần nào của trang đăng nhập mà cậu cần chạy ngày mai?
Mike: “Tôi cần trang đăng nhập? Tôi cần có thể đăng nhập được. “
Paula: “Mike, tôi có thể đưa cho cậu một bản mock-up[1] của trang đăng nhập, nó sẽ cho phép cậu có thể đăng nhập được. Hiện tại tôi đã làm nó hoạt động được rồi. Nhưng nó không kiểm tra tên người dùng và mật khẩu của cậu, và nó cũng sẽ không gửi mail mật khẩu bị quên tới cậu được. Nó sẽ không có banner tin tức của công ty “Times-squaring” ở phần đầu trang, nút “trợ giúp” và hiệu ứng chữ cũng chưa hoạt động. Nó cũng không lưu trữ cookie để nhớ thông tin đăng nhập cho lần kế tiếp, và nó cũng không đặt bất cứ giới hạn quyền nào của cậu. Nhưng cậu sẽ có thể đăng nhập được. Thế được chứ?”
Mike: “Tôi sẽ có thể đăng nhập được ư?”
Paula: “Đúng, cậu sẽ có thể đăng nhập được.”
Mike: “Điều đó thật tuyệt Paula, cậu đúng là vị cứu tinh!” (đi ra nhẹ nhõm và nói “Được!”)
Họ đã đạt được kết quả khả dĩ tốt nhất. Họ đã làm được điều này bằng cách nói không và sau đó tìm ra một giải pháp mà cả hai bên đều cùng đồng ý. Họ đã cư xử như những người chuyên nghiệp. Cuộc đối thoại có một chút đối kháng, và có một vài thời điểm không dễ chịu, nhưng điều đó là tất yếu khi cả hai người đều kiên quyết theo đuổi các mục tiêu của mình mà chúng thì lại không ăn khớp nhau một cách hoàn hảo.
Thế còn giải thích Tại sao?
Có thể bạn nghĩ rằng Paula nên giải thích tại sao trang đăng nhập cần mất nhiều thời gian như vậy. Kinh nghiệm của tôi là giải thích tại sao ít quan trọng hơn nhiều so với điều thực tế. Thực tế là trang đăng nhập sẽ cần hai tuần để hoàn thành. Tại sao nó lại cần tới hai tuần thì chỉ là vấn đề chi tiết.
Thực vậy, biết được lý do tại sao có thể giúp Mike hiểu, và do đó sẽ chấp nhận điều thực tế. Đủ công bằng. Trong tình huống mà Mike có khả năng kỹ thuật và sẵn lòng để hiểu thì việc giải thích này là hữu ích. Ngược lại, Mike có thể không đồng ý với kết luận đó. Mike có thể quyết định rằng tất cả điều Paula đang làm là sai. Anh ấy có thể nói rằng cô ấy không cần phải thực hiện tất cả những bài kiểm tra đó, hoặc không cần phải soát lại, hoặc rằng bước 12 có thể bỏ qua. Cung cấp quá nhiều chi tiết có thể là một gợi ý để người quản lý đi quá sâu vào chi tiết.
Mức đe dọa cao
Thời điểm quan trọng nhất để nói không là khi mức đe dọa đang ở mức cao nhất. Mức đe dọa càng cao, thì từ “không” càng trở nên có giá trị.
Điều này thật hiển nhiên. Khi cái giá của sự thất bại cao tới mức sự sinh tồn của công ty phụ thuộc vào nó, thì bạn phải tuyệt đối xác định là sẽ phải đưa cho người quản lý của bạn thông tin tốt nhất mà bạn có thể. Và điều đó thường có nghĩa là nói “không”.
Don (Giám đốc Phát triển): “Hiện giờ chúng tôi ước lượng để hoàn thành dự án Golden Goose cần 12 tuần tính từ ngày hôm nay, với sai lệch cộng hoặc trừ 5 tuần.”
Charles (CEO): (ngồi nhìn chằm chằm 15 giây với khuôn mặt đỏ gay) “Cậu ngồi đây và nói với tôi rằng chúng ta có thể cần tới 17 tuần để chuyển hàng được ư?”
Don: “Đúng vậy, như vậy mới khả thi.”
Charles: (đứng dậy, Don đứng dậy một giây sau đó) “Mẹ kiếp Don! Cái này đáng ra phải làm xong 3 tuần trước rồi! Ngày nào tôi cũng bị Galitron gọi hỏi cái hệ thống quái quỷ của họ làm đến đâu rồi. Tôi sẽ không nói với họ rằng họ sẽ phải đợi 4 tháng nữa đâu. Cậu làm thế nào thì làm.”
Don: Chuck, tôi đã nói với ông điều này 3 tháng trước rồi, sau khi tất cả thay đổi, chúng ta cần hơn 4 tháng nữa để thực hiện. Christ Chunk, ý tôi là ông đã cắt giảm 20% nhân sự đội của tôi đấy! Ông có nói với Galitron là chúng ta sẽ trễ không?”
Charles: “Cậu thừa biết là tôi không nói mà. Chúng ta không thể chịu được tổn thất khi mất hợp đồng đó đâu Don. (Charles dừng lại, khuôn mặt anh ta trắng bệch) Không có Galitron, chúng ta sẽ thực sự tiêu. Cậu biết điều đó không? Và bây giờ nếu như chậm trễ như thế này, thì tôi sợ rằng… Tôi sẽ phải nói với ban giám đốc thế nào đây? (Ông ta từ từ ngồi xuống ghế, cố gắng không suy sụp.) Don, cậu nhất định phải làm tốt hơn.”
Don: “Tôi không thể làm được gì Chuck. Chúng ta đã nói về vấn đề này rồi. Galitron sẽ không giảm bớt phạm vi dự án, và họ sẽ không chấp nhận bất cứ một phiên bản tạm thời nào. Điều họ muốn là chỉ phải cài đặt chương trình này một lần và hoàn thành. Tôi không thể đơn giản là làm nhanh hơn được. Điều đó không thể được.”
Charles: “Mẹ kiếp. Tôi không thấy vấn đề gì nếu tôi nói cho cậu biết công việc của cậu đang bị đe dọa đấy.”
Don: “Đuổi việc tôi thì cũng sẽ không thay đổi được ước lượng đấy đâu, Charles.”
Charles: “Chúng ta dừng ở đây nhé. Hãy đi về với đội của cậu và tiếp tục dự án này đi. Tôi có thể sẽ phải thực hiện một cuộc điện thoại khó khăn đây.”
Dĩ nhiên, Charles nên nói với Galitron là “không” ba tháng trước rồi, khi anh ta lần đầu tiên biết về thời gian ước lượng mới này. Ít nhất thì bây giờ anh ta đang thực hiện điều đúng đắn bằng cách gọi cho họ (và ban giám đốc). Nhưng nếu Don không làm kẹt khẩu súng của anh ta thì những cuộc gọi đó sẽ có thể còn chậm trễ lâu hơn nữa.
Làm một “team player”
Tất cả chúng ta đã nghe về việc làm một “team player[2]” quan trọng như thế nào. Trở thành một team player nghĩa là bạn phải chơi vị trí của mình tốt nhất có thể, và giúp đỡ những đồng đội của bạn khi họ đang bị mắc kẹt. Một team player sẽ giao tiếp thường xuyên, theo dõi đồng đội của mình, và thực hiện trách nhiệm của mình tốt nhất có thể.
Một team player không phải là người lúc nào cũng nói “có”. Hãy xem tình huống sau:
Paula: “Mike, tôi có ước lượng này dành cho cậu. Đội của chúng ta đã đồng ý là chúng ta sẽ sẵn sàng đưa bản demo trong khoảng 8 tuần nữa, có thể sai lệch một tuần.”
Mike: “Paula, chúng ta đã lập kế hoạch cho bản demo tính từ giờ là 6 tuần nữa rồi.”
Paula: “Cậu không nghe chúng tôi ư? Thôi nào Mike, cậu không thể ép chúng tôi.”
Mike: “Đã định vậy rồi mà.”
Paula: (thở dài) “OK, nhìn đây, tôi sẽ trở về đội và xem chúng tôi có thể an toàn chuyển giao những gì trong 6 tuần nữa không, nhưng nó sẽ không phải là toàn bộ hệ thống. Sẽ có một vài chức năng bị thiếu, và việc nạp dữ liệu sẽ không hoàn thiện được.”
Mike: “Paula, khách hàng đang mong muốn nhìn thấy một bản demo hoàn chỉnh.”
Paula: “Điều đó sẽ không thực hiện được đâu Mike.”
Mike: “Khốn kiếp. Được rồi, hãy làm theo kế hoạch tốt nhất mà cô có thể và cho tôi biết vào ngày mai.”
Paula: “Tôi có thể làm được điều đó.”
Mike: “Không có cách nào mà cô có thể làm để theo được thời hạn đó ư? Có thể là một cách làm việc thông minh hơn và sáng tạo hơn chẳng hạn.”
Paula: “Tất cả chúng tôi đã khá sáng tạo rồi Mike. Chúng tôi đã có những cách xử lý tốt các vấn đề, và thời hạn để hoàn thành vẫn sẽ phải là 8 hoặc 9 tuần, không thể là 6 tuần được.”
Mike: “Cô có thể làm thêm.”
Paula: “Điều đó chỉ làm chúng tôi làm chậm hơn thôi Mike. Anh có nhớ cái đống chúng tôi đã làm lần trước khi mà chúng tôi được yêu cầu phải làm thêm giờ không?”
Mike: “Có chứ, nhưng lần này sẽ không như thế.”
Paula: “Nó sẽ chỉ như lần trước thôi Mike. Tin tôi đi. Chắn chắn sẽ phải cần 8 hoặc 9 tuần, không phải là 6.”
Mike: “Được rồi, hãy đưa cho tôi kế hoạch tốt nhất của cô, nhưng hãy vẫn suy nghĩ về việc làm thế nào để hoàn thành trong 6 tuần nhé. Tôi biết cô sẽ tìm được cách. “
Paula: “Không, Mike, chúng tôi không thể. Tôi sẽ đưa cho anh bản kế hoạch trong 6 tuần, nhưng nó sẽ thiếu rất nhiều chức năng và dữ liệu. Đó là cách duy nhất rồi.”
Mike: “Được rồi, Paula, nhưng tôi cá nhóm của cô có thể làm nên điều kỳ diệu nếu cố gắng.”
(Paula đi ra lắc đầu.)
Sau đó, trong buổi họp chiến lược của các Giám đốc…
Don: “Được rồi Mike, như anh biết khách hàng sẽ tới xem buổi demo trong 6 tuần nữa. Họ đang mong muốn nhìn thấy mọi thứ hoạt động.”
Mike: “Vâng, chúng tôi sẽ sẵn sàng. Đội của tôi đang chạy vắt chân lên cổ với dự án này và chúng tôi sẽ hoàn thành được nó. Chúng tôi sẽ phải làm thêm giờ, và sáng tạo hơn nữa, nhưng chúng tôi sẽ thực hiện được điều này!”
Don: “Thật là tuyệt khi chúng tôi có những team player như cậu và đội của cậu.”
Ai mới thực sự là team player trong trường hợp này? Paula đang chơi hết mình cho đội bởi vì cô ấy đã nói ra những gì có thể, và những gì không thể, hoàn thành tốt nhất khả năng của mình. Cô ấy kiên quyết bảo vệ vị trí của mình, mặc cho lời dỗ dành và tán tỉnh của Mike. Mike thì rõ ràng đang chơi trong một đội chỉ có một người. Mike chơi vì Mike. Anh ta rõ ràng không phải ở đội của Paula bởi vì anh ta đã cam kết những điều mà Paula nói rõ là cô ấy không thể thực hiện được. Anh ta cũng không phải người đội của Don (mặc dù anh ta sẽ không đồng ý như vậy) bởi vì anh ta chỉ dùng miệng lưỡi để nói dối mà thôi.
Vậy tại sao Mike lại làm điều này? Anh ta đã muốn Don xem mình như là một team player, và anh ta có niềm tin vào khả năng dỗ dành và thuyết phục Paula trong việc cố gắng hoàn thành theo deadline 6 tuần. Mike không phải là kẻ ác, anh ta chỉ quá tự tin vào khả năng điều khiển mọi người làm theo những gì anh ta muốn mà thôi.
Cố gắng
Điều tệ nhất mà Paula có thể làm khi đáp lại lời chỉ thị của Mike là nói “Được rồi, chúng tôi sẽ cố gắng.” Tôi ghét phải dẫn lời của Yoda ở đây, nhưng trong trường hợp này thì ông ấy đúng. Đừng có cố gắng.
Có lẽ bạn không thích cái ý kiến này? Có lẽ bạn nghĩ rằng việc cố gắng là một thứ tích cực để làm. Sau cùng, liệu Columbus có khám phá ra châu Mỹ nếu ông ấy không cố gắng không?
Từ cố gắng có nhiều định nghĩa. Định nghĩa của từ cố gắng tôi đưa ra ở đây là “thực hiện một nỗ lực thêm.” Nỗ lực thêm nào mà Paula sẽ thực hiện để làm cho bản demo sẵn sàng đúng thời hạn? Nếu có nỗ lực thêm nào mà cô ấy có thể thực hiện, thì nghĩa là trước đây cô ấy và đội của mình chắc hẳn đã không thực hiện với tất cả nỗ lực. Họ chắc hẳn đang giữ một chút nỗ lực nào đó để dự phòng.
Lời hứa cố gắng là một sự thừa nhận rằng bạn đang giữ sức, rằng bạn có một lượng nỗ lực thêm dự phòng nào đó mà bạn vẫn có thể dùng. Lời hứa cố gắng là một sự thừa nhận rằng mục tiêu có thể đạt được bằng việc thực hiện thêm nỗ lực này; hơn nữa, đó là một lời cam kết sẽ thực hiện nỗ lực thêm đó để đạt được mục tiêu. Do đó, bằng cách hứa sẽ cố gắng bạn đang cam kết sẽ thành công. Điều này sẽ đặt gánh nặng lên vai bạn. Nếu “sự cố gắng” của bạn không dẫn tới kết quả mong muốn, bạn sẽ coi như là bị thất bại.
Bạn có năng lượng dự phòng thêm nào mà bạn đang giữ không? Nếu bạn dùng những nguồn dự phòng này, bạn sẽ có thể đạt được mục tiêu chứ? Hoặc, với việc hứa sẽ cố gắng, có phải bạn đang đặt bản thân mình vào khả năng thất bại không?
Bằng việc hứa sẽ cố gắng, bạn đang hứa sẽ thay đổi kế hoạch của bạn. Sau cùng thì các kế hoạch bạn đã đưa ra là không đủ. Bằng việc hứa sẽ cố gắng, bạn đang nói rằng bạn có một kế hoạch mới. Kế hoạch mới là gì? Bạn sẽ làm thay đổi cái gì tới hoạt động của mình? Bạn sẽ làm điều gì khác biệt khi bây giờ bạn “đang cố gắng”?
Nếu bạn không có một kế hoạch mới, nếu bạn không tạo ra một thay đổi trong hoạt động của mình, và nếu bạn làm mọi thứ chính xác như khi bạn làm trước khi bạn hứa “cố gắng” thì như vậy “cố gắng” có ý nghĩa là gì?
Nếu bạn không phải đang giữ chút năng lượng nào đó để dự phòng, nếu bạn không có một kế hoạch mới, nếu bạn không thay đổi hoạt động của mình, và nếu bạn khá tự tin vào ước lượng ban đầu của mình, thì về căn bản hứa sẽ cố gắng là một sự không thành thật. Bạn đang nói dối. Và bạn có thể đang làm như vậy để giữ thể diện và tránh phải đối đầu.
Cách xử lý của Paula tốt hơn nhiều. Cô ấy liên tục nhắc cho Mike là ước lượng của đội đưa ra là không chắc chắn. Cô ấy luôn nói “8 hoặc 9 tuần.” Cô ấy nhấn mạnh sự không chắc chắn và không bao giờ thay đổi. Cô ấy không bao giờ đề nghị là sẽ nỗ lực thêm, hay có một kế hoạch mới, hay một vài thay đổi trong hoạt động để có thể giảm thiểu được sự không chắc chắn đó.
Ba tuần sau…
Mike:” Paula, còn 3 tuần nữa là tới buổi demo, và các khách hàng đang yêu cầu trông thấy chức năng FILE UPLOAD hoạt động.”
Paula: “Mike, chức năng đó không nằm trong danh sách những chức năng mà chúng ta đã thỏa thuận.”
Mike: “Tôi biết, nhưng họ đang yêu cầu nó.”
Paula: “Được rồi, điều đó có nghĩa là hoặc là chức năng SINGLE SIGN-ON hoặc là BACKUP sẽ phải bỏ khỏi buổi demo thôi.”
Mike: “Chắc chắn là không như vậy! Họ cũng mong muốn trông thấy các chức năng đó hoạt động tốt mà.”
Paula: “Vậy là họ đang muốn trông thấy mọi chức năng đều hoạt động. Đó là cái mà anh đang muốn nói với tôi ư? Tôi đã nói là điều đó sẽ không xảy ra được.”
Mike: “Xin lỗi Paula, nhưng khách hàng sẽ không thay đổi điều này. Họ muốn trông thấy tất cả.”
Paula: “Điều đó sẽ không xảy ra được Mike. Chỉ là không thể làm được.”
Mike: “Thôi nào Paula, cô không thể ít nhất là cố gắng ư?”
Paula: “Mike, tôi có thể cố gắng bay lên, tôi có thể cố gắng biến chì thành vàng. Tôi có thể cố gắng bơi vượt biển Đại Tây Dương. Anh có nghĩ tôi sẽ thành công không?”
Mike: “Bây giờ cô đang nói vô lý. Tôi không phải đề nghị việc không thể.”
Paula: “Vâng, nhưng anh đang làm vậy đấy.”
(Mike cười nhệch, gật đầu, và quay đầu bước đi.)
Mike: “Tôi có niềm tin vào cô Paula; tôi biết rằng cô sẽ không để tôi ngã ngựa đâu.”
Paula: (nói với Mike ở đằng sau) “Mike, anh đang nằm mơ rồi. Điều này sẽ không kết thúc có hậu đâu.”
(Mike chỉ vẫy tay mà không buồn quay đầu lại.)
Cuộc gây hấn thụ động
Paula có một quyết định thú vị để thực hiện. Cô ấy nghi rằng Mike đã không nói cho Don về ước lượng của cô ấy. Cô ấy có thể chỉ việc để cho Mike tự mình rơi xuống vực. Cô ấy có thể đảm bảo rằng bản copy của các bản ghi nhớ thích hợp đều nằm trên hồ sơ lưu trữ, vì vậy khi thảm họa ập tới cô ấy có thể chỉ ra cô ấy đã nói với Mike điều gì, và cô ấy đã nói với anh ta khi nào. Điều này gọi là cuộc gây hấn thụ động. Cô ấy chỉ việc để cho Mike tự vả vào mặt mình.
Hoặc, cô ấy có thể dập tắt thảm họa này bằng cách liên lạc trực tiếp với Don. Điều này nguy hiểm, chắc chắn là vậy, nhưng nó cũng là cách mà một team player cần phải làm. Khi một chuyến tàu chở hàng đang bị trật đường ray, mà chỉ có bạn mới trông thấy, bạn có thể yên lặng nhảy khỏi tàu và nhìn mọi người khác kết thúc cuộc đời, hoặc bạn có thể hô lên “Tàu! Trật đường ray rồi!”
Hai ngày sau…
Paula: “Mike, anh đã nói với Don về ước lượng của tôi chưa? Ông ấy đã nói với khách hàng rằng buổi demo sẽ không có chức năng FILE UPLOAD hoạt động rồi chứ?”
Mike: “Paula, cô đã nói với tôi là cô sẽ làm nó hoạt động mà.”
Paula: “Không, Mike, tôi không hề nói vậy. Tôi đã nói với anh rằng đó là điều không thể. Đây là copy bản ghi nhớ mà tôi đã gửi cho anh sau buổi nói chuyện của chúng ta.”
Mike: “Ừ, nhưng cô không định sẽ cố gắng chút nào, phải không?”
Paula: “Chúng ta đã thảo luận về việc này rồi. Anh vẫn nhớ chứ, vàng và chì?”
Mike: (thở dài) “Nhìn này, Paula, cô phải làm được điều đó. Cô phải làm. Hãy làm bất cứ thứ gì, nhưng cô phải làm bằng được điều này cho tôi.”
Paula: “Mike. Anh sai rồi. Tôi không phải làm bằng được điều này cho anh. Cái tôi phải làm là nói với Don nếu anh không nói.”
Mike: “Điều này là làm vượt cấp đấy, cô không được làm vậy.”
Paula: “Tôi không muốn đâu Mike, nhưng tôi sẽ làm nếu anh buộc tôi phải làm vậy.”
Mike: “Ôi, Paula…”
Paula: “Nhìn này, Mike, chức năng đó sẽ không hoàn thành đúng hạn vào buổi demo. Anh cần ghi nhớ điều này trong đầu. Hãy ngừng cố gắng thuyết phục tôi làm chăm chỉ hơn. Hãy ngừng lừa dối chính mình là bằng cách nào đó tôi sẽ lôi được một con thỏ ra khỏi cái mũ. Hãy đối mặt với thực tế là anh phải nói với Don, và anh phải nói với ông ấy trong hôm nay.”
Mike: (trố mắt) “Hôm nay ư?”
Paula: “Đúng vậy, Mike. Hôm nay. Bởi vì ngày mai tôi muốn có một buổi họp với anh và Don về việc những chức năng nào sẽ có trong buổi demo. Nếu buổi họp đó không thực hiện vào ngày mai, thì tôi sẽ buộc phải tự gặp Don thôi. Đây là copy bản ghi nhớ giải thích điều đó.”
Mike: “Cô chỉ đang che đậy khuyết điểm của mình thôi!”
Paula: “Mike, tôi đang cố gắng che đậy khuyết điểm của cả hai chúng ta. Anh có tưởng tượng được sự khủng khiếp thế nào nếu khách hàng tới đây mong muốn xem bản demo hoàn chỉnh mà chúng ta không thể đưa ra cho họ không?”
Điều gì xảy ra cuối cùng giữa Paula và Mike? Tôi sẽ để cho bạn suy nghĩ tiếp những trường hợp nào có thể xảy ra. Điểm mấu chốt ở đây là Paula đã cư xử rất chuyên nghiệp. Cô ấy luôn nói “không” đúng thời điểm, và đúng cách. Cô ấy nói “không” khi bị ép phải sửa ước lượng kế hoạch của mình. Cô ấy nói “không” khi bị ép buộc, bị dụ dỗ, và bị van nài. Và, điều quan trọng nhất, cô ấy đã nói “không” với sự tự lừa dối bản thân và không hành động gì của Mike. Paula đang chơi hết mình cho đội. Mike cần giúp đỡ, và cô ấy đã dùng mọi cách trong khả năng của mình để giúp anh ta.
Cái giá của việc nói “được”
Phần lớn là chúng ta muốn nói “được”. Thực vậy, các nhóm khỏe mạnh đều phấn đấu tìm cách để nói “được”. Người quản lý và các lập trình viên trong những nhóm hoạt động tốt sẽ đàm phán với nhau cho đến khi họ đi tới một sự nhất trí trong kế hoạch hành động.
Nhưng, như chúng ta đã thấy, đôi khi cách duy nhất để có được từ “được” chính xác thì chúng ta phải không sợ nói từ “không”.
Hãy xem câu chuyện sau mà John Blanco đã đăng trên blog cá nhân của anh. Tôi đưa nó ra ở đây với sự cho phép của anh ấy. Khi bạn đọc nó, hãy hỏi bản thân mình xem khi nào và như thế nào anh ấy nên nói “Không”.
Code đẹp là điều không thể ư?
Khi bạn bước vào tuổi teen, bạn quyết định bạn muốn trở thành một nhà phát triển phần mềm. Trong suốt những năm trung học phổ thông, bạn học cách để viết phần mềm dùng các nguyên lý hướng đối tượng. Khi bạn tốt nghiệp đại học, bạn áp dụng tất cả các nguyên lý mà bạn đã được học vào các lĩnh vực như trí thông minh nhân tạo hoặc đồ họa 3D.
Và khi bạn chạm tới ngưỡng chuyên nghiệp, bạn bắt đầu hành trình không hồi kết để viết code “hoàn hảo”, bảo trì được, chất lượng có thể thương mại hóa được. Chất lượng thương mại ư. Hả. Điều đó khá thú vị.
Tôi cảm thấy bản thân mình may mắn vì tôi yêu design pattern. Tôi thích học các lý thuyết về việc viết code một cách hoàn hảo. Tôi không cảm thấy vấn đề gì khi thảo luận hàng giờ đồng hồ về việc tại sao sự lựa chọn cây kế thừa của đồng nghiệp của tôi là sai – rằng lựa chọn HAS-A tốt hơn lựa chọn IS-A trong rất nhiều trường hợp. Nhưng một số điều đang làm phiền tôi sau này và tôi đang băn khoăn… Liệu code tốt là điều không thể trong môi trường phát triển phần mềm hiện đại?
Đề xuất một dự án điển hình
Với vai trò một lập trình viên hợp đồng toàn thời gian (và bán thời gian), tôi dành cả ngày (và đêm) để phát triển các ứng dụng di động cho các khách hàng. Và điều mà tôi học được qua nhiều năm là việc tôi làm theo yêu cầu của khách hàng đang đẩy dần tôi khỏi việc viết các ứng dụng chất lượng thực sự mà tôi vẫn yêu thích.
Trước khi tôi bắt đầu, hãy để tôi nói rằng điều này không phải là do tôi thiếu cố gắng. Tôi yêu chủ đề code tinh gọn. Tôi không biết có người nào theo đuổi thiết kế phần mềm hoàn hảo như tôi đã làm hay không. Đó là quá trình mà tôi thấy khó có thể lảng tránh được, không phải vì nguyên nhân như bạn nghĩ.
Bây giờ, hãy để tôi kể cho bạn một câu chuyện.
Bước vào cuối năm ngoái, một công ty khá tên tuổi đặt ra một RFP (Request for Proposal – Yêu Cầu Đề Xuất) là xây dựng một ứng dụng cho họ. Họ là một nhà bán lẻ khổng lồ, nhưng để giấu tên chúng ta hãy gọi họ là Gorilla Mart. Họ nói rằng họ cần tạo một chương trình trên iPhone và cần phải tạo cho họ trước ngày Black Friday. Bạn có tin được không? Lúc đó đã là ngày mùng 1 tháng 11. Điều đó có nghĩa là tôi chỉ có ít hơn 4 tuần để tạo ra chương trình đó. Ồ, mà tại thời điểm đó Apple vẫn phải mất hai tuần để cấp phép cho các ứng dụng. (Ah, những ngày xưa đẹp đẽ). Vậy nên, đợi đã, chương trình này phải viết trong… HAI TUẦN?!?!
Vâng. Chúng tôi có hai tuần để viết ứng dụng này. Và, không may thay, chúng tôi đã thắng thầu. (Trong kinh doanh, khách hàng là thượng đế). Điều này sẽ xảy ra.
“Nhưng điều này được mà,” Lãnh đạo Gorilla Mart #1 nói. “Chương trình này rất đơn giản. Nó chỉ cần cho người dùng thấy một vài sản phẩm từ catalog và cho phép họ tìm kiếm vị trí cửa hàng của chúng tôi. Chúng tôi đã làm điều này trên website của chúng tôi rồi. Chúng tôi cũng sẽ chuyển cho các anh các ảnh đồ họa cần thiết nữa. Các anh có thể – từ đó gọi là gì nhỉ – à, hardcode[3] nó!”
Lãnh đạo Gorilla Mart #2 chêm vào. “Và chúng tôi chỉ cần một vài coupon khuyến mãi được hiện ra ở phần thanh toán. Ứng dụng này sẽ chỉ dùng một lần rồi vứt đi. Chúng tôi cần nó hoạt động sớm, và sau đó ở giai đoạn II chúng tôi sẽ làm lại ứng dụng này từ đầu quy mô hơn và tốt hơn.”
Và sau đó điều đó xảy ra. Mặc dù nhiều năm kinh nghiệm đã nhắc nhở chúng tôi rằng mọi chức năng mà khách hàng yêu cầu sẽ luôn luôn phức tạp để viết hơn là lời mô tả nó, chúng tôi vẫn nhận làm. Chúng tôi thực sự tin rằng lần này nó có thể hoàn thành trong hai tuần. Vâng! Chúng tôi có thể thực hiện được điều đó! Lần này sẽ khác! Nó chỉ là một vài hình ảnh đồ họa và một lời gọi dịch vụ để lấy được vị trí cửa hàng. XML! Không khó khăn gì cả. Chúng tôi có thể thực hiện được. Tôi được lên dây cót! Chiến thôi!
Nhưng chỉ cần một ngày là tôi có thể biết được sự thực phũ phàng thế nào.
Tôi: Anh có thể cung cấp cho tôi thông tin cần để tôi có thể gọi được web service[4] lấy thông tin vị trí các cửa hàng của anh được không?
Khách hàng: Web service là cái gì thế?
Tôi: …………….
Và đó chính xác là cách mà nó đã diễn ra. Dịch vụ truy xuất vị trí cửa hàng của họ, tìm thấy ngay tại góc trên bên phải website của họ, không phải là một web service. Nó được tạo ra bởi một đoạn code Java. Và để khởi động lên được, nó được host bởi một cộng sự chiến lược của Gorilla Mart.
Chúng ta hãy bước vào địa hạt phần mềm “hãng thứ 3” hiểm ác.
Trong ngôn ngữ khách hàng, một “hãng thứ 3” cũng gần giống như Angelina Jolie. Mặc dù lời hứa là bạn sẽ có thể có một buổi trò chuyện tuyệt vời trong bữa ăn và hy vọng là sẽ còn gắn kết sau đó nữa… nhưng xin lỗi, nó sẽ không xảy ra như vậy. Bạn chỉ được tưởng tượng về nó trong khi bạn vẫn phải cố gắng đảm bảo công việc kinh doanh của chính bạn.
Trong trường hợp của tôi, chỉ có thứ duy nhất tôi có thể đánh vật với Gorilla Mart là một ảnh chụp danh sách các cửa hàng hiện tại của họ trong một file Excel. Tôi đã phải viết code tìm kiếm vị trí cửa hàng từ đầu.
Một vấn đề nữa tiếp tục đến vào ngày hôm sau: Họ muốn sản phẩm và dữ liệu coupon khuyến mãi có thể thay đổi được hàng tuần. Vậy mà họ đã nói chỉ cần hardcode là được! Hai tuần để viết một ứng dụng iPhone thì bây giờ trở thành hai tuần để vừa viết ứng dụng iPhone, vừa viết một PHP backend, và tích hợp chúng cùng nhau… Cái gì nữa? Họ còn muốn tôi phải thực hiện cả quy trình QA nữa ư?
Để thực hiện được công việc thêm này, việc code sẽ phải thực hiện nhanh hơn một chút. Hãy quên abstract factory[5] đi. Tôi đành phải dùng một vòng lặp siêu to khổng lồ thay vì thiết kế theo design pattern, quả thực là tôi không có thời gian!
Việc code đẹp trở thành điều không thể.
Hai tuần để hoàn thành
Để tôi kể lại với bạn, hai tuần đó thật là khốn khổ. Đầu tiên, hai ngày đã bị mất do những buổi họp cả ngày cho dự án tiếp theo của tôi. (Điều này cho các bạn thấy khung thời gian để thực hiện dự án ngắn như thế nào). Cuối cùng, tôi thực sự chỉ có tám ngày để hoàn thành mọi thứ. Tuần đầu tiên tôi đã làm việc 74 giờ và tuần tiếp theo… Chúa ơi… Tôi không thể nhớ được, hệ thần kinh của tôi đã bị tê liệt. Có lẽ đó cũng là một điều tốt.
Code đó khá tệ và tôi không thể có đủ thời gian để refactor. Hãy xem với khung thời gian như vậy, tuy nhiên, nó thực tế cũng khá sáng sủa, và sau cùng thì code đó cũng sẽ “vứt đi”, đúng không? Điều này bạn nghe có quen không? Đợi một chút, nó cũng tốt hơn đó.
Khi tôi đụng lần cuối vào cái ứng dụng này (lần cuối này là viết toàn bộ code phía máy chủ), tôi đã bắt đầu nhìn lại codebase và suy ngẫm nó có lẽ cũng được đấy. Dù sao thì ứng dụng cũng đã hoàn thành. Tôi đã sống sót!
“Này, chúng tôi vừa thuê Bob, và anh ấy rất bận, anh ấy không thể nghe điện thoại, nhưng anh ấy nói rằng chúng tôi nên yêu cầu người dùng cung cấp địa chỉ email của họ để lấy được coupon. Anh ấy chưa nhìn thấy ứng dụng này nhưng anh ấy nghĩ rằng đó sẽ là một ý tưởng tuyệt vời! Chúng tôi cũng muốn một hệ thống báo cáo để lấy được những email đó từ máy chủ. Hệ thống đó phải đẹp và không quá đắt. (Đợi đã, phần cuối đó là Monty Python[6]). Nói về coupon, chúng cần có thể đặt được số ngày mà sau đó sẽ hết hạn do chúng tôi chỉ định. Ồ, và… “
Chúng ta hãy lùi lại nhé. Chúng ta biết rằng code đẹp là phải như thế nào? Đó là code mà có khả năng mở rộng được. Bảo trì được. Nó có thể dễ dàng sửa đổi. Nó có thể đọc được như một đoạn văn. Nhưng đây lại không phải là code đẹp.
Một điều nữa, nếu bạn muốn trở thành một lập trình viên tốt hơn, bạn phải luôn luôn giữ điều không thể tránh được này trong tâm trí mình: Khách hàng sẽ luôn luôn nới rộng deadline. Họ sẽ luôn luôn muốn nhiều chức năng hơn. Họ sẽ luôn luôn muốn thay đổi sau đó. Và đây là công thức mà tôi đoán được:
(Số Lượng Người Điều Hành)2
+ 2*(Số Lượng Người Điều Hành Mới)
+ (Số Lượng Con Của Bob)
= SỐ NGÀY THÊM VÀO CUỐI CÙNG
Bây giờ, những người điều hành là những người đứng đắn. Tôi nghĩ vậy. Họ làm vì gia đình họ. Họ muốn ứng dụng được thành công (tại thời điểm quảng cáo!). Khi tất cả đã được nói ra và hoàn thành, tất cả họ đều muốn thêm vào các chức năng hoặc thay đổi thiết kế mà họ thấy cần cho họ.
Vì vậy, trở lại câu chuyện, chúng tôi được thêm hơn chục ngày cho dự án đó và hoàn thành xong chức năng email mà khách hàng mong muốn. Và sau đó tôi đổ gục vì kiệt sức.
Các khách hàng không bao giờ quan tâm bạn đã làm như thế nào
Các khách hàng, bất chấp lời cam đoan của họ, bất chấp sự cấp bách rõ ràng của họ, không bao giờ quan tâm bạn làm gì với ứng dụng để có thể hoàn thành đúng thời hạn. Buổi chiều mà tôi sửa sang hoàn thiện ứng dụng, tôi đã gửi một email kèm bản build cuối cùng cho tất cả các bên liên quan, những người điều hành (hừ!), những quản lý .v.v. “NÓ ĐÃ HOÀN THÀNH! TÔI GỬI CHO CÁC ANH PHIÊN BẢN 1.0!” Tôi ấn nút Gửi, dựa lưng vào ghế, và với một nụ cười tự mãn, tôi bắt đầu tưởng tượng công ty sẽ tung hô tôi như thế nào và làm một cuộc diễu hành xuống phố số 42 trong khi tôi được lên ngôi “Lập Trình Viên Vĩ Đại Nhất Mọi Thời Đại.” Ít nhất thì khuôn mặt tôi sẽ trên tất cả các quảng cáo của họ, đúng không nhỉ?
Nhưng buồn cười thay, họ dường như không đồng ý. Thực sự là tôi không chắc họ đã nghĩ gì. Tôi không nghe thấy điều gì cả. Kể cả một tiếng khẽ. Những người ở Gorilla Mart đang gấp rút và đã chuyển chú ý sang thứ tiếp theo rồi.
Bạn có nghĩ tôi nói dối không? Hãy kiểm tra lại điều này. Tôi đã đưa ứng dụng này lên Apple store mà không điền vào phần mô tả ứng dụng. Tôi đã yêu cầu điều này từ Gorilla Mart, và họ đã không trả lời tôi mà tôi thì không còn thời gian để chờ đợi. (Xem đoạn trước.) Tôi đã viết cho họ lần nữa. Và lần nữa. Tôi đã nói cả với vài quản lý của chúng tôi về vấn đề này. Hai lần tôi đã nghe lại và hai lần tôi được nói rằng “Anh lại cần cái gì nhỉ?” TÔI CẦN MÔ TẢ ỨNG DỤNG!
Một tuần sau, Apple đã bắt đầu kiểm tra ứng dụng. Đây thường là thời gian để ăn mừng, nhưng lần này thay vào đó lại là khoảng thời gian kinh hoàng chết chóc. Như đã dự đoán, một ngày sau khi chương trình này bị từ chối, tôi nhận được lời xin lỗi vì đã từ chối ứng dụng nghèo nàn nhất, đáng buồn nhất mà tôi có thể tưởng tượng được: “Ứng dụng thiếu phần mô tả.” Các chức năng hoạt động hoàn hảo, nhưng lại không có mô tả ứng dụng. Và vì lý do này Gorilla Mart đã không có được ứng dụng của họ sẵn sàng cho ngày Black Friday. Tôi đã khá buồn.
Tôi đã hy sinh gia đình của tôi trong hai tuần siêu nước rút, và không ai tại Gorilla Mart quan tâm tới việc đưa ra một mô tả ứng dụng trong suốt thời gian một tuần. Họ đã đưa cho chúng tôi một giờ sau khi bị từ chối – hình như đó là một tín hiệu chấm dứt thương vụ.
Nếu tôi buồn trước đây, thì sau đó tôi trở nên giận tím mặt mất một tuần rưỡi. Các bạn xem, họ vẫn không cung cấp cho chúng tôi dữ liệu thật. Các sản phẩm và coupon trên máy chủ đều là giả. Các bạn có tưởng tượng được không. Mã coupon là 1234567890. Bạn biết đấy, một con số giả mạo vô lý.
Và trong buổi sáng định mệnh đó, khi tôi kiểm tra lại và thấy CHƯƠNG TRÌNH ĐANG KHẢ DỤNG! Tuy nhiên dữ liệu đều là giả! Tôi đã gào lên trong sợ hãi khốn nạn và gọi cho bất cứ ai tôi có thể và thét lên “TÔI CẦN DỮ LIỆU!” rồi người đàn bà ở đầu dây bên kia đã hỏi tôi liệu tôi cần cứu hỏa hay cảnh sát, có vẻ như tôi đã gọi cho 911[7]. Nhưng sau đó tôi đã gọi cho Gorilla Mart và cũng như vậy, “TÔI CẦN DỮ LIỆU!” Và tôi sẽ không bao giờ quên được câu trả lời:
Ồ, John đấy hả. Chúng tôi vừa có phó chủ tịch mới và chúng tôi đã quyết định không tung ra ứng dụng này nữa. Anh có thể kéo nó xuống khỏi App Store được không?
Cuối cùng, thực tế là có ít nhất 11 người đã đăng ký địa chỉ email của họ trong cơ sở dữ liệu, điều đó có nghĩa là có 11 người có khả năng đã bước vào một Gorilla Mart với một coupon iPhone giả trong tay. Điều đó thật tệ hại.
Kể từ khi tất cả được nói ra và hoàn thành, vị khách hàng đó chỉ nói đúng một điều duy nhất: Code này sẽ vứt đi. Chỉ có điều là nó đã không bao giờ được tung ra trước đó.
Kết quả? Nhanh chóng để hoàn thành, chậm chạp ra thị trường
Bài học trong câu chuyện này là những nhà đầu tư của bạn, dù là khách hàng bên ngoài hay người quản lý bên trong, đã tìm ra cách để làm cho các lập trình viên viết code được nhanh. Hiệu quả ư? Không. Nhanh ư? Có. Đây là cách để thực hiện:
- Nói với lập trình viên ứng dụng rất đơn giản. Điều này nhằm làm cho nhóm phát triển rơi vào sự phán đoán sai lầm. Nó cũng làm cho các lập trình viên bắt đầu làm việc sớm hơn, nhờ đó họ…
- Thêm chức năng bằng cách đổ lỗi cho nhóm vì đã không nhận ra được sự thiết yếu của chúng. Trong trường hợp này, các nội dung được hardcode sẽ bị yêu cầu thay đổi trong bản cập nhật ứng dụng. Sao tôi có thể không nhận ra được điều đó chứ? Tôi có, nhưng trước đó tôi đã tin một lời hứa sai, và đó là lý do tại sao. Hoặc một khách hàng sẽ thuê “một gã mới” nào đó rồi anh ta chợt nhận ra rằng ở đó có một sự thiếu sót rõ ràng. Đến một ngày một khách hàng sẽ nói rằng họ vừa thuê Steve Jobs và chúng tôi có thể thêm thuật giả kim vào ứng dụng không? Sau đó họ sẽ…
- Đẩy deadline. Liên tục và liên tục. Những lập trình viên làm việc với tốc độ nhanh nhất và nỗ lực nhất có thể (và tiện thể là khả năng gây lỗi nhiều nhất của họ, nhưng ai quan tâm về điều đó, đúng không?) với một vài ngày để đuổi theo deadline. Vậy tại sao nói với họ rằng bạn có thể đẩy deadline xa hơn trong khi họ đang làm việc rất năng suất đấy? Hãy xem ưu điểm của nó! Và khi mọi sự đang diễn ra, thêm vào đó một vài ngày, thêm vào đó một tuần, tất nhiên là chỉ khi bạn đã làm thêm 20 giờ để hoàn thành mọi việc cho đúng. Nó giống như con lừa và củ cà rốt, ngoại trừ là bạn không được đối xử tốt như con lừa.
Đó là một sách lược tuyệt vời. Bạn có thể trách họ khi bạn nghĩ nó cũng có tác dụng không? Còn họ thì lại không nhìn thấy đống code Chúa-của-Xấu. Và vì vậy nó lại xảy ra, hết lần này tới lần khác, bất chấp các kết quả.
Trong một nền kinh tế toàn cầu hóa, nơi mà các tập đoàn nắm giữ những đồng đô la quyền lực và việc tăng giá cổ phiếu liên quan tới sa thải nhân viên, bắt nhân viên làm quá sức, và thuê ngoài, chiến thuật cắt giảm chi phí lập trình viên như tôi đã chỉ cho bạn thấy đang làm cho code đẹp bị lỗi thời. Là những lập trình viên, chúng ta sẽ bị yêu cầu/nói/bắt buộc viết gấp đôi lượng code trong khoảng thời gian chỉ bằng một nửa so với trước đây nếu chúng ta không cẩn thận.
Code bất khả thi
Trong câu chuyện này, khi John hỏi “Liệu code đẹp là điều bất khả thi?”, anh ấy thực ra là đang hỏi “Liệu tính chuyên nghiệp là điều bất khả thi?” Sau cùng thì thực ra không chỉ có code phải chịu đựng sự tích tệ hại này của anh ấy, mà cả gia đình, ông chủ, khách hàng của anh ấy và cả những người dùng. Mọi người đều mất mát trong cuộc phiêu lưu này (nhiều khả năng là ngoại trừ ông chủ trực tiếp của John, mặc dù tôi cá là họ cũng chịu tổn thất). Và họ đã mất mát do sự không chuyên nghiệp.
Vậy ai đã cư xử không chuyên nghiệp? John đã đưa ra rõ ràng anh ấy nghĩ người đó là những người điều hành ở Gorilla Mart. Sau cùng, câu chuyện thú vị của anh ấy là một sự buộc tội khá rõ ràng về lối hành xử tồi tệ của họ. Nhưng liệu lối hành xử của họ có xấu không? Tôi không nghĩ vậy. Những người ở Gorilla Mart đã muốn lựa chọn là có một chương trình iPhone vào ngày Black Friday. Họ sẵn sàng chi tiền để có được lựa chọn đó. Họ đã tìm được người sẵn sàng cung cấp cho họ lựa chọn đó. Vậy sao bạn có thể đổ lỗi cho họ?
Vâng, đúng là có những thất bại trong trao đổi thông tin. Rõ ràng là những người điều hành không biết web service thực sự là cái gì, và đó là những vấn đề bình thường trong một bộ phận của một tập đoàn lớn không biết về bộ phận khác của tập đoàn đang làm cái gì. Nhưng tất cả điều đó cần phải được dự tính trước. Ngay cả John cũng thừa nhận khi anh ấy nói: “Mặc dù kinh nghiệm nhiều năm đã luôn nhắc nhở tôi là mọi chức năng mà một khách hàng yêu cầu sẽ luôn luôn phức tạp để viết hơn là khi nó được giải thích…”
Vậy nếu thủ phạm không phải là Gorilla Mart, thì đó là ai?
Có lẽ đó là ông chủ trực tiếp của John. John đã nói về điều này không rõ ràng, nhưng có một gợi ý khi anh ấy đã nói rằng” Trong kinh doanh, khách hàng là thượng đế.” Vậy liệu ông chủ của John có đưa ra những lời hứa không hợp lý với Gorilla Mart không? Họ đã gây áp lực lên John, trực tiếp hoặc gián tiếp, để biến những lời hứa này thành hiện thực không? John không nói về điều này, vì vậy chúng ta chỉ có thể phỏng đoán.
Kể cả như vậy, trách nhiệm của John ở đâu trong tất cả sự việc này? Tôi cho rằng John chính là người mắc lỗi. John là người đã chấp nhận deadline hai tuần đầu tiên, mặc dù anh ấy đã biết khá rõ là các dự án thường phức tạp hơn nhiều so với lúc nghe ban đầu. John là người đã chấp nhận cần phải viết code máy chủ PHP. John là người đã chấp nhận chức năng đăng ký email, và ngày hết hạn coupon. John là người đã làm việc 20 giờ một ngày và 90 giờ một tuần. John là người đã loại trừ bản thân mình khỏi gia đình và cuộc sống của anh ấy để thực hiện theo deadline này.
Và tại sao John đã làm như vậy? Anh ấy nói với chúng ta như đùa rằng: “Tôi ấn nút Gửi, dựa lưng vào ghế, và với một nụ cười tự mãn, tôi bắt đầu tưởng tượng công ty sẽ tung hô tôi như thế nào và làm một cuộc diễu hành xuống phố số 42 trong khi tôi được lên ngôi Lập Trình Viên Vĩ Đại Nhất Mọi Thời Đại.” Nói ngắn gọn, John đã cố gắng để trở thành một người hùng. Anh ấy đã nhìn thấy cơ hội để được tôn vinh, và anh ấy đã lựa chọn nó. Anh ấy ngả về trước và chộp lấy chiếc nhẫn bằng đồng.
Những người chuyên nghiệp thường là những anh hùng, nhưng sẽ không như vậy nếu họ chỉ cố gắng vì mục đích như vậy. Những người chuyên nghiệp trở thành những người hùng khi họ hoàn thành tốt công việc, đúng thời hạn và đúng chi phí. Cố gắng trở thành người đàn ông của giờ làm việc, cứu tinh của ngày làm việc như John đã làm thì không được gọi là chuyên nghiệp.
John nên nói “không” với deadline hai tuần ngay từ đầu. Hoặc nếu không thì anh ấy cũng nên nói không khi anh ấy phát hiện ra không có web service nào cả. Anh ấy nên nói không với yêu cầu về chức năng đăng ký email và ngày hết hạn coupon. Anh ấy nên nói không với bất cứ cái gì sẽ đòi hỏi làm thêm giờ và những hy sinh khủng khiếp.
Nhưng trên tất cả, John nên nói không với quyết định bên trong của chính mình đó là cách duy nhất để hoàn thành công việc đúng thời hạn là buộc phải tạo ra một đống code hỗn độn. Các bạn chú ý rằng John đã nói gì về code đẹp và unit test:
“Để hoàn thành được lượng công việc thêm này, việc code sẽ phải thực hiện nhanh hơn một chút. Hãy quên abstract factory đi. Dùng một vòng lặp lớn thay vì composite, không còn thời gian nữa rồi!”
Và lại nữa:
“Tôi đã dành tám ngày đó để code điên cuồng. Tôi đã dùng tất cả các công cụ tôi có để hoàn thành được công việc: copy và dán (có thể gọi là code dùng lại), magic number – con số kỳ diệu (tránh lặp lại việc định nghĩa các hằng số và sau đó, haiz!, gõ lại chúng), và hoàn toàn KHÔNG có unit test! (Ai cần những thanh báo đỏ tại thời điểm như vậy, nó chỉ làm tôi mất thêm động lực mà thôi!)”
Nói “có” với những quyết định kiểu như thế này này là yếu tố quyết định thực sự dẫn tới thất bại này. John đã chấp nhận rằng cách duy nhất để thành công là cư xử thiếu chuyên nghiệp, vì vậy anh ấy đã gặt phải quả báo xứng đáng.
Điều đó nghe có vẻ tàn nhẫn. Nó không có ý như vậy. Trong các chương trước tôi đã diễn tả tôi đã hơn một lần phạm phải những lỗi lầm giống nhau trong sự nghiệp của tôi như thế nào. Sự cám dỗ được trở thành một người hùng và “giải quyết được vấn đề” là rất lớn. Tất cả chúng ta phải nhận ra được rằng nói “có” nhưng lại phải phá bỏ những nguyên tắc làm việc chuyên nghiệp thì không phải là cách để giải quyết các vấn đề. Phá bỏ những nguyên tắc này chính là nguyên nhân bạn tạo ra những vấn đề.
Với tất cả những điều đó, cuối cùng tôi có thể trả lời câu hỏi ban đầu của John:
“Code đẹp là điều không thể ư? Sự chuyên nghiệp là điều không thể ư?”
Câu trả lời: Tôi sẽ nói “không“.
[1] mock-up: bản mô phỏng hoạt động.
[2] team player: người chơi trong đội
[3] hardcode: code cứng, việc đưa các dữ liệu cố định vào code, việc này làm nhanh, nhưng khiến chương trình không thể linh hoạt được.
[4] web service: dịch vụ web, giúp lấy một thông tin nào đó thông qua API của nó.
[5] abstract factory: một trong những design pattern.
[6] Monty Python: nhóm hài kịch nổi tiếng của nước Anh.
[7] 911 là số điện thoại gọi trong trường hợp khẩn cấp ở Mỹ.