Xin mời đọc Phần 1 tại đây
6. Bạn có lịch trình sát với thực tế hiện tại không?
Và chúng ta đến với chủ đề lịch trình. Nếu code của bạn là quan trọng nhất với doanh nghiệp, thì càng có nhiều lý do để doanh nghiệp cần được biết khi nào code của bạn sẽ hoàn thành. Lập trình viên nổi tiếng về việc dự đoán kém. Họ thường hét vào mặt các đồng sự khác: “Nó sẽ xong khi nào nó xong!”
Vấn đề là, mọi chuyện không đơn giản như thế. Có rất nhiều hoạch định cần phải được đưa ra trước khi phát hành sản phẩm: các buổi thử nghiệm, hội chợ, quảng cáo, v.v. Và cách duy nhất để đạt được điều này là phải có một lịch trình, và luôn cập nhật nó cho thật chính xác.
Một vấn đề nữa khi bạn có một lịch trình đó là nó ép bạn phải lựa chọn tính năng nào sẽ được làm, và buộc bạn phải lựa ra những tính năng ít quan trọng nhất và gạt ra thay vì để cho nó lọt vào “thời gian sắp tới” (hay còn gọi là vỡ kế hoạch).
Duy trì một lịch trình không khó, hãy đọc bài viết Lịch trình phần mềm không đau khổ của tôi, và bạn sẽ thấy một cách đơn giản để có được lịch trình tốt.
7. Bạn có tài liệu yêu cầu không?
Viết tài liệu yêu cầu giống như dùng chỉ nha khoa vậy: ai cũng đồng ý rằng đó là việc tốt, nhưng chẳng ai chịu làm cả.
Tôi không thực sự hiểu vì sao lại thế, nhưng có lẽ đó là bởi vì lập trình viên ghét viết tài liệu. Và kết quả là, khi mà một nhóm gồm toàn lập trình viên cắm đầu vào giải quyết vấn đề, họ thường chọn việc thể hiện giải pháp của mình qua code, hơn là qua văn bản. Họ thà cắm đầu vào và viết code còn hơn là viết ra yêu cầu trước.
Ở giai đoạn thiết kế, khi bạn phát hiện ra vấn đề, bạn có thể dễ dàng sửa nó bằng việc thay đổi một vài dòng chữ. Nhưng một khi code đã được viết ra, thì chi phí để sửa vấn đề tăng lên đáng kể, cả về tinh thần (ai cũng ghét vứt bỏ code cả) cũng như thời gian, vì vậy bạn sẽ gặp trở ngại với việc thực sử sửa chữa vấn đề đó. Phần mềm không được viết từ yêu cầu thường có thiết kế tệ hại và lịch trình thì vượt ra ngoài tầm kiểm soát. Đây có lẽ là vấn đề đã từng xảy ra ở Netscape, khi mà bốn phiên bản đầu tiên trở thành một đống hổ lốn đến mức ban giám đốc đã đưa ra quyết định điên rồ là ném code đi và làm lại từ đầu. Rồi sau đó họ lại phạm lại sai lầm này lần nữa với Mozilla, tạo ra một con quái vật không kiểm soát được và mất nhiều năm để có thể bước vào giai đoạn Alpha.
8. Lập trình viên của bạn có môi trường yên tĩnh không?
Có rất nhiều nghiên cứu chứng minh hiệu suất làm việc tăng đáng kể khi bạn cung cấp cho những người làm việc trí óc một môi trường rộng rãi, yên tĩnh và riêng tư. Cuốn sách kinh điển về quản lý phần mềm Peopleware có đầy đủ tài liệu về những cải thiện hiệu suất này.
Lý giải vấn đề này như sau: ta đều biết những người làm trí óc hoạt động hiệu quả nhất khi họ vào “guồng”, hay còn gọi là “hưng phấn”, là lúc mà họ hoàn toàn tập trung vào công việc và loại bỏ hoàn toàn môi trường xung quanh. Họ quên đi thời gian và tạo ra những thứ tuyệt hảo thông qua sự tập trung tuyệt đối. Đây là lúc duy nhất mà họ thực sự có năng suất. Nhà văn, lập trình viên, nhà khoa học, và ngay cả vận động viên đều có thể giải thích cho bạn về cảm giác “hưng phấn” này.
Vấn đề là, để có được trạng thái “hưng phấn” này không dễ dàng. Nếu bạn muốn đo đạc, thì thường phải mất 15 phút để đạt được hiệu suất cao nhất. Và đôi khi bạn mệt hay đã làm nhiều công việc trí tuệ trong ngày hôm đó, thì bạn sẽ không tìm được trạng thái đó nữa và bạn dành thời gian còn lại nghịch ngợm, đọc báo hay chơi xếp hình (
).
Một vấn đề nữa là bạn rất dễ bị mất sự hưng phấn. Tiếng ồn, điện thoại, đi ăn trưa, phải lái xe 5 phút đi mua cốc cà phê, cũng như bị đồng nghiệp làm gián đoạn – đặc biệt là đồng nghiệp – đều làm bạn mất hưng phấn. Nếu đồng nghiệp hỏi bạn 1 câu, dù chỉ là 1 phút gián đoạn, nhưng nó sẽ làm cho bạn mất tập trung đi rất nhiều và phải mất tới nửa giờ để có thể làm việc hiệu quả tiếp được, thì hiệu suất chung của bạn sẽ bị ảnh hưởng thê thảm. Nếu bạn làm việc trong môi trường ồn ào kiểu chuồng bò mà các công ty dotcom thích xây dựng, với mấy ông kễnh marketing hét vào điện thoại bên cạnh lập trình viên, hiệu suất làm việc của bạn sẽ rơi xuống vực sâu vì những người làm việc trí óc sẽ bị gián đoạn liên tục và chẳng bao giờ tập trung được.
Đối với lập trình viên thì càng khó. Năng suất phụ thuộc vào việc tung hứng rất nhiều chi tiết nhỏ nhặt trong trí nhớ ngắn hạn cùng lúc. Bất kỳ một gián đoạn nhỏ nào đều có thể làm cho các chi tiết này rụng hết xuống. Khi bạn quay lại làm tiếp, bạn không thể nhớ những chi tiết này (như tên biến bạn đang dùng, hay bạn đang làm đến đâu trong thuật toán tìm kiếm này) và bạn phải từ từ đưa lại những thứ này vào đầu, khiến cho bạn tốn nhiều thời gian để làm tiếp được.
Hãy làm một phép tính đơn giản. Giả sử (như các nghiên cứu đã đưa ra) như ta làm phiền một lập trình viên, dù chỉ là một phút, chúng ta vừa ném bỏ 15 phút năng suất. Trong ví dụ này ta hãy đặt ô làm việc mở với hai lập trình viên Jeff và Mutt, trong một trang trại nuôi bê thịt như trong truyện Dilbert. Mutt không nhớ được phiên bản Unicode của hàm strcpy, anh ta có thể gu gờ trong 30 giây, hoặc hỏi Jeff, chỉ tốn 15 giây. Vì anh ta ngồi ngay cạnh Jeff nên anh ta hỏi Jeff. Jeff mất tập trung và bị mất 15 phút năng suất (để tiết kiệm cho Mutt 15 giây).
Giờ ta chuyển họ sang những phòng làm việc khác nhau với tường và cửa riêng biệt. Giờ nếu như Mutt không nhớ, anh ta có thể gu gờ nó, vẫn mất 30 giây, hoặc là đi hỏi Jeff, giờ đã tốn lên 45 giây và bao gồm việc phải đứng dậy (một việc không dễ dàng nếu bạn nhìn vào thể trạng của các lập trình viên!). Và thế là anh ta gu gờ nó, vậy là Mutt tốn 30 giây nhưng ta tiết kiệm được 15 phút của Jeff. À…..!
9. Bạn có những công cụ tốt nhất có thể mua bằng tiền không?
Viết code bằng ngôn ngữ của máy là một trong những thứ cuối cùng chưa thể làm ngay tắp lự trên máy tính cá nhân. Nếu quá trình biên dịch của bạn tốn nhiều hơn vài giây, việc trang bị máy tính mới nhất và mạnh nhất sẽ tiết kiệm thời gian cho bạn. Nếu biên dịch chỉ tốn 15 giây, lập trình viên sẽ chán trong khi chờ biên dịch và chuyển qua đọc Củ Hành, thứ sẽ hút hồn họ và làm mất nhiều giờ năng suất.
Chạy duyệt lỗi GUI với những chiếc máy một màn hình thật đau khổ nếu không nói là bất khả thi. Nếu bạn viết code GUI, hai màn hình sẽ làm cho cuộc đời bạn tươi đẹp hơn nhiều.
Phần lớn lập trình viên sẽ phải chỉnh sửa hình ảnh cho hình đại diện hoặc thanh công cụ, và phần lớn lập trình viên không có công cụ tốt dành cho họ. Dùng Microsoft Paint để chỉnh sửa hình ảnh nghe như chuyện tấu hài, nhưng đó là những gì lập trình viên vẫn dùng (ND: chuẩn cơm mẹ nấu rồi).
Ở công ty trước, tay quản lý hệ thống liên tục gửi mail tự động cho tôi than phiền về việc tôi sử dụng nhiều hơn… 220MB đĩa cứng trên máy chủ lưu trữ. Tôi chỉ ra cho hắn thấy với cái giá ổ cứng ngày nay, chi phí cho chút ổ cứng này còn rẻ hơn giấy chùi đít mà tôi dùng. Dù chỉ là 10 phút để dọn dẹp cái thư mục này cũng là một sự hoang phí tàn bạo thời gian của tôi.
Những đội phát triền phần mềm hàng đầu không hành hạ lập trình viên của họ. Những bất mãn dù chỉ rất nhỏ gây ra do việc phải dùng công cụ rởm rít cũng dễ dàng làm cho lập trình viên bực bội và mất vui. Và một anh chàng lập trình viên đang bực là một anh lập trình viên không năng suất.
Và để thêm tí mắm muối… lập trình viên rất dễ nịnh bằng việc cấp cho họ những thứ hay ho nhất, đời mới nhất. Và đây là cách rẻ hơn rất nhiều để giữ họ làm việc cho bạn so với việc nai lưng trả lương cho bằng với thị trường!
10. Bạn có người thử nghiệm phần mềm không?
Nếu đội của bạn không có người thử phần mềm chỉ định, ít nhất là một, hai hay ba lập trình viên, thì bạn đang phát hành sản phẩm lỗi, hoặc bạn đang hao phí tiền của để dùng lập trình viên với giá $100/h để làm việc của những người thử phần mềm giá $30/h. Ki bo trong việc thuê người thử phần mềm là một kiểu tiết kiệm ngược tồi tệ đến độ mà tôi phát điên lên không hiểu vì sao họ không nhận ra nó.
Hãy đọc Năm lý do (sai lầm) bạn không có người thử phần mềm
11. Ứng viên mới có viết code trong bài phỏng vấn không?
Bạn có thuê một ảo thuật gia mà không nói họ diễn cho bạn xem vài trò không? Chắc chắn không! (ND: Hell no :p)
Bạn có thuê nhà hàng tổ chức tiệc cưới cho bạn mà không ăn thử không? Tôi dám chắc là không. (Trừ khi đó là bà cô Marge, và bà ấy sẽ ghét bạn suốt đời nếu bạn không để cho bà ấy nấu bánh gan lợn “nổi tiếng”).
Vậy mà ngày nào cũng có lập trình viên được tuyển dựa vào một bản lý lịch “hoành tráng” hoặc bởi vì người phỏng vấn khoái nói chuyện với họ. Hoặc họ được hỏi mấy câu hỏi lăng nhăng (kiểu như “sự khác biệt giữa CreateDialog() và DialogBox() là gì?”) mà bạn có thể tự xem bằng cách đọc sách hướng dẫn. Bạn đừng ngớ ngẩn quan tâm đến chuyện họ nhớ được bao nhiêu câu tủ, bạn hãy quan tâm đến chuyện họ có code được hay không. Hoặc tệ hơn nếu, họ bị hỏi những câu “À há”: kiểu câu hỏi nghe rất dễ nếu bạn biết, nhưng nếu bạn không biết thì bất khả thi.
Tôi van bạn hãy dừng cách làm này lại, bạn làm trò gì trong các cuộc phỏng vấn cũng được, nhưng hãy để cho lập trình viên viết một ít code. (Để biết thêm, hãy đọc bài Hướng dẫn đơn giản cho phỏng vấn)
12. Bạn có thử nghiệm hành lang với người ngoài không?
Bài thử nghiệm ở hành lang được thực hiện bằng cách tóm lấy bất kỳ người nào đi qua hành lang và bắt họ thử dùng code bạn vừa viết. Nếu bạn làm điều này với năm người, bạn sẽ biết được 95% những gì bạn cần biết về vấn đề sử dụng của code đó.
Thiết kế giao diện tốt không khó như bạn nghĩ, và nó rất quan trọng nếu bạn muốn khách hàng yêu thích và mua sản phẩm của bạn. Bạn có thể đọc cuốn sách miễn phí về thiết kế giao diện của tôi, một cuốn nhập đề ngắn cho lập trình viên.
Nhưng điều quan trọng nhất về giao diện là nếu bạn đưa chương trình của bạn cho một đám người dùng thử (chỉ năm, sáu người là đủ) bạn sẽ nhanh chóng phát hiện ra những vấn đề lớn nhất mà họ đang gặp phải. Hãy đọc bài viết của Jakob Nielsen để hiểu tại sao. Dù thiết kế giao diện của bạn còn thô sơ, chừng nào bạn còn cố gắng thử nghiệm hành lang, gần như miễn phí, thì giao diện của bạn sẽ ngày càng tốt hơn.
Bình luận