Tại sao các nhà phân tích kinh doanh và quản lý dự án có mức lương cao hơn các lập trình viên? [đóng cửa]

Chúng ta phải thừa nhận rằng lập trình khó hơn nhiều so với việc tạo tài liệu hoặc thậm chí tạo biểu đồ Gantt và yêu cầu tiến trình cho các lập trình viên. Vì vậy, đối với chúng tôi là những người ngây thơ, biết rằng lập trình nói chung là khó khăn hơn, tại sao các nhà phân tích kinh doanh và quản lý dự án có mức lương cao hơn các lập trình viên? Điều gì làm cho công việc của họ trở thành một công việc được trả lương cao khi thậm chí nhiều lúc các lập trình viên là những người về nhà muộn?

CẬP NHẬT

Xin lỗi vì sự thiếu hiểu biết của tôi, từ một số phản hồi có vẻ như lý do tại sao BA và PM có mức lương cao hơn bởi vì họ là những người thường chịu trách nhiệm cho các lập trình viên gây rối. Nhưng vào cuối ngày, chính các lập trình viên đã bị bẩn tay để sửa chữa mớ hỗn độn và làm việc chăm chỉ hơn. Vì vậy, nó vẫn không có ý nghĩa.

Việc các nhà quản lý dự án có nhận được mức lương cao hơn so với các lập trình viên và các nhà phân tích kinh doanh hay không đều tồn tại như một lớp học phụ thuộc vào thế giới phần mềm mà bạn đang sống.

Một câu trả lời đơn giản cho câu hỏi này sẽ là "bởi vì trong xã hội của chúng ta, chúng ta vẫn nghĩ rằng tiền lương bị ràng buộc với vị trí trong hệ thống phân cấp." Nhưng câu trả lời này trong khi phản ánh thực tế rằng mọi người được trả tiền dựa trên giá trị cảm nhận của họ không giải thích được tại sao PM và BA đứng đầu trong hệ thống phân cấp trong nhiều tổ chức phần mềm và tại sao ban quản lý lại phân cấp theo thứ tự như một cấu trúc được lựa chọn cho nhóm dự án phần mềm. Đây là hai câu hỏi dường như thực sự đáng để hỏi.

Nói rộng ra có hai loại tổ chức làm phần mềm. Tôi sẽ gọi họ là Nhà máy phụ tùng và Đoàn làm phim.

Các nhà máy tiện ích được sinh ra từ trường quản lý tư duy xoay quanh động lực Lý thuyết X do McGregor đề xuất: nhân viên cấp bậc lười biếng và yêu cầu kiểm soát và giám sát liên tục, công việc được giữ dưới danh nghĩa kiểm tra lương, người quản lý luôn có thể làm cấp dưới của họ ' việc làm để cao hơn hoặc, ít nhất, cùng tiêu chuẩn. Suy nghĩ này đưa ra một ý tưởng tự nhiên rằng toàn bộ nhóm có thể dễ dàng được thay thế và đại diện bởi người quản lý một mình - sau khi tất cả những người khác trong nhóm có thể thay thế dễ dàng hoặc chỉ để tăng cường khả năng hoàn thành nhiệm vụ của người quản lý. Do đó hệ thống phân cấp như một cấu trúc và vai trò công việc khá ngang.

Quản lý Widget Factory hoạt động dựa trên giả định rằng phần mềm có thể được sản xuất theo đặc điểm kỹ thuật do nhà phân tích kinh doanh chuẩn bị thông qua quy trình được xác định rõ ràng dưới sự giám sát chặt chẽ của người quản lý dự án. Việc sản xuất được chăm sóc bằng cách bố trí nhân viên cho dự án với đủ tài nguyên kiểm tra và lập trình có thể thay thế được. Công việc được thúc đẩy bởi một ngân sách được sắp xếp trước dựa trên trường hợp kinh doanh ban đầu được chuẩn bị bởi PM và BA.

Quản lý điều hành Widget Factory rất dễ nhận ra chỉ bằng cách chú ý đến cách những người này nói chuyện. Họ có khả năng về các tài nguyên (bao gồm cả khi đề cập đến các thành viên trong nhóm), quy trình, hiệu quả hoạt động, tính đồng nhất, độ lặp lại, kiểm soát chặt chẽ việc sử dụng tài nguyên, vai trò công việc rõ ràng và đầu vào và đầu ra quy trình được xác định. Họ tình cờ đề cập đến phép ẩn dụ thực tế của nhà máy khi cố gắng truyền tải hình ảnh của hoạt động phát triển phần mềm lý tưởng như họ thấy.

Sau đó là Đoàn làm phim. Họ dựa trên quan niệm rằng mọi người thông minh, tự động viên, làm việc thực sự chăm chỉ và thích công việc của họ nhiều như những đứa trẻ thích chơi. Đoàn làm phim nhận ra rằng do chuyên môn hóa, khả năng đóng góp của cá nhân có thể vượt xa khả năng của những người tổ chức, điều phối và chỉ đạo công việc. Vì người quản lý không còn có thể thay thế cho mọi người, nên cấu trúc phân cấp không hoạt động tốt - mọi người phải hợp tác trong một đội hình phẳng và phức tạp hơn nhiều để hoàn thành công việc. Bản thân các vai trò của Jobs có xu hướng thẳng đứng hơn nhiều - bắt đầu kết thúc - và liên quan đến nhiều kỹ năng khác nhau. Tư duy quản lý này được củng cố bởi Lý thuyết Y của McGregor .

Một giám đốc của một đoàn làm phim biết rằng tầm nhìn của cô về một phần mềm chỉ có thể trở thành sự thật nếu cô có thể tập hợp một đội ngũ tuyệt vời, mê hoặc trí tưởng tượng và giúp nhóm tạo gel và làm việc cùng nhau. Vai trò của cô là truyền cảm hứng, bảo vệ tầm nhìn, cung cấp phương hướng và tập trung các nỗ lực. Mỗi một người quan trọng bởi vì "giám đốc" tin rằng phần mềm là kết quả của sự kết hợp giữa thế giới quan và khả năng của tất cả những người tham gia và một cách duy nhất mà nhóm thực hiện công việc cùng nhau. Mọi người đều nhận ra từ tầm quan trọng của việc đưa các ngôi sao tham gia phi hành đoàn - những người biểu diễn ngôi sao tăng mọi cơ hội thành công. Tầm nhìn thúc đẩy ngân sách và thu hút tài trợ.

