quinta-feira, 29 de outubro de 2020

Comentários sobre o Guia Salarial 2021 Robert Half

 

Nesse post vamos apresentar comentários sobre o Guia Salarial 2021 da Robert Half.

" ...

53% dos empregadores afirmam que os salários não devem sofrer grandes alterações em 2021.

62% dos executivos aprovam o trabalho remoto e tiveram experiência positiva durante a pandemia.

74% dos empregadores apoiam contar com uma equipe de trabalho híbrida (parte home office e parte no escritório).

Os principais motivos são:

  • As pessoas devem trabalhar de onde se sentem mais produtivas;
  • Essa flexibilidade vai aumentar a motivação e lealdade do time;
  • A experiência na pandemia com o trabalho remoto foi boa.

60% dos executivos brasileiros afirmam que a pandemia acelerou os processos de transformação digital da empresa.

56% dos executivos estão muito preocupados com a retenção, e para 54% deles, o principal medo é perder um bom profissional para a concorrência.

41% dos executivos brasileiros disseram que vão aumentar o quadro de trabalhadores por projetos nos próximos meses.

Vantagens de Contratar por Projetos:

  • Contar com profissionais especializados para projetos pontuais, que agregam conhecimento ao time;
  • Manter a agilidade e a produtividade em períodos desafiadores;
  • Aumentar a flexibilidade da área, sem afetar a rotina do pessoal em tempo integral;
  • Avaliar um(a) profissional para futura contratação;
  • Reavaliar a carga de trabalho do pessoal em tempo integral em épocas de maior demanda.

O guia aponta para uma vasta gamas de posições que podem entrar na modalidade de contratação por projetos como, por exemplo, analista de cybersegurança, Scrum Master, analista de sinistro, analista de contabilidade, recrutador de RH, analista de folha de pagamento, analista financeiro, analista de logística, comprador, consultor de compliance, consultor de processos, vendedor, analista de marketing, advogado generalista e paralegal.

...".

Se você é seguidor do blog e deseja receber uma cópia do Guia Salarial 2021 Robert Half, envie um e-mail para h12sblog@gmail.com

******************************************

Sobre a Robert Half

A Robert Half é a primeira e maior empresa de recrutamento especializado no mundo. Fundada em 1948, a empresa opera no Brasil selecionando profissionais temporários e permanentes nas áreas de finanças, contabilidade, mercado financeiro, seguros, engenharia, tecnologia, jurídico, recursos humanos, marketing e vendas e cargos de alta gestão.

Para mais informações acesse > https://www.roberthalf.com.br/

Bem, é isso ai! Até a próxima.

******************************************

segunda-feira, 26 de outubro de 2020

Episódio 4 do PODCAST H12S: Sugestões para Gerenciar o Trabalho Remoto

 


A pandemia do covid-19 acelerou a adoção do trabalho remoto em muitas organizações e isso trouxe novos desafios. Como lidar com o estresse e a insegurança de não estar presente no escritório? Continuaremos produtivos, mesmo com as distrações de casa? Esse artigo trata de questões relacionadas ao trabalho remoto.

No blog, você poderá acessar o texto desse artigo no link > http://h12sse.blogspot.com/2020/06/sugestoes-para-gerenciar-o-trabalho.html

...........................................................................................................

OUÇA ESSE ARTIGO ACESSANDO >

Plataforma SPOTIFY >

https://open.spotify.com/show/7rLe4pURFDPSpVHS7zDuA1

Plataforma RADIO PUBLIC > 

https://radiopublic.com/h12s-podcast-8X2aYk

Plataforma ANCHOR > 

https://anchor.fm/haroldo-m-c-simoes/


...........................................................................................................

terça-feira, 20 de outubro de 2020

O Atributo da Confiança


Ouça esse artigo acessando os links >

Plataforma SPOTIFY >

https://open.spotify.com/show/7rLe4pURFDPSpVHS7zDuA1

Plataforma RADIO PUBLIC > 

https://radiopublic.com/h12s-podcast-8X2aYk

Plataforma ANCHOR > 

https://anchor.fm/haroldo-m-c-simoes/


.............................................................

Nesse artigo vamos tratar do atributo confiança e de sua importância de acordo com a visão de diferentes autores, com ideias que se confirmam e complementam entre si. 


No final desse artigo você poderá encontrar referências aos autores aqui mencionados e seus respectivos livros ou artigos.

Isso posto, vamos lá!

Para começar, eu escolhi o autor Ricardo Vargas e seu livro Construindo Times Altamente Eficazes. Nesse livro Vargas afirma o seguinte:

A confiança é uma das qualidades mais difíceis de se desenvolver em qualquer equipe. Ela só é adquirida através do tempo, do convívio e da experiência. Membros de equipes de alto desempenho devem desenvolver elevado nível de confiança uns nos outros.

Membros da equipe devem evidenciar a competência e o comprometimento demonstrado pelo outro, para que essa confiança possa se desenvolver com o estimulo positivo. Eles devem sentir que todos estão comprometidos com o sucesso da equipe e não apenas com o sucesso pessoal. Eles precisam desenvolver confiança não só na capacidade profissional de outros membros da equipe, mas também na sua interioridade pessoal.

A confiança mútua aumenta a comunicação, o comprometimento e a lealdade entre os membros da equipe.

Por sua vez, John Maxwell em seu livro O Líder 360º, destaca o que ele chamou de “Desafio No. 1”, o desafio da tensão: a pressão de ser surpreendido no escalão médio. Aqui o autor destaca certos desafios da liderança no escalão médio de uma organização e isso se aplica ao gerenciamento de projetos em muitos casos. O autor afirma:

Aprenda a ser líder a despeito das restrições que os outros lhe impuseram.

Uma das coisas mais difíceis com relação a ser um líder no escalão médio de uma organização é que não dá para você ter certeza de onde está. Como líder, você tem certo poder e autoridade. Pode chamar as pessoas de sua área para tomarem uma atitude e orientá-las no trabalho. Ao mesmo tempo, também lhe falta poder em outras áreas. E se abusar de sua autoridade, você pode de fato se complicar.

Se você quiser saber o que levará o desafio da tensão ao limite, é violar a confiança que lhe foi dada com sua autoridade ou posição. Enfraquecer intencionalmente seu líder ou usar os recursos da organização para ganho pessoal é o mesmo que abuso de poder.  

Maxwell detalha essa ideia um pouco mais:

Quando lhe é dada autoridade, você a exerce em nome daqueles a quem deve se reportar. Sua posição nunca tem por objetivo servir aos seus próprios interesses. Ao longo do curso de sua jornada como líder, seu caráter e integridade serão invariavelmente testados. Como alguém que está liderando do escalão médio de uma organização, sua habilidade de manter a autoridade que lhe foi dada depende inteiramente de sua fidelidade em servir às pessoas que lhe deram essa autoridade.

Temos ainda, nessa sequência, o autor Peter Pfeiffer, que afirma em seu livro Facilitação de Projetos, o seguinte: Com relação ao trabalho coletivo, é importante lembrar que apenas juntar um grupo de pessoas não as torna automaticamente uma equipe. Se entendermos equipe como um conjunto de pessoas que se dedicam à realização de um mesmo trabalho (definição do dicionário Houaiss), é preciso levar em consideração que não apenas a dedicação pode variar de uma pessoa para outra, mas que também uma série de outros fatores e aspectos costuma variar, tais como personalidade, competências e experiências. É por isso que as equipes precisam ser construídas e desenvolvidas. Frequentemente mencionam-se, em inglês, quatro estágios genéricos pelos quais as equipes passam até ganhar coerência: forming, storming, norming e performing.

Forming (de formar) – as pessoas se aproximam, se sondam mutuamente, geralmente com simpatia, mas sem muita confiança;

Storming (de contestar) – as pessoas começam a testar umas às outras, bem como os próprios limites, desafiando e questionando posições e conteúdos. A produtividade é ainda baixa e às vezes conflitos vêm à tona;

Norming (de normalizar) – Começa-se a construir valores e visões comuns que resultam em normas e regras de convivência e de trabalho;

Performing (de desempenhar) – Já com maior confiança entre as pessoas, a cooperação começa a fluir melhor e resulta em maior produtividade e satisfação.

Pfeiffer reforça ainda que mesmo já tendo passado pelas fases típicas de construção de uma equipe, é importante lembrar que as equipes precisam ser desenvolvidas sistemática e continuamente. Os relacionamentos entre as pessoas não são construídos em um único momento para durar para sempre, eles têm que ser confirmados e renovados ao longo dos trabalhos a serem realizados em equipe. Nesse processo, a confiança é um elemento-chave, embora não o único, para o bom desempenho das equipes.

O autor Patrick Lencioni, em seu livro Os 5 desafios de equipes, aponta para cinco disfunções típicas das equipes que precisam ser reduzidas ou eliminadas a fim de que as pessoas como indivíduos e os grupos como equipes possam desdobrar as suas potencialidades. As disfunções são: (1) a ausência de confiança entre os membros da equipe, (2) o medo do conflito, (3) a falta de comprometimento, (4) o hábito de evitar responsabilidade e (5) a falta de atenção aos resultados.

Agora continuando, segundo o autor Stephen Robbins, em seu livro Comportamento Organizacional, uma referência para todos que se interessam pela área da gestão nas organizações modernas, a confiança é a pedra fundamental da liderança. As pessoas só seguem e se deixam influenciar por um líder em que têm confiança.

A confiança é uma expectativa positiva de que a outra pessoa não irá agir de maneira oportunista – seja por palavras, ações ou decisões. Os dois elementos mais importantes em nossa definição são familiaridade e risco.

A maioria de nós considera muito difícil, se não impossível, confiar em alguém imediatamente, quando não sabemos nada sobre a pessoa. Em situações extremas, no caso de uma total ignorância sobre a pessoa, podemos apostar nela, mas não confiar. A medida que conhecemos alguém e o relacionamento amadurece, começamos a acreditar na nossa capacidade de formar uma expectativa positiva.

Por sua própria natureza, a confiança leva ao risco do desapontamento ou abuso. Assim, quando confio em alguém, estou pressupondo que essa pessoa não tentará tirar vantagem disso. Essa disposição para assumir riscos é comum a todas as situações que envolvem confiança.

A confiança parece ser um atributo essencial associado à liderança. Quando esta confiança é perdida, o desempenho do grupo pode sofrer efeitos adversos graves.

O conhecimento recente (apenas lembrando que o livro de Robbins é de 2005) trouxeram as manchetes dos jornais a questão da confiança: “Worldcom frauda contabilidade em operações que somam quase 4 bilhões de dólares”. “Executivos da Enron manipulam informes financeiros da empresa”. “Presidente da Tyco International é multado por fraude em impostos sobre faturamento”. “Merrill Lynch paga 100 milhôes de dólares de multa por enganar investidores”. “Stanley Works tenta sonegar impostos criando empresa-fantasma nas Bermudas”. “Martha Stewart é acusada de se beneficiar de informações sigilosas no mercado de ações, além de obstruir o trabalho da justiça”. “Centenas de padres católicos envolvidos em casos de abuso sexual”. Além disso, as práticas de reengenharia, downsizing e o crescente uso de mão-de-obra temporária vem corroendo a confiança que os funcionários têm em seus empregadores. Todos esses eventos levantam uma questão: A confiança está diminuindo?

