Categorias
Tech

3 motivos para a falha de projetos de software

Trabalhando por muitos anos no desenvolvimento, já tive a oportunidade de participar de muitos projetos de software. Boa parte deles como membro de equipe, alguns como Scrum Master e outros como freelancer, fazendo todo o trabalho sozinho.

Isso me trouxe alguma experiência no quesito projeto de software.

Acompanhei projetos que deram muito certo e outros que nem tanto. Sobre estes sempre fica a pergunta: “por que este projeto falhou?”.

Cada projeto tem suas características específicas, mas para me aprofundar mais nos motivos gerais das falhas resolvi fazer uma rápida pesquisa para procurar artigos acadêmicos que falam sobre esse assunto.

Analisando alguns deles fica claro quais são os principais motivos listados.

  • objetivos não realistas ou não articulados
  • software que não atende às reais necessidades do negócio
  • requisitos de sistema, requisitos dos usuários e especificação de requisitos mal definidos
  • gestão de projeto deficiente
  • metodologias/práticas de desenvolvimento desleixadas
  • prazos e orçamentos do projeto
  • estimativas imprecisas dos recursos necessários
  • má comunicação entre clientes, desenvolvedores e usuários
  • uso de tecnologia imatura
  • pressões comerciais
  • satisfação do cliente
  • qualidade do produto
  • entre outros (lista completa neste artigo)

Como podemos perceber, são muitas as possíveis causas de um projeto de software ser malsucedido.

Essas pesquisas foram feitas com diversos projetos e estão em artigos espalhados por aí, mas eu quero focar naqueles motivos que já senti na pele, como um envolvido no projeto.

1. Requisitos de sistema mal definidos

Este é um caso muito mais comum do que se imagina. Acontece o tempo todo e já passei por diversos projetos com esse problema, por isso ele está no topo da minha lista.

Análise de requisitos é um processo complicado e demorado. É preciso da atenção de um profissional especialista e que vai conseguir levantar exatamente tudo que é preciso para que aquele projeto de software atenda às necessidades dos interessados.

Isso faz parte de projetos de softwares mais tradicionais e não necessariamente funciona do mesmo jeito em projetos ágeis, em empresas que necessitam de entregas mais constantes como as startups de tecnologia ou que possuem prazo e orçamento mais apertado como as fábricas de software menores.

Acontece que não ter um levantamento de requisitos tradicional não libera ninguém de levantar requisitos.

Talvez alguns gestores não entendam que o uso de métodos ágeis não é desculpa para que as descrições de tarefas sejam muito bem pensadas e completas.

“Gastar” tempo levantando requisitos bem definidos com os stakeholders (as partes interessadas no projeto) aumenta as chances de uma entrega mais assertiva e rápida do software.

2. Gestão de projeto deficiente

Eis um tópico extremamente genérico e que afeta muito os projetos de software. Uma má gestão pode significar diferentes problemas para a equipe, incluindo o tópico anterior.

Mesmo que as equipes ágeis sejam autogerenciáveis segundo a teoria, normalmente existe alguém que centraliza essa tarefa mais do que os outros membros. Além disso, em muitos casos, os executivos da empresa costumam não permitir tanta autonomia para que a equipe se gerencie.

A gestão de projetos deficiente acaba tendo um impacto muito grande na motivação da equipe, na falha de comunicação, na necessidade de retrabalho, na má administração dos recursos e dos prazos, etc.

Já presenciei alguns casos de má gestão e a responsabilidade pela falha do projeto costuma sobrar para os membros da equipe…

3. Qualidade do produto

Em alguns casos na minha experiência o produto tinha um potencial incrível, poderia trazer muito valor para os usuários… mas simplesmente não funcionou quando eles precisaram.

A qualidade do produto faz parte do valor agregado entregue em qualquer projeto.

É muito comum existir um membro da equipe focado nesse assunto. Uma pessoa para garantir a qualidade do software e mantê-lo sempre na sua melhor versão possível, sem erros e sem problemas de usabilidade.

Projetos de software que falham por falta de qualidade do produto não precisam de muita explicação, não é…

Eis um investimento que vale a pena, mas que muitas vezes é subestimado pelos responsáveis do projeto.

Entre outros…

