Quản lý nhóm lập trình viên: làm thế nào và bằng cách nào để động viên họ đúng cách? Phần một

Epigraph:
Người chồng nhìn những đứa con cáu bẩn, nói với vợ: chúng ta giặt mấy đứa này hay sinh con mới?

Bên dưới phần cắt là cuộc thảo luận của trưởng nhóm của chúng tôi, cũng như Giám đốc phát triển sản phẩm RAS, Igor Marnat, về những đặc điểm của việc thúc đẩy các lập trình viên.

Quản lý nhóm lập trình viên: làm thế nào và bằng cách nào để động viên họ đúng cách? Phần một
Bí quyết thành công trong việc tạo ra các sản phẩm phần mềm thú vị đều được nhiều người biết đến - hãy tuyển dụng một nhóm lập trình viên giỏi, đưa ra ý tưởng hay cho nhóm và không can thiệp vào công việc của nhóm. Các nhà phát triển thú vị rất hiếm và có nhu cầu. Một số nhà tuyển dụng thậm chí còn nói rằng họ có ấn tượng rằng việc đào tạo ra một lập trình viên giỏi sẽ dễ dàng hơn là thuê một người từ thị trường. Ngoài những khó khăn trong việc tuyển dụng như vậy, kinh nghiệm của từng nhà phát triển cụ thể, kiến ​​​​thức của họ về sản phẩm hiện có và lịch sử phát triển của nó thường không thể thay thế hoặc khó bổ sung và tốn thời gian. Vì vậy, nếu bạn may mắn và đã có được một đội ngũ lập trình viên tuyệt vời, điều quan trọng là phải làm việc dựa trên động lực của họ. Thuê và đào tạo các nhà phát triển mới, thành lập một nhóm trong số họ gần như khó khăn và tốn thời gian như việc sinh con và nuôi con.

Hãy xem xét các yếu tố chính tạo động lực cho các lập trình viên (nhóm lập trình viên), sử dụng kim tự tháp Maslow để làm rõ ràng và cấu trúc cách trình bày. Nếu bạn chưa từng nghe nói đến kim tự tháp Maslow thì đó không phải là một lý thuyết không thể chối cãi nhưng rất phổ biến và mang tính minh họa của nhà tâm lý học người Mỹ Abraham Harold Maslow, người đã đề xuất một lý thuyết về động lực cá nhân dựa trên hệ thống phân cấp nhu cầu của con người (xem hình bên dưới).

Maslow sắp xếp các nhu cầu của cá nhân theo thứ bậc từ nhu cầu sinh lý đến nhu cầu phát triển tiềm năng và tự thể hiện. Một giả định quan trọng trong lý thuyết của Maslow là "một người không thể đáp ứng các nhu cầu ở cấp độ cao hơn cho đến khi các nhu cầu ở cấp độ thấp hơn của anh ta được thỏa mãn". Ví dụ, một người không thể bị thúc đẩy bởi nhu cầu kiến ​​​​thức hoặc nhu cầu thẩm mỹ nếu người này đã không ăn hoặc ngủ trong ba ngày.

Quản lý nhóm lập trình viên: làm thế nào và bằng cách nào để động viên họ đúng cách? Phần một

Trước khi đi vào chi tiết, hãy tập trung vào một thực tế hiển nhiên - một nhóm bao gồm mọi người, tất cả mọi người đều khác nhau, mỗi người có cấu trúc động lực riêng. Ngoài việc mỗi người bị thúc đẩy bởi những sở thích khác nhau, mỗi người còn có những điều kiện sống khác nhau. Ai đó đang bắt đầu sự nghiệp và đang nghĩ cách xây dựng nó, ai đó sắp kết hôn và ai đó muốn thành thạo một lĩnh vực chủ đề mới. Điều quan trọng đối với người này lại hoàn toàn không quan trọng đối với người khác, và ngày mai mọi thứ sẽ lại thay đổi. Để hiểu chính xác bối cảnh này, có một biện pháp khắc phục đơn giản - bạn cần suy nghĩ về nó và làm việc với nó. Điều quan trọng nhất là giao tiếp.
Hãy chắc chắn nói chuyện với nhóm của bạn về điều gì đó ngoài công việc, xây dựng các mối quan hệ thân mật.