Khi nói đến bồi thườngCác nhà máy vật dụng cho rằng giá trị cao nhất có được từ công việc được thực hiện bởi người quản lý dự án và nhà phân tích kinh doanh, người nằm trên đỉnh của hệ thống phân cấp và phải được bồi thường tương ứng, phần còn lại của nhóm không quan trọng chừng nào họ còn ' đã có trình độ phù hợp để chuyển đổi các yêu cầu thành mã làm việc. PM và BA làm việc chăm chỉ để duy trì vị trí của họ trên đầu gói bằng cách hạn chế quyền truy cập miễn phí vào các nguồn thông tin dự án cho các thành viên còn lại trong nhóm. Không có quyền truy cập chính thức vào các nguồn thông tin chính mà nhóm đấu tranh để đưa ra bất kỳ phán đoán giá trị nào hoặc đưa ra các giải pháp tốt, các lập trình viên bị từ chối nhận các đơn đặt hàng từ phía trên và giải quyết vấn đề theo quy định của PM và BA.

Trong một sự tương phản rõ rệt, Film crew hoạt động như một đội hình bình đẳng hơn; các thành viên được cấp quyền truy cập không hạn chế vào thông tin chính, được khuyến khích hình thành các bản án giá trị và được tự do lựa chọn một quá trình hành động để thực hiện và đóng góp cho tầm nhìn. Cơ cấu lãnh đạo dựa trên khả năng chứ không phải vai trò cụ thể trong nhóm. Bồi thường phản ánh mức độ mong muốn có được một người cụ thể tham gia dự án, nó thường gắn liền với nhận thức về kết quả cuối cùng sẽ có giá trị hơn bao nhiêu nếu người đó có thể bị thuyết phục để dành năng lượng của họ để tạo ra phần mềm đó. Trong môi trường này, vai trò của người quản lý dự án trở nên ít nổi bật hơn vì anh ta khó có thể trở thành người lãnh đạo sáng tạo; vai trò chủ yếu đến hỗ trợ hành chính và quan hệ đối ngoại.

Bây giờ, sẽ không có gì ngạc nhiên khi hầu hết các nhóm phát triển phần mềm nội bộ và một số chuyên gia tư vấn đều được điều hành khi các nhà máy phụ thuộc vào một quy trình để tạo ra phần mềm luôn nhàm chán; đó là những môi trường mà các nhà quản lý dự án và các nhà phân tích kinh doanh thường được trả nhiều tiền hơn các lập trình viên dựa trên giả định rằng họ mang lại giá trị cao nhất với môi trường được cấu trúc theo đó gây khó khăn cho các lập trình viên khi chứng minh quản lý sai.

Các công ty phần mềm thành công có xu hướng chấp nhận quan điểm của Film Crew, bất kỳ triết lý nào khác sẽ cản trở khả năng thu hút những người tuyệt vời mà họ dựa vào rất nhiều để tạo ra phần mềm tuyệt vời. Không chắc bạn từng thấy vai trò phân tích kinh doanh trong bối cảnh đó và các nhà quản lý dự án ít nổi bật hơn và thường được trả ít hơn các lập trình viên tuyệt vời.

Bởi vì trong xã hội của chúng ta, chúng ta vẫn nghĩ rằng tiền lương bị ràng buộc với vị trí trong hệ thống phân cấp .

Các nhà phân tích hoặc quản lý dự án cao hơn trong hệ thống phân cấp, vì vậy họ nên được trả nhiều hơn.

Hãy để tôi kể cho bạn một câu chuyện có thật minh họa tại sao đây là một vấn đề.

Một người bạn tốt bắt đầu làm lập trình viên trong một bệnh viện lớn. Nhờ làm việc chăm chỉ và cống hiến, anh nhanh chóng trở thành Oracle DBA, một vị trí quan trọng trong một công ty nơi dữ liệu vừa nhạy cảm vừa có giá trị.

Bệnh viện làm việc với các cấp. Cấp độ được ràng buộc với vị trí của bạn trong hệ thống phân cấp, di sản và văn bằng.

Bạn tôi có một đề nghị trở thành DBA trong một công ty khác không sử dụng mức lương. Lương của anh ta có thể được tăng lên rất nhiều. Vì thích và tôn trọng bệnh viện mà anh ta làm việc, anh ta quyết định nói chuyện với ông chủ, yêu cầu tăng lương.

Sếp từ chối. Điều đó là không thể vì các cấp và các công đoàn sẽ không để điều đó xảy ra.

Bạn tôi bỏ đi.

Bệnh viện cuối cùng đã thuê một chuyên gia tư vấn bên ngoài (không bị ràng buộc với các cấp độ) và đăng một công việc trên trang web của họ. Nhà tư vấn không biết gì về cơ sở hạ tầng tại chỗ, vì vậy đường cong học tập của anh ta rất lớn. Bệnh viện mất rất nhiều tiền vì điều đó.

Bệnh viện đã mất nhiều hơn. Chuyên gia tư vấn bên ngoài đã được trả gấp 5 lần những gì bạn tôi yêu cầu và họ không thể tìm được một nhân viên có trình độ để thay thế anh ta.

Đó là gần ba năm trước. Bạn tôi vẫn ở nơi mới của anh ấy và leo lên những bậc thang rất nhanh làm những gì anh ấy yêu thích.

Bệnh viện vẫn đang trả gấp 5 lần.

IMHO, tiền lương nên liên quan đến giá trị bạn cung cấp cho công ty .

CẬP NHẬT : Khi bạn di chuyển cao hơn trong hệ thống phân cấp, có hiệu ứng đòn bẩy xảy ra. Vì vậy, trên thực tế, bạn được trả tiền cho giá trị bạn mang lại. Nhưng những lập trình viên xuất sắc có năng suất cao gấp 10 lần nên được trả gấp 10 lần, bất kể vị trí của họ trong hệ thống phân cấp đó (thường ở dưới cùng). Đó là những gì tôi muốn làm nổi bật.

Họ chấp nhận nhiều rủi ro hơn các lập trình viên. Họ phải đưa ra quyết định dựa trên bất kỳ thông tin nào chúng tôi đã cung cấp cho họ và sau đó đối mặt với sự chỉ trích gay gắt của các bên liên quan khi kỳ vọng của họ không được đáp ứng. Một phần của gói thanh toán bù đắp cho rủi ro này.

Một yếu tố khác có thể là số năm kinh nghiệm cần thiết để chuẩn bị một người quản lý dự án có thể lập kế hoạch, ước tính và giảm thiểu đúng cách. Ở một khía cạnh nào đó, một người quản lý dự án sắc thái được đào tạo thông qua các thất bại, làm cho nó trở thành một kỹ năng đắt tiền để có được . Một khi đạt đến mức thâm niên, một công ty có thể không sẵn sàng từ bỏ nhân sự có giá trị như vậy.

Biên tập:

