Làm thế nào để tôi thành công như một nhà phát triển chính? [tạm dừng]

Tôi đã trở thành nhà phát triển chính trong một dự án cụ thể, nhưng tôi gặp khó khăn trong việc tập trung vào bức tranh lớn và đảm bảo tất cả các phần của dự án đều được bảo hiểm.

Tôi nên lưu ý gì khi quản lý dự án này? Làm thế nào tôi có thể đảm bảo mọi thứ được xử lý theo cách nó nên?

Tôi đã thấy chuyến đi này lên các nhà phát triển khác khi họ thực hiện chuyển đổi sang cấp cao hoặc lãnh đạo. Dưới đây là một vài gợi ý tôi đã đưa ra cho người khác.

• Hiểu mục tiêu của dự án là gì.

Thường thì đó không phải là về tất cả các tính năng đã được đẩy vào dự án. Đó là về một bộ chức năng cốt lõi đang giải quyết nhu cầu kinh doanh. Luôn ghi nhớ điều này vì đó là mục tiêu chính của bạn.

• Phân tích những gì cần hoàn thành trong nhiệm vụ. Hiểu được sự phụ thuộc giữa chúng.

Phá vỡ một dự án nên khá đơn giản. Phá vỡ nó càng sớm trong dự án càng tốt. Nếu bạn phải phủ bóng lên các bộ phận, hãy hiểu rằng chúng có rủi ro cho đến khi bạn hiểu những gì phải làm.

• Hiểu những câu hỏi mở hoặc sự mơ hồ của dự án là gì.

Bạn sẽ không thể giải quyết tất cả sự mơ hồ ban đầu (mặc dù bạn nên thử). Hãy chắc chắn rằng người quản lý của bạn và các bên liên quan của dự án hiểu họ là gì và những rủi ro mà họ gây ra cho dự án.

• Kinh doanh ghét bất ngờ.

Hãy chắc chắn rằng mọi người đều biết (lý tưởng nhất là hàng ngày, nhưng hoạt động hàng tuần) tình trạng của dự án là gì. Và theo trạng thái tôi có nghĩa là những gì đã được thực hiện, những gì còn lại để làm, câu hỏi mở, vấn đề, vv Bất cứ điều gì có thể ảnh hưởng đến việc hoàn thành dự án nên được báo cáo.

• Mỗi ngày, đi qua bức tranh lớn.

Bạn nên đi qua bức tranh lớn mỗi ngày trong một giờ. Hãy tự hỏi mình những câu hỏi. Những gì đã được hoàn thành? Còn lại để làm gì? Các câu hỏi mở là gì? Mục tiêu là gì? Bạn sẽ có thể cung cấp cho ai đó một trạng thái chi tiết của dự án bất cứ khi nào họ yêu cầu.

Lời khuyên đầu tiên tôi sẽ dành cho bạn là chấp nhận rằng việc quản lý nhóm quan trọng hơn là thực hiện các nhiệm vụ lập trình của riêng bạn. Điều đó có nghĩa là khi bạn có 3 đàn em cần giúp đỡ, công việc của bạn là giúp bạn không than vãn về việc nó đang đưa bạn ra khỏi sự phát triển. Là một người dẫn đầu, bạn thường trở thành vật cản để tiến bộ nếu bạn quá tập trung vào các nhiệm vụ phát triển của riêng mình trước tiên.

Ngoài ra, bạn cần phải học cách ủy quyền. Thật khó để giao nhiệm vụ cho ai đó khi bạn có thể làm điều đó một cách dễ dàng trong một giờ và bạn biết họ sẽ loay hoay trong một ngày. Tuy nhiên, họ sẽ không bao giờ tiến bộ trừ khi họ nhận được nhiệm vụ và bạn sẽ làm việc thêm giờ trong khi nhóm của bạn đang chơi trò chơi.