Vì vậy, bây giờ chúng ta hãy cùng điểm qua kim tự tháp Maslow và xem xét các cấp độ của nó khi áp dụng vào việc quản lý một nhóm lập trình viên.

I: Nhu cầu sinh lý, sinh học:

Khi nói đến động lực làm việc, nhiều người thường nghĩ đến tiền lương trước hết. Trong trường hợp này, theo mức lương, ý tôi là một phần vĩnh viễn của gói bồi thường, không phụ thuộc vào kết quả dưới bất kỳ hình thức nào. Điều này không áp dụng cho tiền thưởng, tiền thưởng và chương trình khuyến mãi của công ty. Đó là mức lương mà tôi cho là do mức độ “nhu cầu sinh lý” trong trường hợp của chúng tôi. Tiền thưởng, tiền thưởng dựa trên hiệu suất, quyền chọn và cổ phiếu công ty - Tôi sẽ phân loại tất cả những thứ này ở các cấp độ khác.

Theo ý kiến ​​của tôi, dù nghe có vẻ kỳ lạ thế nào đi nữa thì mức lương cũng có thể cao hơn. làm mất động lực yếu tố chứ không phải là yếu tố thúc đẩy. Điều đặc biệt khi làm việc với các lập trình viên là họ đều là những người, thứ nhất, rất thông minh (một đặc điểm của nghề), thứ hai, có trình độ học vấn sâu rộng và/hoặc rộng rãi. Thông thường, các lập trình viên, ngoài chuyên môn, còn có sự hiểu biết sâu sắc về một hoặc nhiều lĩnh vực chuyên môn mà họ tạo ra sản phẩm. Ngoài ra, những lập trình viên giỏi còn quan tâm và hiểu rõ về lịch sử phát triển lập trình, các thuật toán, tiêu chuẩn,… Điều tương tự cũng áp dụng cho lĩnh vực chủ đề của họ. Đối với những người ở cấp độ này, tiền lương thường không phải là yếu tố thúc đẩy chính.

Đồng thời, theo cách hiểu của họ, việc thiếu một mức lương công bằng cho các lập trình viên sẽ làm mất động lực và làm mất động lực rất nhiều. Có một mức lương công bằng là tiêu chuẩn. Mức lương cao hơn nhiều so với định mức (thị trường) - kỳ lạ thay, đây cũng là một yếu tố khá kém hiệu quả. Một đồng nghiệp từng kể cho tôi nghe về một nhóm lập trình viên của một trong những công ty hoạt hình lớn của Mỹ, do một số hoàn cảnh mà họ nhận được mức lương cao gấp hai đến ba lần so với thị trường. Như anh ấy đã nói, anh ấy chưa bao giờ thấy nhiều lập trình viên buồn chán, lười biếng và mất động lực hơn trong đời. Việc tăng lương có thể tạo động lực trong ngắn hạn, nhưng sau vài tháng, mức lương mới trở thành tiêu chuẩn và không còn động lực nữa. Nói chung, tôi muốn nói rằng đối với các lập trình viên khi mới bắt đầu sự nghiệp, yếu tố tiền lương quan trọng hơn, khi họ trưởng thành và phát triển về mặt chuyên môn thì tầm quan trọng của nó giảm dần và các yếu tố khác bắt đầu chiếm ưu thế.