Os motivos selecionados aqui são os que mais me chamaram a atenção por acontecerem em diversos projetos os quais eu participei. Por isso estão nesta lista em ordem de importância.

Na minha experiência pessoal eu não vejo um motivo específico para a falha de projetos de software e sim uma combinação de problemas que se acumulam e minam o projeto como um todo.

Em diversos dos casos que presenciei mais de um desses itens estavam combinados com outros também descritos na primeira lista retirada dos artigos pesquisados no início dessa publicação.

O que fazer?

Pessoalmente, acredito que uma das formas de evitar a falha de um projeto é ouvindo as pessoas envolvidas. Aproveitar a experiência de quem participa do desenvolvimento para tentar entender o que está acontecendo durante todo o processo.

Uma liderança mais aberta e que se importa com a opinião dos envolvidos tem maior chance de identificar um possível motivo de falha antes que o mesmo se torne irreversível para o projeto.

A chave é não esperar o projeto chegar em um nível crítico para então parar para analisar o que pode estar dando errado.

Por isso as empresas que mais crescem e entregam tecnologias incríveis valorizam tanto os profissionais que colaboram para que isso aconteça. Mantendo sempre um ambiente com menos fricção para comunicação e mais atenção ao que está acontecendo durante as iterações de desenvolvimento.

Para você, quais são os maiores motivos para a falha em projetos de software? Deixe sua opinião sobre o assunto nos comentários.

Até a próxima!

Categorias
Tecnologia

Primeiros passos com o GIT

GIT é um software de controle de versão utilizado por muitos e muitos desenvolvedores e empresas no mercado de tecnologia.

Um controle de versão serve para manter o histórico do desenvolvimento do código e também para ajudar uma equipe de programadores trabalhando no mesmo código a não fazer besteira no meio do caminho.

Vamos à um exemplo bem simples.

João está fazendo alterações no arquivo index.html ao mesmo tempo em que Carlos. João altera as linhas 30 até 50 do arquivo e Carlos da 80 a 100. Em algum momento os dois precisam juntar esse código para ter a versão final do documento que vai para o site joaoecarlos.com.

Isso é bem fácil, basta que um dos dois pegue a parte do código que o outro alterou e cole na posição correta no arquivo index.html. Está pronto para subir para o servidor, certo? Certo.

Então para que eu preciso do Git para ajudar o João e o Carlos?

Bem, basta dizer que se o João estivesse alterando entre as linhas 80 e 100 do mesmo arquivo teríamos um conflito entre o que o João fez e o que o Carlos fez. Não bastaria colar as alterações do João sobre as do Carlos, seria preciso que se analisasse linha por linha do que cada um fez para ver qual deve entrar e qual deve sair. Basicamente os dois precisariam sentar juntos e reescrever o código. Trabalho dobrado.

Agora imagine que essa reescrita de código pudesse ser feita de forma automática? Não seria ótimo?! Sim. Seria.

Aí entra nosso querido software de controle de versão! No caso dessa publicação estamos falando de Git, mas ele não é o único.

Vamos rever o exemplo do site joaoecarlos.com agora utilizando o Git em todo o processo.

João modifica o arquivo em seu computador. Ele salva localmente suas alterações e faz o commit com o Git que salva no repositório local quais alterações foram feitas. No final do processo ele executa um push e essas alterações ficam salvas em no repositório remoto.

Carlos faz alterações no mesmo arquivo e executa seu commit localmente. Quando ele for executar o push para o repositório o Git vai avisá-lo que seu código local não está atualizado com o repositório. Então ele executa um pull e baixa as alterações que João fez e o Git se preocupa em reescrever seu código para escolher quais linhas devem ficar em quais posições. Depois disso, Carlos pode verificar se está tudo certo com seu novo código e mandá-lo para o repositório com mais um push.

Pronto. É assim que funciona o Git… da maneira mais básica o possível, é claro.

O Git é muito mais do que isso, mas primeiro é preciso entender o seu conceito básico para começar a trabalhar com ele.

Vamos ver o passo a passo do que o João e o Carlos fizeram.

Aviso: todos os exemplos vistos nesta publicação são comandos executados em um console/terminal de linha de comando de um sistema operacional com base em Unix (MacOS ou Linux, por exemplo). Eles consideram que o Git já está instalado no seu ambiente de trabalho. Para ver como instalar clique aqui.

