Arquivo da categoria: Sistemas

Matem o formato CSV

Se você trabalha com dados já deve ter usado um arquvo CSV. Quase todo programa tem alguma forma de importar ou exportar dados nesse formato, quase como se fosse um padrão.

O arquivo CSV é só um arquivo de texto, em que cada linha contém dados de um registro e cada campo de um registro em uma linha é separado por um caracter separador.

"Nome","Instrumento"
"John Lennon","Guitarra"
"Paul McCartney","Baixo"
"Ringo Stars","Bateria"
"George Harrison","Guitarra"

O formato tem muitas vantagens que o tornaram popular desde os primeiros softwares de planilha eletrônica. É tão simples que um ser humano consegue ler e escrever um CSV usando um editor de texto simples. É fácil de implementar e por isso todo sistema tem alguma forma de importar e exportar dados nesse formato.

Mas é um formato que fazia mais sentido quando não existiam redes e por isso não se trocavam tantos arquivos entre computadores diferentes, sistemas operacionais diferentes e softwares diferentes com configurações regionais diferentes. O arquivo CSV di jeito que existe hoje devia morrer de velho ou ser sacrificado, se isso fosse possível.

O maior problema do formato CSV é a forma como ele lida com encodings. Ele não lida. O programa que lê o arquivo precisa adivinhar o encoding em que os dados foram gravados e às vezes não acertam.

Isso significa que às vezes você vai mandar um arquivo CSV para alguém, ele vai tentar abrir no programa dele e todos os caracteres com acento vão virar um monte de lixo. Ele vai dizer que a culpa é sua de mandar um arquivo corrompido.

Alguns softwares vão abrir em um encoding padrão e se seus dados ficarem todos enfeitados com caracteres ilegíveis, problema seu. Quem mandou você não converter o encoding do arquivo para o encoding usado pelo software. Mas como você ia adivinhar que encoding é esse, se  isso não for uma configuração explícita.

Outro problema é que o caracter usado para separar os dados de registro não precisa ser uma vírgula, como o nome do formato implica (CSV = comma separated values = valores separados por vírgula). Aqui no Brasil mesmo, muitos programas usam o ponto-e-vírgula ao invés da vírgula como padrão.

Mas não existe uma forma de indicar no conteúdo do arquivo qual caracter está sendo usado como separador. Você simplesmente usa o separador que escolher e se ele não for o padrão, na hora de abrir o arquivo em algum programa, reza para que exista alguma forma de escolher qual caracter você usou como separador. Senão vai ter que arrumar uma forma de mudar os separadores do arquivo.

No caso do Windows, o separador padrão para um arquivo CSV é uma configuração regional do sistema. Se se seu amigo canadense te envia um arquivo que ele gerou no Windows dele e tem vírgulas como separadores, talvez você vai ter um trabalho extra para abrir o arquivo em seu sistema operacional com configurações regionais do Brasil e ponto-e-vírgula como separador. E nem todo software vai usar a configuração do sistema.

Você pode ter lido isso tudo e achado que é um problema bobo, fácil de resolver. Basta que a pessoa que vai abrir o arquivo fique responsável por configurar o software que vai abrir o arquivo com o encoding correto e o separador utilizado. Mas essa solução só mostra como esse formato tem um problema grave de usabilidade. Você nunca precisa checar o conteúdo bruto e configurar um software antes de abrir um XML ou um DOC. Esses passos adicionais tomam tempo e aumentam as chances de erro e corrupção de dados.

O software poderia ser responsável por tentar detectar o encoding e o separador. Mas detecção de encoding pode falhar. Detecção do separador também. O que pode gerar corrupção de dados sem que o usuário perceba.

Esses problemas poderiam ser evitados se o formato tivesse sido formalmente padronizado décadas atrás. Existe um documento  que define que o separador deveria ser sempre a vírgula, mas como sabemos isso já não é obedecido. Além disso o documento não se preocupa com o problema de encoding. Mesmo que se preocupasse, já existem tanto software que geram arquivos CSV no formato livre atual, que para fazer alguma diferença, um padrão deveria ter um novo nome e de alguma forma ser adotado em massa pela indústria.