Có nhiều loại rủi ro hơn tổn hại tài chính hoặc vật chất. Ví dụ, xem xét nguy cơ bị người quản lý hoặc khách hàng khiển trách. Mặc dù không có tác hại thực sự nào được thực hiện, nhưng vẫn không đủ mong muốn để chúng ta điều chỉnh các hành vi của mình để tránh kết cục này. Tuy nhiên, các nhà quản lý phải đưa ra quyết định tốt mọi lúc, và phải cân bằng các loại rủi ro khác nhau vì lợi ích của công ty, không theo sở thích cá nhân.

Lập trình có thể khó khăn hơn bằng một số biện pháp, nhưng nó cũng dễ chịu hơn. Bạn chỉ cần ngồi đó và giải câu đố lập trình tốt đẹp trong khi các nhà quản lý đối phó với tất cả các loại nhảm nhí giữa cấp dưới, khách hàng của họ, ông chủ của chính họ và các bên liên quan. Đó là lý do tại sao rất ít người lành mạnh thực sự muốn trở thành người quản lý, vì vậy bạn phải bù đắp cho điều đó bằng cách trả nhiều tiền hơn.

Lập trình khó hơn, nhưng quản lý hút nhiều hơn.

Một cách để nghĩ giá trị của ai đó đối với công ty là tưởng tượng mọi thứ sẽ như thế nào nếu người đó rời công ty. Thông thường các nhà quản lý hóa ra có giá trị hơn theo nghĩa đó so với các lập trình viên. James Gosling , người tạo ra Java, gần đây đã rời khỏi Oracle. Người ta có thể nghĩ đó là một mất mát lớn, nhưng đoán xem? Thật ra nó không thành vấn đề. Nó hầu như không có bất kỳ ảnh hưởng nào đến Java hoặc trên Oracle. Chó sủa, nhưng đoàn lữ hành đi.

Nhân tiện, tôi (nghiêm túc) nghĩ rằng người quét bụi và người dọn dẹp nên được trả nhiều hơn so với lập trình viên. Dọn dẹp rác của người khác là một công việc tệ hại và không thể thiếu.

Giảm quản lý để tạo biểu đồ và viết tài liệu cũng giống như nói rằng lập trình đang gõ.

Đối với mỗi người, nhưng đối với tôi lập trình dễ hơn nhiều so với việc quản lý mọi người.

Mọi người ở đây đều tập trung vào những tiêu cực. Tôi chưa bao giờ gặp một lập trình viên thích chính trị văn phòng và những người quản lý giỏi che chở bạn khỏi thứ rác rưởi đó. Đã tiếp xúc với rất nhiều người tại khách hàng chính của chúng tôi, một nửa trong số họ là điên rồ và tôi rất vui khi có PM của mình ở đó để khắc phục sự điên rồ đó cho tôi. Nếu họ trả cho họ rất nhiều, thì tốt thôi. Anh ấy hoặc cô ấy cần nó cho liệu pháp không thể tránh khỏi.

Tất nhiên là có thể tranh cãi, nhưng một lý do quan trọng đằng sau điều này là họ mang trách nhiệm của dự án nếu thất bại, không phải các lập trình viên. Họ có thể cung cấp cho bạn một tai nghe để nâng cao thứ gì đó, nhưng họ phải đối mặt với sự chỉ trích từ các quyền lực cao hơn. Họ là những người chịu trách nhiệm lập kế hoạch và dự toán .

Quản lý đòi hỏi một bộ kỹ năng rất đa diện : kỹ năng con người, khả năng lãnh đạo, khả năng ước tính chi phí và thời gian. Để làm tất cả những điều này, họ cũng cần phải liên lạc với bạn về mọi thứ (nghĩa là có một chút manh mối về những gì bạn đang làm, nói về mặt kỹ thuật) hoặc là người đánh giá rất tốt về tính cách.

Nếu các yêu cầu không được xác định chính xác, đó là lỗi của họ.

Nếu kế hoạch kiểm tra không được xác định chính xác, đó là lỗi của họ.

Nếu bạn đi nghỉ hoặc bị gãy chân hoặc bị lãng phí vào tối thứ bảy hoặc rời đi mà không thông báo đầy đủ và họ phải tìm người thay thế hoặc <một số lý do tại đây> và bạn không thể thực hiện công việc của mình và sản phẩm không nhận được giao (đúng thời gian hoặc tất cả), đó vẫn là lỗi của họ .

Cũng lưu ý rằng khi tôi có nghĩa là họ thực hiện trách nhiệm, nó tác động đến những người ở trên và dưới họ . Nếu họ làm hỏng mọi thứ, đó có thể là công việc của nhóm bạn đang trên đường. Đó cũng là loại áp lực mà bạn được trả tiền.

PS: Thêm vào đó, tôi không biết liệu tôi có thể nói rằng lập trình khó hơn so với thực hiện các biểu đồ Gantt (để sử dụng lại ví dụ bạn đề cập). Tôi không biết về bạn, nhưng tôi thấy lập trình (nói chung, với 80% công việc bạn cần làm trong ngành) khá dễ dàng. Nếu bạn làm hỏng cái gì đó, bạn có thể sửa nó. Nếu sếp của bạn làm hỏng biểu đồ gantt của anh ấy hoặc ước tính chi phí của anh ấy, thì đó sẽ là một vấn đề lớn hơn nhiều so với việc đảo ngược một != nulla == null. Những lỗi nhỏ quan trọng trên phạm vi rộng hơn đối với họ. Tất nhiên, hầu hết thời gian, nếu bạn làm hỏng một bài kiểm tra như thế này trong một ứng dụng y tế nhúng được phát hành, đó cũng là một vấn đề lớn. Nhưng họ sẽ gặp nhiều vấn đề hơn bạn!

Cung và cầu là một mô hình kinh tế của việc xác định giá trong một thị trường. Nó kết luận rằng trong một thị trường cạnh tranh, đơn giá cho một hàng hóa cụ thể sẽ thay đổi cho đến khi nó giải quyết tại điểm mà lượng người tiêu dùng yêu cầu (ở mức giá hiện tại) sẽ bằng với số lượng được cung cấp bởi nhà sản xuất (ở mức giá hiện tại), dẫn đến một cân bằng kinh tế của giá cả và số lượng. Bốn định luật cơ bản của cung và cầu là:

• Nếu cầu tăng và cung không đổi thì giá và lượng cân bằng cao hơn.
• Nếu cầu giảm và cung không đổi thì giá và lượng cân bằng thấp hơn.
• Nếu cung tăng và cầu không đổi thì giá cân bằng thấp hơn và số lượng cao hơn.
• Nếu cung giảm và cầu không đổi thì giá cao hơn và số lượng thấp hơn.

Trong trường hợp này, một lý do là có quá nhiều nhà phát triển.

