Làm thế nào để tôi làm cho trường hợp cho các lập trình viên đắt tiền?

Trong công ty của chúng tôi, chúng tôi cần thực hiện nhiều việc dường như không phức tạp, như phát triển Giao diện người dùng di động.

Giả sử các lập trình viên có kinh nghiệm tiêu tốn của chúng tôi gấp 4 lần so với người mới bắt đầu.

Cả hai về cơ bản có thể hoàn thành những điều dường như đơn giản trong cùng một khoảng thời gian.

Sự khác biệt là, các lập trình viên có kinh nghiệm tạo ra ít lỗi hơn và mã của họ ổn định hơn v.v ... Các lập trình viên mới bắt đầu lãng phí rất nhiều thời gian của mọi người khác (PM, khách hàng, v.v.). Nhưng chúng rẻ hơn đáng kể.

Đối số truy cập là, cần có kinh nghiệm và người mới bắt đầu cùng một lượng thời gian để tạo một bảng trong HTML. Do đó, thật xa xỉ khi thuê các lập trình viên có kinh nghiệm để làm, những gì lập trình viên mới bắt đầu cũng có thể đạt được.

Chúng ta có nên đầu tư vào các lập trình viên ngày càng tốt hơn hay nhiều PM hơn và tốt hơn, cho rằng sự khác biệt giữa lập trình viên có kinh nghiệm và lập trình viên mới trong lĩnh vực của chúng ta có thể là 4x.

Tôi có kinh nghiệm đầu tiên về cả hai lý thuyết đang được thử nghiệm trong thế giới thực - trong cùng một dự án.

Trước khi tôi đến, quyết định đã thuê các BA đắt tiền hơn và các lập trình viên rất rẻ - ý tưởng là có các thông số kỹ thuật chất lượng tốt được theo dõi bởi các lập trình viên rất nhỏ.

Sau hơn 6 tháng của dự án chính xung quanh, tôi đã đảm nhận vị trí giám đốc phát triển. Khi tôi đã sửa một vài yếu tố vệ sinh, vấn đề về chất lượng mã vẫn còn. Tôi đã có một số ngân sách dự phòng và thuê một lập trình viên rất có kinh nghiệm (tốt hơn là một Kiến trúc sư giải pháp) với các kỹ năng giao tiếp ngoài bảng xếp hạng và có một đời làm giảng viên ở C # (ngôn ngữ mà dự án được viết). Ý tưởng là để cải thiện chất lượng của các lập trình viên khác bằng cách cung cấp tư vấn và đào tạo miễn phí hiệu quả.

Sau một hoặc hai tháng, điều rõ ràng là thậm chí nó sẽ không hoạt động nên nhóm ban đầu đã bị xóa khỏi dự án và một vài lập trình viên hàng đầu khác đã được thêm vào. Họ đã giao dự án mà nhóm ban đầu đã hoàn toàn thất bại trong hơn 8 tháng cố gắng trong 3 lần chạy nước rút bắt đầu từ đầu vì mã ban đầu là không thể sửa chữa được.

Nếu các yêu cầu của bạn rất cơ bản, bạn có thể thoát khỏi việc sử dụng một lập trình viên rất nhỏ, nhưng khả năng là chúng sẽ tốn kém hơn rất nhiều trong thời gian dài. Đôi khi các yêu cầu "đơn giản" phát triển thành sự phức tạp lớn.

Nếu tôi không đưa ra lựa chọn khó khăn để thay đổi hướng, có lẽ họ vẫn sẽ làm việc với nó :) - Nghiêm trọng hơn, trong ví dụ này, việc thiếu thông tin liên lạc và năng lực của nhóm ban đầu có nghĩa là họ sẽ không nêu vấn đề với đặc điểm kỹ thuật nhưng sẽ chỉ cố gắng làm bất cứ điều gì họ được yêu cầu làm cho dù nó có ý nghĩa về mặt kiến ​​trúc hay không. Một nhà phát triển có kinh nghiệm và tự tin hơn đã đặt câu hỏi và tìm hiểu các yêu cầu cơ bản và do đó cuối cùng đã tạo ra giải pháp phù hợp .

