Blog do Andre Fonseca

Jack Milusnk, em seu blog The Agile Buddy Blog, escreveu um excelente post sobre a questão da histórica técnica. Em tomei a liberdade de escrever uma versão (não tradução) em português do texto. Para quem quiser ler o texto original, acesso o post aqui. Comentários com ajuda na tradução e opiniões são bem vindo.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>

A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog.

Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:

“O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”

Então, qual é a resposta correta?

Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.

Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:

Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog. Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:”O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”Então, qual é a resposta correta? Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Conversando que a gente se entende

Um dos grandes problemas atuais de TI que encontro é a questão da comunicação. Quando esta falha,  tudo falha… mesmo se as outras partes envolvidas estejam “bem feitas”. Sem comunicação, não existe um troca eficiente, a interação entre os membros se perde, há desinformação, entre outros efeitos… sem comunicação não existe possibilidade de time, existe apenas um amontoado de gente trabalhando num mesmo projeto ou atividade.

Antes de mais nada, gostaria de dizer que, quando falo em comunicação,  estou tratando em seu significado mais amplo : comunicação são as conversas, os emails, os quadros de aviso,  as reuniões, os post it na parede… Enfim, ela é tudo que visa a troca de conhecimento ou ideias e informações.  Ao dar bom dia a uma pessoa que trabalha com você, você está se comunicando; ao enviar um mensagem via mensageiros instantâneos (gtalk, msn, yahoo, etc) você está se comunicando.  Muito apenas consideram a parte formal  da comunicação e esquecem que a parte informal é de suma importância.  Se este “bom dia” não acontece, você como líder, pode estar em apuros.

Do pouco que já rodei por aí, já presenciei e participei de diversas situações onde uma comunicação falha, acabou com toda a equipe.  Um dos casos que gosto de citar é de uma empresa onde trabalhei que, o pessoal não tinha uma boa interação e as raras vezes que essa acontecia era para “sacanear”alguém. Isso gerou um desconforto tamanho na equipe, que aos poucos, as pessoas que eram o alvo das brincadeiras ou que não se sentiam confortável com aquilo foram ficando insatisfeitas. Resultado: projeto ruim,  projetos atrasados, etc. Antes que alguém pergunte: “Será possível que um problema pessoal interfira tanto no resultado? Cade o profissionalismo ?”. Não pode esquecer que somos seres humanos e não vulcanos ( momento start trek) … Nossas emoções influenciam diretamente nosso desempenho, ainda mais a nós que somos latinos.

pessoas não conversam

Continuando a história… a comunicação que a principio não tinha nenhuma relação com o desenvolvimento em si, estava causando muitos problemas. Infelizmente não houve solução, as pessoas saíram, e a equipe dissolveu-se.

Bem , se algo que não tem ligação com o dia a dia de projeto já causou um estrago como na história acima, imagine quando falamos de comunicação que fala exatamente do projeto? Se ela for mal feita, o projeto corre sério risco de não dar certo.

Outra história que conto, é de um ex chefe meu que tinha a mania de não expor com clareza o que ele queria, nem explicar de forma clara os requisitos das funcionalidades que eram para ser feitas.  Nas muitas vezes que discuti com ele, exatamente por causa disso, sempre repetia uma frase: “Ainda não sei ler mente, mas quem sabe com o tempo”.  Um requisito mal explicado é pior  ou igual pior que um requisito não dito. Não foram poucas as vezes que o pessoal da equipe acabou implementando funcionalidades incoerentes com o desejado pelo cliente; foi obrigada a refazer tudo por não estar de acordo “como deveria ser” (como se soubessémos por leitura de mente); e por essa estrada o dia a dia seguia.

Mas os problemas não estão somente na parte verbal da comunicação. Acredito, na minha pouca experiência, na maioria  dos casos os grandes problemas estão nas outras comunicações que acabam  esquecidas.  Com a moda de adoção de metodologias ágeis, a questão da comunicação ganhou uma certa importância, mas maior parte dos casos que vejo e ouço de meus amigos, há uma preocupação com a interação verbal, mas esquecem das não verbais (avisos, emails,  alertas, etc) . Pode parecer até uma contrasenso em nossa era, mas parece que estamos cada vez mais nos comunicando pior!  Documentos mais escritos, pouco domínio da lingua, entre outras coisas, dão margem para interpretações equivocadas e com isso perda de tempo por parte do time com implementações incorretas, por exemplo.

