Chào mọi người! Tên tôi là Lyudmila Makarova, tôi là giám đốc phát triển tại UBRD và một phần ba nhóm của tôi là “những nhà tổng hợp”.
Hãy thừa nhận điều đó: mọi Trưởng nhóm công nghệ đều mơ ước có được nhiều chức năng trong nhóm của họ. Thật tuyệt vời khi một người có thể thay thế ba người và thậm chí thực hiện việc đó một cách hiệu quả mà không bị trì hoãn thời hạn. Và quan trọng là nó tiết kiệm tài nguyên!
Nghe có vẻ rất hấp dẫn nhưng thực tế có phải vậy không? Hãy cố gắng tìm ra nó.
Anh ta là ai, người báo trước những kỳ vọng của chúng ta?
Thuật ngữ “người tổng quát” thường đề cập đến các thành viên trong nhóm kết hợp nhiều hơn một vai trò, chẳng hạn như nhà phân tích-nhà phát triển.
Sự tương tác của nhóm và kết quả công việc của nhóm phụ thuộc vào phẩm chất chuyên môn và cá nhân của những người tham gia.
Mọi thứ đều rõ ràng về kỹ năng cứng, nhưng kỹ năng mềm đáng được quan tâm đặc biệt. Họ giúp tìm ra cách tiếp cận nhân viên và hướng anh ta đến nhiệm vụ mà anh ta sẽ hữu ích nhất.
Có rất nhiều bài viết về đủ loại tính cách trong ngành CNTT. Dựa trên kinh nghiệm của mình, tôi sẽ chia các chuyên gia CNTT tổng quát thành bốn loại:
1. “Phổ quát – Toàn năng”
Đây là ở khắp mọi nơi. Họ luôn rất năng động, muốn trở thành trung tâm của sự chú ý, liên tục hỏi thăm đồng nghiệp xem họ có cần giúp đỡ không, thậm chí đôi khi họ còn có thể gây khó chịu. Họ chỉ quan tâm đến những nhiệm vụ có ý nghĩa, việc tham gia vào đó sẽ tạo cơ hội cho sự sáng tạo và có thể giải trí cho niềm kiêu hãnh của họ.
Họ mạnh ở điểm gì:
- có khả năng giải quyết các vấn đề phức tạp;
- đi sâu vào vấn đề, “đào” và đạt kết quả;
- có đầu óc ham học hỏi.
Nhưng:
- không ổn định về mặt cảm xúc;
- quản lý kém;
- có quan điểm không lay chuyển, rất khó thay đổi;
- Thật khó để bắt ai đó làm một việc đơn giản. Những nhiệm vụ dễ dàng sẽ làm tổn thương cái tôi của đấng toàn năng.
2. “Phổ quát – Tôi sẽ tìm ra và thực hiện”
Những người như vậy chỉ cần một cuốn sách hướng dẫn và một chút thời gian - và họ sẽ giải quyết được vấn đề. Họ thường có nền tảng vững chắc về DevOps. Những người tổng quát như vậy không bận tâm đến việc thiết kế và thích sử dụng phương pháp phát triển chỉ dựa trên kinh nghiệm của họ. Họ có thể dễ dàng thảo luận với trưởng nhóm kỹ thuật về phương án đã chọn để thực hiện nhiệm vụ.
Họ mạnh ở điểm gì:
- độc lập;
- sức chịu đựng của đường;
- có năng lực trong nhiều vấn đề;
- uyên bác - luôn có điều gì đó để nói với họ.
Nhưng:
- thường xuyên vi phạm nghĩa vụ;
- có xu hướng phức tạp hóa mọi thứ: giải bảng nhân bằng cách lấy tích phân từng phần;
- chất lượng công việc thấp, mọi việc làm 2-3 lần;
- Họ liên tục thay đổi thời hạn, bởi vì trên thực tế mọi thứ hóa ra không đơn giản như vậy.
3. “Universal – được rồi, hãy để tôi làm điều đó, vì không còn ai khác”
Nhân viên này thông thạo nhiều lĩnh vực và có kinh nghiệm liên quan. Nhưng anh ta không thể trở thành chuyên gia trong bất kỳ lĩnh vực nào trong số đó, bởi vì anh ta thường được sử dụng như một cứu cánh, bịt lỗ hổng trong các nhiệm vụ hiện tại. Mềm mại, hiệu quả, coi mình là người có nhu cầu, nhưng không phải vậy.
Một nhân viên lý tưởng thực tế. Rất có thể, anh ta có một hướng đi mà anh ta thích nhất, nhưng do năng lực bị mờ nhạt nên sự phát triển không diễn ra. Kết quả là, một người có nguy cơ trở nên vô thừa nhận và kiệt sức về mặt cảm xúc.
Họ mạnh ở điểm gì:
- chịu trách nhiệm;
- hướng đến kết quả;
- điềm tĩnh;
- hoàn toàn được kiểm soát.
Nhưng:
- cho thấy kết quả trung bình do trình độ năng lực thấp;
- không thể giải quyết các vấn đề phức tạp và trừu tượng.
4. “Người toàn diện là bậc thầy trong nghề của mình”
Một người có nền tảng vững chắc về lập trình viên sẽ có tư duy hệ thống. Tính mô phạm, đòi hỏi ở bản thân và đồng đội. Bất kỳ nhiệm vụ nào liên quan đến anh ta đều có thể phát triển vô thời hạn nếu ranh giới không được xác định.
Anh am hiểu kiến trúc, lựa chọn phương pháp triển khai kỹ thuật, phân tích kỹ tác động của giải pháp đã chọn đến kiến trúc hiện tại. Khiêm tốn, không tham vọng.
Họ mạnh ở điểm gì:
- thể hiện chất lượng công việc cao;
- có khả năng giải quyết mọi vấn đề;
- rất hiệu quả.
Nhưng:
- không khoan dung với ý kiến của người khác;
- những người theo chủ nghĩa tối đa. Họ cố gắng làm mọi thứ đúng cách và điều này làm tăng thời gian phát triển.
Chúng ta có gì trong thực tế?
Hãy xem vai trò và năng lực thường được kết hợp như thế nào. Hãy lấy một nhóm phát triển tiêu chuẩn làm điểm khởi đầu: PO, giám đốc phát triển (trưởng nhóm công nghệ), nhà phân tích, lập trình viên, người thử nghiệm. Chúng tôi sẽ không xem xét chủ sở hữu sản phẩm và trưởng nhóm kỹ thuật. Đầu tiên là do thiếu năng lực kỹ thuật. Người thứ hai, nếu có vấn đề trong nhóm, bạn có thể làm được mọi việc.
Tùy chọn phổ biến nhất để kết hợp/sáp nhập/kết hợp các năng lực là nhà phân tích-nhà phát triển. Việc phân tích thử nghiệm và “ba trong một” cũng rất phổ biến.
Lấy nhóm của tôi làm ví dụ, tôi sẽ cho bạn thấy những ưu và nhược điểm của những người bạn tổng quát của tôi. Có một phần ba trong số họ trong đội của tôi và tôi rất yêu quý họ.
PO nhận được một nhiệm vụ cấp bách là đưa ra các mức thuế mới cho một sản phẩm hiện có. Nhóm của tôi có 4 nhà phân tích. Khi đó, một người đang đi nghỉ, một người bị ốm, những người còn lại đang thực hiện các nhiệm vụ chiến lược. Nếu tôi rút chúng ra, chắc chắn sẽ làm gián đoạn thời hạn thực hiện. Chỉ có một lối thoát duy nhất: sử dụng “vũ khí bí mật” - một nhà phân tích-nhà phát triển đa năng, người nắm vững lĩnh vực chủ đề được yêu cầu. Hãy gọi anh ấy là Anatoly.
Kiểu tính cách của anh ấy là “phổ quát – tôi sẽ tìm ra và thực hiện nó”. Tất nhiên, anh ấy đã cố gắng giải thích rất lâu rằng anh ấy “có đầy đủ các nhiệm vụ tồn đọng”, nhưng trước quyết định mạnh mẽ của tôi, anh ấy đã được cử đi giải quyết một vấn đề cấp bách. Và Anatoly đã làm được điều đó! Anh đã tiến hành dàn dựng và hoàn thành việc thực hiện đúng thời hạn, khách hàng đều hài lòng.
Thoạt nhìn, mọi thứ đã diễn ra tốt đẹp. Nhưng sau một vài tuần, yêu cầu cải tiến lại xuất hiện đối với sản phẩm này. Bây giờ việc xây dựng bài toán này được thực hiện bởi một nhà phân tích “thuần túy”. Ở giai đoạn thử nghiệm sự phát triển mới, trong một thời gian dài, chúng tôi không thể hiểu tại sao chúng tôi lại mắc sai sót trong việc liên kết các mức thuế mới, và chỉ sau đó, khi đã giải quyết được toàn bộ mớ bòng bong, chúng tôi mới đi đến tận cùng của sự thật. Chúng tôi đã lãng phí rất nhiều thời gian và bỏ lỡ thời hạn.
Vấn đề là nhiều khoảnh khắc và cạm bẫy tiềm ẩn chỉ còn trong phần đầu toa xe ga của chúng tôi chứ không được chuyển ra giấy. Như Anatoly sau này giải thích, anh ấy đã quá vội vàng. Nhưng lựa chọn rất có thể là anh ta đã gặp phải các vấn đề đã có trong quá trình phát triển và chỉ đơn giản là bỏ qua chúng mà không phản ánh điều này ở bất cứ đâu.
Có một tình huống khác. Bây giờ chúng tôi chỉ có một người thử nghiệm nên một số nhiệm vụ phải được các nhà phân tích kiểm tra, bao gồm cả những người tổng hợp. Vì vậy, tôi đã giao một nhiệm vụ cho Fedor có điều kiện - “phổ quát – được rồi, hãy để tôi làm điều đó, vì không còn ai khác”.
Fedor là “ba trong một”, nhưng một nhà phát triển đã được phân bổ cho nhiệm vụ này. Điều này có nghĩa là Fedya chỉ phải kết hợp một nhà phân tích và một người thử nghiệm.
Các yêu cầu đã được thu thập, thông số kỹ thuật đã được gửi để phát triển, đã đến lúc thử nghiệm. Fedor biết rõ hệ thống đang được sửa đổi “như lòng bàn tay” và đã tính toán kỹ lưỡng các yêu cầu hiện tại. Vì vậy, anh không bận tâm đến việc viết kịch bản thử nghiệm mà thực hiện thử nghiệm “hệ thống nên hoạt động như thế nào” rồi chuyển cho người dùng.
Quá trình thử nghiệm đã hoàn thành, bản sửa đổi đã được đưa vào sản xuất. Sau đó, hóa ra hệ thống không chỉ tạm dừng thanh toán đối với một số tài khoản số dư nhất định mà còn chặn các khoản thanh toán từ những tài khoản nội bộ rất hiếm không được phép tham gia vào việc này.
Điều này xảy ra do Fedor đã không kiểm tra xem “hệ thống không nên hoạt động như thế nào”, không lập kế hoạch kiểm tra hoặc danh sách kiểm tra. Anh quyết định tiết kiệm thời gian và dựa vào bản năng của chính mình.
Chúng ta giải quyết vấn đề như thế nào?
Những tình huống như thế này sẽ tác động đến hiệu suất của nhóm, chất lượng phát hành và sự hài lòng của khách hàng. Vì vậy, không thể bỏ mặc họ mà không quan tâm, phân tích nguyên nhân.
1. Đối với mỗi nhiệm vụ gây khó khăn, tôi yêu cầu bạn điền vào một biểu mẫu thống nhất: bản đồ lỗi, cho phép bạn xác định giai đoạn xảy ra hiện tượng “rút vốn”:
2. Sau khi xác định được những điểm nghẽn, một buổi động não sẽ được tổ chức với từng nhân viên có ảnh hưởng đến vấn đề: “Cần thay đổi điều gì?” (chúng tôi không xem xét các trường hợp đặc biệt khi nhìn lại), do đó các hành động cụ thể được sinh ra (cụ thể cho từng loại tính cách) có thời hạn.
3. Chúng tôi đã đưa ra các quy tắc tương tác trong nhóm. Ví dụ: chúng tôi nhất trí ghi lại tất cả thông tin về tiến độ của một nhiệm vụ trong hệ thống quản lý dự án. Khi các thành phần được thay đổi/xác định trong quá trình phát triển, điều này phải được phản ánh trong cơ sở tri thức và phiên bản cuối cùng của thông số kỹ thuật.
4. Việc kiểm soát bắt đầu được thực hiện ở từng giai đoạn (đặc biệt chú ý đến các giai đoạn có vấn đề trước đó) và tự động dựa trên kết quả của nhiệm vụ tiếp theo.
5. Nếu kết quả của nhiệm vụ tiếp theo không thay đổi, thì tôi sẽ không đặt người tổng quát vào vai trò mà anh ta đối phó kém. Tôi cố gắng đánh giá khả năng và mong muốn phát triển năng lực của anh ấy trong vai trò này. Nếu không tìm được câu trả lời, tôi sẽ để anh ấy ở vai trò gần gũi hơn với anh ấy.
Rốt cuộc chuyện gì đã xảy ra?
Quá trình phát triển đã trở nên minh bạch hơn. Yếu tố BUS đã giảm. Các thành viên trong nhóm, khi khắc phục sai lầm, sẽ trở nên có động lực hơn và cải thiện nghiệp lực của mình. Chúng tôi đang dần cải thiện chất lượng các bản phát hành của mình.
Những phát hiện
Những nhân viên theo chủ nghĩa tổng quát đều có những ưu và nhược điểm.
Cộng thêm:
- bạn có thể đóng một tác vụ bị chùng xuống bất cứ lúc nào hoặc giải quyết một lỗi khẩn cấp trong thời gian ngắn;
- một cách tiếp cận tổng hợp để giải quyết vấn đề: người thực hiện nhìn vấn đề đó từ góc độ của tất cả các vai trò;
- những người nói chung có thể làm hầu hết mọi việc tốt như nhau.
Nhược điểm:
- hệ số BUS tăng;
- những năng lực cốt lõi vốn có của vai trò đó bị xói mòn. Vì điều này mà chất lượng công việc giảm sút;
- khả năng thay đổi thời hạn sẽ tăng lên, bởi vì không có sự kiểm soát ở mỗi giai đoạn. Cũng có những rủi ro khi trở thành một “ngôi sao”: nhân viên tự tin rằng anh ta biết rõ hơn rằng mình là một người chuyên nghiệp;
- nguy cơ kiệt sức nghề nghiệp tăng lên;
- rất nhiều thông tin quan trọng về dự án chỉ có thể lưu lại “trong đầu” nhân viên.
Như bạn có thể thấy, còn nhiều thiếu sót hơn. Vì vậy, tôi chỉ sử dụng những người tổng quát nếu không có đủ nguồn lực và nhiệm vụ khá cấp bách. Hoặc một người có những năng lực mà người khác không có nhưng chất lượng lại bị đe dọa.
Nếu quy tắc phân bổ vai trò được tuân thủ khi cùng thực hiện một nhiệm vụ thì chất lượng công việc sẽ tăng lên. Chúng ta nhìn vấn đề từ nhiều góc độ khác nhau, cái nhìn của chúng ta không bị mờ nhạt, những suy nghĩ mới mẻ luôn xuất hiện. Đồng thời, mỗi thành viên trong nhóm có mọi cơ hội để phát triển nghề nghiệp và mở rộng năng lực của mình.
Tôi tin rằng điều quan trọng nhất là cảm thấy được tham gia vào quá trình, thực hiện công việc của mình, tăng dần bề rộng năng lực của bạn. Tuy nhiên, những người tổng hợp trong nhóm mang lại lợi ích: điều chính là đảm bảo rằng họ kết hợp hiệu quả các vai trò khác nhau.
Tôi chúc mọi người có một đội ngũ tự tổ chức gồm những “bậc thầy phổ thông trong nghề”!
Nguồn: www.habr.com