O número de instancias que devem ser usadas, bem como o tamanho delas, depende basicamente da analise feita a partir de um plano de capacidade. Não vamos esgotar o assunto de planejamento de capacidade, mas podemos dar uma idéia de como inicia-lo.

Planejamento de capacidade é o processo de previsão da saturação do sistema pelos níveis futuros de carga de processamento e ainda de se determinar a melhor forma de se retardar esta saturação tanto quanto possível.

Para construção de um plano de capacidade, o primeiro passo é definir a carga total da aplicação e os requisitos de capacidade usando métricas especificas como, tempo de resposta, capacidade de hardware consumida ou picos de processamento.

3 perguntas importantes

Com base em 3 perguntas simples podemos iniciar o planejamento de capacidade. Essas perguntas são:

Quão bem sua infraestrutura está atuando?

É importante medir a carga de trabalho para cada peça individual da arquitetura que compromete sua aplicação, servidor web, base de dados, rede. Compare esses itens com os requisitos de desempenho e verifique se a atuação está de acordo com o esperado.

O que será preciso no futuro para manter um desempenho aceitável?

Planeje o futuro baseado no que se sabe a respeito do passado da performance do sistema, então junte esse planejamento com sua capacidade de cumprir e um prazo realista. Determine o que será preciso e quando será preciso. Leve em conta recursos humanos, arquitetura e até recursos financeiros.

Podem ser necessárias otimizações em códigos, troca de componentes ou até upgrade de harware. Tudo isso implicará em recursos de alguma forma, fique atento a isso.

Como será possível “instalar” e gerenciar recursos, após conseguir o que se deseja?

É preciso ser capaz de se adaptar a novas realidades, por isso devemos aplicar ferramentas e técnicas que facilitem a adequação a novos cenários.

Não podemos esquecer a importância da melhoria continua, que pode nos ajudar a aperfeiçoar rotinas e processos ao longo do tempo.

Importância de regras

Após o inicio do planejamento de capacidade devemos verificar as regras que gostaríamos de atender. Em geral elas devem vir acompanhadas de métricas para que se possa quantificar o atendimento ou não da regra.

Para simplificar é possível iniciar o planejamento de capacidade com apenas 2 tipos de regras.

Regras de agendamento

As regras de agendamento podem atender as demandas On/Off e Sazonal. Com elas podemos agendar períodos em que gostaríamos de escalar nossos recursos para atendimento da demanda.

Regras baseadas em métricas

Basear as regras em métricas é o cenário mais comum, por isso é importante alinhar os dados coletados com o planejamento feito na inicial do planejamento de capacidade.

Cargas e Métricas

As cargas de processamento podem variar de acordo com o sistema, por isso é importante utilizar as métricas corretas para se obter os resultados desejados.  Podemos categorizar as métricas para um melhor entendimento sobre elas.

Métricas imediatas

As métricas imediatas procuram definir e quantificar o trabalho que está sendo feito pelo sistema naquele momento. Como exemplos, podemos citar:

• Número de requisições atendidas por segundo
• Tempo de processamento de determinada rotina
• Número de mensagens atendidas em uma fila de processamento por segundo

Quanto a esse tipo de métrica deve haver cuidado para que a medição não interfira na performance do sistema e também com o tratamento dos dados que serão muito volumosos.

Métricas de carga

Essas métricas definem a carga que está sendo aplicada ao sistema.  Algumas sugestões de medição podem incluir:

• Utilização do CPU
• Utilização de Mémoria RAM
• Tamanho de fila de processamento

Algumas dessas métricas podem ter valor isoladamente, outras podem necessitar de algum dado adicional. Por exemplo, a quantidade de mensagens em uma fila de processamento só produz alguma informação útil se tivermos dados como o número de mensagens que podemos atender por segundo. Assim podemos provisionar nossas WorkRoles para atendimento da fila por exemplo.

Métricas derivadas

Como o próprio nome indica, essas métricas são variações de dados obtidos.  Como exemplo podemos ter:

• Variação na taxa de utilização do CPU
• Variação do número de requisições por segundo
• Variação do tamanho da fila de processamento

Esse tipo de métrica é importante para determinar a velocidade de crescimento e diminuição da demanda. Dessa forma podemos planejar melhor a adição ou diminuição de recursos para não termos gastos desnecessários.

Métricas indiretas

Esse tipo de indicador pode não produzir nenhuma informação se analisado isoladamente, mas se colocado em contexto juntamente com outras métricas, podem produzir indicadores interessantes. Podemos por exemplo monitorar a quantidade de usuários do sistema ou os gastos com instâncias ou banco de dados no Windows Azure.

Com essas informações é possível estabelecer qual a relação de número de acessos e total de usuários do sistema em um momento de pico de carga. É possível tornar realidade cálculos que incluem, por exemplo, o custo financeiro de 1 usuário no sistema.

