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à phần thứ hai trong bài viết 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 thù trong việc thúc đẩy các lập trình viên. Phần đầu tiên của bài viết có thể được tìm thấy ở đây -
Trong phần đầu tiên của bài viết, tôi đã đề cập đến hai cấp độ thấp hơn của kim tự tháp Maslow: nhu cầu sinh lý, nhu cầu an toàn, thoải mái và ổn định và chuyển sang cấp độ tiếp theo, cấp độ thứ ba, cụ thể là:
III - Nhu cầu được thuộc về và yêu thương
Tôi biết rằng mafia Ý được gọi là “Cosa Nostra”, nhưng tôi rất ấn tượng khi biết “Cosa Nostra” được dịch như thế nào. “Cosa Nostra” dịch từ tiếng Ý có nghĩa là “Việc kinh doanh của chúng tôi”. Việc chọn tên rất thành công vì động lực (hãy bỏ nghề nghiệp sang một bên, trong trường hợp này chúng ta chỉ quan tâm đến động lực). Một người thường muốn trở thành thành viên của một nhóm, để thực hiện một số công việc kinh doanh lớn, chung của chúng tôi.
Tầm quan trọng lớn được đặt vào việc thỏa mãn nhu cầu thuộc về và tình yêu trong quân đội, hải quân và bất kỳ đội hình bán quân sự lớn nào. Và, như chúng ta thấy, trong mafia. Điều này có thể hiểu được, bởi vì bạn cần ép buộc những người có ít điểm chung, những người ban đầu không thành lập một đội gồm những người cùng chí hướng, những người được tập hợp lại với nhau bằng nghĩa vụ quân sự (không phải tự nguyện), những người có trình độ học vấn khác nhau, những giá trị cá nhân khác nhau. , theo đúng nghĩa đen là cống hiến cuộc đời mình, bất chấp nguy hiểm chết người, cho một mục đích chung nào đó, giao phó mạng sống của mình cho một người đồng đội trong tay.
Đây là một động lực rất mạnh mẽ; đối với hầu hết mọi người, điều cực kỳ quan trọng là cảm thấy họ thuộc về một điều gì đó lớn lao hơn, biết rằng bạn là thành viên của một gia đình, một đất nước, một đội. Trong quân đội, quân phục, nhiều nghi lễ, diễu hành, tuần hành, biểu ngữ, v.v. đều phục vụ những mục đích này. Hầu như các yếu tố giống nhau đều quan trọng đối với bất kỳ đội nào. Biểu tượng, thương hiệu công ty và màu sắc công ty, đồ dùng và quà lưu niệm rất quan trọng.
Điều quan trọng là các sự kiện quan trọng đều có biểu hiện hữu hình của riêng chúng mà chúng có thể được liên kết. Ngày nay, việc một công ty có hàng hóa, áo khoác, áo phông, v.v. là điều bình thường. Nhưng điều quan trọng nữa là phải làm nổi bật đội ngũ trong công ty. Chúng tôi thường phát hành áo phông dựa trên kết quả phát hành và trao cho tất cả những người tham gia phát hành. Một số sự kiện, lễ kỷ niệm chung hoặc hoạt động với cả nhóm là một yếu tố quan trọng khác của động lực.
Ngoài các thuộc tính bên ngoài, một số yếu tố khác cũng ảnh hưởng đến cảm giác thuộc về một nhóm.
Thứ nhất, sự hiện diện của một mục tiêu chung mà mọi người đều hiểu và chia sẻ đánh giá về tầm quan trọng của nó. Các lập trình viên thường muốn hiểu rằng họ đang làm một điều tuyệt vời và họ đang làm điều tuyệt vời này cùng nhau với tư cách là một nhóm.
Thứ hai, nhóm phải có một không gian liên lạc trong đó cả nhóm có mặt và chỉ thuộc về nhóm đó (ví dụ: cuộc trò chuyện trong trình nhắn tin, đồng bộ nhóm định kỳ). Ngoài các vấn đề công việc, giao tiếp thân mật, đôi khi là thảo luận về các sự kiện bên ngoài, ánh sáng ngoài trời - tất cả những điều này tạo ra cảm giác cộng đồng và tập thể.
Thứ ba, tôi sẽ nhấn mạnh việc áp dụng các phương pháp thực hành kỹ thuật tốt trong nhóm, mong muốn nâng cao các tiêu chuẩn so với những tiêu chuẩn được chấp nhận trong công ty. Việc triển khai các phương pháp tiếp cận tốt nhất được chấp nhận trong ngành, đầu tiên là trong nhóm, sau đó là trong toàn công ty, mang lại cho nhóm cơ hội cảm thấy rằng mình đang đi trước những người khác theo một cách nào đó, dẫn đầu, điều này tạo ra cảm giác thân thuộc đến một đội tuyệt vời.
Cảm giác thuộc về cũng bị ảnh hưởng bởi sự tham gia của nhóm vào việc lập kế hoạch và quản lý. Khi các thành viên trong nhóm tham gia thảo luận về mục tiêu dự án, kế hoạch làm việc, tiêu chuẩn nhóm và thực tiễn kỹ thuật cũng như phỏng vấn nhân viên mới, họ sẽ phát triển ý thức tham gia, quyền sở hữu chung và ảnh hưởng đến công việc. Mọi người sẵn sàng thực hiện các quyết định do chính họ đưa ra và lên tiếng hơn so với những quyết định do người khác đề xuất, ngay cả khi chúng thực sự đồng điệu.
Sinh nhật, ngày kỷ niệm, sự kiện quan trọng trong cuộc đời đồng nghiệp - một chiếc bánh pizza chung, một món quà nhỏ của tập thể mang lại cảm giác gắn bó và biết ơn nồng nhiệt. Ở một số công ty, người ta có phong tục tặng những tấm biển tưởng niệm nhỏ cho 5, 10, 15 năm làm việc trong công ty. Một mặt, tôi không nghĩ rằng điều này thúc đẩy tôi nhiều đến những thành tựu mới. Nhưng rõ ràng là hầu hết mọi người sẽ hài lòng vì họ vẫn chưa quên anh ấy. Đây là một trong những trường hợp mà sự vắng mặt của một sự kiện sẽ làm giảm động lực hơn là sự hiện diện của nó tạo động lực. Đồng ý rằng, có thể khá xấu hổ nếu LinkedIn nhắc nhở bạn vào buổi sáng và chúc mừng bạn nhân kỷ niệm 10 năm làm việc tại nơi làm việc, nhưng không một đồng nghiệp nào trong công ty chúc mừng hay nhớ đến bạn.
Tất nhiên, một điểm quan trọng là sự thay đổi thành phần của đội. Rõ ràng là ngay cả khi việc đến hoặc rời đi của một người nào đó trong nhóm được thông báo trước (ví dụ: trong bản tin của công ty hoặc nhóm, hoặc tại một cuộc họp nhóm), điều này không đặc biệt thúc đẩy bất kỳ ai đạt được những thành tựu mới. Nhưng nếu một ngày đẹp trời bạn nhìn thấy một người mới bên cạnh mình hoặc không gặp một người cũ, đó có thể là một điều bất ngờ, và nếu bạn rời đi, điều đó sẽ hết sức khó chịu. Mọi người không nên biến mất một cách lặng lẽ. Đặc biệt là trong một nhóm phân tán. Đặc biệt nếu công việc của bạn phụ thuộc vào một đồng nghiệp ở văn phòng khác đột nhiên xuất hiện và biến mất. Những khoảnh khắc như vậy chắc chắn đáng để thông báo trước cho nhóm.
Một yếu tố quan trọng mà trong tiếng Anh gọi là quyền sở hữu (bản dịch theo nghĩa đen của “sở hữu” không phản ánh đầy đủ ý nghĩa của nó). Đây không phải là cảm giác sở hữu mà là cảm giác trách nhiệm đối với dự án của bạn, cảm giác đó khi bạn liên kết bản thân một cách tình cảm với sản phẩm và sản phẩm với chính mình. Điều này gần tương ứng với lời cầu nguyện của người lính thủy đánh bộ trong bộ phim “Full Metal Jacket”: “Đây là súng trường của tôi. Có rất nhiều khẩu súng trường như vậy, nhưng khẩu này là của tôi. Súng trường của tôi là người bạn tốt nhất của tôi. Cô ấy là cuộc sống của tôi. Tôi phải học cách sở hữu nó giống như cách tôi sở hữu cuộc sống của mình. Không có tôi, khẩu súng của tôi trở nên vô dụng. Tôi thật vô dụng nếu không có khẩu súng trường của mình. Tôi phải bắn thẳng khẩu súng trường của mình. Tôi phải bắn chính xác hơn kẻ thù đang cố giết tôi. Tôi phải bắn hắn trước khi hắn bắn tôi. Hãy để nó như vậy..."
Khi một người làm việc trên một sản phẩm trong thời gian dài, có cơ hội chịu hoàn toàn trách nhiệm về sự sáng tạo và phát triển của nó, để xem một sản phẩm hoạt động phát sinh từ “không có gì”, cách mọi người sử dụng nó, cảm giác mạnh mẽ này sẽ nảy sinh. Các nhóm sản phẩm làm việc cùng nhau trong thời gian dài trong một dự án thường có động lực và gắn kết hơn các nhóm được tập hợp trong thời gian ngắn và làm việc trong chế độ dây chuyền lắp ráp, chuyển từ dự án này sang dự án khác, không chịu trách nhiệm hoàn toàn cho toàn bộ sản phẩm. , từ lúc bắt đầu đến khi kết thúc.
IV. Cần sự công nhận
Một lời nói tử tế cũng làm hài lòng con mèo. Mọi người đều được thúc đẩy bởi sự thừa nhận tầm quan trọng của công việc họ đã làm và đánh giá tích cực về nó. Nói chuyện với các lập trình viên, đưa ra phản hồi định kỳ cho họ, khen ngợi một công việc được hoàn thành tốt. Nếu bạn có một nhóm lớn và phân tán, các cuộc họp định kỳ (được gọi là XNUMX-XNUMX) là hoàn hảo cho việc này; nếu nhóm rất nhỏ và làm việc cùng nhau ở địa phương, cơ hội này thường được cung cấp mà không cần các cuộc họp đặc biệt theo lịch (mặc dù các cuộc họp định kỳ với một là tất cả. Nó vẫn cần thiết, bạn chỉ có thể làm điều đó ít thường xuyên hơn). Chủ đề này được đề cập đầy đủ trong các podcast dành cho người quản lý trên manager-tools.com.
Tuy nhiên, cần ghi nhớ sự khác biệt về văn hóa. Một số cách tiếp cận quen thuộc với các đồng nghiệp Mỹ không phải lúc nào cũng hiệu quả với các đồng nghiệp Nga. Mức độ lịch sự được chấp nhận trong giao tiếp hàng ngày trong các nhóm ở các nước phương Tây ban đầu có vẻ quá mức đối với các lập trình viên đến từ Nga. Một số đặc điểm thẳng thắn của đồng nghiệp Nga có thể bị đồng nghiệp từ các quốc gia khác coi là thô lỗ. Điều này rất quan trọng trong giao tiếp trong một nhóm đa sắc tộc, đã có rất nhiều bài viết về chủ đề này, người quản lý của một nhóm như vậy phải nhớ điều này.
Trình diễn tính năng, trong đó các lập trình viên hiển thị các tính năng được phát triển trong quá trình chạy nước rút, là một phương pháp hay để hiện thực hóa nhu cầu này. Ngoài việc đây là cơ hội tuyệt vời để xóa các kênh liên lạc giữa các nhóm, giới thiệu cho người quản lý sản phẩm và người thử nghiệm các tính năng mới, đây còn là cơ hội tốt để các nhà phát triển thể hiện kết quả công việc của họ và cho biết quyền tác giả của họ. Tất nhiên, và trau dồi kỹ năng nói trước công chúng của bạn, điều này không bao giờ có hại.
Sẽ là một ý kiến hay nếu tôn vinh sự đóng góp đáng kể của những đồng nghiệp đặc biệt xuất sắc bằng các bằng chứng nhận, tấm biển tưởng niệm (ít nhất là một lời nói tử tế) tại các buổi gặp mặt chung của nhóm. Mọi người thường rất coi trọng những giấy chứng nhận và bảng hiệu tưởng niệm như vậy, mang theo bên mình khi di chuyển và thường giữ gìn chúng bằng mọi cách có thể.
Để đánh dấu sự đóng góp lâu dài, có ý nghĩa hơn cho công việc của nhóm, kinh nghiệm và chuyên môn tích lũy được, một hệ thống cấp bậc thường được sử dụng (một lần nữa, có thể rút ra sự tương tự với hệ thống cấp bậc quân sự trong quân đội, ngoài ra, để đảm bảo sự phụ thuộc, cũng phục vụ mục đích này). Thông thường, các nhà phát triển trẻ làm việc chăm chỉ gấp đôi để có được những ngôi sao mới trên vai họ (tức là chuyển từ nhà phát triển cấp dưới sang nhà phát triển toàn thời gian, v.v.).
Biết được kỳ vọng của mọi người là rất quan trọng. Một số có nhiều khả năng bị thúc đẩy bởi điểm cao, cơ hội được gọi là kiến trúc sư, trong khi những người khác, ngược lại, thờ ơ với cấp bậc và chức danh và sẽ coi việc tăng lương là một dấu hiệu công nhận từ công ty . Giao tiếp với mọi người để hiểu họ muốn gì và mong đợi gì.
Có thể thể hiện sự công nhận, mức độ tin cậy cao hơn từ phía nhóm, bằng cách trao nhiều quyền tự do hành động hơn hoặc tham gia vào các lĩnh vực công việc mới. Ví dụ, sau khi có được kinh nghiệm nhất định và đạt được kết quả nhất định, một lập trình viên, ngoài việc triển khai các tính năng của mình theo đặc tả, còn có thể làm việc trên kiến trúc của những thứ mới. Hoặc tham gia vào các lĩnh vực mới có thể không liên quan trực tiếp đến phát triển - tự động hóa thử nghiệm, triển khai các phương pháp kỹ thuật tốt nhất, hỗ trợ quản lý phát hành, phát biểu tại hội nghị, v.v.
V. Nhu cầu nhận thức và tự thể hiện.
Nhiều lập trình viên tập trung vào các loại hoạt động lập trình khác nhau ở các giai đoạn khác nhau trong cuộc đời của họ. Một số người thích học máy, phát triển các mô hình dữ liệu mới, đọc nhiều tài liệu khoa học cho công việc và tạo ra thứ gì đó mới từ đầu. Một cách khác gần hơn với việc gỡ lỗi và hỗ trợ một ứng dụng hiện có, trong đó bạn cần tìm hiểu sâu về mã hiện có, nghiên cứu nhật ký, dấu vết ngăn xếp và hình ảnh xác thực mạng trong nhiều ngày và nhiều tuần và hầu như không viết mã mới.
Cả hai quá trình đều đòi hỏi nỗ lực trí tuệ rất lớn, nhưng kết quả thực tế của chúng lại khác nhau. Người ta tin rằng các lập trình viên không muốn hỗ trợ các giải pháp hiện có; họ khá có động lực để phát triển những giải pháp mới. Có một chút khôn ngoan trong việc này. Mặt khác, nhóm đoàn kết và năng động nhất mà tôi từng làm việc cùng đã tận tâm hỗ trợ một sản phẩm hiện có, tìm và sửa lỗi sau khi nhóm hỗ trợ liên hệ với họ. Các chàng trai thực sự sống vì công việc này và sẵn sàng ra ngoài vào thứ bảy và chủ nhật. Chúng ta từng háo hức giải quyết một vấn đề cấp bách và phức tạp khác, vào tối ngày 31/1 hoặc chiều ngày XNUMX/XNUMX.
Một số yếu tố ảnh hưởng đến động lực cao này. Thứ nhất, đó là một công ty có tên tuổi lớn trong ngành, đội ngũ liên kết với nó (xem “Nhu cầu liên kết”). Thứ hai, họ là biên giới cuối cùng, không có ai đứng sau họ, không có đội sản phẩm vào thời điểm đó. Giữa họ và khách hàng có hai cấp độ hỗ trợ, nhưng nếu vấn đề đến với họ thì không còn nơi nào để rút lui, không có ai đứng sau họ, toàn bộ tập đoàn đều dồn vào họ (bốn lập trình viên trẻ). Thứ ba, công ty lớn này có những khách hàng rất lớn (chính phủ các nước, các công ty ô tô và hàng không, v.v.) và các cơ sở lắp đặt quy mô rất lớn ở một số quốc gia. Kết quả là luôn có những bài toán phức tạp, thú vị, những bài toán đơn giản đều được giải quyết nhờ sự hỗ trợ của các cấp độ trước. Thứ tư, động lực của nhóm bị ảnh hưởng rất nhiều bởi trình độ chuyên môn của nhóm hỗ trợ mà họ tương tác (có những kỹ sư rất giàu kinh nghiệm và có năng lực về mặt kỹ thuật) và chúng tôi luôn tin tưởng vào chất lượng dữ liệu họ chuẩn bị, phân tích mà họ thực hiện , vân vân. Thứ năm, và tôi nghĩ đây là điểm quan trọng nhất - đội còn rất trẻ, tất cả các chàng trai đều mới bắt đầu sự nghiệp. Họ quan tâm đến việc nghiên cứu một sản phẩm lớn và phức tạp, giải quyết các vấn đề nghiêm trọng mới đối với họ trong một môi trường mới, họ tìm cách phù hợp với trình độ của các nhóm, vấn đề và khách hàng xung quanh một cách chuyên nghiệp. Dự án hóa ra là một ngôi trường xuất sắc, mọi người sau đó đều có sự nghiệp tốt trong công ty và trở thành lãnh đạo kỹ thuật và quản lý cấp cao, một người hiện là giám đốc kỹ thuật tại Amazon Web Services, người còn lại cuối cùng đã chuyển sang Google, và tất cả trong số họ vẫn nhớ về dự án này một cách ấm áp.
Nếu nhóm này bao gồm các lập trình viên có 15-20 năm kinh nghiệm thì động lực sẽ khác. Tất nhiên, tuổi tác và kinh nghiệm không phải là yếu tố quyết định 100%; tất cả phụ thuộc vào cấu trúc của động lực. Trong trường hợp cụ thể này, mong muốn hiểu biết và phát triển của các lập trình viên trẻ đã mang lại kết quả xuất sắc.
Nói chung, như chúng tôi đã đề cập nhiều lần, bạn phải biết kỳ vọng của các lập trình viên của mình, hiểu ai trong số họ muốn mở rộng hoặc thay đổi lĩnh vực hoạt động của mình và tính đến những kỳ vọng này.
Ngoài kim tự tháp của Maslow: khả năng hiển thị kết quả, trò chơi và cạnh tranh, không nhảm nhí
Có ba điểm quan trọng hơn liên quan đến động lực của các lập trình viên chắc chắn cần được đề cập, nhưng việc đưa họ vào mô hình nhu cầu của Maslow sẽ quá giả tạo.
Đầu tiên là khả năng hiển thị và độ gần của kết quả.
Phát triển phần mềm thường là một cuộc chạy marathon. Kết quả của những nỗ lực R&D sẽ được thể hiện rõ sau nhiều tháng, đôi khi nhiều năm. Thật khó để đi đến một mục tiêu xa xôi, khối lượng công việc khủng khiếp, mục tiêu xa vời, không rõ ràng và không nhìn thấy được, “đêm tối và đầy kinh hoàng”. Tốt hơn là nên chia con đường đến nó thành nhiều phần, tạo một con đường đến cái cây gần nhất mà có thể nhìn thấy được, có thể tiếp cận được, đường nét rõ ràng và nó không cách xa chúng ta - và đi đến mục tiêu gần gũi này. Chúng ta muốn nỗ lực trong vài ngày hoặc vài tuần, nhận và đánh giá kết quả, sau đó tiếp tục. Do đó, nên chia công việc thành nhiều phần nhỏ (các sprint trong Agile phục vụ tốt cho mục đích này). Chúng ta đã hoàn thành một phần công việc - ghi lại, thở ra, thảo luận, trừng phạt kẻ có tội, khen thưởng người vô tội - chúng ta có thể bắt đầu chu kỳ tiếp theo.
Động lực này ở một mức độ nào đó tương tự như những gì người chơi trải nghiệm khi hoàn thành trò chơi trên máy tính: họ định kỳ nhận được huy chương, điểm, tiền thưởng khi hoàn thành mỗi cấp độ; điều này có thể được gọi là “động lực dopamine”.
Đồng thời, khả năng hiển thị của kết quả thực sự quan trọng. Một tính năng đã đóng trong danh sách sẽ chuyển sang màu xanh lục. Nếu mã được viết, kiểm tra, phát hành nhưng không có thay đổi nào về trạng thái hình ảnh mà người lập trình có thể nhìn thấy, anh ta sẽ cảm thấy chưa hoàn thiện và không có cảm giác hoàn thành. Tại một trong các nhóm trong hệ thống kiểm soát phiên bản của chúng tôi, mỗi bản vá đều trải qua ba giai đoạn liên tiếp - bản dựng được lắp ráp và các thử nghiệm đã vượt qua, bản vá đã vượt qua quá trình xem xét mã, bản vá đã được hợp nhất. Mỗi giai đoạn được đánh dấu trực quan bằng dấu tích màu xanh lá cây hoặc chữ thập đỏ. Có lần một trong những nhà phát triển phàn nàn rằng việc xem xét mã mất quá nhiều thời gian, đồng nghiệp cần tăng tốc, các bản vá bị treo trong vài ngày. Tôi hỏi, điều này thực sự thay đổi điều gì đối với anh ấy? Suy cho cùng, khi viết code, build xong và test đã pass, anh ta không cần để ý đến bản vá đã gửi nếu không có ý kiến. Bản thân các đồng nghiệp sẽ xem xét và phê duyệt (nếu không có ý kiến gì). Anh ấy trả lời: “Igor, tôi muốn nhận được ba con ve xanh của mình càng sớm càng tốt.”
Điểm thứ hai là gamification và cạnh tranh.
Khi phát triển một trong các sản phẩm, nhóm kỹ thuật của chúng tôi đã đặt mục tiêu chiếm được vị trí nổi bật trong cộng đồng của một trong những sản phẩm nguồn mở, để lọt vào top 3. Vào thời điểm đó, không có cách nào khách quan để đánh giá mức độ hiển thị của ai đó trong cộng đồng; mỗi công ty lớn tham gia có thể tuyên bố (và tuyên bố định kỳ) rằng họ là người đóng góp số một, nhưng không có cách nào thực sự để so sánh sự đóng góp của những người tham gia với nhau, để đánh giá động lực của nó kịp thời. Theo đó, không có cách nào để đặt ra mục tiêu cho đội mà có thể đo lường được ở một số con vẹt, đánh giá mức độ thành tích của nó, v.v. Để giải quyết vấn đề này, nhóm của chúng tôi đã phát triển một công cụ đo lường và trực quan hóa sự đóng góp của các công ty và cá nhân đóng góp . Từ quan điểm động lực, hóa ra nó chỉ là một quả bom. Không chỉ các kỹ sư và nhóm liên tục theo dõi tiến trình của họ cũng như tiến trình của đồng nghiệp và đối thủ cạnh tranh. Ban lãnh đạo cấp cao của công ty chúng tôi và tất cả các đối thủ cạnh tranh lớn cũng bắt đầu ngày mới với stackalytics. Mọi thứ trở nên rất minh bạch và trực quan, mọi người có thể theo dõi cẩn thận tiến độ của mình, so sánh với đồng nghiệp, v.v. Việc đặt mục tiêu đã trở nên thuận tiện và dễ dàng hơn cho các kỹ sư, nhà quản lý và nhóm.
Một điểm quan trọng nảy sinh khi triển khai bất kỳ hệ thống số liệu định lượng nào là ngay sau khi bạn triển khai chúng, hệ thống sẽ tự động cố gắng ưu tiên đạt được các số liệu định lượng này, gây bất lợi cho các số liệu định tính. Ví dụ: số lượng đánh giá mã đã hoàn thành được sử dụng làm một trong các số liệu. Rõ ràng, việc xem xét mã có thể được thực hiện theo nhiều cách khác nhau, bạn có thể dành vài giờ để xem xét và kiểm tra kỹ lưỡng một bản vá phức tạp bằng cách kiểm tra các bài kiểm tra, chạy nó trên băng ghế dự bị của bạn, kiểm tra bằng tài liệu và nhận thêm một đánh giá về nghiệp của bạn, hoặc nhấp chuột một cách mù quáng vào vài chục bản vá lỗi trong vài phút, cho mỗi bản vá +1 và nhận thêm hai mươi nghiệp chướng. Có những trường hợp hài hước khi các kỹ sư nhấp vào các bản vá nhanh đến mức họ +1 cho các bản vá tự động từ hệ thống CI. Như sau này chúng tôi đã nói đùa, “đi, đi, jenkins.” Trong trường hợp của các cam kết, cũng có nhiều người đã xem qua mã bằng các công cụ định dạng mã, chỉnh sửa nhận xét, thay đổi dấu chấm thành dấu phẩy và do đó đã tăng thêm nghiệp lực của họ. Giải quyết vấn đề này khá đơn giản: chúng tôi sử dụng ý thức chung và ngoài các số liệu định lượng, còn sử dụng các số liệu thiết yếu, định tính. Mức độ sử dụng kết quả làm việc của nhóm, số lượng người đóng góp bên ngoài, mức độ bao phủ thử nghiệm, độ ổn định của các mô-đun và toàn bộ sản phẩm, kết quả thử nghiệm quy mô và hiệu suất, số lượng kỹ sư nhận vai trò đánh giá viên cốt lõi dây đai, thực tế là các dự án đã được chấp nhận vào cộng đồng dự án cốt lõi, việc tuân thủ các tiêu chí ở các giai đoạn khác nhau của quy trình kỹ thuật - tất cả những yếu tố này và nhiều yếu tố khác phải được đánh giá cùng với các số liệu định lượng đơn giản.
Và cuối cùng, điểm thứ ba - Không nhảm nhí.
Các nhà phát triển là những người rất thông minh và cực kỳ logic trong công việc của họ. Họ dành 8-10 giờ mỗi ngày để xây dựng các chuỗi logic dài và phức tạp, vì vậy họ nhanh chóng nhận ra các lỗ hổng trong đó. Khi làm điều gì đó, họ cũng như những người khác, muốn hiểu lý do tại sao họ làm việc đó, điều gì sẽ thay đổi theo chiều hướng tốt hơn. Điều cực kỳ quan trọng là các mục tiêu bạn đặt ra cho nhóm của mình phải trung thực và thực tế. Cố gắng bán một ý tưởng tồi cho nhóm lập trình là một ý tưởng tồi. Một ý tưởng sẽ tệ nếu bản thân bạn không tin vào nó, hoặc trong những trường hợp cực đoan, bạn không có trạng thái nội tâm không đồng ý và cam kết (tôi không đồng ý, nhưng tôi sẽ làm điều đó). Chúng tôi đã từng triển khai hệ thống tạo động lực trong một công ty, một trong những yếu tố của hệ thống đó là hệ thống điện tử để cung cấp phản hồi. Họ đầu tư rất nhiều tiền, đưa người sang Mỹ đào tạo, nói chung là đầu tư hết mình. Một lần, trong cuộc trò chuyện sau khóa đào tạo, một trong những người quản lý đã nói với cấp dưới của mình: “Ý tưởng này không tệ, có vẻ như nó sẽ thành công. Tôi sẽ không tự mình đưa ra phản hồi điện tử cho bạn mà bạn đưa nó cho người của mình và yêu cầu họ làm như vậy.” Thế là xong, không còn gì có thể thực hiện được nữa. Tất nhiên, ý tưởng này đã kết thúc không có kết quả gì.
Nguồn: www.habr.com