Những kỹ năng nào sẽ giúp bạn trở thành một Trưởng nhóm phát triển giỏi?

Xin chào. Tên tôi là Aleksandr Guzenko, tôi là trưởng nhóm của ba nhóm phát triển front-end trong một công ty lớn. Gần đây, một nhân viên đến gặp tôi và nói: “Tôi muốn phát triển thành lãnh đạo nhóm. Tôi phải bắt đầu từ đâu?" Đây là lý do nảy sinh ý tưởng cho bài viết này và tôi đã hứa sẽ gửi cho anh ấy sau này để hướng dẫn.

Trong bài viết này, tôi sẽ cho bạn biết tôi đã trở thành trưởng nhóm như thế nào, những kỹ năng nào bạn không thể làm nếu không có ở vị trí này và cách cải thiện kỹ năng quản lý nhóm của bạn nếu bạn là một nhà phát triển “bình thường”.

Ai là trưởng nhóm và anh ta chịu trách nhiệm gì?

Hãy bắt đầu với lý thuyết, nếu không có lý thuyết này sẽ khó hiểu tại sao bạn lại quản lý việc phát triển mà thay vào đó lại tính ngân sách dự án.

Theo nghĩa cổ điển, trưởng nhóm là người đứng đầu nhóm phát triển. Điều này đúng nhưng có một số hạn chế.

Trong bối cảnh ngày nay, trưởng nhóm không chỉ dừng lại ở các lập trình viên mà còn bao gồm các nhà thiết kế, nhà phân tích, người kiểm tra, chuyên gia SEO và nhiều chuyên gia CNTT cũng như không chuyên về CNTT. Do đó, sẽ chính xác hơn khi định nghĩa trưởng nhóm là người đứng đầu một nhóm nhân viên có cùng vai trò, mặc dù tôi sẽ tập trung cụ thể vào các nhà phát triển.

Thứ hai, trưởng nhóm không chỉ là người lãnh đạo nhóm mà còn là cầu nối chính giữa nhân viên và quản lý. Đây là một bổ sung quan trọng và tôi sẽ cố gắng giải thích lý do bên dưới.

Thứ ba, để hiểu trưởng nhóm chịu trách nhiệm gì, điều quan trọng là phải phân biệt giữa vai trò và vị trí.

Vai trò của trưởng nhóm chủ yếu bao gồm các nhiệm vụ quản lý:

• truyền đạt quan điểm của ban quản lý về các vấn đề quan trọng;
• thực hiện những thay đổi về tổ chức;
• phân công nhiệm vụ giữa các nhân viên và giám sát việc thực hiện;
• trả lời các câu hỏi hiện tại của nhóm;
• Giải quyết tranh chấp;
• tạo bầu không khí thoải mái trong đội;
• xem xét đặc điểm của từng thành viên trong nhóm;

Ở dạng thuần túy, vai trò này hiếm khi được tìm thấy, ngay cả khi danh sách trách nhiệm trên trang tuyển dụng có nội dung khác.

Vị trí trưởng nhóm có thể kết hợp nhiều vai trò cùng một lúc: trưởng nhóm, trưởng nhóm kỹ thuật và trưởng nhóm phát triển. Ở vị trí này, chuyên gia thường tự viết code, quản lý công việc của nhóm và chịu trách nhiệm về phần kỹ thuật:

• tạo ra chiến lược phát triển dự án;
• thiết kế kiến trúc;
• xác định ngăn xếp công nghệ cho các nhiệm vụ và dự án cụ thể;
• giám sát các phiên bản của các thư viện liên quan;
• chịu trách nhiệm về chất lượng mã;
• kiểm soát mức nợ kỹ thuật để nó không trở nên quan trọng đối với dự án.

Sẽ thuận tiện hơn nhiều cho doanh nghiệp khi trưởng nhóm và trưởng nhóm kỹ thuật là một người. Trên thực tế, ngay cả ở những công ty lớn, vị trí trưởng nhóm cũng liên quan đến sự kết hợp của cả ba vai trò này với tỷ lệ khác nhau. Vì vậy, ý tưởng về công việc của một trưởng nhóm thường khác nhau.

