Chào bạn! Tôi nghĩ rằng mọi nhà phát triển chuyển sang vai trò trưởng nhóm ban đầu đều cố gắng quay lại viết mã và giải quyết các nhiệm vụ cùng với nhóm. Sau đó, chúng tôi bắt đầu đề cập đến nhiều nhiệm vụ và vấn đề kinh doanh hơn, đi sâu vào các thách thức liên quan đến kinh doanh, giao tiếp giữa các bộ phận hoặc khách hàng và kiến trúc. Từ thời điểm này trở đi, chúng ta không còn thời gian hay mong muốn làm việc khác nữa. Lịch của một trưởng nhóm điển hình bắt đầu giống như thế này: Làm cách nào để tôi quay lại quá trình phát triển và bắt đầu viết mã lại? Tôi nên bắt đầu từ đâu? Điều quan trọng nữa là phải đánh giá mức độ bận rộn thực sự của bạn và ngày làm việc điển hình của bạn diễn ra như thế nào. Bạn có tham gia vào việc hoàn thiện bản thân sau giờ làm việc hay không? Đây đều là những yếu tố quan trọng. Dựa trên kinh nghiệm của mình, tôi khuyên bạn nên thực hiện các bước theo lộ trình từ “không có thời gian trước hoặc sau giờ làm việc, không có ham muốn hay cơ hội” đến “Tôi luôn ngồi trước máy tính và đây là niềm đam mê của tôi”. Chặn thời gian của bạn! Điểm khởi đầu hiệu quả là sắp xếp thời gian dành riêng cho việc phát triển. Đơn giản chỉ cần dành 'thời gian viết mã' trong lịch của bạn trong một giờ hoặc hơn. Nếu có thể, hãy cân nhắc dành nửa ngày hoặc cả ngày mỗi tuần để giải quyết các nhiệm vụ kỹ thuật. Đúng, nó có thể liên quan đến việc di chuyển các cuộc họp xung quanh, loại bỏ những cuộc họp không cần thiết hoặc thảo luận về sự cần thiết của việc tham dự một số cuộc họp. Tuy nhiên, hãy cân nhắc việc đánh giá lại liệu một số buổi chải chuốt nhất định có còn phù hợp với bạn hay không. Có lẽ bạn đang dành một giờ ở đó mà không có nhiều tác động? Chuyển hướng thời gian đó sang mã hóa! Đánh giá mã với nhóm của bạn! Khía cạnh thứ hai và quan trọng nhất để tối ưu hóa các quy trình nhất định xung quanh bạn là truyền đạt các giá trị hoặc cách tiếp cận của dự án tới đồng nghiệp của bạn. Không phải mọi nhà phát triển đều có cách tiếp cận giống nhau để giải quyết vấn đề, do đó, điều cần thiết là phải xác định trước các kiểu mã hóa, phạm vi kiểm tra cũng như các phương pháp và cơ chế cơ bản của nền tảng hoặc dịch vụ một cách riêng biệt. Luôn tiến hành đánh giá mã và nếu có cảm giác rằng câu hỏi đang kéo dài, hãy tập hợp nhóm để nhanh chóng giải quyết các vấn đề trong yêu cầu kéo (PR). Như thực tế cho thấy, cách tiếp cận này tăng tốc thời gian giải quyết vấn đề, do đó cải thiện thời gian tiếp thị các tính năng. Theo thời gian, nhóm của bạn sẽ hiểu đầy đủ và áp dụng các phương pháp phát triển đòi hỏi ít sự chú ý hơn. Bạn sẽ chỉ tập trung vào việc giải quyết nhiệm vụ hiện tại và logic của nó, điều này sẽ tiết kiệm được vài phút ban đầu và về lâu dài có thể mất hàng giờ phát triển. Trách nhiệm của bạn là gì? Đây có thể không phải là nhiệm vụ rõ ràng nhất, nhưng hãy tự hỏi bản thân, bạn chịu trách nhiệm về việc gì? Bạn cần làm gì? Hãy viết ra tất cả những điểm này trên một tờ giấy và xem liệu bạn có bỏ sót điều gì không cần thiết hay không. Có lẽ bạn đang làm công việc của người khác chỉ vì nó đã trở thành thói quen. Có thể bạn đang giúp đỡ nhóm lân cận trong các quy trình của họ và bạn vẫn tham gia. Xác định rõ ràng vị trí của bạn và những gì bạn đóng góp cho dự án hoặc công ty. Nếu bạn lãnh đạo một nhóm lớn, hãy sử dụng các ghi chú để bạn có thể tạo một hàng nhiệm vụ và vấn đề. Luôn tiến hành đánh giá và đảm bảo rằng nếu bạn là trưởng nhóm DevOps chẳng hạn, bạn sẽ không vô tình xử lý các nhiệm vụ dành cho nhà phát triển ứng dụng di động. Nếu bạn thấy mình quá tải với các nhiệm vụ và sự phụ thuộc, bạn nên dừng lại để nói chuyện với cấp trên và tìm hiểu lý do tại sao điều này lại xảy ra trong bộ phận của bạn. Ví dụ: nếu bạn là nhóm DevOps chịu trách nhiệm về Kỹ sư dữ liệu và họ có người lãnh đạo riêng, thì việc giao lại trách nhiệm cho người lãnh đạo của họ thay vì bộ phận của bạn là điều hợp lý. Tạo các thông số kỹ thuật và tài liệu cần thiết để chính thức hóa các thỏa thuận hoặc bất kỳ chi tiết ẩn nào về thiết lập hoặc bảo trì và đưa mọi người trở lại nhóm tương ứng của họ. Điều quan trọng cần lưu ý rằng đây chỉ là một ví dụ và mọi người đều có đội và nguyên tắc hình thành của riêng mình. Ưu tiên và ủy quyền Có thể bạn không hoàn thành được công việc vì các ưu tiên liên tục thay đổi. Toàn bộ công ty hoạt động theo các đợt chạy nước rút kéo dài hai tuần, nhưng cách thiết lập này không còn phù hợp với bạn nữa và bạn không thấy giá trị của nó. Các tính năng không hoàn thành trong vòng chạy nước rút do mức độ ưu tiên yếu. Điều này phù hợp với các nhóm định hướng dịch vụ. Hãy cân nhắc khám phá Kanban hoặc phương pháp tiếp cận dòng nước. Các nhóm của chúng tôi giống như những hòn đảo riêng biệt, nơi chúng tôi có quyền thử thay đổi các quy trình để tốt hơn. Hãy thử nghiệm việc chuyển sang phương pháp mới trong một tháng và quan sát các chỉ số của bạn. Theo kinh nghiệm của tôi, một vài tuần là đủ để nhận thấy rằng Scrum không phù hợp với chúng tôi và chúng tôi đã chuyển sang Kanban. Thời gian tiếp thị của chúng tôi giảm đáng kể vì giờ đây các ưu tiên có thể thay đổi hai lần một tuần, cho phép chúng tôi giải quyết các vấn đề kịp thời hơn. Tiếp theo, hãy thử chia nhóm thành các khu vực nhưng không quá chi tiết. Đắm chìm từng thành viên trong nhóm theo quy tắc 70/30: 70% dành riêng cho nhóm, dự án hoặc sản phẩm chính của họ 30% cho mọi thứ khác Nếu nhóm của bạn có nhiều hơn 5 người, bạn sẽ đảm nhiệm tất cả các dịch vụ và chức năng, cho phép các cá nhân đi sâu vào lĩnh vực chủ đề nhanh hơn. Điều này đạt được điều gì? Nó cho phép bạn giao một số nhiệm vụ cho nhóm thay vì tự mình làm mọi việc nếu bạn thấy rằng nhà phát triển đã có hiểu biết và sự sâu sắc. Bạn không cần phải mô tả toàn bộ thuật toán và tích hợp! Họ đã biết hết rồi! Quản lý thời gian và năng suất Nhóm lập kế hoạch thời gian làm việc như thế nào? Hãy bắt đầu với một điều đơn giản: bạn hoạt động như một nhóm như thế nào? Hãy xem các ước tính của bạn và cách bạn đánh giá các nhiệm vụ. Mọi thứ có ổn không? Có lẽ cần cải thiện hoặc đưa ra hệ số khối lượng công việc? Hệ số khối lượng công việc giúp hiểu được công việc của từng thành viên trong nhóm trong một lần chạy nước rút hoặc một tuần, xem xét những yếu tố gây xao lãng có thể xảy ra để được hỗ trợ. Ví dụ: nếu bạn là nhóm dịch vụ cần bảo trì sản phẩm của riêng mình, các nhóm khác có thể tìm kiếm sự trợ giúp của bạn hoặc yêu cầu cải tiến, dẫn đến mất thời gian liên lạc trong vòng chạy nước rút. Điều tương tự cũng xảy ra với việc xử lý lỗi; bạn có thể thường xuyên bị phân tâm để giải quyết các vấn đề khẩn cấp trong môi trường sản xuất. Nhưng đó là một chủ đề riêng biệt và tôi khuyên bạn nên xem lại bài viết trước đây của mình về cách thực hiện những cải tiến dần dần trong lĩnh vực này. https://hackernoon.com/just-go-ahead-and-test-your-project-part-1?embedable=true Bây giờ, quay lại hệ số. Nếu chúng tôi thừa nhận rằng mỗi người trong chúng tôi được mời tham gia một cuộc trò chuyện hoặc cuộc họp ít nhất 1 trong 5 ngày để giải quyết vấn đề, hãy cân nhắc điều đó khi lập kế hoạch. Bằng cách này, bạn sẽ quản lý một cách thực tế để hoàn thành các nhiệm vụ thực sự mang lại lợi ích cho nhóm, có khả năng giải phóng thời gian để viết mã. Hãy thử kỹ thuật Pomodoro. Không có gì đột phá; chỉ cần sử dụng một ứng dụng trên điện thoại cho phép bạn tập trung vào một nhiệm vụ trong một khoảng thời gian nhất định, chẳng hạn như 45 phút. Không có gì đặc biệt, tôi đoán vậy. Sử dụng trình theo dõi. Tiến hành điều tra xem bạn dành 8 giờ làm việc vào việc gì - ghi lại từng giờ và phút hoạt động của bạn trong tuần hoặc tháng. Bạn có thể phát hiện ra những yếu tố khiến bạn mất tập trung hoặc bạn có thể nhận thấy rằng đi bộ 15 phút sau bữa trưa giúp bạn làm việc hiệu quả hơn — có lẽ đó là chìa khóa thành công? Hoặc, nếu bạn có ba cuộc họp liên tiếp, bạn có thấy mình không làm gì trong một giờ sau đó mà chỉ đọc các thông số kỹ thuật không? Có lẽ đó là thử thách đối với bạn? Vấn đề là hãy xem xét kỹ lưỡng những gì bạn đang làm và tôi tin rằng bạn sẽ xác định được những lĩnh vực cần cải thiện. Tham gia vào các dự án đầy thách thức về mặt kỹ thuật Nếu bạn thấy mình không thể tham dự các cuộc họp dành riêng cho các giải pháp kiến trúc hoặc thiết kế hệ thống, hãy đọc phần tiếp theo hoặc tài liệu. Cố gắng hiểu làm thế nào và những gì giải quyết vấn đề. Tốt nhất là bạn không nên bỏ lỡ những cuộc họp như vậy và cố gắng đắm mình vào khía cạnh kỹ thuật càng nhiều càng tốt. Chọn các dự án hoặc khía cạnh dự án yêu cầu tìm hiểu sâu về mã. Điều này sẽ giúp bạn theo kịp các công nghệ và phương pháp phát triển mới. RnD dành cho bạn Nếu bạn nhận thấy các khu vực trong dự án có vấn đề hoặc cần cải thiện chức năng, hãy thoải mái tạo nguyên mẫu. Điều này không chỉ cho phép bạn hình dung những thay đổi được đề xuất mà còn cung cấp cho nhóm tài liệu hữu hình để thảo luận và ra quyết định. Mục tiêu chính không chỉ là giới thiệu các ý tưởng mà còn là triển khai chúng vào dự án nếu chúng thực sự có ý nghĩa hoặc mang lại lợi ích. Ví dụ: nếu bạn luôn mơ ước chuyển các dịch vụ lỗi thời từ Java 1.8 sang phiên bản 21, tại sao bạn không thử? Tạo một nguyên mẫu, đưa nó cho nhóm xem, phát triển giải pháp của bạn và ghi lại toàn bộ quá trình để tham khảo trong tương lai. Cách tiếp cận này không chỉ giúp thực hiện các cải tiến kỹ thuật mà còn tạo ra sự hiểu biết chung trong nhóm về những thay đổi tiềm năng. Do đó, bạn có thể đóng góp mang tính xây dựng cho dự án, đảm bảo sự phát triển hiệu quả và thúc đẩy sự đổi mới. Điểm đánh giá! , bạn sẽ có vài giờ để viết mã, đề xuất giải pháp và sau đó bạn có thể nghỉ ngơi. Tất nhiên, vị trí lãnh đạo đơn giản là không cho phép bạn làm cả hai việc và nếu trọng tâm của bạn vẫn là phát triển thì bạn có thể cân nhắc việc quay trở lại. Ở giai đoạn này Điều đó không có gì sai cả - nhận ra rằng công việc quản lý đang trở nên buồn tẻ đối với bạn, ngay cả khi bạn xuất sắc trong lĩnh vực đó, cũng không sao cả. Chỉ là vào thời điểm này, nó đã mất đi sức hấp dẫn đối với bạn. Nếu bạn vẫn còn thời gian rảnh Học tập và phát triển bản thân Liên tục trau dồi kiến thức bản thân bằng cách đọc tài liệu kỹ thuật, khám phá các khóa học đào tạo và tham gia các hội nghị kỹ thuật. Điều này sẽ giúp bạn theo kịp các xu hướng mới nhất và các phương pháp hay nhất trong phát triển phần mềm. Đọc tài liệu kỹ thuật mang đến cơ hội duy nhất để nghiên cứu sâu về công nghệ, phương pháp và phương pháp hay nhất mới. Điều này có thể bao gồm sách, bài viết, blog và các tài liệu khác đề cập đến các khía cạnh khác nhau của phát triển phần mềm. Tham gia các khóa học giáo dục là một cách có hệ thống và có cấu trúc để tiếp thu kiến thức về các chủ đề và công nghệ mới. Nền tảng khóa học trực tuyến cung cấp nhiều khóa học về các ngôn ngữ, khung và khái niệm lập trình khác nhau. Việc tham gia các hội nghị kỹ thuật không chỉ mở ra cơ hội tìm hiểu về các xu hướng và cải tiến mới nhất mà còn có cơ hội giao lưu với các chuyên gia trong ngành. Hội nghị cung cấp nền tảng để chia sẻ kinh nghiệm, thảo luận các vấn đề đầy thách thức và xây dựng kết nối trong cộng đồng kỹ thuật. Tóm lại, việc học hỏi liên tục thông qua việc đọc, tham gia các khóa học và tham dự hội nghị cho phép các nhà phát triển phần mềm không chỉ theo kịp các xu hướng mới nhất mà còn tích cực tích hợp kiến thức và kỹ năng mới vào công việc hàng ngày của họ. Ví dụ: leetcode, Udemy hoặc Youtube (đôi khi, chúng tôi có thể tìm thấy nội dung MIỄN PHÍ thực sự tốt ở đó!). Làm việc trên các dự án cá nhân Nếu có thể, hãy thực hiện các dự án cá nhân vào thời gian rảnh. Điều này không chỉ nâng cao kỹ năng lập trình của bạn mà còn là nguồn ý tưởng mới cho công việc chính của bạn. Ngoài ra, việc kết hợp hoạt động này với điểm RnD trong bài viết có thể là một động lực bổ sung cho sự sáng tạo và đổi mới. Làm việc trong các dự án cá nhân cho phép bạn áp dụng các kỹ năng của mình vào các tình huống thực tế, thử nghiệm các công nghệ mới và giải quyết các vấn đề trong thế giới thực. Các dự án này có thể liên quan đến việc phát triển các ứng dụng web của riêng bạn, tạo các dự án nguồn mở hoặc tham gia vào các dự án phụ thú vị. Việc tích hợp hoạt động này với công việc nghiên cứu và phát triển (RnD) đã đề cập trước đó cho phép bạn tạo nguyên mẫu và trưng bày chúng tại nơi làm việc của mình. Việc công khai dự án của bạn, chẳng hạn như tham gia phát triển nguồn mở, không chỉ cải thiện kỹ năng của bạn mà còn góp phần xây dựng các kết nối nghề nghiệp có giá trị và được công nhận cho khả năng sáng tạo của bạn. Tuy nhiên, điều quan trọng cần nhớ là việc tuân thủ chính sách bảo mật (NDA) trong công việc chính của bạn là ưu tiên hàng đầu. Trước khi bắt tay vào các dự án cá nhân, bạn nên tham khảo ý kiến của các chuyên gia pháp lý và ban quản lý để đảm bảo rằng quá trình sáng tạo của bạn không vi phạm các quy tắc đã được thiết lập và tạo điều kiện cho năng lượng sáng tạo của bạn được phát triển tự do trong khi vẫn bảo mật dữ liệu nhạy cảm. Phần kết luận Tìm thời gian để viết mã với tư cách là trưởng nhóm đòi hỏi nỗ lực có ý thức và quản lý ưu tiên hiệu quả. Hãy nhớ rằng vai trò của bạn không chỉ liên quan đến việc trực tiếp lãnh đạo nhóm mà còn phải duy trì các kỹ năng kỹ thuật của bạn ở mức thỏa đáng. Đây sẽ là một thử thách và tôi chúc bạn gặp nhiều may mắn! Tôi đã nhìn thấy vấn đề từ lâu rồi. Nếu bạn muốn đọc sách chuyên ngành, tôi khuyên bạn nên đọc sách: và link link