Điểm quan trọng thứ hai là sự cân bằng hợp lý về mức lương trong đội. Nếu một nhóm cảm thấy rằng sự đóng góp của một thành viên thấp hơn đáng kể nhưng mức thù lao vẫn như nhau, điều này sẽ làm mất đi động lực của toàn nhóm. Đôi khi các nhà quản lý bị cám dỗ đổ thêm tiền vào lửa - để giữ chân một người kiệt sức hoặc mất động lực bằng cách tăng lương của anh ta lên trên mức bình thường. Điều này thường chỉ tạo ra vấn đề về lâu dài - động lực của bản thân người đó sẽ không tăng nhiều, hoặc sẽ tăng trong vài tháng, nhưng động lực của những người còn lại trong nhóm sẽ giảm xuống. Trong những tình huống như vậy, đáng để tìm kiếm các cách tiếp cận khác, tất nhiên, trừ khi đây là một chuyên gia duy nhất cần được giữ lại bằng bất cứ giá nào, thậm chí trong một thời gian ngắn.

II. Nhu cầu về điều kiện sống an toàn, thoải mái, đồng bộ:

70 năm trước, sự hiện diện của bếp nấu trong ô tô có thể là yếu tố thúc đẩy khi chọn ô tô, khi đó nó vượt quá tiêu chuẩn và là dấu hiệu của sự sang trọng. Giờ đây, ngay cả việc không có điều hòa cũng là điều vô nghĩa, và sự hiện diện của nó tất nhiên sẽ không phải là yếu tố thúc đẩy khi chọn xe. Vì vậy, 10-15 năm trước, một văn phòng tiện lợi, phần cứng tốt, cà phê ngon, thể dục, giờ giấc linh hoạt, v.v. có thể là những yếu tố thúc đẩy tốt, nhưng giờ đây đây đã trở thành tiêu chuẩn cho công việc của một lập trình viên giỏi. Đồng thời, sự vắng mặt của họ sẽ lại làm mất đi động lực.

Một yếu tố làm giảm động lực quan trọng là thiếu khả năng tập trung và môi trường làm việc ồn ào. Công việc của một lập trình viên đòi hỏi sự im lặng và tập trung. Nếu không gian văn phòng không tạo cơ hội cung cấp cho các nhà phát triển một không gian làm việc tách biệt, thì ít nhất cần phải đảm bảo sự hợp tác thoải mái giữa những đồng nghiệp không gây trở ngại cho nhau. Tốt hơn hết hãy đoàn kết những đồng chí năng nổ và ồn ào lại với nhau, tạo cơ hội tập trung cho những người cần.

Chi phí thời gian của một lập trình viên hiện nay cao hơn đáng kể so với chi phí của phần cứng mà anh ta làm việc trên đó. Hai hoặc ba màn hình, máy tính mạnh mẽ, nơi làm việc thoải mái cho mọi nhà phát triển - phải là tiêu chuẩn ở bất kỳ công ty nào. Chủ đề này được đề cập rõ ràng trong một trong những bài viết của Joel Spolsky “Bài kiểm tra Joel: 12 bước để viết mã tốt hơn.”

Thành phần vật chất của sự thoải mái là cơ bản và đơn giản nhất, bây giờ hãy nói về phần còn lại.

Ở nhiều công ty, tiêu chuẩn dành cho lập trình viên là lịch làm việc linh hoạt và không có quy định về trang phục. Điều này là tốt và đúng nếu đặc thù công việc của nhóm cho phép (ví dụ: không có cuộc họp nào với khách hàng, chính trị gia hoặc chủ ngân hàng).

