Devo dizer que “code-review” ajuda sim, principalmente quando a equipe é renovada com frequência e sua maioria é composta por estagiários e programadores juniors. Agora vendo por outro lado, também temos problemas com o code-review visto que a MDS é desatualizada e implementações ficam paradas esperando pelo code-review. Quem não tiver problemas atire a primeira pedra! Devo dizer que acredito bem mais em programação em pares.

Quanto ao papel de arquiteto, aqui acontece exatamente o inverso, sou barrado pela burocracia e pelo medo de investir na hora de propor alguma melhoria seja na tecnologia, ou seja, no processo.

O comentário do Marcelo Vaz também é pertinente, concordo em tudo que ele disse. Planejamento é tudo, inclusive o do fracasso, pois assim conseguimos contorna-lo a tempo.

Padrões e regras aumentam a produtividade e com isso geram retorno financeiro. Não fosse pela padronização a Ford nunca teria criado o “Model T” e a indústria automobilística não estaria onde está hoje.

Um modelo de negócios exige planejamento, o que restringe a flexibilidade.

O problema não está em criar regras e padrões, está em não reavaliar essas regras e padrões de tempos em tempos.

Sou a favor da inovação mas contra a anarquia. Não conheço modelo de negócios que funcione sem que limites seja estabelecidos.

Seja qual for o ramo de negócios, chega um momento em que o custo de não inovar é maior que o custo da mudança, e é esse o momento em que muitas empresas se veem caminhando para o abismo.