Tỷ lệ của các nhà phân tích cho các lập trình viên

13

“Thông số kỹ thuật tốt sẽ cải thiện năng suất của lập trình viên tốt hơn nhiều so với bất kỳ công cụ hoặc kỹ thuật lập trình nào.”

– Định luật Bryce

GIỚI THIỆU

Về phát triển hệ thống, trong những năm 1960 và đầu những năm 1970, bạn có thể là Nhà phân tích hệ thống hoặc Lập trình viên. Giai đoạn = Stage. Vào thời điểm đó, về cơ bản số lượng nhà phân tích nhiều hơn số lượng lập trình viên (ít nhất là tỷ lệ 2:1). Điều này một phần là do máy tính chỉ mới xuất hiện trong thế giới doanh nghiệp và vẫn còn những người xung quanh có thể xem xét toàn bộ hệ thống. Tuy nhiên, nhu cầu lập trình máy tính của mọi người ngày càng tăng cao và do đó, đây đã trở thành những năm bùng nổ của ngành lập trình. Nếu bạn biết COBOL, Fortran hoặc PL/1, bạn gần như có thể mua đúng vé của mình. Mức lương rất tốt và bạn có thể đe dọa chủ nhân của mình chỉ bằng những gì bạn biết (bạn phải phạm tội gì đó như giết người để bị sa thải). Sự nhấn mạnh vào lập trình trở nên lớn đến mức các tác giả đã vội vã cho ra đời những cuốn sách đồ sộ để tăng năng suất của lập trình viên, do đó, sự ra đời của phong trào Lập trình có cấu trúc vào cuối những năm 1970, ngay sau đó là phong trào CASE (Kỹ thuật phần mềm hỗ trợ máy tính).

Trong khi lập trình ngày càng phát triển thì Phân tích hệ thống lại sa sút nghiêm trọng. Các nhóm thương mại như Hiệp hội Quản lý Hệ thống (ASM) nhận thấy tư cách thành viên của họ giảm dần và buộc phải đóng cửa. Người cuối cùng trong số các Nhà phân tích Hệ thống cũ hoặc đã nghỉ hưu hoặc bị các tập đoàn đuổi việc vào những năm 1980. Các chức danh công việc mới đã xuất hiện, chẳng hạn như Kỹ sư phần mềm và Nhà phân tích/Lập trình viên. Tiêu đề thứ hai này có một chút nhầm lẫn vì trọng tâm là lập trình chứ không phải phân tích hệ thống.

Mặc dù lập trình xuất sắc, nhưng khoảng trống đáng chú ý bắt đầu xuất hiện đối với những người có thể nhìn thấy toàn bộ hệ thống. Viết một chương trình tốt là một chuyện, làm cho nó giao tiếp với các chương trình khác để tạo thành một hệ thống hoàn chỉnh lại là một chuyện hoàn toàn khác. Bước sang thế kỷ này, ngành công nghiệp bắt đầu nói về những thứ như “Kiến trúc doanh nghiệp”, “Quy trình kinh doanh”, “Quy tắc kinh doanh”, “Phân tích kinh doanh”, v.v. Hơn nữa, các hội nghị, nhóm thương mại và chức danh công việc mới bắt đầu nổi lên. Ngày nay, các lập trình viên được coi là một tá và nguồn cung cấp một nhà phân tích thực thụ đang gia tăng.

Tất cả những điều này cho thấy ngành công nghiệp đang cố gắng phát minh lại lý thuyết hệ thống. Trên thực tế, không có gì mới ở đây vì phân tích hệ thống là phân tích hệ thống. Nhưng khi các công ty triển khai lại các khái niệm và chức danh công việc này, họ có chút không chắc chắn về vị trí phù hợp của mình và mối quan hệ của chúng với các chức năng Công nghệ thông tin khác.

ĐẶC TRƯNG

Ngày nay, một Nhà phân tích hệ thống có nhiều tên gọi; ví dụ: Nhà phân tích kinh doanh, Kiến trúc sư doanh nghiệp, Kỹ sư hệ thống (sở thích cá nhân của tôi), v.v. Tuy nhiên, chúng ta đang nói về một người có nhiệm vụ nghiên cứu các yêu cầu thông tin của một doanh nghiệp và thiết kế một giải pháp hệ thống tổng thể để đáp ứng chúng. Hơn nữa, nhà phân tích chịu trách nhiệm chỉ định các yêu cầu phần mềm và do đó, được coi là người trung gian với nhân viên lập trình. Các đặc điểm cá nhân của nhà phân tích khác biệt đáng kể so với lập trình viên. Trong khi lập trình viên có xu hướng hướng nội hơn và tập trung vào công nghệ, thì nhà phân tích có xu hướng hướng ngoại và hướng kinh doanh hơn. Các nhà phân tích sở hữu kỹ năng giao tiếp tốt (bằng lời nói và bằng văn bản) để làm việc hiệu quả với cả người dùng cuối và nhân viên lập trình. Họ biết cách thực hiện một cuộc phỏng vấn và thuyết trình (kỹ năng bán hàng). Ngoài ra, họ có xu hướng nhìn vào bức tranh toàn cảnh thay vì chỉ nhìn vào một phần của nó và sở hữu tinh thần kinh doanh.

Nhà phân tích hiểu các vấn đề kinh doanh của người dùng cuối và thân thiết với hoạt động của bộ phận người dùng. Nói cách khác, nhà phân tích có thể thoải mái đặt mình vào vị trí của người dùng cuối. Nếu họ đang làm đúng công việc của mình, các nhà phân tích sẽ tạo ra những ứng cử viên xuất sắc để đảm nhận trách nhiệm trong hệ thống phân cấp quản lý. Nhưng vì các nhà phân tích đã sa sút trong nhiều năm nên điều này đã không xảy ra trong một thời gian khá dài. Lần cuối cùng tôi nghe nói về một nhà phân tích hệ thống tốt nghiệp ở vị trí quản lý chính là Dan Boone, người được bổ nhiệm làm Chủ tịch kiêm Giám đốc điều hành của Armco Steel vào cuối những năm 1970.