afogado em post its

Não sou a favor de um revisor de português para cada empresa, mas sou sinceramente a favor de pessoas que usem bem o meio de comunicação delas.  Não adianta querer escrever um livro para explicar algo por email, nem um frase.  Tem que se dosar, e procura tirar o melhor de cada. Além disso, essa comunicação não verbal, tem que ser intuitiva, leve, fluidica e permitir uma interação entre a mensagem e o espectador.  Gramática correta, ortografica correta, coerencia e coesão,  sintaxe … tudo isso facilita a leitura e deixa a coisa direta e clara.  Canso de ver aberrações em emails de pessoas de cargos de relevancia que no final acabam indo para lixeiras contendo um aviso importante por erros de escrita grosseiros ( erros de uso de “mim”, “amostrar” ao invés de mostrar, falta de pontuação, estrangerismo em excesso – os jobs file executam em multthreading com forks de flocks vibration poles – e por ai vai ). Fazer o simples, escrever simples, “famoso feijão com arroz”, funciona na maioria dos casos.

Por isso que quadros de post its podem ser excelentes ferramentas, mas cuidado para não abusar da coisa.  Ter a preocupação de pensar nas cores, letras, tamanho de fonte,  são coisa extremamentes válidas e garante um bom retorno no objetivo de comunicar, porém isso sempre fica num segundo plano e na maioria dos casos ignorado.

Bem amigos, enquanto não tivermos evoluído o suficiente para termos telepatia e ler mentes, ou algo parecido, vamos depender, e muito, da comunicação.  Por isso trate-a com carinho em seus projetos e dedique um tempo para trabalhá-la de forma a ser a melhor coisa o possível e verá que os ganhos vão pagar cada sacrificio feito nesse sentido.

Esses dias li um e-mail numa lista de discussão que participo onde a pessoa perguntava como ela deveria fazer para documentar um projeto que ele desenvolveu sozinho. Ainda segundo ele, a ideia é de permitir que num futuro próximo um novo desenvolvedor possa trabalhar no sistema sem traumas e com uma curva de aprendizado rápida.

Antes de tentar responder a pergunta, acredito seja necessário entender a diferença entre análise e documentação.  Muitas pessoas que trabalham com  criação de softwares, acabam confundindo documentar com analisar.  Essa dúvida é normal pois muitas “ferramentas” e “métodos” também se apresentam como opção de documentação, ou o contrário : coisas que deveriam ser usadas para documentar são usadas para fazer análise ( e até acabam com uma má fama sem terem culpa disso – puro mal uso). Um exemplo disso, no meu ponto de vista, é o uml : Muitos usam a UML com o propósito de analisar e modelar. Ela até foi criada com esse intuito pois, quando foi concebida  era bastante custoso codificar e alterar o código feito (lembre-se dos cartões perfurados, cobols da vida, etc) mas hoje isso já não é válido (com linguagens modernas, codificar é rápido e alterá-lo mais ainda). Voltando, UML, no meu ponto de vista, é muito mais documentativa do que modelagem.  Seus diagramas tem um ótimo apelo de representar graficamente um sistema e como diz um ditado: “Uma imagem vale por mil palavras”.

Um outro mito a ser desfeito, insisto, no meu ponto de vista, é de que documentar não agrega valor. Por mais que ninguém diga isso, por mais que ninguém escreva isso, por mais que ninguém assuma isso, muitos de nós considera o ato de documentar como uma atividade secundária, e com isso, delegamos para que outros façam ou, em piores casos, nem o fazemos. A questão que ninguém escreve um sistema para si e, na maioria dos casos, não fazemos isso sozinhos.  Outro ponto é que, possivelmente, não ficaremos para o resto de nossa vidas com aquele projeto, passaremos para outros desafios e aquele sistema deverá ser cuidado por outro pessoa que não necessariamente participou da equipe que o desenvolveu. Tal fato, implica em ter que forma esse pessoa de forma que ela possa dar continuidade ao aplicativo sem comprometer a qualidade dele (estou assumindo que seja aqueles projetos onde temos testes automatizados, linguagens bem expressivas, etc). Logo, tendo todo esse contexto em mente, fica fácil mostrar que documentar, no mínimo, é evitar dores de cabeça futuras.