Por conta da longevidade e abrangência da adoção do formato CSV, nós somos reféns dos problemas desses arquivos, obrigados a implementar sistemas que continuem processando esse formato só porque outros sistemas se sentiram na obrigação de dar suporte a CSV, como num círculo vicioso.

Equipes de tecnologia odeiam gerentes não técnicos

Ao conhecer uma pessoa, o profissional de tecnologia começa a classificar: esse pessoa é técnica ou não? Ela já teve que configurar um banco de dados ou uma fila de mensageria? Ela sabe como usar criptografia? Ela consegue entender a arquitetura de um sistema olhando para um diagrama? O quanto ela entende de tecnologia?

Isso não acontece porque técnicos se consideram uma casta diferente que só se relaciona com pessoas da mesma turma. O problema todo se resume à comunicação. Se você precisa explicar algo para uma pessoa que também é técnica, pode levar em conta que ela já sabe conhece algumas informações básicas, e isso torna a explicação mais fácil. E isso torna o trabalho do técnico mais fácil.

Outro problema são as expectativas mágicas que os leigos têm em relação aos técnicos. Por não saber como as coisas funcionam, tentam imaginar como devem funcionar. Por isso na hora de explicar um problema técnico que está tendo, pessoas não técnicas tentam explicar de uma forma que talvez não vá fazer muito sentido para o técnico. Pode ser uma reclamação de que um documento importante sumiu, fazendo o pessoal do CPD perder tempo recuperando o arquivo do backup quando na verdade a janela do Word estava só minimizada.

Por isso, uma situação que cria muita insatisfação é quando o gerente de uma equipe de tecnologia não é uma pessoa com perfil técnico. Normalmente alguém que está no cargo porque tem experiência em gerir pessoas, projetos, clientes. E para muitas empresas, essa estratégia parece natural, já que funciona com outras áreas da empresa, em que os especialistas são os membros da equipe e o gestor só coordena e cobra. Por que a equipe de TI seria especial?

O problema de comunicação entre técnicos e não-técnicos afeta o dia a dia da relação com o gerente. O gerente da equipe é uma das pessoas com que o profissiona de tecnologia mais vai ter que interagir. Se ele não for técnico, você tem esse desgaste a mais de energia tentando explicar conceitos básicos, preparando uma aula só para passar um status do andamento de um projeto.

Dependendo do gerente, suas expectativas mágicas podem causar muito stress para a equipe, principalmente quando ele é responsável por estabelecer os prazos. Para o gerente não-técnico, uma mudança no sistema pode parecer trivial, algo que vai tomar algumas horas. Mas olhando com mais cuidado, um técnico pode detectar que isso vai exigir mudanças grandes que podem tomar meses. E se o gerente não tiver como renegociar esse prazo (ou simplesmente quiser mostrar serviço para seus superiores), a equipe é quem paga o pato de trabalhar fora do horário de serviço para entregar o que foi pedido.

Nem toda empresa pode ou consegue achar alguém com o perfil de gerente técnico. É possível fazer uma equipe técnica e um gerente não-técnico funcionarem juntos, mas é mais difícil. Esse gestor precisa ter humildade e facilidade para aprender um pouco sobre a tecnologia usada por sua equipe, não necessariamente entendendo os detalhes de quem bota a mão na massa, mas o suficiente para entender uma conversa sobre o assunto. Também é importante ter confiança com a equipe, pedindo dos profissionais feedback quando o lado técnico afetar seu trabalho.

Algo que pode ajudar é utilizar a cultura de equipes autogerenciadas, muito difundida na comunidade de métodos ágeis. Nesse caso, o gerente funcionaria mais como um facilitador.

De qualquer forma, ter um gerente técnico pode ajudar muito na hora de contratar novos membros para sua equipe. Na hora da seleção o gerente vai saber o que realmente importa na prática, enquanto o candidato pode se sentir mais motivado de saber que vai trabalhar com alguém que entende o lado dele.

Como escolher a melhor linguagem de programação para seu projeto

