Làm thế nào để bắt đầu có được kinh nghiệm quản lý dự án [đã đóng]

Có một số yêu cầu công việc về kinh nghiệm quản lý dự án cho một lập trình viên, chẳng hạn như:

ứng viên phải có một số kinh nghiệm quản lý một dự án, không nhất thiết phải với cấp dưới, mà là đã làm việc trong một dự án suốt từ thiết kế đến thử nghiệm.

Tôi đã tự hỏi

1. "cấp dưới" nghĩa là gì ở đây?
2. nếu có một số sách, trang web hoặc nơi khác có cả hướng dẫn chung và các dự án mẫu thực tế đơn giản để giúp người ta có được một số điều cơ bản về toàn bộ quá trình của một dự án. Tôi đặc biệt quan tâm đến các dự án cho cả Linux và Windows, trong C, C ++, Python, Java. Tôi đang cân nhắc để bắt đầu bằng cách tự chơi, không muốn tìm một công ty nào.

Chuyên ngành của tôi không phải là CS, vì vậy tôi có thể thiếu những điều cơ bản.

Yêu cầu công việc về cơ bản muốn khách hàng tiềm năng có kinh nghiệm với một dự án mà bạn phụ trách, trong đó bạn có thể có hoặc không có người theo sự dẫn dắt của bạn. Nếu bạn có loại kinh nghiệm đó và bạn dự định đề cập đến nó, hãy chắc chắn rằng bạn đã thành công với nó.

Nếu bạn không có kinh nghiệm về PM, thì điều tốt nhất nên làm là chủ động và tìm kiếm một dự án trong công việc hiện tại của bạn . Nếu vì một lý do nào đó, bạn không thể có được một dự án trong vành đai của mình, thì hãy bắt đầu một dự án nguồn mở và cố gắng đưa mọi người lên tàu . Ngay cả khi bạn là một nhà phát triển solo, bạn sẽ học được rất nhiều điều về quản lý dự án phần mềm. Tôi đã bắt đầu dự án nguồn mở của mình và tôi đang học các kỹ thuật quản lý dự án (PM). Tôi thậm chí còn tự học và đánh giá mình là nhà phát triển đang làm việc bởi vì tôi là cả người quản lý và nhà phát triển của tôi, vì vậy phía người quản lý của tôi đặt nhiệm vụ và ước tính và phía nhà phát triển của tôi cam kết thực hiện các nhiệm vụ đó. Bây giờ trong công việc, chúng tôi đang bắt đầu một dự án và bây giờ tôi cảm thấy tự tin hơn để cam kết cho một yêu cầu cụ thể và cách ước tính giao hàng của họ.

Về kỹ thuật cho phần mềm nguồn mở PM:

1. Khám phá các tính năng .... đôi khi ngay cả khách hàng cũng không biết anh ấy thực sự muốn gì.

2. Dịch các tính năng thành các yêu cầu.

3. Dự toán yêu cầu.

4. Ưu tiên các yêu cầu và chọn những yêu cầu phù hợp trong một lần lặp. (Những yêu cầu cơ bản nhất có thể phù hợp trong một lần lặp là gì?)]

5. Đặt cột mốc và lặp lại.

6. Chia tay vấn đề. (phân tích tên miền)

7. Thiết kế sớm (thiết kế vừa đủ tốt).

8. phát triển (thử nghiệm, thực hiện, v.v.)

9. Vào cuối vòng lặp, hãy phân tích hiệu suất và phản hồi của bạn. Tôi đã cung cấp những gì tôi hứa? Có chuyện gì? Những gì tôi đã làm đúng?

Cũng tìm hiểu làm thế nào để phạm vi với THAY ĐỔI . Nghiêm túc mà nói, ở giữa vòng lặp của bạn, bạn hoặc khách hàng của bạn sẽ phát hiện ra rằng có một tính năng rất quan trọng là nếu bạn không làm điều đó, dự án đã chết. Nhiều khả năng, hằng số duy nhất của bạn trong dự án của bạn là thay đổi!

