Là mã gia công đắt hơn trong dài hạn? Nó có gây hại cho chất lượng mã? [đóng cửa]

Tôi biết về một công ty sở hữu tài sản trí tuệ của một sản phẩm phần mềm đàng hoàng và kiếm thu nhập tuyệt vời từ việc cấp phép mỗi năm. Tuy nhiên, giám đốc (không có kỹ thuật) phàn nàn về chi phí duy trì nhóm phát triển, vì nó ăn đáng kể vào tỷ suất lợi nhuận và đang xem xét việc thuê ngoài phát triển các mô-đun cụ thể sang các quốc gia khác có mức phí thấp hơn.

Cá nhân, tôi không nghĩ rằng đây sẽ là một giải pháp hiệu quả hơn về chi phí trong dài hạn. Điều này có thể dẫn đến sự cố truyền thông khi có sự cố, ngoài ra, các thông số kỹ thuật sẽ cần phải được giữ kín nước và cuối cùng có thể mất nhiều thời gian hơn. Theo tôi, khi làm việc trong các nhóm giao tiếp là chìa khóa - hoặc có cách nào hiệu quả để thực hiện công việc này không?

Tôi chắc chắn rằng ai đó có một ví dụ về hoạt động này, nhưng tôi đã không nhìn thấy nó.

Tôi đã làm việc trong một công ty Fortune 500 trong nhiều năm, nơi họ thuê ngoài phát triển. Tôi không có một ví dụ duy nhất trong những năm của một dự án thuê ngoài với chi phí thấp hơn so với việc chúng tôi tự thực hiện (trong nhà).

Mặc dù tỷ lệ lập trình của họ ít hơn chúng tôi, chúng tôi đã dành thời gian gấp 3 lần thời gian để quản lý nhóm thuê ngoài so với chúng tôi làm cho các nhóm nội bộ. Đó là trên thời gian bổ sung cần thiết để có các yêu cầu chi tiết hơn nhu cầu của nhóm nội bộ của chúng tôi và thời gian bổ sung cần thiết trong QA vì mã không bao giờ gần đúng.

Bạn có thể có một cách nhanh chóng, bạn có thể có nó với giá rẻ, hoặc bạn có thể làm nó tốt. Bạn không thể có cả ba, và tôi sẽ lập luận rằng thậm chí hai trong số ba có thể là một sự kéo dài.

Đối với một công ty phần mềm, điều này chỉ đơn giản là ngu ngốc. Gần nhất họ có thể đi đến một quyết định hợp lý thông minh sẽ là chuyển công ty đến một địa điểm khác có tài năng rẻ hơn.

Một công ty phần mềm thuê ngoài phát triển phần mềm của họ không còn là một công ty phần mềm nữa. Tôi sẽ lập luận rằng bất kỳ lợi nhuận kiếm được sẽ là ngắn hạn, bởi vì bạn đang tạo ra sự cạnh tranh của riêng bạn. Một khi họ nhận ra rằng họ biết sản phẩm tốt hơn bạn, thì họ cũng nhận ra rằng họ không cần bạn nữa.

Kinh nghiệm duy nhất của tôi về gia công cho một công ty ở nước khác sẽ là lần cuối cùng của tôi. Công ty được thuê, không hoàn thành công việc đúng hạn hoặc thậm chí từ xa đáp ứng các thông số kỹ thuật, và kết quả là chúng tôi phải làm lại toàn bộ lô một lần nữa trong nhà.

Tuy nhiên, nếu bạn có thể tìm thấy một công ty đáng tin cậy mà bạn có thể tin tưởng (tức là bạn đã thấy / nghe những điều tốt đẹp về họ từ những người khác) thì có lẽ điều đó đáng giá.

Giám đốc muốn thay thế một số nhà phát triển địa phương có kinh nghiệm của mình bằng những người ở một quốc gia xa xôi mà chuyên môn của anh ta không đủ thẩm quyền để đánh giá, những người không có kinh nghiệm về mã, và những người không thể được giám sát hoặc tư vấn trực tiếp mật mã.

