Por Luiza dalmazo
Publicado em 13/02/2009 – 20:29

Os blogs surgiram em 1997. Doze anos depois há mais de 133 milhões de blogs no mundo indexados no Technorati, pesquisador especializado nos chamados diários online. Eles já provaram sua importância. Recebem 77,7 milhões de visitantes únicos diariamente só nos Estados Unidos. Presidentes de empresas criaram blogs para falar de suas estratégias e se relacionar com os clientes. Surgiram companhias para rastrear os principais blogueiros e administrar os anúncios na web direcionados para o canal.

Na semana passada, entretanto, o jornalista Dan Lyons, que ficou famoso pela autoria do blog Fake Steve Jobs, questionou a viabilidade econômica desse modelo. ´´Durante dois anos eu estive obsessivo com a ideia de transformar o blog em um negócio´´, escreveu. Mas no dia em que sua identidade foi desvendada após uma notícia do jornal The New York Times, recebeu 500 mil visitantes no site e ganhou 100 dólares por isso. Naquele mês, ganhou 1 039 dólares após mais de 1 milhão de visitas. Mesmo depois de acordos para ganhar mais com anúncios, nunca foi o suficiente para que pudesse abandonar seu trabalho ´oficial´.

O relato traz de volta um questionamento importante: apesar da inegável relevância quando se trata de conteúdo, será que eles terão viabilidade econômica? A média anual de receita com anúncios nos EUA é de 200 dólares, segundo o Technorati. Mais: 46% dos blogueiros não têm propagandas em seus sites. Dos que lucram com a prática, só 28% tem um espaço no site para isso — a maioria ganha por cliques recebidos depois de buscas.

No Brasil, pouco mais de 2 milhões de pessoas exercem a prática, de acordo com o indexador de blogs em língua portuguesa Blogblogs. Como somos um mercado menos maduro e só 25% dos lares nacionais têm computador, os blogueiros brasileiros sofrem mais. A matéria de Larissa Santana na revista Exame mostra que alguns conseguem viver disso, mas os retornos vêm principalmente em forma de mimos que as empresas mandam para agradar os chamados ´formadores de opinião´.

Fonte: Portal EXAME

por Rodrigo Yoshima
em 2 de Julho de 2008 para o blog Débito Técnico

Nesta semana eu e o Phillip Calçado compartilhamos uma coisa: nós lemos artigos numa revista fora do mundo de tecnologia (se é que existe isso hoje em dia) e achamos conceitos ágeis lá. Veja este post no blog gringo dele:

BigPharma Problems & Solutions: Have You Seen This Before?

Na edição brasileira da Harvard Business Review de junho/2008, Tim Brown escreveu um artigo apresentando o “Design Thinking”. Ao ler o artigo ví que Design Thinking é recheado de conceitos ágeis. Muito recheado! É praticamente uma abordagem ágil para a inovação em todas as esferas empresariais.

A abordagem de [Thomas] Edison é um dos primeiros exemplos do que hoje se chama design thinking – metodologia que imbui todo o espectro de atividades de inovação de um etos de concepção centrado no homem… Edison não era um cientista especializado num campo apenas – era, antes, um generalista com aguçado tino comercial. Em seu laboratório em Menlo Park, New Jersey, Edison se cercava de gente com talento para improviso e experimentação. Na prática, derrubou o mito do “inventor genial e solitário” ao criar uma abordagem de equipe à inovação.

Preste atenção nesta parte:

A idéia era justamente não corroborar hipóteses preconcebidas – mas ajudar o investigador a aprender algo a cada lance iterativo.

(grifo meu)

É interessante ver como pragmatismos estão florescendo dentro no mundo empresarial das pessoas espertas e como mais e mais rigidez e controle estão obscurecendo a vida das empresas burras. Design Thinking é uma perspectiva humana para a solução dos problemas. É o envolvimento de cada indivíduo, de cada mente, na busca de uma solução viável e criativa. Isso envolve empatia, raciocínio integrativo, otimismo, experimentação e colaboração. O Design Thinking é a dinâmica de um processo colaborativo de inovação. Relatando um caso de solução para um problema de um grupo de enfermagem da Kaiser (não é a fábrica de cervejas), Tim Brown acrescenta o que colaborou para a solução:

