Phần mềm và nhạc rock (Software and rock music)

lessons software teams can learn from rock bands

Tôi đã nhận được một bức thư bất thường từ một sinh viên cũ mà tôi muốn chia sẻ cùng các bạn, một số trong các bạn có thể thấy nó thú vị.

Thưa giáo sư,

Thầy đã đề nghị em chia sẻ kinh nghiệm làm việc của em với các sinh viên hiện thời. Kinh nghiệm của em có thể là bất thường bởi vì bên cạnh làm việc như người phát triển phần mềm, em cũng là một nhạc sĩ trong nhóm nhạc rock. Chúng em đi nghỉ mát dọc bờ biển California nơi em và cả nhóm dựng lên sân khấu và biểu diễn cho hàng nghìn người, người khác trả tiền để xem biểu diễn của chúng em.

Tôi thích phần mềm nhưng đam mê của tôi là trong âm nhạc. Có việc làm tốt giúp tôi theo đuổi mối quan tâm của tôi trong âm nhạc. Với thu nhập từ việc làm phần mềm, tôi có thể mua được nhạc cụ tốt nhất, hệ thống âm thanh tốt nhất cho nhóm rock của tôi. Tôi để các bài hát của chúng tôi lên YouTube và đã có nhiều ghé thăm ở đó. Chúng tôi đã có CD đầu tiên của mình được bán hàng trăm nghìn bản và trên một triệu lượt tải xuống, rồi chúng tôi trở nên nổi tiếng. Bây giờ tôi có việc làm tốt nhất ở cả hai thế giới yêu thích: Lập trình viên phần mềm làm việc ban ngày và ngôi sao nhạc rock về ban đêm.

Trong cách tiếp cận Agile, nhóm phát triển phần mềm phải tự tổ chức để thiết kế, viết mã, kiểm thử và phát hành phiên bản mới cứ mỗi bốn tuần (đơn vị: Sprint). Người dùng có chức năng mới mỗi khi chúng ta phát hành bản mới. Nếu họ thích, họ cho chúng ta biết cảm nghĩ. Nếu họ không thích, chúng ta cũng biết điều đó. Điều này cũng tương tự như trong âm nhạc. Ban nhạc của tôi cũng là nhóm tự tổ chức, chúng tôi tạo ra bài hát mới, các tiết mục mới cứ mỗi mười hay hai mươi tuần rồi biểu diễn cho thính giả. Chúng tôi lấy phản hồi rất nhanh chóng. Nếu họ thích bài biểu diễn, chúng tôi được khen ngợi không ngớt. Nếu không, họ la hét chê bai chúng tôi.

Với hoà nhạc rock, âm nhạc là không đủ. Phải có cả ánh sáng và âm thanh chất lượng. Ánh sáng laser càng nhiều càng tốt. Hệ thống âm thanh phải rất lớn. Chúng tôi thuê những người hỗ trợ để quản lý các hệ thống âm thanh và ánh sáng này. Mọi người tham gia vào buổi hoà nhạc rock đều là chuyên gia. Từ người kỹ thuật âm thanh cho tới người vận hành ánh sáng, cần một nhóm chuyên gia để dựng buổi diễn lớn. Không có họ, mọi người sẽ không trả tiền để xem chúng tôi.

Phát triển phần mềm cũng giống như vậy. Nếu bạn là kỹ sư giỏi, bạn muốn có ai đó cũng giỏi như bạn hay còn giỏi hơn ở trong nhóm của bạn. Nhóm phần mềm cần những người hỗ trợ như kiểm thử viên, chuyên viên đảm bảo chất lượng (QA/QC), chuyên viên quản lý cấu hình (Configuration Management). Tệ nhất là trong nhóm cò một người không đảm bảo đủ kỹ năng khiến cả nhóm bị chậm tiến độ. Mọi người tham gia vào phát triển phần mềm cẩn phải là chuyên gia trong lĩnh vực của họ. Chúng ta cần một nhóm chuyên gia để thiết kế ra phần mềm tốt. Không có họ, sẽ không có ai mua phần mềm.

Nhiều sinh viên đại học tin rằng chỉ cần lập trình là đủ. Điều này không đúng. Lập trình chỉ chiếm tỉ lệ nhỏ trong phát triển phần mềm. Bạn cần biết vòng đời phát triển, phương pháp xây phần mềm cũng như công cụ phần mềm để tăng năng suất. Những thứ này không được dạy ở trường cho nên bạn phải tìm hiểu thêm khi bạn làm việc, nhưng bạn cần phải tiếp thu nhanh hơn nữa. Mọi người trong nhóm sẽ không chờ đợi bạn vì bạn có thể là "kỳ đà cản mũi" họ. Bạn không chỉ là người lập trình giỏi mà còn là người "học nghề" nhanh. Bạn sẽ sớm nhận ra rằng chính khái niệm cơ bản đã học ở trường sẽ giúp bạn học nhanh.