Primeiro eles precisaram iniciar o repositório Git localmente no diretório em que seus códigos estavam. Acessando via linha de comando eles entraram na raiz do código.

cd /Project/joaoecarlos/

Foi lá que ele iniciaram seu novo repositório com o comando:

git init

Para verificar os arquivos que o Git vai rastrear eles usaram o comando git status e viram algo como o exemplo abaixo.

On branch master
Initial commit
Untracked files:
  (use "git add <file>..." to include in what will be committed)
index.html
nothing added to commit but untracked files present (use "git add" to track)

Eles notaram que está escrito Untracked files logo acima do nome do arquivo. Isso quer dizer que o Git não está “rastreando” esse arquivo.

Com o comando git add . eles adicionaram todos os arquivos do seu projeto na lista de arquivos a serem rastreados. O . representa todos os arquivos e diretórios presentes nesse diretório. Eles viram algo assim:

On branch master
Initial commit
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
new file:   index.html

Agora eles tem um ambiente preparado para fazer o seu primeiro commit. Eles adicionaram o arquivo index.html à lista de arquivos que serão gravados nesse commit.

Com a execução do comando git commit -m "Primeiro commit" eles finalmente gravaram sua primeira “versão” do site joaoecarlos.com no seu repositório local.

[master (root-commit) d8cbc79] Primeiro commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html

O atributo -m "Primeiro commit" é um encurtamento de uma parte do processo de commit que é muito importante: descrever o que foi alterado.

Todo commit precisa ter uma boa descrição do que foi feito. Isso facilita muito para o futuro, onde centenas ou milhares de commits foram executados em um repositório. Imagina se você precisa encontrar onde foi feita alguma alteração no passado?

Pode-se executar esse comando sem o atributo -m, mas em seguida o console irá abrir um editor de texto para que se escreva uma mensagem descrevendo o que foi alterado.

Bom, agora que nossos colegas do exemplo já tem um repositório local, precisam enviar isso para um repositório centralizado. Um exemplo de serviço muito bom (e bem conhecido) para criar um repositório é o GitHub.

Depois de criarem sua conta e seu repositório no Github, nossos desenvolvedores adicionaram esse repositório como remote nas suas configurações do Git.

git remote add origin https://github.com/user/repo.git

Esse origin que você vê no comando é um apelido que se dá para o repositório remoto em sua máquina. Por padrão estamos chamando de origin que é o mais comum que você vai encontrar por aí.

Adicionar o remote no seu repositório local serve para indicar de onde ele deve puxar o código atualizado e para onde ele deve enviar seus commits. É o repositório com o qual todos os desenvolvedores do projeto vão interagir e onde ficará registrado todas as informações sobre alterações e versões do código do seu projeto.

Agora nossos desenvolvedores de exemplo estão prontos para subir seus primeiros commits para o repositório no GitHub com o comando git push origin master.

git push origin master

Vamos analisar esse comando…

git push é a parte que diz que queremos enviar o que temos de commitsna nossa máquina para o repositório remoto, GitHub por exemplo.

origin master diz para onde enviar esses commits, como o apelido do repositório é origin isso significa que vamos enviar para o GitHub que adicionamos a pouco.

master significa o branch que estamos usando. Mais para frente vou falar sobre branch, mas por enquanto vamos assumir que estamos trabalhando apenas com o branch padrão, que é chamado de master. Ele já foi criado quando o João ou o Carlos executou o git init lá no começo.

voilá. O código dos nossos amigos está no repositório do GitHub.

Agora vamos dizer que o Carlos precise trazer as atualizações de lá. Ele executou os primeiros passos (git initgit remotegit add e git commit) na sua máquina local e agora quer atualizar o código com o que tem no repositório remoto.

git pull origin master

Assim como o git push nós estamos dizendo para o Git de onde queremos buscar as atualizações com o origin master.

Agora o Git já atualizou o código na máquina do Carlos.

Em outro momento vou falar sobre os conflitos, algo que pode acontecer nesse momento de sincronização (ou merge) quando se usa controle de versão.

Por enquanto é isso. Esses são os primeiríssimos passos para utilizar o Git como controle de versão em um projeto.