Nếu bạn hỏi các nhà phát triển từ các công ty khác nhau về trách nhiệm của trưởng nhóm, câu trả lời rất có thể sẽ khác nhau. Sẽ có nhiều ý kiến tương tự giữa các trưởng nhóm. Để xác minh điều này, chỉ cần truy cập bất kỳ trang tìm kiếm việc làm nào và xem danh sách trách nhiệm ở các vị trí tuyển dụng khác nhau.

Ai có thể trở thành trưởng nhóm?

Để lãnh đạo một nhóm phát triển, bạn cần có năng lực và kinh nghiệm nghiêm túc. Vì vậy, cách phổ biến và đúng đắn nhất để trở thành trưởng nhóm là trước tiên phải lên cấp cao và sau đó mới hướng tới vị trí lãnh đạo. Nhưng điều này không phải lúc nào cũng xảy ra.

Nếu nhóm chỉ bao gồm các lập trình viên cấp trung và trong số họ có một nhân viên chủ động, người nắm rõ mọi vấn đề và hỗ trợ dự án, thì anh ta sẽ là một trưởng nhóm xuất sắc. Đúng, anh ấy có trình độ kỹ thuật kém hơn tiền bối, nhưng nếu không có ai cao hơn trong đội thì năng lực của anh ấy sẽ khá đầy đủ.

Đồng thời, không phải tiền bối nào cũng tìm được vị trí trưởng nhóm là con đường sự nghiệp phù hợp. Làm việc ở vị trí lãnh đạo phải thực sự thú vị, nếu không bạn có thể bị kiệt sức vì khối lượng công việc quản lý.

Làm thế nào để hiểu rằng bạn có thể xử lý khối lượng công việc?

Câu trả lời ngắn gọn: hãy thử nó. Nói với người quản lý của bạn rằng bạn muốn đảm nhận thêm trách nhiệm miễn phí và xem điều gì sẽ xảy ra. Đây là phương án đôi bên cùng có lợi nên ban lãnh đạo thường sẵn sàng hợp tác.

Đội trưởng thắng : có người làm việc cho anh ta.

Doanh nghiệp thắng : công việc được hoàn thành nhưng bạn không phải trả tiền cho việc đó.

Học viên trưởng nhóm cũng có một lợi thế : sau khi làm việc ở chế độ này vài tháng đến một năm, anh ta có thể tự mình hiểu được liệu mình có thành công hay không và liệu mình có thích lãnh đạo hay không. Và nếu câu trả lời cho từng điểm là “có”, bạn có thể nghiêm túc suy nghĩ về việc phát triển theo hướng này.

Cách trở thành trưởng nhóm: chiến lược tăng trưởng

Chỉ có hai lựa chọn. Đầu tiên là loại bỏ tất cả các nhà phát triển khác trong công ty và trở thành trưởng nhóm với tư cách là nhân viên “lớn tuổi nhất”. Tuy nhiên, có nguy cơ là từ “cũ” sẽ không phải đặt trong dấu ngoặc kép. Lựa chọn thứ hai là tự mình chủ động.

Tôi sẽ cho bạn biết nó đã xảy ra với tôi như thế nào. Theo bằng tốt nghiệp của tôi, nghề nghiệp của tôi là quản lý và tôi đã tự học lập trình song song với việc học ở trường đại học. Vì vậy, tôi quyết định trở thành trưởng nhóm phát triển ngay cả trước khi tôi nhận được công việc đầu tiên là lập trình viên.

Lúc đầu, tôi làm việc ở các công ty nhỏ. Tôi đã mất hai năm để làm quen với nó và phát triển từ một cầu thủ cấp dưới thành một cầu thủ trung phong mạnh mẽ. Nếu không có kinh nghiệm lập trình, bạn sẽ không thể trở thành một trưởng nhóm giỏi: bạn cần hiểu quá trình phát triển diễn ra như thế nào cũng như những sai sót và cạm bẫy nào tồn tại.