Hơn nữa, không bao giờ chỉ sửa mã của người khác. Nói với họ những gì sai (và tại sao) và làm cho họ sửa nó. Hoặc bạn sẽ có một chu kỳ mà bạn phải sửa chữa mọi thứ vì chúng không trở nên tốt hơn. Nếu họ không thể sửa nó, thì hãy cân nhắc xem họ có nên ở lại đội không. Đừng để các thành viên nhóm yếu ở lại vì bạn đang sửa chữa mọi thứ họ làm.

Là người dẫn đầu, bạn trở thành kẻ xấu và cung cấp cho họ những tin tức không dễ chịu (cả lên và xuống chuỗi). Điều đó đi với công việc là tốt. Điều đó có nghĩa là bạn phải thực hiện đánh giá hiệu suất kém; bạn phải nói với họ rằng thời hạn đã được chuyển lên hoặc các yêu cầu đã thay đổi; bạn cần phải thúc đẩy kẻ lười biếng không tiến bộ; và bạn phải nói với cấp trên của bạn khi thời hạn sẽ không được đáp ứng và tại sao và những gì bạn đang làm về nó. Trở thành người dẫn đầu không phải là để được thích, mà là về hiệu quả. Công việc của bạn là đưa phần mềm ra khỏi cửa, không kết bạn. Truyền thông là chìa khóa và tránh những tin tức xấu kết thúc làm cho tình hình tồi tệ hơn. Một khách hàng có nhiều khả năng xử lý việc được thông báo sẽ mất thêm ba tuần một tháng trước khi ra mắt so với khi ngày ra mắt trôi qua và sau đó bạn nói với họ rằng bạn cần thêm ba tuần nữa.

Đây là danh sách kiểm tra không chính thức của tôi. Điều đó rất không chính thức ... Tôi không làm mọi thứ hàng ngày, nhưng nếu tôi không đạt được tất cả những điều này hàng tuần, tôi sẽ hơi lo lắng và nếu tôi không đánh chúng hàng tháng, tôi sẽ hoảng loạn. Và số dặm thay đổi hoàn toàn dựa trên văn hóa công ty / nhóm, phong cách cá nhân và loại dự án.

• Nói chuyện riêng với nhóm - mọi người trong nhóm của bạn - có công việc hữu ích để làm không? biết mục tiêu tổng thể của sản phẩm và phát hành hiện tại là gì? họ có biết bạn kiếm tiền như thế nào và lực đẩy lớn của doanh nghiệp bạn là gì không? họ có biết làm thế nào công việc hiện tại của họ phù hợp với tất cả những điều đó?

• Nói chuyện với nhóm một cách tập thể - tập hợp tất cả chúng cùng với những tin tức quan trọng, tập hợp các nhóm lại với nhau để đảm bảo việc giao tiếp diễn ra với và không có bạn. Là một nhóm nhỏ, đây có lẽ là phiên chiến lược nhóm. Khi nhóm trở nên lớn hơn, nó sẽ trở thành trường hợp bạn phải hướng dẫn họ vượt qua những điểm chính, và chắc chắn sẽ trở thành một bạn nói về kịch bản của họ. Điều đó không sai - có những lúc rất quan trọng rằng mọi người đều nghe bạn nói thông tin công khai với mọi người . Vì vậy, mọi người đều biết rằng bạn đang cung cấp thông tin phổ biến. Nhưng cuộc họp "bạn - với - mọi người" rất khác so với cuộc họp chiến lược nhóm nơi bạn có nhiều hướng dẫn hơn.

• Lấy mẫu công việc của nhóm - cố gắng lấy một chút khảo sát về công việc của mọi người. Đọc mã của họ, chạy các chức năng của họ, thử các trường hợp thử nghiệm của họ. Đừng nhắm vào 100% công việc của mọi người, hãy thử lấy một chút từ mọi người. Cung cấp cho họ thông tin phản hồi, nhưng cũng gửi đi các lĩnh vực điểm mạnh và điểm yếu trong toàn đội.