…as equipes de inovação exploraram soluções potenciais por meio de brainstorming e prototipagem rápida… Um teste com protótipos não precisa ser complexo e nem caro. Um protótipo deve consumir apenas a quantidade de tempo, esforço e investimento necessária à geração de um feedback útil a evolução da idéia – nada mais. Quanto mais “acabado” parecer um protótipo, menor a probabilidade de que seus criadores ouçam o feedback – e se valham dele.

Olha que engraçado! A HBR, uma revista tradicionalíssima, está dizendo que meus protótipos visuais estão certos! Quando aquele gerentinho metido torcer o nariz poderei falar: “- Você leu o artigo sobre Design Thinking na Harvard Business Review?”

…o que ocorreu na equipe de enfermagem da Kaiser não foi um avanço súbito e revolucionário, nem o estalo de um gênio – foi fruto do trabalho árduo realçado por um processo criativo de descoberta centrado no ser humano, seguido de ciclos iterativos de testes com protótipos e aperfeiçoamento.

Esta é a parte que mais gostei (comentários meus entre parênteses):

O melhor jeito de descrever o processo de design é metaforicamente (Beck?) – como um sistema de espaços, em vez de uma série predefinida de passos ordenados (Gantt?). Esses espaços delimitam tipos distintos de atividades correlatas que, juntas, formam o continuum da inovação. O Design Thinking pode parecer caótico para um marinheiro de primeira viagem (seu chefe?). Mas, no decorrer de um projeto, os participantes acabam entendendo que o processo faz sentido e produz resultados (um release?), ainda que sua arquitetura seja distinta do processo linear fundado em marcos intermediários característico de outras atividades empresariais.

Este parágrafo no artigo é uma das melhores definições que já ví a respeito da natureza de um processo de design. Desenvolver software é 100% design. Isso foi tão contundente pra mim que contactei o Tim Brown – o autor do artigo – perguntando se ele tinha sido influenciado pelas práticas do Agile Software Development. Veja a resposta dele entre outras coisas:

From: Tim Brown
Date: 2008/7/2
Subject: Re: Article about Design Thinking on Harvard Business Review
To: Rodrigo Yoshima

Hi Rodrigo,
It doesn’t surprise me to hear that software design shares many of the same characteristics as design thinking. You are right that there has not been a lot of interaction between these two communities other than through the computer human interaction folks where I think a lot of these same issues have been discussed.

Thanks for making the link.

Best regards
Tim

On 6/30/08 5:53 PM, “Rodrigo Yoshima” wrote:

> Hi Tim,
> I’ve just read your article about Design Thinking and I’m
> just very very curious about how you put Design Thinking
> pratices together. Design Thinking concepts are very close
> to Agile Software Development Practices. Have you ever
> heard about it? Take a look at www.agilemanifesto.org.
>
> I see that the values of the Agile Manifesto is our flag of
> Design Thinking on Software Development. 100% of the
> software construction is design. Agile Practices are:
>
> – Human centered / Focused on Team Work
> – Iterative / Cyclical / Feed-back based
> – Use a lot of Prototypes / Sketches
> – Empirical
>
> I guess that you can really benefit from the contents
> that our community have being studying for the last 20 years.
>
> Cheers.
>
> Rodrigo Yoshima
> ASPERCOM / MundoJava

Sim! Mais uma vez provamos que o futuro do mundo empresarial é empírico e pragmático. Mais uma vez está provado que rigidez e processos inflexíveis impedem a inovação. Quem só tem martelo na mão só vê pregos pela frente… e sai martelando tudo.

Fonte: Débito Técnico

Postado por Mike Bria, traduzido por Flávia Castro de Oliveira em 13 Fev 2009 08:24 AM

Não é novidade que no coração dos projetos de software bem-sucedidos (e, francamente, conduzindo carreiras) está o bom design. Também não é novidade que definir o que "bom design" realmente significa tem sido o centro de uma lista infinita de debates, artigos, palestras, livros, discussões, etc, por décadas. Para ajudar, J.B. Rainsberger e Scott Bellware oferecem alguns conselhos a seguir até que surja uma verdadeira definição.

Recentemente, o Agilista bastante respeitado e líder do pensamento TDD J.B. Rainsberger comentou sobre o modo como ao longo dos anos ele tem "assistido uma série de tentativas para desenvolver uma definição construtiva e completa do bom design". Sua primeira observação e revelação pessoal:

