Para onde vai o dinheiro - Aplicações a Prazo Millenniumbcp.com

No site (ou sítio) do Millennium BCP para empresas existe uma funcionalidade de aplicações a prazo.

De forma sucinta dá a possiblidade de converter um determinado valor que está numa conta a ordem numa aplicação a curto prazo (ex: 30 dias) a troco de uns juros baixinhos.

Até aqui tudo bem.

Usamos esta funcionalidade há anos e um determinado problema persiste. Quando se faz a aplicação financeira o montagem aplicado desaparece durante umas horas, depois umas largas horas, por vezes um dia.

Durante este período de tempo o valor simplesmente desaparece da nossa conta. Screenshots, comprovativos, pdfs enviados para o banco surtem muito pouco efeito e o problema continua a ser um mistério insondável.

A minha questão é... para onde vai o dinheiro?

To do or not to do

In house or Outsource Development?

Fact: Occasionally, you need new software, a new package, a new library, whatever...
Options: do it yourself, get someone else to do it or get it already done.

This is what this post is all about: to do or not to do? That, my dear programmers, is (sometimes) the question.

Like most technical dilemmas, this is not as straightforward as it may seem.

Let's take a look at some major considerations:
 - Cost
 - Ownership
 - Time to Business Value
 - Knowledge

Cost: This is usually one of the major concerns. Consider not only how much you would be charged if you sent it outside your team, but also how much it would cost to do it inhouse (in fact, this is the first criteria you should consider). Figure out the costs of your team being assigned to this one project.

Ownership: As far as inhouse goes, it's granted. However, when outsourcing you have to make sure it's specified on the contract (don't forget to do this) or on the license agreement.

Time to Business Value: It's cheaper to do it inhouse and the ownership is obvious... but can your team get it done on time? It's normal for projects not to be ready on time for a million reasons. If you outsource the project, you can assure this on the contract (include a clause on the contract stating that the supplier has to pay you a specific amount for each day of delay). If you prefer to buy it or get it already done, make sure that it does what you need and that you have support. Also verify if its source is open or not and if the supplier won't be going bankrupt anytime soon.

Knowledge: Even if it's done by your inhouse team, make sure that the knowledge gained is not limited to one particular individual or two. Guarantee that there is technical documentation and that the skills needed to support it are common to most programmers on your team (or at least that you can easily find that kind of resources).

I've kept this list short. It should be enough for most cases.
Do your decisions already take all of this into account?

Produção versus Produtividade

Vivemos num país onde o trabalho não produtivo ultrapassa os 35% (fonte: Expresso).

Poderiamos fazer muito mais sem aumentar a carga laboral diriam alguns.
Na Espanha e na França onde esta percentagem é ainda maior, as empresas em média produzem mais. Este argumento cai por terra.
A resposta é simples, produtividade.

Confunde-se muito produção (conjunto de bens e serviços produzidos) com produtividade (taxa na qual os produtos e serviços são produzidos).

Numa análise leve existem opções para fazer mais: aumentar o trabalho produtivo e/ou aumentar a produtividade.

Assumamos um trabalhador português (com os 35% de trabalho não produtivo) cujos objectivos diários estão a ser cumpridos.
Seria legitimo assumir que apenas teria de trabalhar 65% do dia dado que é suficiente para os objectivos da entidade patronal. Bastam apenas 5 horas e 12 minutos de trabalho produtivo para cumprir os objectivos. Se cortarmos as quase 3 horas da carga horária diária restante teremos um aumento significativo de produtividade mantendo os objectivos.

Assumamos um outro cenário. Uma empresa tem um excesso de encomendas e pondera a contratação de novos funcionários, trabalho temporário, subcontratação.  Todas estas opções implicam um custo adicional. Aumentando o trabalho produtivo e/ou produtividade tal não seria necessário.

Sem querer entrar em assuntos como gestão do tempo, motivação, planeamento e definição de objectivos, este raciocínio simples pretende demonstrar que existe elasticidade entre produção e produtividade. Cabe a cada gestor estar atento e gerir o melhor balanço.