Phải làm gì với tư cách là một Dev khi trong nhiều năm, nhóm của họ đã thiếu đổi mới sản phẩm, không sử dụng các phương pháp mgmt dự án và giữ các thực hành Dev của phần mềm xấu? [đóng cửa]


14

Tôi quan tâm đến việc biết cách xử lý một quy trình phát triển phần mềm hiện tại đã không được thay đổi trong nhiều năm và cuối cùng sẽ dẫn đến thất bại của sản phẩm và nhóm. Vâng, có lẽ cách dễ dàng hơn để giải quyết điều này là thay đổi công việc, nhưng với nền kinh tế này thì nói dễ hơn làm. Tuy nhiên, nếu bạn có ví dụ cụ thể và đã thấy hoặc đã nhiều lần trong cùng một tình huống và nghĩ rằng giải pháp tốt nhất để giải quyết các vấn đề này, là rời khỏi công ty, thì hãy ủng hộ câu trả lời của bạn. Vấn đề là, câu hỏi này thực sự có câu trả lời đặc biệt là nếu nhiều chuyên gia về vấn đề này chỉ ra rằng con đường tốt nhất để đi là: tuyến đường A.

Tôi biết hàng tấn nhà phát triển đã hoặc đang ở trong tình huống tương tự. Đây là một trong những lý do chính tại sao các công ty đi từ vị trí số 1 trong thị trường của họ để trở thành người cuối cùng hoặc thậm chí ra khỏi thị trường. Hy vọng rằng câu trả lời trong bài viết này sẽ giúp các nhà phát triển khác gặp phải trở ngại tương tự. Trong một nhóm phát triển nhỏ hoặc lớn, điều này thường xảy ra:

  • Một số nhà phát triển dường như không quan tâm và quyết định đi theo dòng chảy và thích để lại mã với nhiều mã có mùi như vậy và quá trình phát triển như là,
  • Những người khác cảm thấy mệt mỏi vì không có sự thay đổi và từ chức và chuyển sang một công ty khác,
  • Những người khác dường như sợ nói chuyện và thích giữ im lặng,
  • Đôi khi rất ít nhà phát triển hoặc chỉ một người cố gắng lên tiếng để cải tiến sản phẩm và nói với nhóm rằng tầm quan trọng của việc tuân theo các thực tiễn mã hóa tốt nhất và lợi ích của việc đó đối với khách hàng, người dùng và nhóm. Những nhà phát triển loại này thường quyết định ở lại với nhóm vì những lý do như công ty cung cấp lợi ích mà rất ít công ty phần mềm cung cấp hoặc sản phẩm có nhiều tiềm năng, v.v.

Sản phẩm trong nhóm của chúng tôi chỉ là một phần nhỏ mà công ty có được doanh thu vì nó có một chiếc ô sản phẩm (công ty này không phải là công ty phần mềm / phần cứng; do đó, không có vụ kiện bằng sáng chế liên tục, ít nhất là cho đến nay bất ổn). Những gì tôi đã học được cho đến nay trong những năm này từ kinh nghiệm của các nhà phát triển khác và kinh nghiệm của tôi là để thực sự biết một nhóm phát triển, phải mất thời gian, không phải ngày, cũng không phải tuần, mà là vài tháng. Trong quá trình phỏng vấn nếu nhóm muốn thuê bạn, hoặc cần bạn; họ làm cho mọi thứ nghe có vẻ tuyệt vời, và họ có thể cho bạn biết những gì bạn muốn nghe. Tuy nhiên, thực tế lại khác khi bạn bắt đầu làm việc trong nhóm đó và bắt đầu đào sâu vào mã và tiến tới quy trình SDLC hoàn chỉnh. Đây là khi là một nhà phát triển, bạn bắt đầu nhìn thấy thực tế của công việc bạn đã làm. Thực tế này khiến bạn khó muốn chuyển từ công ty này sang công ty khác bởi vì thật khó để biết liệu công ty bạn chuyển đến sẽ tốt hơn hay tồi tệ hơn. Vâng, bạn có thể đọc các đánh giá của Glassdoor, v.v., nhưng có bao nhiêu trong số những đánh giá trực tuyến đó là có thật, và không phải từ HR?

