Honestidade como inovação

Alguns vão pensar, "esse cara tá louco".... temos de ser honestos o tempo todo... Mas é um desabafo mesmo. Encontramos situações profissionais onde a honestidade resolveria o problema da melhor forma possível, mas por conta de protocolos e etiqueta temos de desenrolar algumas coisas até o fim e o que é pior sem agregar nenhum valor a solução, pelo contrário, só piorando e gastando mais tempo e recursos para tal.

Então por que não simplesmente abrimos o jogo? "OLha isso aqui está errado por conta disso, disso e disso... sem rodeios". Claro que para isso a gerência tem de aceitar também.

Sejamos justos e claros, sem fingimentos... se não gosto de você, tenho de poder dizer isso, assim somos honestos e nos tratamos profissionalmente bem, mas não vou chama-lo para jantar em casa.

Sejam honestos em todos os relacionamentos, é a melhor coisa e elimina o tempo de desconfiança ou de elocubrações...

Seu time agradece.

www.UMPORDIA.net

Olá Pessoal,

Estou escrevendo sobre uma novidade, o site www.umpordia.net. Trata-se de um site sobre meio ambiente, mas que não fala de salve as baleias ou as tartarugas, mas fala sobre como podemos ajudar o planeta pegando o lixo do chão, reciclando um ítem por dia, ou ainda deixando o carro de lado por um espaço pequeno e assim vai...

A idéia é concientizar aqueles que tem muita dificuldade de adotar as medidas, agora necessárias, a favor do meio ambiente. Pessoas que não conseguem ir na esquina sem o carro, ou que acham que juntar pets é juntar lixo.

Novas idéias são sempre bem vindas, agora é acessar e se você tiver alguma idéia, contribua pelo livro de visitas. Ou então deixe seu comentário, seja qual for... recomendo... WWW.UMPORDIA.NET.

Abraço e até a próxima!

Será que teremos um Agile Maturity Level

O uso de metodologias Ageis vem crescendo muito nos últimos 2 anos e organizações com CMMI de qualquer nível estão tentando manter a certificação o que não é uma tarefa simples.

Muitas iniciativas, principalmente nos Estatus Unidos, estão trabalhando para aplicar CMMI para projetos usando Agile. Bons artigos já estão por ai, mas ainda é uma tarefa difícil. É como juntar torcedores do Corinthians e Palmeiras para torcerem pelo mesmo time formado pela junção dos dois times.

Mas isso vem por ai, e toda ajuda é bem vinda. CMMI nos ajudou a chegar onde estamos no gerenciamento de projetos, e tem muito a ajudar na maturação de projetos Ageis.

Mais informação está surgindo...

Abraço.

CHANGING FAST FROM A CHAOTIC TO A PRODUCTIVE TEAM

This is an article from a friend, it is really amazing how he used the open mind to change the way of doing things. It's innovation that matters!!! The author of this article is Andre Paulo Pinto Khury.

Enjoy

A personal experience of André Khury

I was not working for IBM yet in February 2003, when I was assigned to help the development team of the biggest IT project of the largest Brazilian federal bank. The development team included Java developers, COBOL/CICS developers and integrators. At the time there were 23 developers working together at the same room and for the same project and with the same goals, but yet they were very much divided among them due to some personal quarrels, differences and prejudice. One of the major problems cause was the fact that there were four different vendor companies allocating professionals in the project and wrangling for a bigger 'piece of the pie'. This dispute affected their employees and created a sort of a politics of deniability of information. There were old and experienced professionals as well as rookies that were desperately in need of support in their tasks but refused to cry for help, or help was denied when asked for. Synergy was a word that people did not know. Also, since the development was far behind schedule, the team was somehow leadless, because the team leader was much more involved with technical labor, like coding, than with the organization and support of the group. Many programs were already being coded without final requirement documentations and specific designs approved by the client - just based on scratches and informal papers. The rate of rework was huge then. In short, I've found a chaos that I've never seen before in my life as IT professional.

After making a lot of personal notes of the whole picture I was able to identify most of the issues as well as those problems that should be stricken down as fast as possible. However, I knew that in such a scenario, I should understand not only the project needs but those of the team members as well. I wanted to see the project from their point of view, and collect their opinion on how to make the work better and faster for them. So I decided to talk in private with each one and make an accurate list of all individual needs, opinions and difficulties. I was surprised many times during the interviews.

That is a short list of the main issues found with the team members and how I dealt with them:

• It was a young team composed by people coming from all over the country, with very different ages, formations and professional experiences. Their differences were starting to be too visible.

• In despite of the size and importance of the project they were working on, the team was not motivated at all. That seemed the only reason they were there yet, away from home, was the high pay.

• Many team members were avoiding to share information with others, or even to give any help to those belonging to a different vendor company. They didn't want to ease the work of their 'competitors'. There was not a feeling of partnership among the team members.

• Some were loosing focus, working without commitment with the project schedule and goals.

