Motivação, Engajamento ou Comprometimento?

Como é difícil conceituar essas três palavras… Ainda mais dentro do ambiente empresarial.

A motivação é decorrente de fatores internos do ser humano, do seu estilo de vida, valores e crenças, objetivos e necessidades, ou seja, é pessoal. O papel da empresa é fazer com que o colaborador desenvolva esta motivação em sua rotina de trabalho.

E o que vem a ser engajamento?

“O engajamento profissional é uma combinação de comprometimento funcional e emocional.” – Mark Schumann

É o entusiasmo a satisfação pelo trabalho. É fazer com que o funcionário se sinta envolvido com a organização. Ele deve perceber que seu trabalho interfere diretamente em toda a cadeia de negócio da organização, gerando frutos e retorno direto. Não é apenas fazer o próprio trabalho bem feito, mas sim contribuir para que o todo faça da melhor maneira possível.

E onde fica o comprometimento?

Não basta pessoas motivadas e engajadas quando se deseja alcançar o diferencial de mercado, é imprescindível a presença do comprometimento, tanto do colaborador quanto da organização.

Existe uma antiga piada na qual uma galinha e um porco estão conversando e a galinha diz: “Vamos abrir um restaurante.” O porco responde, “Boa ideia, mas como iremos chamá-lo?” “Que tal ‘Presunto e Ovos’”, diz a galinha. “Não, obrigado” diz o porco. “Eu estaria comprometido enquanto você estaria apenas envolvida.”

Estar comprometido com um resultado nos ajuda a manter a calma diante das adversidades e obstáculos que nos cercam.

Mas quais são os fatores que determinam o comprometimento?

Eugenio Mussak, em seu livro Caminhos da Mudança (2008) identifica as cinco condições básicas para que ocorra o comprometimento, em qualquer tipo de relação:

1.    Admiração

2.    Respeito

3.    Confiança

4.    Paixão

5.    Intimidade

Isso significa que só ficamos ao lado de alguém que admiramos, e da admiração surge o respeito, que gera a confiança e a paixão e com todos estes ingredientes juntos queremos continuar convivendo com esta pessoa e sendo íntimos. Resumindo, é a soma destes fatores que sustenta uma relação, seja ela profissional ou pessoal.

Fontes:

http://www.efetividade.net/2010/06/22/comprometimento-e-a-vontade-de-fazer-parte-de-uma-historia/

http://www.fredgraef.com.br/blog/index.php/artigos/video-lideranca-consciencia-comprometimento-e-engajamento/

Imagem: http://www.flickr.com/photos/merwing/530535214

Binary Search: Uma roleta russa com o tambor cheio

O tema  Binary Search não é bem agilidade, mas esse temido comando do ABAP pode nos fazer perder muito tempo. Eu já perdi muito tempo tentando resolver um deifeito que era decorrente apenas de uma clausula dessas. Para tentar exemplificar o que é o Binary Search, vou explicar rapidamente a estrutura de seleção de dados de banco de dados do SAP.

A grande maioria dos dados são selecionados e armazenados em tabelas temporárias.  Essas tabelas funcionam como um vetor ou um cursor em outras linguagens de programação. Para selecionar uma linha em especial, usa-se um comando chamado read com as chaves do registro da tabela temporária que deseja retornar. Simples, não? Mas o SAP tem outra peculiaridade, ele é dividido em camadas (serviço de banco de dados e serviço de aplicação). Dizem, que o serviço de aplicação é muito forte, por isso, seria mais vantagioso, por exemplo, selecionar várias linhas de uma tabela de banco de dados e depois filtrá-la através de comandos como read  e etc.

Porém, com um volume enorme de linhas, mesmo um read na camada de aplicação acaba tornando-se demorado, então-se tem a clausula Binary Search  que pode ser adicionada em um comando read. O que ela faz? A leitura não é feita mais sequencialmente, e sim quebrando a tabela pela metade, tornando o acesso mais rápido. Mas temos que ter os registros em ordem, pois caso contrário, pode-se ter um retorno errado. Exemplo: Temos a tabela temporária abaixo com apenas 1 campo na ordem conforme está:

01
02
07
05
06
08
09
10

Se usarmos um read com a clausula Binary Search, nessa tabela e procurármos pelo valor 07, o retorno será que o mesmo não existe. Mas porquê? A tabela será dividida em 2, primeiramente, será testado se o valor procurado é menor ou maior que esse valor. Imaginamos que o meio seja o número 05. Então, saberíamos que o valor estaria no subconjunto ente 06 e 10. Faríamos um segundo acesso a tabela e saberíamos que estaria no subconjunto entre 06 e 08 e tendo apenas esses elementos o 07 não existe no conjunto.