Điều gì sẽ là cách tốt nhất để giải quyết các vấn đề được nêu dưới đây khi xem xét rằng người quản lý ngay từ đầu đã luôn chống lại sự thay đổi và các nhà phát triển trước đó đã làm điều tương tự trong nhiều năm?

  • Thiếu sản phẩm Đổi mới trong nhiều năm: Sản phẩm có rất nhiều tiềm năng và mang lại doanh thu tốt cho công ty, nhưng sản phẩm có vẻ như đã được sản xuất 20 năm trước. Một số người dùng đã phàn nàn rằng sản phẩm không thân thiện với người dùng cũng không trực quan và những người khác đã đề cập đến việc sử dụng các ứng dụng như Gmail và cảm thấy thất vọng khi sử dụng sản phẩm vì không có các tính năng tương tự. Vấn đề chính ở đây là khi bạn cố gắng làm nhà phát triển để thay đổi sản phẩm và bắt đầu di chuyển các yếu tố chính của sản phẩm xung quanh chỉ một vài pixel (để làm cho nó thân thiện hơn với người dùng hoặc trực quan hơn), người quản lý hoảng loạn và nói với bạn để đặt nó trở lại nơi nó đã được. Nếu bạn cố gắng thêm một tính năng có lợi cho năng suất cho người dùng, người quản lý sẽ yêu cầu bạn xóa tính năng này vì "người dùng đã quen với việc thực hiện quy trình theo cách đó, v.v." Tôi nghĩ rằng bạn có quan điểm chống lại sự thay đổi, cải tiến và đổi mới (người quản lý không sẵn sàng thay đổi, ngay cả khi bạn là nhà phát triển cung cấp các lập luận mạnh mẽ về lợi ích). Công ty có một vài đối thủ cạnh tranh trong lĩnh vực (sản phẩm của một vài trong số đó cạnh tranh hơn), nhưng bằng cách nào đó công ty đã duy trì các khách hàng hiện tại trong nhiều năm.

  • Thiếu sự phối hợp quản lý dự án: Do đó, một số dự án được giao trễ, có lỗi và một số khách hàng phàn nàn (khách hàng cũng báo cáo lỗi) hoặc ngân sách được sử dụng quá nhanh trước khi giao dự án, v.v. Tôi đã cung cấp cho họ một vài mẹo phối hợp dự án và các ý tưởng hiện đang được sử dụng thường xuyên để theo dõi tiến độ của các dự án và nhiệm vụ cần thực hiện.

  • Phần mềm xấu Thực tiễn phát triển: Mùi mã được nhìn thấy trên hầu hết nếu không phải tất cả các tệp, không có tài liệu, dự phòng mã, tầng đầu cuối và mặt sau trộn trên cùng một tệp, các công cụ phát triển lỗi thời, không có môi trường thử nghiệm thực tế cũng như các công cụ kiểm tra (chỉ sao chép và dán các tệp từ môi trường dev đến sản xuất, và sau đó kiểm tra thủ công rằng mọi thứ có vẻ tốt và phát hành). Hầu hết các công cụ phát triển tôi sử dụng để phát triển và thử nghiệm mà nhóm không biết, vì nhóm chỉ sử dụng 2 IDE để phát triển mã và kiểm soát nguồn chỉ khả dụng cho môi trường phát triển. Các nhà phát triển khác đã cố gắng sử dụng các khung công tác mới nhất để cải thiện các vấn đề hiện tại, nhưng người quản lý không thích nó vì "nếu bạn rời đi, thì ai sẽ duy trì mã đó?, Hãy để nó theo cách đó" rời đi và chuyển đến một công ty khác.

Tóm lại, tôi chắc chắn các tình huống tương tự xảy ra với nhiều nhà phát triển ở các công ty khác nhưng do hoàn cảnh khác nhau, nhà phát triển có thể thích ở lại nhóm hơn là đến công ty khác vì lý do như (thuận tiện trong công việc, linh hoạt trong công việc, hoặc lợi ích của công ty hoặc chỉ vì một cơ hội tốt hơn đã không đến). Không có công ty hoàn hảo mà tôi biết, nhưng bạn sẽ là nhà phát triển ứng xử và tiếp cận tất cả các vấn đề này như thế nào để giữ mọi thứ tích cực và cuối cùng thúc đẩy thay đổi để cải thiện sản phẩm và cải thiện quy trình phát triển phần mềm (cho dù bạn có nhiều năm kinh nghiệm phát triển hay chỉ một vài)? Tôi biết đây là bài viết dài, nhưng tôi thích cung cấp thêm chi tiết để tăng cơ hội nhận được phản hồi hữu ích hơn.