Esse texto foi produzido para quem nunca teve contato algum com controle de versão, para dar uma ideia geral de como é e para que serve.

Se você quer saber mais sobre Git, deixe um comentário que eu planejo mais publicações como essa, dando continuidade ao processo e explicando mais sobre outros fatores.

Postado originalmente no Medium.

Categorias
Crônicas Tecnologia

Ser um Programador Ninja…

…ou Programador Rockstar ou Mago da Programação…


Este texto foi originalmente publicado no Medium. Leia a versão original clicando aqui e recomende se você gostar.


Alguns bons anos atrás, costumava ser cool ver uma vaga de emprego com a expressão “programador ninja” ou algo do gênero. Mostrava que a empresa era maneira, joinha e que tinha aquele ambiente de trabalho diferentão.

“Buscamos um programador ninja”

Hoje, a coisa é um pouco diferente. Quando vejo uma vaga que busca um programador ninja ou um mago da programação, eu já desconfio.

O problema não é a expressão em si, que hoje em dia é brega e não pinta mais a empresa como “diferentona”. O problema é que ela costuma vir com uma lista absurda de exigências…

O cidadão tem que comprovar anos de experiência em diversas linguagens de programação, tem que gostar de programar em seu horário livre (?!) e, às vezes, é um diferencial, se não obrigação, que o camarada tenha projetos paralelos.

Ou seja, o cara não tem que ser um programador… Ele tem que programar de tudo e o tempo todo. Se tiver vida pessoal, não serve para mago da programação.

O ninja-mago-rockstar da programação

Por algum motivo essas empresas acreditam que é preciso ser apaixonado pela programação para ser um bom profissional. E para demonstrar isso tem que ter aqueles projetos paralelos e, quem sabe, uns commits no seu Github nas madrugadas de sábado.

O que não percebem é que quem programa por prazer não necessariamente vai gostar de trabalhar no seu projeto de gestor administrativo ou de vendas. Hobbies que viram trabalho nem sempre são tão prazerosos. E isso não é tudo…


Nesta semana eu li um texto aqui no Medium chamado Programming Doesn’t Require Talent or Even Passion (Programar Não Exige Talento ou Mesmo Paixão). Eu recomendo a leitura para qualquer um que trabalhe na área.

Nele o autor fala que nunca antes uma habilidade foi tão mitificada como a programação.

“Você não precisa apenas ter talento, você também precisa ser apaixonado para se qualificar como um bom programador.”

É exatamente o que pedem nessas vagas de programador Rockstar dos dias de hoje.


Exemplo de uma vaga postada na lista Python BrasilNo texto citado, o autor ainda traz uma série de grandes nomes da área, como os criadores dos frameworks Rails e Django e da linguagem PHP, por exemplo, que demonstram claramente não serem grandes amantes da programação e muito menos gênios da magia do desenvolvimento de software.

“Na verdade eu odeio programar, mas eu amo resolver problemas.” Tradução da citação de Rasmus Lerdorf, criador do PHP.

Eu trabalho nessa área há cerca de treze anos e não tenho receio em dizer que os melhores profissionais que encontrei não eram grandes magos dos códigos. O que realmente importa nessa área é a entrega. É conseguir resolver os problemas apresentados de forma objetiva e simples e, quase sempre, em um curtíssimo espaço de tempo.

Um bom profissional da programação não precisa ser um gênio, um monstro, um ninja, um hacker… ele precisa saber resolver problemas e ter a capacidade e humildade de aprender o que precisar para atingir esse objetivo.

Além disso, esse mito atrapalha todo mundo que está envolvido ou quer se envolver na área.

“O mito do ‘programador gênio’ é extremamente perigoso. Por um lado, ele deixa o limiar de entrada muito alto, assustando um monte de aspirantes a programador. Por outro lado, também assombra os que já são programadores, porque isso significa que se você não é um mago na programação, você é ruim… …Programação é só um monte de habilidades que podem ser aprendidas e não exigem muito talento, e não é vergonha nenhuma ser um programador mediano.” Tradução livre de parte da citação de Jacob Kaplan-Moss, criador do Django.

Eu consegui aprender a programar, e nem sequer gostava disso…

