Para um projeto, todos na área de liderança sabem que é muito importar saber escutar e se comunicar, que cerca de 90% do trabalho de um gerente de projeto é comunicação. Com certeza isso não é mais novidade para a grande maioria das pessoas, portanto, o objetivo do post de hoje é mostrar uma importante descoberta para mim nesse último ano, que fez com que minha comunicação tenha melhorado muito, e que reflete o que sinto a respeito de saber se comunicar e da importância de saber ouvir na vida e no trabalho.
Até a algum tempo atrás as pessoas me falavam com frequência que não compreendiam o que eu falava, acredito que nada muito grave, assim como um joinvillense típico e sua mania de falar rápido. Percebi que isso começou a comprometer minha comunicação na empresa, foi quando me sugeriram que procurasse um fonoaudiólogo para entender o motivo. Foi isso que fiz, procurei um especialista e comecei a consultar uma fonoaudióloga. Foi então que percebi como realmente eu tinha problemas na dicção e como a hesitação, o tentar pensar e falar ao mesmo tempo, ferrava minha fluência.
Essa minha dificuldade me fez adquirir um importante e chato hábito: sempre que tentava me comunicar com qualquer pessoa, em reuniões principalmente, pedia feedback: “você entendeu o que eu quis dizer?” e aguardava um sim bem convincente para continuar a conversa. Percebi, portanto, que muitas pessoas mesmo respondendo que sim, não entendiam nada, ou entendia pouco, ou até mesmo entendiam outra coisa totalmente diferente do que queria dizer. Foi ai que, ainda inseguro, junto com o “você entendeu o que eu quis dizer?” emendava “o que você acha disso” ou “o que você entendeu? pode me falar?”. Dessa forma, eu tinha certeza de que a pessoa realmente entendeu.
Com o tempo conseguia saber quem entendia de verdade e quem não entendia o que eu queria dizer, e comecei a perceber que as pessoas que não entendiam e as que entendiam da primeira vez que eu falava eram sempre as mesmas pessoas. Percebi também que ser um bom ouvinte refletia diretamente no trabalho dessas pessoas. Ou seja, os que entendiam com muita facilidade, eram aqueles que trabalham em projetos em que a equipe estava em total sintonia, onde cada um sabe o que deve fazer durante a semana. E que frequentemente as pessoas que não entendiam, eram os que tinham problema nas entregas e no que deveria fazer durante a semana.
Estou procurando entender agora como ser um bom ouvinte, ainda não descobri uma fórmula mágica, mas tenho certeza que essa formula passa pelo respeito ao seu interlocutor, e também por técnicas de relaxamento, concentração, meditação e respiração. Acredito também, que, você deve estar efetivamente presente no momento da conversa, não pensar nos problemas que estava resolvendo anteriormente e nem nos problemas que você vai resolver futuramente, e prestar atenção apenas no que você está ouvindo.
Hoje, entender essas coisas, acabou moldando a forma de me comunicar com cada uma das pessoas que me relaciono. E na empresa, durante as reuniões semanais (reunião de Sprint) procuro entender primeiramente, qual o nível de recepção do meu ouvinte. Em alguns momentos, ainda preciso pedir feedbacks mais frequentes, até ficar claro. Mas também há momentos em que apenas um olhar já basta para ficar claro que estamos alinhados.
Vídeo demonstra de forma resumida os processos da metodologia de desenvolvimento de software na Informant.
Ele foi produzido pelo Prof. Luiz Camargo para ser utilizado como material da disciplina de Gestão de Projetos em cursos da Sociedade Educacional de Santa Catarina – Sociesc.
Os livros sobre desenvolvimento Ágil sempre citam a teorias das restrições, onde é falado que devemos encontrar dentro do projeto a restrição que afeta o seu desempenho, a atividade que limite a velocidade do projeto. Alguns falam que o papel do programador na sua atividade de codificar é, dentro da maioria dos projetos de software, a restrição do projeto, ou seja, o Bottleneck.
Acredito que realmente o programador seja a restrição, vimos isto em todos os projetos da Informant. O que quero dizer é que o trabalho de programar é muito importante, tudo o que o programador fizer que não seja codificar, estamos limitando a velocidade do projeto. A codificação tem a sua velocidade, e deve ser respeitada. As demais atividades do projeto devem estar voltadas para esse momento. Sabendo disso temos que maximizar o tempo por dia de programação, e respeitar muito este momento. Algumas práticas que temos adotado para isto:
Quando precisar conversar com um programador, e ele estiver programando, pense sempre ”será que preciso realmente falar com ele, não posso esperar um pouco”
Quando passar uma responsabilidade para um programador pense se você mesmo não pode fazer isso.
Racionalize as reuniões que envolvem o programador. Traga ele somente no momento que for necessário, estimar tarefas.
Gerente de projeto/produto, será que o que vocês pedem para o programador fazer não é mais burocracia do que realmente necessário (apontamentos de horas, Destelhamento de tarefas, contato com cliente)
Quando você como programador, estiver tentando resolver um problema a mais de 2 horas e não consegue encontrar a solução, peça ajuda, não fique mais do que 4 horas no mesmo problema, você está travando o projeto.
Você como gerente de produto, deve estar com os cenários (atividades) detalhados e priorizados na reunião de sprint. Para poder sanar todas as perguntas dos programadores no momento que forem feitas.
Você como programador, deve seguir a prática de trabalho energizado, e controlar quanto tempo consegue ficar programando sem interrupção, de e-mail, mensagem. Feche essas interrupções no momento da codificação.
Você como programador, deve automatizar tudo que não for programação. Investir em colocar em prática todos os conceitos da integração contínua.
Todas essas dicas vão permitir melhorar a qualidade do código, pois permitirão o programador se concentrar melhor nas suas atribuições:
A programação em par
TDD
Os testes de Integração
As folgas semanais
As atividades de lazer da equipe, o café e as bolachas.
Faz tempo que pretendo escrever sobre como foi a viagem a Alemanha com o grupo de empresários joinvillenses. A viagem foi muito interessante e inesquecível por vários motivos: foi minha primeira viagem internacional, a CEBIT, a visita à SAP, os amigos feitos, a cultura do povo, a história de Berlin . O motivo deste post é antes de tudo uma homenagem aos colegas da viagem, e uma forma de registrar definitivamente, de nunca esquecer.
A Chegada em Hannover
Saímos de Joinville cedo, fomos de Ônibus até o Aeroporto de Curitiba pegar o avião até São Paulo, foi o momento para nos apresentar e começar a nos conhecer, fomos em 16 empresários, todos de empresas de Joinville: Artur(Feeling), Dionei (Gate),Henke (GranSystem), Maurício “Parceiro”(GTI) , Moacir (Impulso), Vilmar Flamenguista (Micromed), Fernando Fix (Grupo Organo), Sardagna EU(Informant), Edcel (Setrion), Egídio (Setti),Claudio(Euax e “armador dos bons do Jec”), Edésio (Macedon), Francisco (Sofdata), Roberto (Softin), Fábio (Softran), Romulo (Controller) e nosso lider e guia Donizette (Sebrae) .
Antes da partida, Fizemos um lanche em são paulo, fora a quantidade de pessoas do lugar o que mais marcou nesse momento foi um comentário muito bom do Fix, dizendo que se Joinville um dia tiver um aeroporto daquele tamanho e com aquela quantidade de pessoas, nós (as empresas de Joinville) estariam muito bem servidas, ou seja temos muito espaço para crescer.
Pegamos o avião para Alemanha, Munique, já fomos recebido na porta do avião pela tripulação falando em alemão, serviram bebidas (cerveja, vinho) e lanches, foram 12 horas de vôo cruzando o oceano, passando por cima do deserto do Saara, Mar Mediterrâneo, Itália, Alpes Suíços, assisti muitos filmes, um que me chamou a atenção foi o filme A invenção da Mentira, filme é um conto de um mundo onde as pessoas só falavam a verdade, e consequentemente eram muito sinceras, parecia que o filme já previa como seria os próximos dias convivendo com a cultura dos Alemães. Aterrissamos as 5:00 da manha em Munique, aeroporto enorme, com calefação, mas já fiz o desafio de dar uma volta pela rua de 1 minuto e voltar só para sentir o ar gelado próximo de 0 graus. Lá o pessoal já começou a atacar o duty free: Ray Ban, Mont Blank e Rolex.
Pegamos um novo voo com destino a Hannover, viajem curta e foi muito legal ver Alemanha do alto, o que víamos era um pais com várias vilas, rodeadas de campos de plantações gigantes, não sendo atoa que um dos pontos fortes da Alemanha era a agricultura. Chegando a Hannover fomos muito bem recebidos por nossas fantásticas guias, a Regina e sua filha Stefanie. Que já forma nos apresentando Hannover, um pouco do aspecto político e cultural, até nossa chegada ao Hotel.
Na chegada ao hotel, todos foram descansar, quer dizer quase todos, a adrenalina de chegar em um pais novo, e a vontade de conhecer, e até a fome, não deixou Eu, Fix, Roberto, Cláudio e Dionei descansar. Fomos passear pela região, estávamos do lado do centro, andamos em algumas lojas e acabamos comendo uns lanches na lanchonete que seria o local que todos paravam para comer nos próximos dias. Voltamos ao hotel, e esperamos o grupo se reunir quando foi feito um novo passeio agora com todos, passamos pela Prefeitura velha, cidade velha, igrejas, foi muito legal. O pessoal aproveitou para fazer umas compras e acabamos nos reunindo para jantar em um restaurante argentino, neste momento todos já estavam enturmados e preparados para o próximo dia o embarque para conhecer a SAP. Claro que após voltarmos fomos ao bar do hotel, um cantinho que ficava do lado da recepção, Dionei ,Eu, Fix e Fábio brindamos um(dois, três como dizia Dionei) chopes, e assim acabou o primeiro dia.
A Visita na SAP
O dia começou cedo, muito cedo mesmo, cerca das 5 da manhã, quando fui atualizar os e-mails e ligar para a Esposa. Dia de pegar o trem cruzar parte do pais para conhecer a gigantesca SAP. As 6:30 foi servido o café da manhã, muito bom por sinal, entendi por que os americanos adoram ovos com bacon no café, pois realmente são muito bons. Pegamos o trem no horário marcado, alguns perderam e acabaram não partindo junto com o grupo. O trem para Waldorf era muito rápido, cerca de 250 km/h, muito legal. Chegamos na SAP, lugar incomum, a cede da empresa era uma cidade, com vários prédios, não dava para entender o tamanho do lugar.
Entramos em um dos prédios fomos recepcionados e levados a uma sala de café, lugar muito bonito e aconchegante de dar inveja as salas de café de nossas empresas, depois fomos encaminhado para a sala da apresentação, onde o Sr. Mathias Green começou a apresentação. Durante a apresentação foi trazido um lanche, pois ocorreu durante o almoço, a apresentação foi em alemão com a tradução em português, é claro, alguns pontos da apresentação que me chamaram a atenção:
Durante a apresentação ficou claro que a SAP se posiciona como uma empresa que promove a sustentabilidade de seus clientes, e fez muito sentido, pois ela está implantando nas maiores empresas do mundo, otimizando processos, diminuindo as redundâncias de informações, e substituindo processos manuais, ficou muito evidente o apego ao Green it. Esta sustentabilidade começa na maneira que os próprios prédios da SAP são construídos, sendo chamados de prédios inteligentes e ecologicamente corretos.
Demonstrou também que os principais concorrentes da SAP neste momento é a Dinamics da Microsoft e o ERP da Oracle, que são muito forte em toda a EUROPA.
A SAP também tem uma politica de recursos humanos muito audaciosa, onde promove o rodízios de funções, horários flexíveis, premiações e muita satisfação dos funcionários. Da para ver pelos corredores o modo que ela trata os funcionários, através de refeitórios e lanchonetes muito criativas demonstrando a valorização que se dá aos seus colaboradores.
Após a apresentação fomos conhecer os corredores dos prédios, onde realmente existia pessoas trabalhando, o que chamou atenção foi o tamanho do restaurante, onde consegui imaginar tão grande a SAP era. Foi uma visita muito produtiva, e especial, muito boa sacada quem sugeriu esta visita, valeu muito a pena.
A ceBIT 2010.
O ponto alto da viagem foram com certeza as visitas a feira, o combinado era a divisão em vários grupos de pessoas com uma interprete.
Estande Amazon
Porém quando cheguei dei de cara com o estande da Amazon, focando quase que exclusivamente seus serviços Web Services, e naquele momento estava para começar uma palestra sobre o EC2, pronto, já fiquei e assisti, nesse momento já me perdi do grupo e tive que seguir a viajem sozinho. Veja o vídeo da palestra.
Brasil na ceBIT
Após sair da Amazon fui caminhando e conheci a área destinada aos estandes dos países, entre eles o Brasil, o estande de software estava bem decorado, contou com poucas empresas a maioria delas eram do Rio Grande do Sul na área de inovação. Ao todo foram 18 empresas de software, estas empresas foram patrocinadas com louvor pelas entidades Softex, Apex, Softsul, Anprotec, digo isso pois foi, segundo o Terra, a maior participação do pais na feira. Outra participação do Brasil foi na parceria de criação de software que existe entre o brasil e a Alemanha “German – Brazilian Year of Science”, onde nos foi apresentado como seria a parceria de entre 2010 e 2011.
Por enquanto é isso. Nos próximos posts falarei mais sobre a ceBIT e nossa viagem a Berlin.
Na primeira semana do inverno de 2007 o analista de sistema João Pedro da distribuidora Santo Grau está precisando resolver um problema no módulo de controle de estoque do ERP da empresa. Todos os dias aparecem novos produtos na tela de Quebras de Estoque (tela que apresenta produtos com quantidade maior do que existe no estoque físico), algum problema ocorre no sistema que acaba alimentando quantidades erroneamente. Após três semanas tentando achar o motivo ele desiste de procurar, e para resolver, acaba criando um roteiro para corrigir a tela e mostrar somente as quebras geradas corretamente pelo usuário do estoque. A partir dai tudo está funcionando perfeitamente como deveria, até que um dia o analista deixa o módulo de faturamento e passa a cuidar do financeiro. Nesse momento ele precisa passar “seus conhecimentos” para outro analista junior que assume seu novo papel de analista de faturamento, e para que a tela de quebra de produtos continue funcionando perfeitamente o antigo analista cria um script em papel que descreve os 5 passos a serem seguidos para resolver o problema na tela de Quebra. A partir dai o analista novo fica 3 anos executando o script, passo a passo todos os dias. Ele ajeita sua rotina para este trabalho: na parte da manha faz passo a passo o script e vai tomar café, depois volta e… Bom dai continua fazendo suas tarefas de análise de sistema.
Este exemplo de seguir um script, é muito comum acontecer, já aconteceu comigo algumas vezes. Veja, não estou falando apenas de scripts de rotinas de banco de dados e programas de correção que devem ser rodados periodicamente. Poder ser esses tipos de scripts, como também pode ser um processo de software engessado que deve ser seguido por todos, ou um projeto legado que assumimos e continuamos a seguir o mesmo modelo de código, arquitetura e correção de bugs. Enfim seguir scripts são todas as tarefas que assumimos em uma nova função, não são scripts de código “bat” nem “javascript” , mas no sentido de roteiro, na qual executamos uma narrativa mastigada passada por um roteirista.
É muito cômodo seguirmos script, você pode ficar anos executando o mesmo script, quando questionado o por que de você fazer assim a resposta é muitas vezes a mesma, “porque me mandaram fazer assim”, “porque o cliente quer assim”, “porque é meu trabalho”, “porque é importante para o funcionamento do sistema”, “porque sempre fiz assim e sei que funciona”, porque estou na minha zona de conforto.. (bom, esse último motivo ninguém fala).
Estive pensando, por que os roteiristas costumam nos passar um script, a resposta que conseguir chegar são três:
Manter o sincronismo do sistema social, dos processos, se cada um seguir seus scripts a peça fica completa e todos vão ter um grande espetáculo, ou um grande projeto, ou uma grande satisfação do cliente.
Outro motivo é que foi constatado através de muita repetição e estudos, que esse script ou rotinas ou processos são as melhores práticas para serem seguidos, que o espetáculo vai ser um sucesso, e isso garante um padrão a ser seguido e controlado.
E o último motivo, e o mais perigoso claro, é que esse roteiro foi criado para você, por que simplesmente o roteirista não confia em você, ele tem medo de que você não seja capaz de fazer o melhor, ele fez sempre assim e foi a maneira que ele pode fazer, não a melhor, mas sim uma maneira que ele ajeitou as coisas, e acredita que se continuar assim as coisas continuaram funcionando.
E ai, será que os scripts que estamos executando, estamos fazendo por qual motivo? Será que foi nos dados para garantir o funcionamento de tudo, por que não confiam o suficiente que podemos fazer melhor?
A resposta encontrei há algum tempo no livro do Ricardo Semler: ”ferramenta dos três por ques” e recentemente lendo um dos princípios do XP: “a coragem”.
No livro Você está louco, Semler convida a nos fazer a seguinte pergunta: “Por que fazer desta forma?” para tudo que fazemos. Isso o levou a seguir uma nova forma de administrar sua vida, mudou a maneira de administrar a sua empresa, de encarar os problemas de maneira muito mais lúcida, quebrou regras e práticas que estavam enraizadas no meio empresarial e educacional.
Quanto ao princípio da coragem, ela nos indica que não podemos ter medo de fazer acontecer, de assumirmos responsabilidades e fazer diferente, de errar e tentar novamente. Temos que ter coragem de fazer tudo de novo, assumir os riscos, rasgar os scripts e aprender com os mais novos: ”Deixa comigo, confie em mim que sei como fazer”.
Dentro da metodologia de desenvolvimento da Informant existe a prática “Zero Bugs”, corrigir os bugs no momento que aparecem. Além de nossas lições aprendidas constatar que é uma pratica importante, ela também faz parte das práticas do XP e está bem fundamentada no livro “arte do desenvolvimento ágil”
Parece óbvio que não pode existir bugs no código, mas saber da existência deles e não corrigir custa caro, ai vai alguns motivos:
Ele pode se transformar maior com o tempo, pois várias modificações no código vão deixando o bug difícil de ser corrigido;
Exige esforço e pode abalar muito um projeto, um cliente insatisfeito por algo que ninguém corrigiu;
Desperdício de tempo que temos que gastar para ter que explicar para todos que “já sabemos que existe e está no nosso Product Backlog para corrigi-lo”;
Aqui vai umas dicas para evitar o acúmulo de bugs
Prefira sempre falar “Temos uma nova funcionalidade para desenvolver, porém vai atrasar por que estamos matando alguns bugs acumulados neste sprint”, ou seja, prefira corrigir bug a construir funcionalidade nova;
Não crie listas de bugs conhecidos, aproveitem projetos novos para não deixar que essas listas existam;
Priorize os bugs os que estão incomodando o cliente não os que estão incomodando você;
Priorize bugs que maximizem o valor entregue para o cliente e que exigem menos esforços;
E o mais importante: só faça entrega de funcionalidades que não exista nenhum bug conhecido. Não de acesso a funcionalidades (botões, telas, links, processo) em que exista bugs conhecidos, elimine-os antes.
O termo Sabotagem surgiu quando funcionários descontentes das fábricas jogavam seus tamancos “sabot” dentro das máquinas para causar estragos, faziam isso como forma de protesto pelos maus tratos, baixos salários e trabalho digno.
Sinto que hoje sabotagem pode ocorrer de maneira muito mais sutil e frequente dentro das softhouses, porém acredito que esses tem uma causa um pouco menos válida do que antigamente, acredito que o motivo de hoje tem muito mais haver com o “ego de programador” e de “chefes-mal-acabados” do que por luta por melhores salários.
Você já se pegou pensando em ir mais devagar com a codificação só para mostrar para o “Chefe Encrenca” que não gostou da crítica que recebeu dele? “Não vou utilizar o TDD por que todo mundo fala e você não é fâ de modismo”, ou por que fazendo isso você vai ceder para seu chefe, vai dar razão para ele . Tem o famoso “já que você não aceito a minha sugestão, vou programar da minha forma e você programa da sua”.
Essas micro sabotagens que ocorrem com muita freqüência, acabam sempre sendo ruim para a empresa, cliente e programadores. Mas de quem é a culpa? a culpa é da imaturidade. Tanto dos programadores por muitas vezes não serem maduros o suficiente e não aprenderam a se desprender de seu ego, e culpa também do chefe que não sabe ser chefe e conquistar as pessoas, esbarrando também em seus egos. Acredito que o sucesso de um projeto tem muito mais haver de “como estão fazendo” do que de “o que estão fazendo”. Um projeto com uma equipe unida, e todos estarem fazendo seu trabalho com gosto, tem muito mais chance de dar certo, do que por exemplo a metodologia de desenvolvimento que estão seguindo.
Para ter uma equipe unida, sem sabotagem, dependerá de programadores e chefes maduros. Pense se você como programador não esta sabotando seu projeto? E você como lider está realmente conseguindo com que sua equipe seja unida? A humildade é um dos ingredientes chaves nesta resposta, alguém terá que ceder, e se todos cederem sempre, todos os dias, vão naturalmente amadurecendo. Um exemplo legal que ocorre dentro da Informant é o “o que espero de você” onde um dos pontos positivos é aprender a ser mais humilde e reconhecer os erros perpetuar os acertos cometidos.
Quer ser um excelente programador? você se tornará um muito mais rápido, se amar a matemática.
Mas antes de falar de matemática vamos falar de programação, não sei se você já reparou, mas sempre antes de tentar resolver um problema complexo de programação (uma tela complicada, um processo com várias regras) seguimos um algoritmo para resolver mais ou menos assim:
Vou procurar na internet para ver se já tem alguma coisa pronta que possa me ajudar a resolver isso, se não tiver pulo para a linha 3
Implemento o que encontrei na internet, pulo para a linha 6
Vou falar com os gurus da empresa para ver se eles tem alguma solução para meu problema, se não tiver vou para a linha 5
Implemento o que os gurus me sugeriram (normalmente copiar o código de algum lugar que já foi implementado) e pulo para a linha 6
Vou tentar me virar sozinho faço algumas provas de conceitos até chegar a solução ideal e começo a escrever os testes, (isso se usar o TDD) Nesse ponto você entra em outro script, que é o TDD.
Rodo vejo como ficou, se não ficou bom volto para a linha 1.
É quando você está na linha 5 que você vai começar a utilizar a abstração, e é esse momento que você realmente estará programando de verdade, criando algo novo que vai servir para quem tiver o mesmo problema que você, você estará praticando a arte da programação. A abstração, é ela que diferencia um guru programador de um iniciante, é ela que garante que você pode aprender qualquer linguagem de programação muito rápido e se tornar fera nela. É aquela fato, ler um livro de linguagem de programação não garante que você vai sair programando bem.A experiência em programação vai te ajudar muito, principalmente na execução do algoritmo acima e vai te deixar muito rápido nas suas codificações, mas somente se você tiver a capacidade de abstração muito estimulada vai conseguir executar a linha 5 do script de maneira bela, precisa e naturalmente.
Mas qual a relação entre abstração e a arte de programar bem?
Primeiro que antes de escrever a primeira linha de código em uma linguagem de alto nível tipo o java muita coisa já foi abstraida: gerenciamento da memória, muito código nativo, o sistema operacional , etc. Depois você tem que conseguir abstrair o problema todo, quebrando ele em pedacinhos de código que você vai escrever, nesse caso você tem que responder: ”eu não sei tudo o que eu tenho que fazer para resolver esse problema, mas tenho certeza que isso vai ter que ter no código”, implemente o que você tem certeza que deve fazer e repita a pergunta “pronto, fiz isso, ainda não está pronto mais sei que isso também é obrigatório ter no código” e depois vai repetindo esse pensamento até finalizar o problema. Quebre o todo em partes pequenas de cada vez e concentre-se nelas, é uma maneira simples de explicar abstração aplicada na programação. É fácil observar pessoas que não tem o capacidade da abstração muito bem estimulada, pois quando pegam um problema muito grande para resolver travam, não sabe por onde começar..
Agora.. o que isso tem haver com a matemática? Preste atenção na forma que codificamos a solução de um problema grande da computação, essa visão de abstrair não é o MESMO processo que você usa para resolver uma problema de algebra das aulas de matemática? primeiro resolver as multiplicações, depois tirar o mínimo múltiplo comum, depois resolver as divisões,depois as somas, e assim vai…. É verdade, aquelas aulas chatas que você achava que não serviam para nada, porque “existia a calculadora” na verdade estavam preparando você para poder ser um sujeito mais organizado, racional, e melhorando a capacidade inata do ser humano de abstrair as coisas que não são importantes. Não é por acaso que os cursos de ciência da computação tem muita matemática em sua grade curricular.
A programação é um simples exemplo onde usamos muito a matemática, mas se você reparar também usamos muito em nosso dia a dia, se você não esta conseguindo organizar bem o seu dia, pode ser que falte você abstrair o que não é importante, um exemplo que tive que utilizar matemática foi montar o berço da minha filhinha, onde a solução é o berço montando, mas para começar a montar tive que ir montando as poucos, muito parecido com um problema simple de soma na matemática (parte da frente + parte de tras)…
Montei o berço da minha filhinha utilizando minha capacidade de abstrair
Cubo mágico
Existem algoritmos mais complicados, um exemplo é o cubo mágico, esse sim é um problema complexo de resolver, só um conselho tente resolver ele sem procurar por algoritmos prontos utilizando apenas a sua capacidade de abstração, que é a unica habilidade necessária para resolve-lo ; – )
O universo da informação está sempre se renovando, a web se ronovou nos últimos anos, gurus e universitários, agora bilionários, deixaram ela mais interativa, mais dinâmica, fazendo com que estejamos mais conectados, informados e ligados. Lembram de como era a 10 anos atras?
As empresas que desenvolvem software for business estão correndo atrás, pois não podem mais obrigar seus clientes a usarem sistemas confusos, travados, caros e defasados. E por outro lado, por não terem alternativas, as empresa que compram esses software, não podem mais obrigar os seus colaboradores aprende-lo e a usa-lo, gastando milhares de reais em custos de infra estrutura, treinamento e suporte, e ainda por cima seus funcionários desmotivados em trabalhar em um ambiente de software que não lhes agrada.
Um Sotware de gestão deve estar em sintonia com as mudanças, deve ser prazeroso usá-lo, deve estar a altura das soluções mais fántasticas e colaborativa que existem na internet: orkut, youtube, google, gmail; pois na verdade, o sistema de uma empresa, compete a atenção de seus colaboradores, com essas páginas. Um software para a sua empresa, deve ser MAIS… mais interativo que um orkut, mais customizável que um msn, mais eficiente que o excel, e até que mais que um email. Deve atender especificamente o problema do seu negócio, não amarra a empresa a solução proposta pelo software comprado. Deve informar todos os problemas que podem acontecer, não ter funcionalidades a mais que nunca vão ser usadas, ser simples, barato e nunca ser arriscado financeiramente, do tamanho do seu negócio e do seu bolso.
Não adianta tentar customizar os seus sistemas para essa tendencia, as mudanças são caras e muitas vezes inviáveis, pois demanda toda uma equipe nova para refaze-lo, e ainda conta com funcinários antigos que são muito resistentes a mudanças. E o produto final acaba sendo um filhote feinho do sistema original, apresentando os mesmo problemas que antigamente. Empresas novas também tentam seguir essa tendência, mas acabam esbarrando com funcionários desanimados, inexperientes e defasados tecnologicamente.
A empresa de software ideal está atenta a isso, e sabe que fazer sistemas com essa qualidade exigida, é difícil, exige pessoas experientes, desenvolvedores, designers, arquitetos abertos a essa nova realidades, fazendo o que gostam e com vontade, a mesma vontade que os construtores da web 2.0 tiveram, pois eles mesmo são esses construtores. Pessoas ligadas a todos os novos conceitos de interatividade, informação na hora certa, conceitos de negócios a nível operacional e gerencial, tendo a inteligência de fazer aquilo que o cliente quer, que o cliente precisa, da melhor forma possível sem mais nem menos.
