Quando falamos do trabalho em programação, apesar de também ter seu nicho de manutenção (correção de bugs que surgem, verificação de funcionalidades, etc), estamos falando de um trabalho que é essencialmente criativo. Muitas coisas terão que ser trabalhadas a partir do zero e melhorias serão feitas com base em novas funcionalidades ou novas maneiras de fazer as coisas.

Perceba que tudo que é feito em programação é novo: nova melhoria, novo programa, nova solução, novo hotfix, etc. E, para tudo que é criado, sempre teremos que trabalhar com projetos.

Mas, como podemos definir o que é um projeto?
De acordo com o site significados

Projeto é um plano para a realização de um ato e também pode significar desígnio, intenção, esboço.

Esta é uma palavra oriunda do termo em latim projectum que significa “algo lançado à frente

Ou seja, um projeto é um planejamento de realizar algo no futuro, o que faz bastante sentido. Você não tem algo concreto hoje, mas você estuda os passos que são necessários para conseguir chegar nesse estado almejado, ou nesse produto idealizado. A partir disso, podemos abstrair o que é necessário nos atentarmos para trabalharmos em um projeto.

Quando o projeto é pessoal, o desafio é maior do que se fosse um projeto empresarial. No caso das empresas, os papéis são separados: temos a figura do gestor de projetos que cuida de tudo que é relacionado à parte gerencial e administrativa. Você, como desenvolvedor, se situado ali nos níveis júnior e pleno, iria integrar a parte técnica do projeto, como um músico que tem que seguir as fintas do maestro. Porém no projeto pessoal, as figuras do gestor e do técnico se fundem em uma única pessoa, então quem irá gerenciar e desenvolver o projeto será o autor do projeto (ou seja, você). E são várias pequenas coisas que devem ser gerenciadas, então a execução do projeto é o menor dos problemas.

Recapitulando, um projeto é um ato de execução a fim de se chegar a determinado estado futuramente. O ato refere-se ao que será feito: um site, um software de gestão de arquivos, um editor de texto. Quando definimos o que iremos fazer, muitas vezes é a coisa mais genérica possível, porém isto pode emergir de duas possibilidades que não são necessariamente excludentes entre si

1. um desejo (aumentar o faturamento, facilitar algo, melhorar alguma coisa, se atualizar, satisfação pessoal, conseguir um emprego, etc.);

2. uma necessidade(aumentar o número de vendas para acompanhar o mercado, lançar um produto para fazer concorrência com outro, automatizar algo para ter mais tempo para outra tarefa, ganhar mais, etc.).

Geralmente, a premissa por trás do ato irá dizer muito sobre o direcionamento que o projeto irá tomar. Com isso, temos a semente que irá geminar o projeto, para partirmos para um plano e uma execução.

Projetos pessoais não têm uma estrutura formal definida. Ninguém se reúne consigo mesmo para dizer o que deve ou não ser feito. Eu tenho uma ideia e o meu desejo é colocar ela em prática logo, e essa é minha motivação (o que em parte tem me feito procrastinar para escrever este post, mas isso é outro assunto). No meu primeiro post, falei sobre a motivação pela qual me levou a fazer meu site, então só sentei e fiz, mas senti várias dificuldades pelo caminho. Para concretizarmos o nosso intento, precisamos saber qual são os objetivos envolvidos nisso, e esses objetivos irão se traduzir na delimitação do projeto, ou em seu escopo.

Em um projeto pessoal, a definição de escopo é muito fluida, fazendo com que essa delimitação seja a mais nebulosa possível. Pense por um segundo: você está fazendo um projeto para você mesmo. Após um tempo em execução, algumas linhas de código estão prontas juntamente com algumas funcionalidades. Neste exato momento, você pensa um pouquinho e decide mudar, adicionar ou diminuir algo. Como é somente você e você mesmo, não existe dificuldade em mudar, é somente você, seu bel-prazer e sua disciplina que mandam. A mudança no escopo se torna muito fácil nesse sentido, mas extremamente complicada para o projeto. Afinal, como podemos dar esse projeto como acabado se sempre tem algo para mudar? Uma solução viável seria adiar essas mudanças para a fase de manutenção, quando o escopo mínimo inicial já está feito e foi realizado o deploy. Foi a mesma coisa com meu site, onde sacrifiquei várias coisas que queria colocar somente para ter um estado inicial terminado. Gostaria de colocar uma página com meu currículo, adicionar responsividade (que é coisa básica hoje em dia), e fazer mais coisas, mas deixei para fazer isso em implementações futuras.

Isso nos leva a outra coisa importante: o prazo. O prazo em um projeto pessoal é super flexível, afinal, não existe aquela pressão do mercado para que haja o pagamento sobre o projeto tão logo ele seja terminado (ou área comercial que promete um prazo mirabolante para cliente que é tecnicamente impossível), mas você imagina um horizonte de tempo para que aquele projeto esteja pronto. Mas muitas coisas podem acontecer nesse meio tempo, como outras coisas te ocuparem, a necessidade de intercalar os estudos com aquele projeto, o fator humano (procrastinação, não estar psicologicamente bem naquele dia). Tudo isso influencia em quanto tempo você irá terminar o projeto. Eu mesmo admito que, antes de finalmente terminar meu site, fiquei uma semana inteira procrastinando sobre ele. A automotivação nesse sentido é algo muito importante, bem como disciplina, mas é necessário ter cuidado quando tudo isso se torna uma autocobrança exagerada.