Reunindo informações necessárias

A plataforma da Microsoft possui muitas fontes que podemos usar para coletar dados. Uma delas é o Windows Azure Diagnostics (http://msdn.microsoft.com/en-us/library/windowsazure/hh411552.aspx), que permite a coleta de dados de aplicações que estão sendo executadas na plataforma. Essa API pode ser usada para log, auditoria, monitoramento de performance, entre outras coisas.

É possível também obter outros tipos de informações através da Service Management API do Windows Azure, que informa por exemplo, o status de uma determinada instância. Essa é uma API muito importante no que diz respeito a escalar os recursos computacionais.

É importante lembrar que quanto maior o volume de informação coletada, maior será a precisão para tomada de decisões, porém isso implicará em um custo maior também, relativo a trafego dessas informações de analise, armazenamento e até performance em determinados casos.

Conclusão

Ao concluir o planejamento de capacidade e tentar reunir as informações necessárias, você pode ter percebido que as regras têm diferentes complexidades. Submeter os dados coletados a tratamento, pode se tornar uma tarefa que exija a implementação de uma “engine” própria de interpretação de regras.

Sugestões e tipos de regras

Regras restritivas

Pelo bem do sistema e as vezes pela saúde financeira da empresa, é interessante criar regras de restrinjam a atuação em determinadas situações. Por exemplo:

• “Execute no mínimo 2 instâncias”
• “Utilize os recursos necessários para melhor performance enquanto a conta de uso estiver abaixo de R$ 1.000”

Regras de respostas

Para garantir o bom funcionamento do sistema, em determinados momentos é preciso “responder” a picos de utilização imediata ou análise de variações com o passar do tempo. Como exemplo podemos citar:

• “Se a media de requisições por segundo aumentar x%, aumente uma instância”
• “Se o tempo de resposta de uma requisição ultrapassar 1000ms, aumentar uma instância”
• “Se o número de mensagens na fila de processamento ultrapassar 100, adicionar uma Worker Role”

O processamento de regras pode ser algo muito complexo, por isso não subestime a importância dessa etapa na construção da sua aplicação. Essa é apenas uma sugestão pessoal para implementação e definição de regras.

Aplicação

A construção de um sistema de escalabilidade dinâmica pode ser dividida em 3 grandes áreas, são elas:

Monitor de Performance

• Monitora as aplicações no Windows Azure
• Coleta os dados
• Armazena os dados

Motor de Interpretação de Regras

• Executa o tratamento dos dados
• Confronta dados e regras estabelecidas

Motor de Escalabilidade

• Recupera os dados coletados e armazenados pelo monitor de performance
• Passa informações ao motor de interpretação de regras
• Executa rotinas de chamadas ao Windows Azure para provisionar os recursos na plataforma, de acordo com a saída estabelecida pela interpretação das regras.

É possível também construir uma aplicação que seja reutilizada em ambiente Windows, fora da nuvem, pois os contadores de performance em muitos casos são comuns. Tudo vai depender do nível de acoplamento do seu código com as funcionalidades e APIs do Windows Azure.

A construção de uma aplicação para alcançar a escalabilidade dinâmica no Windows Azure não é algo tão complexo quanto pode parecer. Mas para que essa aplicação agregue valor ao seu produto, é preciso entender alguns conceitos por trás da escalabilidade dinâmica, que partem do planejamento de capacidade e chegam até a utilização do Windows Azure.

Esse artigo teve como objetivo sugerir um modelo para implementação de uma “engine” de escalabilidade dinâmica e explicar alguns conceitos que devem ser difundidos para o melhor atendimento da demanda computacional, através do planejamento de capacidade, utilizando a ferramenta Windows Azure.

Espero que gostem.

Introdução

O Windows Azure é um ambiente flexível, oferecendo aos desenvolvedores de software uma grande resposta a cenários que podem tirar vantagem da escalabilidade. A arquitetura do Windows Azure também permite que aplicações completas sejam reformadas como serviços, excluindo a necessidade de operações e equipamentos na infra-estrutura local.

Embora a plataforma forneça ferramentas e suplementos específicos para o sistema de desenvolvimento utilizando as tecnologias Microsoft, o Windows Azure é um ambiente aberto que permite que os desenvolvedores continuem usando as linguagens, ferramentas e serviços habituais.

Ter a computação funcionando apenas como um pacote de conveniências era um sonho que tinha o potencial de transformar o mercado de TI, oferecendo inúmeras vantagens, como a forma de entrega de softwares e a maneira de se pensar em recursos de hardware. Cloud Computing é um novo termo para a tão sonhada, computação como utilidade,  que recentemente emergiu como uma realidade comercial.

A escalabilidade que a cloud computing nos permite é muito mais que isso, é uma maneira de ganhar dinheiro, ou deixar de gastá-lo. É um caminho para pequenas organizações parecerem e tornarem-se grandes. Alguns dos fatores que tornam a cloud computing tão atraente são:

1. A ilusão de recursos computacionais infinitos, disponíveis sob demanda, eliminando a necessidade dos clientes de pensar muito a frente para provisionar recursos.
2. A eliminação de um comprometimento por parte dos usuários de computação em nuvem, permitindo companhias começarem pequenas e aumentar recursos de hardware apenas quando há um aumento nas suas necessidades.
3. A habilidade de pagar pelo uso de recursos de hardware baseados em períodos pequenos como processamento por hora, armazenamento por dia e etc. E principalmente por liberar esses recursos quando não são mais necessários.

Situações de uso

• On e Off – Podemos exemplificar esse tipo de demanda com sistemas ou rotinas que funcionam em horários pré-determinados para consolidar dados. A frenquencia pode variar a depender do tipo de sistema. O processamento pode ocorrer em horas determinadas do dia ou somente uma vez por mês, tudo depende da necessidade do sistema.
• Crescimento rápido – Um dos melhores padrões de uso para tirar vantagem da computação em nuvem. A dificuldade das startups em prever o crescimento da sua demanda é algo conhecido por todos. Utilizar cloud computing nesse cenário pode ser a diferença entra e vida e a morte de uma startup, que precisar gastar o mínimo possível, ao mesmo tempo que tem que responder rapidamente ao crescimento da demanda.
• Carga Imprevista – Nem sempre temos capacidade de prever um pico de trafego, por conta disso, essa também é uma boa situação para aplicação de cloud computing. O Windows Azure por exemplo, permite que você aumente seu poder de processamento em pouco tempo. Dessa forma será possível atender a demanda repentina de um website que virou hit nas redes sociais por exemplo.
• Carga Sazonal – Com o tempo você pode identificar um padrão sazonal na sua demanda computacional. Para esses casos a computação em nuvem o ajudará a manter uma estrutura mais barata durante a maior parte de tempo, aumentando os recursos de processamento apenas quando necessário.

Windows Azure e cargas

A característica de provisionamento dinâmico é um dos fatores que mais interessa, do ponto de vista da aplicação.  Com esse recurso, podemos ter a redução de custos operacionais, com uma configuração de infra-estrutura mais aderente às necessidades do negócio.

No Windows Azure temos o conceito de instancias computacionais, que facilitam o trabalho de provisionamento dinâmico. Na plataforma da Microsoft é possível manipular o tipo/tamanho dessas instancias, assim como o número delas.

Tipos de instancias

Atualmente existem 5 tipos ou “tamanhos” de instâncias, cada uma delas com diferentes recursos computacionais. Abaixo segue uma tabela informativa:

Podemos perceber que o Windows Azure está preparado para atender a maior parte das necessidades computacionais. Temos opções de instâncias multiprocessadas, com baixo ou alto desempenho de I/O, com grandes capacidades de armazenamento interno e memória. Tudo depende da sua necessidade.

Adicionando e removendo instancias

Apenas o alto poder de processamento não encerra a discussão quando falamos de sistemas que precisam de uma alta disponibilidade. É importante saber que no Windows Azure existe a possibilidade de adicionar ou remover instancias computacionais a qualquer tempo.

A recomendação básica é que se trabalhe com um mínimo de 2 instancias computacionais sempre, para manter a disponibilidade.  Dessa forma se pode atender a picos de demanda e adequar o número de instancias a necessidade, sem causar indisponibilidade do serviço, de forma transparente para o usuário.

O Windows Azure fará o balanceamento de carga automaticamente para sua aplicação, portanto, devemos apenas tomar os cuidados básicos com relação a rotinas que tenham afinidade com a maquina em que são processadas.

Parece que em breve será possível controlar o esquema de load balancer nas aplicações, mas esse é um tema que merece uma outra discussão.

Podemos aplicar Poka-Yoke através de testes unitários e até através da arquitetura do software. O desenvolvimento guiado por testes é um forma de se aplicar Poka-Yoke e é muito fácil de se perceber isso, porque você está fazendo teste para garantir um processo com qualidade e não para testar a qualidade de um processo já pronto. A diferença é sutil mas muito importante.

Se você já tem um nível de maturidade um pouco maior, eu vou tentar adivinhar o que acontece com sua equipe.

Todos utilizam TDD, a arquitetura é aberta e flexível e os Smurfs passeiam pela manhã no seu escritório.

A realidade dos Smurfs não é impossível de ser alcançada,  porem depende de comprometimento da equipe e profissionais maduros.  Nós sabemos que essa não é a realidade da maioria das empresas. É difícil encontrar profissionais maduros e o comprometimento é um requisito que depende de vários outros fatores dentro da organização.

Esse é um problema de algumas metodologias ágeis na área de software. Elas trouxeram as pessoas para o centro e exigiram comprometimento para transformar todos os princípios ágeis em realidade. Mas infelizmente o mundo não é assim e frequentemente você terá que lidar com profissionais sem o comprometimento suficiente.

Às vezes temos equipes que misturam todo tipo de profissional, essa é a realidade da maioria. Nesse caso aplicar Poka-Yoke em arquitetura significa construir de forma que evite a falha por parte dos menos comprometidos ou menos experientes.

No seu ambiente de trabalho, como esses assuntos são tratados?

Existem diversas maneiras de estruturar a escrita de teste, mas vou falar rapidamente os conceitos básicos. Vamos ao código que interessa.

Para esse exemplo estou usando a suite de testes nativa do Visual Studio, mas todas as outras do mercado você deve encontrar as mesmas opções, apenas com nomes um pouco diferentes. Usando C# no exemplo:

[TestClass]
    public class ProdutoRepositorioTeste
    {

        public CommerceContexto contexto { get; set; }

        // Use TestInitialize() para rodar código antes de cada teste
        [TestInitialize()]
        public void InicializacaoTestes()
        {
            EstrategiaInicializacaoBancoDadosTeste estrategia = new EstrategiaInicializacaoBancoDadosTeste();
            contexto = new CommerceContexto("conexaoTeste", estrategia);
        }

        // Use TestCleanup para executar algum código depois de cada teste
        [TestCleanup()]
        public void MyTestCleanup()
        {
            contexto.Dispose();
        }

        [TestMethod]
        public void Deve_Retornar_Somente_Produtos_A_Venda()
        {
            //Arrange
            Repositorios.ProdutoRepositorio repositorio = new Repositorios.ProdutoRepositorio(contexto);

            //Act
            List<Produto> produtos = repositorio.ObterProdutosAVenda();

            //Assert
            Assert.IsNotNull(produtos);
            Assert.AreEqual(2, produtos.Count);
        }
    }

Nesse caso estou testando uma rotina que utiliza o Entity Framework 4.1

Não vou entrar em detalhes técnicos da implementação, até porque a discussão sobre como e porque testar de determinadas maneiras com EF 4.1 é bem extensa. Só pra constar, essa implementação usa uma estrategia de inicialização própria e acaba sendo executada contra uma base de dados SQLCompact, por motivos específicos. Mas o código acima foi modificado para simplificar o entendimento do exemplo.

Inicializando os teste

Se você tem algum código, que precisa ser executado sempre antes de cada teste, então você pode fazer isso através de algum método com a notação TestInitialize()

Desta forma, sempre antes da execução de cada caso de teste será executado o metodo InicializacaoTestes() no exemplo acima.

Você pode optar também por inicializar um objeto que seja válido para todos os testes executados dentro dessa classe de testes. Para fazer isso, basta substituir o TestInitialize() pelo ClassInitialize()

Executando testes

Dentro do método de teste gosto de seguir algumas regrinhas, começando por colocar um nome compreensível na rotina de teste, definir e seguir uma convenção de nomes que será utilizada da mesma forma nas outras rotinas de teste.

Outro ponto é a separação do código de teste no famoso modelo mental AAA

Arrange – Act – Assert

ou

Preparar – Agir – Verificar

Organizando o código dessa forma fica mais fácil de identificar possíveis falhas e testes que estão abrangendo mais ações do que deveriam.

Finalizando os testes

A mesma logica que funciona para a inicialização de testes deve ser aplicada aqui também. O TestCleanup() cumpre a função de executar algum trecho de código após cada teste e o ClassCleanup() deve ser utilizado para executar rotinas depois da finalização de todos os testes dentro do contexto daquela classe.

Nada de complexo na estruturação dos testes, mas não utilizar esse ou algum outro modelo lógico de estruturação de testes facilita a ocorrência de erros, quando os testes começam a ficar complexos e o projeto vai crescendo. O texto é bem simples, mas é para não deixar passar batido alguns erros comuns que vejo em códigos por ai…

Você tem alguma opinião sobre isso? Concorda com a estrutura de testes? Deixe um comentário…

Exemplos de Poka-Yoke

Dispositivos a prova de erro previnem o usuário de fazer alguma ação que leve a um comportamento ou resultado não desejado. Como exemplo simples, podemos citar os aparelhos de processamento de alimentos que só “funcionam” quando o compartimento de alimentos está devidamente fechado. Isso evita que o consumidor ligue o processador acidentalmente enquanto está com a mão dentro do compartimento.

Temos muitos outros exemplos, como por exemplo a retirada da chave da ignição do carro com o mesmo em movimento.

Poka-Yoke em Software

Muita coisa já foi escrita sobre Poka-Yoke em desenvolvimento de software, principalmente por autores que trazem as abordagens de LEAN para o mundo da produção de software.

Todos entendem o conceito e conseguem aplicar em determinados níveis, mas parece que as pessoas negligenciam o fator que leva isso a ser importante. Não vou entrar aqui na história da Qualidade e falar da era das inspeções, controle estatístico, qualidade total e etc. Vou citar apenas uma frase que resume muito bem a falha que muitos cometem.

“Qualidade deve ser construída, não controlada!”

Em software vivemos na era da inspeção da qualidade. As pessoas querem controlar a qualidade, ao invés de estabelecer processos que garantam a qualidade desde o inicio. Dessa forma vamos viver eternamente correndo atrás de bugs.

Marry Poppendieck costuma dizer em seus livros que:

“Inspeção para encontrar defeitos é um desperdício. Inspeção para prevenir defeitos é essencial.”

Poka-Yoke no desenvolvimento

Podemos aplicar Poka-Yoke em diversos aspectos no desenvolvimento de software, mas vou fazer uma pergunta simples a você.

Porque você controla a qualidade através de inspeções e testes depois que o software/funcionalidade já está pronto?

Seguindo as referências que citei acima, o processo muito mais eficiente seria controlar a qualidade enquanto o software está sendo desenvolvido e não depois da funcionalidade pronta.

Podemos aplicar Poka-Yoke através de testes unitários e até através da arquitetura do software. O desenvolvimento guiado por testes é um forma de se aplicar Poka-Yoke e é muito fácil de se perceber isso, porque você está fazendo teste para garantir um processo com qualidade e não para testar a qualidade de um processo já pronto. A diferença é sutil mas muito importante.

Através da arquitetura também podemos aplicar Poka-Yoke, mas esse é um tema muito mais profundo, que merece um post só para essa discussão.

Concorda? Discorda? Deixe um comentário.

Recentemente tenho ouvido muita coisa que eu discordo a respeito de liderança. Na maioria das vezes essas afirmações vem de pessoas que possuem uma posição profissional superior a minha, por isso, em determinados momentos, fica difícil confrontar o conhecimento teórico com a experiência prática.  Nesses casos a prática tem a seu favor o resultado alcançado e comprovado.

Para ser Líder é preciso um cargo

Hoje as pessoas já conseguem ver a diferença entre liderança e autoridade com uma facilidade maior. Mas ainda existe muita gente que acha que a liderança só é exercida com um cargo. Isso é uma grande bobagem.

O cargo só irá conferir a autoridade necessária para determinadas ações, mas um líder de fato tem sua autoridade estabelecida de outra forma. Não vou entrar na discussão de tipos de liderança, mas só para exemplificar, você já deve ter se deparado no seu ambiente de trabalho com alguem que não tinha nenhum cargo de liderança, porém conseguia unir todo time em uma direção. Os fatores que levam a isso podem variar de conhecimento técnico superior aos demais, até carisma e poder de negociação elevados.

Para ser Líder é preciso ter carisma

Vejo muita gente se apegando a essa afirmação hoje em dia. Principalmente em tempos de Apple e Steve Jobs, todos acham que o modelo de sucesso é exatamente esse. O primeiro engano nessa afirmativa está implícito.  As pessoas acham que o carisma está diretamente ligado ao poder de convencimento e isso não é verdade. Poder de convencimento passa por diversos aspectos incluindo conhecimento, carisma e habilidades de negociação.

Liderança x Conteúdo

Isso é muito importante! Não existe liderança sem conteúdo.

Somente o carisma e habilidades interpessoais não irão criar um bom líder. Uma liderança dessa forma não se sustenta durante muito tempo. A mais de um ano, li um livro chamado “O andar do bêbado“. É um daqueles livros que muda suas perspectivas diante de vários acontecimentos rotineiros da vida.

Nesse caso o grande fator de mudança é um novo olhar sobre a matemática e a estatística. O livro vai de analises do mercado financeiro até Hollywood, passando pelos esportes. E ao final do livro eu garanto que você vai começar a olhar de forma diferente a aleatoriedade de fatos versus a real competência de determinadas pessoas.

O Líder nasce pronto

Essa é uma das besteiras que ouço com mais freqüência. Já ouvi, inclusive de selecionadores, esse tipo de coisa.

Ninguém nasce líder. A liderança vai ser formando aos poucos nas pessoas. Liderança é um processo de aprendizagem como qualquer outro, o que muda é que muitas coisas não podem ser aprendidas pela teoria, como relacionamento interpessoal.

Nós aprendemos a ser líderes com a nossa familia, com os nossos amigos e na nossa vida profissional. Tudo tem influencia, mas como já tinha dito no tópico anterior, é preciso conteúdo também.

Você realmente concorda que uma pessoa introvertida não possa exercer uma boa liderança? Eu poderia citar inúmeros casos de pessoas que não se enquadram no estereótipo de lider e que foram muito bem sucedidos em suas funções de liderança.

Existe um tipo ideal de liderança

Essa é outra grande mentira. Cada pessoa e cada situação exige uma abordagem diferente.

O importante é que o líder maximize seu estilo de liderança procurando tirar maior proveito de seus pontos fortes. Além disso, o contexto em que se está inserido pode exigir mais, de alguma habilidade especifica, e cabe ao líder notar isso e adequar seu estilo de liderança a situação.

O Líder forma seguidores

Em entrevista, o César Souza, uma vez disse que o verdadeiro Líder não forma seguidores, ele forma outros Líderes. Isso é a mais pura verdade, mas vamos além. Vamos a teoria da “explosão dos palhaços” do Guy Kawasaki.

Ele fala que o líder deve estar sempre cercado de pessoas mais inteligentes do que ele. “Contrate sempre pessoas A+”, é o que ele fala. Se você é uma pessoa nível “A” e começa a contratar pessoas nível “B”, essas pessoas nível “B” vão recrutar pessoas nível “C”, e um belo dia você vai acordar e vai se ver rodeado de pessoas nível “Z”.

Contrate talentos e forme talentos. Faça isso de forma que eles consigam fazer as coisas melhor do que você, esse é o grande legado que se pode deixar em qualquer lugar.

Todo esse texto foi baseado em experiências pessoais, mas o que me levou a escreve-lo de fato, foi uma entrevista do César Souza que eu vi na Globo News. Infelizmente não achei o link novamente para compartilhar, mas vou procurar. A cada tópico da entrevista eu sentia que todas as minhas indignações com relação a esses mitos faziam perfeito sentido.

Você concorda com isso tudo?

Ultimamente me deparei com muitas paginas e grupos de discussão que se apegam a conceitos e levam aquele conhecimento a ferro e fogo. Algumas dessas pessoas são fã boys e transformam aquele assunto em uma religião, outras tem interesses comerciais em defender determinadas posições e a grande maioria vai engrossar a voz da comunidade aplaudindo a metodologia ou tecnologia da vez.

A comunidade agil

De muito tempo para cá, tenho visto muitas dessas discussões envolvendo a comunidade agil. Me parece que as pessoas que compraram a idéia de agilidade querem mostrar ao mundo como isso é maravilhoso. O que eu não entendo é porque ao invés de amadurecer o modelo que essas pessoas tem em mãos, elas se preocupam muito mais em seguir regras e tentar estabelecer o que é agil e o que não é.

Arquitetura de software

A mesma preocupação existe no ramo de arquitetura de software. Os auto proclamados semi-deuses do desenvolvimento, aparecem com soluções já vistas antes em diversos outros cenários e sempre preocupados em criar uma soluções que atendam a todos os cenários possíveis, ao invés de atender com máxima eficiência o cenário existente no momento.

Essa discussão pode se estender a diversos outros exemplos e nesse ponto você pode não estar enxergando onde eu quero chegar com todo esse papo furado, então deixe-me explicar.

Não siga regras, estenda o modelo

Todos esses problemas ocorrem porque a grande maioria das pessoas estão no primeiro estagio do conhecimento. Elas simplesmente aprenderam uma maneira que funciona para elas, e estão replicando isso. São como potes vazios, que precisavam ser preenchidos pelo conhecimento.

O que temos hoje são pessoas que adquiriram esse conhecimento e hoje seguem suas regras. Essas pessoas são perigosas, tenha cuidado. Em certo momento, eu mesmo posso me tornar uma dessas pessoas, porque todos passamos por esse estágio do conhecimento.

São essas pessoas que vão te dizer que fazer as coisas de determinada maneira, não é ser agil. Ou aquelas outras que vão te dizer que pensar do jeito X ou do jeito Y viola o conceito Z e que isso não é mais admitido no mercado atual.

Eu estou propondo algo diferente. Estou propondo que vocês pensem em dar o próximo passo. Ao invés de ficar preso ao que pode e o que não pode, estendam o modelo atual para atender as necessidades de vocês.

Se você já possui o conhecimento e já consegue andar com as próprias pernas, então é hora de dar o próximo passo e quebrar as regras onde elas devem ser quebradas para gerar mais valor a sua proposta, seu modelo.

Na verdade não existem regras

Se você conseguir sair da primeira etapa para a segunda, meus parabéns! Quebre as regras com consciência e alcance os melhores resultados, continue estudando e continue avaliando os resultados. O engraçado é que quando se chega nesse estagio em algum conhecimento, você para de ver sentido em discussões do tipo “pode fazer isso”, “não pode fazer aquilo”. Discussões do tipo “isso não é o padrão XYZ” ou “Isso não é SCRUM”, passam a ser tediosas.

Obviamente que muita gente vai continuar a alimentar todo esse tipo de discussão, por diversos motivos, mas se você chegou nesse ponto, não engrosse a voz da comunidade debatendo sobre coisas sem sentido.

Depois de ainda mais tempo praticando, você vai descobrir que na verdade não existem regras.

Nunca existiram.

Só existiam nomes e conceitos, mas nenhuma regra.

É nessa hora que chega aquele momento mágico. Agora sim, você realmente consegue enxergar o sentido e a falta de sentido de tudo, e é nesse momento que surge a INOVAÇÃO!

Quando chega esse momento você está livre do que é certo e errado, você simplesmente tem um objetivo e sabe tudo que é preciso para alcança-lo. Só depende de você usar uma ferramenta que já existe ou criar uma ferramenta inteiramente nova!

Faça diferente e crie sua própria ferramenta para resolver os seus próprios problemas!

Será que isso acontece mesmo?

E nas empresas, será que é prudente deixar que isso aconteça? Você confiaria todo potencial de inovação de sua empresa a apenas uma pessoa?

Na minha opinião, esse estereótipo não deve existir em empresas. A inovação e criatividade é individual sim, mas pode e deve ser exercitada em grupo para chegar a resultados melhores. Somente em grupo podemos validar nossas idéias, termos opiniões para melhorar ou enxergar novos caminhos que não eram contemplados na idéia inicial. Por isso acredito que a inovação é uma atividade em grupo, mas esse grupo deve ser muito bem formado, por pessoas que queiram inovar, que queiram criar algo melhor!

Por acaso, hoje li um texto que falava mais ou menos a mesma coisa, na pagina da HSM e tinha o título de: Criatividade Produtiva

Baseado nesse texto, copiei 7 dicas para vocês e estou disseminando…

1 – Atitude: catalisadora de energia criativa e agregadora de habilidades e talentos. Ver-se como alguém criativo é passo importante para liberar a imaginação e aproveitar habilidades e conhecimentos.
2 – Desafiar suposições: temos crenças – e somos afetados pelas crenças de outras pessoas – que nos impedem de usar a imaginação e resolver os problemas criativamente. É importante identificar e listar as suposições, convenções e crenças que afetam a compreensão, análise e solução, e livrar das que não são verdadeiras ou que se tornaram obsoletas.
3 – Quebrar regras: na solução de problemas e na inovação é importante questionar as regras, especialmente quando elas aprisionam a mente a velhos hábitos e modos de pensar.
4 – Não ter medo de errar: grandes invenções raramente resultam de golpe da sorte, mas da sucessão de tentativas frustradas.
5 – Acreditar que há mais de uma solução certa: Na escola somos ensinados que há uma única solução certa. Na realidade, com muita frequência há mais do que uma e, muitas vezes, a primeira resposta que nos ocorre é a menos criativa. Esforce-se para procurar outras soluções de forma que você tenha várias opções para comparar e escolher a melhor.

6 – Suspenda o julgamento. O julgamento prematuro é o caminho certo para bloquear a criatividade. É essencial separar a fase de geração de ideias da fase de julgamento, pois não se pode dirigir com um pé no acelerador e outro no freio. No trabalho em equipe, deve-se ficar atento para os comportamentos que desencorajam as contribuições dos participantes, bloqueiam suas mentes e minam o espírito de equipe.
7 – Persistir: experimentar e ter alguns fracassos faz parte do processo de geração de ideias e inovação. O segredo do sucesso está na constância de propósito, em manter-se firme apesar dos percalços no caminho.

E você, o que acha disso? Deixe sua opinião sobre criatividade e inovação

Muito se fala hoje sobre Lean Startups e derivados que propõem, de certa forma, estratégias para desenvolvimento de produtos e ir para o mercado rapidamente.  Mas infelizmente tenho visto exemplos consecutivos de startups que se perdem no caminho, justamente por não ter uma estratégia traçada.

Começar é importante, mas igualmente importante é saber onde você quer chegar no futuro e traçar alternativas para fazer isso acontecer.

Algum autor certa vez citou uma frase parecida com essa:

Se você não sabe onde quer chegar, qualquer lugar servirá!

Essa frase tem uma certa beleza e é muito poética, mas na minha opinião, não se aplica ao cenário de empresas. Nesse contexto, se você não sabe onde quer chegar, significa que você provavelmente não chegará a lugar nenhum!

É muito normal você encontrar startups que aos poucos vão se afastando do seu objetivo primário, deixando de lado conceitos e idéias que levaram ao surgimento do negócio. Mudar é normal, e não tem problema nenhum se a mudança for parte de um plano estratégico de crescimento e melhoria, mas infelizmente essa não é a realidade.

As empresas vão mudando para atender a clientes com exigências chatas, para conseguir entrar em um novo mercado e entre outras coisas. Mas aos poucos elas vão se afastando da sua verdadeira essência, e aquele valor unico que  deu inicio a tudo, vai ficando para trás.

Dentro de pouco tempo a empresa está fazendo de tudo um pouco para atender aos seu clientes. Fazer tudo não é um problema, o problema é não fazer nada bem feito. Os pedidos dos clientes aos poucos vão sugando todo o tempo e aquela razão de ser da empresa vai começando a ter cada vez menos atenção e como conseqüência, nunca alcança o patamar que deveria.

Porque isso tudo acontece? Entre outras coisas, por falta de estratégia!

Eu sei que o cenário é difícil para uma empresa que está começando, existe a necessidade de faturamento, pressão de todos envolvidos no processo, que querem os primeiros resultados e por ai vai, mas na minha opinião, isso tudo não é motivo para deixar a estratégia de lado!

A estratégia contempla vários aspectos que vão te ajudar a planejar suas ações para atingir seus objetivos no futuro. Se pensarmos que somos startups, então podemos partir da premissa que hoje não temos nada, e amanhã queremos conquistar o mundo!

Para conquistar o mundo temos que pensar estratégicamente, analisando os riscos, oportunidades, forças, fraquezas, cenários entre outras coisas. Precisamos pensar quais serão nossos próximos passos para atingirmos nossos objetivos. Isso é estratégia!

A estratégia é um plano

É um plano para o futuro, uma direção que vai ser a base para a tomada de decisão quanto a suas ações. Suas ações devem convergir para a direção escolhida. É um caminho para levar a sua empresa de onde ela está hoje, até onde você quer que ela esteja no futuro.

Nem sempre os planos estabelecidos são cumpridos, mas precisamos estar em constante vigilância, analisando resultados  e fazendo adaptações necessárias para que nossos planos sigam o seu curso correto, ou até para detectarmos a necessidade de mudar o curso das coisas antecipadamente.

A estratégia é um padrão

 Nesse caso, veja padrão como um plano de coerência de suas ações ao longo do tempo. Se a sua startup é focada em produtos de alto valor agregado e se mantem assim ao longo do tempo, isso é um padrão que a sua empresa segue.

Mantenha consistência e coerência entre seu discurso e suas  ações e aos poucos vá criando seu padrão de atuação. Nesse ponto a angustia por resultados e a tentativa de atender diferentes clientes pode atrapalhar a sua empresa. Acho que as pessoas ainda tem grandes problemas com segmentar seus produtos.

A estratégia é uma posição

Estabelecer uma posição no mercado é o fator fundamental para sua estratégia. Mas não é só isso, a posição em si é a estratégia, pois define a empresa ou produto, fazendo com que as pessoas reconheçam a marca e possam diferencia-la das outras. A posição define o significado da sua empresa, então preste muita atenção nisso.

A estratégia é uma perspectiva

Se você segue um padrão e tem uma posição, provavelmente não terá problemas de ter uma perspectiva sobre as coisas. Crie uma perspectiva, uma maneira de olhar as coisas e use essa lente especial sempre. Olhe sempre os seus consumidores através dessa mesma lente quando for tomar decisões. Veja por essa lente também quando precisar tomar visões de negócio, para garantir que está indo sempre pela mesma direção, pois foi guiado sempre pela mesma forma de ver as coisas.

O estratagema

Essa é a manobra que você utilizará para botar em pratica a sua estratégia. As ações que vão derivar de todas as outras questões e que vão fazer você alcançar seu objetivo traçado anteriormente. Avaliar as ações são importantes para medir sua efetividade muda-las caso seja necessário.

Quando pensar em um produto ou serviço, pense estratégicamente, isso lhe dará vantagem frente aos competidores. Analise o cenário, olhe para todas essas questões e monte um plano para atingir seu objetivo no futuro.

Lembre-se, se você não sabe onde quer chegar, não chegará a lugar nenhum!

@{
  int x = 123;
  string y = "because.";
}

<%
  int x = 123;
  string y = "because.";
%>

<span>@model.Message</span>

<span><%: model.Message %></span>

<span>
@Html.Raw(model.Message)
</span>

<span><%= model.Message %></span>

@foreach(var item in items) {
  <span>@item.Prop</span>
}

<% foreach(var item in items) { %>
  <span><%: item.Prop %></span>
<% } %>

@if (foo) {
  <text>Plain Text</text>
}

<% if (foo) { %>
  Plain Text
<% } %>

@if (foo) {
  @:Plain Text is @bar
}

Hi philha@example.com

<span>ISBN@(isbnNumber)</span>

<span>In Razor, you use the
@@foo to display the value
of foo</span>

@*
This is a server side
multiline comment
*@

<%--
This is a server side
multiline comment
--%>

@(MyClass.MyMethod<AType>())

@{
  Func<dynamic, object> b =
   @<strong>@item</strong>;
}
@b("Bold this")

Hello @title. @name.

Hello <%: title %>. <%: name %>.

Peço desculpas pela falta de coloração de sintaxe, mas para que está querendo um guia de referência rápida para a Sintaxe Razor, já é de grande ajuda.