Làm quản lý dự án tốt cần một nền tảng lập trình? [đóng cửa]

Đôi khi tôi không thể chịu đựng được khi các nhà quản lý dự án yêu cầu tôi ước tính thời gian để hoàn thành các nhiệm vụ khác nhau. Ước tính là một phỏng đoán và đoán có thể sai. Nói chung, các yêu cầu và tài liệu xấu sẽ dẫn đến dự đoán xấu.

Vì vậy, tôi thường tự hỏi liệu các nhà quản lý dự án có từng cố gắng đoán xem nhiệm vụ X và Y sẽ mất bao lâu không, và việc gán một số cho nó dựa trên những gì ít được biết và thu thập từ khách hàng.

Câu hỏi của tôi là: Những người quản lý dự án giỏi có cần phải có một nền tảng lập trình không?

Hoặc có lẽ câu hỏi nên là, những người quản lý dự án tốt có cần phải là một lập trình viên giỏi trước đây không? Có bất kỳ mối tương quan?

Quản lý dự án CNTT chắc chắn không giống như quản lý các loại dự án khác. Tôi đã từng nghe nói về một người quản lý dự án không có kinh nghiệm về CNTT. Cuối cùng anh ta đã làm các lập trình viên thất vọng và về cơ bản khiến họ sợ hãi.

Mặt khác, một lập trình viên trở thành Quản lý dự án có thể trở thành một người thích kiểm soát, nghĩ rằng anh ta có thể sửa chữa mọi thứ nếu anh ta không thể khiến các lập trình viên thực hiện đúng (đó là vấn đề của tôi trong các tình huống tương tự)

Một người quản lý có nền tảng kỹ thuật mạnh mẽ thường hiểu rõ hơn cách nhóm của họ "nghĩ". Luôn luôn tốt hơn để có một người quản lý hiểu bạn, phải không?

Số hai kỹ năng hoàn toàn khác nhau. Người quản lý dự án tồi không nhất thiết là người không hiểu về CNTT và ngược lại.

Hợp lý, hợp lý, có tổ chức, hiểu các mục tiêu dự án và kinh doanh liên quan , và một động lực tốt hoàn toàn không phụ thuộc vào khả năng lập trình.

Mọi thứ khác như nhau, tôi thích một người quản lý dự án có kinh nghiệm kỹ thuật mạnh mẽ, cập nhật . Tuy nhiên, trong thế giới thực, các lập trình viên tốt nghiệp ngành quản lý dự án toàn thời gian có nhiều khả năng cho phép bộ kỹ năng của họ trở nên cũ kỹ và lỗi thời, điều này không tốt hơn nhiều so với họ không có nền tảng kỹ thuật.

Tôi đã làm việc với những người quản lý dự án tốt và một số người kinh khủng, và tôi có thể thành thật nói rằng tôi đã thấy rất ít mối tương quan giữa khả năng quản lý và nền tảng kỹ thuật của họ. Yếu tố quan trọng nhất không phải là nền tảng kỹ thuật, mà là họ có bao nhiêu kinh nghiệm quản lý các dự án phần mềm . Nếu bạn có hai người quản lý dự án đầu tiên của họ, lập trình viên tốt nghiệp ngành quản lý dự án sẽ tệ như người quản lý dự án không có nền tảng CNTT. Cả hai sẽ trải qua một quá trình học tập dốc.

Cuộc tranh cãi về khả năng của các nhà quản lý dự án không có nền tảng kỹ thuật nhắc nhở tôi một chút về điều này:

Tôi thành thật nghĩ rằng câu trả lời là không. Có một hành lý đầy đủ các năng lực cần thiết để trở thành một người quản lý dự án tốt và trở thành một lập trình viên không phải là một trong số họ. Một người quản lý dự án tốt có thể quản lý bất kỳ dự án thuộc bất kỳ loại nào nếu có những người giỏi trong nhóm dự án biết họ đang làm gì. Chất lượng chính mà người quản lý dự án nên có là kỹ năng giao tiếp . Công việc của người quản lý dự án là điều phối các nhiệm vụ của dự án và duy trì liên lạc giữa khách hàng, nhóm dự án và bất kỳ bên liên quan nào khác. Anh ấy / cô ấy nên biết mọi lúc về tiến trình của đội và nếu họ gặp phải những trở ngại, nhưng không cần biết vấn đề là gì hoặc bạn cần khắc phục điều gì, trừ khi điều đó liên quan đến một người khác trong đội sẽ có thời gian cần được điều chỉnh để giúp khắc phục vấn đề.

Đối với việc đưa ra ước tính, đó là một thực tế của cuộc sống trong bất kỳ công việc. Bạn không bao giờ có thể xây dựng một ngôi nhà đúng giờ nếu thợ điện không thể cho bạn biết anh ta sẽ mất bao lâu để làm hệ thống dây điện - khi nào bạn sẽ biết đặt anh chàng tường của mình? Mặc dù vậy, tôi đồng ý rằng CNTT rất khó đưa ra ước tính vì số lượng người không thể tin được rất cao. Khách hàng không phải lúc nào cũng biết những gì họ muốn và họ có xu hướng quên nói với bạn một loạt điều. Những gì tôi từng làm là ước tính khoảng thời gian tôi nghĩ sẽ mất bao lâu, sau đó nhân nó lên 2! Và một người quản lý chương trình giỏi không nên đóng đinh bạn khi ước tính của bạn sai, điều đó sẽ khiến anh ta đau đầu sắp xếp lại lịch trình, nói chuyện với khách hàng, giải thích với các ông chủ rằng nó sẽ tốn kém hơn, v.v ... Nhưng đó là một phần công việc của họ - một lần nữa, chủ yếu là những gì được yêu cầu.

Và tôi thậm chí sẽ nói rằng không có bất kỳ kỹ năng lập trình nào thậm chí còn tốt hơn - một lập trình viên cũ có thể cố gắng tự mình ước tính hoặc đoán thứ hai ước tính của bạn. Và tất cả chúng ta đều biết rằng các kỹ năng CNTT đã lỗi thời rất nhanh. Bạn cần bắt đầu đặt câu hỏi khi người quản lý dự án của bạn quan tâm nhiều hơn đến cách bạn sẽ thực hiện một nhiệm vụ hơn là thời gian có thể và khi nào bạn sẽ hoàn thành. Họ có thể yêu cầu bạn đánh giá các lựa chọn thay thế và cho phép bạn băm chi tiết nhưng điểm chính là để biết bạn sẽ ảnh hưởng đến lịch trình của dự án như thế nào.

Cuối cùng, tôi không nói rằng không cần phải có kỹ năng CNTT để quản lý dự án CNTT - Người CNTT là loại người dường như không thể thô tục hóa những gì họ đang nói cho dân gian (!), Điều này giúp biết biệt ngữ cơ bản để có thể giao tiếp với họ! Ngoài ra, biết các bước cơ bản là rất quan trọng - bạn cần thiết lập một máy chủ trước khi chạy một trang web trên đó. Tôi không thể quản lý một dự án xây dựng nếu tôi không biết rằng thợ điện phải hoàn thành hệ thống dây điện trước khi tôi đóng tường !!

Một PM thực sự cần biết dự án sẽ làm gì, có khả năng đòi hỏi một số nền tảng kỹ thuật nhưng không phát triển.