Embora as manchetes citadas sejam de 15 anos passados, se trocarmos o nome de algumas empresas e alguns personagens teremos situações muito semelhantes de estórias se repetindo. Como se o sistema não tivesse condições de aprender com seus erros e os continuasse cometendo. Robbins continua:

Quando se trata das grandes corporações e seus executivos, a resposta varia de acordo com a amostra: se de funcionários ou do público em geral. Este último segmento tem uma péssima opinião sobre os líderes empresariais. Para se ter uma ideia, os bombeiros são considerados sete vezes mais confiáveis que os executivos, e a maioria diz confiar menos nos executivos do que nos advogados. Para alguém dos EUA que vê um advogado como um tubarão, isso é muito significativo. O autor complementa:

Já os funcionários mostram uma confiança bem maior em seus líderes empresariais. O por quê dessa diferença é uma questão pouco clara.

Robbins fala sobre os princípios básicos da confiança:

(1) A desconfiança destrói a confiança – as pessoas confiantes demonstram sua confiança aumentando sua abertura em relação aos outros, passando informações relevantes e expressando sempre suas ideias e intenções. As pessoas que não confiam agem diferente. Elas escondem informações e agem de modo oportunista para levar vantagem.

(2) Confiança gera confiança – demonstrar confiança na outra pessoa pode criar reciprocidade. Os líderes eficazes vão construindo a confiança aos poucos e encorajam os liderados a responder da mesma maneira. Ao oferecer sua confiança aos poucos, os liderados reduzem os riscos no caso de sua confiança ser traída.

(3) O crescimento muitas vezes mascara a desconfiança – o crescimento dá aos líderes a oportunidade de promoções rápidas e também maior poder e responsabilidade. Neste contexto, os líderes tendem a enfrentar as dificuldades com medidas paliativas, que escapam da atenção imediata de seus superiores, e deixam os problemas que surgem da desconfiança para seus sucessores.

(4) A redução de pessoal (ou downsizing) testa o mais alto grau de confiança – demissões são assustadoras. Mesmo depois de terminados os cortes, aqueles que sobreviveram em seus empregos se sentem inseguros. Quando o empregador destrói o laço de lealdade, demitindo funcionários, há menos disposição entre os trabalhadores para confiar naquilo que seus dirigentes dizem.

(5) A confiança aumenta a coesão – confiança significa que as pessoas podem contar umas com as outras. Quando enfrentam adversidades, os membros de uma equipe que confiam uns nos outros trabalham juntos e são capazes de grandes esforços para atingir as metas do grupo.

(6) A desconfiança destrói o grupo – quando os membros da equipe desconfiam uns dos outros, eles se repelem e se separam. Eles buscam seus objetivos pessoais em vez daqueles de interesse do grupo. Eles tendem a não acreditar uns nos outros, estão sempre alertas contra explorações e restringem sua comunicação. Estas atitudes tendem a prejudicar ou, até mesmo, a destruir o grupo.

(7) A desconfiança geralmente reduz a produtividade – embora não se possa afirmar que a confiança necessariamente aumenta a produtividade, ainda que isso geralmente aconteça, a desconfiança quase sempre reduz a produtividade. As pessoas sonegam informações e buscam secretamente atender a seus próprios interesses. Quando enfrentam problemas, funcionários evitam compartilhar com os outros, temendo ser prejudicados. O clima de desconfiança estimula formas disfuncionais de conflitos e dificulta a cooperação.

Ainda é muito oportuno lembrar o que Ganis, Ackerbauer e Cariello afirmam em um trecho de seu artigo Why Some Agile Teams Succeed and Others Do Not (Por que algumas equipes Ágeis são bem sucedidas e outras não):

Nós acreditamos que, a medida que as equipes se tornam mais consistentes em como entregam lançamentos de sucesso ou produtos mínimos viáveis ​​(MVPs), elas começarão a construir uma confiança mais profunda em sua liderança. Então, à medida que a “janela de confiança” entre as equipes de desenvolvimento e a liderança aumenta, as equipes se tornarão mais receptivas à experimentação e terão maior probabilidade de inovar enquanto continuam a aprimorar seu entendimento e implementação de práticas Ágeis. Além disso, com mais confiança, a liderança se sentirá mais confortável permitindo que as equipes executem seus processos Ágeis e, portanto, mais disposta a aceitar um lançamento incremental de um MVP com a confiança de que o melhor ainda está por vir.

Sim, certamente a confiança é a essência da liderança ágil e do trabalho em equipe. Bem, acho que conseguimos desenvolver bem o tema da confiança e sua importância. Então, está falado. Até a próxima.

Referências:

Ganis, M., Ackerbauer, M., Cariello, N. The Speed of Trust: Why Some Agile Teams Succeed and Others Do Not. Postado em 29/abril/2020 em Business Agility & Software Engineering Excellence, Business Technology & Digital Transformation Strategies Cutter Business Technology Journal. Disponível em:

< https://www.cutter.com/article/speed-trust-why-some-agile-teams-succeed-and-others-do-not>

 

Lencione, Patrick. Os 5 desafios de equipes: uma fábula sobre a liderança. Rio de Janeiro: Elsevier, 2003.

 

Maxwell, John C. O Líder 360º. 2ª. Edição. Rio de Janeiro: Thomas Nelson Brasil, 2012.

 

Pfeiffer, Peter. Facilitação de Projetos – conceitos e técnicas para alavancar equipes. Rio de Janeiro: Brasport, 2006.

 