Cảm ơn rất nhiều cho tất cả thông tin phản hồi và thời gian của bạn


Thay đổi công việc? ...
Robert Harvey

1
Cũng như một lưu ý, nhiều đánh giá cửa kính là có thật trong kinh nghiệm của tôi.
Telastyn

1
Người quản lý của bạn là người quản lý phát triển hay người quản lý sản phẩm, tức là người quyết định mức độ ưu tiên của các mặt hàng sẽ được phát triển dựa trên giá trị doanh nghiệp mà họ đại diện?
Marjan Venema

4
Bạn có nhận ra rằng những quả bóng lớn của bùn thực sự hoạt động , phải không?
Denis de Bernardy

4
Ít nhất là một phần của việc hoàn thành công việc khi bạn chỉ là người lẩm cẩm của Joel Spolsky có liên quan.
AakashM

Câu trả lời:


18

Câu nói của Martin Fowler có liên quan: "Bạn có thể thay đổi tổ chức của mình hoặc thay đổi tổ chức của mình." Cho rằng rõ ràng bạn đã quyết định thay đổi tổ chức của mình (làm cho nó tốt hơn) thay vì thay đổi tổ chức của bạn (làm việc cho một tổ chức khác), đây là một vài gợi ý.

Đầu tiên, rất nhiều quá trình hành động của bạn phụ thuộc vào chi tiết về cấu trúc quyền lực và chính trị tại nơi làm việc. Có một người quản lý phát triển phần mềm, hoặc một số? Nếu nhiều người, có ai trong số họ không thích thay đổi không? Có bao nhiêu nhà phát triển phần mềm? Là các nhà phát triển quan tâm đến việc thay đổi? Nếu vậy, có một số thay đổi mà bạn sẽ có thể thực hiện ngay cả khi không có sự chấp thuận của ban quản lý. (Như Fowler gợi ý trong Tái cấu trúc , bạn thậm chí có thể không phải nói với quản lý. Có lẽ bạn được thuê để phát triển phần mềm một cách tốt nhất có thể, vì vậy nếu có cách nào tốt hơn thì hãy làm điều đó.)

Thứ hai, hãy nhớ rằng quản lý có thể có lý do chính đáng cho những gì họ đang làm. Bạn là nhà phát triển phần mềm; công việc của bạn là phát triển phần mềm tốt và biết các kỹ thuật tốt để làm việc đó. Công việc của ban quản lý là tìm hiểu các vấn đề hình ảnh lớn hơn và các cân nhắc kinh doanh có thể vượt ra ngoài tầm nhìn của bạn. Ngay cả khi bạn đúng và họ sai về những điều cần cân nhắc trong kinh doanh (mối quan tâm của bạn về việc thiếu đổi mới, giao hàng trễ, khiếu nại của khách hàng, v.v.), hiểu được quản lý đến từ đâu sẽ giúp bạn giao tiếp theo cách của họ, giảm bớt mối quan tâm của họ, và như vậy.

Thứ ba (và liên quan), đảm bảo bạn có thể nói ngôn ngữ kinh doanh. Một doanh nghiệp (đúng) không liên quan trực tiếp đến các thực tiễn phát triển phần mềm tốt; một doanh nghiệp quan tâm đến việc phục vụ nhu cầu của khách hàng và kiếm lợi nhuận. (Và nhiều doanh nghiệp rõ ràng sẽ phục vụ nhu cầu tối thiểu có thể để kiếm lợi nhuận.) Bạn sẽ hiệu quả hơn trong việc thúc đẩy thay đổi nếu bạn có thể giải thích cách thực hành phát triển phần mềm xấu và thiếu đổi mới sẽ ảnh hưởng đến lợi nhuận của công ty hoặc lâu dài Sức khỏe.