Mas, enfim, como documentar?

A pergunta poderia ser redigida da seguinte forma para ter mais sentido para nós : Como podemos documentar sem que isso seja uma atividade secundária e agregue mais valor ao sistema? .  A maioria das linguagens modernas oferecem recursos, bastante interessantes, que podem responder essas perguntas. Em Java, nós temos o recurso básico do JavaDoc (comentários em formato especiais que são colocados no código fonte. Depois, através de ferramenta exportamos para um html), em .NET (csharp) temos algo parecido, e por ai segue. Embora isso já seja algo que ajude, considero insuficiente como documentação pois, quem irá ler não terá uma visão do funcionamento ou do comportamento do sistema.

Nesse contexto de comportamento e funcionamento que entram a ajuda primordial dos teste automatizados. Um efeito secundário dos testes automatizados (tanto os teste unitários quando os testes de comportamento) é de, se bem escritos e de grande abrangência,  eles acabam sendo uma boa fonte de consulta para o entendimento da aplicação.  Existe, inclusive, frameworks de teste de comportamento (Behavior Tests) que permitem que se escrevam de forma literal facilitando ainda mais o seu uso como documentação, como por exemplo o Cucumber (Ruby), Pyccuracy ( espero ter escrito certo – Python), etc.

Por fim, eu pessoalmente, acredito que um bom diário de bordo também ajuda bastante. Um diário de bordo, consiste, em algo parecido com um blog ( pode até ser um blog), em que vou escrevendo o dia a dia do desenvolvimento tentando retratar as decisões não técnicas e situações vencidas pela equipe de forma que a pessoa que irá trabalhar com o sistema no futuro tenha também uma visão do por que de certas escolhas, do sentimento da equipe naquele momento, etc.

Recentemente li um artigo do Martin Fowler (já tinha lido, mas praticamente o reli com outros olhos)  onde ele discute a questão do design e da análise dentro do mundo ágil, mais precisamente o XP (Extreme Programming).  No artigo, cujo título é “Is Design Dead?”, Fowler discorre sobre vários tópicos e tenta ver se é realmente um fato que com a adoção de  metodologias ágeis, o uso de padrões, análise prévias e design se tornaram práticas mortas

Dentro do times ágeis, existem diversas premissas que devem ser adotadas para que se possa colher todas as vantagens que ele oferece.  Algumas das mais famosas são:

• Faça o justo necessário:  não faça aquém nem além do que deve ser feito na iteração
• Refatoração : sempre que puder melhore o código
• Foco nas tarefas que agregam valor na visão do cliente
• Fazer o simples e depois evoluir o código de acordo com a necessidade.

Fazer o justo necessário é de focar em gerar valor para o cliente. Aqui a principal mensagem está em evitar tarefas que no final não geram retorno. Exemplo: o tme que gasta horas para criar um modelo de dados;  times que gastam considerável soma de tempo para escrever  bibliotecas para fazer algo que não esteja ligada a funcionalidade que o cliente deseja  naquela iteração (api de log, api de para ler o xml de configuração, api para tratar string, etc). Nesta ideia também se encaixa a questão de evitar tarefas que não agregam valor para o produto.

A Refatoração constante do código significa mais que simplesmente rescrever trechos de código e sim, uma busca constante por simplicidade, qualidade e por programas legíveis. Uma coisa que os mais novos sempre erram é de ter uma visão simplória do que venha ser Refatorar : não é simplesmente acerto de escopo de variável,  comentar, etc.  Refatorar, em XP principalmente é “alma do negócio”.

Quando se diz – ” Fazer o simples e evoluir“, você está comunicando ao seu time que é desejável que façam coisas simples. A medida da necessidade do projeto, os modelos, arquiteturas, etc., vão evoluindo e ganhando os recursos necessários para resolver os problemas.  Dentro da refatoração existirá, também, o espaço necessário para a melhora.

Fazer ou não fazer análise em projetos ágeis ?