Điều quan trọng là phải có một khoảng thời gian cụ thể để toàn bộ nhóm làm việc cùng nhau tại địa phương để mọi người có thể giao tiếp và giải quyết các vấn đề trực tiếp. Về bản chất, một lập trình viên không rời bỏ công việc ngay cả sau giờ làm việc. Thông thường, các vấn đề trong công việc vẫn hiện lên trong tâm trí anh ấy bất kể anh ấy có mặt ở văn phòng hay không và những quyết định đúng đắn thường đến từ bên ngoài văn phòng. Với nhu cầu phải tốt (mà chúng ta sẽ thảo luận dưới đây), việc kiểm soát nhỏ nhặt sẽ có hại. Nó không chỉ làm mất động lực mà còn làm giảm năng suất. Thực tế cho thấy, nếu không có sự kiểm soát, một nhóm có động lực sẽ có nhiều khả năng làm việc lâu hơn mức cần thiết. Nếu có sự kiểm soát, các nhà phát triển có thể ngồi vào bàn phím từ chín đến sáu giờ, nhưng tôi nghĩ kết quả sẽ tệ hơn. Như người ta nói, một người có thể dẫn ngựa xuống nước, nhưng cả trăm người cũng sẽ không ép anh ta uống nếu anh ta không muốn.

Việc mô tả mức độ nhu cầu này cũng đề cập đến việc không bị lo lắng và sợ hãi, không có sự hỗn loạn và nhu cầu về cấu trúc và trật tự. Đây cũng là những điểm cực kỳ quan trọng, ảnh hưởng lớn đến không khí trong đội.

Thứ nhất, không có sự hỗn loạn, cấu trúc và trật tự - nhóm phải hiểu ai chịu trách nhiệm về việc gì, vai trò được phân bổ như thế nào, cần phải làm gì, cho ai, khi nào, những yêu cầu nào làm nền tảng cho sản phẩm, những kỳ vọng của ban quản lý và khách hàng... Hầu hết những điều này cần được mô tả chính thức, mọi thứ nên được thảo luận định kỳ. Nếu không thảo luận và sử dụng định kỳ, các mô tả sẽ không có tác dụng. Thực hành tốt là nên thảo luận định kỳ và cập nhật chúng dựa trên kết quả phân tích khám nghiệm tử thi sau khi phát hành.

Thứ hai, bầu không khí yên tĩnh và thân thiện. Tất cả chúng ta đều dành phần lớn thời gian tại nơi làm việc và chúng ta muốn làm việc đó mà không bị căng thẳng, xung đột hay sợ hãi. Nhóm phát triển thường làm việc dưới áp lực từ lịch trình và khách hàng. Không ai cần thêm căng thẳng từ đồng nghiệp và cấp trên. Bầu không khí trong nhóm, nói chung, việc một nhóm các nhà phát triển có thể được gọi và trở thành một “nhóm” là trách nhiệm trực tiếp và quan trọng của người quản lý, một trong những nhiệm vụ trung và dài hạn quan trọng nhất. Vì vậy, điều quan trọng là người quản lý phải làm việc, đặc biệt là với những xung đột trong nhóm và không để sự phát triển của họ diễn ra theo hướng tự nhiên. Quản lý xung đột là một chủ đề riêng biệt cần được nghiên cứu riêng.

Có hai cách chính để tác động đến trạng thái cảm xúc của nhóm và hành vi của đồng nghiệp (nếu có ai đó thêm vào nhận xét thì điều đó thật tuyệt). Đầu tiên là hành vi của chính bạn. Tấm gương cá nhân là cực kỳ quan trọng đối với người quản lý và nhóm. Như người ta nói, linh mục cũng vậy, việc đến cũng vậy. Hãy cư xử theo cách bạn mong đợi đồng nghiệp của mình sẽ cư xử. Thứ hai là khuyến khích hành vi đúng đắn và có thể nói là không khuyến khích hành vi sai trái. Giao tiếp với mọi người, đưa ra phản hồi cho họ, có nhiều cách để làm điều này. Nhìn chung, phản hồi là một chủ đề được thảo luận riêng; nó là một phần quan trọng và quan trọng trong việc làm việc có động lực.