Vài năm sau, tôi đến làm việc cho một công ty lớn và ngay lập tức bày tỏ mong muốn trở thành trưởng nhóm. Ở các công ty lớn, sáu tháng hoặc một năm một lần, họ thường tiến hành đánh giá hiệu suất, khi người quản lý gặp nhân viên và cùng nhau xây dựng kế hoạch phát triển cá nhân cho tương lai gần. Tại mỗi cuộc họp như vậy, tôi đều nói rằng tôi muốn trở thành trưởng nhóm. Lần đầu tiên họ nói với tôi: “Mọi thứ đều tuyệt vời, nhưng trước hết hãy tích lũy kinh nghiệm đã”. Chúng tôi đã lập một kế hoạch phát triển để tôi có thể tích lũy kinh nghiệm lãnh đạo.

Trong khoảng sáu tháng, cùng với trưởng nhóm của mình, tôi đánh giá và phân chia các nhiệm vụ và cố gắng phân bổ chúng cho các nhân viên. Khi chất lượng công việc của chúng tôi ít nhiều ngang nhau, công ty mới thành lập một nhóm phát triển front-end mới do tôi đứng đầu. Ở những công ty lớn, bạn không phải đợi quá lâu.

Người ta nói rằng có hai cột mốc quan trọng trong quá trình phát triển của một trưởng nhóm: thứ nhất là từ hai đến sáu nhân viên, thứ hai là từ 7 nhân viên trở lên. Lúc đầu, tôi chỉ có một nhân viên, bây giờ tôi lãnh đạo ba nhóm phát triển front-end - 12 nhân viên.

Tôi chỉ đơn giản là thể hiện sự chủ động, xuất hiện trước mặt quản lý và ngay khi có cơ hội, tôi được bổ nhiệm làm trưởng nhóm.

Chờ tăng trưởng hay rời sang công ty khác?

Các trưởng nhóm thường được đề cao trong công ty và điều này rất quan trọng cần được tính đến. Nếu công việc hiện tại của bạn có triển vọng phát triển, bạn nên chủ động và thử sức mình trong vai trò người quản lý. Nhưng nếu cả nhóm đều là front-end và back-end và mỗi người đều là trưởng nhóm của riêng mình thì bạn không nên mong đợi một phép màu. Tốt hơn là bạn nên chuyển đến một công ty lớn hơn và cho biết rằng trong tương lai bạn muốn đảm nhận vị trí lãnh đạo. Bạn sẽ cần thời gian để nghiên cứu các quy trình và hiểu logic nghiệp vụ của dự án. Nhưng khi một vị trí phù hợp mở ra trong công ty, rất có thể họ sẽ chọn bạn thay vì một người ngoài cuộc.

Những kỹ năng nào sẽ giúp bạn trở thành một trưởng nhóm giỏi?

Ở vị trí trưởng nhóm, kỹ năng cứng và kỹ năng mềm đều quan trọng như nhau. Các nhà phát triển thường biết kỹ năng cứng còn thiếu những gì. Hơn nữa, các yêu cầu này gắn chặt với chuyên môn hóa và công nghệ nên không có danh sách chung. Tôi sẽ nói về các kỹ năng mềm mà tôi cho là quan trọng đối với sản phẩm và công ty.

Khả năng tìm ra vấn đề trong quá trình

Tốc độ và chất lượng phát triển, do đó, chi phí, phụ thuộc vào các quy trình trong công ty, nhưng chúng hiếm khi lý tưởng.

Ví dụ: bạn đã sửa lỗi và sẵn sàng đưa bản dựng lên giá đỡ, công việc kinh doanh đang chờ đợi. Nhưng để làm được điều này, bạn cần phải trải qua năm quy trình và thu thập sự chấp thuận từ tất cả những người có liên quan. Bạn viết thư cho những người phụ trách - im lặng. Bạn bắt đầu lôi kéo họ, nhưng những tin nhắn trang trọng đến chỉ để phản hồi - mọi người đều không có thời gian. Có thể mất đến sáu giờ trước khi phiên bản đã sửa được đưa lên kệ. Và tất cả thời gian này bạn dành để cố gắng tiếp cận đồng nghiệp của mình và công việc kinh doanh sẽ thua lỗ.