Thứ tư, thay đổi văn hóa công ty từ vị trí của một công nhân cấp bậc là vô cùng khó khăn. James Shore (một nhà tư vấn và tác giả nhanh nhẹn) đã viết Nhật ký thay đổi mô tả những nỗ lực của chính mình khi làm như vậy. Tôi thực sự khuyên bạn nên đọc toàn bộ. Một vài điểm liên quan:

  • Đừng cố gắng thay đổi mọi thứ cùng một lúc. Tìm những điểm đau lớn nhất và bắt đầu từ đó. Đưa mọi người lên tàu bằng cách giúp họ xem những thay đổi của bạn giải quyết những điểm đau đó.
  • Hiểu quan điểm của người khác. Shore nói về những thay đổi mà anh ấy đã thúc đẩy từ góc độ phát triển phần mềm đã bị người quản lý dự án chống lại vì anh ấy (Shore) không xem xét những thay đổi đó sẽ ảnh hưởng đến người quản lý dự án như thế nào.
  • Cuối cùng, bạn sẽ cần một số hỗ trợ từ cấp cao hơn, ngay cả khi bạn đang tự mình nhắc nhở hầu hết các thay đổi. Shore nói về nhà vô địch của anh ấy ("ai đó tôi làm việc với người có nhiều đầu mối hơn tôi và thường nghĩ giống như những gì tôi làm").

4
Lời khuyên thực tế, quá nhiều lần các nhà phát triển chỉ nghĩ về codebase chứ không phải về mặt kinh doanh và bỏ lỡ một bức tranh lớn tạo nên những gì chúng ta làm và tại sao chúng ta làm điều đó.
gbjbaanb