Robbins, Stephen. Comportamento Organizacional. 11ª. Edição. São Paulo: Pearson Prentice Hall, 2005.

 

Vargas, Ricardo e Nir, Michael. Construindo Times Altamente Eficazes. Rio de Janeiro: Brasport, 2014.

 

terça-feira, 6 de outubro de 2020

Vamos falar do “Sprint Creep”





Links para plataformas de PODCAST:

Plataforma SPOTIFY >

https://open.spotify.com/show/7rLe4pURFDPSpVHS7zDuA1

Plataforma RADIO PUBLIC > 

https://radiopublic.com/h12s-podcast-8X2aYk

Plataforma ANCHOR > 

https://anchor.fm/haroldo-m-c-simoes/

...........................................................

Justiça seja feita, esse termo Sprint Creep apareceu no artigo de Bart Gerardi, de setembro de 2020, chamado What About Sprint Creep? (que traduzindo seria E quanto ao Sprint Creep?), publicado no website projectmanagement.com.

Link para acessar esse artigo >>

https://www.projectmanagement.com/articles/654814/What-About-Sprint-Creep-

Lembrando que esse website é dedicado ao gerenciamento de projetos e para acessar os conteúdos completos dos materiais ali publicados é necessário se registrar e fazer o login. Para os seguidores do blog eu posso enviar um PDF desse artigo, bastando apenas o envio de um email para o enderêço h12sblog@gmail.com .

O texto fará referências aos papéis, artefatos e cerimônias encontradas no método Scrum de gerenciamento ágil de projetos. Para os iniciantes, vou descrever esses papéis, artefatos e cerimônias de forma geral e resumida aqui, em seguida. No final desse texto você poderá encontrar sugestões de links com mais detalhes e informações adicionais sobre o método Scrum.

No Scrum são estabelecidos os Sprints. Um Sprint é um ciclo ou período de tempo (também chamado de “Time Box”) em que um conjunto de atividades deve ser executada. O Sprint é o engrenagem principal do mecanismo que movimento o Scrum.

Em linhas gerais, se eu tenho um produto para ser desenvolvido, eu não faço esse desenvolvimento todo de uma vez. Eu divido o produto em partes e executo essas partes em ciclos ou sprints. Tipicamente, um sprint tem duração de 1 a 4 semanas.

O Product Backlog é a lista de requisitos e funcionalidades desejadas para desenvolvimento de um produto – que podemos considerar como inteiro e completo. Quando eu divido o produto em partes, eu também divido o Product Backlog em partes. Cada uma dessas partes é registrada em um Sprint Backlog.

O Sprint Backog é, portanto, uma lista de itens selecionados dentro do Product Backlog (formando uma parte do produto) que a Equipe planeja concluir dentro do Time Box de um Sprint. Então, ainda em linhas gerais, tudo se passa como se o projeto iniciasse e fosse avançando, com a equipe executando diferentes partes do produto dentro dos Sprints. A equipe executa um certo número de Sprints até que o produto completo é concluído.

O Scrum considera 3 papéis fundamentais: o Product Owner, o Scrum Master e a Equipe do projeto.

O Product Owner (ou Dono do Produto) é o responsável por gerenciar o Product Backlog, com função de priorizar as entregas. Por sua vez, o Scrum Master é o responsável por garantir que todos trabalhem e sigam as regras do processo, participem das suas cerimônias e usem corretamente seus artefatos. E finalmente a Equipe é a responsável pelo desenvolvimento e entrega do produto.

São artefatos obrigatórios do Scrum: o Sprint Backlog e o Product Backlog.

São cerimônias do Scrum – a Sprint Planning (é a reunião de planejamento do sprint), As Daily Meetings (são reuniões diárias de acompanhamento do trabalho que está sendo executado), a Sprint Review (é uma revisão sobre o que foi feito durante o sprint) e a Sprint Retrospective (é uma retrospectiva do sprint sobre como trabalhamos e o que pode ser melhorado).

Bem, continuando, Gerardi menciona em seu artigo que nos projetos com gestão tradicional um gerente de projeto precisa ficar atento e tentar evitar mudanças de requisitos, novas solicitações e outras adições a um projeto em andamento - todas ocorrências comuns conhecidas como “scope creep”. Na verdade, o “scope creep” é frequentemente considerado um grande risco para um projeto e aparece em relatórios amplamente divulgados como uma das razões pelas quais os projetos não têm sucesso. Se um gerente de projeto não for cauteloso, os requisitos podem se multiplicar, causando atrasos nas entregas, atrasos no cronograma, estouro do orçamento ou até o cancelamento do projeto.

Sim, o “scope creep” é um problema para os projetos tradicionais, com planos estabelecidos no início e, com orçamentos e recursos fixos. No entanto, de acordo com Gerardi, isso não deve ser um problema para projetos que operam com os princípios ágeis. Ainda, segundo o autor, em círculos ágeis, o “scope creep” é às vezes chamado de “sprint creep” – com novas tarefas sendo inseridas em um sprint já planejado ou com as tarefas existentes recebendo requisitos expandidos.

Nos projetos tradicionais, os líderes são, geralmente, resistentes a esses tipos de mudanças. Eles trabalham com um processo de Controle Integrado de Mudanças que estabelece que devemos fazer uma revisão, ou melhor, uma análise dos impactos da mudança nos custos, no cronograma, na qualidade, no que deverá ser replanejado, e assim por diante. Essa análise, portanto, é necessária para que se conheça os impactos gerados pela mudança. Será necessário saber se a mudança solicitada vale a pena e se a mesma traz benefícios para o projeto. O resultado dessa análise nos leva a conhecer as mudanças aprovadas e, consequentemente, resulta em uma atualização do plano de gerenciamento do projeto.