Chỉ khi làm việc thực tế, bạn sẽ nhận ra rằng trên lớp học về cấu trúc dữ liệu hay những buổi trên lớp buồn tẻ về phân tích yêu cầu hệ thống thông tin thì bây giờ những môn học đó thực sự quan trọng sau khi đi làm. Không có những tri thức này, bạn sẽ chật vật tiến thân trong nghề nghiệp. Đây là lý do tại sao các sinh viên thường đi tắt, các sinh viên học theo kiểu “mẹo vượt qua kỳ thi”sẽ không khó có thể sinh tồn khi ra trường đời. Không có nền tảng mạnh, họ không bao giờ biết áp dụng tri thức và cách biến đổi chúng thành kỹ năng.

Nhiều người tin rằng chỉ cần kỹ năng ghi ta giỏi là ổn. Điều đó không đúng hoàn toàn. Chơi ghi ta chỉ là một phần trong nhóm nhạc rock. Bạn cần biết về xu hướng âm nhạc, việc sản xuất chương trình radio và TV cũng như nhạc cụ để dùng. Những thứ này không có sẵn cho nên bạn phải tự học thật nhanh.

Thị trường rất cạnh tranh và thính giả sẽ không đợi bạn. Nếu bạn không có bài hát mới, tiết mục mới thì họ sẽ bỏ bạn. Điều này nghĩa là bạn phải không chỉ là nhạc sĩ giỏi mà còn là người học hỏi tốc độ. Tôi nghĩ phần mềm và nhạc rock có nhiều điểm chung. Âm nhạc là ngành công nghiệp đầy những bất ngờ cho nên để sống còn bạn phải học liên tục.

Bạn sẽ nhận ra rằng đam mê là không đủ, bạn phải có “hiểu biết về thương trường” nữa. Không có kỹ năng này, bạn sẽ vật lộn với cuộc sống để cạnh tranh với “mảng tối” mà hầu hết mọi người không biết. Đây là lý do tại sao nhạc sĩ ngây thơ bị khai thác và những người có thái độ hồn nhiên sẽ không bao giờ tồn tại trong ngành công nghiệp này.

Với mọi vai trò trong nhóm phần mềm, luôn có các nhóm kỹ năng cần phải làm chủ. Nhưng trong khi bạn học những kỹ năng này, bạn phải có kiến thức tối thiểu về những kỹ năng của các vai trò khác nữa. Cùng là một nhóm, bạn phải học về cách nhóm vận hành, cách làm việc cùng nhau để tạo ra phần mềm. Nhiều sinh viên chỉ tập trung vào ngôn ngữ lập trình nhưng không quan tâm để yếu tố đảm bảo chất lượng, quản lý cấu hình hay quản lý yêu cầu người dùng. Một sai lầm lớn là dự án phần mềm phần nhiều bị xem là công việc viết mã.

Chẳng hạn, là người kiểm thử bạn phải nắm rõ phần mềm viết mã tốt khác với viết mã kém như thế nào. Công việc kiểm thử của bạn bị ảnh hưởng trực tiếp bởi chất lượng của viết mã, cho nên điều mấu chốt là bạn phải làm việc với người lập trình để loại bỏ các lỗi cơ bản trước khi chuyển tiếp kết quả sang pha kiểm thử. Còn nếu bạn là kỹ sư phát triển, điều quan trọng nhất với bạn là cần biết kiến thức sơ bộ về quản lý dự án. Khác biệt giữa quản lý giỏi và quản lý kém  là khác biệt giữa dự án thành công và dự án thất bại. Đặc biệt lưu ý, khi dự án thất bại, ông chủ sa thải người quản lý dự án, chứ không sa thải kỹ sư phát triển.

Tương tự cho ban nhạc rock. Các nhạc sĩ cần biết về kỹ năng và vai trò của nhau. Người đánh trống chắc chắn biết khi nào anh ta phải dừng lại để cho người chơi ghi ta “độc tấu”. Người chơi đàn bass có thể gợi ý hợp âm nào đó cho người chơi ghi ta để họ có thể hoà âm. Kỹ sư âm thanh, chuyên gia ánh sáng phải lắng nghe cẩn thận và chăm chú vào mọi thứ sẽ diễn ra trong buổi hoà nhạc, và điều chỉnh tương ứng khi cần. Tất cả những người này đều làm việc dưới việc quản lý của đạo diễn sân khấu có kỹ năng và kinh nghiệm.

