Notícias de dispositivos móveis, gadgets, aplicativos Android

Um componente crítico para o sucesso ágil: respeito

Era uma vez uma equipe de marketing √°gil que tentava dizer n√£o a um pedido de vendas de √ļltima hora. Um evento estava chegando e o vendedor queria um material impresso personalizado e uma landing page correspondente.

Os profissionais de marketing estavam no meio de uma corrida. A solicitação de venda era urgente, mas não muito importante.

A equipe de marketing Agile foi ensinada que não deveria aceitar trabalho no meio do sprint sem um forte business case, então eles prometeram documentar a solicitação como um cartão em seu backlog e considerá-la no próximo sprint.

Chocado, o vendedor foi em frente e criou seu próprio one-pager e iniciou um teste gratuito de uma ferramenta de landing page para que pudesse direcionar o tráfego do evento para ela.

Eles nunca contaram ao marketing sobre nada disso.

Enquanto isso, outro vendedor recebeu uma solicitação de novo recurso de um cliente em potencial e pediu à equipe de desenvolvimento Agile para construí-lo. Assim como os profissionais de marketing, os desenvolvedores estavam no meio do sprint e se recusaram a começar a trabalhar no recurso imediatamente.

O vendedor ficou desapontado, mas não teve escolha a não ser aceitar a decisão e esperar que o recurso fosse priorizado para receber atenção.

Por que essas histórias parecem tão diferentes? Ambas as equipes são ágeis e ambas devem ter autonomia para controlar seus fluxos de trabalho. No entanto, a recusa de um encontra uma solução alternativa secreta, enquanto o outro é, ainda que a contragosto, aceite.

Esta história ilustra uma questão fundamental para as formas ágeis de trabalhar à medida que saem do software, uma questão que todos os defensores da agilidade nos negócios precisam considerar cuidadosamente.

N√≥s recomendamos:  Truques para vencer os desafios da Clash Royale King's Cup

Respeito, Mística e Agilidade

Essas duas histórias são tão diferentes por alguns motivos. A primeira está enraizada na percepção interna de uma função específica. O desenvolvimento de software é, em geral, um processo misterioso para aqueles de nós que não conseguem fazê-lo.

Letras e s√≠mbolos s√£o combinados em c√≥digo, de alguma forma compilado (seja l√° o que isso signifique) e, eventualmente, aparece como coisas novas que as pessoas podem fazer com um software ou aplicativo. (Meu marido se formou em ci√™ncia da computa√ß√£o e, sem d√ļvida, estremeceria com essa descri√ß√£o grosseira do processo de desenvolvimento, mas s√≥ sei disso depois de ouvi-lo falar sobre seu trabalho durante anos.)

Felizmente para as equipes de software Agile em todo o mundo, essa mística muitas vezes se traduz em respeito pelo desenvolvimento. Não entendemos isso completamente e certamente não poderíamos replicá-lo, então quando uma equipe de desenvolvimento nos diz quanto tempo algo vai demorar, estamos inclinados a acreditar neles. Podemos negociar o escopo ou a data de entrega, mas no final aceitaremos o que conseguirmos.

Além do mais, os produtos de software são suficientemente complexos para terem uma estrutura de governança robusta que evita que pessoas não autorizadas mexam neles. Se uma equipe de desenvolvimento recusar minha solicitação de recurso, não poderei simplesmente fazer login no servidor de produção e adicioná-lo sozinho.

Juntas, essas duas coisas permitiram que estruturas como o Scrum fossem eficazes no desenvolvimento de software de maneiras que muitas vezes n√£o s√£o replic√°veis ‚Äč‚Äčem outras fun√ß√Ķes.

Marketing é apenas bebida e adivinhação

O marketing √© um excelente exemplo dessa nuance. V√°rias equipes de marketing Agile me disseram que n√£o podem recusar solicita√ß√Ķes de trabalho, mesmo que j√° estejam sobrecarregadas, porque se n√£o o fizerem, outra pessoa o far√°.

N√≥s recomendamos:  Ubuntu 23.10 Beta j√° est√° dispon√≠vel para download

Assim como na hist√≥ria que abriu este artigo, o solicitante encontrar√° uma solu√ß√£o alternativa para realizar sua tarefa. Muitas vezes, o resultado √© um trabalho que n√£o est√° alinhado aos padr√Ķes da marca, que n√£o √© monitorado de forma eficaz, totalmente ineficaz ou todas as op√ß√Ķes acima.

Todos n√≥s consumimos materiais de marketing, seja um e-mail, um an√ļncio ou um site, e, portanto, assumimos que somos profissionais de marketing qualificados.

Um cartoon de Dilbert, no qual um desenvolvedor de software est√° pensando em mudar para o marketing, termina com Dilbert dizendo que ele n√£o deveria fazer isso porque marketing √© ‚Äúapenas bebida e suposi√ß√Ķes‚ÄĚ. Com essa percep√ß√£o, n√£o √© de admirar que as pessoas n√£o tenham problemas em agir pelas costas de uma equipe de marketing √°gil quando t√™m a aud√°cia de dizer n√£o a uma solicita√ß√£o.

Sem a capacidade de adiar solicita√ß√Ķes recebidasnenhuma equipe Agile pode prosperar.

Promovendo o respeito por todas as equipes √°geis

N√£o √© muito pr√°tico criarmos o equivalente a um servidor de produ√ß√£o para marketing e todas as outras fun√ß√Ķes que desejam ser √°geis. O objetivo n√£o √© bloquear os meios de realizar o trabalho.

O que podemos fazer √© construir uma cultura de respeito m√ļtuo entre as √°reas funcionais.

Uma equipe de marketing √°gil que afirma que sua carga de trabalho n√£o consegue acomodar uma solicita√ß√£o de √ļltima hora deve ser ouvida da mesma forma que uma equipe de desenvolvimento √°gil. Al√©m do mais, deveria haver reconhecimento de que o marketing √© uma profiss√£o complexa. Existem especialidades e nuances que tornam isso muito dif√≠cil ‚Äď nem todo mundo est√° qualificado para ser profissional de marketing.

N√≥s recomendamos:  Fones de ouvido para jogos sem fio JBL Quantum 350 com drivers de 40 mm lan√ßados na √ćndia

À medida que a agilidade percorre toda a organização, mais e mais equipes Agile serão formadas. Cada um deles tem o direito de possuir seu trabalho.

Se minha equipe de marketing √°gil quiser fazer uma nova contrata√ß√£o e solicitarmos ajuda de uma equipe √°gil de RH, eles poder√£o nos dizer ‚Äúagora n√£o‚ÄĚ se n√£o tiverem capacidade. Isso n√£o significa que devemos postar uma descri√ß√£o de cargo n√£o aprovada no Even amanh√£, porque n√£o queremos esperar por eles.

Sem fazer um esforço deliberado para compreender as complexidades do trabalho dos nossos colegas, colocamos em risco toda uma transformação Agile.

Pode parecer o c√ļmulo do desperd√≠cio explorar o que um departamento totalmente separado faz, mas esses pontos de conex√£o e empatia s√£o cruciais para fazer a agilidade dos neg√≥cios funcionar. √Č uma mudan√ßa de confiar na m√≠stica do desenvolvimento de software para proteger as equipes, mas √© vital para o sucesso Agile a longo prazo em qualquer organiza√ß√£o.