Làm thế nào để bạn quyết định nếu bạn nên có một dự án?

Tôi là một nhà phát triển khá mới. Về chuyên môn, tôi đã lập trình C # được hai năm với tư cách là thực tập sinh và 6 tháng là nhà phát triển cơ sở. Một người bạn của gia đình tôi cần giúp đỡ với một dự án được viết trong VB.net. Tôi chưa bao giờ sử dụng VB.net, vì vậy tôi hơi lo lắng ở đó.

Nhưng, câu hỏi thực sự xuất hiện trong thực tế là một khi tôi xem các tài liệu cho dự án tôi có cảm giác rằng không có gì thực sự tốt sẽ đến từ nó. Tôi có cảm giác rằng nó sẽ gây ra căng thẳng nhiều hơn sau đó tôi muốn có trong cuộc sống của tôi hiện tại.

Làm thế nào để các nhà phát triển có kinh nghiệm đưa ra quyết định về việc có nên thực hiện dự án hay chỉ để nó đi? Một số số liệu tốt để làm cho quyết định dễ dàng hơn là gì?

Biên tập

Đây thực sự có vẻ như là một hệ thống ERP rất lớn mà anh ấy muốn tôi làm việc và tôi không tin rằng anh ấy biết bất cứ điều gì về lập trình nên tôi không nghĩ rằng tôi còn rất trẻ thậm chí còn nghĩ đến anh ấy.

Từ kinh nghiệm của tôi: Không bao giờ làm công việc liên quan đến tiền cho các thành viên gia đình mà bạn phải dành kỳ nghỉ với hoặc bạn bè mà bạn muốn giữ. Một trong các bên liên quan sẽ luôn cảm thấy như bên kia đang tính phí quá cao hoặc không trả đủ tiền và họ đã giúp đỡ bên kia. Khi thời hạn kết thúc, họ thường ít hiểu biết nhất và họ thường là những kẻ lừa đảo trong quá trình thử nghiệm beta bởi vì nếu bạn có một lỗi - mà bạn sẽ - họ sẽ không hiểu. Nó luôn luôn là một mớ hỗn độn.

Tôi đã từng duy tâm và nghĩ rằng mọi người khác chỉ cần những kỹ năng tốt hơn cho mọi người, nhưng không, đó chỉ là cách nó diễn ra. Những người không hiểu quy trình phát triển phần mềm sẽ LUÔN sợ hãi khi có điều gì đó không đáp ứng được kỳ vọng của họ ngay từ giây phút đầu tiên họ nhìn thấy. Điều này đúng trong kinh doanh với các nhà quản lý dự án cũng như với các thành viên trong gia đình. Vấn đề là, bạn phải duy trì mối quan hệ với gia đình và bạn bè, và mọi thứ không bao giờ nghiêm túc trong kinh doanh.

Điều đó nói rằng, nếu dự án sẽ tăng mức độ căng thẳng của bạn và bạn không cần tiền thì tại sao lại lấy nó? Đặc biệt nếu bạn đã có một công việc phát triển phần mềm mà bạn muốn nổi trội, tôi sẽ nói rằng bạn nên dành hết sức lực để làm việc xuất sắc trong công việc hàng ngày vì đó là nơi cuối cùng bạn sẽ được khen thưởng vì chất lượng công việc.

Nếu bạn cần tiền, và bạn ổn với sự mất mát tiềm tàng của một người bạn trong gia đình, thì hãy nhận công việc. Điều tồi tệ nhất có thể xảy ra - ngoài những điều tôi đã đề cập trước đây - là bạn học những gì bạn đang có và không giỏi, hoặc bạn học được rằng bạn cắn nhiều hơn những gì bạn có thể nhai khiến dự án trở nên tồi tệ đau đầu do thiếu kinh nghiệm của bạn. Tôi đã làm điều đó hai lần với công việc hiện tại của mình - may mắn thay tôi rất hiểu nhà tuyển dụng. Mặc dù đó là sự khốn khổ trong khi tôi cảm thấy chết trong nước, tôi đã nổi lên một lập trình viên tốt hơn nhiều với bộ kỹ năng rộng hơn nhiều so với trước đây.