Ồ, một điều khác. Đừng cho rằng bạn có thể ngay lập tức thuê một lập trình viên tuyệt vời. Có rất nhiều người dân ngoài kia với nhiều năm kinh nghiệm về sự tầm thường sẽ mang lại kết quả tồi tệ như một thiếu niên nhưng sẽ có giá tương đương một siêu sao (đôi khi còn nhiều hơn). Tôi có một "tỷ lệ trúng" rất tốt nhưng điều đó đi kèm với kinh nghiệm và tôi có rất nhiều. Đó là chủ đề của một cuộc trò chuyện hoàn toàn khác ngoài chủ đề ở đây ...

TL; DR Lập trình viên giỏi là một món hời. Một chút khó khăn là tìm ra chúng và tạo ra một môi trường làm việc đủ hấp dẫn để giữ chúng.

Nếu bạn có số liệu thống kê hiệu suất sâu rộng, bạn có thể thực hiện trường hợp kinh doanh bằng toán học. Những điều này có thể cho thấy tốc độ phát triển sẽ bù đắp cho việc tăng giá, hoặc thậm chí tốt hơn, rằng một thiết kế mạnh mẽ có thể tiết kiệm nhiều hơn trong việc bảo trì và phát triển các phiên bản tiếp theo. Thật không may, những con số như vậy không có sẵn thường xuyên - đặc biệt là đối với các công nghệ mới hơn.

Một lập luận khác có thể là thời gian để thị trường. Điều này dễ hiểu hơn bởi quản lý cấp trên. Tuy nhiên, nếu thời gian không thực sự quan trọng, điều này sẽ không có ích.

Trong phương sách cuối cùng, tìm thấy một hình ảnh của Red Adair , người lính cứu hỏa nổi tiếng, người được gọi đến trong một thảm họa lớn sau nhiều nỗ lực không thành công của những kẻ ít kinh nghiệm. Câu nói nổi tiếng của ông:

Nếu bạn nghĩ rằng việc thuê một người chuyên nghiệp là tốn kém, hãy đợi cho đến khi bạn thuê một người nghiệp dư.

... Xứng đáng được in màu và hiển thị nổi bật trên cửa văn phòng của bạn, để mọi người hiểu tất cả những gì về nó ;-)

Tôi thích và nâng cao câu trả lời của maptle, nhưng tôi muốn đề cập đến một số động thái và lập luận khác mà các câu trả lời khác chưa đưa ra.

Đầu tiên, ẩn ý trong câu trả lời của maptle là thực tế là dưới một cấp độ kỹ năng nhất định, một số vấn đề là không thể. Thật không may, cách bạn phát hiện ra điều này là do nhóm của bạn cố gắng và thất bại, điều này rấtđắt. Sau khi thất bại, có hai bài học có thể học được từ điều này. Một lựa chọn là bạn học được rằng bạn cần nhiều nhà phát triển có năng lực hơn và vì vậy bạn thuê họ và bạn hoàn thành dự án vượt quá ngân sách và vượt tiến độ, nhưng ít nhất bạn đã chuẩn bị trong tương lai. Tùy chọn khác là một dự án như vậy là "quá khó" cho nhóm của bạn và những điều đó không nên được thử trong tương lai, tức là bạn từ bỏ dự án và thực sự có bất kỳ dự án tương tự nào. Tất nhiên, sẽ hiếm khi được gọi là "chúng tôi quá ngu ngốc để làm điều này", nhưng thay vào đó sẽ được hợp lý hóa là "hệ thống của chúng tôi rất phức tạp" hoặc "chúng tôi có rất nhiều mã kế thừa" hoặc một số mã khác. Quan điểm sau này có thể làm cong đáng kể quan điểm của một công ty về những gì có thể và thời gian phát triển / tốn kém sẽ là bao lâu. "

Một câu hỏi là, chính xác kế hoạch của công ty bạn là gì? Được rồi, họ sẽ thuê các lập trình viên cơ sở giá rẻ. Ba năm trôi qua, bây giờ thì sao? Họ làm gì với nhà phát triển đã ở bên họ suốt ba năm đó? Có phải họ không bao giờ tăng lương cho anh ấy / cô ấy? Các tùy chọn ở đây như sau:

