2008-12-03 22 views
8

Tôi đang đối phó với một vấn đề với chủ nhân hiện tại của tôi đã nghiêm túc làm cho tôi xem xét việc tìm kiếm việc làm ở nơi khác. Họ đang theo ấn tượng rằng 100% phát triển tùy chỉnh nên được loại bỏ và thay thế bằng các sản phẩm COTS, chẳng hạn như SharePoint. Trong khi tôi nhận ra rằng đây không phải là một kỳ vọng thực tế, tôi đã tìm thấy nó không thể tranh luận quan điểm của tôi với những người trong quản lý chia sẻ những quan điểm này. Lập luận của họ thường liên quan đến một cái gì đó dọc theo dòng của một tính năng đã tồn tại trong SharePoint bao gồm tính năng X, do đó có ít rủi ro hơn và thử nghiệm không phải được thực hiện đối với nó.Làm thế nào để đối phó với nỗi sợ hãi của Custom Dev

Trường hợp tại điểm, chúng tôi có tình huống khi danh sách SharePoint hoàn toàn không thể đáp ứng đáp ứng các yêu cầu và mong đợi của khách hàng. Tuy nhiên, việc lưu dữ liệu này trong cơ sở dữ liệu SQL sẽ dễ dàng đáp ứng các yêu cầu. Bất cứ khi nào nhóm phát triển của chúng tôi đề xuất đi ra ngoài ranh giới của SharePoint, tuy nhiên, quản lý tăng lên trong ngọn lửa về cách mọi dòng mã bổ sung vào sự phức tạp của dự án và tăng rủi ro. Trong khi điều này là chắc chắn đúng trong một số trường hợp, nó không phải luôn luôn như vậy. Tuy nhiên, lập luận của họ là vì SharePoint cung cấp cơ chế lưu trữ dữ liệu, nên chúng ta nên sử dụng nó 100% thời gian. Bất kể nó có đáp ứng yêu cầu của khách hàng hay không.

Tôi đã đến mức tôi ghét phải làm việc vì tôi liên tục buộc phải làm những điều mà tôi biết (chắc chắn 100%) là không đúng và có thể được thực hiện ngay bằng cách phát triển tùy chỉnh. Nó chỉ đơn giản là những gì có vẻ là một đối số không thể mà tôi làm việc, tuy nhiên.

Bạn có gặp phải tình huống tương tự nào không? Nếu vậy, bạn đã làm gì để vượt qua những thách thức này?

+3

Làm thế nào kỳ lạ .. SharePoint chính nó được thiết kế để được mở rộng với dev tùy chỉnh! –

+0

Phát triển tùy chỉnh là gì? – BlackBear

Trả lời

15

Nếu bạn không chia sẻ tầm nhìn của công ty và nếu bạn không thể khai sáng thì chắc chắn, đây là thời điểm tốt để bắt đầu tìm kiếm.

Bạn đã chỉ ra rằng có nguy cơ buộc phải "giải pháp" trên ứng dụng khách không hỗ trợ hoặc thiếu chức năng hoặc không sử dụng được?

Có thể đưa ra kế hoạch giải quyết và giảm thiểu rủi ro nhận thức của họ.

+1

Nó không phải dễ dàng như vậy .. Tôi cũng làm việc trong công ty nơi 'Sharepoint' là viết tắt của loại đạn bạc và rất khó để thuyết phục quản lý. May mắn duy nhất của tôi là người giám sát của tôi là loại người quản lý kỹ thuật, người hiểu được những hạn chế của Sharepoints. – drax

+0

Btw, +1 cho lời khuyên để rời tàu chìm :) nó là vô nghĩa để làm việc cho công ty mà quy tắc bạn ghét – drax

1

Tôi đang làm điều tương tự trong công việc hiện tại của mình, không có cách nào dễ dàng để giải quyết tình huống này. Tất cả những gì tôi có thể làm là nuốt chửng lý lẽ của tôi, vì họ đã khiến tôi không có nơi nào, và làm theo yêu cầu của ban quản lý của tôi. Khóa học này sẽ đi ngược lại bản chất lập trình cơ bản của bạn bằng cách sử dụng giải pháp tốt nhất cho nhiệm vụ, và có thể xây dựng một thứ gì đó tuyệt vời trong quá trình, nhưng vì họ là sếp thực sự là giải pháp duy nhất của bạn. Bạn có thể thử các trường hợp trang web, với bằng chứng, nơi nó có ý nghĩa hơn để sử dụng các giải pháp tùy chỉnh. Nhưng nếu ông chủ của bạn là bất cứ điều gì giống như tôi, nó sẽ không nhận được rất xa trước khi trận đấu la hét bắt đầu. Giải pháp duy nhất khác là loại bỏ việc tiếp tục và tìm một công việc mới.