Một ví dụ khác là số lượng truy cập cắt cổ vào các hệ thống, chương trình, gian hàng và kho lưu trữ khác nhau. Các ngân hàng thường phải chịu đựng điều này. Một người đến làm việc, anh ta cần phải hiểu dự án, nhưng trong một tháng rưỡi đầu tiên anh ta không thể làm được gì cả, bởi vì - đúng vậy - không có quyền truy cập. Một vấn đề khác với quyền truy cập là có rất nhiều quyền truy cập và không thể nhớ tên của chúng. Ví dụ: thay vì “truy cập vào kho lưu trữ” trong thư mục sẽ có A32B18KZ - hãy thử tìm nó.

Tôi biết những trường hợp thực tế mà nhà phát triển không thể bắt đầu công việc trong một hoặc hai tháng. Tất cả thời gian này anh ấy đã nhận được tiền lương, nhưng vỡ mộng và nghỉ việc. Nghĩa là, công ty đã dành sáu tháng để tìm kiếm một nhân viên, trả lương cho anh ta trong hai tháng và sau đó phải bắt đầu lại quá trình tuyển dụng.

Những vấn đề như vậy trong quy trình sẽ làm phức tạp và làm chậm công việc. Nhiệm vụ của trưởng nhóm là nhìn thấy chúng và hiểu chính xác điều gì đang hoạt động kém và lỗi xảy ra ở đâu.

Khả năng giải quyết vấn đề hoặc truyền đạt chúng một cách chính xác cho doanh nghiệp

Điều quan trọng không chỉ là nhìn thấy các vấn đề trong quy trình mà còn đưa ra giải pháp. Bạn có thể tự mình giải quyết một số khó khăn mà không cần đến sự quản lý. Ví dụ, một nhóm đang gặp khó khăn với một người quản lý trạng thái bất tiện. Nếu dự án nhỏ hoặc mới bắt đầu, bạn có thể sắp xếp một cuộc gọi, tìm phương án tốt nhất và vạch ra cách giới thiệu dần dần một người quản lý nhà nước mới mà không bị lỗ. Một giải pháp đã được tìm ra và doanh nghiệp thậm chí còn không biết về sự tồn tại của vấn đề.

Nhưng hầu hết các vấn đề chỉ có thể được giải quyết với sự giúp đỡ của quản lý cấp cao. Ví dụ: để đẩy nhanh tốc độ đưa các bản dựng lên gian hàng, bạn có thể xác định một người có mối quan hệ tốt với tất cả các bộ phận và có quyền tiếp cận với những người ra quyết định, đồng thời lôi kéo người đó tham gia vào quá trình phê duyệt. Nếu không có phản hồi từ đồng nghiệp từ các bộ phận khác, anh ấy biết phải viết thư cho ai và có thể thiết lập quy trình theo cách thủ công. Nhưng công việc như vậy đòi hỏi một vị trí riêng nên bạn cần được sự chấp thuận của ban lãnh đạo công ty.

Vấn đề truy cập được giải quyết tương tự. Hầu hết các nhà phát triển đều cần các hệ thống và chương trình giống nhau. Ví dụ: đối với các nhà phát triển giao diện người dùng - kho lưu trữ, giá đỡ, Jira, v.v. Vậy tại sao không tạo gói truy cập tiêu chuẩn cho họ và thuê một người sẽ yêu cầu họ với một mức lương nhỏ? Nhưng điều này cũng đòi hỏi ý chí của lãnh đạo cao nhất của công ty.

Vì vậy, một trong những kỹ năng chính của trưởng nhóm là có thể truyền đạt chính xác bản chất của vấn đề cho doanh nghiệp. Có một số bí mật ở đây.

• Một lần là không đủ . Các vấn đề hiếm khi được giải quyết sau lần liên hệ đầu tiên, vì vậy bạn cần đến gặp ban quản lý vào những khoảng thời gian nhất định và nhắc nhở họ về vấn đề: “điều này đang làm mất tinh thần của nhóm”, “chúng tôi đang làm giảm năng suất”.

  
  

• Nếu bạn thấy các vấn đề của nhóm và lợi ích kinh doanh được kết nối với nhau như thế nào, hãy nhấn vào vị trí này . Ví dụ: có một lỗi nghiêm trọng phải mất hai ngày để sửa, mặc dù chỉ mất vài giờ làm việc và kết quả là doanh nghiệp thua lỗ. Bạn đến gặp quản lý và nói về vấn đề phối hợp xây dựng. Vào những thời điểm như vậy, các doanh nghiệp càng cởi mở với những đề xuất càng tốt. Nhưng giải pháp phải đã sẵn sàng.