Chất lượng buổi biểu diễn của một nhạc công cũng phải tương xứng như âm thanh từ nhạc cụ của họ. Cho nên điều mấu chốt là nhạc sĩ phải làm việc với ê kíp những người hỗ trợ để đảm bảo ánh sáng và âm thanh chuẩn trước từng buổi diễn. Khác biệt giữa buổi hoà nhạc rock tốt và kém là khác biệt giữa biểu diễn thành công và biểu diễn thất bại. Đặc biệt, nếu buổi biểu diễn thất bại, người quản lý ban nhạc sa thải đạo diễn sân khấu, không sa thải nhóm hỗ trợ.

Không nhạc sỹ nghiêm chỉnh nào lại chơi nhạc cụ kém. Người nhạc sỹ thành công sẽ luôn tập trung cao độ và tìm các nhạc cụ phù hợp cho công việc. Họ phải chuẩn bị các bài hát mà họ sẽ chơi, họ phải biết rõ tiết mục của họ, vai trò của họ. Khi biểu diễn, nhạc sỹ không chỉ giỏi với nhạc cụ mà họ phải biết rõ giới hạn của hệ thống âm thanh, điều đó có nghĩa là họ phải biết mọi thứ về nhạc cụ và khi nào dùng chúng để có được âm thanh chất lượng.

Áp dụng tương tự cho phần mềm. Trước khi bạn viết ra một dòng mã, bạn cần hiểu về yêu cầu, thiết kế, giao diện người dùng, và công cụ kiểm thử. Nếu bạn là kiểm thử viên, bạn không chỉ giỏi tìm ra lỗi, mà còn phải có khả năng viết kế hoạch nghiệm thu, kịch bản kiểm thử, tình huống kiểm thử, và cũng có thể viết mã kiểm thử tự động giống như lập trình viên. Bạn sẽ thực hiện từng bước theo cách rõ ràng và chính xác nhất.

Nếu bạn làm việc trực tiếp với người dùng cuối, bạn cần hiểu quy trình doanh nghiệp của họ để có thể viết ra các câu chuyện người dùng (User Story), tình huống sử dụng (User Case) để chuyển đổi thành mã chương trình và sau đó tiến hành kiểm thử. Nếu hiểu được quy trình thực tế này, bạn mới nhận ra rằng các khóa học về thu thập, phân tích yêu cầu người dùng, về User Case, về UML, về User Story... thực sự có giá trị cho sự nghiệp bạn. Nếu là sinh viên, bạn có thể nghĩ rằng các lớp như vậy nặng về lý thuyết, và không nhận thấy tầm quan trọng nào. Đừng đánh giá thấp các môn học này. Trường Đại Học dạy bạn là có chủ đích cả.

Không nhạc sỹ nào ra sân khấu mà không có chuẩn bị, không phần mềm nào được viết mã mà không có hiểu biết về thiết kế. Điều này xem ra khó khăn cho nhiều người lập triinhf phần mềm, những người chỉ muốn viết mã mà không cần tư duy sâu. Nếu viết mã kém chất lượng, họ sẽ viết lại, nếu có lỗi, họ sẽ sửa sau. Không nhạc sỹ nào có thể lặp lại cùng bài hát nếu họ phạm sai lầm. Thính giả sẽ la hét họ. Họ không bao giờ có cơ may thứ hai cho nên trong trường hợp này, chất lượng buổi biểu diễn nhạc rock vẫn bài bản hơn so với công việc phát triển phần mềm.

Khi buổi hoà nhạc kết thúc, người quản lý sẽ triệu tập cả ban nhạc lại và tổng kết xem đã làm tốt việc gì và chưa tốt việc gì. Khi dự án phần mềm hoàn thành, có bao nhiêu người quản lý dự án sẽ triệu tập nhóm để mổ xẻ và nói cho họ biết việc nào tốt, việc nào chưa tốt? Phần lớn những người quản lý dự án sẽ cảm thấy hạnh phục khi dự án đã hoàn thành và phần mềm được chuyển giao cho khách hàng, rồi sẽ sửa lỗi sau. Có bao nhiêu lập trình viên sẽ tự suy nghĩ, đánh giá về hiệu quả và năng suất của bản thân? Bao nhiêu người trong số họ sẽ biết về số lỗi của họ. Và đây lại là một bằng chứng cho thấy tổ chức ban nhạc rock vẫn bài bản hơn so với phát triển phần mềm.

Đấy là quan điểm và kinh nghiệm của tôi, tôi mong rằng sinh viên của chúng ta có nhiều thành công hơn bậc tiền bối. Có nhiều công việc làm phần mềm ở bang California. Dường như mọi công ty đều đang thuê người phát triển phần mềm và sẵn lòng trả nhiều tiền cho họ. Tôi ước điều đó cũng tương tự trong nhạc rock.

Nguồn: TIGO Solutions