3

Có ai trong quản lý sở hữu cổ phiếu trong SharePoint không? Hệ thống có được phát triển bởi em trai của CEO không?

Nếu chúng có khả năng đàn hồi để thay đổi, bạn nên tìm hiểu lý do thực sự trước khi cố gắng tranh luận với chúng. Họ có thể tuyên bố rằng có thêm phức tạp, thử nghiệm khó khăn, v.v., nhưng nếu bạn có thể phản đối mọi đối số với một vị trí cho thấy vị trí của họ, với tất cả sự tôn trọng, bị hiểu sai, và họ vẫn không thảo luận, thì bạn có thể tranh luận sai điểm.

Nếu chúng bị khóa vào công nghệ vì lý do phi kỹ thuật, chẳng hạn như ai đó đã đọc SharePoint là điều cuối cùng trong bất kỳ tình huống kỹ thuật nào (và, tất nhiên, không biết đầu bài viết gì khác ngoài SharePoint = tốt) sau đó bạn không nên cố gắng tranh luận và tiết kiệm năng lượng của bạn. Để tìm việc làm.

9

Bạn ghi lại các mối quan tâm của mình và để những điều đó ở trên bạn biết chúng, và sau đó bạn làm như họ yêu cầu. Nếu nó không hoạt động, bạn có tài liệu mà bạn đã đưa ra những lo ngại. Nhưng cố gắng làm cho nó hoạt động theo cách của họ, vì vậy nó không giống như bạn đang cố gắng để làm suy yếu kế hoạch của họ. Họ đang chấp nhận rủi ro lớn hơn, và do đó họ có trách nhiệm lớn hơn. Cố gắng hết sức để làm cho nó hoạt động theo cách của họ, và bỏ lo lắng về nó.

3

Chứng minh điều đó cho họ. Khi các yêu cầu yêu cầu một danh sách có thể xử lý 100.000 mục có sắp xếp nhiều cột - hãy viết một kịch bản để thêm 100.000 mục thử nghiệm vào danh sách chia sẻ và cho phép họ dùng thử, tốt nhất là "khách hàng" yêu cầu danh sách xem. :-)

1

Tôi đã đối mặt với cùng một loại thử thách ngay từ ngày đầu tiên. Quản lý có một sự miễn cưỡng tự nhiên để thêm mã tùy chỉnh vào giải pháp. Tuy nhiên, trong hầu hết các trường hợp, việc giải thích đúng hơn là giải pháp phù hợp cho khách hàng sẽ bao gồm một số mã tùy chỉnh.

Hãy nhớ rằng, nếu bạn cho rằng bạn có thể bao gồm mã tùy chỉnh trong codebase chung, thì ông chủ có thể phê duyệt ý tưởng.

2

Tôi chắc chắn sẽ nhận được hồ sơ của mình và mở cửa nếu tôi là bạn. Không chỉ là trải nghiệm mà bạn hiện đang gặp khó chịu, nó thực sự có thể làm tổn thương sự phát triển nghề nghiệp của bạn trong một thời gian dài. Hãy nghĩ về nó. Trong khi bạn đang mệt mỏi với chủ nhân hiện tại của bạn ở vị trí hiện tại của bạn, các nhà phát triển khác đang áp dụng các công nghệ mới và mở rộng kinh nghiệm của họ.

Có một điều như sự khác biệt ý thức hệ giữa các nhà phát triển và ý tưởng của một công ty về vai trò của nhà phát triển là gì. Nếu cuộc thảo luận mở và candor đưa bạn đến đâu đó, bạn sẽ không bị lỗi vì thiếu nỗ lực. Lòng trung thành với một công ty là một điều tốt, nhưng mối quan hệ cần phải là một con đường hai chiều.

Đáng buồn thay, cuối cùng có thể sẽ nhận ra rằng họ sai trong các giả định của họ - nhưng bạn không thể chờ đợi ngày đó tới. Đôi khi nó không bao giờ đến. Đặc biệt (và không hiểu sai, tôi thích SharePoint khi nó được sử dụng cho những gì nó được dự định), SharePoint trở thành Access tiếp theo, trong đó những người đọc tạp chí quản lý thấy đủ của nó ném xung quanh để gọi nó là Đấng cứu thế.