Nếu phân tích hệ thống được thực hiện chính xác, năng suất của lập trình viên sẽ được cải thiện vì các nhà phân tích sẽ cung cấp các thông số kỹ thuật tốt cho các bài tập ứng dụng. Trong trường hợp không có các nhà phân tích hệ thống, lập trình viên sẽ mất thời gian đáng kể, người phải đoán lần thứ hai những gì người dùng cuối muốn. Chắc chắn, điều này dẫn đến việc viết đi viết lại phần mềm nhiều lần. Dữ liệu tốt và thông số kỹ thuật xử lý, do nhà phân tích hệ thống cung cấp, sẽ cải thiện năng suất của lập trình viên tốt hơn nhiều so với bất kỳ công cụ hoặc kỹ thuật lập trình nào. Điều này có nghĩa là các lập trình viên là những người được hưởng lợi từ việc phân tích hệ thống tốt.

Điều này mang đến một điểm thú vị, tỷ lệ của Nhà phân tích hệ thống so với Lập trình viên trong một tổ chức phát triển là bao nhiêu? Thành thật mà nói, tôi tin rằng nên có gấp đôi số lượng nhà phân tích so với số lượng lập trình viên. Bằng cách tập trung vào công việc ban đầu, việc lập trình được đơn giản hóa. Hãy để tôi minh họa điểm này bằng cách sử dụng các hình tam giác sau đây biểu thị tổng số nỗ lực trong một dự án (ngoài ra, tôi đã chọn điều này từ các khách hàng của mình ở Nhật Bản, những người có cùng quan điểm với tôi), hãy xem:

http://www.phmainstreet.com/mba/blog/ss060724.jpg

Hình tam giác bên trái đại diện cho cách tiếp cận truyền thống theo đó số lượng lập trình viên gấp đôi so với số lượng nhà phân tích hệ thống. Theo cách tiếp cận này, người ta dành nhiều thời gian hơn đáng kể để sản xuất phần mềm để đáp ứng các yêu cầu được xác định kém. Người Nhật chỉ ra rằng đáy của tam giác thực sự là không đáy vì điều đó có nghĩa là cần thêm thời gian để hoàn thành một dự án. Hãy so sánh nó với hình tam giác bên phải, nơi có số lượng nhà phân tích gấp đôi số lượng lập trình viên. Theo kịch bản này, sẽ dành nhiều thời gian hơn để phân tích vấn đề, thiết kế hệ thống và tạo ra các thông số kỹ thuật lập trình tốt hơn. Do đó, các lập trình viên không cần phải đoán trước những gì phải được thực hiện và có thể thực hiện công việc của họ hiệu quả hơn.

Tuy nhiên, vấn đề với sơ đồ bên phải là Phân tích hệ thống được coi là một khái niệm hơi mơ hồ đối với quản lý. Mặt khác, lập trình thì hữu hình hơn và mọi người dễ dàng nắm bắt hơn; bạn đang viết mã và sản xuất một chương trình hoặc bạn không. Do đó, tư duy trong quản lý là bạn sẽ không làm việc hiệu quả trừ khi bạn viết mã, do đó có xu hướng phân tích hệ thống phím tắt. Đây là lý do chính khiến Phân tích hệ thống sụp đổ vào những năm 1980. Và đây là lý do tại sao cần phải cung cấp đào tạo để ban quản lý đánh giá cao nhu cầu phân tích hệ thống. Thành thật mà nói, tôi nhận thấy ban quản lý có thể hỗ trợ rất nhiều nếu nó được trình bày đúng cách với họ.

PHẦN KẾT LUẬN

Cho dù bạn gọi họ là Nhà phân tích hệ thống, Nhà phân tích kinh doanh, Kỹ sư hệ thống hay Kiến trúc sư doanh nghiệp, thì việc thấy chức năng quan trọng này được giới thiệu lại cho các công ty là điều rất đáng khích lệ. Đối với tôi, đó là điều không thể tránh khỏi. Tôi đoán rằng các công ty cuối cùng đã nhận ra rằng bạn không thể giải quyết các vấn đề về hệ thống của mình chỉ bằng cách sử dụng các công cụ và kỹ thuật lập trình tốt hơn.

Chúng ta cũng bắt đầu nhận thấy sự trỗi dậy của các nhóm thương mại có liên quan để thay thế các nhóm như Hiệp hội Quản lý Hệ thống (ASM), chẳng hạn:

Viện phân tích kinh doanh quốc tế

IIBA dường như đang tiếp tục ở nơi ASM đã dừng lại, bao gồm cả chứng nhận. Trong khi ASM đã phát triển và cung cấp chứng chỉ Certified Systems Professional (CSP) từ nhiều năm trước, IIBA muốn tạo ra thứ gì đó tương tự.

Tất cả những điều này cho thấy ngành công nghiệp đang cố gắng phát minh lại lý thuyết hệ thống như thế nào. Trong khi các hệ thống như vậy hoạt động nổi tiếng cho đến những năm 1980 thì nó đã bị lãng quên trong hai mươi năm qua do quá chú trọng vào lập trình. May mắn thay, các công ty cuối cùng đã nhận ra tầm quan trọng của hệ thống hoạt động và đang cố gắng sắp xếp công việc của họ theo thứ tự. Tôi đoán những gì đi xung quanh, đến xung quanh.


Kim Tuyết