• Some were stuck and just waiting for other team members to finish their parts to continue.

• Some were working very slow, full of doubts about the requirements and the design documentation but did not ask for help. Instead, they were expending many precious hours trying to figure out alone what they were expected to do.

After speaking up clearly about all the problems over a team meeting, I encouraged each one to be more tolerant and flexible with the teammates and make an extra effort to put apart the differences and develop or accept friendship, exchange experiences and speak about themselves. Also, we organized a weekly team meeting where everybody would have the opportunity to speak a little about his task and his difficulties as well as make direct questions and anyone in the team was allowed to reply. They started to talk, discuss the questions and enjoy the company of the teammates.

That project was too important to be just 'one more job' to do. Working on this project should not be justified only by the good pay. It was a great experience for the curriculum of any developer. It had a nationwide visibility and was about to be used by thousands of clients. This system was even to be exported to foreign governments too. Doors could be opened and new great opportunities could appear for those involved in it. We would be making use of high technology in our area and it would make the project both challenging and interesting and we all should stop to thing about it and realize the privilege we had to be there. I spoke this way to the team in our meetings and individually also. Soon I could observe a very nice reaction of the team members.

It was unacceptable for me to watch people from a vendor company denying or hiding data from teammates of another vendor company. As the Project Leader, I had direct access to the managers and, after reporting this issue to them, we decided to make some major changes in the way the data should flow. From that moment on, all members of the team would have access to all requirements and design documents, database models, test results, schedules and any other related documentation that could be relevant for the team knowledge of the project and their individual tasks. Also, some developers were severely warned about avoiding this kind of behavior. When a new requirement or design document was sent for development, before forwarding it to the developer, I read it and show it to the team. A printed copy was delivered to the assigned developer and the files were stored in the team repository for free access. Also, to incite the development of a team feeling, whenever possible or necessary I designated people of different vendor companies to work in the same program or task. Since they had to finish the job on schedule, they normally assisted each other when a problem appeared.

To improve commitment, focus and productivity:
• Every morning, before start working, we used to have a 10 to 15 minutes meeting to speak about the day target for the team, and to clear up any doubts about the project.
• I requested a big flip chart and placed it by my desk, so that the team could see it easily. Every morning, after our short daily meeting, I put there the scheduled targets for the day and the desired individual accomplishments of each one.
• During the day, I went to each workstation and had a brief chat with the developers about their difficulties and pendencies. If some developer was stuck by any reason, I searched for an immediate solution or, if not possible to continue with the task he was doing, he was redirected either to start a new task or to help another developer with his tasks, until the problem could be resolved.
• The chronogram was updated daily and, even though it was already set as available for consult in the team repository, I insisted sending it for the team by email.
• When the team was depending on another team to continue working, like waiting for the mainframe programmers that were not part of our project to send us test files, simulators were generated accordingly to the pre-approved protocols and the developers could use them to emulate the communication to another layers, programs and platforms.
• The test team was also requested many times to improve the quality of our unit tests and to speed up the creation of the unit test scripts.

In a short time, everyone involved in the project clearly noted a great improvement in the productivity of the development team and in the quality of the delivered services. When I left the project, the performance of every team member was very satisfactory, the development was back on schedule and the team was highly motivated.

2009 - ano novo, já sabe o que vem de novo por ai?

É isso ai, vem mais um ano ai, iniciando com crise e cheio de incertezas quanto a crédito e até quanto a saúde dos países do primeiro mundo. A idéia que vem a mente é, bom, então melhor ficar quieto e esperar passar a maré, depois agimos... Certo? Eu acho que não. É uma opinão pessoal, mas para mim, é a hora de trazer a inovação a tona.

Claro que o planejamento fica sendo mais importante do que nunca. Mas não é hora de parar, a não ser que tenha visto que o nicho tenha terminado (muito difícil), de resto, entendo que seja uma boa hora de entrar no mercado.

Mas, o diferencial deve ser muito forte, por isso o momento para inovação. Inovações que ajudem a reduzir custos ou que ajudem a encontrar problemas antes que ocorram estão em alta. Se souber de algo, vá em frente!!!

Bom, um bom natal e um ano inovador em todos os pontos da vida. Inove 365 vezes em 2009

É hora de inovar

Com a crise por ai, só se ouve palavras de desânimo e desespero, está na hora das oportunidades. É hora de inovar.

Inovar para usar a situação a seu favor, lembre-se se fizer a mesma coisa sempre, terá sempre o mesmo resultado. Então, ao invés de propagar a mensagem de desânimo, pare, reflita sobre a sua posição na crise e veja como você pode fazer para mudar alguma coisa.

Inovar pode ajudar, mas saiba que pode ser um risco. Já comentei aqui que inovar é arriscado, normalmente um risco calculado, mas ainda um risco. Em momentos de crise, os riscos são mais exagerados, porém mais fáceis de serem identificados.