Không có tính toán để xác định những công việc nên cho đi và giữ, chỉ có kinh nghiệm và tính cách của bạn. Bạn chỉ cần quyết định những gì bạn coi trọng và theo đuổi nó. Những điều cần cân nhắc:

Đây có phải là một dự án mà tôi sẽ thích làm việc? Đội có phải là đội mà tôi sẽ thích làm việc cùng không?

Họ sẽ cung cấp loại thanh toán nào? Nếu không, tôi sẽ nhận được sự phát triển chuyên nghiệp nào? Họ có cung cấp bất kỳ loại rủi ro được chia sẻ (ví dụ: tùy chọn cổ phiếu, tỷ lệ phần trăm lợi nhuận) không? Đây là một người thuyết phục lớn đối với tôi.

Dù sao, đây chỉ là những nguyên tắc để sử dụng trong việc ra quyết định của bạn. Tất cả phụ thuộc vào những gì bạn coi trọng. Ví dụ, tôi coi trọng những thách thức trí tuệ và thời gian với gia đình vì vậy tôi thường đặt ưu tiên cao cho dự án là gì và các kỹ năng tôi sẽ học được khi thực hiện. Tuy nhiên, tôi cũng đảm bảo rằng tôi chỉ làm việc 2 hoặc 3 đêm một tuần để tôi có thể dành thời gian cho vợ con vì tôi đã làm việc cả ngày. Tôi điều chỉnh thời hạn để đáp ứng nhu cầu này. Nếu họ không thích điều đó, thì tôi sẽ không nhận việc.

Dù bạn làm gì, hãy chắc chắn rằng bạn nói rõ những gì bạn sẽ và sẽ không làm, và đảm bảo rằng họ nói rõ những kỳ vọng của họ trước khi bạn nhận việc. Điều tồi tệ nhất có thể xảy ra là khách hàng có những kỳ vọng không có căn cứ và bạn đã đánh giá thấp những kỳ vọng đó.

PS tôi thực sự muốn tôi đã đọc bài viết này sớm hơn trong sự nghiệp của tôi. Nó áp dụng cho đoạn cuối cùng của tôi. http://www.joelonsoftware.com/articles/fog0000000356.html

Làm thế nào để các nhà phát triển có kinh nghiệm đưa ra quyết định về việc có nên thực hiện dự án hay chỉ để nó đi?

Tôi có cần công việc không? Nếu vậy, tôi "lấy" dự án.

Một số số liệu tốt để làm cho quyết định dễ dàng hơn là gì?

Tôi có bao nhiêu sự lựa chọn? Nhiều hơn 1? Tôi có thể chọn giữa các lựa chọn thay thế.

Chỉ 1? Tốt. Thế là xong.

Câu hỏi "căng thẳng trong cuộc sống của tôi" là tranh luận; không tham gia một dự án có nghĩa là không duy trì việc làm; trong đó có hậu quả tai hại.

Nếu bạn có loại tự do tài chính trong đó "căng thẳng" là yếu tố quyết định, điều đó thực sự tuyệt vời.

Bạn sẽ đạt được gì từ dự án này? Tiền bạc? Kinh nghiệm? Thứ gì khác?

• Tiền: Đó là từ một thành viên trong gia đình (Tôi cố gắng không làm kinh doanh với gia đình, nhưng đó là một cuộc thảo luận hoàn toàn khác), nó nhỏ (vì vậy bạn phát ra âm thanh), bạn khá trẻ, vì vậy đừng mong đợi nhiều tiền từ nó (dựa trên kinh nghiệm của tôi ).

• Kinh nghiệm: bạn có thể học một ngôn ngữ mới! Điều đó có thể có giá trị trong tương lai, có thể cung cấp cho bạn một lợi thế nhỏ so với các nhà phát triển .NET, những người chỉ biết C #.

Nhưng bản năng ruột của bạn nói với bạn rằng dự án này sẽ tồi tệ . Tại sao vậy? Có vẻ như bạn ít nhất có thể có được một số kinh nghiệm từ điều này.