Tôi đã chuyển đổi giữa vai trò nhà phát triển và PM trong suốt sự nghiệp của mình. Tôi có các nhà phát triển cho dự án của mình kiếm được gấp đôi so với tôi và những người khác đang kiếm được một nửa. Những người có mức lương cao đang được trả lương vì họ là: A) Họ là những nhà phát triển "rockstar". B) Họ tương tác với khách hàng, giải thích sản phẩm theo cách dễ hiểu cho khách hàng và dễ hiểu. C) Họ chỉ đạo các nhóm các nhà phát triển làm việc trên nhiều dự án. D) Họ luôn sẵn sàng và mong muốn làm hài lòng.

Họ thực hiện vai trò của một nhà phát triển, PM và BA trong các năng lực khác nhau. Nói chung, nếu bạn dành 90% thời gian của mình, thì việc cắt mã sẽ không có giá trị và có thể dễ dàng thay thế. Nếu bạn muốn kiếm nhiều tiền hơn thì bạn cần phải chịu trách nhiệm nhiều hơn ... và có lẽ phải tìm một công ty khác sẽ trả cho bạn nhiều hơn.

Lý do là khu vực trách nhiệm của người quản lý dự án (thường) là giao toàn bộ dự án đúng thời hạn, với chất lượng chấp nhận được, trong một ngân sách theo kế hoạch. Thường có rất nhiều tiền bị đe dọa, vì vậy các nhà quản lý dự án giỏi thường có mức lương cao hơn các lập trình viên.

Tuy nhiên, tôi không cảm thấy rằng các nhà phân tích kinh doanh, trung bình, kiếm được mức lương cao hơn đáng kể so với các lập trình viên. Và tôi cảm thấy rằng nó trở nên ít phổ biến hơn rằng mức lương trong một công ty được xác định bởi hệ thống phân cấp chứ không phải bởi giá trị của một nhân viên.

Trải nghiệm của tôi có thể khác (hoặc tôi sống trong một vũ trụ khác với các định luật vật lý bị bóp méo), nhưng hầu hết các nhà phân tích kinh doanh và quản lý dự án (không phải người quản lý chương trình , nhưng người quản lý dự án hoặc PMP) tôi từng thấy ở mức hoặc thấp hơn một chút mức lương trung bình của lập trình viên.

Khoảng cách tiền lương bắt đầu nới rộng hơn khi so sánh với mức lương trung bình của các kỹ sư phần mềm (theo sở thích của người thiết kế phần mềm). Khoảng cách thậm chí còn nhiều hơn khi so sánh với EE cao cấp hoặc kỹ sư phần mềm cao cấp. Hầu như không có nhà phân tích kinh doanh cấp cao hoặc PMP cao cấp nào sẽ làm giống như một EE cao cấp hoặc kỹ sư phần mềm cao cấp / chính.

Tuy nhiên, một người quản lý chương trình (không giống như PMP), người đó sẽ kiếm được nhiều hơn bất kỳ ai khác (và lý do nên rõ ràng.)

Điều khiến tôi băn khoăn nhất khi tôi thấy những phàn nàn về lương này là với tư cách là lập trình viên (đặc biệt là lập trình viên cấp cơ sở / mới vào nghề), chúng tôi (hoặc không) đặc biệt. Không có gì thực sự trong một lập trình viên nhập cảnh ngay khi ra trường xứng đáng với mức lương của nhà khoa học tên lửa. Không .

Tất cả chúng tôi làm việc trên phần mềm bắt đầu từ con số không. Tất cả chúng tôi đã làm.

Và NẾU chúng tôi thực sự trung thực, chúng ta biết rõ rằng chúng tôi không biết tào lao. Có thể hoàn thành tải khóa học CS nâng cấp của chúng tôi chỉ là điểm khởi đầu. Nó không làm cho chúng tôi đặc biệt hay ZOMG !!!! uber-Einstvian. Thực sự không!

Chưa hết (và nhờ vào thời kỳ tồi tệ của bong bóng dot-com), chúng tôi hy vọng sẽ tạo ra không chỉ nhiều hơn, mà còn nhiều hơn một người có trình độ đại học khác chỉ vì OH WOW, chúng tôi là lập trình viên và họ chỉ là doanh nghiệp các nhà phân tích và PMP.

Bạn có thể đánh vần sự kiêu ngạo? Newsflash - đối với hầu hết các nhiệm vụ lập trình trong doanh nghiệp, bạn thậm chí không cần bằng cấp 4 năm. Thực sự, đó là nghiêm trọng.

Dành thời gian cho công việc và xây dựng kinh nghiệm để chuyển từ lập trình sang công nghệ phần mềm (hoặc kỹ thuật cho vấn đề đó) ở cấp cao. Sau đó, bạn có thể yêu cầu để làm cho nhiều, nhiều, pero mucho mucho nhiều hơn một nhà phân tích kinh doanh và PMP.

Làm cho nó qua với - một số người trong chúng ta (hoặc đã) trả quá cao. Giai đoạn = Stage.

Bỏ qua một bên: lý do để một nhà phân tích kinh doanh và / hoặc PMP đưa ra mức lương gần hoặc tương tự với các lập trình viên chưa tích lũy được thời gian và chuyên môn cần thiết để trở thành kỹ sư phần mềm trung / cao cấp (hoặc vẫn chưa phát triển chuyên môn trong lĩnh vực yêu cầu cao khu vực):

Một nhà phân tích kinh doanh là người liên lạc giữa phần mềm và hệ thống và người kinh doanh / quy trình kinh doanh (là những người chứng minh sự tồn tại của tiền lương của bạn, chứ không phải theo cách khác.) Họ là những người chịu trách nhiệm phá vỡ các quy trình kinh doanh theo phương pháp, cách phân tích, như đầu vào có thể chấp nhận được để hình thành các yêu cầu, những thứ bạn làm việc trên. Họ đảm bảo rằng bạn dành phần lớn thời gian để lập trình và không phải đối phó với những chi tiết vụn vặt trong kinh doanh.

Nhiều bạn nghĩ kinh doanh thật dễ dàng. Nếu bạn thực sự nghĩ đó là sự thật, Chúa sẽ giúp bạn.

Người quản lý dự án là người chịu trách nhiệm tung hứng nhiều dự án (trong khi bạn chỉ phải tung hứng với một hoặc hai người nhiều nhất vào bất kỳ thời điểm nào.) Anh ấy là chiếc ô của bạn, và anh ấy là người phải làm công việc bẩn thỉu nhất số đông chưa rửa còn lại không muốn làm - để đuổi mọi người xuống để đảm bảo họ làm công việc của họ hoặc loại bỏ những trở ngại cho công việc của bạn.

Anh ấy là người sẽ hỏi bạn "bạn đang làm gì vậy? Bạn đang làm gì để giúp chuyển dự án theo? Bạn có vấn đề gì với công việc của bạn không? Trở ngại của bạn là gì, bạn cần gì? Ai có thể đưa nó cho bạn? "...