Diante do que disse antes, principalmente de evitar atividades que não agreguem valor, os mais puristas, diriam que fazer analise ( estudo, diagramas, etc para entender a arquitetura e quais seriam os requisitos técnicos)  é algo que não deve ser feito. Iriam além estes mesmo: afirmaria que tal prática é ultrapassada e que de nada server.

Bom, eu discordo. E se me perguntassem isso, responderia:  - “Depende ! “

Se estamos falando de um sistema simples, cujos os requisitos são extremamente claros,  fazer analise pode ser um passo a mais que poderia ser retirado. Ou então, considerado como um história de documentação que deve ser tratado no backlog ( mas com baixa prioridade de acordo com a visão do cliente). Porém se estamos falando de sistemas cujo o processo a ser gerido é complicado  e/ou com regras de negócios complexas, uma fase, por menos que seja, de análise ajudaria até melhor entender os requisitos. O problema está que muitas equipes de desenvolvimento tornam o resultado de uma analise uma verdade absoluta e imutável.  Bem, isso não pode ser verdade pois o cliente vária vezes nem ter certeza do que quer e ao longo das entregas que começa a desenhar melhor sua necessidade e desejo.

Analisar previamente ajuda a diminuir riscos e a nortear, de certo modo, a visão do time na hora de implementar.

Entretanto, ao realizar uma analise, podemos pensar como um rascunho do Niemeyer de um prédio novo. Serve apenas para ter um impressão inicial não muito clara do que iremos realizar.

Quem usa XP não adota padrões?  Não define arquitetura?

Esta aí outra coisa que não gosto e nem concordo em ouvir.  Bem, os padrões não são ruins, são as pessoas que abusam do direito de usá-los.  Já vi gente fazendo um site para 10 pessoas (coisa interna de uma empresa) cujo o escopo é limitado e quase nunca evolui, colocando milhões de camadas, milhares de DAOs, VOs, etc.

Muitos poderiam dizer, principalmente os defensores mais ferrenhos, que devem sempre fazer as coisas simples.  Minha resposta : no final, caso faça algo descendente, é bem possível que “esbarre” num padrão.

Outra coisa que não concordo é a questão de não se discutir arquitetura… Para um projeto pequeno, você pode se dar ao luxo de não pensar nisso, pelo menos, num primeiro momento, mas para projetos grandes, tem que pensar nos componentes pois isso influirá diretamente na forma que time irá implementar as coisas. Novamente reforço que, quando sugiro usar padrões, não é pegar o livro e fazer tudo que está dizendo ali. Nada nos impede de adaptar a sugestão para nossa realidade.

Rebeldia  e revolução a parte, sempre vou dizer que o melhor caminha continua sendo o do meio. Ficar com o melhor de todos os mundos é o paraíso a ser desejado.

Muito sem tem dito, hoje, sobre a questão da gestão de projetos. Nisso, incluo a famosa atual discussão da aplicação de metodologias ágeis, que antes eram práticas aboninadas, frente aos sucessivos fracassos que as gestão waterfall (gestão de atividades em cascatas cuja a imagem mais forte são os gigantescos cronogramas em gráficos de Gantt). Embora exista, de uma certa forma, um guerra entre os padrões – ora um diz que é melhor por um motivo, ora outro diz que não é nada disso, ambos mostram casos de sucessos e erros dos outros e por ai vai – existe pontos bastante comuns  em seus discursos, como por exemplo: foco na satisfação do cliente, busca por altos rendimentos – produtos entregues mais rápido, com maior qualidade, etc.

Ninguém está errado em querer focar em agradar seu cliente, muito menos na busca por maximizar seus lucros ( vender mais e gastar menos para realizar, etc). A questão que gostaria de discutir é a mensagem vinculada que vem sendo dita por ambos que remete a querermos trabalhar sempre próximos de nossos limites (alta disponibilidade, entregas super rápidas, e outras coisas parecidas)

Não é errado quere maximizar os trabalhos. O problema está em sempre querer usar e fazer as coisas no limite ( para cima ou para baixo)