Gerardi afirma que embora essa abordagem às vezes seja necessária em um projeto não ágil, ela é inadequada para uma equipe que trabalha de maneira ágil. Em vez de resistir à mudança, uma equipe ágil a acolhe e descobre como se adaptar a ela.

É nesse ponto de seu texto que o autor apresenta como pensa que um gerente deve tratar as solicitações de mudança em um projeto ágil. Então vejamos:

No Agile, não deve haver algo como “sprint creep”, apenas "novo trabalho" - o que significa trabalho que ainda não foi concluído. Isso é igualmente verdadeiro se for uma nova história de usuário, um novo requisito funcional ou não funcional ou mesmo uma nova ideia que não surgiu na última vez que o backlog foi preparado ou o sprint planejado. Uma equipe ágil está sempre dando boas-vindas a novos trabalhos em seu backlog ou considerando novas ideias para inclusão em um lançamento. Isso não significa que a equipe deva aceitar toda e qualquer sugestão ou interrupção, ou simplesmente adicionar um novo trabalho sem análise, no entanto.

Essa parte me fez acender um sinal de alerta. Como assim, sempre dando boas-vindas a novos trabalhos no seu backlog? Dar boas-vindas significa dizer sim, pode entrar! Afinal de contas, ninguém dá boas-vindas dizendo sinto muito, você não pode entrar. Se, por outro lado, eu tiver que analisar antes de dizer sim, não estou “sempre” aceitando novos trabalhos. Bem, vamos seguir o texto e ver onde ele vai nos levar.

Aqui estão algumas idéias sobre como lidar com novas solicitações durante um sprint.

Solicitações de mudança que não ajudam a atingir a meta do sprint - Provavelmente é óbvio, mas para considerar assumir um novo trabalho em um sprint, ele deve estar alinhado com o objetivo geral do próprio sprint. Se algo novo chegar que não ajudará a atingir a meta, mas ainda for considerado urgente ou de maior prioridade, a equipe e o Product Owner devem considerar o replanejamento de todo o sprint. Raramente faz sentido distrair a equipe com um trabalho que não esteja alinhado com o propósito geral e quase sempre levará ao fracasso da meta. Certamente pode haver exceções, como uma solicitação muito pequena ou talvez uma solicitação de operações ou segurança da informação que possa ser tratada, mas novas tarefas relacionadas a histórias de usuário devem aguardar um Sprint futuro. Me parece que esse ponto foi tratado com muita clareza e eu concordo plenamente com essa abordagem. Continuando:

Solicitações que estão alinhadas com a meta - Se a solicitação ajudar a atingir o objetivo geral, o Product Owner e a equipe devem discutir o valor relativo do novo item. Se o valor for realmente maior do que o que a equipe está trabalhando atualmente, então a equipe deve pelo menos estar aberta à ideia de enfrentá-lo.

Lembrando aqui que, dependendo de cada caso, a nova tarefa poderá ser simplesmente inserida junto com as que já estavam sendo executadas ou uma ou mais tarefas que estavam em execução poderão ser removidas, para dar espaço a essa nova tarefa. De qualquer modo o planejamento do sprint deverá ser refeito e isso implica em interromper o trabalho que vinha sendo feito para redefinir o que será executado durante o sprint. Continuando:

Se essa solicitação de mudança – que é uma nova história de usuário – for aceita e inserida no sprint o gerente de projetos ainda deverá responder as seguintes perguntas:

A equipe ainda sente que o sprint é alcançável? O Product Owner concorda que o novo sprint é de maior valor do que o antigo? Existe algum outro motivo pelo qual o custo da interrupção é menor do que o valor criado?

Agora é a hora de considerar todas essas coisas e determinar se o novo item pode ser adicionado e o que deve ser removido. 

Gerardi nesse ponto do texto discute a urgência da mudança. Continuando: -

Mesmo que a nova história seja considerada de alta prioridade e de alto valor, ainda existe o custo de interromper um sprint em execução para adicionar essa nova história, com a discussão na equipe para determinar opções e escolher um novo caminho.

Além de falar sobre a prioridade e o valor da solicitação de mudança, a equipe e o Product Owner também devem falar sobre sua urgência. Se a nova história for inserida no próximo sprint, os clientes a usarão imediatamente? Existe uma razão pela qual a história precisa ser acelerada? Qual será o impacto negativo para o produto ou para o cliente se a história esperar até o próximo sprint?

O autor conclui afirmando que:

Em um projeto não ágil, o escopo deve ser estritamente gerenciado e o trabalho inesperado ou “scope creep” pode criar um risco para a entrega geral do projeto. Em um projeto de execução ágil, o oposto é verdadeiro. Novas solicitações não devem ser temidas, elas são apenas novos itens de sprint que podem ser considerados para adição a um sprint. Contanto que um novo item tenha tempo para ser adequadamente preparado e analisado, esteja alinhado com a meta geral do sprint e forneça valor imediato ao produto ou cliente, vale a pena pensar em adicionar, mesmo em um sprint em execução.

E certas coisas podem nem mesmo ser consideradas adições, mesmo que sejam itens realmente novos.

Agora, aqui entre nós: Ter um critério significa seguir o seguinte raciocínio: - Eu aceito se esse novo trabalho ou se essa nova história de usuário passar pelos critérios definidos para que algo novo seja aceito.

Caso contrário, esse novo trabalho não será aceito. Isso, sem enrolação, é seguir um critério de aceitação para que algo novo seja incluso no sprint.