Algumas pessoas lamentam a falta de uma definição construtiva e completa do bom design. Eu não, e hoje eu finalmente descobri por que penso que não temos de nos preocupar com isso.

Ele continua com uma retratação que ele não discorda de ter um "teste claro para decidir quão ‘bom’ é o design"" seria uma coisa útil (com exemplos como o porquê), mas em seguida se continua dizendo porque não se preocupa como fato de que talvez ainda não tenhamos "um verdadeiro caminho". Ele aponta para sua experiência, para o que ele acha que nós temos que fazer para ajudar a otimizar nossas chances de conseguir um "bom design":

Nos últimos dez anos eu aprendi algumas coisas incrívelmente úteis sobre o design:

• Quando os programadores escrevem testes de design, eles tendem a achar mais de seus próprios defeitos mais rapidamente, que reduz o custo total de compreender seu design.
• Quando os programadores duplicam o código, os índices de defeito aumentam, e quando eles reduzem a duplicação, os índices de defeitos diminuem.
• Quando os programadores começam a mudar código desconhecido, eles começam a esclarecer os nomes obscuros no código: nomes de variáveis, nomes de métodos, nomes de classes. Esta prática ajuda-os a alterar o código com mais segurança e de forma mais barate.

Eu aprendi estas coisas na prática, através de proramação em par e observando outros programadores no trabalho. Acho que é mais importante notar que só com apenas estas três observações, nós melhoramos o valor do design do software consideravelmente.

J.B. termina com uma reflexão sobre o que muitas vezes ele usa para identificar um bom design, "Eu me viro com o Teste do Miller: Eu reconheço quando o vejo."

Interessantemente, um dos temas chave do que J.B. está dizendo tem a ver com a idéia que para um design ser bom, deve ter "boa aparência" aos olhos de alguém novo para ele; (parafraseado) "..código desconhecido? Esclareça os nomes e então até você entenderá melhor…", "Eu sei quando eu ovejo". Para não esticar a mensagem do J.B. além do que ela significa, mas alguns poderiam usar isso para dizer que um bom design é "facilmente compreendido", e escrito sob a idéia recente do Scott Bellware. Em suas palavras:

A essência do "bom design" é a capacidade de ser absorvido pela mente humana. O design é "bom" quando ele pode ser facilmente compreendido.
…
Design bom é sobre conhecimento. Nós o envolvemos em todos os tipos de terminologia, mas no fim, é sobre fazer pequenos pedaços de software que são fáceis de entender por conta própria, que se encaixam para compor coisas maiores que si próprios e que possam ainda assim serem facilmente entendidos.

Bellware aprofunda sobre como o termo "testabilidade" refere-se a idéia de um bom design, mas não necessariamente na forma como muitas vezes é utilizado. Ele salienta que a "testabilidade" do código não é sobre "se ele pode ser testado", mas sim se ele "está [atualmente sendo] facilmente testado", e que "testes" tem tudo a ver com a compreensão:

Lembre-se, testar é fazer observações, e observações são para aprender.
…
Se é difícil criar um objeto afim de saber o que ele faz e se ele faz certo, então você provavelmente tem um objeto com o design pobre. Isto sugere que você usa codigo de teste para provar que você tem o design correto. E isto é o que testabilidade significa.

…
Não importa quão bom eu me torne em design orientado a objetos, a única prova de que um design é bom é código que prova concretamente que eu alcançei o mais elevado nível de facilidade de criação de um objeto para uso.

Assim, como aponta J.B., definir "bom design" sem ambiguidades pode ser aó mais uma daquelas cenouras numa vara; está sempre um passo a frente de nós, não importa quantos passos damos para frente. Mas ele também destaca, e como parece sugerir Bellware, há ferramentas à nossa disposição hoje em dia, para ajudar a nos guiar em direção a designs que nos mantenham produtivos e felizes, aproveitando nosso dia-a-dia como programadores. O que você acha disso?

Fonte: InfoQ

