domingo, 21 de março de 2010
.jpg)
Text developed to Advanced Writing Skills course at Associação Cultural Brasil Estados Unidos in March 2010, given by Elizabeth Crockett. It was based on When You Think the Strategy is Wrong, paper written by Amy Gallo to Blog Best Practices at Harvard Business Review On-Line.
One of many tasks of a manager is to implement organization´s strategy and to make others – his/her team, unit or department – execute it very well.
Although, sometimes the manager can think that the strategy adopted by the organization is wrong. In this case, the manager´s professional should be cautious and analyze the situation with patience, because to start, immediately without to be sure about what is happening, the “fire alarm” can be dangerous to him/herself image.
Experts say that to develop a strategy is difficult, needs time, often the process is messy and the result is never perfect. A manager must speak up about his/her thinking and doubts, but, before needs to pass by some steps.
The first step is to understand in what context the strategy was created. At this moment, it is important to contact experienced people who fellow the development process. These people can return useful information and advice from a variaty of points of view.
The second step is to reflect about the concerns using gained information in a contextualized way. No one strategy is a hundred percent perfect, but, sometimes one mistake can be only a different perception of eavaluating it and not a real problem. A responsible manager should ask him/herself if there is a real problem or only an unease because of his/her feelings and point of view.
After research and reflection about the problem compared with his/her motivations, if the concerns continues is time to verbalize them.
The third step is to talk with his/her direct boss about what concerns him/her. At this moment is important to have solid information that sure is going to help explain his/her thoughts. Besides, the manager should propose actions that can mitgate the strategy´s mistakes. In the conversation it is important not question the authority of boss.
The number of cases with mistakes related to strategy that put organizations in real risk is small. If it is the case, the manager should consider quitting, but is necessarily to send a message to his/her CEO talking about roots of decision.
sábado, 6 de março de 2010
Globalization: Working Abroad Being Culturally Sensitive
0 comentários Postado por Ricardo Rabêlo Filho, Paula Ivy às 08:03
Text developed to Advanced Writing Skills course at Associação Cultural Brasil Estados Unidos in March 2010, given by Elizabeth Crockett. It was based on Globalization: The Borderless Leader, paper written by Malcolm Wheatley to 2008 Leadership in Project Management - Project Management Institute.
In the past, to find people who work abroad was very difficult. Nowadays, some things like low-cost air travel and high-speed internet connectivity have made workers, regardless of position, establish professional relationships with many others around the world. This change occurred with the advance of globalization, - a phenomenon mainly identified by the integration and interdependence among economies and the technological, ecological and others spheres of societies around the world. In this context, leaders are challenged – and need to learn – to be more culturally sensitive and need to teach and motivate employees to do the same.
Before learning cross-cultural skills and changing your behavior is necessary to find out when and where cultural differences exist. It can be difficulty, because all people are totally immerssed in their culture and do not see its features. It is impossible to describe with a hundred percent certainty and in detail the individual behavior of each citizen in a country or city, but with antropological research, called etnograph, we can discover common denominators about behavior in a society. Fons Trompenaars, a Belgian academic, wrote a book called Riding the Waves of Culture, based on Geert Hofsted´s research, and determined that cultures could be characterized by their features in a number of dimensions such as uncertainty avoidance, individualism vs. collectivism and hierarchical vs. participative decision process. For example, in what Mrs. Trompernaars called “particularism”, relationships are more important than rules. On the other hand, in what he called ”universalist”, rules take procedence over people.
After knowing mainly characteristics of a culture and determining its key-points, it is necessary to fit policies and work manneers to it. For example, if in a culture face-to-face contact has a high value, leaders should not use solely e-mail. They need to find other medias like vídeoconferencing. This aproach is supported by Rudolf Melik, author of The Rise of the Project Management Workforce: Managing People and Projects in a Flat World. Another example is give to us by Ron Hyams, a South-Africa-based managing partner with the multinational executive coaching firm Praesta. He explains a female marketing director who was accustomed to walking in her company´s office looking at Black Blarry. The perception about her, in South Africa where she was working, was negative because there people value eye contact and they felt insulted by her.
Daniel Hepp, a Canada-based director of professional services at Blue Cats Networks, looks at differences among cultures as a good thing. In his opinion, people from different cultures give to organizations an advantage built by different points of view and perspectives.
Dean Cunnengham, England-based managing director of Cross Border Coaching believes that, about every thing, overcoming natural habits and adjusting your behavior is not a piece of cake and demands practice, so you should not get disillusioned.
domingo, 14 de fevereiro de 2010
Série Reconciliando o Econômico e o Social
0 comentários Postado por Ricardo Rabêlo Filho, Paula Ivy às 04:58
Esta série de artigos leva como nome o subtítulo da versão traduzida para o português do livro escrito por Jean-Francois Chanlat, em 1998, com o título original de Sciences sociales et management: plaidoyer pour une anthropologie générale, sendo esta obra o alicerce fundamental do estudo que aqui se desenvolverá. Obra esta que também fôra base para debates na disciplina Abordagem Sócio-Política das Organizações, ministrada pelo Prof. Dr. Reynaldo Paula(UFBA).
A motivação para o estudo do tema em questão advém da minha percepção sobre o mundo da administração e sobre aquilo que a respeito dele é publicado nas mais diversas mídias. O que comumente se vê são materiais que tratam a administração pelo prisma do sistema capitalista fundamentado na economia de mercado onde a obtenção de lucro torna-se o objetivo fim, dando pouco ou nenhum espaço para os aspectos sociais. Pretendo aqui preencher esta lacuna, fazendo o leitor refletir e desenvolver um senso crítico mais apurado para que assim este também possa, com as suas ações, contribuir para o desenvolvimento de uma administração mais justa e coerente com as necessidades daqueles que compõem a teia social.
O objetivo destes artigos será esclarecer, através de uma evolução histórica, mas ao mesmo tempo intimamente relacionada ao contexto presente, o surgimento da organização empresarial como a conhecemos hoje, sua escalada no que diz respeito à ocupação cada vez mais constante em posições de poder e influência social, bem como desenvolver uma abordagem crítica dos seus métodos, ações e respectivas conseqüências para a sociedade e por fim ressaltar a importância de se desenvolver uma visão administrativa que relacione os aspectos econômicos e sociais.
Para guiar os estudos sobre o tema, descrevo abaixo alguns tópicos que servirão como alicerces.
- A razão instrumental.
- Desenvolvimento histórico do capitalismo com foco nas suas organizações produtivas e relações sociais engendradas no interior das mesmas.
- Necessidade de sistematizar o conhecimento sobre a administração dessas organizações e o surgimento do Management e a sua diferenciação semântica com a Administração.
- O management na atualidade.
- Desenvolvimento de uma administração que pense o econômico, mas que tenha o social como fator de relevância.
domingo, 17 de janeiro de 2010
Texto baseado no livro Dominando Linux Red Hat 9, Editora Ciência Moderna.
Há tempos atrás, os computadores eram muito caros, contudo a demanda era muito alta e, como solução, cientistas desenvolveram o conceito time-sharing(compartilhamento de tempo), onde muitos usuários através de terminais eram conectados a um computador, hoje isso se chama Arquitetura Cliente Servidor.
Um dos primeiros projetos nesta área foi o Multics, envolvendo MIT, Bell Labs, na época pertencente a AT&T e General Eletric.A Bell Labs saiu do projeto, mas Ken Thompson e Dennis Ritchie, os quais trabalhavam para AT&T continuaram a trabalhar no desenvolvimento de um sistema multiusuário; o resultado disto foi o Unix.
Na época a AT&T não podia participar do mercado de computação devido a intervenções do governo americano, por isso resolveu destribuir o sistema com seu código fonte a universidades.
Na década de 1980, a AT&T passou a ter autorização para comercializar o Unix e então este passou a ser um sistema fechado.
Devido aos altos preços praticados pela AT&T, universitários começaram a desenvolver sistemas similares ao Unix.Nesta época surge um grupo, o FSF(Free Software Fundation) liderado por Richard Stallman, cujo objetivo era o compartilhamento de software.Este grupo desenvolveu a licença GPL e componentes de sistemas operacional tipo Unix(Projeto GNU).
Em 1991, Linus Torvalds, estudante de Ciência da Computação da Universidade de Helsinki, Finlândia, desenvolve um kernel(núcleo de sistema) e, em 1995 algumas empresas juntam o kernel desenvolvido por Linus aos componentes do Projeto GNU, da FSF e surge o sistema operacional GNU/Linux com sua várias distribuições(customizações do sistema).
"Extreme Programming(XP) é um processo de desenvolvimento que possibilita a criação de software de alta qualidade, de maneira ágil, econômica e flexível. Vem sendo adotado com enorme sucesso na Europa, nos Estados Unidos e, mais recentemente, no Brasil.", Vinicius Manhães Teles, autor do livro Extreme Programming.
O XP tem como principais características o desenvolvimento com escopo variável e por etapas, através de uma série de implementações, possibilitando entrega mais rápida das partes de software que são mais necessárias e de uso mais imediato, assim como a redução dos custos, pois o cliente só paga por aquilo que recebe; o refactoring, ou seja, a organização do código de forma que esse seja claro e permita complementações futuras; o uso intensivo de testes de código individuais e integrados além da programação em par, tornando o desenvolvimento mais rápido, pois diminui-se o tempo na busca por erros, possibilitando a geração de produto final com maior qualidade; e a interação contínua e sólida com o negócio do cliente, através das técnicas de feedback e trabalho, por vezes, dentro do mesmo espaço físico do contratante.
Além dessas práticas, a metodologia XP oferece inúmeras outras que, em conjunto, possibilitam a entrega de softwares com ótima relação custo x benefício.
Para maiores esclarecimentos, consulte o livro Extreme Programming de Vinicius Teles, publicado pela editora Novatec e/ou clique no link da Improve It na lista ao lado.
Extreme Programming X Método Tradicional
0 comentários Postado por Ricardo Rabêlo Filho, Paula Ivy às 05:27| Extreme Programming | Método tradicional |
| · O cliente participa ativamente do processo de desenvolvimento que aumenta a segurança do negócio e diminui as dúvidas da equipe. · O contrato é de escopo variável o que permite ao cliente modificar as funcionalidades no decorrer do processo de desenvolvimento o que garante maior satisfação para o mesmo. · O cliente não precisa esperar muito tempo para obter retorno com o software pois as principais funcionalidades são logo postas em uso. · Programação em par e testes constantes diminuem os bugs. · Não existe especulação o que diminui o tempo no desenvolvimento. | · O cliente não participa do desenvolvimento o que diminui a segurança no negócio e aumenta as dúvidas da equipe aumentando as possibilidades de erro. · No sistema tradicional(linear em cascata) o contrato é de escopo fechado(tenta-se ao máximo impedir mudanças o que é extremamente incorreto)resultando muitas vezes na insatisfação do cliente fazendo com que este gaste mais com atualizações. · O cliente somente obtém lucro com o software depois de muito tempo e muitas vezes este não corresponde as suas necessidades. · Gasta-se muito tempo com documentações que rapidamente se tornam obsoletas. · A existência de “Ilhas de Conhecimento” e o incentivo ao trabalho individual prejudicam o resultado final. |
Entrevista por e-mail, realizada em 2006, com Vinicius Manhães Teles, autor do livro Extreme Programming
0 comentários Postado por Ricardo Rabêlo Filho, Paula Ivy às 05:191º A cada iteração o cliente recebe atualização de software?
R: Sim.
2º Exemplo de contrato com escopo variável?
R: Desculpe-me pela demora na resposta. Em XP não existem modelos fixos para estes artefatos. Inclusive, nem sempre equipes XP chegam ao ponto de usar todos eles. Seja como for, você pode obter uma boa idéia de como criá-los no meu livro http://www.improveit.com.br/livroxp.jsp. Além disso, no que se refere especificamente ao contrato de escopo negociável, dê uma olhada em http://www.improveit.com.br/xp/contrato.jsp.
3º No livro há um capitulo que fala sobre design simples, mas eu não compreendi satisfatoriamente este conceito. Em poucas palavras, é possível dizer o que seria um design simples de um software?
R: Sobre a questão do design simples, vejamos um pequeno exemplo. Marcelo é um desenvolvedor trabalhando em um projeto de desenvolvimento que envolve inúmeras funcionalidades a serem colocadas em um site. A próxima funcionalidade que ele irá implementar diz o seguinte:
"Mostrar no site uma lista numerada, contendo 10 livros, que encontram-se descritos em anexo".
Marcelo sabe que o cliente vive mudando de idéia, então, decide fazer uma lista flexível com a qual o cliente possa, no futuro, inserir mais livros, mudar a ordem de apresentação, alterar o conteúdo etc. Então ele modela uma tabela no banco de dados, cria um formulário para cadastrar os livros pela web, insere os livros, em seguida cria uma página que mostra o conteúdo da tabela do banco de dados. Além disso, nessa mesma página, ele inclui a possibilidade de alterar a ordenação dos livros, de acordo com os seguintes critérios:
* Por nome do livro
* Por autor
* Por preço
* Por editora
Marcelo é o máximo, certo? Não apenas é um desenvolvedor dedicado, ele também tem iniciativa e consegue antecipar os movimentos do cliente. Pena que algumas mudanças nas prioridades do cliente fizeram com que aquela funcionalidade não fosse mais necessária. Marcelo gastou uma semana de desenvolvimento, enquanto poderia ter gasto apenas uma hora se tivesse escrito a listagem diretamente em um HTML simples.
As pesquisas demonstram que 64% das funcionalidades de um sistema comercial típico nunca ou raramente são usadas (veja a Figura 1 em http://www.improveit.com.br/xp). Portanto, investir em um design além do necessário para o que o cliente solicitou costuma ser bastante perigoso, como o exemplo acima ilustrou. Para ter acesso a um exemplo verdadeiro, bem mais drástico do que o apresentado aqui, acesse a minha dissertação no link http://www.improveit.com.br/xp/ dissertacaoXP.pdf e leia da página 130 à 134.
O XP sugere que a cada iteração, o desenvolvedor se preocupe em implementar apenas o estritamente necessário para que a funcionalidade solicitada pelo usuário fique pronta. Isso é o que chamamos de design simples. Em XP os desenvolvedores evitam antecipar necessidades futuras, pois sabem que raramente acertam com exatidão sobre o que o cliente realmente vai pedir no futuro.
Essa prática é contrária ao que é feito habitualmente em desenvolvimento, chamado de BDUF (big design up front). O BDUF é exatamente o que o Marcelo fez neste exemplo, ele foi além do que precisava ser feito, ou seja, além do design que seria suficiente para a necessidade do cliente.
Na minha dissertação, você também poderá ler mais sobre design simples das páginas 91 a 98.
4º Quando a Improve It desenvolve um sistema a equipe fica no prédio do cliente ou bem próximo a ele como é recomendado no livro?
R: Sim. Às vezes ficamos em um escritório próximo ao cliente, mas na maioria das vezes trabalhamos diretamente no escritório do cliente.
5º O fato de a equipe ir para o prédio do cliente não gera transtornos? O cliente não acha "esquisito" a equipe vir para o seu escritório?
No nosso caso isso é relativo. Atualmente, a maior parte do trabalho que fazemos é mentoring. Portanto, normalmente alocamos um ou mais profissionais, que atuam como mentor, os quais trabalham em conjunto com uma equipe de desenvolvimento do próprio cliente. Em alguns casos ir para o prédio do cliente pode trazer transtornos, sem dúvidas, mas em outros não. Isso naturalmente depende de caso a caso.
6º Na integração não seria mais demorado resolver as colisões do que impedir que um mesmo arquivo fosse modificado ao mesmo tempo?
R: Impedir que um mesmo arquivo seja modificado ao mesmo tempo por diferentes pessoas costuma retardar significativamente o desenvolvimento, porque é comum um desenvolvedor ter que trabalhar com inúmeros arquivos abertos ao mesmo tempo, o que eleva a possibilidade de que um ou vários destes arquivos também tenham que ser usados por outros desenvolvedores ao mesmo tempo. Essa é a alternativa mais segura para se evitar conflitos, mas é também a que mais retarda o trabalho da equipe.
Por sua vez, permitir que várias pessoas editem o mesmo arquivo ao mesmo tempo, embora permita maior agilidade para a equipe, pode gerar conflitos demorados de serem solucionados. O XP resolve isso fazendo com que as integrações ocorram com grande freqüência. Por exemplo, as pessoas tendem a integrar o que estão fazendo a cada 2h no máximo. Como o volume de trabalho em duas horas tende a ser reduzido, o potencial de conflito também se reduz bastante. Na prática, por mais surpreendente que pareça, conflitos de integração são raros em XP. Embora eu nunca tenha medido isso, acredito que tipicamente, a cada 100 integrações, provavelmente temos menos de 5 delas com conflito que necessite ser tratado pelo desenvolvedor. Ainda assim, como o escopo de trabalho é reduzido entre uma integração e outra, eventuais conflitos são resolvidos com bastante rapidez.
7º Quais as funcionalidades de uma ferramenta de build além de compilar? Gostaria de saber um pouco mais sobre as diferenças entre ambiente de desenvolvimento e ferramenta de build.
R: Um ambiente de desenvolvimento é algo como o Eclipse, IntelliJ, JBuilder, NetBeans etc. Ele possui inúmeras funcionalidades para edição de código, depuração, compilação etc. Mas, um dos aspectos mais marcantes destas ferramentas é a presença de um editor, que cada vez mais possui bastante inteligência, sendo capaz de compilar o código à medida em que escrevemos, coloca cores de acordo com as características do que foi escrito etc.
Uma ferramenta de build, como o Ant, é capaz de automatizar uma infinidade de atividades que, do contrário, teríamos que executar manualmente. No link http://ant.apache.org/manual/coretasklist.html você pode conhecer as inúmeras tarefas que o Ant é capaz de fazer por você, tais como compilar, executar testes de unidade, criar arquivos zip, fazer ftp, telenet, criar e remover diretórios, copiar arquivos etc.
Apenas para dar um exemplo, veja algumas das coisas que o Ant faz para nós quando precisamos atualizar o site da Improve It:
- Compila todos os arquivos
- Cria um arquivo ZIP contendo toda a estrutura do site
- Estabelece uma conexão ftp com nosso servidor
- Envia o ZIP por ftp
- Estabelece uma conexão telnet com nosso servidor
- Executa remotamente um shell script de atualização em nosso servidor, o qual faz backup da versão anterior (para o caso de recovery de falhas) e coloca os novos arquivos em produção
- Executa todos os 940 testes contra os novos arquivos colocados em produção
8º O Eclipse executa testes de unidade sozinho ou é necessário o Ant integrado a ele?
R: Ele é capaz de executá-los sozinho, sem a presença do Ant. O JUnit já vem integrado ao Eclipse por default
9º Caso seja feita uma classe genérica em Java por exemplo esta poderá ser chamada de framework ou somente são framworks programas como o Delphi?
R: Na verdade, nem uma coisa nem outra. Um framework normalmente é um *conjunto* de classes que tende a ser reutilizado em inúmeros projetos diferentes, por ser genérico e fornecer funcionalidades freqüentemente necessárias em diferentes projetos. Por exemplo, quem programa em Java costuma usar o Hibernate, que é um framework para facilitar o acesso a bancos de dados. Tem também o Struts para ajudar no desenvolvimento de aplicações web e o próprio JUnit que ajuda na criação e execução de testes unitários. Aliás, o DUnit é um exemplo de framework desenvolvido para Delphi.
10º A reutilização de código não é recomendável pelo livro, mas como não reutilizar, por exemplo, o código que faz consulta ao BD?
R: Acho que houve um equívoco. A reutilização de código é extremamente recomendável e até mesmo essencial para a utilização do Extreme Programming. Em XP há uma enorme preocupação no sentido de não duplicar código, o que é conseguido, naturalmente, com a reutilização de código tanto quanto possível.
11ºAo reutilizar o código você não estará fazendo uma duplicação já que irá copiar e colar?
R: Não. Quando me refiro a reutilizar código, não estou pensando em nenhuma hipótese na temível "técnica" de copiar e colar. Essa é uma forma de duplicar código, não de reutilizar.
Reutilizar significa escrever o código em um único lugar e permitir que ele seja acessado diversas vezes, por inúmeros clientes. É possível reutilizar código de várias formas, tais como se usando constantes, variáveis, métodos, superclasses etc.
12º Como está a aceitação em relação ao eXtreme Programming no Brasil?
R: Ainda tímida, já que em grande parte das organizações ainda é desconhecido. Porém isso vem mudando. Há uns três anos pouquíssima gente tinha sequer ouvido falar de XP no Brasil. Hoje em dia muita gente até já ouviu falar, mas ainda há poucas experiências. Em todo o caso, já existe uma séria de projetos usando e a tendência, na minha opinião, é que isso evolua rapidamente nos próximos anos, da mesma forma que vem ocorrendo no exterior.