Então, me parece que na ânsia de se mostrar alinhado aos princípios ágeis, o autor escolheu, do ponto de vista prático, as ideias contidas no bom e velho processo de Controle Integrado de Mudanças do guia PMBOK. A propósito, são todas ótimas ideias do autor apresentadas no artigo.

Os gerentes de projeto sempre buscaram usar as melhores práticas, ferramentas e técnicas para alcançar o melhor resultado, para tornar o projeto bem-sucedido, dentro de certa realidade e circunstâncias, com restrições e recursos disponíveis (dinheiro, tempo, pessoas, tecnologia). Eles (e elas) usaram essa abordagem porque fazia mais sentido, era adaptada às necessidades específicas de cada projeto e produzia os resultados desejados. Portanto, não há nenhum demérito em usar os princípios do processo de Controle Integrado de Mudanças para tomar uma decisão sobre uma solicitação de mudança em um projeto ágil.

Para gerenciar um projeto é necessário utilizar o conhecimento de múltiplos domínios e campos do conhecimento, além de manter a mente aberta para perceber e descobrir o que funciona. Fazemos o que funciona e quando não funciona, tentamos descobrir algo diferente. Se nos esquecemos desse princípio, estaremos colocando nossos projetos em risco. Bem, então tá falado. Até a próxima.

..................................................

Uma rápida leitura em http://h12sse.blogspot.com/2014/05/mais-um-pouco-de-scrum.html pode ajudar a entender os Sprints e o trabalho do Product Owner no Scrum.

Para mais informações acesse > https://blog.trello.com/br/scrum-metodologia-agil      ou   https://www.scrum.org/



domingo, 4 de outubro de 2020

H12S PODCAST

 


                          LINK >>>

Plataforma SPOTIFY >

https://open.spotify.com/show/7rLe4pURFDPSpVHS7zDuA1

Plataforma RADIO PUBLIC > 

https://radiopublic.com/h12s-podcast-8X2aYk

Plataforma ANCHOR > 

https://anchor.fm/haroldo-m-c-simoes/


De agora em diante vamos disponibilizar além dos textos dos artigos que você encontra no blog, também os áudios de alguns desses artigos. Tudo isso vai estar disponível em um PODCAST. No blog você encontrará os links para acessar o nosso PODCAST diretamente no SPOTIFY e em outras plataformas. Os links para o nosso áudio de apresentação estão bem aí em cima, logo abaixo da imagem! Então, tá falado. Até a próxima.

                           ***********************************************

terça-feira, 22 de setembro de 2020

SQUADS para implementar agilidade organizacional

Muito tem se falado nos squads, equipes multidisciplinares que trabalham com agilidade. Essa ideia, implementada para valer na Spotify à partir de 2011, tem sido adotada em muitas empresas pelo mundo e também aqui no Brasil.




Por conta da necessidade de transformação digital, o ambiente de trabalho ágil está se tornando cada vez mais comum. Uma pesquisa da McKinsey, com mais de 2.500 pessoas em empresas de diferentes tamanhos, verificou que 37% dos entrevistados disseram que suas organizações estavam implementando ações relacionadas a transformação ágil. Essa mudança é impulsionada pela prova de que equipes pequenas e multidisciplinares das organizações ágeis podem responder com rapidez e prontidão às oportunidades de mercado e às demandas dos clientes em constante mudança. Essas equipes chamadas de squads têm grande autonomia. 

No Brasil já existem empresas que adotaram a agilidade organizacional através de squads. Uma rápida pesquisa no Google e no Youtube mostrará vários casos de squads em empresas que operam em território brasileiro como, por exemplo, Nubank, Whirlpool, Unilever, Natura e Vivo.

O texto “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds”, de Henrik Kniberg & Anders Ivarsson, datado de outubro de 2012, apresenta a ideia geral dos squads. Aqui, nesse post, vamos apresentar os conceitos principais sobre esses squads. Há dezenas de websites com artigos, entrevistas e videos que tratam desse assunto e recomendamos que o leitor acesse esse material caso deseje se aprofundar no assunto. O texto acima mencionado pode ser facilmente encontrado através de uma pesquisa no Google. Entretanto, se o seguidor do blog tiver dificuldade em encontra-lo, terei prazer de enviar por email.

Scaling Agile @ Spotify (um resumo do texto original) –

Lidar com várias equipes em uma organização de desenvolvimento de produto é sempre um desafio! Um dos exemplos mais impressionantes que vimos até agora é o Spotify, que manteve uma mentalidade ágil apesar de sua expansão para mais de 30 equipes em 3 cidades.

O Spotify é uma empresa fascinante que está transformando a indústria musical. A empresa existe há apenas 6 anos e já tem mais de 15 milhões de usuários ativos e mais de 4 milhões de pagantes. O próprio produto pode ser comparado a um reprodutor de música mágico no qual você pode encontrar e tocar instantaneamente todas as músicas do mundo.

Então, como isso é gerenciado? Nós já apresentamos em conferências e fomos pegos em discussões envolventes sobre como trabalhamos no Spotify e como a empresa lida com agilidade com centenas de desenvolvedores. Muitas pessoas são fascinadas por isso, então decidimos escrever um artigo sobre isso.

Squads - Um squad é semelhante a uma equipe Scrum, e é projetado para parecer uma mini-startup. Eles se sentam juntos, e eles tem todas as habilidades e ferramentas necessárias para projetar, desenvolver, testar e liberar para produção. Eles são uma equipe auto-organizada e decidem sua própria maneira de trabalhar - alguns usam sprints (do Scrum), alguns usam Kanban, alguns usam uma combinação dessas abordagens. Cada squad tem uma missão de longo prazo, como construir e melhorar o cliente Android, criando a experiência de rádio Spotify, dimensionando os sistemas de back-end ou fornecendo soluções de pagamento.