Ngoài ra, đó là vấn đề tôn trọng lĩnh vực và nhà phát triển, hơn cả kiến ​​thức thực tế. Một thủ tướng cần nghiêm túc với các nhà phát triển, những gì họ cần, những gì họ có thể làm, những gì họ không thể, mất bao nhiêu thời gian. Một thủ tướng có một số ý tưởng về những gì mình không biết có thể rất hiệu quả. Một thủ tướng nghĩ rằng mình có tất cả các câu trả lời là xấu. Đây có thể là một nhà phát triển cũ tin rằng anh ta hoặc cô ta biết tất cả mọi thứ và không, hoặc một người không bao giờ phát triển và không nghĩ rằng anh ta cần bất kỳ kiến ​​thức kỹ thuật đặc biệt nào để quản lý.

Tôi không nghĩ rằng một người quản lý dự án của một dự án CNTT đòi hỏi một nền tảng CNTT. Nhưng anh ấy / cô ấy chắc chắn phải hiểu CNTT, và nên biết các dự án CNTT hoạt động như thế nào.

Mặc dù nền tảng CNTT là một lợi thế bổ sung, nhưng thiếu nó không làm cho một người quản lý dự án CNTT không tốt. Ngoài ra có một nền tảng CNTT không phải là yếu tố quyết định.

Tôi đã làm việc với cả hai loại, và mỗi loại đều có những phẩm chất và vấn đề riêng.

Với nền tảng CNTT:
- Sẽ hiểu khi chúng tôi nói lỗi hiệu suất vì mã không đa luồng
- Nhưng, trong một số trường hợp, sẽ nói "này, bạn chỉ cần thêm 4 dòng mã, bạn có thể làm điều đó trong 10 ngày"

Không có nền tảng CNTT:
- Sẽ rất thoải mái khi đàm phán để thay đổi thời hạn thoải mái
- Đối với một dự án không có bất kỳ yêu cầu nào (đôi khi), đôi khi sẽ nói "chúng ta có thể ước tính sơ bộ 100 ngày và đề cập đến bộ đệm 30%.

Tôi tin rằng họ cần một số nền tảng lập trình. Nếu không thì họ sẽ luôn gây áp lực cho các lập trình viên nhanh chóng thực hiện nhiệm vụ của họ và mong đợi nó sẽ được thực hiện trong vòng vài giờ khi thực sự nhiệm vụ đòi hỏi rất nhiều suy nghĩ và cống hiến. Những phẩm chất này được biết đến và thành thạo với các lập trình viên, vì vậy nếu người quản lý dự án có nền tảng lập trình thì anh ta / cô ta sẽ hiểu một nhiệm vụ cụ thể sẽ mất bao lâu và sẽ không có tranh luận trong bộ phận và do đó cuối cùng một dự án tốt sẽ phát triển.

@NimChimpsky Tôi đồng ý.

Đó là vấn đề của cái gì , không phải như thế nào (Lắng nghe tích cực là một công cụ tốt).

Dự toán hoạt động cho các nhiệm vụ kỹ thuật nhỏ, nhưng để lập kế hoạch, bạn cần phải làm việc cùng nhau để thấy toàn bộ sự phức tạp. Và bạn không phải là đối thủ.

Nó chắc chắn sẽ giúp đặc biệt nếu họ không phải là một người quản lý dự án tốt. Đối với một người quản lý dự án tốt, nó thực sự quan trọng.

Không.

Người quản lý dự án giỏi là người có thể đồng cảm và hiểu được nhu cầu, sở thích và khả năng của nhóm mình là gì, cho dù đó là tại công trường xây dựng, sàn sản xuất hay nhà phát triển phần mềm.

Người quản lý dự án tốt hay xấu có thể có bất kỳ loại nền tảng nào:

Những người quản lý tồi với nền tảng kỹ thuật có thể là những lập trình viên không đánh giá cao những người mới gặp khó khăn khi đối phó với những khái niệm trần tục, "dễ dãi" như con trỏ.

Một người quản lý giỏi có thể là một lập trình viên trung bình, người không thông minh hay thông minh như các đồng nghiệp của mình nhưng hiểu biết sâu sắc về cấu trúc dự án, các yêu cầu và hiểu được bài học của Tháng huyền thoại bởi vì anh ta đã sống những ngày mã hóa tồi tệ và đã nhai vì không hoàn thành việc giao hàng của mình đúng hạn.