và sau đó anh ta sẽ đi đến những người khác hỏi những câu hỏi khó tương tự, đảm bảo rằng các chướng ngại vật được loại bỏ và đảm bảo rằng bạn đang giảm cân cho dự án (nếu cần thiết.)

Vấn đề số một tôi từng thấy trong nhiều dự án thất bại là thiếu PMP hoặc thiếu tôn trọng PMP (đặc biệt là từ các nhà phát triển.) Rất hiếm khi tôi thấy các dự án thất bại vì PMP không đủ năng lực, và người ta phải tự hỏi tại sao nhiều lập trình viên nhiều hơn mong muốn nói rằng đó là trường hợp.

Tôi đang ở trong lĩnh vực tài chính và tôi nghĩ rằng tâm lý là giống nhau trong hầu hết các trang phục phi công nghệ:

Trả lương tỷ lệ thuận với rủi ro nghề nghiệp

Chặn hoàn toàn việc sa thải một nhóm hoặc nhóm, các lập trình viên cấp thấp luôn giữ công việc của họ. Đó là bản chất của công việc, và các lập trình viên đi sâu vào nó biết rõ rằng họ đang chấp nhận rủi ro bằng không. Nếu có một lỗi, đó không phải là đầu của họ trên khối chặt.

Ở cấp độ cao hơn, nếu một cái gì đó vít lên, bạn là người đầu tiên đi. Tôi đã có nhiều kinh nghiệm với một nhân viên cấp dưới mắc một lỗi đánh máy nhỏ dẫn đến việc chúng tôi bị mất tiền và tôi đã chịu nhiệt cho nó (không phải là lập trình viên thực sự mắc lỗi).

Rất đơn giản, tiền lương tương xứng với rủi ro. Mặt khác, các lập trình viên không nhất thiết phải có bất kỳ giao diện nào trong trò chơi.

Nếu câu hỏi của bạn là "tại sao X và Y có mức lương cao hơn các lập trình viên tại công ty của tôi " thì tôi có thể đã trả lời "bạn có thể làm việc ở công ty sai."

Thành công của một công ty trong kinh doanh phần mềm phụ thuộc nhiều vào khả năng của các lập trình viên hơn bất kỳ ai khác. Các công ty không nhận ra điều này sẽ tự động gặp bất lợi so với những công ty có được nó. Thuê các lập trình viên giỏi nhất và chăm sóc họ là cách tốt nhất của bạn. Sự khác biệt trong công việc của các lập trình viên vĩ đại so với phần còn lại là rất lớn; cách lớn hơn mức chênh lệch lương họ chỉ huy. Nhưng nếu bạn khăng khăng trả tiền cho các lập trình viên của mình, bạn sẽ nhận được những gì bạn phải trả cho.

Điều đó nói rằng, mọi vai trò khác trong kinh doanh đều quan trọng. Các nhà quản lý tuyệt vời có tác động rất lớn. Rất nhiều trong số đó là bằng cách có được những lập trình viên tuyệt vời và giữ cho họ hạnh phúc. Một cái gì đó tương tự có thể được nói về phân tích kinh doanh, tiếp thị, bán hàng, thử nghiệm và hỗ trợ.

Nếu bạn là một lập trình viên tuyệt vời và bạn không được khen thưởng xứng đáng, hãy đi đến một nơi khác. Sau đó, một lần nữa, bạn có thể không phải là một lập trình viên tuyệt vời. Thật không may nếu bạn không tuyệt vời, thật khó để biết tại sao. Nếu bạn biết tại sao, bạn có thể thay đổi và trở nên tuyệt vời, phải không?

Tôi đã là một lập trình viên và tôi đã là một người quản lý. Tôi đã làm việc với rất nhiều lập trình viên tuyệt vời, nhưng chỉ có một vài người quản lý tuyệt vời. Khi tôi là một người quản lý, tôi không tuyệt vời, nhưng ít nhất tôi biết điều đó. Người của tôi đã tăng nhiều hơn tôi đã làm, mà họ xứng đáng.

Nó ít liên quan đến kỹ năng và công việc, ý tôi là rất ít trong nền kinh tế gắn liền với số tiền mà mọi người xứng đáng kiếm được.

Xứng đáng để kiếm được nhiều tiền hơn là một ý tưởng phù du, mọi người đều tin rằng họ xứng đáng để kiếm được nhiều tiền hơn.

Mặc dù có thể không công bằng, các nhà quản lý kiếm được nhiều tiền hơn chỉ vì các chủ doanh nghiệp tin tưởng họ hơn. Các nhà quản lý thường nhận được mức lương cao hơn, đơn giản vì vậy họ sẽ không nhận một công việc mới bất thường vào thời điểm bất tiện.

Tôi nghĩ rằng toàn bộ cơ sở của bạn cho câu hỏi này là thiếu sót.

Quản lý phải được trả nhiều hơn cấp dưới của họ. Thâm niên trong một công ty thường dựa trên tiền lương, và không có cách nào một nhân viên cấp dưới có thể có phương tiện để chỉ huy người cao niên của họ.

Người dẫn đầu là một kỹ năng chuyên môn. Không phải ai cũng có thể là người quản lý dự án (PM). Nhiệm vụ ngày càng khó khăn hơn khi số lượng nhân viên tăng lên. Trong vai trò PM kỹ thuật, Thủ tướng cần phải nắm bắt tốt công nghệ để lãnh đạo hiệu quả - hoặc họ sẽ không có sự tôn trọng và hỗ trợ của cấp dưới.

Trong nhiều ngành nghề, một kỹ năng cốt lõi là khả năng bán một thứ gì đó. Và để bán một cái gì đó sẽ, bạn cần phải bán chính mình. Bạn cần người mua tin tưởng bạn và đánh giá cao sản phẩm hoặc dịch vụ mà bạn cung cấp nhiều như bạn dự định. Kỹ năng này hoàn toàn có thể chuyển sang đàm phán lương.

Tôi đã xem qua tất cả các bài đăng và tôi dám nói rằng hầu hết trong số họ đang cố gắng so sánh táo và chuối.

Trước hết, tôi tin rằng ai đó nói rằng 'quản lý là miếng bánh' không bao giờ phải quản lý bất cứ điều gì ngoài lịch trình của chính mình. Mặt khác, nói rằng 'bất cứ ai cũng có thể mã hóa bất cứ điều gì' là ngớ ngẩn (và trong diễn đàn sai, vì Chúa!).

Tôi đặc biệt thích rwong và luis.espinal asnwers, mặc dù tôi tin rằng có những sự thật khác cũng cần được chú ý.