Nói cùng ngôn ngữ với doanh nghiệp

Cách chắc chắn nhất là tính toán xem vấn đề này khiến công ty thiệt hại bao nhiêu trước khi đưa nó lên ban quản lý.

Với tư cách là trưởng nhóm front-end, tôi thường xuyên thu thập phản hồi từ nhân viên. Ví dụ, các nhà phát triển liên tục phàn nàn rằng các nhiệm vụ được mô tả kém. Vì điều này, phải mất một thời gian dài mới tìm ra được tác giả của vấn đề muốn gì ở họ. Sau đó, những người thử nghiệm đến gặp các nhà phát triển và cố gắng hiểu những gì đã được thực hiện và chính xác những gì họ cần thử nghiệm, cũng như hơn thế nữa trong chuỗi. Kết quả là mọi người vẫn hiểu bản chất theo cách riêng của mình và lỗi xuất hiện.

Tôi tính toán rằng trung bình nhóm dành 40% thời gian làm việc để sửa lỗi. Cùng với nhóm, chúng tôi đã tiến hành phân tích hồi cứu và phát hiện ra rằng một nửa số lỗi này phát sinh chỉ do họ hiểu sai bản chất của vấn đề. Tức là 20% thời gian làm việc của nhà phát triển bị lãng phí vì nhiệm vụ được mô tả kém. Đây là con số bạn nên đến gặp ban quản lý. Thật dễ dàng để chuyển nó thành tiền - cùng ngôn ngữ mà doanh nghiệp hiểu.

Tạo môi trường thuận lợi trong nhóm

Khi mọi người thích làm việc với nhau, mọi tương tác sẽ diễn ra suôn sẻ hơn. Tại sao Scrum lại phổ biến đến vậy? Đây không phải là về tài liệu mà là về con người. Đôi khi, việc gọi điện cho đồng nghiệp trong hai phút sẽ hiệu quả hơn là đợi hai ngày để anh ta ghi lại câu trả lời và mô tả mọi thứ một cách chi tiết. Vì vậy, khi có bầu không khí hiểu biết lẫn nhau và giúp đỡ lẫn nhau trong nhóm thì mọi người sẽ dễ dàng liên hệ với nhau hơn. Ví dụ: bạn tìm thấy một đoạn mã và bạn không hiểu nó làm gì. Nếu tình hình trong nhóm không tốt, bạn sẽ ngại gọi điện và hỏi - “anh ấy sẽ nghĩ tôi ngu ngốc”.

Để duy trì mối quan hệ tốt trong nhóm, tôi tổ chức các cuộc gọi kéo dài hàng giờ mỗi tuần một lần. Chúng tôi chia thời gian này thành ba phần. Đầu tiên là “thư giãn”. Chúng tôi chia sẻ meme và truyện cười. Phần thứ hai là thảo luận về các vấn đề. Đôi khi chúng tôi cùng nhau ném bài trong Miro, điều này không phải ai cũng thích. Đây là cách tôi có được hình ảnh chính xác về điều gì đang làm chậm các chàng trai. Sau đó, chúng tôi có thể đưa ra các phương án giải pháp và sau đó tôi sẽ vận động hành lang với ban quản lý. Và chúng tôi kết thúc việc “thư giãn” một lần nữa: chúng tôi có thể thảo luận về phim ảnh hoặc điều gì đó khác. Những cuộc họp như vậy tạo ra bầu không khí tích cực và khiến tôi, với tư cách là người lãnh đạo, hiểu được những khó khăn trong nhóm đang gặp phải.

Đại biểu

Một sai lầm phổ biến của những người lãnh đạo nhóm mới là tập trung quá trình làm việc vào chính họ. Trong trường hợp này, nếu trưởng nhóm đột nhiên bị ốm hoặc đi nghỉ, công việc sẽ bắt đầu bị đình trệ và anh ta sẽ liên tục bị kéo. Để ngăn điều này xảy ra, bạn có thể dạy ai đó trong nhóm thực hiện một phần trách nhiệm của trưởng nhóm. Ví dụ: tin tưởng người khác phân công nhiệm vụ mỗi tháng một lần. Bằng cách này, một người khác trong nhóm sẽ có kỹ năng này và trưởng nhóm sẽ có thể đi nghỉ một cách bình tĩnh, biết rằng sẽ không có chuyện gì xảy ra nếu không có anh ta.