Você tem um novo projeto para começar, e com os ventos de esperança de código novo sem bugs antigos, vem também o peso de tomar uma decisão importante: qual linguagem de programação utilizar? Nesse caso, podemos generalizar a mesma questão para frameworks, bibliotecas e ambientes que você vai utilizar.

Novo projeto

Começando novo projeto

O primeiro impulso natural é partir para uma abordagem quase científica, que começa com a busca por “qual a melhor linguagem de programação” ou ainda “comparação java vs pascal vs resident evil”. A partir daí chegamos a tabelas de comparação, benchmarks, ou simplesmente artigos em defesa desta ou daquela linguagem. O que é ótimo porque podemos aprender com a experiência dos outros.

O próximo passo é misturar essa nova informação com a sua experiência de projetos passados e aulas na faculdade, carregar tudo no seu cérebro e processar levando em conta as seguintes heurísticas:

Linguagens da moda: tome cuidado para não se deixar seduzir pela atual linguagem que está na moda, que todos os “hackers legais” estão usando ou querendo usar. Nada contra usá-las em projetos pequenos, para aprender e descobrir por experiência própria quais seus pontos fortes e fracos, mas muitas dessas modas vêm e vão muito rápido. Imagine a dor de cabeça que vai ser se você precisar montar uma boa equipe que precisa conhecer uma linguagem que quase ninguém domina. E como explicar para seu chefe ou cliente que seu sistema tem um problema que depende de um patch de correção que nunca vai sair, porque o pessoal que mantinha a linguagem de programação que você escolheu resolveu montar uma banda.

Moda

Moda

Conforto: pergunte-se se você e o resto de sua equipe se sentem tranquilos para resolver qualquer problema que vá surgir usando essa linguagem, ou se só de pensar nisso começam a suar frio. A linguagem te faz se sentir o McGyver usando qualquer objeto para desativar uma bomba ou o Mr. Bean se atrapalhando com um guardanapo?

Nível de ajuda externa: se você tem alguma experiência na área, deve ter algumas histórias de bugs misteriosos para contar. Se você precisar de ajuda para resolver algum problema, você consegue encontrar uma solução só de procurar a mensagem de erro no Google? Existe uma comunidade de bons desenvolvedores envolvidos com a linguagem, respondendo sobre dúvidas em fóruns e blogs? Existe alguma empresa que dá suporte a sua empresa mesmo se for final da copa do mundo com show de Elvis Presley (que foi encontrado vivo)?

Equipe: caso você precise aumentar a equipe do projeto, é fácil encontrar mais profissionais que já saibam a linguagem? Ela é fácil de aprender? No geral, os programadores que usam essa linguagem de programação parecem ser espertos ou são do tipo de pessoa que acerta o sorvete na testa?

Equipe

Equipe

Tipo de sistema: algumas linguagens são ótimas para um certo tipo de aplicação e precisam de adaptações horríveis para serem usadas em outros contextos. Mesmo que você ame a linguagem, que seja ela que você gosta de abraçar numa noite fria de inverno, nem sempre vale a pena fazer a coitada se contorcer e se machucar para satisfazer seus desejos mais obscuros (estou treinando para escrever contos eróticos).

Levando tudo isso em consideração você não tem uma garantia de sucesso, porque a linguagem é só uma ferramenta. Mas pode dormir um pouco mais tranquilo, sabendo que você sendo responsável em relação a diversos riscos que muitos aventureiros não levam em consideração.

Grails & Groovy: primeiras impressões

A maior certeza que você pode ter, se for seguir carreira como programador, é que você vai usar muitos frameworks e linguagens de programação diferentes. Alguns você vai odiar de coração, mas vai ser obrigado a usar. E quando um colega seu citar o nome dessa ferramenta, você provavelmente reagirá como se sua mãe tivesse sido xingada. Mas também haverá os frameworks e linguagens que você vai odiar menos, e que talvez, por comparação com o que você já usou no passado, você chegue até a gostar.

COBOL: não gostei

COBOL: não gostei