Một người quản lý tốt có thể là anh chàng bán hàng phần mềm phát hiện ra rằng những người bạn lập trình viên của anh ta không thể đi chơi với anh ta vào cuối tuần vì những lời hứa không thực tế mà anh ta đã đưa ra cho khách hàng.

Kiến thức kỹ thuật không xác định trước trình độ của một lập trình viên với tư cách là người quản lý, bởi vì các kỹ năng cần thiết trong cả hai công việc hoàn toàn khác nhau. Vì vậy, không.

Tôi chưa bao giờ thấy một người quản lý dự án không có kinh nghiệm về CNTT có thể quản lý một dự án phát triển phần mềm không tầm thường đáng chết. Tôi đã thấy rất ít người quản lý dự án có kinh nghiệm về CNTT có thể làm điều đó, nhưng họ dường như ít làm hỏng nó hơn.

Theo kinh nghiệm của tôi, quản lý là về giao tiếp hiệu quả và ra quyết định. Với ý nghĩ đó, điều hợp lý là ai đó hiểu về nghề thủ công (ít nhất là các khái niệm và thuật ngữ cốt lõi) được sử dụng bởi những người họ quản lý, phù hợp để trở thành người quản lý hơn người ít hiểu biết, nhưng chắc chắn là có Không liên quan. Tôi đã thấy các nhà quản lý có kinh nghiệm lập trình thành công và thất bại, cũng giống như các nhà quản lý không có kinh nghiệm lập trình.

Hoặc là cực đoan là xấu, theo ý kiến ​​của tôi; Những người có quá ít kinh nghiệm lập trình có thể tin tưởng một cách mù quáng vào các lập trình viên của họ (Shepard theo con cừu); Những người có quá nhiều kinh nghiệm có thể liên tục đặt câu hỏi về nỗ lực của nhóm họ (quản lý vi mô).

Cá nhân, tôi nghĩ ai đó nắm vững các khái niệm lập trình cốt lõi, nhưng nhận ra rằng họ không phải là một "người nóng bỏng", là kiểu người quản lý lý tưởng.

Chắc chắn rồi.

Tôi phải cẩn thận với điều này vì nó dựa trên những câu chuyện có thật nhưng tôi sẽ cố gắng giải thích nỗi đau của mình.

Tôi đang làm việc như một kỹ sư phần mềm và chúng tôi có một người quản lý dự án mà tôi đang làm việc rất nhiều gần đây. Anh ta không có nền tảng kỹ thuật và có vẻ như điều đó không làm anh ta quan tâm nhưng đó không phải là vấn đề (mọi người đều có lợi ích riêng). Nếu bạn không muốn có bí quyết kỹ thuật vì nó "quái đản" hơn là của bạn NHƯNG nếu công việc của bạn là nói chuyện với khách hàng ở cấp độ kỹ thuật, điều cần thiết là phải có kiến ​​thức kỹ thuật mà anh ta không biết có.

Dù sao, có anh chàng này anh ta không hiểu bất cứ điều gì về cách một máy chủ hoạt động, cách một trang web hoạt động, cách lập trình hoạt động và như vậy. Đôi khi tôi cảm thấy như anh ấy không biết BẤT CỨ NÀO. Vì vậy, mỗi khi tôi cố gắng làm cho anh ấy rõ ràng những gì chúng ta phải làm bây giờ hoặc vấn đề là những gì chúng ta có tại thời điểm anh ấy không hiểu bất cứ điều gì. VÀ anh ta không phải là kiểu người sẽ nói "Đợi một chút. Bạn có thể nhắc lại rằng tôi thực sự không hiểu lắm về điều đó." Không, anh ta là kiểu người không muốn chứng tỏ rằng anh ta không hiểu gì trong toàn bộ cuộc trò chuyện.