1

Tôi thực sự cảm thấy nỗi đau của bạn.

Nếu đó là tôi, tôi sẽ sử dụng thời gian rảnh rỗi của mình để thu thập thông tin chứng minh quan điểm của tôi và viết tài liệu theo cách dễ hiểu.

Nếu họ chỉ hiểu tiền, nói tiền, nếu họ chỉ hiểu nỗi sợ hãi (làm "điều này" bởi vì họ sợ "đó"), hãy sử dụng sự sợ hãi, tìm điều đáng sợ cho họ trong giải pháp "của họ".

Tài liệu mỗi lần triển khai mới, thời gian, tiền bạc và vấn đề phát sinh. Và ghi lại giải pháp của bạn sẽ là gì.

Có thể họ không thấy vấn đề trong giải pháp của họ, vì họ tập trung vào việc không gặp sự cố trong giải pháp "của bạn".

6

Điều này nghe có vẻ không ổn và có thể không phải là câu trả lời bạn muốn. Có một bộ phận ít được biết đến trong văn phòng của tôi được gọi là "The Skunk Works". Mọi người, theo cách riêng của họ (thường là trong giờ ăn trưa hoặc thời gian biên soạn) quyết định viết các chương trình nhỏ giúp công ty. Những điều thú vị về điều này là kết quả không "chi phí" công ty bất cứ điều gì.

Cuộc đối thoại thường đi như thế này:

"Chúng tôi cần phải mua phần mềm này" -Boss

"Nhưng, chúng tôi đã có điều đó trong nhiều tháng John, đã viết rằng trở lại trong ngày." - Lập trình viên

"?" -Boss

Rất nhiều lần các nhà phát triển thấy một quyết định là xấu và chỉ cần tạo một quy trình song song diễn ra tự động. Sau đó, khi nội dung truy cập vào người hâm mộ và khách hàng thất vọng, giải pháp thay thế sẽ ổn định tại chỗ.

Tôi có ví dụ về máy phát hành tự động. Nhà phát triển đã sử dụng để tạo các báo cáo tùy chỉnh này. Khi khách hàng của chúng tôi tăng lên, khối lượng công việc của nhà phát triển tăng lên. Vấn đề là "Để khách hàng có được nhà phát triển báo cáo tùy chỉnh phải được tham gia." Vì vậy, trong khi công ty đang tìm kiếm một người nào đó để làm báo cáo toàn thời gian hoặc tìm cách để khách hàng thực hiện chúng, tôi đã viết một máy phát hành tự động tìm kiếm các thay đổi báo cáo và phát hành trực tiếp cho khách hàng. Tôi cũng đã viết một tiện ích cho phép bất kỳ ai thực hiện thay đổi đối với các báo cáo dễ sử dụng hơn so với những gì nhà phát triển có. Khi ông chủ đưa ra thông báo cố gắng tìm một giải pháp, tôi đã nói với ông rằng nó đã sẵn sàng và thậm chí ông có thể thay đổi các báo cáo và giải phóng chúng. Bây giờ, mọi người đều có thể thay đổi báo cáo, thường là quản lý và hỗ trợ khách hàng thực hiện những thay đổi này. Mặt thú vị là các nhà phát triển không tham gia nữa.

Chỉ cần thực hiện. Nếu bạn định rời khỏi anyways, cũng có thể thử.

+2

Điều này có thể làm việc miễn là quản lý không nhận được khó chịu mà bạn đã làm việc trên một cái gì đó họ không biết về! –

+0

Và sự hồi hộp khi một số thứ này xuất hiện trong lĩnh vực này và sau đó thổi một thời gian sau ... và không ai còn lại biết cách giải pháp 'đặc biệt' hoạt động cũng như cách duy trì nó. Tùy thuộc vào công ty và mức độ nghiêm trọng của họ khi ở trong hộp, bạn thực sự có thể làm hại họ nhiều hơn với các dự án skunkworks hơn là thực hiện chính xác những gì họ yêu cầu. Chỉ là một suy nghĩ trước khi bạn bơi qua sâu, cá mập bị nhiễm khuẩn cuối của hồ bơi. –

1

Tôi đã làm việc ở một nơi mà quản lý không mang tính xây dựng trong cách tiếp cận của họ, không hoàn toàn xấu như bạn mô tả, nhưng đủ tệ.