Parte dos novos padrões internacionais de relatórios financeiros (IFRS – International Financial Report Standards) foi introduzida no Brasil através da Lei 11.638/07. A lei deve conferir mais transparência às práticas contábeis, possibilitando maior controle e prestação de informações aos acionistas e investidores. Ela estabelece critérios para avaliação e demonstração dos ativos, passivos e riscos inerentes ao negócio desenvolvido o que está alinhado com as normas internacionais. Pela lei brasileira, empresas que tiverem ativo total superior a R$240 milhões ou receita bruta anual maior que R$300 milhões devem adotar os novos padrões de relatórios financeiros. Essa sistemática, na prática, igualou as empresas limitadas e as S/As na forma de apresentar seus resultados. Antes do IFRS, as empresas adotavam princípios locais de contabilidade geralmente aceitos (GAAP – Generally Accepted Accounting Principles). As empresas americanas utilizam princípios conhecidos como USGAAP. O Brasil adota o BRGAAP. E assim, cada pais adotava seus princípios contábeis. O IFRS normaliza a forma de apresentação dos relatórios financeiros.

Entretanto, a fase de transição traz sérias implicações para empresas de todos os portes. As S/As terão que aderir ao IFRS, sem deixar de estar em conformidade com suas regulamentações fiscais, de dividendos, etc., o que leva essas empresas a terem no mínimo dois conjuntos de relatórios financeiros.

Esse cenário complexo de negócio deve ser refletivo nos ERPs das empresas. Os ERPs devem ter recursos para manter uma contabilidade paralela para suportar os padrões IFRS e os padrões locais, em qualquer país. O ERP deve permitir ajustar as diferenças entre o padrão IFRS e os princípio locais (GAAP). Todas essas condições devem ser estar em conformidade com a Lei americana Sarbanes-Oxley e regras contábeis locais. Para empresas que adotam soluções de mercado (SAP, JDEdwards, Oracle Financial, Microsiga, etc.) esses ajustes ficam por conta dos fornecedores. Para quem ainda possui sistemas financeiros desenvolvidos internamente terão que investir na introdução desses ajustes. Embora, em ambos os casos será necessário a participação de especialistas de alto nível para orientar as modificações, sob o risco de perder a conformidade das informações.

A questão que sempre preocupa os CIOs é a velocidade de localização dessas exigências nos ERPs que executam por aqui. Os fornecedores, por metodologia e prioridades, fixam datas apertadas para liberar as modificações e deixam os clientes, que estão no final da linha de produção, com prazos curtos de implantação das novas versões.

Nessas situações a demanda por consultores especializados cresce de forma exponencial e, também, os custos de implantação. Nessas ocasiões paramos para refletir se não seria importante ter uma equipe interna com todo esse conhecimento para evitar a dependência das empresas de consultoria. A resposta é que devemos ter um mix de profissionais internos e externos e, a equipe de planejamento de TI deve estar atenta a potenciais demandas futuras para se antecipar na contratação dos melhores profissionais. A falta de planejamento acaba deixando a empresa em dificuldades, seja pela falta de profissionais experientes ou ter que pagar altos custos de contratação.

Sumarizando, a Lei 11.638/07 que introduz no Brasil algumas normas do IFRS traz implicações sérias nos ERPs das empresas porque deve coexistir por um período dois ou mais conjuntos de relatórios financeiros, um suportando o IFRS e outro as normas locais (GAAP). A área de TI deve se antecipar a movimentos como esse para conseguir contratar profissionais experientes para a fase de implantação dos ajustes, evitando um impacto negativo no atendimento das novas normas regulatórias e pagar altos preços por profissionais qualificados.

Fonte: efagundes.com

Mais que comparar fornecedores, CIOs devem avaliar as reais necessidades das áreas de negócio. Para isso, é importante que consultem todos os funcionários, já que muitas vezes os gestores não têm conhecimento total dos problemas rotineiros enfrentados por seus times

Nancy Shawver*
Publicada em 13 de fevereiro de 2009 às 08h05

Mesmo com a ajuda de consultores, técnicos e especialistas de negócios, a implementação de CRMs muitas vezes não é bem-sucedida. Mais do que a necessidade de uma ferramenta, as empresas precisam ter a noção exata das demandas que pretendem suprir com esses sistemas de gestão dos clientes para, só aí, escolher a opção mais adequada à sua estrutura organizacional.

Para tanto, o CIO ou o responsável pela implementação do sistema de Custom Relationship Management deve avaliar todas as áreas de negócio da companhia. Em primeiro lugar, não é possível implementar um programa global se os departamentos da companhia não forem completamente integrados – se isso deixa de acontecer, a ferramenta fica em um “vácuo” e acaba ficando aquém da performance necessária.