Alguns, como eu, nunca ficam muito satisfeitos e sempre estão a procura da solução perfeita. A resposta à pergunta mais levantada por quem precisa parir um projeto: “o que vamos usar?” Esses sujeitos estão sempre experimentando coisas novas, procurando alguma solução que não tenha os problemas que as outras tinham, e quem sabe um dia encontrar o cálice sagrado das soluções de sistemas. E eu TALVEZ tenha encontrado algo bem próximo disso e que por acaso tem o nome de Grails (se você não entendeu está na hora de entrar num curso de inglês – aí CCAA, olha a oportunidade que vocês perderam de fazer merchandising no blog).

Não vou dar o veredito final porque ainda usei muito pouco Grails, em um projeto pequeno, em que um dos maiores objetivos era aprender Grails e Groovy. Mas para vocês terem uma idéia, o projeto envolvia integração com uma interface Flex (o RIA da Adobe) e usava JMS (o padrão de Mensageria Java). E mesmo assim, escrevi muito pouco código, quase nada de configuração e nenhum SQL (sim, o projeto tem banco de dados). Acho que o fato de eu ter tido pouco trabalho fazendo isto já mostra um pouco o porquê de eu ter achado o framework tão bom.

Grails: o logotipo foi o que menos gostei.

Grails: o logotipo foi o que menos gostei.

Outro motivo para não bater o martelo é que ainda não parei para aprender Ruby on Rails. Está na minha lista de “coisas a fazer (ou não)”, mas da forma como é aclamado pelos rubistas, deve realmente ser muito bom. Bom, se bem que “Crepúsculo” é aclamado por muita gente e eu não estou a fim de ver um filme que mistura Malhação com vampiros emos. Mas o fato de Grails ter sido inspirado em Rails não me permite ignorar sua existência.

Minha experiência com o framework foi curta, mas espero poder usar eventualmente para outras coisas. Por enquanto ainda não usaria para um projeto principal, mas para algo menor não teria dúvidas. Seguem abaixo minhas observações sobre Grails:

  • a linguagem Groovy: não gostava muito de linguagens dinâmicas, mas talvez isto tenha sido por conta do período em que usava PHP. Groovy é uma linguagem muito agradável de usar (pelo menos te garanto que é MUITO mais agradável que Java) e que da mesma forma que Perl, te dá diversas formas de se fazer a mesma coisa. E assim como Ruby, te dá a opção de extender a definição de qualquer classe (como adicionar métodos a uma classe da API padrão por exemplo) e de usar closures (que a grosso modo funciona como os ponteiros para métodos e funções existentes em outras linguagens). Me agrada muito a implementação da linguagem, que te poupa de fazer checagens bobas como verificar se o objeto é nulo, ou concatenação de strings, tornando o código mais legível e mais fácil de escrever.
  • plataforma Java: isto é mais vantajoso para quem já trabalha com Java, mas de certa forma é vantajoso para todos pelo tamanho da comunidade Java. O Grails e o Groovy foram contruídos sobre a plataforma Java. Dessa forma, um código escrito em Java é aceito como código em Groovy, o que pode tornar o aprendizado um pouco mais fácil. Um código escrito em Groovy tem total interoperabilidade com código em Java, permitindo que você tenha um projeto com partes escritas em uma linguagem e partes escritas na outra. Tanto que você pode utilizar qualquer coisa que você já podia utilizar em Java (bibliotecas, frameworks, etc). Isso foi aproveitado pelos idealizadores de Grails, pois o framework tem como seus alicerces dois frameworks Java muito populares: Spring e Hibernate.
  • GORM: é o responsável por mapear seus objetos para os registros no banco de dados (daí a sigla ORM – Object-Relational Mapping), e utiliza o Hibernate por baixo do capô. Este é o melhor ORM que já vi, pois de fato torna o trabalho muito mais fácil. Como eu disse, não escrevi uma linha de SQL e também não encostei em nenhum XML de configuração para fazer o GORM funcionar. Utilizar o GORM é basicamente como eu gostaria que fosse utilizar um banco de dados orientado a objetos. Se GORM fosse uma mulher eu casava. Ah, mulher gostosa, claro.
  • plugins: Grails tem uma boa variedade de plugins para extender sua funcionalidade. O que mais me impressionou é a facilidade de se instalar um plugin em um projeto. É tão fácil quanto instalar algo usando apt-get, basta um comando (traduzindo para quem só usa Windows: é fácil pra caralho!). Em um projeto não Grails, normalmente acrescentar uma tecnologia nova, como funcionalidade de web-services ou um motor de busca, sempre gera um certo stress, a ponto de gerentes com mais experiência alocarem um bom tempo na agenda do projeto para a tecnologia ser incorporada sem problemas. Em Grails, você instala o plugin e usa o resto do tempo que seu gerente alocou para ficar pedindo convite para o novo Orkut! SE não fizerem um plugin para isso.
  • ambientes: o framework já vem preparado para rodar sua aplicação nos ambientes de teste, desenvolvimento ou produção, facilitando a configuração para essa divisão por estágios. E não só isso, quando você faz o download do Grails ele já vem com um banco de dados (HSQLDB) e servidor web (Jetty) para que você possa sair escrevendo código sem se preocupar em montar o ambiente na sua máquina.
  • testes: a parte de testes automatizados (tanto unitários quanto funcionais) faz parte do framework, o que faz com que ele reforce o uso dessas boas práticas.