Cấp dưới là những người báo cáo cho bạn (tức là nếu bạn là người quản lý). Về cơ bản, nó nói rằng bạn không nhất thiết phải có người quản lý, nhưng cần phải chịu trách nhiệm cho tất cả các khía cạnh của dự án từ đầu đến cuối.

Thật không may, tôi không biết bất kỳ tài nguyên nào về nó; có lẽ ai đó khác có thể giúp với phần câu hỏi của bạn.

Quản lý dự án là nghệ thuật hơn khoa học. Sách không giúp được gì nhiều. Kinh nghiệm về cơ bản là những gì được yêu cầu.

Để có được kinh nghiệm, bạn chỉ cần tham gia vào một số dự án với các nhà quản lý dự án tốt và xấu. Đó là cách bạn học loại nghệ thuật này: xem người khác.

Mặc dù rất nhiều trường đại học cố gắng, có rất nhiều về quản lý dự án CNTT không thể dạy; nó phải được trải nghiệm, sau đó học bằng cách thử và sai. Nếu bạn chưa bao giờ ngồi xuống với anh chàng sẽ trả hóa đơn của bạn để phát triển một phần mềm, thì hãy ngồi lại với những người dùng cuối tương lai của phần mềm của bạn để xác định xem nó cần gì và hoạt động như thế nào, và cân bằng hai bộ yêu cầu thường độc quyền này để đưa phần mềm từ những suy nghĩ ban đầu đến một sản phẩm hoàn chỉnh trong tay người dùng mục tiêu của bạn, bạn chưa "quản lý" một dự án và mặc dù bạn có thể được đưa ra các chiến lược chung, v.v. không tốt nếu bạn bị rơi vào tình huống như vậy chìm hoặc bơi.

Quản lý dự án phần mềm liên quan đến tất cả năm lĩnh vực của SLDC cổ điển; phân tích, thiết kế, phát triển, thực hiện và bảo trì. Nó cũng đòi hỏi phải xử lý ba lĩnh vực chính của các bên liên quan - lao động, quản lý và ngân sách - trên cả hai mặt của dự án (những người muốn sản phẩm và những người tạo ra nó). Nó thường được học thông qua kinh nghiệm nhiều hơn là thông qua việc đọc, ngoài ra có một số lượng tốt các cuốn sách có thể giúp đỡ.

Có vẻ như các yêu cầu công việc bạn đang tìm kiếm chỉ đơn giản là tìm kiếm một người có vai trò cao cấp trong một dự án. Không có cấp dưới có nghĩa là họ không tìm kiếm bạn để quản lý mọi người (cung cấp đánh giá hiệu suất, thuê / chữa cháy, v.v.)

Làm việc tất cả các cách từ thiết kế đến kiểm tra thực sự là một phạm vi khá hẹp. Điều này không bao gồm những thứ như đưa ra một dự án cho Sr. Management, làm việc với khách hàng theo yêu cầu, làm việc với tiếp thị và bán hàng và toàn bộ giai đoạn phát hành và hỗ trợ của các dự án.

Tôi sẽ nhận được Phát triển nhanh vì nó được tổ chức tốt xung quanh mọi giai đoạn của dự án, chủ yếu theo quan điểm của Nhà phát triển SW. Nó có thể là một chút ngày, nhưng nó làm tốt công việc cung cấp đủ tài liệu khởi đầu để đưa bạn đi. Từ đó, ngay cả khi bạn chưa muốn "tìm một công ty", bạn vẫn nên tìm một nhóm người để nói chuyện thông qua các vấn đề có nhiều kinh nghiệm hơn bạn. Học hỏi từ những người đã trải qua quá trình dường như luôn là giáo viên nhanh nhất / hiệu quả nhất. (đừng hiểu sai ý tôi, tôi cũng giới thiệu sách, nhưng nếu bạn mới bắt đầu, bạn sẽ thấy hữu ích khi có ai đó giúp xây dựng bối cảnh với bạn khi bạn xử lý thông tin trong sách)

chúc may mắn!