Một lưu ý khác về bầu không khí, có vẻ bất thường, nhưng trên thực tế, nó rất quan trọng. Thông thường, trong nhóm phát triển có ít nữ hơn nam giới. Thường thì các nhóm hoàn toàn là nam giới. Trong những điều kiện như vậy, cũng đang trong tình trạng căng thẳng, đôi khi ngôn ngữ tục tĩu bắt đầu được sử dụng trong đội. Thực tế cho thấy điều này có tác động tiêu cực đến bầu không khí, giao tiếp dần trở nên thô lỗ. Bạn nên tránh sử dụng nó cho chính mình và không khuyến khích sử dụng nó trong nhóm của bạn.

Các nhóm phát triển thường được gọi là R&D (nghiên cứu và phát triển), trong đó nghiên cứu chiếm một phần quan trọng trong công việc. Đây là phần thường khó lập kế hoạch và lập kế hoạch, nếu không thì sẽ không phải là phần nghiên cứu. Điều quan trọng là nhóm có quyền mắc sai lầm, chủ động, thử các phương án khác nhau có thể dẫn đến thành công hoặc không. Sai lầm là một phần bình thường của công việc, chúng không thể tránh khỏi, nhưng bạn có thể nghiên cứu, phân tích, học hỏi từ chúng cho tương lai và tiếp tục. Nguyên tắc 5 Tại sao, bắt nguồn từ Toyota, là một cách hay để tìm ra nguyên nhân gốc rễ của vấn đề. Trừng phạt lỗi lầm là một cách tuyệt vời để tạo ra bầu không khí sợ hãi và bất an. Ngoại lệ duy nhất là khi dựa trên kết quả phân tích, hóa ra lỗi là do thái độ làm việc thiếu chuyên nghiệp, trong trường hợp này có thể cần phải đưa ra các quyết định về nhân sự.

Bầu không khí trong nhóm bị ảnh hưởng rất nhiều bởi sự mong đợi và trạng thái cảm xúc của bạn trước khi cuộc trò chuyện bắt đầu. Trước khi bắt đầu một cuộc thảo luận khó khăn, một cuộc trao đổi nào đó hoặc chỉ là một cuộc trò chuyện đầy cảm xúc, tâm trạng và thái độ của bạn đối với người mà bạn sắp nói chuyện là rất quan trọng. Theo mặc định, tôi luôn tin tưởng và hành động dựa trên những gì người đó chân thành cố gắng làm tốt nhất. Nếu từ vị trí của bạn có vẻ như không phải như vậy, bạn cần phải bình tĩnh và tìm hiểu chi tiết bối cảnh và hiểu điều gì anh ấy đã làm đúng, tại sao anh ấy cho rằng điều đó là đúng và kỳ vọng của chúng ta khác nhau ở đâu. Thông thường, hóa ra chúng không thực sự khác nhau, chỉ là tầm nhìn của anh ấy về bối cảnh đầy đủ hơn hoặc mới mẻ hơn và có điều gì đó mà bạn chưa biết. Hoặc ngược lại, anh ta không biết điều gì đó. Điều này đặc biệt quan trọng trong một nhóm phân tán, khi mọi người ít giao tiếp trực tiếp hơn và sử dụng email cũng như tin nhắn tức thời. Điều này thậm chí còn quan trọng hơn trong một nhóm bao gồm các lập trình viên đến từ các quốc gia khác nhau và phân bổ ở các múi giờ khác nhau. Đây là lúc sự khác biệt về văn hóa bắt đầu đóng một vai trò lớn.