Se você se interessou em aprender mais, a InfoQ tem um livro gratuito (gratuito de verdade) chamado Getting Started with Grails. Para mais conteúdo, eu recomendo um livro não-gratuito chamado Beginning Groovy and Grails: From Novice to Professional. E para trocar experiências, já existe um fórum de Grails e Groovy brasileiro: o Grails Brasil.

Sabores de open source

Não é um pretzel verde

Não é um pretzel verde

Preconceito. Essa é uma reação muito comum entre executivos de TI em relação a produtos open source. A imagem que eles tem de projetos open source é de que eles são feitos por gordinhos cheios de espinhas que escrevem código nas horas vagas. Afinal, uma coisa que é de graça não pode ser boa, não é?

O que muitos desses caras não sabem (os executivos, não os gordinhos espinhentos) é que software open source não é necessariamente de graça. Não necessariamente quem produz software nessa modalidade trabalha por caridade ou por ser idealista. É uma questão de modelo de negócios.

Um modelo que evoluiu bastante nos últimos dez anos é distribuir software de graça e open source (os dois não são sinônimos) e cobrar por suporte, treinamento e consultoria. Outro é oferecer versões gratuitas que resolvem o problema da maior parte dos usuários e vender uma versão mais turbinada. Ambos os modelos tem se mostrado lucrativos, quando o produto é bom, obviamente. Além disso, muitos projetos são financiados por firmas grandes de investimento.

O nome de que todo mundo se lembra quando falamos disso é a Red Hat, que além de ter uma distribuição de Linux muito popular, também é dona do JBoss, um dos servidores de aplicativo Java mais usados no mercado. Em 2007 a Red Hat teve um faturamento de mais de U$ 400 milhões. Impressionante se considerarmos que eles concorrem diretamente com Microsoft, Oracle e IBM, além de uma cacetada de distribuições Linux.

Mas existem vários outros exemplos de bom projetos open source que tem estrutura de empresa “normal”, ou seja, que tem um modelo finaceiramente sustentável. Alguns que me lembro agora:

  • SpringSource: inicialmente só distribuiam o framework Spring, uma alternativa mais leve e mais fácil de usar às arquiteturas enterprise padrão de mercado. Não só o framework amadureceu, mas a empresa oferece diversos outros produtos, além de treinamento, suporte e consultoria. Tem entre seus clientes, a NASA. Toyota, Samsung, Cisco. E há pouco tempo a SpringSource adquiriu outra empresa, a Hyperic, outra empresa de Open Source, que faz software de monitoramento.
  • Terracotta: já falei desses caras em um post anterior. Desenvolvem uma solução de cluster para servidores Java. Tem clientes como JPMorgan, Hitachi, Adobe e Eletronic Arts.
  • Alfresco: gerenciamento de documentos eletrônicos altamente customizável. Um de seus fundadores é o John Newton, um dos caras que criaram o Documentum da EMC, por acaso um sistema de gerenciamento de documentos eletrônicos. O que significa, que o Alfresco não foi concebido como um hobbie, ele foi criado a partir da experiência adquirida fazendo um software comercial (e caro) e que se tornou um de seus principais concorrentes.
  • Pentaho: business inteligence ao alcance de todos. Business Inteligence é o tipo de sistema que normalmente é bem caro e se for mal implantado ou mal conduzido não tráz muito benefícios. Porque não experimentar uma opção mais acessível? Diminuir os custos e os riscos. Isso sim é business inteligence.
  • Intalio: sistema de gerenciamento de processos de negócios (ou Business Process Management). Outro que está na categoria “sistemas que custam o olho da cara”. Já cheguei a baixar a versão community que é gratuita e não consegui muito progresso, mas isso já faz algum tempo. Considerando os outros softwares de BPM que já vi, acho que está na média, não parece estar defasado, mas também não me impressionou. Mas tem alguns clientes grandes, como a Accenture, a Cisco e a Petrobras.