Além disso, todos os colaboradores da organização devem ser consultados antes da implementação do sistema. Só assim, todas as suas reais necessidades serão conhecidas, já que muitas vezes os gestores não têm conhecimento total dos problemas rotineiros enfrentados por seus times.

*Nancy Shawver é especialista em implementações de CRM

Fonte: CIO

Juliano Barreto, de INFO Online
13 de fevereiro de 2009

Quando foi promovido, Marthin De Beer, atual vice-presidente sênior de tecnologias emergentes da Cisco, precisou mudar de Dallas, no Texas, para San Jose, na Califórnia. Além da distância de 2 253 quilômetros entre as duas cidades, outro problema: a secretária de Beer não poderia acompanhá-lo. O estilo de vida no Silicon Valley seria caro demais para ela. Foi aí que o executivo acabou transformando o impasse numa excelente propaganda do que os sistemas de telepresença podem fazer. Hoje, quem chega ao escritório dele na Califórnia é recepcionado por uma tela full HD de 67 polegadas, que exibe ao vivo a secretária, sentadinha e sorridente lá em Dallas.

Por essa descrição, você pode ter imaginado que a projeção é apenas uma espécie de videoconferência em tela grande. Não é bem por aí. As opções de telepresença comercializadas por empresas como Cisco, HP e Polycom criam uma impressionante sensação de imersão e envolvem uma infraestrutura especial que vai da configuração da rede com links dedicados até a decoração das salas. De acordo com a consultoria Frost & Sullivan, a venda e a instalação de sistemas como esse movimentarão mais de 3 bilhões de dólares no mundo até 2010. Para montar a infraestrutura, uma empresa gasta de 30 mil a 500 mil dólares, mas economiza com passagens aéreas e ganha em produtividade. É quase como um teletransporte para os executivos.

Ao vivo e em full HD
A reprodução da imagem de clientes ou de sócios em tamanho real e em alta definição, em 1 080p, é a característica mais atraente das soluções de telepresença. Só que o resultado final dessa mágica está longe de ser feito apenas por câmeras e LCDs. As salas de telepresença seguem um padrão idêntico de pintura, mobília e iluminação — tudo para dar uma sensação de continuidade entre as duas salas. “O ambiente especial e a qualidade de vídeo aumentam a percepção das reações, dos movimentos de seu interlocutor como se fosse numa reunião de verdade”, diz Carlos Pane, gerente da área de comunicação integrada da IBM.

O áudio também é calibrado para reproduzir o posicionamento dos executivos na mesa. Com um sistema de som espacial, os canais de áudio (entre 3 e 5) reproduzem as vozes mais para o canto ou mais para o centro da mesa de reunião. Se uma folha de papel for arrastada de uma ponta a outra da mesa dá para ouvir o ruído atravessando a sala com perfeição, como foi comprovado pela INFO numa reunião realizada na sala TP-3000, da Cisco.

Além disso, a empresa precisa ter um bom link de internet disponível e equipamentos para fazer a compressão e a descompressão do vídeo em tempo real. “Com o uso de codecs, são necessários 5 Mbps para a transmissão de cada tela em 1 080p. Sem a compressão, seria preciso 1,5 Gbps para realizar a mesma tarefa”, diz Marcelo Ehalt, diretor de engenharia da Cisco.

Apesar de toda essa complexidade, o usuário não precisa ser fera em tecnologia. Basta reservar a sala de reunião pelo Outlook e depois apertar um botão do telefone-IP para iniciar a chamada. Todo o resto do trabalho fica com as equipes de instalação e suporte, que deixam a sala calibrada e pronta para ser usada. “Há equipes treinadas para testar a conexão antes das reuniões. A empresa também pode solicitar o acompanhamento do suporte em tempo real”, afirma Pierre Rodrigues, diretor de operações da Polycom. O técnico vê a conferência por meio de outra câmera e resolve eventuais dificuldades em tempo real.

Quanto vale o show?
Depois dos atentados de 11 de setembro de 2001, as empresas americanas passaram a pensar duas vezes antes de colocar seus executivos em viagens de negócios. A solução na época foi investir em videoconferência. Atualmente, o medo de terroristas arrefeceu, mas a crise econômica global pede cortes de custos. A telepresença, mesmo com preços ainda altos, pode render um bom retorno sobre o investimento.