• Họ đưa ra mức tăng cạnh tranh để giữ chân nhân viên, trong trường hợp nào tại sao họ lại gặp vấn đề trong việc trả lãi suất cho nhà phát triển cao cấp bây giờ? Tôi sẽ trở lại điều này mặc dù.
• Họ có tỷ lệ trì trệ, điều đó có nghĩa là cuối cùng họ sẽ "sôi sục" với những nhân viên thiếu lái xe và / hoặc kỹ năng.
• Họ chủ động loại bỏ nhiều nhân viên cao cấp hơn.

Hai trường hợp thứ hai ngụ ý rất nhiều sự thay đổi nhân viên, điều đó có nghĩa là mất kiến ​​thức của công ty và trả tiền cho nhân viên làm việc liên tục. Trong trường hợp thứ hai, về cơ bản, bạn đang chọn các nhà phát triển tồi và do đó chi phí sẽ tăng theo hình thức tăng lịch trình. Cách thức này sẽ diễn ra là mọi thứ đều ổn trong dự án X cho đến khi đột nhiên Jim rời đi, một trong những nhà phát triển tốt hơn, bởi vì anh ta đã không được tăng lương trong hai năm, bây giờ dự án sẽ "hiểu được" lâu hơn đáng kể bạn cần phải thuê và đào tạo các nhà phát triển cơ sở mới, những người (có lẽ) sẽ không giỏi như Jim. Đây là cách bạn tính toán lại kỳ vọng.

Ngay cả trong trường hợp các mức tăng cạnh tranh đang được cung cấp, nếu tất cả những gì bạn có là các nhà phát triển cơ sở ở đâu và họ phải học như thế nào? Về cơ bản, bạn đang hy vọng rằng một trong số họ sẽ tự mình học hỏi các thực hành tốt bất chấp môi trường làm việc của họ và cuối cùng là cố vấn cho những người khác (trái ngược với việc rời khỏi đồng cỏ xanh hơn). Nó sẽ có ý nghĩa hơn rất nhiều khi "tố chính máy bơm" với một số nhà phát triển giỏi. Nhiều khả năng bạn sẽ phát triển văn hóa của người mới bắt đầu chuyên gia . Kết quả là cuối cùng bạn sẽ trả mức giá dành cho nhà phát triển cao hơn cho những người chỉ tốt hơn một chút so với nhà phát triển cơ sở và độc hại về mặt văn hóa.

Một lợi ích của, đặc biệt, các nhà phát triển rất giỏi, mà tôi ngạc nhiên không ai khác đề cập đến là họ có thể dễ dàng trở thành một nhân tố. Nó cũng có thể là trường hợp một nhà phát triển cơ sở và một nhà phát triển cao cấp mất cùng thời gian để tạo một bảng. Tuy nhiên, một nhà phát triển giỏi sẽ không làm điều đó. Họ sẽ tạo một trình tạo bảng để giảm thời gian cho mọi người tạo bảng. Ngoài ra, họ cũng sẽ tăng trần những gì có thể cho mọi người . Ví dụ: các nhà phát triển đã triển khai khung MapReduce của Google có khả năng cực kỳ đủ điều kiện, nhưng ngay cả khi người dùngMapReduce hoàn toàn không thể tự tạo một phiên bản phân tán ồ ạt cho thuật toán của họ, giờ đây họ có thể dễ dàng với MapReduce. Thường thì sự năng động này là ít trắng trợn hơn. Ví dụ, kiểm soát nguồn, kiểm tra và thực hành triển khai tốt hơn giúp mọi người trở nên tốt hơn, nhưng việc theo dõi một người cụ thể có thể khó hơn.