Outro dia  conversando com um amigo,falvamos da situação atual onde temos empresas onde tudo é maior, melhor, alto, etc. Empresa, que devido a uso de alguma metodologia “bala de prata” , as entregas são super rápidas,  projetos com alta tecnologias,  sistemas com as últimas novidades, e (ufa!) por ai seguem.  Tudo feito no limite, tudo é SUPER (quando digo limite falo do fato de todos terem desempenhos fora do comum). Se me permitem a brincadeira, é  verdadeiro local de trabalho de sobre humanos, pois trabalhar sempre no limite máximo é algo bem difícil para nós mortais. É como se tivéssemos “pessoas” correndo a velocidades de provas de 100m durante uma maratona. Para seres humanos comum é algo que dá para fazer nos primeiros 200m mas depois não dá… simplesmente não dá.  A gente acaba “abrindo o bico”

Não seria nenhuma surpresa se numa empresa como esta surgissem pessoas tendo crises de estresse (com variações agudas como por exemplo sindrome do pânico), pessoas com saúde comprometida, um número razoável de pessoas acima do peso, pessoas fumantes, etc. Considerando que ainda não temos super -homens por aí, ao não ser nos filmes e novelas (ehehehehe), mais cedo ou mais tarde algo deve acontecer.

Alguns pensam que podem correr um maratona mantendo a velocidade de corredores de 100 m. Simplesmente não dá e acabam que não completam todo o percurso.

Existe um preceito budista, no qual eu acredito que é : ” O melhor caminho é o do meio” . Diz alguns historiadores que Buda ( na época o princípe Siddhartha Gautama ) em seu caminho para a iluminação começou tentando seguir pelo caminha dos homens santos hindus fazendo jejuns, e se submetendo a sofrimentos como forma de purificar.  Foi quando num dia de meditação percebeu que o caminho não estava no limite e sim no meio termo.  Não podemos deixar ir sem regra alguma mas também não podemos colocar todas as restrições. Devemos buscar o equilibrio para nos tornar sustentáveis na caminhada da iluminição.

Equilibrio

Antes que comecem a dizer que estou ficando maluco e escrevendo coisas sem nexo algum, vamos traçar a correlação dos preceito budistas e trabalho.

Me assusta um pouco o fato de que atualmente, muitos tentem vender o uso de metodologias ágeis como um forma de aumentar o rendimento da empresa. Isso, num primeiro momento pode soar até inocente, mas para um empresário, isso irá soar como aumentar lucro.  A questão que quem está mostrando a idéia esquece de dizer que é verdade que melhora a qualidade e a velocidade do time de desenvolvimento (na maioria dos casos) mas isso não é para ser usado como motivo para aumentar a carga de trabalho da equipe e sim permitir um equilibrio maior. Tal equilibrio significa fazer menos horas extras, ter uma jornada de trabalho mais leve e que permita as pessoas irem para suas casa felizes e ainda com energia para conviver com suas famílias, ou então, realizarem outras atividades como esportes, estudos, etc. O mais engraçado disso que relendo o manifesto agil e alguns textos mais antigos sobre o assunto notei que, eles sempre carregam uma mensagem de foco no humano… na visão do profissional não como recurso e sim como individuo e trabalhador criativo que tem necessidades a serem atendidas.

Outra palavra chave que quero adicionar a nossa equação é : SUSTENTABILIDADE. Modelos que andam no limite não são sustentáveis… pois trabalhar sempre na modalidade de capacidade total significa maximizar também os desgastes.  A natureza mostra que devemos sempre buscar uma velocidade de cruzeiro, ou seja,  um rendimento tal que possamos andar bem mas sem tocarmos as fronteiras do recurso ou pessoa. Sustentabilidade também tem relação com pensar no futuro. Por isso, sempre querer inovar em tudo, pode acarretar em não ser sustentável no médio nem no longo prazo.  Viver trabalhando com as  últimas novidades ou com padrões, que ainda não estão totalmente difundidos no mercado, é buscar um vida dificil  para o Rh. Pois as pessoas que lá estão hoje, por gostarem de novidades, logo mudaram o foco de seu interesse para outras coisas e aquele sistema ficará, lá, legado a ninguém pois, ainda não existem profissionais disponiveis no mercado com o tal conhecimento.

Por isso, volta a frase:  ” O melhor é o caminho do meio”.  Temos sim que tentar aumentar nosso tempo de resposta a projetos, ajudar as empresas a ganhar dinheiro, entretanto é importante também garantir a sustentabilidade do processo e das pessoas.