Hầu hết các nhà thầu sẽ bắt đầu với việc xem họ sẽ nhận được bao nhiêu tiền để quyết định nhận một dự án. Lý tưởng nhất, các dự án khó khăn hơn dẫn đến nhiều tiền hơn. Nếu điều này là khó khăn, nó sẽ trả tốt, nhưng tôi không biết chi tiết để biết nếu bạn thực sự sẽ được trả tiền tốt ...

Đáp lại các chi tiết trong bản cập nhật của bạn: Nói với anh ta rằng điều này vượt quá phạm vi của một lập trình viên cơ sở duy nhất. Bạn có thể có thể thực hiện một vài phút nghiên cứu và xem liệu có một sản phẩm hiện có có thể làm những gì anh ấy muốn và xem trang "Tính năng" có nói về tùy chỉnh / plugin / khả năng mở rộng không. Anh ta cũng có thể muốn nói chuyện với một cửa hàng phần mềm tùy chỉnh nếu không có sản phẩm hiện có ngoài đó, hoặc công việc lập trình plugin mở rộng cần phải được thực hiện. Không có gì sai khi thừa nhận một dự án quá lớn đối với bạn để xử lý - tốt hơn nhiều so với thực hiện và thất bại hoàn toàn (đặc biệt nếu đó là một thành viên gia đình - các chức năng gia đình có thể khó xử và căng thẳng trong nhiều năm).

A friend of my family

Cá nhân nếu cụm từ này có liên quan, tôi không lấy dự án.

Là một người làm việc tự do, tôi chỉ chấp nhận các dự án mà tôi tự tin để có thể hoàn thành kịp thời gian, ngân sách, chất lượng tốt. Từ chối một dự án không có nghĩa là thất nghiệp - ít nhất là không phải là mãi mãi. Chấp nhận một dự án bạn không thể cung cấp chi phí tất cả mọi thứ - tiền bạc, danh tiếng, sức khỏe.

Đôi khi khó khăn hơn một chút khi một khách hàng tốt cần sự giúp đỡ cho một dự án mới đơn giản là không phù hợp với kỹ năng của tôi; nhưng ngay cả sau đó, tốt hơn là thành thật và để người khác làm điều đó.

Trong trường hợp của bạn, bạn có thể và nên từ chối dự án - bạn không đủ kinh nghiệm, bạn không biết ngôn ngữ, nó quá lớn đối với bạn.

Tôi đã làm lập trình tự do trong hơn hai mươi năm. Để một dự án thực sự thành công, nó cần ít nhất những điều sau:

1. Ai đó biết các công nghệ lập trình, phần mềm và phần cứng được sử dụng để triển khai - hoặc các công nghệ đủ tương tự để tìm hiểu các công nghệ triển khai thực sự nhanh
2. Ai đó biết miền vấn đề, và có thể và sẵn sàng dịch nó thành thông số kỹ thuật mà lập trình viên có thể sử dụng. (Nếu lập trình viên cũng là chuyên gia về miền và dự án đủ đơn giản, thông số kỹ thuật có thể nằm trong đầu hoặc ghi chú không chính thức.)
3. Ai đó có khả năng, sẵn sàng và có kinh nghiệm trong việc quản lý các nhiệm vụ dự án, dòng thời gian, v.v., và biết các loại cạm bẫy mà bạn có thể gặp phải với những việc như ước tính và cách tránh chúng
4. Ai đó để quản lý các liên lạc và mối quan hệ giữa tất cả các bên liên quan của dự án, bao gồm cả lập trình viên và khách hàng
5. Mọi người ở cả hai phía, tư vấn và khách hàng, những người có kinh nghiệm trong việc giữ cho các vấn đề kinh doanh đang diễn ra vững chắc, bao gồm cả hợp đồng và tiền bạc. Nếu bạn không có kinh nghiệm này cho mình, bạn có thể nhờ một cố vấn có kinh nghiệm cho đến khi bạn có.
6. Mối quan hệ kinh doanh kéo dài trong một cánh tay, nếu bạn phải đưa ra quyết định kinh doanh khó khăn, bạn không gặp vấn đề gì ngoài công việc
7. Một nhóm đủ lớn, với sự kết hợp đúng đắn về chuyên môn, công cụ và tài nguyên, để cung cấp một sản phẩm chất lượng trong dòng thời gian cần thiết