Có một vài tùy chọn. Một là để đi trước và làm những gì cần phải được thực hiện cho khách hàng với lựa chọn "giá trị đồng tiền" tốt nhất bạn có thể. Bạn có thể sẽ phải làm cho các nhà phát triển cùng nhau thành một nhóm để thực hiện công việc "bất tuân dân sự" này.

Một cách tiếp cận mạnh mẽ hơn sẽ thực sự làm cho người hâm mộ nhấn vào người hâm mộ là đi đến khách hàng (đừng làm điều này nếu nó là khách hàng bên ngoài hoặc nếu bạn muốn giữ công việc của mình) và đặt ra những gì đang diễn ra để xảy ra với dự án này nếu X và Y. Điều này là khá nhiều kể câu chuyện ra khỏi trường học và sẽ là xấu, nhưng giải trí.

Một cách tốt hơn một chút là đi lên chuỗi và nhận được nhà tài trợ có thể tạo ra điều xấu cho bạn. Về cơ bản đi phía sau sếp của bạn (es) trở lại. Điều này có thể làm việc, nhưng nó sẽ có kết quả dự đoán được cho mối quan hệ của bạn với quản lý của bạn.

Cuối cùng và khó nhất là xác định người giữ quan điểm rằng bất kỳ mã tùy chỉnh nào là xấu và thu hút họ trong cuộc trò chuyện để tìm hiểu xem họ có niềm tin và phản đối điều đó bằng ví dụ ở đâu. Nhấn mạnh vào cuộc trò chuyện vì bạn sẽ phải lắng nghe và hiểu những mối quan tâm cơ bản của họ (mà sẽ không phải về mã tùy chỉnh cho mỗi người) và chỉ giải quyết chúng sau khi bạn đạt được những người tin tưởng đó.

Tôi không thể cho bạn biết cách làm việc nào sẽ hoạt động tốt nhất vì nó phụ thuộc quá nhiều vào các cá nhân có liên quan. Tất cả những gì tôi biết là bạn không thể thay đổi con người và theo kinh nghiệm của tôi, cách tốt nhất để giải quyết vấn đề cho đến nay là rời khỏi và làm việc với những người không ...

+0

Tôi sẽ không khuyên bạn nên tự chèn mình giữa chủ nhân của bạn và khách hàng của họ trừ khi có một lý do pháp lý hoặc đạo đức trực tiếp để làm như vậy (sự khác biệt triết học về triển khai là không đủ). Và ngay cả trong những trường hợp đó, một trung gian được khuyến khích (như một luật sư). Việc khiến khách hàng bị mất có khả năng gây ra việc chấm dứt ngay lập tức. –

2

Tôi thấy rằng thường không có cách nào của 'chiến thắng' các cuộc tranh luận này thông qua nói chuyện một mình. Nhiều nhà quản lý tạo thành một ý kiến ​​về một sản phẩm hoặc giải pháp thông qua việc đọc các bài viết định hướng quản lý. Xem bạn có thể tìm thấy một số bài viết không.

Nếu bạn có thể trích dẫn ví dụ về những thứ mà SharePoint không có khả năng làm và hiển thị ví dụ về cách bạn có thể chi phí hiệu quả giải quyết những vấn đề này thông qua phát triển tùy chỉnh thì bạn đang trên đường. Một trong những sai lầm là cố gắng và biến nó thành một cuộc trò chuyện về công nghệ, nó không phải, hiệu quả về chi phí, hiệu quả chi phí và khả năng bảo trì - đó là những câu thần chú và các số liệu sẽ cản trở các nhà quản lý phi kỹ thuật xem xét các giải pháp thay thế.

Nếu bạn có thể cùng nhau đưa ra bằng chứng về khái niệm cho một số vấn đề này, thì kẹo mắt tốt hơn thực sự giúp bán bên ngoài các nhóm kỹ thuật.

Cuối cùng, chúc may mắn :)

0

cách không gọi mã tùy chỉnh. Thay vào đó, nếu bạn gọi nó là 'các tiện ích mở rộng người dùng SharePoint được mong đợi' hoặc điều gì đó có thể làm giảm nhận thức sai về một cụm từ cụ thể.

cũng như đã được nói, có thể có một lý do khác khiến bạn không thể quản lý chương trình này. Nó có lẽ là tốt nhất để không đoán thứ hai quá nhanh, như nhiều người sẽ có giá trị.

Cuối cùng, có rất nhiều địa điểm cần phát triển. nó không đau để tìm kiếm một trận đấu tốt hơn.

chúc may mắn.

Các vấn đề liên quan