Para ver se o cálculo vale a pena, não basta comparar os 30 mil dólares de uma sala de telepresença básica com os 8 mil reais de uma única passagem de São Paulo para Nova York na classe executiva. “Dependendo do salário do executivo, você deve calcular o tempo que ele perde viajando. São horas de trabalho desperdiçadas”, afirma Pierre Rodrigues, da Polycom.

Hologramas a caminho
A exibição holográfica da repórter da CNN na cobertura das eleições americanas causou frisson pelo mundo, mas cenas como aquela podem começar a se repetir em qualquer sala de reuniões. Com um novo protocolo de rede batizado de Next IP e projetores especiais, a empresa australiana Telstra demonstrou uma tecnologia para exibição de imagens 3D ao vivo. De acordo com a Telstra, o sistema só deve ser comercializado daqui a uns cinco anos, devido ao elevado custo da infra-estrutura de roteadores com velocidade de até 193 terabits por segundo.

Kabul Online
Se a história do filme Cartas de Iwo Jima, sobre a Segunda Guerra Mundial, se passasse nos dias de hoje, o título do longa definitivamente precisaria mudar de nome. A comunicação entre os soldados e suas famílias avançou muito desde então. Os soldados aliados da OTAN, que servem em Kabul, no Afeganistão, por exemplo, já podem se comunicar com seus familiares por meio de um sistema de telepresença portátil feito de material resistente ao calor. O sinal é enviado por satélites e exibe em tempo real as imagens dos familiares, numa sala do quartel general da OTAN, na Bélgica.

Leia Também: Os 10 mitos sobre a telepresença

Fonte: INFO Professional

São Paulo – Profissional responsável por projetar e integrar diversas soluções para automação de residências tem um mercado muito promissor.

Por Rodrigo Afonso, repórter do COMPUTERWORLD
13 de fevereiro de 2009 – 07h00

Muitas dos recursos de residência que antes pareciam ficção científica hoje são realidade. Já é possível ligar equipamentos à distância, programar o horário da irrigação do jardim, fechar cortinas, acionar o alarme por telefone, controlar a câmera de segurança pela internet, entre outros recursos. Com o grau tecnológico atual, quase não há limites para a automação.

Para juntar tantos recursos e centralizar sua administração, um novo profissional passa a ser muito requisitado: o integrador de automação residencial. Há poucas empresas brasileiras na área, mas a demanda por este tipo de serviço cresce exponencialmente.

Segundo Robert Andrade, analista da consultoria Robert Half, os profissionais da área são aqueles que possuem o raciocínio lógico como destaque, pois acaba tendo de buscar informações diversas em manuais, analisar muitas documentações e encontrar a melhor forma de integrar soluções. “Programadores e desenvolvedores podem se destacar na área. Profissionais de engenharia e arquitetura também têm ótimas chances de ganhar este mercado”, afirma.

Não há um roteiro específico para se buscar formação. O profissional que pode se dar bem é aquele que gosta da área, fica muito antenado com relação à novos lançamentos e que mantém um grande conhecimento sobre as melhores soluções com base na compatibilidade.

Conheça um integrador de automação residencial
José Roberto Muratori é um engenheiro de produção que abriu sua própria firma de automação residencial com uma sócia arquiteta. O profissional atuava na área em que se graduou, mas migrou de área após enxergar o potencial de crescimento da automação residencial.

Muratori afirma que é preciso conhecer profundamente as soluções disponíveis e acompanhar atentamente o mercado para saber dos melhores lançamentos de produtos. “Não preciso ser especialista em equipamentos determinados, mas preciso conhecer o suficiente para integrar em um sistema único e eficiente”, afirma Muratori.

O profissional acrescenta que estruturar um plano passo-a-passo no papel ajuda muito no momento de pensar nas melhores soluções. “Todo o trabalho da automação residencial começa em um projeto muito bem feito. Sem projeto, é impossível haver uma implementação com qualidade”.

Muratori aposta em um desenvolvimento muito rápido do mercado, já que alguns países estão muito a frente neste setor. O profissional afirma que a decolagem depende de projetos de construção civil que já prevejam a automação, barreira que já começa a ser vencida nos lançamentos mais modernos.

Fonte: Computerworld

Martin Fowler escreveu um artigo polêmico para Scrummers, mas não pode ser visto como uma crítica ao Scrum e sim como uma crítica a quem aplica Scrum da maneira errada e a quem não se preocupa em tornar isso aparente. A seguir a tradução na íntegra do artigo.