Relacionado ao prazo, temos a questão do custo, que parece irrisório, porém, mesmo que não haja um desembolso financeiro, o custo existe, e ele está traduzido no tempo. É necessário lembrar-se que custo não deve ser associado imediatamente com custo financeiro e sim com alocação de recursos. Dinheiro é um recurso, mas não é o recurso. O computador internamente possui custos, traduzidos em alocação de memória, gastos de energia elétrica e queima de disco, que no final, são equacionados na eficiência do sistema digital. De igual forma, você aloca tempo nesse projeto, e por conta disso, há uma expectativa sobre isso. Toda vez que temos um custo, temos também uma noção de retorno associada a ele. Tempo procrastinado é tempo gasto sem retorno, porém tempo de descanso é tempo gasto em eficiência, e é importante não confundir isso.

Para garantir eficiência também há a questão do ferramental para as tarefas envolvidas no projeto. Em projetos empresariais, essa questão costuma ser estudada tendo em vista os objetivos do projeto, pois uma ferramenta mal escolhida se traduz em maior custo. Em projetos pessoais isso é mais flexível. Muitos projetos são para composição de portfólio e para fins didáticos. O portfólio é a demonstração do que eu consigo fazer com a ferramenta. Meu site também faz parte do meu portfólio, então consigo demonstrar que sei manipular o código para que cuspa HTML para mim, e isso com Javascript puro, e isso, ao mesmo tempo, teve um fim didático, porque poderia ter escolhido um framework. Mas isso me permitiu ver como parte das coisas funcionam por baixo de um framework, e tenho a vantagem de voltar no meu projeto depois com novos conceitos em mente para aprender ainda mais sobre uma coisa que eu fiz. Por exemplo, eu tenho um projeto de Relógio Digital que fiz em Javascript puro, e na última semana estive aprendendo sobre Vue. O que eu fiz com várias linhas de Javascript, o Vue já faz pra mim automaticamente com menos linhas escritas por mim, fazendo esse gerenciamento automatizado entre VDOM e DOM.

Tirando essa questão do didatismo, a ferramenta é muito importante, pois em lugar nenhum existe algo como "The Jack of All Trades". Por exemplo, você precisa plotar um relatório em um site, dá pra usar Canvas, mas por que não já ir direto para o D3.js?

Uma vez tentei ajudar um estudante de física, onde o professor tinha o orientado a estudar sobre a biblioteca ggplot, desenvolvida originalmente para FORTRAN, porém as funções também podem ser chamadas em C. Lembro que uma das coisas que questionei é, porque o professor não passou algo em Python? Python tem um bom nível de abstração para que profissionais que não são de programação possam se focar na solução necessária sem terem que se preocupar com detalhes técnicos que não viriam ao caso para sua profissão. Vejamos que, para começar, as funções de FORTRAN, tem seus parâmetros, por padrão, passados por referência, enquanto em C, temos o padrão, que é por valor, e também parâmetros passados por referência utilizando ponteiros. Aí o físico vai ter que estudar sobre ponteiros, e também sobre alocação de memória manual (coisa que muito programador não sabe, inclusive eu, graças o Garbage Collector que grande parte das linguagens interpretadas possuem), bem como modelo de memória.

Por que não passar um Python pra ele onde a preocupação do profissional irá ser apenas a sintaxe? Já disse aqui que não é a toa que Python é uma ferramenta popular para análise de dados. Isso só demonstra que a ferramenta também tem que fazer sentido ao profissional (se você discorda, dê um maçarico a um engenheiro e vamos ver até onde ele chega).

Para dar uma última pincelada em cima disso, convém observar que o projeto tem que fazer sentido em seu todo. Quando falamos em projeto pessoal, acredito que sua principal característica seja sua fluidez: ele se adapta ao profissional (e não o contrário) e não mantém um estado rígido quando se propõe, por isso, talvez ele seja mais difícil. Lidar com liberdade é muito difícil, afinal você tem várias possibilidades, e a pior coisa ao ser humano é a armadilha da escolha (e não a ilusão da escolha em si). Talvez por isso, acho bem complicado fazer um projeto grande sem ter um roadmap ou uma definição bem sólida do que eu preciso fazer, mas mesmo assim ainda faço dessa forma e simplesmente seguir ordens seja um caminho mais fácil. Tudo onde há apenas uma possibilidade a ser seguida é inicialmente mais fácil, mas menos satisfatório, e o caminho onde há mais sofrimento (liberdade) é aquele que no fim é o que há de mais felicitante (filosofia de buteco para acabar bem).