Isso tudo acontece, por que a clausula Binary Search tem como pré-requisito que a tabela interna deva estar ordenada, e quando ela não está, o resultado pode ser diferente do que o esperado. Ahh bom, simples então: vou apenas ordenar a tabela interna e está tudo resolvido.

Concordo plenamente com essa afirmação, o problema é ter certeza que ninguem nunca mais irá alterar a ordem desa tabela e sempre ficará na ordem esperada pelo read.

Para apimentar mais ainda tudo isso, algumas consultorias da SAP não tem muito critério técnico na contratação de desenvolvedores de software. Então imagine, alguém que não tenha um conhecimento técnico de desenvolvimento usando uma clausula dessa? É certo que algum dia irá falhar.

Imagem 1: http://www.flickr.com/photos/mrcrash/823113691

Imagem 2: http://www.flickr.com/photos/kitsu/261128078

A amizade e o número de itens de Backlog

Adoro as analogias de números e dos processos de gerenciamento de Projetos. E descobri mais um bem interessante lendo o livro Desenvolvimento de Software com Scrum – Aplicando Métodos Ágeis com Sucesso do Mike Cohn. Essa analogia, em especial, limitando o número de itens em um backlog de produto em um time Scrum ao mesmo número de amizades que conseguimos administrar.

Usando a analogia de conhecer pessoas, o número de Dunbar diz que conseguimos ter relação de amizade com no máximo 150 pessoas. Isso já foi inclusive tema de pesquisa e a grande maioria das pessoas que usam a rede social facebook realmente se limitam a esse número.

Essa mesma regra pode existir para itens do backlog de produto de um time Scrum. Como é tarefa do Dono do Produto conhecer esses itens com uma maior profundidade, não deve ser maior que 150 itens.

Mas o que fazemos que tivermos um produto muito grande, onde os itens ultrapassam esse número? O próprio Scrum responde. Como os itens não precisam ser detalhados antecipadamente, podemos deixar um grande número de histórias de usuário em tamanhos épicos e detalhar quando realmente for preciso. E se mesmo assim, o número ainda for grande, podemos criar temas de história

Imagem: http://www.flickr.com/photos/marhoons/3062160992

Como comunicar a mudança

Até mesmo os carrinhos de supermercado tão bem aceitos atualmente, tiveram reistência.

Estou lendo o livro do Mike Cohn titulado Desenvolvimento de Software com Scrum – Aplicando Métodos Ágeis com sucesso. O livro é realmente muito bom, é pena eu estar tendo a oportunidade de lê-lo tão tarde. Acredito até que deve ser um dos primeiros, se não o primeiro livro a ser lido sobre Métodos Ágeis.

Mas falando sobre a mudança, acredito que ela não é natural, precisamos nos educar ou fazermos um esforço para aceitá-la. E não é só com nós, seres racionais que isso ocorre. Vou dar um exemplo:

Tenho uma cadela (vira-lata quase uma dachshund, vulgo linguiçinha). E todo o dia passeio com ela, faço uma volta por algumas quadras e sempre faço o mesmo trajeto na mesma direção, e ela caminha maravilhosamente. Mas tente apenas trocar a direção da caminhada, ela vira outro bicho, quer voltar, tenta fugir e etc. Ou seja, não é natural mudar, ela quer ter previsibilidade do caminho.

E o mesmo acontece conosco, um exemplo clássico é dos carrinhos de supermercado. Eles surgiram para resolver um problema: As pessoas iam ao supermercado e enchiam suas sacolas. Porém, quando ficavam pesadas, as pessoas paravam de comprar. Então, foi inventado o carrinho de supermercado. Mas as pessoas não utilizavam de princípio, não se sentiam à vontade para utilizá-los. E como isso foi resolvido? Sylvan Goldman (invetor do carrinho de supermercado) contratou alguns atores para realizarem compras utilizando os carrinhos. Vendo alguém utilizar, isso acabou se popularizando.

Algumas pessoas opõem-se a qualquer tipo de mudança. Suponho que você poderia entrar em uma empresa, anunciar que todos vão receber um aumento de 20 a 50% e, mesmo assim, haverá resistência. Alguns suspeitariam dos verdadeiros motivos do chefe, outros considerariam o aumento injusto (trabalho mais do que ele, por que ele vai receber um percentual de aumento maior?) Mike Cohn, Desenvolvimento de Software com Scrum – Aplicando Métodos Ágeis com sucesso, página 119.

E nesse ponto, temos outra lição para aprender. A comunicação da mudança deve ter vários níveis hierárquicos para ser aceita pelo máximo de pessoas. No caso dos carrinhos de supermercado, não adiantava apenas propagandas, apelos dos supermercados, precisou-se ver alguém do mesmo nível utilizando para atingir várias pessoas. O mesmo acontece na nossa empresa, clube, escola e etc. Não adianta apenas o diretor falar que a mudança irá ocorrer. Em muitas ocasiões, um par que já aceitou a mudança conversar com outro é muito mais efetivo.

