Esse é um assunto antigo, publicado em 1997 por Craig Larman em seu livro “Applying UML and Patterns”. Porém, é de grande relevância no contexto do desenvolvimento de software e, por isso, vale a pena relembrar. Por haver bastante material na internet a respeito do GRASP, vou tentar contribuir apenas com um resumo que serve tanto como referência rápida quanto breve introdução para quem ainda não conhece.
GRASP significa General Responsibility Assignment Software Patterns (ou Principles) e trata-se de um conjunto de nove princípios fundamentais em design orientado a objetos que estão relacionados com a atribuição de responsabilidades entre os elementos do software, tais como módulos, classes e métodos. Quando falamos de “responsabilidades”, nesse contexto, estamos nos referindo a distribuição das ações que serão realizadas pelos elementos do software.
O que os princípios do GRASP nos oferece é uma forma de distribuir essas responsabilidades da melhor maneira possível, visando a qualidade do código com relação a torná-lo mais legível, desacoplado e fácil de manter – tanto manutenção corretiva quanto evolutiva.
A seguir, serão apresentados de forma resumida os nove princípios do GRASP:
1. Information Expert oy Expert Principle: A melhor classe para assumir uma responsabilidade é aquela que possui todos os dados necessários para realizá-la. Se uma classe não possui todos os dados necessários, ela não pode realizar aquilo que precisa, logo, essa classe não é o melhor elemento para receber a responsabilidade.
2. Creator: Atribua a classe B a responsabilidade de criar uma classe A quando:
B contém ou agrega de forma composta A
B registra A
B usa de perto A
B tem os dados de inicialização para A
3. Controller: É o primeiro objeto, depois da camada de interface com o usuário, a receber e coordenar uma operação do sistema. O objeto deve receber essa responsabilidade quando se enquadrar nos cenários a seguir:
O objeto representa todo o sistema, a raiz do sistema, o dispositivo onde o software executa ou o subsistema.
O objeto representa um cenário de caso de uso onde a operação funciona.
4. Low Coupling: Ao atribuir uma responsabilidade, tenha certeza de estar reduzindo ao máximo a dependência com outros elementos do sistema. Quanto mais isolado e independente for o elemento, menos acoplado ele está. Essa medida reduz o impacto de mudanças e promove o reuso de componentes.
5. High Cohesion: Atribuir uma responsabilidade de modo que o elemento torne-se o mais focado, inteligível e fácil de manter possível. Quanto maior a coesão menor será o acoplamento.
6. Indirection: Consiste em criar um componente para servir como mediador (Mediator Pattern) entre dois ou mais componentes que estão relacionados. Essa medida evita o acoplamento direto entre esses componentes que precisam se relacionar.
7. Polymorphism: Quando um comportamento varia conforme o tipo do objeto (sua classe), atribua a responsabilidade ao método que representa tal comportamento. Dessa maneira, usando polimorfismo, podemos evitar sentenças condicionais no código para saber qual comportamento adotar. Esses comportamentos serão acionados de acordo com o tipo de cada objejeto.
8. Pure Fabrication: Quando os demais princípios não forem suficientes para atribuir uma responsabilidade sem causar baixa coesão e alto acoplamento, crie uma classe para assumir essa responsabilidade. Um exemplo desse princípio é o padrão Domain Service usado no DDD, ele contém a lógica que não pertence a uma entidade específica.
9. Protected Variations: Consiste em identificar pontos de variações e instabilidades nos elementos do sistema para criar uma interface estável em torno deles. Com essa medida, protegemos o resto do sistema das variações e da instabilidade desses elementos.
Se você for familiarizado com o assunto, esse resumo vai ajudar a lembrar de algumas coisas pontuais, quando necessárias. Mas se o assunto for novo para você, recomendo procurar outras fontes e continuar se aprofundando nele. Os ganhos pela aplicação desses princípios em projetos de software são significativos e aumentam a qualidade do produto final.
O Flask é um framework leve e simplificado em Python para criar aplicações Web. E o Heroku é uma plataforma em nuvem onde você pode publicar suas aplicações ou serviços com planos grátis para iniciantes e estudantes.
Esse é um tutorial para criar um projeto Python com Flask e Gunicorn do zero, fazendo deploy na plataforma em nuvem Heroku.
O Flask será usado para criar um serviço que irá atender uma requisição HTTP. O Gunicorn é um HTTP Server que subirá o serviço do Flask. O Gunicorn será usado porque o HTTP Server interno do Flask é somente para desenvolvimento e testes, não deve ser utilizado em produção.
O código completo desse exemplo pode ser clonado a partir do Git em https://github.com/edprata/python-flask-on-heroku
Preparação no Heroku:
Acesse o Github e crie um repositório novo para o seu projeto.
Acesse o Heroku e crie uma conta gratuita. Ele utiliza autenticação em duas etapas. Você pode usar o Google Authenticator no seu celular para esse fim.
Na home do Heroku, clique no botão “New” no canto superior direito e selecione “Create new app”.
Em “App name” coloque o nome do seu projeto, pode ser o mesmo do Github.
Clique em “Add Pipeline”.
Em “Choose a pipeline” escolha “Create new pipeline”.
Em “Name the pipeline” pode usar o mesmo nome do App. Se for usar staging (um ambiente de homologação) pode acrescentar “-stage” no final do nome para diferenciar da pipeline de produção (production). É recomendado usar pelo menos dois ambientes, em sendo pré produção.
Em “Choose a stage to add this app to” escolha “staging”.
Clique em “Create app”.
Abra a aba “Deploy” e desça até “Deploy method”.
Clique em “GitHub”, informe o nome do repositório e clique no botão “Search”.
Agora seu App Heroku está conectado ao repositório Github e pronto para receber seu código.
Clone e Criação do Projeto:
Em um diretório da sua máquina a sua escolha faça a clonagem do projeto Github:
O projeto estará vazio, acesse sua IDE preferida, como o PyCharm, e crie um projeto Python nesse diretório.
Preparação do Projeto Python para o Heroku:
1. Crie um arquivo chamado “requirements.txt”, no raiz do projeto, com as dependências (bibliotecas). Esse arquivo é lido pelo Heroku durante o deploy e essas dependências serão instaladas automaticamente. O conteúdo deve ficar conforme abaixo, cada dependência em uma linha. Em nosso exemplo o conteúdo deve ser:
flask
gunicorn
2. Crie um arquivo chamado “Procfile” (desse jeito, sem extensão) com o seguinte conteúdo:
web: gunicorn service
3. Esse arquivo é lido pelo Heroku após o deploy e o comando dentro dele é executado. No nosso caso o comando acima subirá o HTTP Server Gunicorn executando um arquivo Python chamado “service”. Note que não será chamado o Flask diretamente, pois é o Gunicorn que fará esse trabalho.
Código Python com o Flask:
Para nosso Hello World escreva num arquivo chamado “service.py” o seguinte código:
# Lib do Flask.
from flask import Flask
# Lib que permite ler variáveis de ambiente.
from os import environ
# Lê a variável de ambiente HOST e na sua ausência usa o endereço '0.0.0.0'.
# Esse endereço com zeros indica ao Flask para aceitar requisições de outras origens.
# Por default o Flask só aceita requisições da máquina local.
host = environ.get("HOST", '0.0.0.0')
# Lê a variável de ambiente PORT, pois no servidor é um dado dinâmico.
port = environ.get("PORT", 5000)
# Imprime os dados para aparecer no log do Heroku.
print("HOST={} PORT={}".format(host, port))
# Cria um objeto Flask para subir no servidor.
app = Flask(__name__, static_folder='static')
# Essa variável "application" será usada pelo Gunicorn para subir o Flask.
application = app.wsgi_app
# Médoto que irá atender uma requisição HTTP tipo GET na raiz do domínio.
@app.route("/")
def hello_world():
return "<p>Hello, World!</p>"
if __name__ == '__main__':
# Sobe o Flask no host e porta do ambiente em que está rodando.
app.run(debug=False, host=host, port=port)
OBS: O nome do arquivo não é importante, mas deve ser o mesmo referenciado no arquivo “Procfile”.
Commit do código:
No console, faça commit no GitHub conforme abaixo:
Retorne ao Heroku, acesse o pipeline criado por você e em seguida a aba “Settings”.
Desça até “Connect to GitHub”.
Informe o nome do repositório no GitHub e clique em “Search”.
Clique no botão “Connect”.
Acesse a página de configurações do App criado por você (na tela “Pipeline” tem o atalho).
Acesse a aba “Deploy” e desça até “Automatic deploys”.
Clique no botão “Enable Automatic Deploys” para que nos próximos commits o deploy ocorra automaticamente.
Desça até “Manual deploy” e clique no botão “Deploy Branch”, já que essa é a primeira vez e você já fez commit.
Aguarde até que o deploy termine e apareça a mensagem “Your app was successfully deployed.”.
No canto superior direito no topo da tela há o botão “Open app”, clique nele e veja o resultado.
Dicas:
Se houver erro no deploy você pode consultar o log no Heroky. Utilize o botão “More” e em seguida “View Logs” no canto superior direito da tela.
Se ocorrer erro nas primeiras tentativas de deploy ou se ficar muito tempo inativo o serviço pode cair e você pode ter que ir até a página do seu App, aba “Overview”, quadro “Dyno information” e verificar se está “ON”. Se não estiver clique em “Configure dynos” e no quadro “Free Dynos” clique no lápis (lado direito). Coloque em “ON” e confirme.
Você pode criar um segundo pipeline de production para ter dois ambientes e trabalhar com promoção de código. Cada pipeline pode receber o código de um branch diferente do GitHub, por exemplo branch “homolog” e “master”.
Referências:
Se quiser conhecer mais sobre os assuntos abordados aqui pode consultar os endereços abaixo:
Este é mais um artigo voltado à educação de nível superior. Utilizarei nos exemplos tópicos ligados ao mercado de Tecnologia da Informação, pois é a minha área de especialização. Porém, os critérios que serão apresentados servem também para outras áreas. Basta usar a imaginação e substituir os nomes técnicos para os da sua área (se você não for de TI) e os conselhos continuarão valendo.
A motivação do artigo, obviamente, é apoiar e orientar estudantes, recém-formados e profissionais com pouca experiência. E, por favor, vamos começar assumindo que cursos extracurriculares são importantes, ok? Não é objetivo deste artigo colocar a importância deles em discussão, mas sim os critérios para escolher e investir. Afinal, trata-se de trocar tempo e dinheiro por conhecimento. É preciso saber escolher para evitar desperdício destes recursos tão preciosos.
Alinhados quanto à motivação e objetivo do artigo, lhe pedirei que pense por um minuto em quantos cursos você acha interessante e/ou gostaria de fazer nos próximos meses. Considere, por exemplo, cursos de tecnologias específicas (Java, .Net, Android, Swift, SAP, AWS), métodos e processos (Scrum, XP, TDD, RUP) e também técnicas, frameworks e boas práticas (User Experience, PMI, ITIL, COBIT).
Já pensou nos cursos que gostaria? Quem sabe você queira fazer tudo que eu citei e ainda muito mais, não é? Se você pensar pelo trabalho que isso irá lhe dar, poderá não querer fazer nenhum. Mas se pensar no possível retorno profissional e financeiro, aí as coisas mudam e o interesse surge.
Lembro que quando eu estava na faculdade queria fazer quase todos os cursos de que ouvia falar. Mais tarde, quando me tornei professor, pude ver alguns alunos enfrenando o mesmo dilema que eu tive. Os alunos mais interessados, claro. O dilema de ter muito a aprender, mas não ter muito tempo nem muito dinheiro. É uma fase difícil!
A primeira dica é: decida-se sobre o que você quer ser! Em outras palavras, defina qual função você desempenhará no mercado de trabalho. Este é o fator mais importante de todos e não apenas para escolher cursos extracurriculares. Saber o que se quer é importantíssimo para que você possa alcançar seus objetivos com mais velocidade e menos sofrimento. Sempre abordo este ponto em artigos como esse, pois ele é realmente determinante para a tomada de decisões quanto à formação e a vida profissional. Pessoas indecisas tendem a perder muitos recursos e trilhar um caminho bem mais longo.
Como segunda dica, recomendo buscar conhecer um pouco mais sobre o assunto de interesse, quer seja pesquisando na internet ou conversando com profissionais mais experientes, antes de procurar qualquer instituição de ensino ou cursinho. Não procure orientação lá no cursinho, pois as pessoas poderão estar mais interessadas em vender do que no seu futuro profissional. Certifique-se de que o assunto é realmente relevante para a função que você vai exercer no mercado de trabalho. Se depois de pesquisar por você mesmo e também conversar com pessoas imparciais você chegar a conclusão que o assunto não é realmente relevante, recomendo descartar e procurar outro que seja. Não desperdice seu tempo, aprenda a priorizar. Este, aliás, já é um exercício extremamente útil e uma habilidade exigida pelo mercado de trabalho.
Chegou a conclusão que o assunto é de interesse e também é relevante? Ótimo! Mas antes de decidir, lá vai a terceira dica: Você já procurou saber se existe alguma certificação associada a este assunto? Este curso que você encontrou por aí cumpre algum pré-requisito para, mais tarde, você obter a certificação? Se não entendeu fique tranquilo, eu vou explicar melhor.
Muitos dos assuntos que você vai decidir estudar (sejam tecnologias, técnicas, métodos ou conjuntos de boas práticas) podem e provavelmente são regulamentados por alguma instituição, empresa ou órgão (geralmente internacionais). Esta organização, que está por trás do assunto que você pensa em estudar, estabelece critérios para “premiar” com uma certificação ou licença os profissionais que alcançam proficiência. Isto significa que se você investir em um curso que não cumpre com as exigências ou critérios estabelecidos pela organização responsável você estará desperdiçando, de certa forma, energia com algo que poderia lhe dar um retorno ainda maior. Mais tarde, quando você desejar obter a certificação, terá que fazer outro curso, muito semelhante àquele que já fez, mas que cumpre os requisitos da organização responsável.
Vamos ao exemplo. Já ouviu falar de Scrum? Se você é de TI, é quase certo que sim. Esse é um método para gestão de projetos bastante famoso hoje em dia. Mas você sabia que, apesar de haver um montão de cursinhos de Scrum por aí, apenas alguns deles podem lhe conceder ao final o privilégio de ostentar a certificação da Scrum Alliance? Esta é a organização que regula o Scrum no mundo. E se você não seguir os padrões dela não pode se dizer realmente conhecedor da metodologia e nem comprovar proficiência por meio de uma certificação. Neste caso, por isso é um bom exemplo, a organização responsável exige que você aprenda o método pelo curso oficial, que só pode ser ministrado por um profissional qualificado para este fim. Apenas depois do curso realizado você pode fazer a prova teórica que lhe dará a certificação. Para você ter uma ideia, hoje no RJ só existe uma instituição que oferece o curso oficial, mas há centenas de cursinhos “alternativos”.
Agora imagine que você, ao invés de fazer o curso oficial formulado e ministrado de acordo com os critérios da Scrum Alliance, fez outro qualquer que não lhe dá o direito de fazer a prova. Se quiser ser reconhecido como um profissional qualificado para trabalhar com Scrum, você terá que fazer o curso novamente. Perdeu tempo e dinheiro fazendo da primeira vez, mesmo que tenha sido mais barato.
A Oracle e a Microsoft também exigem cursos oficiais para algumas certificações, só para dar mais exemplos. Então, recomendo atenção a este detalhe. Afinal, qualquer certificação ou curso oficial darão muito mais peso ao seu currículo. Isto não se discute.
Por fim, uma quarta dica: Busque referências sobre a instituição onde você vai estudar e o professor que ministrará as aulas. O currículo do professor e as referências do curso são muito importantes. Se não houver experiência e didática adequadas, você terá mais dificuldade para absorver o conteúdo que, por sua vez, já pode ser bastante exigente.
Resumindo, estas são as quatro dicas fundamentais para decidir quais cursos fazer:
1 – Defina-se quanto à função que você vai exercer na vida profissional;
2 – Avalie a importância do assunto de interesse com relação à função escolhida. Aprenda a priorizar os assuntos mais relevantes;
3 – Procure saber se o assunto não exige um curso oficial ou critérios específicos como pré-requisitos para uma certificação ou licença. Se houver, vale mais a pena buscar o caminho oficial, mesmo que você não pretenda certificar-se agora;
4 – Por fim, avalie bem a instituição e o professor. Ao colocar no seu currículo o nome de uma instituição, você coloca junto a reputação dela.
Espero ter contribuído para elucidar este velho dilema. Deixe sua opinião, ok?
Muito se vê e se ouve sobre a luta contra inovações que chegam para mudar o mercado e os modelos de negócios tradicionais. Dois grandes exemplos são o Ubber e o Whatsapp, que frequentemente passam por turbulências causadas por protestos, ataques jurídicos e críticas polêmicas sobre questões como pagamentos de impostos e a existência ou não de vínculos trabalhistas (este último fator no caso do Ubber).
E para dar força a esta onda de modelos de negócios inovadores, chegaram até nós os cartões de crédito que, além de não cobrarem anuidade, são gerenciados por nós mesmos via aplicativos – entre outros benefícios. É claro, isto já não é mais novidade e não estou aqui para “dar a notícia” que já está velha. Segundo o Wikipédia, a primeira compra utilizando o Nubank foi realizada em 1/4/2014, ou seja, já caminhamos para três anos de operação deste cartão. Não faz muito tempo o Nubank ganhou até um concorrente, o Digio, emitido por uma parceria entre o Banco do Brasil e o Bradesco. Saiba mais sobre o Digio nesta matéria da Infomoney, se você ainda não conhece.
Esclarecido que não estou aqui para “dar a notícia” sobre o lançamento do Ubber, Nubank, Digio, Whatsapp ou qualquer outro, a reflexão que trago neste artigo é: será que toda essa cadeia reativa, em torno destas inovações, conseguirá de fato derruba-las? Eu acho que não e vou explicar o porquê.
Por quê inovações geralmente encontram tanta reação?
Primeiro gostaria de analisar junto com você qual é o motivo de tanta reação com relação a modelos de negócios inovadores. A opinião pública costuma se dividir, sempre há pessoas contra e a favor, apesar de, a princípio, a “inovação” como conceito ser geralmente considerada uma “coisa boa”. As pessoas, em seus discursos, costumam afirmar que “inovar” é algo positivo. Muitas campanhas de marketing e líderes de todos os tipos fazem uso da palavra “inovação” com entonação positiva e até colocando este conceito como um “objeto de desejo”, se é que se pode transformar um “conceito” em “objeto”. Enfim, a “inovação”, como ideia, geralmente não é combatida. Mas quando ela se manifesta em algo concreto, como um produto ou serviço, aí a coisa muda de figura.
Um dos problemas é que quando uma inovação se apresenta no mercado, como produto ou serviço, ela geralmente carece de leis e regras específicas. É claro, o tal produto ou serviço inovador não existia, logo, como poderia haver regulamentação apropriada? E é a partir deste momento que a sociedade começa a questionar detalhes sobre recolhimento de impostos, limites operacionais, logística e concorrência, entre outros. Com relação a isso o conselho de um humilde consumidor como você: precisamos ter paciência e sobriedade, pois tudo o que é novo precisa de tempo para amadurecer. Mas se quisermos evoluir e usufruir das inovações, precisamos saber tratá-las com carinho até que todos estes detalhes sejam digeridos e tratados adequadamente.
Outro problema das grandes inovações, e acredito que o maior deles, é que elas geralmente abalam o mercado e até as relações de emprego tal como os conhecemos. Novos modelos trazem novos conceitos e, consequentemente, novas formas de relacionamento do cidadão com o trabalho. Isso é inevitável! Sabemos que profissões morrem e nascem o tempo todo e que, em época de grandes mudanças e surgimento de ideias inovadoras, este processo é acelerado.
Este é o fator que costuma ser mais criticado, mas a inovação não deve ser detida por causa dele. Podemos até lutar contra ela, podemos resistir, podemos lamentar… mas no final, modelos de negócios mais eficientes sempre causarão mudanças profundas nas relações de consumo e também trabalhistas. Modelos de negócios obsoletos irão consequentemente morrer, pois não serão competitivos. Mas novas oportunidades nascerão, ainda que das cinzas dos velhos negócios.
Há um post circulando nas redes sociais, que geralmente fala sobre o Ubber, citando a morte da profissão de datilógrafo, o fim das fitas K7 e dos discos de vinil, assim como o filme fotográfico e alguns outros produtos, serviços e profissões devido a evolução tecnológica. Você já deve ter visto este post por aí. Ele é bastante interessante, pois nos alerta sobre um dilema antigo e inevitável: inovação trás mudanças. Você consegue se imaginar utilizando uma máquina de escrever hoje? De modo algum, com certeza. Será assim daqui a alguns anos quando você pensar em telefonia tal como era há pouco tempo atrás, quando pensar sobre os cartões de crédito que cobravam anuidade e não ofereciam aplicativos para dar informações em tempo real sobre seus gastos ou quando você pensar sobre como funcionavam os táxis.
Não posso deixar de abordar neste artigo outro fator muito importante, motivo pelo qual há tantos problemas, críticas e até boicotes, numa tentativa desesperada e vã de combater inovações. Este outro fator é a resistência dos modelos de negócio que se tornam obsoletos com o surgimento de ideias inovadoras e até revolucionárias.
Muitas vezes os negócios que se veem, de repente, obsoletos, representados por organizações já consolidadas no mercado com seu modelo de operação “tradicional”, começam a combater por meios jurídicos e até financeiros os novos negócios baseados em ideias inovadoras. Isso não é raro. Algumas organizações, mais antenadas e dispostas a se reinventarem, aderem à inovação e lançam produtos concorrentes. Mas organizações com visão focada no passado ou acomodadas geralmente preferem combater ao invés de acompanhar as tendências do mercado.
Será que, no final, as inovações irão prevalecer?
A experiência nos mostra que, com mais ou menos facilidade, as inovações, tanto tecnológicas quanto mercadológicas, tendem a vencer estes muitos obstáculos e, no final, nos vemos num cenário onde não conseguimos mais imaginar como vivíamos sem aquele novo produto ou serviço. É bastante difícil, se não impossível, deter ideias realmente inovadoras. E o fator que considero principal para este fato é o seguinte: inovações trazem implícito em sua concepção a eficiência que ideias tradicionais, já exploradas ao limite, jamais poderão alcançar.
Uma ideia inovadora tende a nascer maior e melhor que qualquer evolução dada a ideias antigas e conservadoras. E ainda oferecem potencial de crescimento que as antigas ideias um dia já tiveram, mas que, por vezes, alcançou o seu limite.
Lembra-se dos conceitos da Matriz BCG, proposta na década de 70? Pois é, eles ainda são úteis e servem para nos ajudar a entender este processo. O ciclo de vida de produtos e serviços, como tudo que há, um dia encontra seu fim e, para manter a “roda girando”, é preciso inovar!
Outro ponto relevante, que muito contribui para o sucesso das inovações, é a rápida adoção de produtos e serviços inovadores pelo mercado consumidor. Logo que experimentamos algo novo, melhor e mais eficiente que os produtos e serviços até então disponíveis, não nos imaginamos mais vivendo sem eles. Alguém quis usar discos ou fitas K7 após o surgimento do CD? Alguém que experimenta conteúdo on-demand, como o do Netflix, se contenta depois em assistir apenas a TV tradicional (aberta ou a cabo)? Alguém que experimenta um cartão de crédito sem anuidade, com acompanhamento de gastos no App e descontos para pagamentos antecipados, quer continuar a utilizar um cartão sem nada disso? Há exceções, mas evidentemente a maioria preferirá a novidade. E onde houver mercado consumidor, haverá alguém interessado em vender.
Considerações finais
Talvez este excesso de reação inicial, oriundo principalmente daqueles que se sentem ameaçados por soluções inovadoras, seja o efeito causado por uma sociedade pouco acostumada a investir em pesquisa e a pensar em inovação. Isso se compararmos o nosso país com outros onde esta cultura é amplamente disseminada. Quem sabe este exercício não esteja sendo tão praticado quanto deveria por organizações e profissionais em geral e, talvez por isso, estejamos sendo mais resistentes do que deveríamos. Se bem que alguma resistência é sempre normal e, ouso dizer, até saudável. Mas não muita.
Gostaria de concluir dizendo que sim, os boicotes, manobras jurídicas e artifícios mercadológicos das grandes corporações poderão até deter uma ou outra empresa que surja com uma ideia inovadora. O Nubank, por exemplo, até pode ser aniquilado pelos grandes players do mercado financeiro. Entretanto, a ideia que for realmente inovadora ressurgirá de novo e de novo até se consolidar no mercado por meio de uma ou de várias organizações. Pois não se pode deter a inovação em si, este é um conceito maior que todos nós e que está profundamente enraizado na alma do ser humano. É possível reprimir por um pouco de tempo, mas não é possível reter para sempre a inovação.
Então, o que você acha? Deixe sua opinião e contribua com o artigo.
Vez e outra eu escuto novamente esta discussão. Seja pela dúvida dos iniciantes, pela defesa de quem acredita ou pelas críticas de que quem não acredita na importância delas. Com objetivo de reforçar o coro dos defensores e orientar os iniciantes, resolvi colocar também minha opinião. Posso até “chover no molhado”, mas acredito que o assunto vale a pena.
Uma certificação, na área de TI, é basicamente um documento que atesta proficiência do detentor em determinada técnica, método ou tecnologia. Com ela, o profissional pode não só afirmar, mas também comprovar, que possui um conhecimento profissional específico e que alcançou este conhecimento por mérito próprio. Além de comprovar que este conhecimento foi testado por critérios estabelecidos por uma entidade ou organização, em geral internacional, por meio de um processo maduro, seguro e confiável.
Isso é particularmente mais relevante para os iniciantes, que padecem de pouca ou nenhuma experiência profissional adquirida no mercado de trabalho. Uma certificação não substitui a experiência oriunda do exercício da profissão, evidentemente. Mas é uma forma de comprovar conhecimento e, pelo menos, uma convivência teórica mais profunda com determinada técnica ou tecnologia. Muito mais profunda que, por exemplo, as abordagens feitas nas salas de aulas de universidades e cursos extracurriculares.
Mas será que o mercado dá realmente algum valor a isso? Com certeza! Geralmente as empresas utilizam estas certificações para cumprirem exigências em processos licitatórios, de clientes, de projetos específicos e também para fazerem propaganda do seu corpo técnico. Quanto mais profissionais certificados uma empresa possui, mais condições ela tem de captar clientes e projetos.
Mas as empresas não possuem suas próprias certificações? Sempre há alguém que faz esta pergunta, mesmo que em tom retórico. Sim, claro, as empresas podem adquirir diversos tipos de certificações e as utilizam para se destacarem perante a concorrência. Mas as certificações de seus profissionais também são utilizadas para esse fim. Muitas vezes o contrato que ela deseja ganhar exige certa quantidade de profissionais certificados e, se a empresa não dispuser destes profissionais, não consegue fechar o negócio.
A certificação não é importante apenas para que possa ser “exibida” em concorrências, licitações e para clientes mais exigentes. Ela de fato enriquece o profissional que, muitas vezes, saiu da graduação com grandes “brechas” em sua formação. Um dos problemas mais comuns encontrado em profissionais iniciantes é o fato de eles terem adquirido conhecimento multidisciplinar, mas bastante superficial. Isso pode ser minimizado por uma certificação na área de atuação pretendida.
Se você está nesta fase, recomendo em primeiro lugar que você defina o seu objetivo. É importante que esteja claro para você qual é a função que deseja exercer no mercado de trabalho. E é comum existir esta dúvida no início da carreira. Quer ser analista de negócios, especialista em banco de dados, programador, analista de BI, trabalhar com nuvem, mobile ou ser gerente de projetos? Saber qual caminho você pretende trilhar é fundamental para economizar tempo e dinheiro na busca por seu lugar ao sol. Quanto mais rápido você definir seu objetivo, mais rápido tende a alcança-lo.
Em segundo lugar, trace um plano, ou seja, que habilidades e conhecimentos você precisar ter para ser aquilo que pretende? Não perca tempo investindo em cursos ou habilidades que não estejam diretamente ligadas a função que você quer exercer. Uma boa forma de fazer isso é estar sempre pesquisando vagas de empregos e observando o que as empresas pedem para cada cargo. Se você investir em coisas que “podem ter a ver” ou que “podem ajudar”, você estará deixando de investir em coisas que com certeza farão a diferença e encurtarão sua caminhada rumo ao topo. Tudo é uma questão de relevância e prioridade.
Por último, mas não menos importante, insista na obtenção das habilidades, conhecimentos e certificações que você entendeu como realmente importantes para seu objetivo profissional. E persista até conseguir! Não se proponha conseguir logo na primeira tentativa, pois isso não é saudável e, além do mais, não faz a mínima diferença quantas vezes você tentou. O importante é você aprender de verdade o que esta estudando e conquistar o título ou certificação pretendidos. O quanto de esforço foi necessário aplicar é algo muito pessoal. Mas lhe garanto, não é fácil para ninguém! Contudo, é recompensador.
Espero ter dado “aquele empurrãozinho” que faltava para você começar a se preparar.
Este é um assunto antigo e batido. Porém de grande relevância e ainda cheio de mitos, dúvidas e o pior: Cercado de resistências no dia a dia de equipes de desenvolvimento de software em empresas de consultoria e Software Houses de todos os portes.
As alegações para não utilizar um processo ou método de desenvolvimento são sempre as mesmas:
Nós não temos tempo, o prazo é muito curto!
O cliente não vai querer pagar por isso…
Somos pagos para criar software, não documentos!
Isto aumenta demais o custo do projeto.
Já sabemos o que precisamos fazer, é só programar!
A demanda é muito simples, não precisamos disso…
Na prática, esta coisa de processo não funciona.
Mas então qual é o motivo para a alta taxa de insucesso dos projetos de software? Afinal, se a estimativa de custo e prazo estavam corretas e o escopo estava tão claro ou era tão simples que nem mesmo era preciso fazer uma análise mais aprofundada, o que deu errado? Geralmente algumas das seguintes situações ocorrem:
O prazo é excedido (e frequentemente numa taxa absurda que, por vezes, ultrapassa até a faixa de 100% do prazo estimado);
O custo é excedido (e frequentemente as consultorias levam prejuízo com projetos que, a princípio, pareciam ter uma ótima margem de lucro);
A entrega é um produto muito distante das expectativas do cliente, ou seja, eles esperavam uma maçã, mas entregamos algo semelhante a um abacaxi que, no fundo, não sabemos bem o que é…
E ainda podemos observar os seguintes sintomas durante o andamento do projeto:
O cliente reclama o tempo todo (do prazo, do escopo, da qualidade, da atenção dada ao projeto e muitas outras coisas);
A equipe se desfaz “repentinamente” (as pessoas vão para outros projetos ou para outras oportunidades de emprego);
A equipe não sabe o que fazer ou como fazer as coisas (projeto e funcionalidades mal compreendidos);
A equipe se perde em meio as atividades (não sabem quais os próximos passos);
A entrega não é clara (nem para o Gerente do Projeto, nem para a equipe e nem para o cliente);
Grandes “mudanças”, como arquiteturais ou de modelagem de dados, são descobertas no meio ou até mesmo no fim do projeto. A palavra está entre aspas, pois geralmente não são mudanças, mas sim necessidades mal compreendidas e as vezes que até foram sinalizadas pelo cliente desde o início.
Vários outros sintomas poderiam ser citados e certamente qualquer pessoa que trabalha em projetos de software se identificaria com cada item da lista, lembrando-se de situações que viveu na própria pele. E o motivo é simples: A forma como fazemos software repete viciosamente a receita falha de não seguir um processo na prática.
A maioria das grandes consultorias possuem um processo, geralmente inspirado no RUP. E até possuem certificações de qualidade. Apesar disto, o problema persiste. Por quê? Basta pensar por alguns segundos e qualquer profissional da área vai se lembrar de experiências onde o processo e a documentação era apenas uma “burocracia que tinham que seguir” para entregar o projeto. Quantas vezes a documentação é feita DEPOIS do desenvolvimento do software, quando deveria ser a base para a sua construção? Em síntese: Apenas para “inglês ver”.
Se o processo não é implantado de fato na organização ele se torna um grande fardo para os profissionais que deveriam ser resguardados e assessorados por ele. Implantar um processo de desenvolvimento não é apenas criar um monte de modelos de documentos. Também não se trata de conseguir um certificado para a empresa. Trata-se na verdade de incorporar um processo ou método à cultura da organização, de treinar e envolver os profissionais, além, é claro, de seguir de fato o processo e não apenas “ter para constar”.
Quando uma organização busca uma certificação de qualidade baseada em processo, mas não implanta este processo de fato, ela apenas GASTA dinheiro. Quando ela implanta, ela investe. Mas não é um investimento para curto prazo e talvez este seja um dos motivos pelos quais muitos gestores não consigam ver com o devido valor tal investimento.
Mas o que um processo pode fazer de concreto pela organização ou pelo projeto? É fácil entender a necessidade de se planejar algumas coisas: A construção de uma ponte, um prédio ou um viaduto. E até coisas mais simples: Uma viajem, as férias ou o casamento. É fácil olhar para estas necessidades e pensar “seu eu não me preparar e planejar, acho que pode dar errado”. Mas por alguma razão as pessoas não tem este mesmo instinto ou consenso quando o assunto é “software”. Elas acreditam que “de alguma forma mágica” tudo será construído muito rapidamente e, como computadores são incríveis, o sistema vai saber fazer tudo o que elas imaginarem (mesmo se imaginarem depois de o sistema já estar pronto). Sei que não preciso dizer mais direi: Nada disso vai acontecer.
Como qualquer outra coisa (e eu diria muito mais) a construção de softwares precisa ser minuciosamente planejada para que haja um mínimo de qualidade e para que não se jogue dinheiro fora (e muito) devido a fatores como:
Pedidos desnecessários (coisas que o cliente pediu ou acha legal ter, mas nunca vai precisar);
Prazo e/ou esforço mal estimados;
Retrabalho e/ou perda de produção devido a necessidades mal compreendidas ou mal implementadas;
Perda de produtividade por questões de má gestão da equipe – profissionais frustrados ou desmotivados produzem muito menos e com baixa qualidade;
Desgaste no relacionamento com o cliente que, aliás, quando está insatisfeito não volta.
Desta forma podemos dizer acertadamente que ter um processo significa pensar e planejar antes de fazer. Consequentemente, isto significa diminuir custos e aumentar a lucratividade. Além disso, ao se diminuir custos tornamos a organização mais competitiva. E estas não são razões ruins para se decidir por um investimento.
E será que funciona? Pense bem: Organização, planejamento e métodos funcionam para qualquer outra coisa. Isto apenas não é diferente para o assunto “construção de software”. E por que haveria de ser?
Aí vão alguns conselhos para quem ainda pensa que um processo de desenvolvimento é só uma teoria que não pode ajudar:
Se o tempo é curto hoje, ele será bem menor depois que o projeto não estiver andando adequadamente por falta de entendimento, falta de definições e, principalmente, depois que parte dele precisar ser refeito ou reestruturado devido deficiências durante a concepção (que, aliás, pode nem ter sido feita);
Se o custo já está elevado, ele será muito maior quando a equipe for forçada a fazer várias horas extras para entregar o projeto que já está atrasado. Por causa daquelas “mudanças” que só são descobertas no meio ou no fim do caminho;
Se o cliente não quer pagar pelo que você acha que ele não entende (como o processo e os documentos), muito menos irá pagar pelo atraso ou pelo produto de má qualidade;
Nada é tão simples quanto parece. E se parece, é porque você não entendeu;
E por último, mas não menos importante, planejar, na prática, é o que funciona! Se planejando temos problemas, sem planejamento temos muito mais.