Tôi đã trải qua điều đó hai lần. Trong cả hai trường hợp, các công ty nước ngoài rẻ tiền không cung cấp đúng thời gian với chất lượng đầy đủ. Khi các nhà phát triển địa phương nghe nói công việc đang đi ra nước ngoài, họ đã tìm thấy các công việc khác thay vì chờ đợi để được làm thừa. Khi tình trạng xuất huyết chuyên môn tiếp tục, lịch trình bị trượt, các lỗi nghiêm trọng không được khắc phục, khách hàng đã nổi giận và chuyển sang đối thủ cạnh tranh, và cuối cùng cả hai công ty đã xếp lại.

Cũng có những vấn đề kỳ lạ với giao tiếp, kỳ vọng và văn hóa. Chẳng hạn, một đội nước ngoài đã không kiểm tra nhiều mã hoặc trả lời email kịp thời. Hóa ra người quản lý CNTT địa phương đã nhận được một phần thưởng cho việc giảm chi phí, vì vậy anh ta có toàn bộ văn phòng trên một kết nối Internet tốc độ thấp. Một lần khác, những người kiểm tra QA thế giới thứ ba thường xuyên đưa một số lỗi cực kỳ khác nhau vào cùng một báo cáo lỗi; quản lý của họ sợ hết số lỗi.

Một số đội ở những nơi rẻ tiền là tốt. Từ những gì tôi nghe được, Red Hat dường như có một đội ngũ rất có thẩm quyền ở Bắc Kinh. Nhưng họ đã có nhiều năm kinh nghiệm với những người làm việc từ khắp nơi trên thế giới qua điện thoại trước khi họ bắt đầu làm việc đó, và những người ở Bắc Kinh là nhân viên của Red Hat, không phải là một công ty gia công.

Có - bạn nhận được những gì bạn phải trả cho.

Theo kinh nghiệm của tôi, trừ khi nhu cầu thị trường và phát triển của bạn quá đơn giản, họ có thể dễ dàng giải thích qua email cho bất kỳ nhà phát triển nào có rào cản ngôn ngữ có thể, và đơn giản đến mức ngay cả một nhà phát triển không thực sự đầu tư vào công ty vẫn có thể thành công tại việc tạo ra một sản phẩm chất lượng, thì có, sản phẩm của bạn sẽ bị ảnh hưởng .

Tôi đã làm việc tại một công ty nơi chúng tôi có một đội ngũ phát triển lớn tại địa phương và sản phẩm của chúng tôi bị ảnh hưởng đơn giản vì đội ngũ quản lý đã đổ nhiều tiền và công sức hơn vào việc bán hàng. Bởi vì rất nhiều nỗ lực đã được đổ vào doanh số, có vẻ như chúng tôi đã làm "tốt" - nhưng điều đó có nghĩa là để kiếm doanh thu, chúng tôi buộc phải tiếp tục đổ tiền và tài nguyên vào quy trình bán hàng.

Chúng tôi đã có một đội từ xa nhưng chúng tôi đã tích hợp họ hoàn toàn vào công ty và họ đã tham gia ở cùng cấp độ với các đội địa phương của chúng tôi. Đó là cách duy nhất nó có thể làm việc . Tôi là trưởng nhóm địa phương cho họ và chúng tôi đã bay ra để làm việc trên trang web với họ thường xuyên. Chúng tôi đã cho họ áo sơ mi và áo khoác của công ty giống như các đội địa phương. Sau khi xem xét tất cả, nó có thể giúp chúng tôi tiết kiệm 20-30%. Nếu bạn kết hợp một hệ thống cố gắng cắt giảm chi phí nhiều hơn thế, sản phẩm của bạn sẽ bị ảnh hưởng theo.

Nếu bạn đang làm việc với một nhóm gia công chất lượng, và ban quản lý sẵn sàng giao tiếp và thực thi các tiêu chí chấp nhận.

Sau đó, chi phí sẽ bằng với một sản phẩm được phát triển nội bộ.

Bạn cũng có thể có được chất lượng tương tự, nếu bạn may mắn.

Tôi có thể hơi thiên vị vì công ty của tôi giữ một nhân viên phát triển nội bộ, và không thuê ngoài bất kỳ sự phát triển sản phẩm nào. Tôi nghi ngờ những kinh nghiệm chúng tôi có với các đối tác tích hợp, những người đã thuê ngoài phát triển có liên quan đến quyết định đó.

Theo kinh nghiệm của tôi, thuê ngoài một dự án không phải là giải pháp tốt nhất khi cố gắng có được lợi nhuận tốt hơn.