Isso tudo sem entrar na discussão ideológica sobre software livre vs software proprietário. O que eu quero com este post é talvez acordar alguém, que ainda tenha a mentalidade de que esse tipo de software não presta. Já vi muito produto caro, de qualidade estupidamente inferior, mas que tinham preço alto por causa do fabricante famoso. “Sistemas de grife” .

Software para reduzir o número de reuniões inúteis

Pra que era esta reunião mesmo?

Pra que era esta reunião mesmo?

Um software capaz de diminuir (ou extinguir) o número de reuniões inúteis. Pessoas que trabalham de verdade (que não apenas fingem) provavelmente pagariam milhões por uma solução destas. Principalmente porque muitas dessas pessoas passam a maior parte do tempo presos em reuniões que não agregam muito, só geram mais bagunça (e mais reuniões) e se extendem por muito mais tempo do que deveriam. Se alguém parásse para calcular o quanto de retorno a maioria das reuniões geram para a empresa, as salas de reunião acabariam lacradas.

Um grande erro que muitas pessoas cometem é convocar reuniões para tomar uma decisão. Muita gente para trocar informações, discutir idéias, pode ser algo produtivo. Um monte de gente falando para no final tomar uma decisão conjunta simplesmente é muito tempo e muita energia desperdiçada. Muitas cabeças podem até pensar melhor do que uma, mas levam muito mais tempo para bater o martelo. Se você concorda com isto, deve concordar comigo que a principal função de uma reunião é a comunicação entre a equipe.

Mesmo essas reuniões cujo objetivo é realmente a comunicação, existem algumas doenças que são bastante recorrentes. Entre elas a síndrome de PQEERM (“Pra que era essa reunião mesmo?”), a febre da digressão infinita (onde alguém na reunião começa a fugir bastante do objetivo da reunião para falar das maravilhas da viagem para São José dos Campos) ou o mais comum Mal de NMPMPMCUR (“Não Me Preparei Mas Pelo Menos Convoquei Uma Reunião”). Sem falar no custo impossível de calcular que envolve cada pessoa parar de fazer o que está fazendo para participar de uma reunião. Quando você está executando uma tarefa, e precisa parar no meio, você leva muito mais tempo para retomar depois do que se conseguisse se concentrar e terminar tudo.

Algumas ferramentas simples que já fazem parte do dia a dia do escritório podem ser usados para minimizar o número dessas reuniões. E-mails, telefones, páginas da Intranet ou até mesmo um arquivo de Excell compartilhado podem ser utilizados para divulgar informações, discutir questões e permitir que as pessoas que precisam tomar as decisões cheguem a alguma conclusão. O problema dessas soluções é que o controle que se tem sobre essa informação é muito fraco, a informação fica muito dispersa (“Mas eu te perguntei isso fazem duas semanas! Ah não, esqueci de te copiar no e-mail… “).

A melhor solução que conheço para este tipo de perda de tempo é o Basecamp. O Basecamp é um sistema Web para gerenciamento de projetos criado pela 37Signals. Tem alguns clientes grandes como Warner, Adidas, Kellog´s e USA Today, mas sua base de clientes é composta principalmente de pequenas e médias empresas.