Um squad não tem um líder de esquadrão (chefe) formalmente nomeado, mas tem um product owner. O product owner é responsável por priorizar o trabalho a ser feito pela equipe, mas não está envolvido com a forma como eles fazem o trabalho deles. Os product owners de diferentes squads colaboram uns com os outros para manter um documento de roadmap de alto nível que mostra para onde o Spotify como um todo está se dirigindo, e cada product owner é responsável por manter uma carteira de produtos (product backlog) correspondente para seu squad.

Tribos - Uma tribo é uma coleção de squads que trabalham em áreas relacionadas - como no tocador de música ou na infraestrutura de back-end. A tribo pode ser vista como uma “incubadora” das mini-startups e tem um certo grau de liberdade e autonomia. Cada tribo tem um líder que é responsável por fornecer o melhor ambiente possível para os squads dentro daquela tribo. Os squads de uma tribo estão todos fisicamente no mesmo escritório, normalmente ao lado uns dos outros, e as áreas de lazer próximas promovem a colaboração entre os times.

As tribos são dimensionadas com base no conceito do "número de Dunbar", que diz que a maioria das pessoas não pode manter um relacionamento social com mais de 100 pessoas (O Spotify adotou o número 100, embora o número de Dumbar seja 150. Ver artigo sobre o número de Dumbar aqui!). Quando grupos ficam muito grandes, começamos a ver mais coisas  como regras restritivas, burocracia, política, camadas extras de gestão e outros resíduos. Portanto, as tribos são projetadas para ter menos de 100 pessoas.

Com vários squads, sempre haverá dependências. Dependências não são necessariamente ruins – squads às vezes precisam trabalhar juntos para construir algo realmente incrível. No entanto, nosso objetivo é ter squads que sejam tão autônomos quanto possível, especialmente minimizando dependências que possam causar bloqueios ou retardos.

Uma fonte comum de problemas de dependência em muitas empresas é o desenvolvimento versus operações. A maioria das empresas com as quais trabalhamos têm algum tipo de transferência do desenvolvimento para operações, com atrito associado e atrasos. Na Spotify, há uma equipe de operações separada, mas seu trabalho não é liberar os squads – seu trabalho é dar aos squads o suporte de que precisam para liberar o código por conta própria; suporte na forma de infraestrutura, scripts e rotinas. Eles estão, de certo modo, “construindo o caminho para a produção”.

Capítulos e Guildas – Os Capítulos e Guildas são a cola que mantém a empresa unida, e nos dá algumas economias de escala sem sacrificar muita a autonomia. O Capítulo é uma pequena família de pessoas com habilidades semelhantes, trabalhando dentro da mesma área de competência e dentro de uma mesma tribo.

Cada Capítulo se reúne regularmente para discutir sua área de especialização e seus desafios específicos - por exemplo o Capítulo de teste, o Capítulo de desenvolvedores web ou o Capítulo de backend. O líder do Capítulo é o gerente de linha dos membros do Capítulo, com todas as responsabilidades tradicionais, como desenvolver pessoas, definir salários, etc. No entanto, o líder do Capítulo também faz parte de um squad e está envolvido no trabalho do dia a dia, que o ajuda a ficar em contato com a realidade.

Uma Guilda é uma "comunidade de interesse" mais orgânica e abrangente, um grupo de pessoas que deseja compartilhar conhecimento, ferramentas, código e práticas. Os Capítulos são sempre locais para uma tribo, enquanto uma Guilda geralmente corta toda a organização. Alguns exemplos são: a Guilda de tecnologia da web, a Guilda de testadores, a Guilda de treinadores, etc.

O Spotify cresceu muito rápido - ao longo de 3 anos, crescemos de 30 para 250 pessoas em tecnologia - então temos nossa parte da dor de crescimento! Este modelo de escala - com squads, tribos, capítulos e guildas - é algo que foi introduzido gradualmente ao longo do ano passado, por isso as pessoas ainda estão se acostumando a ele. Mas até agora, com base em pesquisas e retrospectivas, o modelo parece estar funcionando muito bem! No entanto, como acontece com qualquer organização em crescimento, as soluções de hoje geram os problemas de amanhã. Então fique sintonizado, a história não acabou: o).

*******************

Nubank -

