I m a g i n a r y :::::::::::::

Conhecimento tecnológico + Gestão eficiente = Software que funciona

Sobre o que Escrevemos:

Arquitetura, programação, peploware, gestão no desenvolvimento de software e manutenção. Linguagem de programação java. Banco de Dados. Tecnologias e Mercado Tecnológico em geral.

Como chegar ao sim

Sábado, 18 de Outubro de 2008

O assunto negociação e visto como algo pejorativo e o pensamento comum e que numa negociação para se chegar a um bom acordo, devemos recorrer a ‘truques sujos’ ou ‘ceder a pressões’.No livro ‘Como chegar ao sim’, mostra que uma negociação pode ser diferente, mostrando um processo de busca de boas alternativas para todos os interessados na substancia da negociação.

No livro ‘Como chegar ao sim’ o autores define um método para obter um bom acordo para todos. O método concentra-se em quatro pontos:

1) Separe as pessoas do problema.

2)Concentre-se nos interesses, não nas posições.

3) Invete opções de ganhos mútuos.

4)Insista em critérios objetivos.

O livro também mostra uma estrategia de como obter êxito na negociação com pessoas que são mais poderosas, recusando-se a ceder às pressões ou recorrer a ‘truques sujos’.

Ficha do livro:
Como Chegar ao Sim: a Negociação de Acordos sem Concessões
Editora: Imago
ISBN: 8531209560
Ano: 2005

O mesmo remedio para todas as doenças!

Quinta, 9 de Outubro de 2008

Em todas as circunstâncias no desenvolvimento de um problema ( software), utilizar o framework padrão ou sempre a mesma solução( exemplo: Session Bean + DAO + Struts) designado pela corporação ou grupos de que se dizem arquitetos, independente do sistema e da condição que o software vai ser desenvolvido, como prazo, tecnologias e plataformas envolvidas, experiência da equipe e características do sistema, costuma causar prejuízos a empresa quando em produção ou no prazo de desenvolvimento.

Cada técnica deve ser aplicada a um determinado problema, aplicar uma técnica que não ajude ou atrapalhe, não soluciona o problema, adiciona mais problemas, acho que dai vem aquela velha frase:

“Informática e a solução para os problemas que você ainda não conhece”

Seria o mesmo que receitar aspirina para qualquer doença, porque para dor de cabeça, ela funciona muito bem, quanto a uma dor de barriga!

Tudo depende das condições de desenvolvimento e do tipo do sistema, uma arquitetura para os sistemas de uma empresa de telecom e bem diferente de uma empresa de varejo.Cada uma tem a sua característica inerente aos seus negócios, posso falar por experiência, que muitos sistemas na área de telecom ficam mais difíceis quando no processo de desenvolvimento for utilizado apenas a abordagem relacional, o que não e o caso de empresas de varejo que armazena dados e processa para geração de relatórios e apenas exibe a informação para o usuário do sistema. Sistemas de telecom envolve diversas plataformas e tipos de tecnologias e protocolos, enquanto que no ramo de varejo e mais servidores de banco de dados.

Utilizar artefatos desnecessários e modelar todos os sistemas seguindo um padrão determinado, como diagramas de seqüências para todo caso, causa sobrecarga de documentos desnecessários e desperdício de horas de trabalho e um acumulo de papel. Proteja a natureza!. Selecione o que realmente seja necessário para desenvolver e modelar no sistema para determinar a maior parte da energia no objetivo principal do sistema.

Frameworks proprietarios e outro caso que costuma costuma adicionar mais custos ao projeto ou para empresa, são mais horas gastas no desenvolvimento, e não consegue diluir este custo em diversos projetos como alguns argumentam, para saber se vale realmente a pena desenvolver um framework, coloque argumentos financeiros na sua proposta, prove com dados historicos da empresa, prove em numeros se vale a pena. E coloque todos este requisitos para que a solução seja otima para o negocio, e não somente em termos tecnologicos.

O arquiteto deve agir como medico, receitando uma arquitetura(solução) de acordo com o cliente e tipo de sistema.

Aviso! Compre bastante aspira para os programadores, quando eles tiverem que dar manutenção no sistema com o framework e soluções padrão.