Có lẽ đây là một tiêu chí tốt để đánh giá công việc của một trưởng nhóm: nếu bạn bị loại khỏi nhóm, mức an toàn sẽ đủ trong một tháng.

Phân bổ hợp lý các khu vực chịu trách nhiệm trong nhóm

Trong quá trình phát triển, một số liệu như hệ số bus được sử dụng để quản lý rủi ro đối với dự án. Nó cho thấy có bao nhiêu thành viên trong nhóm phải bị một chiếc xe buýt hư cấu đâm phải để phá hủy toàn bộ dự án. Nếu hệ số bus = 1, bạn đang gặp vấn đề nghiêm trọng.

Ví dụ, chúng tôi đang phát triển một dự án phức tạp. Nó có một mô-đun phức tạp và chỉ có một nhà phát triển biết cách hoạt động cũng như cách xử lý nó. Nếu người này bị ốm, nghỉ việc hoặc đi nghỉ, việc thay đổi mô-đun này sẽ trở thành một thủ tục rất dài và tốn kém, ảnh hưởng tiêu cực đến toàn bộ dự án. Để ngăn điều này xảy ra, bạn cần dần dần dạy các nhân viên khác cách làm việc với các mô-đun hoặc thư viện phức tạp.

Trưởng nhóm phải có khả năng phân bổ trách nhiệm một cách chính xác trong nhóm mà không giới hạn các quy trình cho một người, không khiến người đó trở nên quan trọng đối với dự án.

Tầm nhìn chiến lược của dự án

Người lãnh đạo tổ phải hiểu dự án đang đi tới đâu, nó có vấn đề gì và cách giải quyết chúng. Ví dụ: tổng khối lượng công việc của nhóm là 100 giờ làm việc mỗi tuần. Và doanh nghiệp đưa ra mong muốn của mình trong suốt 100 giờ. Tại thời điểm này, nợ kỹ thuật đang tích tụ trên dự án, đây cũng là lúc phải giải quyết. Nhiệm vụ của trưởng nhóm là theo dõi thời điểm trước khi nợ kỹ thuật trở nên nghiêm trọng và quản lý vận động hành lang để nhóm dành một tỷ lệ thời gian nhất định để giải quyết các vấn đề hiện tại.

Bạn có thể gặp phải những vấn đề gì khi là trưởng nhóm?

Tốt hơn hết là ngay từ đầu bạn nên biết lý do tại sao các trưởng nhóm lại nỗ lực nhận ra những hồi chuông cảnh báo.

Sự hiểu lầm từ phía doanh nghiệp

Đây là vấn đề phổ biến nhất khi, hết tháng này qua tháng khác, bạn cố gắng liên hệ với ban quản lý, bạn đưa ra các vấn đề của mình và một giải pháp có sẵn, nhưng trên hết, họ chỉ đưa vấn đề vào hồ sơ tồn đọng và không có gì xảy ra. Có thể có nhiều lý do. Đầu tiên là bạn đang nói sai ngôn ngữ trong kinh doanh và bạn nên thay đổi cách tiếp cận của mình. Thứ hai là sếp của bạn “biết rõ mọi thứ” và tiếp tục làm mọi việc theo cách của mình. Trong trường hợp này, giải pháp tốt nhất là thay đổi công ty.

Thiếu nguồn lực

Một ví dụ đơn giản: nhóm của bạn liên tục bị ngập trong nhiệm vụ và không còn đủ người. Các doanh nghiệp vừa và nhỏ có thể không có đủ tiền để thuê nhân viên mới. Trong trường hợp này, bạn có thể đảm nhận một vai trò bổ sung, chẳng hạn như vai trò của nhà phân tích hệ thống và bắt đầu mô tả các nhiệm vụ để công việc tiến triển nhanh hơn. Ở các công ty lớn, rất có thể là có tiền, nhưng chuỗi ra quyết định quá dài và không có gì đảm bảo rằng một con mèo chưa vượt qua được giữa sếp cấp ba và cấp bốn và quá trình này sẽ không bị đình trệ vì điều này. Ở đây, bạn chỉ có thể cố gắng thu phục ai đó từ ban lãnh đạo cấp cao về phía mình hoặc chỉ chờ đợi.