Để tranh luận về phía bên kia một chút, có thể những người cấp cao hơn là đúng. Có lẽ các nhà phát triển có kinh nghiệm hơn không cần thiết. Tuy nhiên, nếu đó là trường hợp, có vẻ như sự phát triển không phải là một phần quan trọng của công ty. Trong trường hợp đó, tôi sẽ loại bỏ hoàn toàn các nhà phát triển và sử dụng phần mềm sẵn có hoặc thuê các nhà thầu theo yêu cầu. Có thể đáng để khám phá lý do tại sao họ không chỉ sử dụng các nhà thầu chứ không phải là một nhóm nội bộ. Nếu bạn sẽ có rất nhiều nhân viên khuấy động, thì các nhà thầu tăng cường không nên là một vấn đề.

Đây không phải là một hoặc / hoặc tình huống.

Đặc biệt trong một dự án lớn hơn, bạn thường có một vài người tương đối có kinh nghiệm trong các vai trò cao cấp và một số người ít kinh nghiệm hơn trong các vai trò cơ sở. Bằng cách này, những người cao cấp không chỉ có thể giúp đỡ trực tiếp cho dự án bằng cách viết mã và giúp đưa ra các quyết định khó khăn hơn, mà họ còn có thể giúp đỡ gián tiếp bằng cách tư vấn cho các đàn em.

Với một số chăm sóc, điều này cũng có thể giúp ngăn chặn các kỹ sư cao cấp nhanh chóng bị đốt cháy bằng cách được yêu cầu liên tục làm công việc thiếu thách thức hoặc quan tâm đến họ. Ít nhất là theo kinh nghiệm của tôi, thậm chí một chút thời gian tư vấn cho một số người cấp cơ sở (hoặc thậm chí cấp thực tập) có thể làm cho một cuộc chạy nước rút thú vị hơn rất nhiều.

Công bằng mà nói, tôi nên nói thêm rằng loại vị trí này có lẽ sẽ không phù hợp với tất cả các kỹ sư cao cấp. Nó đòi hỏi một sự nhấn mạnh gia tăng đáng kể về kiến ​​trúc và thiết kế, truyền thông, tài liệu, v.v. Đặc biệt là từ rất sớm, nó cũng thường đòi hỏi rất nhiều kỷ luật - đối với ai đó đã tạo ra sự nghiệp viết mã, thật hấp dẫn khi chỉ nhảy vào viết mã, thay vì dạy một kỹ sư cơ sở cách làm. Nó cũng thường xuyên bị cám dỗ để viết lại hoàn toàn từ đầu khi mã không phải là cách cá nhân bạn thích nó - ngay cả khi nó hoàn toàn phù hợp với công việc.

Tuy nhiên, nếu bạn thực sự không thể thuyết phục được quản lý đi cùng với nhiều cấp độ kinh nghiệm, về cơ bản không có câu hỏi nào mà bạn phải đi để có thêm kinh nghiệm. Nếu bạn để lại một dự án hoàn toàn cho nhân sự cấp dưới, rất có thể bạn sẽ không bao giờ có được một sản phẩm có thể sử dụng được. Tồi tệ hơn, họ sẽ không nhận ra rằng những gì họ đang làm không mang lại bất kỳ tiến bộ thực sự nào cho một sản phẩm có thể sử dụng được, vì vậy họ sẽ tiếp tục làm việc theo hướng đã chọn sau khi một người có kinh nghiệm hơn sẽ nhận ra rằng họ đã thực hiện sai lầm cơ bản từ sớm, và cần sao lưu, tập hợp lại, mang vòng bi của họ, và bắt đầu theo một hướng mới để có bất kỳ hy vọng đến đích đến có ý nghĩa.

Bất kỳ dự án trong thế giới thực nào cũng được điều khiển bởi nhu cầu của khách hàng, và do đó liên quan đến các nhiệm vụ có độ phức tạp thấp (ví dụ: xây dựng các biểu mẫu CRUD) và độ phức tạp cao (ví dụ: xây dựng hệ thống thông báo theo hướng sự kiện). Cách duy nhất để chỉ có các nhiệm vụ phức tạp thấp là liên tục nói với khách hàng từ "không", điều mà không bộ phận bán hàng nào tôi từng nghe nói sẵn sàng làm.