Trong công việc, chúng tôi đã có một cái gì đó như vậy đang diễn ra và tốt, như những người khác cũng nói, cuối cùng chúng tôi đã làm lại điều đó và duy trì những gì trên một máy chủ sản xuất. Kết luận về vấn đề này, nó có giá gấp đôi.

Ý kiến ​​của tôi về vấn đề này là nếu bạn đang suy nghĩ về việc cố gắng tạo ra sự khác biệt về phát triển gia công bên lề, bạn có thể sẽ vứt bỏ khoản đầu tư của mình. Nếu bạn nghĩ về nó, thành công của sản phẩm là vấn đề của những thứ hoạt động như được thúc đẩy, vì vậy nếu bạn thay đổi nhóm phát triển, mọi thứ có thể trở nên xấu xí.

Phần mềm nguồn mở được lên kế hoạch / thực hiện tốt có thể là câu trả lời của bạn, bởi vì nó có thể mang lại lợi nhuận cao và việc bảo trì được giao phó cho cộng đồng, nhưng không có công thức để thành công. Lời khuyên tốt nhất tôi có thể đưa ra là đề xuất một số cuộc nói chuyện về những gì thực sự là nguồn mở và các shenanigans của nó:

• "Cách bắt đầu một dự án nguồn mở" của Jeremy Ruston (BT) http://vimeo.com/856110
• "Nguồn mở là ma thuật" của Chris DiBona (Google) http://www.youtube.com/watch?v=hmZyyBVbkOQ
• "Động cơ của cộng đồng" của Jono Bacon (Canonical) http://www.youtube.com/watch?v=zKOrWubmzAY
• "Các dự án nguồn mở và những người độc hại" Ben Collins-Sussman & Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "Có gì cho tôi? Lợi ích từ mã nguồn mở" Ben Collins-Sussman & Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

Và có lẽ cũng:

• "Cách chọn mô hình kinh doanh" của Roan Lavery (FreeAgent) http://vimeo.com/5588154

Theo tôi, điều về nguồn mở là xây dựng một cái gì đó có giá trị và lợi ích không chỉ cho bạn mà còn cho tất cả, sức mạnh của nguồn mở nằm trong cộng đồng.

Ngoài ra, nếu sếp / công ty của bạn không muốn mở phần mềm, chỉ cần cô lập các chi tiết cụ thể về logic và bí quyết kinh doanh của riêng bạn. Vì vậy, những gì bạn sẽ làm:

1. Ươm tạo một dự án nguồn mở với tài nguyên của bạn
2. Phát triển cộng đồng
3. ???
4. Lợi nhuận =)

Vâng, tôi nghiêm túc và "???" liên quan đến những gì bạn muốn theo đuổi sau khi bạn thu thập đủ tiền lãi. Với các công cụ ngày nay như Github và twitter, bạn có thể truyền bá từ dễ dàng hơn, nhưng hãy nhớ rằng ấn tượng đầu tiên của bạn phải đủ thú vị.

Nếu bạn không thực sự muốn nguồn mở ( mà bạn phải hiểu như một mô hình kinh doanh trước khi triển khai nó, nếu bạn muốn thành công ), bạn luôn có thể khởi chạy nó như một dịch vụ, để kiểm tra video Carsonified, nhưng điều đó bao hàm toàn bộ rất nhiều thứ khác cho công ty của bạn.

Cuối cùng, là nguồn mở hoặc khởi chạy nó như một dịch vụ là những cách giúp dự án bền vững về lâu dài.

Tôi không nhớ tác giả của trích dẫn này, nhưng nó đánh vào móng tay.

" Các nhóm được ghép lỏng lẻo làm việc cùng nhau trên các thành phần được liên kết chặt chẽ đều thất bại. Chắc chắn "

Gia công = các nhóm liên kết lỏng lẻo.

Cố gắng giảm chi phí bằng cách phân chia theo địa lý công việc trên các thành phần phụ thuộc lẫn nhau luôn luôn thất bại.

Mặt khác, dựa trên kinh nghiệm của tôi, việc chuyển toàn bộ một phần của danh mục phần mềm có thể hoạt động, có nghĩa là nó có thể được phát triển với chất lượng tốt với chi phí giảm.