Arrisque sim, se você tem uma idéia, olhe bem e vá em frente.

Até a próxima.

Agile Software

Olá Pessoal, aqui estou mais uma vez após um longo período, espero aumentar a frequência de artigos no futuro...

O assunto de hoje é inovação pura ná área de gerência de projetos, trata-se de Agile. Uma maneira mais eficiente para gestão de projetos.

Se você ainda não ouviu falar, é bom começar a pesquisar, aliás, tenho algumas dicas a quem interessar... Agile nasceu em 2001 com o manifesto que pode ser encontrado em www.agilemanifesto.org, segue abaixo:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Poucas coisas trouxeram tantas quebras de paradigmas como Agile, baseado em LEAN traz conceitos que são duros de engolir, mas os resultados são muito melhores que os obtidos até agora pelas outras metodologias.
Agile tem 4 grandes pontos, Self directed teams, susteinable pace, Time Boxed and Stakeholder feedback. Uma prévia de cada conceito:

. Time-Boxed - Trata-se de interações de 2 a 4 semanas, onde se deve designar o que deve ser feito, fazer, e entregar algo realmente pronto para o cliente. Dentro de 2 a 4 semanas, o resultado é algo pronto para ser utilizado. se há algo a se fazer para completar, então não está pronto e não é parte do resultado. Com isso é possível ver muito rapidamente e de forma transparente o andamento do projeto.

. Self Directed team - ninguém diz o que deve ser feito, a lista de tarefas é compartilhada e cada membro do time pode escolher o que fazer. Isso é um ponto muito difícil para gerentes que estão acostumados a designar tarefas... O time está comprometido, com o resultado da interação, e por isso farão o melhor que puderem. Lembro também que estamos falando de profissionais e que com responsabilidade farão o melhor que puderem.

. Susteinable pace - honestidade e transparência, não adianta dizer que entregará algo impossível e ficar trabalhando 18 horas por dia mais fins de semana para entregar. Estatísticas comprovam que mais defeitos são encontrados em situações de overload. Portanto é mais produtivo ser honesto e determinar um limite para o que deve ser entregue, mais que aquilo nào dá.

. Stakeholder feedback - o contato com o stakeholder é o pilar de sustentaçào do que está sendo feito e o que deve ser entregue, como temos interações de curto prazo, o relacionamento com o cliente deve ser muito estreito, para que nào se perca tempo desenvolvendo a solução ou o produto errado. O Stakeholder é que determina as prioridades das tarefas e o que ele quer ver no final.

Como disse anteriormente Agile tem os conceitos de LEAN incorporados. Lean foi criado na Toyota e hoje é aplicado a desenvolvimento de aplicações.
Lean tem 7 conceitos fundamentais, são eles:

1. Eliminate Waste - waste é tudo que não gera valor ao cliente, portanto documentação excessiva, funcionalidades não utilizadas, retrabalho etc. Em Lean toda tarefa deve ter como resultado algum valor agregado.

2. Built Quality in - é conhecido que quanto mais tarde se encontrar os defeitos, mais caro será para concerta-los. Portanto estamos falando de encontrar o defeito no momento de desenvolvimento, não na fase de testes. O uso de Unit Tests é bem comum para encontrar falhas ainda em desenvolvimento. É tarefa do desenvolvedor garantir que não há falhas.

3. Defer commitment - as decisões devem ser tomadas no último momento possível (dentro do esperado é claro) e sempre que possível as decisões devem ser reversíveis. Uma decisào irreversível, deve ser tomada no último instante possível, quando todas ou o máximo possível de informação e tecnologia está disponível. Assim tem-se mais segurança para a tomada de decisão e pode-se utilizar sempre o que há de mais moderno na solução.

4. Deliver Fast - isso é mais que entregar rápido, é entregar o que o cliente pediu e não o que queremos vender. A idéia é produzir a partir de uma solicitação, e não termos um produto pronto e entrega-lo ao cliente.

5. Focus on learning - os processos devem ser melhorados sempre, há empresas que dizem: "se um processo não muda a 2 meses é porque o processo não é mais utilizado ou a empresa fechou". Sempre há algo a melhorar e quem participa do processo é responsável por isso.

6. Respect People - cada membro do time é importante e é quem faz o processo caminhar e melhorar, ninguém melhor para dizer como fazer o seu trabalho do que você mesmo.

7. Optimize the whole - melhorar todo o sistema e não só um pedaço dele. Um exemplo básico seria, para melhorar um carro não basta somente colocar um motor mais forte nele, mas a suspensão, as rodas e pneus, a estrutura, o câmbio e mais outras partes devem ser melhoradas como um todo. Esse é o conceito, melhorar o todo e não só um pedaço.





Bem, hoje paro por aqui, mas volto com mais sobre Agile, nas próximas, vou escrever sobre scrum, planning poker Business Driven Development entre outros.

Até mais!

Algumas referencias:
http://www.agilemanifesto.org
http://www.agilealliance.com/