• Kiểm tra với quản lý của bạn sớm và thường xuyên - đây không phải là màu nâu, đây là vòng lặp. Nếu bạn không biết quản lý của bạn cần gì và quản lý của bạn đang nghĩ gì thì làm sao nhóm của bạn có thể đáp ứng mong đợi? Bạn cần phải có một sự phục hồi thực sự tốt với sếp của bạn và bạn cần phải ở trong đội của anh ấy, cách mọi người ở trong đội của bạn. Khả năng giao tiếp hiệu quả với sếp về những thứ tầm thường làm tăng sự tự tin rằng bạn sẽ có thể nhận được sự giúp đỡ và hiểu rõ khi khủng hoảng xảy ra. Đây cũng là một kiểm tra thực tế tốt cho việc người mù hình ảnh lớn của bạn đang ở đâu.

• Xem xét tài nguyên nhóm theo định kỳ - mọi người sẽ rít lên khi tài nguyên có sẵn trước đó không có sẵn, nhưng xem xét các điểm đau không xác định. Chokepoint của bạn ở đâu? Có công cụ mới nào hữu ích không? Hầu hết các đội đều có một anh chàng mà tôi nghĩ là Thợ săn công cụ, người luôn theo kịp các tiện ích mới nhất và tốt nhất. Cân bằng các cuộc trò chuyện giữa Tool Hunter và GuyWhoHatesEverythingNew để tìm điểm tiếp theo cho sự tiến hóa. Các công cụ bao gồm mọi thứ - SW, CTNH, không gian vật lý, tài nguyên học tập.

• Biết và giữ liên lạc với các nhóm hỗ trợ. Mỗi công ty là khác nhau, nhưng biết những người chịu trách nhiệm kiểm soát chất lượng của bạn, viết tài liệu, pháp lý, cơ sở vật chất, tài chính và bất kỳ nhóm hỗ trợ nào khác duy nhất cho doanh nghiệp của bạn. Chúng là những yếu tố kích hoạt hình ảnh lớn nhất mà tôi có thể nghĩ ra, bởi vì chúng nhìn thế giới hoàn toàn khác với bạn.

• Biết đối thủ của bạn - dành ít nhất một chút thời gian mỗi tuần để tìm hiểu xem ai đó sẽ giải quyết vấn đề mà sản phẩm của bạn giải quyết như thế nào nếu họ không sử dụng sản phẩm của bạn. Nó có thể không phải là một công ty duy nhất, nhưng giải pháp khác đó mang lại điều gì cho bạn?

• Xem lại chi phí và lịch trình- Làm thế nào có khả năng nhóm của bạn có nghĩa là thời hạn hiện tại của họ? Làm thế nào về thời hạn tiếp theo? Tỷ lệ đốt chi phí của bạn là gì? Những khoản mua lớn sắp tới mà bạn chưa trả tiền chưa? Những gì còn lại của ngân sách của bạn? Các chi tiết khác nhau tùy theo cách bạn thực hiện theo dõi tài chính, nhưng ngay cả trong một công ty rất không chính thức, bạn nên có một số ý tưởng về cả hai ngày / tuần / tháng ngân sách bạn còn lại và thời hạn của bạn là gì đối với sản phẩm hiện tại. Ở đâu đó, bằng cách nào đó, một người nào đó tốt hơn nên lên kế hoạch "chúng ta cần bao nhiêu người để làm công việc này?" và "chúng tôi có thể đủ khả năng trả cho họ vào tháng tới / quý / năm không?". Bạn cần biết những con số đó và có đầu vào ở các bước tiếp theo. Bạn cần một kế hoạch rõ ràng cho tuần tới mà bạn có thể giải thích ngay bây giờ nếu có ai đó bước vào và hỏi. Bạn cần một kế hoạch khá tốt cho tháng tới, Điều đó sẽ chỉ thay đổi ở 2-3 nơi khi thực tế đạt được. Bạn cần một kế hoạch sơ sài cho quý và một vị tướng đứng đầu trong năm của bạn. Trước đó, ngay cả trong dự án lớn, những con số chỉ là những con số. Nghe họ nói, nhưng nhận ra rằng không ai đăng nhập bằng máu.