Nếu bạn chỉ có các nhà phát triển cấp cơ sở, điều đó có nghĩa là bạn sẽ chỉ có thể thực hiện các nhiệm vụ có độ phức tạp thấp và do đó chỉ có thể xây dựng một sản phẩm có giá trị thấp và đấu tranh khó hơn trên thị trường để phân biệt các sản phẩm của bạn. Nếu bạn muốn phân biệt, bạn cần xây dựng chức năng có giá trị cao, chắc chắn sẽ chuyển thành các nhiệm vụ có độ phức tạp cao. Rốt cuộc, nếu nó dễ dàng thì nó sẽ không có giá trị. Điều đó có nghĩa là bạn cần mọi người thực hiện các nhiệm vụ phức tạp cao đó và bạn cần các nhà phát triển cấp cao.

Nếu bạn chỉ có các nhà phát triển cấp cao, bạn sẽ lãng phí các kỹ năng của họ vào công việc có giá trị thấp, gặp khó khăn trong việc giữ chân họ khi buộc họ làm công việc đó, cũng như mạo hiểm để họ đi vào vùng đất thiên văn kiến ​​trúc khi cố gắng thực hiện các nhiệm vụ đơn giản hơn thú vị để làm việc trên. Điều này có nghĩa là bạn cũng cần phải có một số nhà phát triển thiếu kinh nghiệm để nhận các nhiệm vụ đó.

Một nhóm lành mạnh làm việc trên các sản phẩm hướng đến khách hàng thường là một hỗn hợp. Tỷ lệ giữa các nhà phát triển cơ sở và cấp cao phụ thuộc vào tỷ lệ giữa các nhiệm vụ phức tạp thấp và phức tạp cao, và điều đó phụ thuộc vào chiến lược kinh doanh của bạn. Nếu bạn chủ động tìm kiếm khối lượng lớn công việc cắt cookie dễ hiểu có biên độ thấp, bạn sẽ không có nhiều nhiệm vụ phức tạp cao và có thể sẽ thuê hầu hết các nhà phát triển cấp cơ sở. Nếu bạn chủ động tìm cách phân biệt và nhắm mục tiêu các hốc không được giám sát ở mức lợi nhuận cao hơn, bạn sẽ có nhiều nhiệm vụ phức tạp cao và tìm kiếm hầu hết các nhà phát triển cấp cao.

Trong câu trả lời của tôi, tôi sẽ cho rằng các lập trình viên cao cấp không nhất thiết phải viết mã nhanh hơn các nhà phát triển cơ sở. Trong thực tế, các lập trình viên nhanh nhất là những người trung bình vừa rời trường đại học.

Kiến thức tên miền là chìa khóa cho nhà phát triển cao cấp. Một nhà phát triển cấp cao giỏi nên có kiến ​​thức mạnh về lĩnh vực này, điều mà nhà phát triển cơ sở có thể không có. Các nhà phát triển có kinh nghiệm hiểu vấn đề, những gì cần giải quyết và làm thế nào để giải quyết nó. Họ có thể giải quyết vấn đề phức tạp hơn cho doanh nghiệp so với hầu hết các nhà phát triển cơ sở.

Lập trình tương đối là một bộ kỹ năng rẻ tiền, đó là kiến ​​thức chuyên môn đáng kể.

Đừng cố gắng 'tạo ra vụ án' Thị trường định giá cho nhân viên. Nếu thị trường sẵn sàng trả thêm 4 lần cho kinh nghiệm thì vì các công ty nói chung đã làm việc rằng có sự gia tăng năng suất gấp 4 lần.

Bây giờ rõ ràng thị trường có thể sai, có thể là 3,5 hoặc 5x nhưng trừ khi bạn là một cơ quan kỹ thuật số, cạnh tranh với thị trường hoặc một số sắc thái như vậy là không quan trọng.

Vấn đề thực sự của bạn là Bạn có đủ giỏi để phỏng vấn để có thể phân biệt giữa một dev có kinh nghiệm tốt và chỉ là một dev cũ đang làm mờ nó.

Câu hỏi thứ hai của bạn về PM vs ngân sách Nhà phát triển. Tôi sẽ nói rằng một nhà phát triển có thể làm mà không cần PM nhưng PM không thể làm mà không có nhà phát triển. Để công cụ phát triển của bạn được sắp xếp trước, sau đó nhận PM để đưa quản trị viên ra tay.