Screenshot do Basecamp

Screenshot do Basecamp

A grande vantagem do Basecamp é que ele é extremamente simples. Eles têm até um depoimento de um cliente contando como sua própria mãe ficou gerenciando o negócio dele por um tempo, de tão simples que é o sistema. Se você é do tipo que acha que software bom é aquele que tem todas as funcionalidades possíveis (que você nem usa), passe longe de tudo que a 37 Signals produz. O nicho deles é produzir sistemas que sejam simples, leves mas que resolvam o problema na maioria dos casos. Para os usuários, isso significa menos tempo e esforço para aprender a usar o software, menos poluição visual na sua tela (como é que as pessoas não enlouquecem com tantos botões e menus o dia inteiro?). Filosofia “Apple iPhone” de software. Simples e direcionado para melhorar a usabilidade do software.

 As funcionalidades principais do Basecamp para gerenciamento de projetos (e para diminuir as reuniões inúteis) são as seguintes:

  •  Lista de tarefas: nada mais é que uma lista de To-Do bem simples, com a diferença de que você pode delegar uma tarefa para uma pessoa da equipe e iniciar discussões relacionadas à tarefa. Imagine criar uma tarefa “escolher novo layout do site”, postar imagens com os layouts propostos, discutir sobre eles, chegar a uma conclusão, sem precisar parar para fazer uma reunião. Agora imagine quanto tempo uma reunião sobre isso poderia levar.
  • Compartilhamento de arquivos: projetos sempre tem arquivos que são muito utilizados. Porque não deixá-los no mesmo lugar onde você tem as informações sobre o andamento do projeto, todos os membros da equipe acessam. É o que os GEDs queriam ser quando crescerem, juntar o documento com o contexto em que fazem sentido. Nunca mais passe 15 minutos em uma reunião com o anúncio da nova planilha para cálculo de impostos.
  • Mensagens: provavelmente a funcionalidade mais óbvia. Comunicação na forma mais simples. Tem um anúncio a fazer relacionado ao projeto? Poste a mensagem na lista de mensagens desse projeto. Comunicação dentro do contexto.
  • Milestones: se você tem deadlines (conhecidas pelo Aurélio como prazos), deliverables (não conhecidos pelo Aurélio, mas seria algo como “coisas para entregar”), pode criar um Milestone e associar tarefas a ele.  
  • Writeboards: editor de texto simples para permitir a edição colaborativa de textos. Bem melhor que passar uma tarde inteira em uma sala de reunião tentando chegar a um texto perfeito para o material do novo produto, com todo mundo querendo dar palpite ao mesmo tempo e com gente fazendo bico porque a vírgula não ficou no lugar onde ele queria.

 Como eu disse, é um sistema extremamente simples. Para quem normalmente associa gerenciamento de projetos com algo como o Microsoft Project, a lista de funcionalidades acima deve soar limitada demais. Só que a maioria dessas ferramentas, para controle mais minucioso de projetos, foi criada pensando em projetos extremamente complicados, em que cada tarefa pode causar um impacto (e um prejuízo) muito grande se não for coordenada e executada dentro do prazo certo. É tão complicado que você precisa parar tudo para planejar o seu planejamento e fazer reuniões para organizar suas reuniões. Se você não está em um projeto para desenhar uma usina nuclear ou construir um foguete espacial, posso dizer com 99% de probabilidade que você não precisa de algo como o MS Project.

Além disso tudo, o Basecamp é muito barato. Com planos que vão de U$24 a U$149 por mês, e todos os planos permitem um número ILIMITADO de usuários. Eles também tem a versão gratuita, com limite para 1 projeto, para que as pessoas possam experimentar as principais funcionalidades. Compare com o preço de licença de um Microsoft Project por exemplo.

Menos reuniões = mais tempo para olhar fotos de pessoas relaxando na praia

Menos reuniões = mais tempo para olhar fotos de pessoas relaxando na praia

Se você conhece alguma solução para minimizar o número de reuniões desnecessárias, poste aí nos comentários. Se tiver uma idéia boa para isto, abra um negócio e fique milionário (ou converse comigo, ;-)).