Nhưng nó không kết thúc ở đây vì sau đó anh ta gọi cho khách hàng và nói điều gì đó về cơ bản là không đúng sự thật. Và kết cục là chúng ta phải gọi khách hàng lại với nhau để làm cho nó rõ ràng trở lại.

Đó là lý do tại sao tôi nói rằng nó thực sự là ESSENTIAL để có một số nền tảng kỹ thuật cơ bản và bí quyết kỹ thuật. Anh ta không nên viết mã nhưng anh ta có thể hiểu những gì đang diễn ra và những quy trình phải được thực hiện.

BTW kể từ khi tôi làm việc với anh ấy, công việc của tôi không còn vui nữa.

Tôi sẽ nói có, anh ta nên có một số nền tảng lập trình. Nếu người quản lý không có manh mối về việc lập trình như thế nào, thì anh ta sẽ kết thúc với các ước tính không thực tế để phát triển và sửa lỗi. Ngoài ra, anh ta sẽ không hiểu rõ bất kỳ vấn đề kỹ thuật nào đủ để đưa ra quyết định. Các lập trình viên trong nhóm có thể nói dối anh ta và anh ta có thể không nhận ra, các lập trình viên cũng có thể nói với anh ta một vấn đề và anh ta có thể nghĩ rằng họ đang nhảm nhí xung quanh

Kỹ năng kỹ thuật không làm cho một người quản lý tốt, kỹ năng quản lý tốt làm. Nó có thể hữu ích nếu một người quản lý đã dành thời gian của họ trong "chiến hào" vì họ có thể đánh giá cao quá trình mà giáo dân không thể có. Tuy nhiên, nó cũng có thể dẫn đến một loại quái vật kiểm soát mà thậm chí kiểm soát những người quản lý giáo dân kỳ dị không có. Họ có thể cố gắng tự làm tất cả công việc hoặc xem xét kỹ lưỡng công việc của bạn một cách cực kỳ khó chịu.

Theo kinh nghiệm cá nhân của tôi, người quản lý tốt nhất tôi từng có khá là không biết gì về công nghệ, nhưng anh ấy biết rằng những người làm việc dưới quyền anh ấy biết công cụ của họ, và anh ấy biết làm thế nào để có được sự trung thành và tôn trọng của đội ngũ của mình. Tôi làm việc dưới quyền anh ấy bốn năm và chỉ rời công ty vì anh ấy đã rời đi và được thay thế bởi một người quản lý không tốt.

Một trong những người quản lý tồi tệ nhất mà tôi từng có là chuyên về mã hóa (nếu không phải là thiết kế phần mềm) và tự mình làm rất nhiều công việc đến nỗi anh ta để lại cho chúng tôi ít nhiều hơn là phế liệu, sửa lỗi hoặc các dự án mà anh ta không muốn để tự làm

Dường như có một số nhầm lẫn:

Thủ tướng không phải là ông chủ của các nhà phát triển . Người chịu trách nhiệm cho nhóm phát triển (Trưởng nhóm, Quản lý) và việc tuyển dụng và đánh giá sẽ quyết định xem bạn có làm việc chăm chỉ không.

Ước tính không hoàn hảo. Tôi nghĩ Thủ tướng hiểu điều này nhiều hơn bạn nghĩ. Bạn có nghiêm túc mong đợi không ai hỏi bạn mất bao lâu để làm một cái gì đó không? Mọi người đều muốn biết khi nào nó hoàn thành và đó là công việc của PM để theo dõi nó.

Bạn có thể là một PM là bạn: A) hiểu cách quản lý dự án B) hiểu quá trình phát triển. Cả hai điều này đều đòi hỏi kiến ​​thức về mã hóa, nhưng nó có thể giúp ích.