Bạn sẽ không tìm thấy bất cứ ai ở đất nước của mình với một phần tư chi phí của một nhà phát triển thực sự tốt. Bạn có thể tìm thấy ai đó với một nửa lương, và đó sẽ là một người mới bắt đầu tuyệt đối. Đối với một người nào đó bằng một phần tư tiền lương, bạn cần phải đi ra nước ngoài, và sau đó bạn sẽ gặp vấn đề với truyền thông, những người mù quáng tuân theo thông số kỹ thuật và tất cả các loại rắc rối.

Bạn cần một nhà phát triển giỏi. Nếu bạn thêm nhiều lập trình viên cơ sở, bạn cần một nhà phát triển giỏi có kỹ năng giao tiếp mạnh mẽ, người sẵn sàng và có khả năng để mắt đến đàn em. Không có một nhà phát triển giỏi, bạn sẽ lạc lối. Bạn có thể may mắn tìm thấy một số người mới bắt đầu tài năng phi thường, nhưng một khi anh ấy hoặc cô ấy nhận ra họ là tốt, họ sẽ muốn một mức lương lớn hơn.

Nếu bạn không có một nhà phát triển giỏi, bạn sẽ không có ai nhìn thấy bức tranh lớn hơn và không ai có thể giải quyết các vấn đề không thể giải quyết bằng stackoverflow. Và bạn sẽ có mã mà không thể nhầm lẫn, bởi vì các nhà phát triển cơ sở không biết cách tạo mã có thể duy trì. Họ có thể học nó, nhưng họ sẽ không có nhà phát triển giỏi nào trong nhóm.

Có một vài trở ngại mà công ty của bạn sẽ phải vượt qua trước khi bạn có thể quyết định liệu việc thuê các lập trình viên giỏi hơn có hiệu quả về chi phí hay không. Xin lỗi nếu tôi đưa ra một số giả định tiêu cực về nơi bạn làm việc, nhưng tôi không tin họ biết họ đang làm gì.

1. Họ đã đánh giá chính xác mức độ phức tạp của phần mềm bạn xây dựng chưa? Có vẻ như họ không nghĩ rằng những gì bạn đang làm là rất khó khăn, vậy tại sao thuê những người giỏi hơn? Bạn đã thực hiện trường hợp sai lầm được thực hiện và các giải pháp và năng suất tốt hơn sẽ kiếm tiền như thế nào? Tiết kiệm thời gian là rất tốt, nhưng nhiều công ty thà lãng phí cả tuần của một lập trình viên hơn là cho họ tiền để mua một miếng lót chuột.
2. Công ty của bạn có hấp dẫn với các lập trình viên giỏi không? Họ có khả năng xác định chúng? Không có gì tệ hơn việc thuê một Dev cao cấp, trả cho họ nhiều tiền hơn và họ kéo toàn bộ đội xuống do thiếu kỹ năng và / hoặc khả năng lãnh đạo.
3. Công ty của bạn có thể sử dụng một lập trình viên tốt? Nếu tất cả những gì họ sẽ làm là ném thông số kỹ thuật kém chất lượng vào họ và chỉ bảo họ cứ đi xây dựng nó, thì sao? Họ sẽ cho họ bất kỳ tự do để làm mọi thứ theo cách của họ? Rốt cuộc, một lập trình viên giỏi theo định nghĩa biết cách tận dụng thời gian của mình tốt hơn. Chúng tác động đến những người xung quanh và khiến các lập trình viên khác cải thiện. Họ giới thiệu các thiết kế và kiến ​​trúc tốt hơn mà phần còn lại xây dựng để làm cho sản phẩm tốt hơn nhiều.

Xin lỗi, nhưng tôi cảm thấy như công ty của bạn sẽ không biết phải làm gì với một lập trình viên giỏi, vì vậy bạn có thể muốn thuyết phục họ thuê người quản lý tốt hơn trước và giải quyết những vấn đề nội bộ này.