Scrum Flácido

por Martin Fowler
Janeiro 29, 2009

Existe uma bagunça que ouço em muitos projetos recentemente. Funciona assim:

– Querem usar um processo ágil, escolhem Scrum
– Adotam as práticas Scrum, e talvez até os princípios
– Depois de algum tempo, o progresso é lento, porque a base de código é uma bagunça

O que acontece é que eles não prestaram atenção à qualidade interna de seu software. Se você cometer esse erro, irá rapidamente descobrir que seu progresso foi desacelerado, porque é muito difícil adicionar novas funcionalidades que você gostaria. Você caiu no problema de Débito Técnico e seu scrum caiu de joelhos. (E se você esteve num scrum real, saberá que isso é uma Coisa Ruim).

Mencionei Scrum, porque quando vemos esse problema, Scrum parece ser particularmente comum, como o processo nominativo que a equipe segue. Para muitas pessoas, a situação é exacerbada pelo Scrum, porque Scrum é um processo centrado em técnicas de gerenciamento de projetos e deliberadamente omite qualquer prática técnica, em contraste (por exemplo) com Extreme Programming.

Defendendo o Scrum, é importante apontar, que só porque ele não inclui nenhuma atividade técnica dentro de seu escopo, isso não deve levar ninguém a concluir que ele não acha isso importante. Sempre que ouvi Scrummers proeminentes, sempre enfatizaram que você deve ter boas práticas técnicas, para ter sucesso com um projeto Scrum. Eles não dizem quais práticas técnicas devem ser, mas você precisa delas. Afinal projetos enfrentam problemas por causa de qualidade interna pobre o tempo todo, e o fato que muitos entram abaixo da bandeira do Scrum, parece ser mais pelo fato de Scrum ser popular no momento, do que qualquer coisa particular no Scrum. Popularidade e Difusão Semântica tendem a andar juntos.

Então, o que fazer a respeito?

A comunidade Scrum precisa redobrar seus esforços, em garantir que as pessoas entendam a importância de práticas técnicas fortes. Certamente qualquer tipo de revisão de projeto deve incluir o exame de quais práticas técnicas estão presentes. Se você estiver envolvido ou conectado a esse tipo de projeto, faça barulho se o lado técnico estiver sendo negligenciado.

Se estiver apresentando Scrum, garanta que está prestando atenção às práticas técnicas. Tendemos a aplicar muitas do Extreme Programming e eles se encaixam muito bem. Os XPers costumam brincar que com alguma justificativa, Scrum é apenas XP sem as práticas técnicas que a fazem funcionar. De qualquer forma, as práticas de XP são um bom ponto para se começar – e certamente serão muito melhores do que nada.

Sempre gosto de apontar que não são metodologias que levam ao sucesso ou fracasso. Usar um processo pode ajudar uma equipe a subir no jogo, mas no fim é a equipe que importa e que carrega a responsabilidade de fazer o que funciona para elas. Estou certo que muitos dos projetos Scrum Flácidos em andamento, prejudicarão a reputação do Scrum, e provavelmente a reputação maior de Ágil. Mas já que vejo Difusão Semântica como algo inevitável, não estou desproporcionadamente alarmado. Equipes que fracassam, provavelmente vão fracassar seja lá qual metodologias elas – erradamente – apliquem. Equipes que tem sucesso, construirão suas práticas sobre boas idéias e o papel da comunidade scrum é espalhar essas boas idéias.

Muitas pessoas estão olhando para Lean como a Próxima Grande Coisa Ágil. Mas quanto mais popular lean se tornar, mais vai incorrer nos mesmos problemas que Scrum está enfrentando agora mesmo. Isso não torna Lean (ou Scrum) sem valor, apenas nos lembra que Indivíduos e Interações são mais valiosos que Processos e Ferramentas.

Além das funções habituais, nessas prestadoras de serviços os executivos de TI devem gerenciar investimentos e resultados provenientes do segmento de P&D e equilibrar o budget para inovação de acordo com os objetivos do negócio

Srini Kumar*
Publicada em 10 de fevereiro de 2009 às 17h06