Kết quả của công việc không thể nhìn thấy được

Chuyện xảy ra là bạn đến một công ty, xây dựng chiến lược, lập kế hoạch và đam mê công việc, nhưng thời gian trôi qua mà không có gì thay đổi. Không mất nhiều thời gian để trở nên chán nản ở đây: "Ai cần tất cả những thứ này?" Trong trường hợp này, bạn có thể tiến hành phân tích hồi cứu để hiểu lý do tại sao dự án không tiến triển. Hãy tự hỏi bản thân: “Có lẽ mình đang nhắm sai mục tiêu, giải quyết sai vấn đề?”

Thiếu công cụ để đạt được mục tiêu

Điều này xảy ra khi bạn được giao vào vị trí lãnh đạo, được giao trách nhiệm nhưng không được trao bất kỳ đòn bẩy kiểm soát nào. Ví dụ: không có cách nào để tiến hành phỏng vấn một cách độc lập và tuyển dụng các nhà phát triển vào nhóm của bạn. Ở đây chỉ có hai lựa chọn: cố gắng liên hệ với doanh nghiệp và cho biết vị trí của bạn hoặc thay đổi công ty.

Tiếp cận trực tiếp với quản lý cấp cao

Để phát triển sản phẩm và giải quyết các vấn đề hiện tại của nhóm, trưởng nhóm phải thường xuyên liên lạc với những người ra quyết định. Nếu quyền truy cập vào "top" bị đóng, các vấn đề sẽ không được giải quyết, các chiến lược phát triển đầy hứa hẹn sẽ không được nói ra và động lực làm việc sẽ mất đi. Để không kiệt sức, tốt hơn hết bạn nên thay đổi công ty nếu không thiết lập được mối quan hệ với ban lãnh đạo.

Chế độ khẩn cấp vĩnh viễn

Đôi khi có quá nhiều nhiệm vụ và nhóm không còn có thể đáp ứng được luồng công việc đang đến. Trong tình huống khẩn cấp liên tục, các cuộc gọi thông thường sẽ mờ dần trong nền - ai cần meme và cuộc trò chuyện trống rỗng khi có thể dành thời gian này để loại bỏ lỗi? Kết quả là cả đội biến thành một con ngựa bị điều khiển, sớm muộn gì cũng kiệt sức và mọi người sẽ bắt đầu bỏ đi. Tất cả những gì trưởng nhóm có thể làm là cố gắng ép nhân viên mở rộng hoặc xếp các nhiệm vụ vào hàng đợi.

Bầu không khí tồi tệ trong đội

Điều này có thể xảy ra nếu bạn tham gia vào một nhóm đã được thành lập mà mọi người đều ghét nhau. Một phong cách giao tiếp độc hại đã ăn sâu vào nhóm và không có bất kỳ cuộc nói chuyện nào về việc hỗ trợ lẫn nhau. Khi đó điều duy nhất có thể làm là giải tán toàn bộ đội và chiêu mộ lại.

Dù vấn đề là gì, luôn có cơ hội đạt được kết quả thuận lợi. Đừng bỏ cuộc sau thất bại đầu tiên. Có thể đáng để chờ đợi một chút hoặc thay đổi cách tiếp cận của bạn. Nhưng nếu bạn đã thử mọi cách và cảm giác như đang đập vào một bức tường trống, thì quyết định ra đi sẽ là quyết định đúng đắn duy nhất.

Phần kết luận

Khả năng giải quyết vấn đề là một phẩm chất quan trọng của người lãnh đạo nhóm. Nhưng than ôi, không phải lúc nào nó cũng thành công. Nhưng nếu bạn cảm thấy rằng bạn đã đánh dấu thời gian được một hoặc hai năm và không thể tác động đến nó bằng bất kỳ cách nào nhưng bạn muốn phát triển thì việc thay đổi công ty không phải là một ý tưởng tồi. Đừng sợ thay đổi. Thay đổi công việc là chuyện bình thường.