Shore nói về nhà vô địch của anh ấy ("ai đó tôi làm việc với người có nhiều đầu mối hơn tôi và thường nghĩ giống như những gì tôi làm" - để tôi phải thêm "nhưng không cố gắng thay đổi bất cứ điều gì". quá nhiều
Mawg nói rằng phục hồi Monica

10

Câu trả lời ngắn gọn rõ ràng là rời khỏi công ty. Những người khác đã rời đi, và người quản lý của bạn là một cản trở tích cực để tiến bộ. Nếu bạn ở trong vị trí đó, bạn sẽ dần dần phân rã (cả về tinh thần và kỹ năng). Tìm một công việc mới không phải lúc nào cũng dễ dàng, nhưng trong trường hợp này là cần thiết.

Chỉ trong trường hợp bạn chọn không rời khỏi công ty (dòng đầu tiên của loại câu hỏi của bạn đã đưa ra điều đó):

Người quản lý của bạn có một ông chủ? Nếu vậy, ông chủ đó xem sản phẩm như thế nào? Bạn có thể (tôi thậm chí có thể nói không?) Đi qua đầu quản lý của bạn và tiếp cận ông chủ của mình? Đừng cằn nhằn anh ấy với các chi tiết kỹ thuật, chỉ thể hiện sự quan tâm và nhiệt tình trong việc phát triển trong công ty. Trình bày ý tưởng hữu hình cho những cải tiến có thể ảnh hưởng đáng kể đến điểm mấu chốt. Bạn có thể được thăng chức từ dưới chướng ngại vật.

Mặc dù được cảnh báo - trong khi một số bánh xe rít lên bị bôi trơn, những cái khác được thay thế. Bạn S khiến người quản lý của bạn không thích bạn. Anh ta sẽ nghe về điều này, và anh ta sẽ nói những điều không tử tế về bạn với sếp của anh ta. Bước đi cẩn thận, nhưng hãy nhớ - không có rủi ro, không có phần thưởng.

Điều tồi tệ nhất có thể xảy ra là bạn sẽ tìm kiếm một công việc mới, dù sao bạn cũng nên làm.


2
Xin lỗi, tôi đã phải downvote, vì OP đặc biệt nói rằng anh ấy không tìm kiếm lời khuyên dọc theo dòng chữ "Tìm kiếm một công việc mới".
KChaloux

4
@KChaloux - Cảm ơn phản hồi. Hầu hết câu trả lời của tôi không phải là "tìm kiếm một công việc mới", nhưng tôi cảm thấy bỏ đi điều đó sẽ là một sự bất đồng và dẫn đến một câu trả lời không đầy đủ.
Dan Pichelman

9

Có vẻ như đã đến lúc bạn tìm hiểu về những con bò tiền mặt. Tới đâyở đây . Và hãy xem Ma trận chia sẻ tăng trưởng . GSM cung cấp một số thông tin bổ sung về lý do tại sao bò tiền mặt là một trạng thái tốt.

Investopedia (liên kết thứ hai) có lẽ có trích dẫn tốt nhất trong trường hợp này.

  1. Một con bò tiền mặt đòi hỏi ít vốn đầu tư và cung cấp dòng tiền dương, có thể được phân bổ cho các bộ phận khác trong tập đoàn. Những người tạo ra tiền mặt này cũng có thể sử dụng tiền của họ để mua lại cổ phiếu trên thị trường hoặc trả cổ tức cho các cổ đông.

Như bạn đã lưu ý, có một số mặt tích cực khi tham gia vào một dự án tiền mặt.

  • Nó ổn định
  • Một mức độ khiêm tốn của sự phát triển mới được đảm bảo
  • Luôn luôn có công việc sửa lỗi để khắc phục.

Và như bạn cũng lưu ý, có một số nhược điểm đối với các dự án đó.

  • Nó ổn định và cơ sở mã không chuyển qua nhiều
  • Các công nghệ mới thường bị bỏ qua (quá đắt để bắt đầu)
  • Và mọi thứ trở nên ... cũ kỹ.

Tôi đã từng làm việc trong một dự án nơi tôi có nhiều khiếu nại tương tự như những gì bạn đã nêu ra. Tôi nhớ rõ ràng chia sẻ mối quan tâm của tôi về cơ sở mã với sếp của tôi tại thời điểm đó. Cái nhìn sâu sắc của anh ấy không đặc biệt khai sáng nên tôi sẽ không chia sẻ nó. Nhưng tôi đã dập tắt dự án và sự thật được nói, đó là một trong những dự án tốt hơn tôi từng thấy. Không, nó không hào nhoáng. Vâng, chúng tôi đã bỏ lỡ thời hạn. Vâng, tôi đã lên kế hoạch cho một vài cuộc tuần hành tử thần từ đó. Không, công nghệ mã không phải là tất cả sáng tạo nhưng chúng tôi đã tạo ra một số giải pháp tuyệt vời.

Vấn đề là tôi. Tôi không có đủ quan điểm để hiểu những gì một cơ sở mã thực sự đòi hỏi để tồn tại. Tôi không có kinh nghiệm để xem nơi mà sự đổi mới đang thực sự xảy ra. Tôi đã không hiểu các nguyên tắc cơ bản của thị trường chỉ ra mức tài trợ phù hợp cho dự án tiền mặt đó là bao nhiêu.

Tôi sẽ khuyến khích bạn xem đây là cơ hội học tập để hiểu rõ hơn về cách thức kinh doanh và cách bạn có thể cải thiện kỹ năng của mình trong việc điều chỉnh sản phẩm theo nhu cầu của doanh nghiệp. Mặc dù công việc có thể không hào nhoáng, nhưng tiềm năng học tập rất cao và những kỹ năng đó sẽ giúp bạn vững bước sau này trong sự nghiệp. Phần lớn phát triển cấp độ công ty xoay quanh tất cả các ràng buộc bạn vừa đề cập. Các mã hôi thối; mọi thứ đã được đặt tại chỗ để chứa thời hạn đã thoát ra; nhiều nhà phát triển chống lại sự thay đổi.

Tại một số điểm, bạn vẫn sẽ chuyển từ dự án. Những bài học bạn có thể mang theo bên mình có thể là những bài học thực sự cho sự nghiệp.


2
+1, tôi đã thấy các công ty chạy trong chế độ này trong hơn một thập kỷ. Một khi chúng có quán tính, chúng sẽ chạy trong một thời gian dài.
GrandmasterB

2
Thực sự sâu sắc. Các lập trình viên dường như chủ yếu cho rằng họ đang hoặc nên làm việc với các dự án "ngôi sao" đầu tư cao, và tham chiếu Ma trận Chia sẻ Tăng trưởng giải thích lý do tại sao điều này rất hợp lý không phải là trường hợp. Sẽ thật tuyệt nếu biết các dự án bò tiền mặt có xu hướng tốt cho những người lao động tham gia - đó là công việc quan trọng, nhưng chi phí tiền mặt thấp có xu hướng có nghĩa là trả lương thấp cho mỗi công nhân, hoặc chỉ cần ít công nhân hơn? Và họ sẽ không trở thành công nghệ tiên tiến.
psr

1
@psr - Kinh nghiệm của tôi là nó cũng có thể tốt cho người lao động. Trong thực tế, tôi đã thấy đề nghị thanh toán tốt hơn từ các công ty ổn định hơn. Nhưng tôi chưa bao giờ làm việc cho một tổ chức thực tế, bỏ qua tỷ lệ bỏ qua. "Tiền mặt thấp" là một thuật ngữ tương đối và xoay quanh chi phí cơ hội hơn bất kỳ thứ gì khác. Các quỹ luôn có sẵn cho các dự án có thể chứng minh ROI thích hợp. Tuy nhiên, một số năm, ngưỡng ROI đó cao hơn các mức khác do cạnh tranh nội bộ đối với các quỹ đó.

5

Người quản lý của bạn có thể chống lại sự thay đổi bởi vì anh ta thấy không có giá trị (kinh doanh) nào đang thay đổi thực tiễn. Doanh nghiệp thấy không có vấn đề thực sự bởi vì bất cứ điều gì được yêu cầu của nhóm phát triển cuối cùng cũng được thực hiện và các khiếu nại của khách hàng không được gửi đến những người quan tâm và / hoặc có thể làm gì đó để đảm bảo kết quả tốt hơn. Hoặc là hoặc doanh nghiệp đã chấp nhận tình trạng hiện tại là không thể tránh khỏi.

Nếu bạn sẽ thay đổi thực tiễn phát triển, bạn cần cho họ thấy rằng tình trạng hiện tại là không thể tránh khỏi. Và cách duy nhất bạn sẽ được lắng nghe là xây dựng một trường hợp kinh doanh cho thấy tình trạng hiện tại đang làm tăng chi phí của sản phẩm và kìm hãm tiềm năng doanh thu như thế nào khi đưa ra một tình huống khác.

Để xây dựng trường hợp kinh doanh đó, bạn cần nói chuyện với người quản lý sản phẩm của phần mềm này. Người quản lý sản phẩm là người quyết định mức độ ưu tiên của các mặt hàng sẽ được phát triển dựa trên giá trị kinh doanh mà chúng đại diện. Người quản lý sản phẩm là (nên) là người có thể thấy được lợi ích và giá trị kinh doanh của việc có thể xây dựng phần mềm tốt hơn nhanh hơn. (Và tôi hy vọng nó không giống với trách nhiệm của nhóm phát triển.)

Trường hợp kinh doanh cần giải quyết những ảnh hưởng đối với doanh thu kinh doanh của:

  • Các tính năng chưa được triển khai sẽ tạo ra nhiều khách hàng hơn hoặc giữ được nhiều khách hàng hơn nếu họ được triển khai.
  • Các tính năng được thực hiện không đầy đủ tạo ra sự không hài lòng của khách hàng và dẫn đến sự tiêu hao trong khách hàng.

Trường hợp kinh doanh cũng cần cho thấy các thực tiễn phát triển hiện tại đang ảnh hưởng đến tốc độ và chi phí phát triển các tính năng cần thiết như thế nào:

  • Mất bao lâu để thực hiện ngay cả những thay đổi đơn giản nhất.
  • Có bao nhiêu lỗi được giới thiệu là kết quả của việc phát triển các tính năng mới, cả về tính năng mới cũng như thiệt hại tài sản thế chấp trong các tính năng khác.
  • Mất bao nhiêu thời gian để sửa những lỗi này không thể dành cho việc triển khai các tính năng mới.
  • Có bao nhiêu cuộc gọi hỗ trợ được tạo vì những lỗi này và nhân viên hỗ trợ cần chi bao nhiêu cho các cuộc gọi này.

Và tất nhiên cần phải cho thấy việc áp dụng các thực tiễn phát triển tốt hơn sẽ ảnh hưởng đến những con số này như thế nào.

Bạn có thể phải đối mặt với sự cần thiết phải viết lại (chính) các phần (chính) của phần mềm. Ngay cả khi bạn không, thì Làm thế nào để sống sót khi viết lại từ đầu mà không mất đi sự tỉnh táo của bạn là phải đọc cách tiếp cận các loại dự án này.

Lưu ý cuối cùng: nếu người quản lý sản phẩm không quan tâm đến tất cả những điều này, bạn sẽ bị mất: nhảy tàu.


Cảm ơn thời gian và phản hồi của bạn. Tôi đồng ý, lý do chính tại sao quản lý cấp cao không thấy những vấn đề này là những gì bạn đã đề cập: "khiếu nại của khách hàng không được gửi đến những người quan tâm và / hoặc có thể làm gì đó để đảm bảo kết quả tốt hơn" là điều mà nhà phát triển có thể làm để tránh điều đó?
kami

@kami: Ngoài: bắt đầu tổng hợp các số liệu và khiến họ chú ý bởi những người quan tâm? Không, không nhiều nếu bạn giới hạn bản thân trong vai trò là nhà phát triển. Nếu bạn muốn mọi thứ thay đổi, bạn sẽ phải bước ra ngoài ranh giới trở thành nhà phát triển. Làm cho số liệu của bạn thẳng, trình bày chúng cho người quản lý của bạn trước và chỉ cho những người ở trên / bên cạnh anh ấy / cô ấy khi anh ấy không hành động. Đừng vượt qua đầu anh ấy / cô ấy với kết quả của bạn trước khi cho phép anh ấy / cô ấy tỏa sáng với công việc của bạn. Nó sẽ đi một chặng đường dài để đạt được kết quả mong muốn của bạn.
Marjan Venema

Cảm ơn. Người quản lý 'sản phẩm' hiện tại là một lập trình viên bằng cách nào đó đã trở thành người quản lý, và bây giờ là người quản lý phát triển, người quản lý sản phẩm và người quản lý dự án.
kami

@kami: không may là một công thức nổi tiếng cho sự sụp đổ do "Nguyên tắc Peter: Tại sao mọi thứ luôn đi sai" . Cuốn sách gốc: Nguyên lý Peter
Marjan Venema

4

Tôi nghĩ rằng đây là một vấn đề thực sự khó khăn với không có giải pháp trực tiếp. Dưới đây là một số ý tưởng về những gì bạn có thể thử làm:

Sợ thay đổi Về chủ đề thay đổi mọi thứ tốt hơn tôi hiểu lý do tại sao quản lý sợ thay đổi. Mọi người đã quen với mọi thứ theo một cách nhất định và nếu bạn thay đổi nó, người dùng sẽ nổi loạn (có thể). Thay đổi là một điều đáng sợ và thường đòi hỏi rất nhiều suy nghĩ và nghiên cứu trước khi thực hiện. Những gì bạn cần là dữ liệu để cho thấy rằng điều này là tốt hơn và người dùng muốn nó. Nói về gmail, bạn có thể xem xét một số thứ như "Google Labs" nơi bạn có thể bật / tắt các tính năng mới để người dùng có thể dùng thử. Sau đó kết nối một số bộ sưu tập dữ liệu xung quanh điều này để giúp sao lưu các thay đổi của bạn.

Thay đổi quy trình phát triển phần mềm Thay đổi một lần nữa mọi người khó thay đổi vì bạn nói có một cách tốt hơn. Tôi nghĩ rằng trong kịch bản này, đề xuất tốt nhất của tôi là dẫn dắt bằng ví dụ. Làm những việc theo cách mà bạn muốn chúng được thực hiện và cho mọi người thấy nó tốt hơn bao nhiêu. Ngoài ra, và đây là chìa khóa, bạn cần tìm những người khác chia sẻ suy nghĩ của bạn. Nếu bạn có thể có được một vài người trên tàu sẽ giúp ích rất nhiều cho sự nghiệp của bạn. Khi bạn có thể hiển thị một số kết quả thì bạn có thể tiếp cận quản lý về việc làm cho những thay đổi này rộng hơn. Tôi thấy rằng một từ trên xuống và một nỗ lực rễ cỏ thực sự có ích với việc thực hiện các thay đổi.

Ngoài ra, về phía các công cụ, các công ty sợ nâng cấp / thay đổi những thứ này bởi vì chúng tốn tiền và kết quả của các công cụ mới không phải lúc nào cũng có thể đo lường được. Giới thiệu của tôi ở đây là để làm cho các công cụ của riêng bạn. Nếu bạn tự làm, bạn sẽ tiết kiệm thời gian và làm việc tốt hơn. Hy vọng mọi người sẽ bắt đầu chú ý và sau đó cũng muốn sử dụng chúng.

Thay đổi quản lý Điều này thật khó khăn và tôi không chắc làm thế nào ngoài việc là người tạo ra kết quả và có ý kiến ​​của họ có giá trị. Một khi ý kiến ​​của bạn có giá trị, mọi người có thể bắt đầu lắng nghe hoặc họ có thể không.

Cuối cùng hãy nhớ thay đổi là khó khăn và mất thời gian. Treo ở đó và bắt đầu nhỏ và xây dựng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.