Trong hoàn cảnh khó khăn, việc lái xe qua khi đang di chuyển thì dễ, rất dễ, nhưng việc lái xe về lại khó khăn, cặn bã đọng lại rất lâu. Hãy để tôi cho bạn một ví dụ đơn giản từ kinh nghiệm gần đây. Một trong những người quản lý nhóm rất cần nhận xét về một số vấn đề với khách hàng từ người quản lý của một nhóm liên quan ở quốc gia khác. Anh ta ping một đồng nghiệp trong tin nhắn, đợi 15 phút, ping lại, rồi 15 phút sau anh ta vào một cuộc trò chuyện lớn có cả những người quản lý khác, và tấn công nhẹ đồng nghiệp đó với câu nói như: “vì bạn không có thể bằng lòng trả lời tôi, và câu hỏi này không quá khẩn cấp?” Cuối cùng, hóa ra người đưa tin của công ty chúng tôi hơi buồn tẻ và đồng nghiệp không nhìn thấy câu hỏi nào cả. Tôi đã phải xin lỗi. Nói chung, tốt hơn là nên bắt đầu với những điều tốt đẹp. Bạn luôn có thể mắc sai lầm nghiêm trọng và gặp rắc rối sau này; điều đó không có vấn đề gì cả (mặc dù bạn không nên làm vậy). Nói chung, trong hơn 20 năm làm việc trong ngành của chúng tôi, tôi chỉ gặp một đồng nghiệp thực sự độc ác một lần (!). May mắn thay, chúng tôi chia tay khá nhanh. Hóa ra là đúng trong phần lớn các trường hợp khi cho rằng đồng nghiệp muốn điều tốt nhất, theo sự hiểu biết tốt nhất của họ về bối cảnh.

Nhiệm vụ của bạn với tư cách là người quản lý là đảm bảo đồng bộ hóa bối cảnh, hiểu biết chung về kỳ vọng, yêu cầu, thời hạn và tiêu chuẩn được chấp nhận trong nhóm. Những điều này tưởng chừng như là những điều nhỏ nhặt nhưng bầu không khí trong nhóm được xây dựng chính xác từ những điều nhỏ nhặt như vậy. Từ góc độ nhóm phân tán, một trong những nhiệm vụ quan trọng là đảm bảo rằng các thành viên trong nhóm được giao tiếp trực tiếp định kỳ. Tôi đã hơn một lần nghe các lập trình viên nói rằng, chẳng hạn như sau khi các kỹ sư từ nhóm hỗ trợ đến gặp họ và trực tiếp làm việc cùng nhau, họ vui vẻ ở lại làm việc để đích thân giúp đỡ Pasha, người mới đến gặp họ trong một trường hợp khó khăn, mặc dù trước đó Pasha chỉ là một biểu tượng trong sứ giả, và sẽ không có ai dừng lại vì biểu tượng đó.

Nhân tiện, tôi bắt đầu nói về nhóm hỗ trợ và nhớ lại một ví dụ kinh điển cho tôi. Một lần, một khách hàng ở Mỹ gặp sự cố với sản phẩm, một trong những kỹ sư trong nhóm hỗ trợ thực hiện công việc của anh ấy (biệt phái từ Nga) đã ở lại sau giờ làm để giúp đỡ nhưng vấn đề không được giải quyết và không được giải quyết. Nói chung là anh nán lại và ngồi đó gần như tới tận sáng. Tại thời điểm này, người quản lý của khách hàng đã báo cáo vấn đề lên cấp cao hơn, xác định mức độ nghiêm trọng của nó đối với họ và rời khỏi công việc vào buổi tối. Quá trình leo thang đã bắt đầu có động lực ở một múi giờ khác, các nhà quản lý hỗ trợ ở Nga bắt đầu cố gắng giúp đỡ, do một số khó khăn nhất định trong giao tiếp với văn phòng khách hàng (VPN, sự cố kết nối, khó khăn khi gọi giữa các quốc gia, ...) họ không biết rằng anh chàng này đã ở trong văn phòng và giải quyết vấn đề và cố gắng tìm kiếm anh ta. Họ chỉ tìm thấy nó vào buổi sáng (Mỹ), khi vấn đề gần như đã được giải quyết và sản phẩm đang hoạt động. Ngay lập tức họ bắt đầu nói rằng cái quái gì vậy, khách hàng đang leo thang như vậy, không có gì hiệu quả, bạn ở đâu, chúng tôi không thể tìm thấy bạn, v.v. Không cần phải nói, hậu quả của hành vi như vậy là anh chàng đã bị mất tinh thần rất nhiều. Tổ chức công việc của một nhóm phân tán là một chủ đề lớn riêng biệt, nhưng điều quan trọng cần nhớ là hai điều. Thứ nhất, giao tiếp và bầu không khí rất quan trọng, sự thành công của công việc phụ thuộc vào nó. Thứ hai, việc này tự nó không có tác dụng, nó phải được giải quyết một cách riêng biệt và chuyên sâu.