Bạn mô tả một người bạn của gia đình không biết gì về lập trình, người muốn bạn - một lập trình viên thiếu kinh nghiệm - để xây dựng một hệ thống ERP sử dụng công nghệ mà bạn không biết.

Tôi nghe có vẻ như tình huống này chắc chắn bỏ lỡ # 1, # 3, # 6 và # 7, và có thể tất cả chúng. Như Adam nói trên Mythbuster, "Đây là một công thức cho thảm họa."

Heck, tôi sẽ không chạm vào cái này với một cột mười feet. Tôi có thể tiếp tục và nói về những lá cờ đỏ khác mà tôi thấy ở đây, nhưng về cơ bản, lời khuyên của tôi dành cho bạn là hãy đi theo cảm nhận của bạn, bởi vì bạn nói đúng: "không có gì thực sự tốt sẽ đến từ nó."

Vì đây là một người bạn của gia đình, nếu tôi là bạn, tôi sẽ chỉ nói: "Bạn có một dự án tuyệt vời và bạn cần ai đó thực sự tốt, và tôi quá thiếu kinh nghiệm để cho bạn kết quả mà bạn nên có" và Để nó ở đó.

Tôi cũng thấy rằng khi bạn có một khách hàng gặp vấn đề ở một khu vực, họ có khả năng là một vấn đề ở những người khác. Một khách hàng tiềm năng thậm chí sẽ cân nhắc việc có một hệ thống ERP được thiết kế và triển khai bởi một lập trình viên cơ sở là quá thờ ơ với bản thân họ và những người khác, hoặc rẻ tiền một cách lố bịch, và một trong số họ sẽ đưa họ vào danh sách "tránh xa" của tôi .

FWIW, với tư cách là một nhà tư vấn / người làm việc tự do, tôi tự mình hoàn thành các vai trò của mình, với lời khuyên từ vợ tôi. Chúng tôi đã tìm ra tất cả những thứ đó là gì khi thấy các dự án thất bại do thiếu chúng - đôi khi, đó là dự án của chính chúng tôi. Và thậm chí sau hai mươi năm, và mặc dù đã kiểm tra các tiêu chí này, tôi vẫn tiếp tục với một dự án không thường xuyên thực hiện - rủi ro đó luôn là một phần của việc kinh doanh. Bây giờ tôi chỉ đảm bảo rằng các dự án không thất bại vì bất cứ điều gì tôi đã làm sai và các hợp đồng được cấu trúc để tôi được trả tiền nếu phía bên kia thất bại.

Bạn có muốn làm việc với những người khác có liên quan?

Dự án chỉ là một cái cớ để gặp gỡ và liên kết với mọi người.

Cá nhân tôi sẽ làm một cuộc thăm dò nhỏ về những gì anh ấy muốn, dòng thời gian, loại chi phí mà anh ấy mong đợi, v.v. Nếu đây thực sự là một ERP lớn thì sự giúp đỡ có thể kéo dài trong nhiều năm và thực sự trở nên xấu xí. Quản lý chất thải so với SAP sẽ là một ví dụ về mức độ đắt đỏ này nếu bạn thực sự có nghĩa là lớn như trong ngân sách dự án 9 chữ số.

Quan điểm của tôi khi thực hiện cuộc thám hiểm là vẽ một đường thẳng trên cát để rõ ràng lý do tại sao tôi lại đặt câu hỏi và kết quả là tôi dự định sẽ có gì. "Làm thế nào khả thi để tôi thấy điều này?" là câu hỏi mà tôi có khi tôi đặt câu hỏi về phương pháp, ngân sách và thời gian trả trước và sau đó thực hiện một nghiên cứu nhỏ để xem liệu mọi thứ có xuất hiện ở cấp độ hay đây có phải là một trang web hài hước về CNTT không như WTF hàng ngày .