Xác định xem các lập trình viên có hoàn thành đủ không không phải là công việc của Thủ tướng trừ khi anh ta đóng vai trò là trưởng nhóm. Để biết liệu có ai "thổi khói" về thời gian hoàn thành nhiệm vụ hay không, người quản lý sẽ luôn có lợi thế nếu anh ta hiểu những gì liên quan.

Ước tính sẽ tốt hơn với các lập trình viên có kinh nghiệm có lịch sử làm việc trên một loại dự án cụ thể. Không ai mong đợi họ hoàn hảo, nhưng họ thực sự mong bạn đến gần và tốt hơn theo thời gian.

Tôi nhớ lại câu nói cũ: "bạn không cần phải điên khi làm việc ở đây, nhưng nó giúp".

Câu trả lời ngắn gọn là kinh nghiệm mã hóa thực hành không phải là điều kiện tiên quyết của một PM phần mềm tốt, nhưng nó thường được ưa thích hơn. Điều quan trọng để trở thành một PM có thể là hiểu được quá trình phát triển (bất kỳ phương pháp nào được sử dụng) và tin tưởng rằng các nhà phát triển sẵn sàng và có thể thực hiện công việc của họ. Kinh nghiệm phát triển cung cấp kiến ​​thức thực hành về quá trình đó, do đó nó giúp ích. Các PM làm việc theo cách của họ trong công ty cũng biết về văn hóa công ty (và codebase) và có mối quan hệ với các thành viên phục vụ lâu dài khác của nhóm nhà phát triển, đó là lý do tại sao IMO các PM tốt nhất được thăng chức từ bên trong được đưa vào từ bên ngoài. Nếu ai đó bên ngoài công ty có thể quản lý nhóm tốt hơn ai đó từ bên trong có thể, mọi thứ RẤT sai.

Một điều tôi đã đề cập là mối quan hệ giữa nhóm PM và nhà phát triển. Đây là cả ở cấp độ cá nhân và kỹ thuật. Chìa khóa ở đây là giao tiếp; các nhà phát triển phải cảm thấy họ có thể mang lại các vấn đề, cả về kỹ thuật và liên cá nhân, cho Thủ tướng và Thủ tướng phải hiểu các thành viên nhóm phát triển khi họ mô tả một vấn đề.

Về bản chất cụ thể của câu hỏi của bạn, một ước tính chính xác là như vậy; một phỏng đoán có giáo dục về một đại lượng (trái ngược với một giả thuyết, đó là một dự đoán tổng quát hơn về kết quả của một sự kiện trong tương lai). Người quản lý thường sẽ áp dụng toán học hoặc trực giác một số công cụ sửa đổi, dựa trên các ước tính gần đây của bạn so với các mốc thời gian thực tế. Agile xây dựng điều này vào quá trình ước tính; khách hàng ước tính trực quan sự phức tạp của các yêu cầu, sau đó các nhà phát triển cũng làm như vậy và sau đó các nhà phát triển thực sự đi ra ngoài và phát triển giải pháp, đưa ra các điểm dữ liệu của người quản lý để tính tỷ lệ các điểm yêu cầu cho điểm dev và điểm dev cho con người yêu cầu của chúng tôi.

Nói tóm lại, người quản lý sẽ chỉ lấy ước tính của bạn theo mệnh giá theo một trong ba trường hợp sau:

• Bạn đã khá chính xác với ước tính của bạn về các nhiệm vụ tương tự trong quá khứ.
• Anh ấy chịu áp lực giao hàng, và ước tính của bạn tốt hơn anh ấy nghĩ.
• Anh ta đang tìm kiếm một lý do để sa thải bạn.

Nếu đó là tình huống cuối cùng, sẽ có nhiều manh mối khác xung quanh nơi làm việc mà có lẽ bạn nên thoát khỏi địa ngục.

Tôi không có ý tưởng nhưng người quản lý của tôi cần một số kiến ​​thức kỹ thuật. Đôi khi không thể giải thích anh ta.