As demandas são definidas e priorizadas de acordo com os OKRs (Objectives & Key Results) do squad, que são determinados de acordo com os OKRs da empresa, e com os ganhos/gastos previstos por modelos que as pessoas que trabalham com BA (Business Analytics) analisam. Se uma determinada tarefa tem potencial de fazer com que o squad atinja algum ou alguns OKR(s), então ela é detalhada, discutida com todos os chapters (Capítulos) que serão envolvidos, antes de ser feita. Em geral, o prazo não é o componente mais crucial de um OKR, - dado que não passamos por cima da qualidade para cumprir um prazo. No entanto, como um dos valores da empresa é “We think and act like owners, not renters” (“Nós pensamos e agimos como donos, não como inquilinos"), a grande maioria das pessoas quer “shipar” - colocar coisas em produção. A ideia de entrega contínua é forte e existem ferramentas internas feitas para garantir que tudo que seja produzido, vá para experimentação do público - que às vezes são os próprios Nubankers (colaboradores do Nubank) - o mais rápido possível, com a maior qualidade e de forma mais eficiente. Quando algo está muito repetitivo e tomando muito tempo do time, automatizamos. Expressões como "feedback rápido" e "vamos aprender a não ter medo de errar" são comumente ouvidas nos corredores” (Kete Martins Rufino. Clique no link abaixo para ler a matéria completa).

 

https://medium.com/mulheres-de-produto/como-funcionam-os-squads-no-nubank-e1194a6f2a9e

*******************

Natura -

“A gente aprovou com nosso vice-presidente a estrutura do lab e como ele funcionaria. Depois, combinamos com ele que pediríamos mais desculpas que permissão e em alguns processos conseguimos quebrar as burocracias. Isso é muito simbólico porque estamos falando de uma empresa gigante, a Natura é muito grande, tem muitos processos, muitos comitês, toda decisão aqui é muito compartilhada.

A gente não tinha um squad oficial, a gente montou um time exclusivo focado só nos testes que estávamos fazendo aqui dentro do Movimento Natura. Grandes times de trabalho multidisciplinares comprometiam muito o propósito da entrega final. Entendemos então, que times grandes não dão certo.

Quando a gente chega à conclusão de qual teste que a gente vai fazer e qual a solução que a gente vai testar, chamamos a pessoa do time daquela área que provavelmente será a área de quando o teste for validado. Se for validado ela vai escalar. A pessoa que participa desde o começo do time está muito engajada, e vai conseguir implementar isso com velocidade, e com mais agilidade também” (Diana Guimarães. Clique no link abaixo para ler a matéria completa).

https://www.ubistart.com/blog/natura-como-montar-squads-para-desenvolvimento-de-testes/

*******************

Vivo –

“Para Luiz Medici, vice-presidente de Inteligência Artificial da Vivo, o grande impulso para começar a organizar o trabalho em squads veio das empresas digitais. A Vivo viu a entrada de players digitais alcançando resultados muito rápidos e entendeu que um dos catalisadores disso era a forma de trabalho em ambientes colaborativos. "Para competir nesse mercado novo digital, precisamos nos reinventar." A operadora começou a usar grupos de trabalho em 2018, com o laboratório digital. Agora, são mais de 100 squads em funcionamento” (Extraído de matéria publicada no Correio Braziliente. Clique no link abaixo para ler a matéria completa).

https://www.correiobraziliense.com.br/app/noticia/economia/2019/07/29/internas_economia,788500/empresas-da-velha-economia-imitam-as-startups.shtml

 

Bem, é isso ai, até a próxima!

 


quinta-feira, 17 de setembro de 2020

ORIENTAÇÃO DE TCC ONLINE

Olá pessoal, 

Obrigado por me acompanhar no blog. Vamos falar mais uma vez sobre orientação de TCC online!!!



Eu gostaria de começar dizendo que a escolha do tema do TCC é o início do trabalho e, geralmente, esse tema deve estar conectado aos interesses do aluno. E por que isso? O interesse real significa que o trabalho terá valor para o aluno. Recentemente, fiz algumas sugestões no artigo Temas Atuais para o TCC do seu MBA em Gestão de Projetos que você poderá acessar através do link abaixo. 

http://h12sse.blogspot.com/2020/08/temas-atuais-para-o-tcc-do-seu-mba-em.html

Uma vez escolhido o tema, surgem outros aspectos importantes que irão definir o caminho que o TCC deverá seguir como, por exemplo, os objetivos do trabalho, as hipóteses e as perguntas que serão respondidas pela pesquisa do aluno. Um desses aspectos é identificar se a Instituição de Ensino permite que o TCC seja baseado apenas em pesquisa bibliográfica ou, por outro lado, se o aluno terá que usar um estudo de caso (projeto desenvolvido pelo aluno), além da pesquisa bibliográfica.

Há instituições que não permitem monografias que usem apenas o estudo de livros e artigos (pesquisa bibliográfica). Geralmente, as faculdades fornecem um documento com as normas de elaboração de monografias e nesse documento essas regras são definidas. Recomendo que você verifique isso antes de iniciar o seu TCC.

Não é de agora que estou prestando serviços de orientação de TCC online, já faço isso há bastante tempo. Tenho trabalhado com estudantes de várias Instituições de Ensino como, por exemplo, FGV, USP/ESALQ/PECEGE, Centro Universitário SENAC, Kroton Educacional/Anhanguera, Estácio Pós-graduação MBA, Universidade de Uberaba, com excelentes resultados até o presente momento. Sim, me orgulho muito disso! O fato mais importante é que, sem exceção, é o estudante que escreve seu trabalho, que é o dono e autor do seu texto, sendo minha parte apenas a orientação. Evidentemente, meu trabalho não substitui o orientador(a) do aluno em sua faculdade, mas facilita o relacionamento do estudante com seu orientador(a) de forma mais produtiva, para elaboração da monografia.

A ideia na orientação é ajudar o aluno em cada passo do trabalho, desde a escolha do tema até o artigo final ficar pronto. Meu trabalho inclui: 

- Ajuda na escolha do tema; 

- Suporte na elaboração do projeto de TCC; 

- Esclarecimento de dúvidas; 

- Estrutura de capítulos do artigo; 

- Sugestões de referências bibliográficas; 

- Uso correto das citações no texto conforme a norma ABNT; 

- Correções do texto do ponto de vista de estilo e gramática nas diferentes versões do aluno até que o texto final fique pronto; 

- Auxílio no uso de artigos em inglês (sou fluente); 

- Verificação de plágio; 

- Dicas para a defesa oral;

A orientação acontece por e-mail, mensagens de texto e chamadas de voz via whatsapp e, também, chamadas de voz via telefone celular (eu ligo para o aluno no dia e horário combinados). Se desejar conversar por telefone pode me enviar seu número através do email  h12sblog@gmail.com  que ligarei para você. Mais uma vez agradeço por sua atenção.

 Atenciosamente, 

Prof. Haroldo Simões