Imagem: http://www.flickr.com/photos/cuitzilart/5371532987/

O poder da discussão e a arte de desenvolver sem codificar

Discutir em frente a um quadro branco é a forma mais efetiva de comunicação

A palavra discussão é uma injustiçada. Mas já parou para pensar o que quer dizer a palavra discussão? Vou demonstrar duas que mais gosto:

1. Análise e troca de ideias sobre um assunto entre duas ou mais pessoas com o objetivo de chegar a um consenso
2. Debate sobre um tema ou uma opinião, em que cada pessoa defende argumentos opostos; polêmica; controvérsia

E o desenvolvimento de software está muito ligado a discussão, a troca e a análise de idéia. Ainda me lembro de uma palestra dada pelo @lcparzianello em um evento sobre Business Analisys. A @schwengberl pode explicar muito melhor isso. Mas dizia mais ou menos isso:

Analisar o negócio do teu cliente em busca de uma solução é a arte de desenvolver sem codificar

O que quero dizer com isso? Claro que o que queremos é gerar código fonte, tem coisa melhor do que gerar código fonte? Porém antes de gerar código fonte, precisamos realmente entender a real necessidade do nosso cliente, e se codificar é realmente a melhor opção. Quem sabe uma mudança ou uma melhoria no processo já resolva?

E para conseguir isso? Discutindo. Não existe melhor ferramenta do que analisar e trocar ideias. E de preferência em frente a um quadro branco para potencializar a comunicação. Eu tenho vários bons exemplos onde isso funcionou muito bem

Imagem: http://www.flickr.com/photos/notemily/4950119983/

Escopo aberto, mas Visão fechada

Triângulo de Ferro do Gerenciamento de Projetos

Já conhece o triangulo de ferro? No BaBrazil tive uma ótima notícia que ele vai sair inclusive do PMBOK na próxima versão. Realmente uma notícia grandiosa para quem gerencia e desenvolve projetos com tanta incerteza.

Porém, sempre que falo de Agilidade e de projetos gerenciados de forma Ágil, a pergunta retorna: Como planejar e principalmente cobrar por algo tão incerto como o desenvolvimento de Software?

A primeira resposta é que vendemos solução e não um conjunto de funcionalidades ou horas de trabalho. Não é a entrega de um escopo planejado que determina o sucesso de um projeto, mas a resolução do problema proposto inicialmente.

E como o framework do Scrum trabalha com isso? O Scrum tem muito forte o conceito de visão de Produto. Temos uma visão do que deve ocorrer e do que deve ser solucionado e desenvolvemos até conseguirmos chegar à visão. A visão permanece fixa, se ela precisar ser alterada, um novo projeto deve ser constituído, pois é a visão a determinante do projeto.

Por outro lado, o escopo pode alterar no decorrer do projeto, para melhor atender a própria visão. O escopo trabalha a serviço da visão e não o inverso.

E existem várias ferramentas que ajudam a determinar a visão, citando algumas: Product Vision Box, Elevator Statement e Project Statement.

Algumas referências:

1. Product Vision - Joel on Software
2. Elevator Statement  ou Elevator Pitch

Está Pronto e Feito? As definições desses dois estados em um Projeto Scrum

Definir os 2 estados de um Item de Product Backlog

Definir esses dois estados de um PBI (Product Backlog Item) é um dos processos mais importantes (se não é o mais) do pré jogo de um projeto Scrum. Vou explicar para que eles servem e como definir.

O estado de Pronto define que um PBI está preparado para ser estimado e começar o desenvolvimento. É responsabilidade do time de desenvolvimento de um Projeto Scrum definir o que deve ter de informação um PBI para a primeira reunião de um Sprint (Sprint Planning). E responsabilidade do Product Owner garantir que todos os PBI que estão no topo do Product Backlog e que possa entrar na próxima Sprint tenha as informações suficientes para estimar e começar o desenvolvimento. Claro que sabemos que como qualquer método ágil, a comunicação precisa ser maximizada e não vai dar para pegar um item e desenvolver do início ao fim sem uma iteração com o Product Owner.

Os 3 c’s de uma User Story são: Cartão, Comunicação e Comunicação. Um cartão de uma User Story é um contrato para começar uma conversa.

Já a definição de Feito garante a qualidade de um PBI trabalhado dentro da Sprint. Esse estado é definido pelo Product Owner e vai ser o critério para aceitar ou não um item. Normalmente garante que um item tenha sido totalmente desenvolvido, testado unitariamente, testes funcionais e de integração. Lembrando que é binário (está Feito ou não).