Tôi không tin hệ thống phân cấp là một câu trả lời - không phải ngày nay - mặc dù nó hoàn toàn phù hợp trong 10.000 năm qua. Chúng tôi đã sống trong nhiều thế kỷ trong một xã hội nơi lợi nhuận của bạn càng cao, sức mạnh của bạn (và ngược lại) càng cao. Tôi không tin rằng nó áp dụng cho thế giới của chúng ta, theo cách nó (đặc biệt là trong khu vực của chúng tôi).

Quay lại câu hỏi chính, tôi tin rằng các nhà quản lý thường kiếm được nhiều tiền hơn bởi vì họ có giá trị hơn đối với một công ty không phải vì anh ta cao hơn về thứ bậc, nhưng anh ta cao hơn vì

• tất cả kiến ​​thức anh ta thu thập được từ các kinh nghiệm trước đây (thường là các lập trình viên có ít kinh nghiệm hơn các nhà quản lý nói chung)
• để có thể quản lý nhiều thứ cùng một lúc (lập trình viên có một nhiệm vụ - hoặc một danh sách nhiệm vụ - để hoàn thành, trong khi các nhà quản lý phải tự quản lý các nhiệm vụ của mình
• họ là người liên lạc chính cho dự án mà họ quản lý và vì lý do này, họ là 'mục tiêu' đầu tiên trong trường hợp có sự cố xảy ra. Sẽ dễ mất việc hơn nếu bạn là người quản lý; là một nhà phát triển, bạn có 'giấy phép để làm lại một cái gì đó'. Đó là yếu tố 'rủi ro' mà mọi người đề cập.
• nhà phát triển là một phần của toàn bộ vòng đời dự án. Tôi tin rằng khi chúng ta nói ở đây về 'lập trình viên', chúng ta cũng đang nghĩ về những người thử nghiệm, các nhà văn kỹ thuật và tất cả những người khác rất quan trọng cho sự thành công của dự án.
• và có một thứ mà tôi chỉ thấy trong một vài bài viết về chủ đề này: lãnh đạo. Trở thành một người quản lý là biết cách liên lạc với mọi người, đàm phán, giữ cho mọi người có động lực, để tạo ra sức mạnh tổng hợp khi tâm trạng của mọi người không ổn.

Theo tôi, yếu tố lãnh đạo là lý do chính cho mức lương cao hơn, bởi vì nó tạo ra một kết quả lâu dài rất lớn cho công ty và cho tất cả những người xung quanh lãnh đạo.

BTW, tôi chỉ có một vài kinh nghiệm với tư cách là trưởng nhóm (không phải là trưởng nhóm dự án!) Và tôi càng biết những gì một nhà lãnh đạo làm, càng nhiều công việc tôi nhận ra tôi phải làm.

Chỉnh sửa: Quên làm nổi bật: kỹ năng giao tiếp không phải là một điểm mạnh đối với hầu hết chúng ta, nhưng là điều bắt buộc đối với một nhà lãnh đạo. Bên cạnh đó, tôi muốn chia sẻ một bài viết rất hay tại Coding H khiếp sợ, liên quan đến các lập trình viên giỏi và kỹ năng giao tiếp -> http: //www.codinghorror.com/blog/2011/02/how-to-write-without- Writing .html

Hãy nghĩ về nó theo cách này, số lượng các nhà quản lý có kỹ năng ít hơn số lượng lập trình viên lành nghề, do đó các nhà quản lý có giá trị hơn đối với các công ty.

Điều đó phụ thuộc vào cách bạn xác định "khó khăn". Mặc dù vậy, tôi tự hỏi liệu bạn có biết Quản lý dự án là gì và các Nhà phân tích kinh doanh nên làm gì không. Tôi đọc nhiều thất vọng từ câu hỏi của bạn, vì vậy tôi nghĩ rằng bạn có một số kinh nghiệm xấu. Không bao giờ là ít hơn, tôi muốn cố gắng trả lời câu hỏi của bạn.

Người quản lý dự án và Nhà phân tích kinh doanh thường 'già' hơn khi họ hoàn thành các vị trí đó. Khi các nhà phát triển bắt đầu sự nghiệp của họ rất trẻ (khoảng 20 tuổi), hầu hết các nhà quản lý và phân tích dự án đều gần 30 tuổi (điều này đã tạo ra sự khác biệt trong thanh toán chỉ bằng tuổi). Họ cũng là những người phải đối mặt với việc tiếp xúc với khách hàng, điều đó có nghĩa là họ phải đi lại tại chỗ, dành hàng giờ tra tấn để lắng nghe khách hàng (đặc biệt là khi dự án bị trục trặc) và tranh thủ những mong muốn / nhu cầu của họ. Họ phải cẩn thận với những gì họ hứa và đặc biệt là trong phạm vi nào (thời gian giao hàng). Mặc dù theo quan điểm của bạn rằng những gì họ làm chỉ là tài liệu, các nhà phân tích kinh doanh được giáo dục để phân tích nhu cầu cho doanh nghiệp và các nhà quản lý dự án đang bảo vệ việc lập kế hoạch dự án.

Họ hoạt động như một tường lửa giữa khách hàng và nhà phát triển. Một quan điểm kỹ thuật là một cái gì đó khác với một quan điểm bán hàng. Hầu hết các nhà phân tích kinh doanh và quản lý dự án cũng đang phải đối mặt với một lượng lớn khách hàng - họ được tiếp xúc và có 'khách hàng tiềm năng'. Mạng lưới của họ bao gồm những người ra quyết định và do đó các công ty thích giữ mọi người với các mạng như vậy trong tầm tay; sau khi bán hàng là bán hàng

Liên quan đến khó khăn? Bắt đầu một công ty, có mười nhà phát triển và cố gắng quản lý một dự án. Đau đầu đi kèm với nó miễn phí. Làm điều này trong một năm và sau đó nhìn vào câu trả lời của bạn một lần nữa. Dành cho BA? Đi cho một cơ hội như vậy. Hãy ngồi xuống với những khách hàng có máy AIX từ năm 1974 và người thiết kế hệ thống đó đã chết / nghỉ hưu / chết / alzeheiming và nhà phát triển cần biết liệu một giá trị nào đó được tạo ra hay có một công thức thần bí nào đó. Cố gắng thuyết phục 20 người bằng một powerpoint về giải pháp của bạn trong vòng 3 ngày. Nếu tài liệu là 'dễ dàng', Linux sẽ làm khuynh đảo cả thế giới vào năm 1997. Thực sự, hãy thử viết một tờ giấy trắng kỹ thuật mỗi tháng cho những người không có kỹ thuật (những người nghĩ rằng Facebook là một cuộc cách mạng trong điện toán).

Tôi là một kỹ sư bán hàng. Điều đó có nghĩa là, tôi phát triển nhưng chuyên môn của tôi là dành cho các nguyên mẫu và trình diễn. Và tôi kiếm được nhiều hơn một nhà phân tích kinh doanh hoặc một người quản lý dự án. Không phải vì tôi có một mạng lưới (mặc dù vậy), nhưng vì tôi đã để lại thái độ và tập trung hơn vào quan điểm kinh doanh, tôi đã được chứng nhận và tự dạy mình một số kỹ năng mềm. Và kinh nghiệm để học được rằng 'không' cũng là câu trả lời, khi nói đến việc làm thêm giờ.

Câu trả lời đơn giản: Chúng có giá trị hơn đối với công ty so với lập trình viên.

Tại sao? Bởi vì họ đảm bảo rằng các dự án được hoàn thành, ngay cả khi họ không tự lập trình. Điều đó có nghĩa là giá trị của họ (hoàn toàn về mặt tiền tệ đối với công ty) không chỉ là một lập trình viên cá nhân. Công ty không tin rằng các lập trình viên không được quản lý là hiệu quả, và do đó có giá trị ... Chỉ có người quản lý làm cho họ như vậy.

Sucks, và chúng tôi có thể không thích nó, nhưng đó là lý do tại sao công ty trả tiền cho họ nhiều hơn.

Vị trí của họ (như những người khác đã chỉ ra) đi kèm với những hạn chế: Mặc dù họ không hoàn thành một dự án trong một thời gian nhất định, đó là lỗi của họ, không phải các lập trình viên. Họ gánh vác nhiều trách nhiệm hơn và rất có khả năng bị sa thải vì thất bại (trừ khi có một số gia đình trị của công ty BS đang diễn ra).

Vì vậy, thực sự, họ không được phép phạm sai lầm, gây áp lực hơn cho họ và có một công việc biến động hơn nhiều ... nhưng đừng nhầm lẫn: Đây không phải là lý do tại sao họ được trả nhiều hơn - một công ty không cung cấp cho một con chuột của bạn bao nhiêu áp lực, vị trí của bạn biến động như thế nào, bất cứ điều gì như thế. Họ chỉ quan tâm giá trị bạn mang lại cho công ty. Giai đoạn = Stage.

Đó là chủ nghĩa tư bản, folks.

Tôi không biết kiến ​​thức về Biểu đồ Gantt cần được cập nhật bao nhiêu lần trong một năm. Nhưng khi lập trình, bạn cần cập nhật cho mình những công nghệ mới, điều này sẽ không dễ dàng với tuổi của bạn.

Học một công nghệ mới cần nhiều giờ mồ hôi, nếu bạn đủ thông minh để tiếp thu.

Kỹ năng đạt được trong nhiều năm làm lập trình không được coi trọng nhiều trong văn hóa công ty hiện tại.

So sánh mức lương lập trình viên mới tốt nghiệp với một người có hơn 10 năm kinh nghiệm là một câu chuyện hơi buồn.

So sánh một PM mới với PM 10 năm là một câu chuyện tuyệt vời, PM có thể trở thành Giám đốc sau 10 năm kinh nghiệm.

Vậy tại sao vẫn còn rất nhiều người muốn học CNTT trong trường đại học? Tôi không hiểu Họ đã được thông báo chính xác?

Tôi không hiểu làm thế nào mọi người đánh giá cao các kỹ năng ngày nay.

Vì những lý do chính xác tương tự mà một CEO có thể kiếm được gấp 263 lần so với công nhân trung bình của họ.

Quản lý không phải lúc nào cũng kiếm được nhiều hơn nhân viên kỹ thuật. Các nhân viên kỹ thuật cấp cao nên tích cực tham gia phân tích cấp kinh doanh và ra quyết định và lập biểu đồ lộ trình kỹ thuật cho công ty. Khi gặp trường hợp này, đội ngũ kỹ thuật cao cấp có thể kiếm được nhiều hơn một chút so với các nhà quản lý doanh nghiệp mà họ làm việc hàng ngày.

Một trong những huyền thoại phổ biến về kinh doanh là người quản lý nên được trả nhiều hơn sau đó những người mà anh ấy / cô ấy quản lý. IMO, bạn thấy khái niệm này cố gắng sâu sắc hơn trong các vụ thảm sát hơn là trong các nhóm chức năng, nhanh nhẹn.

Nói cách khác: bồi thường được cho là phản ánh giá trị đóng góp của một người cho công ty. Có những người quản lý doanh nghiệp xuất sắc và người quản lý trung bình, và có những kỹ sư xuất sắc và những người làm việc trung bình. Nếu bạn có một kỹ sư xuất sắc chuyên về công nghệ kiếm tiền và có kiến ​​thức sâu rộng về công nghệ của công ty, thì đó có phải là lợi ích tốt nhất của công ty để bù đắp cho người này một cách tích cực hơn một giám đốc kinh doanh bình thường đang quản lý kỹ sư xuất sắc này không? Chi phí cơ hội của việc mất chuyên môn kỹ thuật và bộ kỹ năng đó là gì vì bạn đã bỏ qua nguồn tài nguyên quý giá này?

Tôi đã bắt đầu một tháng trước với dự án đầu tiên của tôi là một PM. Trước khi tôi làm lập trình viên. (nhân tiện, tôi nhận được tiền như trước đây.)

Tôi phát hiện ra rằng trở thành một PM tốt có nghĩa là trở thành một lập trình viên giỏi với nhiều kinh nghiệm. Bạn sẽ có thể đi từ thành viên nhóm này sang thành viên khác và thảo luận về các vấn đề họ đã sử dụng kinh nghiệm thực tế của bạn để giúp họ hiểu vấn đề bằng cách đưa ra quan điểm khác. Nhiệm vụ của bạn là, ngoài việc khác, để quản lý các giao diện. Một PM giống như một nhạc trưởng. Bạn có thể có những nhạc sĩ giỏi nhất nhưng nếu bạn không có một nhạc trưởng giỏi, người biết chơi dàn nhạc cụ meta tốt, bạn sẽ chỉ gặp một mớ hỗn độn.

Đối tác là chuyên gia. Đây là lập trình viên có khả năng giải quyết các vấn đề khó khăn vì anh ta có kiến ​​thức sâu rộng về miền vấn đề. Những người có kinh nghiệm này thường được trả lương cao nếu họ đủ giỏi trong đàm phán. Thật không may, các chuyên gia thường là những người mọt sách và không quan tâm đến tiền hoặc giỏi trong việc thực hiện một thỏa thuận tốt ...

Các lập trình viên không đặt mức lương là ưu tiên cao nhất (Giả sử nó ở mức hợp lý.). Hãy tưởng tượng hai lời mời làm việc trong đó một người có mức lương cao hơn, cam kết cùng thời gian, nhưng yêu cầu hỗ trợ kỹ thuật, giờ làm việc nghiêm ngặt, quy định trang phục, viết tài liệu người dùng, xử lý mã kế thừa bằng ngôn ngữ cổ mà bạn hy vọng bạn sẽ không bao giờ phải sử dụng nữa, làm thế nào nhiều tiền lương hơn bạn sẽ yêu cầu?

Nếu bạn làm việc cho một công ty tôn trọng lập trình, toán học, giải quyết vấn đề, bất kỳ kỹ năng nào, thì bạn có thể kiếm được nhiều tiền hơn cho hai điều:

• Làm việc khó hơn
• Chịu trách nhiệm nhiều hơn

Chỉ vì Bệnh viện không trả nhiều tiền cho DBA lành nghề của họ (xem ví dụ trong câu trả lời đầu tiên) không có nghĩa là điều này giống nhau ở mọi công ty.

Được rồi, tôi hơi ngạc nhiên với câu trả lời, vì vậy nó ở đây. Nhưng trước đó, tôi sẽ chỉ muốn làm rõ rằng tôi là một Lập trình viên và không có gì tôi thích hơn Lập trình. Điều đó nói rằng tôi có một sự quan tâm lành mạnh và tôn trọng các Thủ tướng và BA có thẩm quyền . Tôi nhận ra rằng nhiều người trong chúng ta phẫn nộ PM và BA vì không giống như lập trình, có thể vượt trội trong họ mà không cần trình độ năng lực cần thiết (chính trị văn phòng, bộ đồ đẹp, v.v.).

Tuy nhiên, cả Quản lý dự án và Phân tích kinh doanh đều là những thành phần quan trọng của sự phát triển phần mềm.

Bất cứ khi nào chúng ta nghĩ về phát triển phần mềm, nhiều người trong chúng ta có xu hướng chỉ tập trung vào lập trình để loại trừ mọi thứ khác. Tuy nhiên, có nhiều thứ hơn là mã hóa.

Mục đích đầu tiên của sự phát triển, đó là tạo ra một phần mềm thực sự giải quyết và giải quyết các vấn đề của khách hàng. Điều này ngụ ý đầu tiên thực sự tìm ra các yêu cầu của khách hàng (vì khách hàng có thể không thực sự chắc chắn về những gì anh ta muốn), điều này chỉ có thể bằng một phân tích chi tiết về miền mà khách hàng vận hành và cấu trúc của các hiện vật khác nhau (cho dù đó là con người, cơ sở hạ tầng kỹ thuật hoặc quy trình), và sau đó phát triển giải pháp kinh doanh phù hợp (và tích hợp với công nghệ) để giải quyết các yêu cầu đó.

Tương tự, bất kỳ dự án nào có quy mô đáng kể hoàn toàn không thể hoạt động mà không có quản lý hiệu quả. Bây giờ tôi không biết nó ở những nơi khác như thế nào, nhưng cho đến nay kinh nghiệm của tôi là các PM thường được thăng cấp từ hàng ngũ lập trình viên, vì vậy họ có một số ý tưởng về những gì cần thiết để tổ chức và thực hiện dự án.

Để tóm tắt cả BA và PM là lớp trừu tượng để phát triển .

Nhiều người nói ở đây, lập trình khó khăn hơn và đó là lý do tại sao nó nên kiếm được nhiều tiền hơn. Đó là một quan điểm rất lãng mạn. Sự thật là, trong một công ty bình thường, khỏe mạnh, việc thanh toán là theo trách nhiệm , điều đó có nghĩa là giá trị gia tăng của người đó và cả rủi ro .

Nguy cơ thường sẽ bị lãng quên. Thông thường nếu lập trình viên thất bại trong công việc khó làm của mình, có thể có một số chi phí tăng lên, nhưng không có gì hơn. Không giống như 10% công nhân sẽ mất việc hoặc một cái gì đó tương tự. Rủi ro khá thấp.

Ngoài ra tôi muốn không đồng ý với ý kiến, rằng hầu hết những người kinh doanh kiếm được nhiều tiền hơn. Tôi cá là anh chàng kinh doanh bình thường kiếm được ít tiền hơn thì hầu hết các Cử nhân Khoa học / Kỹ thuật sẽ kiếm được. Ví dụ như một lập trình viên kỳ nghỉ đại học, tôi kiếm được gần giống như một số công nhân kinh doanh toàn thời gian trong cùng một công ty.

Và cuối cùng nhưng không kém phần quan trọng, tại sao người quản lý dự án không phải là kỹ sư? Thông thường người quản lý dự án là một anh chàng có nhiều năm đứng đầu trong chủ đề của dự án mà anh ta quản lý, nghĩa là trong công việc lập trình, đó sẽ là một lập trình viên giàu kinh nghiệm, là người quản lý dự án.

Có các môi trường doanh nghiệp trong đó mẫu lệnh và điều khiển hoặc mẫu giao tiếp trung tâm và nói chiếm ưu thế. Trong các tổ chức này, người quản lý và người giao tiếp chính thường là cùng một người. Điều này làm cho người quản lý một điểm thất bại duy nhất - bất kỳ tác động ảm đạm nào của thông tin sai lệch hoặc bản dịch bị mất được khuếch đại. Do đó, các môi trường này đòi hỏi những người có nền tảng kỹ thuật rộng rãi là người quản lý để đảm bảo độ chính xác.

Các đội được tổ chức tốt hơn thường chỉ định một người giao tiếp chính để giảm bớt trách nhiệm này. Các tổ chức thực hành quản lý kiến ​​thức không có bất kỳ điểm thất bại nào trong giao tiếp. Trong các tổ chức này, các nhà quản lý và các nhà truyền thông chính thu hút thông tin và tạo điều kiện cho các cuộc thảo luận. Những thông tin này sẽ được nắm bắt và xử lý để chia sẻ nội bộ. Một bộ kỹ năng xã hội khác nhau được yêu cầu.

Tương tự như vậy, các nhà phân tích kinh doanh thường là người liên lạc duy nhất giữa khách hàng và nhân viên kỹ thuật của công ty.

Đây không phải là luôn luôn như vậy. Khi tôi làm việc cho Tập đoàn Khoa học Máy tính (CSC), hầu hết các nhà quản lý đã kiếm được ít hơn so với "những người sản xuất thứ gì đó hữu ích". Trong trường hợp của CSC, tôi nghĩ rằng đây là trường hợp vì công ty đã được bắt đầu bởi một nhóm lập trình viên.

Vào thời điểm đó (1970) có một công ty phần mềm khác ở LA mà tôi quên tên với một bảng lương thú vị. Các lập trình viên được trả 25.000 đô la / năm và nhân viên hỗ trợ được trả 15.000 đô la / năm. Ý tưởng là nếu bạn là lập trình viên tồi tệ hơn ở đó, bạn không nên ngạc nhiên khi bị thay thế.