“Depois de muito tempo percebi que eu tinha ficado melhor em programar e continuava sempre ocupando vagas em empresas nessa área, entretanto, sempre querendo sair para ‘trabalhar com o que gosto’.”

Esse é um trecho de um texto que escrevi em 2014 falando sobre a minha relação conturbada com a programação. Eu passei anos procurando trabalhar em outra área, porque realmente não gostava de programar.

O que mudou isso em mim foi conhecer o Python. Passei a curtir a simplicidade e objetividade de escrever códigos com essa linguagem. Hoje eu gosto do que faço. De vez em quando eu até programo por diversão no meu horário livre.

Eu não consigo me enxergar como um bom programador, mas sei que consigo atender as expectativas de quem me contrata. Resolvo os problemas e faço as minhas entregas. E isso me deixa orgulhoso do meu trabalho.

Não somos ninjas, gênios ou magos, somos profissionais da área de desenvolvimento de software. É isso que temos que ser das 9h as 18h, ou em qualquer que seja seu horário de trabalho, o que fazemos fora disso diz respeito somente a nós mesmos.

Quer ter projetos paralelos? Ama programar? Ótimo.

Mas se você gosta de nadar, andar de bicicleta, jogar futebol, passear com seu cachorro, ficar com sua família ou dormir por horas e horas no seu tempo livre, você continua sendo um programador.

Não é isso que vai definir sua qualidade como profissional.

Pode ser também…

Categorias
Tecnologia

Sticky navbar com Bootstrap

Como fixar a barra de navegação do Bootstrap quando a barra de rolagem chegar nela? Essa funcionalidade é chamada de Sticky Navbar.

Utilizando esse código JavaScript abaixo a barra de navegação estática (com a classe .navbar-static-top) passa a ficar fixada no topo da página (classe .navbar-fixed-top) quando a barra de rolagem atinge certa parte da página.

      var num = $('.navbar').offset().top;

      $(window).bind('scroll', function () {
          if ($(window).scrollTop() > num) {
              $('.navbar').addClass('navbar-fixed-top');
              $('.navbar').removeClass('navbar-static-top');
          } else {
              $('.navbar').addClass('navbar-static-top');
              $('.navbar').removeClass('navbar-fixed-top');
          }
      });

A variável num contém a quantidade de pixels do topo até onde a barra de rolagem vai atuar para modificar o estilo da navbar. Neste caso estou utilizando o método offset() do jQuery para verificar a altura da barra de navegação automaticamente.

As classes de navbar descritas acima são originalmente do Bootstrap (testado com o Bootstrap 3.3.2), mas com algumas adaptações pode ser utilizado em qualquer outro CSS, basta alterar os nomes das classes no código.

Esse código foi encontrado nesse JSFiddle e apenas alterei para a utilização do método offset().

Categorias
Tailer

Por que parou? Parou por que?

Fazem algumas semanas que não temos novas páginas da webcomic Tailer online, não é? Infelizmente sim… E hoje recebi um comentário perguntando o por que. Vou aproveitar a deixa e escrever um pouco sobre isso.

Estou sempre buscando evoluir a história de Tailer, tentando melhorar a qualidade dela. Sei que não sou um ótimo escritor, mas por isso mesmo prezo muito o que estou desenvolvendo no decorrer das páginas da webcomic.

Tailer terminou sua fase inicial, onde os personagens são apresentados. Praticamente todos que vão ser importantes na história já foram introduzidos nas páginas. Agora chega a parte que eu considero a mais complicada de todas: criar um relacionamento realista entre todos eles.

É exatamente nesta parte que estou meio travado. Tenho uma noção clara do que quero fazer no final de Tailer, mas para chegar a este final, preciso ter sucesso na atual fase de relacionamentos que a história se encontra. É por isso que a produção diminui de velocidade. Preciso pensar muito bem em cada um dos acontecimentos, planejando e prevendo o papel que cada personagem terá no final.

Além disso, o meu tempo continua escasso, como sempre. Outro motivo pelo qual as páginas estão mais demoradas.

Bem, espero que todos estejam acompanhando a história e que estejam satisfeitos com o que vem acontecendo com os personagens. Porque o trabalho, mesmo independente e sem fins lucrativos, é feito com muita dedicação.

Obrigado a todos.

Oficialmente publicado no meu DeviantArt