Một điểm quan trọng khác liên quan đến mức độ nhu cầu này là tiền lương. Không phải là mức lương như vậy mà là sự hiện diện của một quy trình nhất định để thay đổi nó. Công ty phải có cách tiếp cận để xác định yêu cầu đối với các vị trí ở các cấp độ khác nhau. Mỗi nhà phát triển phải có thể thảo luận về những kỳ vọng đối với công việc của họ với công ty, hiểu cách thức và thời điểm những nỗ lực của họ có thể ảnh hưởng đến mức lương của họ. Các cuộc họp định kỳ với người quản lý, đánh giá hiệu suất nửa năm hoặc hàng năm phục vụ mục đích này. Một lần nữa, đây là một trong những khoảnh khắc mà sự hiện diện của chúng không tạo động lực rõ ràng, nhưng sự vắng mặt của chúng khiến chúng ta mất động lực rất nhiều.

Từ nhu cầu trật tự và sự hiện diện của các quy tắc, kéo theo nhu cầu tuân thủ các quy tắc này, tuân theo các quy tắc được chấp nhận trong nhóm, cả chính thức và không chính thức. Nói chung, tôi gọi đó là nhu cầu “trở nên tốt”. Sự hiện diện của nhu cầu này khẳng định rằng việc quản lý vi mô là không cần thiết mà còn có hại. Chỉ cần cung cấp cho một người mọi thứ cần thiết cho công việc, cung cấp cho anh ta kiến ​​​​thức về bối cảnh, các ưu tiên và mang lại quyền tự do hành động và ra quyết định ở cấp độ của anh ta là đủ. Trong điều kiện như vậy, anh ta sẽ cảm thấy tin tưởng, có cơ hội tự mình đưa ra quyết định, chịu trách nhiệm về chúng và có thể bộc lộ tiềm năng của mình.

Một điểm quan trọng khác cần được cho là cần có trật tự và không có sự hỗn loạn là khả năng tập trung vào một nhiệm vụ, không có sự chuyển đổi bối cảnh thường xuyên. Trở thành một lập trình viên đòi hỏi thời gian và sự tập trung. Các lập trình viên thực sự không muốn vội vàng từ bỏ một nhiệm vụ và chuyển sang nhiệm vụ khác. Một phần công việc cần thiết của lập trình viên thường không chỉ là phát triển mã thực tế mà còn sửa lỗi và hỗ trợ xử lý các yêu cầu từ khách hàng. Cần lập kế hoạch trước cho những việc như vậy, theo cách cho phép lập trình viên bình tĩnh và hoàn thành đầy đủ công việc của một nhiệm vụ trước khi chuyển sang nhiệm vụ khác. Lựa chọn tốt nhất là cho bản thân cơ hội tự lập kế hoạch cho công việc của mình, xác định trước các ưu tiên và nhiệm vụ sắp tới, phân bổ khoảng thời gian dài, kéo dài để làm một loại nhiệm vụ. Chủ đề này được mô tả rất rõ trong cuốn sách “Google - Kỹ thuật về độ tin cậy của trang web”, mô tả rõ ràng các phương pháp lập kế hoạch công việc của các nhóm đảm bảo vận hành và phát triển các hệ thống lớn, chịu tải cao, có khả năng chịu lỗi cũng như các kỹ sư có nghề nghiệp kết hợp phát triển phần mềm và hỗ trợ phần mềm.

Để được tiếp tục ...

Nguồn: www.habr.com

Thêm một lời nhận xét