Comum em empresas, principalmente de grande porte, as consultorias desempenham hoje papel estratégico no desenvolvimento de políticas globais de negócios e projetos específicos nos ambientes corporativos. Tais prestadoras de serviços atuam, muitas vezes, em parceria com as áreas de TI dos clientes na implementação de programas e ajustes operacionais necessários ao aumento de produtividade empresarial.

Até aí, nenhuma novidade. Porém não podemos esquecer que as consultorias, em si, também são empresas estruturadas que precisam de gestores de tecnologia e podem ser boas opções para executivos que procuram uma nova oportunidade ou a recolocação profissional.

Os CIOs são responsáveis pela estratégia técnica da companhia e pela identificação das ferramentas que proverão vantagem competitiva ao negócio. Entretanto, além dessas funções, os executivos de TI também devem desempenhar outros papéis no caso das consultorias, entre eles, o de gerenciar os investimentos e os resultados provenientes da pesquisa e desenvolvimento, bem como o alinhamento do budget para inovação, de acordo com os objetivos da organização.

Seguem alguns pontos que os CIOs precisam conhecer antes de trabalhar em consultorias:

• A maioria dos clientes conta com um executivo de TI especialmente direcionado para lidar com os projetos realizados em parceria com as consultorias;
• Todas as decisões tomadas terão impacto direto no negócio da empresa;
• Além das decisões internas, CIOS de consultorias podem participar de alguns projetos com clientes;
• Nas consultorias, ao contrário do que acontece em outros segmentos, a área de TI não é vista como um centro de custos, e sim como investimento indispensável para desenvolvimento do negócio.

Srini Kumar é fundador e CEO da PlanCube.

Fonte: CIO

Segue abaixo um vídeo do criador do sistema GTD (Getting Things Done) também ministrado na Google:

Para facilitar, e como o vídeo tem +/- 45 minutos de duração, fiz um resuminho dos pontos que achei mais interessantes:

- É necessário adquirir a habilidade de lidar com o inesperado sempre tendo a mente limpa;

- Cultivar a condição de “Mind like water”, que significa adequar corretamente a sua atitude com a situação que se apresenta. O exemplo que David Allen dá é quando se joga uma pedra na água a água responde com movimento de acordo com o tamanho da pedra (problema) jogado, não mais nem menos;

- Cultivar a habilidade para concentrar-se. Deve-se eliminar as distrações que são emanadas de tarefas mal organizadas organizando-as em um sistema;

- O seu cérebro não é bom para lembrar, relembrar e avisar de coisas que você precisa fazer. Ele precisa de um sistema que não dependa somente dele;

- O seu cérebro precisa confiar neste sistema no qual ele sabe que vai ter tudo aquilo que precisa para concluir as tarefas que você definiu como necessárias;

- Você precisa dar atenção àquilo que sua mente está tentando dar atenção, caso contrário aquilo que está te tirando a concentração vai ter mais atenção do que merece;

- É necessário capturar, clarificar e organizar as tarefas a fazer em todos os aspectos da sua vida. Não podemos diferenciar o trabalho das outras áreas da sua vida. A única diferença vem da pergunta: O que deve ser feito agora?;

- Manter sempre a sua perspectiva e controle das tarefas;

Definição dos tipos de atitudes (perspectiva X controle):

Reactor: Só reage àquilo que jogam em cima dele. Apagador de incêndios. Não tem controle nem perspectiva.
Crazy Maker: Tem milhões de idéias e perspectiva, mas sem controle algum. Muito volátil.
Micro Manager: Controla demais pequenos detalhes que não fazem diferença dentro da perspectiva, só geram stress.
Master & Commander: Controle e perspectiva em sintonia.

Passos para cultivação do sistema GTD:

Coletar: Nada deve permanecer na mesa, na cabeça ou no seu caminho;
Processar: Depois de coletar as informações deve-se processá-las de forma a serem passíveis de organização;
Organizar: Categorizar e limpar as tarefas de sua mente para dentro do seu sistema. Definir todos pontos e ações futuras;
Revisar: Revisar todo o sistema para ver se faz sentido, se é simples e se é eficaz. Isso deve ser feito continuamente durante toda a utilização do sistema;
Fazer: Finalemente, dar vazão as ações que deverão ser realizadas conforme foi estipulado nos passos anteriores;

David Allen ainda fala sobre o horizonte de perspectivas, que tratarei em posts futuros.

O livro dele pode ser encontrado aqui.

Fonte: D’-A-R-T