Đó là đầu của tôi ra khỏi danh sách đầu của tôi. Tôi thường thêm vào đó khi tôi bị "đập đầu" một cách bất ngờ (hình ảnh tôi rất nhạy cảm với một khu vực tôi đã bỏ lỡ và sau đó tôi xoay được nó vào danh sách kiểm tra. ).

Ngoài ra - hãy chuẩn bị cho Chuyển đổi bối cảnh Dread. Nếu bạn chỉ mới bắt đầu quản lý, có khả năng bạn có một nhóm nhỏ và ai đó quản lý nghĩ rằng bạn sẽ dành thời gian để quản lý nhóm và dành thời gian để làm công việc đóng góp cá nhân. Điều này có thể được thực hiện, nhưng chuyển đổi bối cảnh giữa hai là thô. Lập kế hoạch cho nó. Chặn thời gian để chuyển đổi (như trước và sau bữa ăn trưa) và biết bộ kỹ năng ít luyện tập của bạn và nhận ra rằng bạn sẽ cần phải kéo mình đến đó vài lần đầu tiên - vì vậy hãy đặt thời gian để làm một cái gì đó "liên quan đến bức tranh lớn" và hình dung rằng bạn sẽ cần ít nhất hai giờ để thực sự đến bất cứ nơi nào.

Công tắc ngữ cảnh hoạt động theo cả hai hướng - quản lý để bắt tay vào công việc và ngược lại. Nhưng khi bạn đi từ điểm mạnh và luyện tập đến nơi khó chịu và ít luyện tập hơn thì bạn cảm thấy đau nhiều hơn và động lực để rút lui là mạnh mẽ. Biết nó ở đó và chiến đấu với nó và nhận ra rằng đập xung quanh trong bức tranh lớn giúp bạn tốt hơn trong việc lấy tất cả. Hãy cho mình thời gian để đập.

Đọc cuốn sách này: Mèo chăn gia súc: Một mồi cho lập trình viên dẫn dắt lập trình viên

Thời gian trước tôi đã tặng cuốn sách này cho sếp của tôi và anh ấy thích nó. Khi tôi đang đọc nó, dường như anh ấy biết anh ấy đang nói về cái gì. Và đây là như vậy. Tác giả kể về trải nghiệm của chính mình. Không phải là một bộ sưu tập "sự thật đơn giản" của người quản lý - đây là những lời của cựu lập trình viên. Và nên hiểu rằng đó là kinh nghiệm của mình, nhưng bạn có thể khác. Vì vậy, trên một số điều bạn nên xem xét nghiêm túc. "Người quản lý không còn có thể là một lập trình viên - đó là điều quan trọng".

Khi tôi tiếp quản sự lãnh đạo kỹ thuật của một công ty nhỏ gần đây về một sản phẩm mà tôi không phát triển, điều tôi thấy rất hữu ích trong việc quản lý mọi thứ là ghi lại bằng tiếng Anh các hoạt động của sản phẩm mà các tính năng của tôi ghi lại bằng dưa chuột và cho các bên trong Tôi đã viết lên các giải thích về mô hình đối tượng và lưu chuyển qua các bộ điều khiển khác nhau. Điều tôi tìm thấy khi làm điều đó là A) sản phẩm có một chút lộn xộn :) Và B) Tôi đã học được nhanh hơn nhiều cách ứng dụng hoạt động, vì vậy tôi có thể có một cuộc trò chuyện thông minh về những vấn đề đang xảy ra và những gì cần tái cấu trúc, hoặc những gì nó cần để thực hiện một tính năng nhất định.

Hình ảnh cũng giúp ích cho tôi. Tôi không làm phiền với các sản phẩm như Visio, tôi chỉ sử dụng bút màu và giấy trắng