Epígrafe:
O marido, mirando os fillos sucios, dille á súa muller: ben, lavamos estes ou daremos a luz outros novos?
Debaixo do corte está a segunda parte dun artigo do noso xefe de equipo, así como do director de Desenvolvemento de Produtos de RAS, Igor Marnat, sobre as peculiaridades de motivar aos programadores. A primeira parte do artigo pódese atopar aquí -
Na primeira parte do artigo, toquei os dous niveis inferiores da pirámide de Maslow: necesidades fisiolóxicas, necesidades de seguridade, comodidade e constancia e pasei ao seguinte, terceiro nivel, a saber:
III - Necesidade de pertenza e amor
Sabía que a mafia italiana se chamaba “Cosa Nostra”, pero quedei moi impresionado cando descubrín como se traduce “Cosa Nostra”. "Cosa Nostra" traducido do italiano significa "O noso negocio". A elección do nome é moi acertada pola motivación (deixemos de lado a ocupación, neste caso só nos interesa a motivación). Unha persoa adoita querer formar parte dun equipo, facer un negocio grande e común.
Dáse moita importancia a satisfacer a necesidade de pertenza e amor no exército, na mariña e en calquera gran formación paramilitar. E, como vemos, na mafia. Isto é comprensible, porque hai que obrigar a persoas que teñen pouco en común, que inicialmente non forman un equipo de persoas afíns, que se reúnen por reclutamento (non voluntariamente), que teñen diferentes niveis de estudos, diferentes valores persoais. , para dedicar literalmente a súa vida, con risco mortal, a algunha causa común , confía a túa vida a un compañeiro de armas.
Esta é unha motivación moi forte; para a maioría da xente é moi importante sentir que pertencen a algo máis grande, saber que formas parte dunha familia, dun país, dun equipo. No exército, os uniformes, os rituais diversos, os desfiles, as marchas, as pancartas, etc. serven para estes fins. Aproximadamente os mesmos factores son importantes para calquera equipo. Os símbolos, a marca corporativa e as cores corporativas, a parafernalia e os recordos son importantes.
É importante que os acontecementos significativos teñan a súa propia encarnación visible coa que se poidan asociar. Hoxe en día, é máis ben a norma que unha empresa teña a súa propia mercadoría, chaquetas, camisetas, etc. Pero tamén é importante destacar o equipo dentro da empresa. Moitas veces lanzamos camisetas en función dos resultados dun lanzamento, que se entregan a todos os implicados no lanzamento. Algúns eventos, celebracións conxuntas ou actividades con todo o equipo son outro factor importante de motivación.
Ademais dos atributos externos, outros factores inflúen no sentimento de pertenza a un equipo.
En primeiro lugar, a presenza dun obxectivo común que todos entendan e compartan unha valoración da súa importancia. Os programadores adoitan querer entender que están facendo algo interesante e que o están facendo xuntos, como equipo.
En segundo lugar, o equipo debe dispoñer dun espazo de comunicación no que estea presente todo o equipo e que só lle pertenza (por exemplo, un chat no messenger, sincronizacións periódicas do equipo). Ademais de problemas de traballo, comunicación informal, ás veces discusión de eventos externos, luz offtop - todo isto crea un sentido de comunidade e equipo.
En terceiro lugar, destacaría a introdución de boas prácticas de enxeñería dentro do equipo, a vontade de elevar os estándares fronte aos aceptados na empresa. Implementar os mellores enfoques aceptados na industria, primeiro no equipo, e despois na empresa no seu conxunto, dálle ao equipo a oportunidade de sentir que dalgunha maneira está por diante dos demais, liderando o camiño, isto crea un sentimento de pertenza. a un equipo xenial.
No sentido de pertenza tamén inflúe a participación do equipo na planificación e xestión. Cando os membros do equipo están involucrados en discutir os obxectivos do proxecto, os plans de traballo, os estándares do equipo e as prácticas de enxeñería e entrevistar a novos empregados, desenvolven un sentido de participación, propiedade compartida e influencia no traballo. A xente está moito máis disposta a levar a cabo as decisións tomadas e expresadas por eles mesmos que as propostas por outros, aínda que estean practicamente en sintonía.
Aniversarios, aniversarios, eventos significativos na vida dos compañeiros: unha pizza conxunta, un pequeno agasallo do equipo dan unha cálida sensación de implicación e gratitude. Nalgunhas empresas, é costume dar pequenos letreiros conmemorativos por 5, 10, 15 anos de traballo na empresa. Por unha banda, non creo que isto me motive tanto para novos logros. Pero, obviamente, case calquera estará satisfeito de que non se esqueza del. Este é un deses casos nos que a ausencia dun feito desmotiva máis que a súa presenza. De acordo, pode ser unha vergoña que LinkedIn che recordase pola mañá e te felicite polo teu décimo aniversario no teu lugar de traballo, pero nin un só compañeiro da empresa te felicitou nin se acordase de ti.
Por suposto, un punto significativo é o cambio na composición do equipo. Está claro que aínda que se anuncie con antelación a chegada ou a saída de alguén do equipo (por exemplo, nun boletín informativo da empresa ou do equipo, ou nunha reunión do equipo), isto non motiva especialmente a ninguén a conseguir novos logros. Pero se un bo día ves a unha nova persoa ao teu lado, ou non ves a unha antiga, pode ser unha sorpresa, e se te vas, francamente desagradable. A xente non debería desaparecer tranquilamente. Sobre todo nun equipo distribuído. Especialmente se o teu traballo depende dun compañeiro doutra oficina que de súpeto se levantou e desapareceu. Tales momentos definitivamente paga a pena informar ao equipo por separado con antelación.
Un factor importante, que en inglés se chama propiedade (a tradución literal de "posesión" non reflicte totalmente o seu significado). Este non é un sentimento de propiedade, senón un sentimento de responsabilidade polo teu proxecto, ese sentimento cando te asocias emocionalmente co produto e o produto contigo mesmo. Isto corresponde aproximadamente á oración do Mariño na película "Full Metal Jacket": "Este é o meu rifle. Hai moitos tales rifles, pero este é o meu. O meu rifle é o meu mellor amigo. Ela é a miña vida. Debo aprender a posuír da mesma maneira que a miña vida. Sen min, o meu rifle é inútil. Son inútil sen o meu rifle. Debo disparar o meu rifle en liña recta. Teño que disparar con máis precisión que ao inimigo que intenta matarme. Teño que pegarlle un tiro antes de que me dispare. Que así sexa..."
Cando unha persoa traballa nun produto durante moito tempo, ten a oportunidade de asumir a total responsabilidade da súa creación e desenvolvemento, de ver como unha cousa funcionando xorde da "nada", como a xente o usa, xorde este sentimento poderoso. Os equipos de produtos que traballan xuntos durante moito tempo nun proxecto adoitan estar máis motivados e cohesionados que os equipos que se reúnen durante un período curto de tempo e traballan en modo de cadea de montaxe, cambiando dun proxecto a outro, sen a total responsabilidade de todo o produto. , de principio a fin.
IV. Necesidade de recoñecemento
Unha palabra amable tamén agrada ao gato. Todo o mundo está motivado polo recoñecemento da importancia do traballo realizado e a súa valoración positiva. Fala cos programadores, dálles comentarios periódicos, celebra un traballo ben feito. Se tes un equipo grande e distribuído, as reunións periódicas (o que se chaman un a un) son perfectas para iso; se o equipo é moi pequeno e traballa en conxunto local, esta oportunidade adoita ofrecerse sen reunións especiais no calendario (aínda que unha periódica). a un é todo. Aínda é necesario, podes facelo con menos frecuencia). Este tema está ben tratado nos podcasts para xestores en manager-tools.com.
Non obstante, paga a pena ter en conta as diferenzas culturais. Algúns enfoques coñecidos polos colegas estadounidenses non sempre funcionarán cos rusos. O nivel de cortesía aceptado na comunicación diaria nos equipos dos países occidentais parece inicialmente excesivo para os programadores de Rusia. Algunhas características de franqueza dos colegas rusos poden ser percibidas como grosería polos seus colegas doutros países. Isto é moi importante na comunicación nun equipo interétnico; escribiuse moito sobre este tema; o director dese equipo debe lembralo.
As demostracións de funcións, nas que os programadores mostran funcións desenvolvidas durante un sprint, son unha boa práctica para comprender esta necesidade. Ademais de que esta é unha excelente oportunidade para despexar as canles de comunicación entre os equipos, dar a coñecer novas funcións aos xestores de produtos e probadores, tamén é unha boa oportunidade para que os desenvolvedores mostren os resultados do seu traballo e indiquen a súa autoría. Ben, e pule as túas habilidades para falar en público, por suposto, o que nunca é prexudicial.
Sería unha boa idea celebrar a importante contribución de compañeiros especialmente distinguidos con certificados, letreiros conmemorativos (polo menos unha palabra amable) nas reunións do equipo conxunto. A xente adoita valorar moito estes certificados e sinais conmemorativos, lévaos consigo cando se muda e, en xeral, coidalos de todos os xeitos posibles.
Para marcar unha contribución máis significativa e a longo prazo ao traballo do equipo, a experiencia acumulada e a experiencia, adoita empregarse un sistema de cualificacións (de novo pódese facer unha analoxía co sistema de rangos militares no exército, que ademais de para garantir a subordinación, tamén serve para este fin). Moitas veces, os desenvolvedores novos traballan o dobre para conseguir novas estrelas nas súas correas de ombreiro (é dicir, pasar de desenvolvedor júnior a desenvolvedor a tempo completo, etc.).
Coñecer as expectativas da túa xente é fundamental. Algúns son máis propensos a estar motivados por unha nota alta, a oportunidade de ser chamados, por exemplo, arquitectos, mentres que outros, pola contra, son indiferentes ás cualificacións e títulos e considerarán un aumento do salario un sinal de recoñecemento da empresa. . Comunicarse coas persoas para comprender o que queren e cales son as súas expectativas.
Unha demostración de recoñecemento, un maior nivel de confianza por parte do equipo, pódese dar dando máis liberdade de acción ou implicación en novas áreas de traballo. Por exemplo, despois de adquirir certa experiencia e acadar certos resultados, un programador, ademais de implementar as súas características segundo a especificación, pode traballar na arquitectura de cousas novas. Ou involúcrase en áreas novas que quizais non estean directamente relacionadas co desenvolvemento: automatización de probas, implementación de mellores prácticas de enxeñería, axuda na xestión de lanzamentos, charlas en conferencias, etc.
V. A necesidade de coñecemento e autorrealización.
Moitos programadores están enfocados en diferentes tipos de actividades de programación en diferentes etapas da súa vida. Algunhas persoas gústalles facer aprendizaxe automática, desenvolver novos modelos de datos, ler moita literatura científica para traballar e crear algo novo desde cero. Outra está máis próxima á depuración e ao soporte dunha aplicación existente, na que cómpre afondar no código existente, estudar rexistros, apilar trazos e captchas de rede durante días e semanas e case non escribir código novo.
Ambos procesos requiren un gran esforzo intelectual, pero o seu resultado práctico é diferente. Crese que os programadores son reacios a apoiar as solucións existentes; están bastante motivados para desenvolver outras novas. Hai un gran de sabedoría nisto. Por outra banda, o equipo máis motivado e unido co que traballei dedicouse a apoiar un produto existente, buscar e solucionar erros despois de que o equipo de soporte se puxese en contacto con eles. Os mozos vivían literalmente para este traballo e estaban preparados para saír os sábados e domingos. Noutro día tratamos con ansia outro problema urxente e complexo, ben na noite do 31 de decembro ou na tarde do 1 de xaneiro.
Varios factores influíron nesta alta motivación. En primeiro lugar, era unha empresa cun gran nome no sector, o equipo asociouse a ela (ver "A necesidade de afiliación"). En segundo lugar, eran a última fronteira, non había ninguén detrás, non había un equipo de produto naquel momento. Entre eles e os clientes había dous niveis de apoio, pero se o problema chegaba a eles, non había onde retirarse, ninguén estaba detrás deles, toda a corporación estaba sobre eles (catro novos programadores). En terceiro lugar, esta gran empresa tiña clientes moi grandes (gobernos dos países, empresas de automóbil e aviación, etc.) e instalacións a moi grande envergadura en varios países. Como resultado, problemas sempre complexos e interesantes, problemas sinxelos foron resoltos co apoio de niveis anteriores. En cuarto lugar, a motivación do equipo estivo moi influenciada polo nivel profesional do equipo de apoio co que interactuaban (había enxeñeiros moi experimentados e con capacidade técnica), e sempre confiamos na calidade dos datos que elaboraban, na análise que realizaron. , etc. En quinto lugar, e creo que este é o punto máis importante: o equipo era moi novo, todos os mozos estaban ao comezo da súa carreira. Estaban interesados en estudar un produto grande e complexo, resolver problemas graves que eran novos para eles nun ambiente novo, buscaron igualar profesionalmente o nivel dos equipos, problemas e clientes da contorna. O proxecto resultou ser unha excelente escola, todos fixeron máis tarde unha boa carreira na empresa e convertéronse en líderes técnicos e altos directivos, un dos mozos agora é xestor técnico de Amazon Web Services, o outro finalmente mudouse a Google e todos deles aínda lembran con calidez este proxecto .
Se este equipo estivese formado por programadores con 15-20 anos de experiencia ás súas costas, a motivación sería diferente. A idade e a experiencia non son, por suposto, factores 100% determinantes, todo depende da estrutura da motivación. Neste caso particular, o desexo de coñecemento e crecemento dos novos programadores deu excelentes resultados.
En xeral, como xa mencionamos varias veces, debes coñecer as expectativas dos teus programadores, comprender cal deles desexa ampliar ou cambiar o seu campo de actividade e ter en conta estas expectativas.
Máis aló da pirámide de Maslow: visibilidade de resultados, gamificación e competencia, sen tonterías
Hai tres puntos máis importantes sobre a motivación dos programadores que definitivamente deben mencionarse, pero incorporalos ao modelo de necesidades de Maslow sería demasiado artificial.
O primeiro é a visibilidade e proximidade do resultado.
O desenvolvemento de software adoita ser un maratón. Os resultados dos esforzos de I+D fanse visibles despois de meses, ás veces anos. É difícil ir a un obxectivo que está moito máis alá do horizonte, a cantidade de traballo é aterradora, a meta está lonxe, non está clara e non se ve, "a noite está escura e chea de horrores". É mellor dividir o camiño en partes, facer un camiño cara á árbore máis próxima que sexa visible, accesible, os contornos son claros e non está lonxe de nós, e vaia ata este obxectivo próximo. Queremos facer un esforzo de varios días ou semanas, obter e avaliar o resultado, despois seguir adiante. Polo tanto, paga a pena dividir o traballo en pequenas partes (os sprints en áxil serven ben para iso). Rematamos parte do traballo -grabámolo, exhalamos, discutimos, castigamos aos culpables, premiamos aos inocentes- podemos comezar o seguinte ciclo.
Esta motivación é ata certo punto similar á que experimentan os xogadores ao completar xogos de ordenador: reciben periódicamente medallas, puntos e bonificacións a medida que completan cada nivel; isto pódese chamar "motivación de dopamina".
Ao mesmo tempo, a visibilidade do resultado é literalmente importante. Unha función pechada da lista debería poñerse en verde. Se o código está escrito, probado, lanzado, pero non hai ningún cambio no estado visual visible para o programador, sentirase incompleto, non haberá sensación de finalización. Nun dos equipos do noso sistema de control de versións, cada parche pasou por tres etapas sucesivas: a compilación foi montada e as probas superadas, o parche pasou a revisión do código e o parche fusionouse. Cada etapa estaba marcada visualmente cunha marca verde ou cruz vermella. Unha vez que un dos desenvolvedores queixouse de que a revisión do código levaba demasiado tempo, os compañeiros necesitaban acelerar, os parches estiveron pendentes durante varios días. Pregunteille, que cambia isto realmente para el? Despois de todo, cando o código está escrito, a compilación está montada e as probas pasaron, non necesita prestar atención ao parche enviado se non hai comentarios. Os propios compañeiros farán a revisión e mancharán (se, de novo, non hai comentarios). El respondeu: "Igor, quero conseguir as miñas tres carrachas verdes o antes posible".
O segundo punto é a gamificación e a competencia.
Ao desenvolver un dos produtos, o noso equipo de enxeñería tiña como obxectivo ocupar unha posición destacada na comunidade dun dos produtos de código aberto, para entrar no top-3. Daquela, non existía unha forma obxectiva de avaliar a visibilidade de alguén na comunidade; cada unha das grandes empresas participantes podía afirmar (e afirmar periodicamente) que era o contribuínte número un, pero non había forma real de comparar as contribucións dos participantes. entre eles, para avaliar a súa dinámica no tempo. En consecuencia, non había forma de marcar un obxectivo para o equipo que se puidese medir nalgúns loros, valorar o grao de consecución da súa consecución, etc. Para solucionar este problema, o noso equipo desenvolveu unha ferramenta para medir e visualizar a contribución de empresas e colaboradores individuais . Desde o punto de vista motivacional, resultou ser só unha bomba. Non eran só os enxeñeiros e os equipos os que supervisaban constantemente o seu progreso e o progreso dos seus compañeiros e competidores. A alta dirección da nosa empresa e todos os principais competidores tamén comezaron o seu día con stackalytics. Todo fíxose moi transparente e visual, todos podían controlar coidadosamente o seu progreso, comparar cos compañeiros, etc. Fíxose cómodo e fácil para enxeñeiros, xestores e equipos establecer obxectivos.
Un punto importante que xorde á hora de implantar calquera sistema de métricas cuantitativas é que, en canto as teñas implantadas, o sistema se esforza automaticamente en priorizar a consecución destas métricas cuantitativas, en detrimento das cualitativas. Por exemplo, o número de revisións de código completadas úsase como unha das métricas. Obviamente, a revisión do código pódese facer de diferentes xeitos, pode dedicar varias horas a unha revisión exhaustiva e a verificación dun parche complexo comprobando probas, executándoo no seu banco, comprobando coa documentación e obter máis unha revisión no seu karma, ou Fai clic cegamente nun par de ducias de parches nun par de minutos, dálle +1 a cada un e obtén máis vinte en karma. Houbo casos cómicos nos que os enxeñeiros facían clic nos parches tan rápido que deron +1 aos parches automáticos do sistema CI. Como máis tarde bromeamos, "vai, vai, jenkins". No caso dos commits, tamén houbo moitas persoas que repasaron o código con ferramentas de formato de código, editaron comentarios, cambiaron os puntos por comas e, así, aumentaron o seu karma. Tratalo é ben sinxelo: empregamos o sentido común e, ademais das métricas cuantitativas, tamén empregamos as esenciais, cualitativas. O grao de uso dos resultados do traballo do equipo, o número de colaboradores externos, o nivel de cobertura das probas, a estabilidade dos módulos e de todo o produto, os resultados das probas de escala e rendemento, o número de enxeñeiros que recibiron o ombreiro principal do revisor. correas, o feito de que os proxectos fosen aceptados na comunidade de proxectos básicos, o cumprimento dos criterios das diferentes etapas do proceso de enxeñería - todos estes e moitos outros factores deben ser avaliados xunto con métricas cuantitativas sinxelas.
E, finalmente, o terceiro punto - Non hai tonterías.
Os desenvolvedores son persoas moi intelixentes e extremadamente lóxicas na súa liña de traballo. Levan entre 8 e 10 horas ao día construíndo cadeas lóxicas longas e complexas, polo que ven vulnerabilidades nelas sobre a marcha. Cando fan algo, eles, como todos, queren entender por que o fan, o que cambiará para mellor. É moi importante que os obxectivos que marcas para o teu equipo sexan honestos e realistas. Tentar vender unha mala idea a un equipo de programación é unha mala idea. Unha idea é mala se ti mesmo non crees nela ou, en casos extremos, non tes o estado interno de non estar de acordo e comprometerme (non estou de acordo, pero fareino). No seu día implantamos nunha empresa un sistema de motivación, un dos seus elementos era un sistema electrónico de retroalimentación. Investiron moito diñeiro, levaron xente a América para adestrarse, en xeral, investiron ao máximo. Unha vez, nunha conversación tras o adestramento, un dos directivos dixo aos seus subordinados: “A idea non está mal, parece que vai funcionar. Eu non che darei feedback electrónico, pero ti dásllo á túa xente e esíxese a eles". Iso é todo, nada se podería implementar máis. A idea, por suposto, acabou en nada.
Fonte: www.habr.com