Waldomiro Jose DallAgnol

10 passos fundamentais
para o sucesso (garantido)
em projetos de migrao,
reengenharia e
desenvolvimento de ERPs

O que apresentaremos nesse EBOOK fruto de nossas experincias de 28

anos como desenvolvedor de sistemas. Os fundamentos (dicas) que estaremos apresentando so em sua maioria, os mesmos defendidos pelas
principais metodologias de desenvolvimento de software e gerenciamento
de projetos, apenas procuraremos enriquece-los com a nossas experincias
pessoais.
Primeiramente vou falar da minha formao, depois falarei dos sucessos e
fracassos de projetos que participei e no final apresentarei as dicas do que
fazer ou no fazer em projetos de desenvolvimento ou redesenvolvimento de
sistemas. Apesar da minha experincia ser na maior parte em projetos de TI,
acredito que possam ser aplicadas a qualquer projeto.

Apresentao:
Waldomiro Jose DallAgnol
Scio e Diretor tcnico da MTM Sistemas Ltda

Formao:
Curso tcnico de contabilidade Segundo grau (Toledo-PR);
Graduao: Bacharelado em Economia (Unioeste Toledo-PR);

Curso Tcnico: Formao de programadores (GSI/IBM);

Ps-Graduao: Administrao de Redes e Sistemas Distribuidos (FESP

Curitiba-PR);
Ps-Graduao: Gerenciamento de Projetos (SENAI Curitiba-PR);
MBA: formao de empresrios e Dirigentes (ISAE/FGV Curitiba-PR);
Mestrado: Engenharia de Produo Sistemas e Logstica (PUC/PR CuritibaPR).

Sumrio

Experincia prossional

01

Projeto 1: Informatizao da area de Comrcio Internacional (Cooperativa Agricola)

02

Projeto 2: Upsizing de sistema (Distribuidora de Medicamentos).

04

Projeto 3: Downsizing (Indstria)

06

Projeto 4: Desenvolvimento de um ERP (Software House)

09

Projeto 5: Reengenharia de Sistemas (Auditoria de tecnologia em sistema de Banco)

10

Projeto 6: Unicao de Grupo Empresarial (Indstria / Consultoria)

12

Projeto 7: Manter o controle durante um assalto (Distribuidora de Medicamentos)

14

Projeto 8: Migrao de sistema (Software House)

17

Projeto 9: Reengenharia de Sistema (Transporadora)

19

Projeto 10: Reengenharia de sistema (Software House)

22

Dicas para desenvolvimento de projetos

24

1) Dimensionamento Limitar o que ser feito e o que no ser feito

26

2) Planejamento Prazos e Equipe

28

3) Comunicao Unica em nome do grupo

31

4) Documentao O Que deve e o que no precisa documentar

33

5) Padronizao Produtividade e manutenes futuras.

35

6) Envolvimento - Conhea e Interaja com sua Equipe

38

7) Motive e melhore o comprometimento da equipe

41

8) Marketing - Proporcione visibilidade rea e aos prossionais de TI

44

9) Gerencie os Conitos e Administre as Perdas

46

10) Adote e use uma metodologia

49

Experincia prossional:
Apesar de ter comeado minha vida profissional muito cedo (aos 14 anos), somente
ingressei no mercado de TI aos 21, porm esses 7 anos que atuei em funes como auxiliar
de servios gerais, balconista de farmcia, gerente de farmcia e gerente de compras de
uma pequena rede de farmcias, tambm foram importantes para agregar conhecimentos que mais tarde tornaram-se muito uteis para entender o funcionamento das empresas
e facilitaram o entendimento das necessidades dos usurios na hora de informatizar
processos de negcio.
A oportunidade de ingressar na area de TI ocorreu quando eu estava finalizando a faculdade de economia e buscava novos desafios. Tomei conhecimento de que uma cooperativa da cidade onde eu estudava, estava promovendo um concurso onde os primeiros
colocados ganhariam um curso de programao de computador e esse curso seria ministrado pela empresa que na poca era a mais conceituada do mundo na rea de informtica, (a IBM) e os alunos com melhor aproveitamento seriam contratados como funcionrios da cooperativa. Passei no concurso, fui um dos selecionados e ao final do curso fui
contratado como programador.Passados 2 anos como programador, fui promovido a
DBA (Administrador de bancos de dados), funo que exerci por mais 2 anos at sair da
empresa para trabalhar no meu primeiro grande projeto de reengenharia de sistemas,
projeto este que abriu as portas para participar em muitos outros projetos de desenvolvimento, redesenvolvimento, reestruturao e integrao de sistemas.

01

Projeto 1: Informatizao da area de Comrcio Internacional

(Cooperativa Agricola)
O primeiro projeto que tive oportunidade de participar, foi possivelmente o maior fracasso entre todos os projetos, pois a no concluso o mesmo, ocasionada por diversos fatores, representou a falncia de uma empresa com aproximadamente 3000 funcionrios.
Nesse projeto, o objetivo era automatizar o processo de comercializao de uma cooperativa agrcola, processo esse que envolvia a gesto de contratos de venda de soja e algodo
principalmente com o mercado externo.
Apesar da area responsvel pelos contratos internacionais movimentar centenas de
milhes de dolares anuais, todo o processo estava concentrado em uma nica pessoa que
seria o usurio chave do projeto. Coincidentemente essa pessoa, apesar de ser mais velho
que eu, havia sido meu colega de faculdade em algumas disciplinas que ele havia ficado
em dependncia. J na poca de faculdade, esse senhor ignorava os demais alunos e tinha
um comportamento que deixava a impresso que ele se julgava superior aos demais.
Minha participao nesse projeto foi como programador, enquanto eu participava da
equipe que estava criando a estrutura do sistema e os cadastros, outra equipe 'tentava'
fazer os levantamentos e a anlise dos processos especficos da area de comercializao.
Eu me lembro que o projeto foi iniciado e somente conseguiram agendar a primeira
reunio com o usurio chave do projeto para depois de 45 dias. Na data da reunio ele
alegou que tinha compromissos e a reunio foi reagendada e novamente reagendada e
novamente reagendada.

02

Passado algum tempo minha equipe finalizou o que era possvel fazer com as informaes
que tinhamos, como eu tinha me destacado na programao e no havia mais o que fazer
porque no conseguiam avanar nos levantamentos de processo, fui realocado na area de
administrao de banco de dados como DBA junior, saindo do projeto, o restante da
equipe continuou tentando sem sucesso, conseguir com o usurio as informaes necessrias para concluir o projeto.
Fiquei na empresa durante mais dois anos e at onde tenho conhecimento, as informaes jamais foram passadas. Menos de um ano depois da minha saida, tive a notcia que a
empresa havia decretado falncia. Mais tarde as auditorias identificaram que centenas
de milhes de dolares haviam sido desviados da empresa pela pessoa que deveria fornecer as informaes para informatizar o processo, ou seja, o usurio chave tinha fortes
motivos para no informatizar sua area.
Nesse projeto ficou evidenciada a resistncia de algumas pessoas em fornecer informaes sobre seus processos, dificultando em muito o trabalho da equipe de desenvolvimento. Esse usurio especfico, queria evitar que as pessoas descobrissem que ele estava
desviando dinheiro da empresa, mas, na maioria dos casos, isso acontece porque as
pessoas esto querendo proteger seus empregos, entendendo que enquanto ele for o
nico detentor daquelas informaes, ele insubstituvel e depois que o processo for
automatizado, qualquer um poder fazer seu trabalho e a empresa o substituir por
algum que custe menos.
Quando esse tipo de coisa acontece, se faz necessrio a interveno de algum que tenha
asceno sobre a pessoa que est dificultando o andamento do projeto e se for o caso,
levar o problema at o patrocinador do projeto.

03

Projeto 2: : Upsizing de sistema (Distribuidora de Medicamentos).

O Termo upsizing j est em desuso h pelo menos duas decadas, ento vamos explicar o
que era o projeto: O Objetivo do projeto era migrar um sistema de Super-micro SID 5900
para um poderoso Mainframe 4381 da IBM. Basicamente era reescrever um sistema que
executava em uma determinada arquitetura de mquina proprietria, que havia atingido
o limite de processamento daquele fabricante, para um equipamento de maior porte de
outro fabricante, com outra arquitetura tambm proprietria.
Traando um paralelo entre os equipamentos, poderiamos afirmar sem medo de errar
que estavamos substituindo um computador com a capacidade de processamento de
uma geladeira atual por outro com a capacidade de uma maquina de lavar roupa que
lava e seca.
O objetivo do projeto era reescrever um sistema em cobol com arquivos indexados para
Cobol e CSP com banco de dados relacional (SQL/DS Precursor do DB2).
Apesar da brincadeira comparando a capacididade ridcula dos equipamentos em relao aos computadores atuais, esse projeto foi realmente um sucesso com prazos e oramento cumpridos.
Em funo das limitaes do prprio equipamento em que o sistema antigo era executado, os processos do sistema eram muito enxutos e otimizados, pois o sistema atendia uma
empresa com mais de 1000 funcionrios que administravam uma rede de farmcias com
aproximadamente 100 lojas e tinha tambm uma distribuidora de medicamentos que
atendia outras farmcias e hospitais.

04

Nesse projeto, a estratgia foi agregar novos recursos e novas funcionalidades a um

processo que j era bom e apesar da limitaes do equipamento antigo, funcionava muito
bem.
Vrios fatores contribuiram para o sucesso desse projeto, mas, podemos destacar principalmente:
Integrao da equipe que conhecia os processos de negcio da empresa e o sistema
antigo, com profissionais que conheciam a nova tecnologia;
Acompanhamento de produtividade individual de cada participante e premiao
pelo cumprimento de metas e prazos.
Como todo o projeto, tambm foram identificadas necessidades no previstas no escopo
inicial e ocorreram problemas, mas, tudo foi superado trabalhando em finais de semanas
e feriados para poder cumprir o cronograma e entregar o projeto no prazo acorado.
No entendo que trabalhar finais de semana e feriados seja algo normal. Se houve aumento de escopo, o normal e que seja postergado o prazo da entrega, mas, nesse caso especfico havia uma data para entregar o prdio onde o computador estava instalado e que
dispunha de toda uma estrutura para suport-lo, por isso houve a necessidade desse
esforo adicional para cumprir o cronograma, compensando o aumento de escopo com a
liberao de horas extras.

05

Projeto 3: Downsizing (Indstria)

O Termo Downsizing j est em desuso h muito tempo, era utilizado para descrever
processos de desenvolvimento de sistemas objetivando desativar computadores de
grande porte, reescrevendo os sistemas para serem executados em computadores menores, porm com mais recursos e maior capacidade de processamento.
O objetivo desse projeto era reescrever um sistema Cobol que era executado em um
Mainframe Honeywell-Bull (Computador de grande porte) para ser executado em microcomputadores com arquitetura intel (Linguagem Microsoft Visual basic e banco de dados
MS SQL Server).
Esse projeto, iniciado em 1993, foi um dos primeiros projetos desenvolvidos no Brasil em
arquitetura Client/Server e apesar dos problemas com a tecnologia nova e alguns erros de
abordagem, o projeto foi um sucesso.
Por tratar-se de uma mudana bastante radical, a empresa teve uma srie de preocupaes na preparao do projeto e as aes tomadas antes mesmo do inicio do desenvolvimento, foram fundamentais para que os objetivos fossem alcanados. Entre as principais
aes tomadas, podemos citar:
a) Criao de uma equipe para definir a metodologia e os padres de desenvolvimento;
b) Contratao de especialistas para desenvolver a estrutura do projeto (Camada de
acessos, rotinas de consistncias, padro de interface, etc;

06

c) Desenvolvimento de um projeto piloto usando a nova tecnologia com o objetivo de

validar os padres e os componentes;
d) Treinamento de todos os profissionais que iriam participar do projeto, inclusive
fornecedores.
O principal erro cometido nesse projeto foi a excessiva importncia dada para a equipe
que iria desenvolver o sistema novo e que conhecia a tecnologia, mas no conhecia o
negcio, relegando os profissionais que conheciam os processos de negocio a um papel
secundrio e a manuteno do sistema legado.
Apesar do objetivo do projeto ser o desenvolvimento de um ERP completo, ele foi
desenvolvido em mdulos com equipes
distintas e pouco integradas. A nossa
atribuio era o desenvolvimento do
mdulo financeiro.
Diferentemente das outras equipes, em
funo da experincia em projetos anteriores bem sucedidos, onde os conhecedores do sistema antigo estavam integrados com a
equipe do sistema novo, conseguimos uma participao mais efetiva do analista que
cuidava do projeto antigo, com isso antecipamos a entrega do projeto em mais um de ms
em relao ao prazo previsto (de 9 meses, concluidos em 8 meses).
Todos os outros mdulos cujas equipes julgaram no necessria a participao dos

07

conhecedores do processo existente apresentaram atrasos. Em alguns, a equipe inteira foi

dispensada e o trabalho refeito. Aps a concluso do nosso mdulo, os membros da nossa
equipe foram distribudos entre os demais projetos e as equipes foram reestruturadas,
desta vez com uma participao mais efetiva dos conhecedores dos processos existentes e
com maior integrao entre os vrios projetos.
Apesar do atraso na entrega do projeto como um todo, do aumento de custos em funo
do retrabalho, o sistema desenvolvido ficou muito bom passando a ser utilizado em outras
empresas do mesmo grupo empresarial.
Como pontos negativos desse projeto podemos citar, o fato da equipe do sistema existente
ter sido deixada um pouco de lado no inicio do projeto; Felizmente isso foi reparado a
tempo e os rumos do projeto ainda puderam ser ajustados.
No perodo em que esse projeto foi desenvolvido, muitas empresas tentaram sem sucesso
reescrever seus sistemas, acredito que em grande parte esses fracassos foram motivados
pelo fato de tentarem criar algo totalmente novo. Havia a idia que o negcio das empresas deveriam ser repensados como um todo e as idias antigas precisavam ser abandonadas. Embora hoje ainda existam pessoas que pensem que refazer um sistema repensar
tudo de forma diferente, ns acreditamos que essa abordagem est errada; Ao refazer um
sistema, devemos melhorar o que est bom e repensar apenas o que no funciona mais,
sempre partindo do que j existe.

08

Projeto 4: Desenvolvimento de um ERP (Software House)

Esse projeto foi o embrio da nossa empresa, a MTM Sistemas. ramos trs analistas de
sistemas, sem capital para comear um negcio, mas queramos aproveitar o momento
que o mercado de tecnologia estava passando, com a popularizao da microinformtica e a possibilidade de empresas de pequeno porte, at mesmo pessoas fsicas
terem um computador pessoal. Antes disso, existiam apenas os computadores de grande
porte que custavam centenas de milhares de dlares, restrito a grandes empresas.
No tnhamos como largar os nossos empregos e nos dedicarmos integralmente ao
projeto, nem condies de contratar uma equipe para desenvolv-lo, optamos ento por
um dos scios sair do emprego, contratar um funcionrio para atuar no desenvolvimento
do sistema; Os dois outros scios continuaram trabalhando e com parte de seus salrios
bancando a equipe e trabalhando junto nos finais de semanas e feriados no desenvolvimento do sistema.
Na poca, a concorrncia era pequena e com o que hoje as Startups chamam de MVP Minimum Viable Product ou Produto Minimamente Vivel, foi fcil conseguir os primeiros clientes que permitiram ao sistema evoluir e com pouco mais de um ano desde o incio
das atividades, a empresa conseguiu viabilizar que os outros scios largassem seus
empregos e passassem a atuar em tempo integral na empresa.
O que eu quero destacar nesse projeto que nada fcil, principalmente para quem est
comeando um negcio; Mais difcil ainda quando no h disponibilidade de recursos
financeiros, nesses casos, a superao dos problemas com muito suor, noites em claro e
finais de semanas e feriados dedicados ao projeto.

09

Projeto 5: Reengenharia de Sistemas (Auditoria de tecnologia

em sistema de Banco)
Esse projeto foi realizado em um banco que tinha seus sistemas em uma plataforma que
havia chegado ao limite da capacidade, e isso estava limitando o crescimento da empresa.
O objetivo do projeto era reescrever o sistema em outra plataforma que permitisse a
empresa continuar a crescer e ganhar mercado, a minha atuao foi como auditor, porque
o previsto inicialmente para ser feito em 12 meses, j estava em desenvolvimento haviam
18 meses e sem previso de finalizao.

Durante a auditoria, a primeira constatao foi que a equipe do novo projeto havia isolado a equipe do sistema antigo e estava tentando criar um processo novo totalmente
desvinculado do processo de negcio atual da empresa que funcionava muito bem, exceto
pela limitao do sistema e da tecnologia que estava sendo utilizada.

10

Outra situao que constatamos, foi que a empresa contratada para re-escrever o sistema, era ligada a uma universidade americana de renome internacional que tentava usar
aquele projeto como Case, criando um projeto totalmente orientado a objetos o projeto
havia iniciado em 1996 e a linguagem utilizada - Visual basic 4.0 - no suportava bem o
conceito. Atribumos os problemas do projeto s limitaes e desconhecimento da tecnologia utilizada e dos prprios conceitos, a opo da equipe em faze-lo atravs de arrays
posicionais (indexao), sem serializao dos objetos. Para quem conhece um pouco de
programao j devem ter imaginado os problemas que ocorriam sempre que era necessrio fazer uma manuteno ou incluir um novo campo em um pseudo objeto.
Diante da constatao de que o sistema no atendia aos processos de negcio da empresa, com manuteno extremamente difceis, a nossa sugesto foi pela paralizao do
projeto o que foi prontamente acatado pela empresa.
Nesse caso, identificamos o erro comum em projetos que ignorar o conhecimento das
pessoas que j esto na empresa e conhecem o processo atual. Tambm h uma tendncia
das pessoas de TI em querer usar sempre a tecnologia que est em foco, mesmo sem
entender bem os conceitos.

11

Projeto 6: Unicao de Grupo Empresarial

(Indstria / Consultoria)
Um dos projetos mais emblemticos dos quais participei foi a unificao de um grupo
empresarial composto por 5 empresas que atuavam no mesmo segmento, a princpio em
regies geogrficas distintas, que em determinados locais concorriam entre s.
Cada empresa tinha uma estrutura totalmente independente da outra, com sua prpria
diretoria, contabilidade, financeiro, departamento de projetos e inclusive sistemas de
gesto diferentes. Em comum entre elas, apenas a holding que s controlava e o produto
vendido; Produto este que tinha marcas distintas em cada uma das empresas.
O Objetivo do projeto era unificar tudo, concentrando toda a operao sob uma mesma
diretoria, com um sistema de gesto nico e eliminando 4 sedes administrativas.
A primeira fase do projeto foi analisar qual das empresas estava mais prxima do idealpretendido, para isso foram feitas uma srie de anlises, considerando fatores como:
estgio de maturao dos processos, sistema de gesto utilizado, localizao geogrfica,
facilidade para contratao de mo de obra, etc....
No momento que ficou definido qual das empresas seria usada como base para a unificao, vocs podem imaginar como ficou o clima organizacional nas demais empresas, que
tomaram conhecimento que em pouco tempo muitos perderiam seus empregos.
O projeto demorou em torno de 2 anos para ser concludo e apesar de terem ocorrido
problemas, a transio foi bastante tranquila em funo de uma srie de medidas que

12

foram tomadas para minimizar os impactos, como por exemplo:

Definio de quais reas seriam afetadas, objetivando no gerar ruido nas demais
reas como: Fabricao, Comercial, operao, expedio, etc.
Definio do cronograma das atividades, dando uma viso clara de quando cada
empresa seria incorporada;
Plano de treinamento, premiao e acompanhamento para recolocao dos
profissionais que seriam desligados, mas, estavam dispostos a permanecer na
empresa at o final do projeto.
Tambm foi dado oportunidade a alguns funcionrios para mudar para a cidade
escolhida para ser a nova base da empresa.
O sucesso do projeto foi to grande que, aps
sua concluso, foi usado como base para
unificar as demais empresas do grupo, de
diferentes segmentos de mercado e inclusive
com atuao em outros paises.

13

Projeto 7: Manter o controle durante um assalto (Distribuidora

de Medicamentos)
Essa experincia no exatamente um projeto, mas pude extrair algumas lies que valem
tanto para a minha vida profissional quanto pessoal!
Tudo se passou em um espao de tempo de aproximadamente 3 horas, perodo em que
ficamos refens de um grupo de assaltantes, dentro de uma distribuidora de medicamentos
onde eu estava em consultoria para recuperao de impostos.
Eu j havia trabalhado como funcionrio dessa empresa por mais de 2 anos e conhecia a
maioria das pessoas que estavam no local, no momento que fomos abordados pelos
assaltantes e comunicados que tratava-se de um assalto.
O primeiro caso curioso ocorreu com um colega que sempre andava armado e antes disso,
sempre que havia alguma conversa sobre algo mais srio, que envolvesse algum tipo de
intriga ou confuso, ele fazia o seguinte comentrio: se fosse comigo, meteria chumbo....
No momento em que soubemos tratar-se de assalto e os assaltantes ordenaram nos
conduziram a uma espcie de poro que existia na empresa, usado como refeitrio dos
funcionrios, constatamos que ele estava congelado, completamente paralisado, sendo
necessrio pega-lo pelos braos e levando quase carregado para o local determinado.
No local para onde fomos conduzidos, j estavam as zeladoras do prdio. Em determinado momento, uma delas se desesperou, comeou a chorar e gritar que todos iramos
morrer. Percebi a irritao de um dos assaltantes e levantei o brao, sem movimentos
bruscos, apenas para ser notado por ele. Com ar bastante autoritrio ele me perguntou: o

14

que foi?. Com calma, pedi licena para conversar com a aquela senhora e tentar acalmla. Ento ele me respondeu: Acho bom, seno dou um tiro nessa via!. Me dirigi at ela e
conversei calmamente por alguns minutos e consegui acalm-la.
Ficamos confinados naquele espao por aproximadamente uma hora at sermos chamados para carregar um caminho com os medicamentos que eles pretendiam levar.
Informaram que queriam apenas anticoncepcionais e antibiticos,... comeamos ento a
retirar os medicamentos do depsito e carreg-los em um caminho. Como tratavam-se
de produtos com caixas pequenas ocupando pouco espao no veculo, os medicamentos
acabaram e o caminho permanecia praticamente vazio.
Os assaltantes comearam a ficar irritados, achando que estvamos escondendo alguma
coisa deles, chegaram inclusive a dar uns tapas no Diretor superintendente da empresa.
Nesse momento, eu tive a idia de sugerir a eles que levassem fraldas. Com calma, me
dirigi ao que parecia ser o chefe e argumentei: Fraldas vendem muito bem, porque no
levam fraldas?. Novamente ele foi bastante seco e perguntou: Onde tem fraldas?.
Indiquei para ele que estavam em cima das prateleiras, perguntei novamente se eu poderia subir e retir-las, ele autorizou.
Como as fraldas ocupam muito espao, em menos de 10 minutos o caminho estava
quase cheio com produtos relativamente baratos se comparado a outros medicamentos.
Ento fomos colocados novamente no refeitrio e orientados a no abrir a porta, caso
contrrio, ele que ficaria do lado de fora, atiraria em quem tentasse sair. Passaram uns 20
mintos, ele abriu a porta bruscamente e deu mais uma advertncia para continuarmos
quietos e no tentar sair. Mais ou menos 1 hora sem nenhuma movimentao aparente,

15

decidimos ver se haviam ido embora, percebemos que j no estavam mais no local.
Exceto o diretor superintendente que foi agredido, quando pensaram que ele estava
mentindo, ningum mais sofreu violncia fsica. Eles ligaram no outro dia indicando a
localizao do caminho vazio e at onde tenho conhecimento, os medicamentos que
nunca foram recuparados, estavam segurados. Os assaltantes tambm nunca foram
identificados ou presos.
Nesse episdio, ficou evidente uma situao que tambm ocorre em muitos projetos de TI,
onde encontramos pessoas com marketing pessoal bastante agressivo, mas que nas
prtica no podemos contar.
Outro ponto a destacar est na comunicao, muitas vezes ficamos preocupados ou
milindrados em dar as ms notcias aos patrocinadores de um projeto e somos surpreendidos com a compreenso deles, desde que sejamos honestos e no tentemos engan-los.
Esse projeto tambm teve semelhanas com muitos projetos de TI. A primeira que faltaram alguns cuidados bsicos, o que permitiu aos assaltantes entrar no prdio e praticar o
assalto e o segundo aspecto foi a questo da documentao: da mesma forma que a
grande maioria dos projetos, a documentao somente foi feita no final - nesse caso
especfico, a documentao foi o boletim de ocorrncia.

16

Projeto 8: Migrao de sistema (Software House)

A tecnologia evolui e alguns processos dos sistemas comeam a tornar-se obsoletos, no
necessariamente o sistema inteiro, mas, surgem novas formas de fazer determinadas
atividades e com o avano da tecnologia algumas tarefas podem ser facilitadas e melhoradas.
Cinco anos aps termos criado a verso inicial do nosso ERP, decidimos adotar uma
verso mais nova da plataforma que havamos utilizado para desenvolve-lo e com isso,
poderamos tambm utilizar uma srie de recursos que haviam nessa nova verso.
Tambm decidimos utilizar o projeto para corrigir alguns processos que, com o uso do
sistema no dia a dia, percebemos que no havamos implementado da melhor forma ou
que poderiam ser melhorados.
Um erro que normalmente comete-se nesses projetos que felizmente ns no cometemos,
empolgar-se com os novos recursos da plataforma e engordar demais o escopo do
projeto, transformando-o naqueles projetos enormes e que no acabam nunca.
Nossa deciso acertada foi estabelecer que iriamos atuar apenas no que o sistema j fazia
e as novas necessidades, que por sinal eram muitas, seriam feitas em uma segunda fase,
depois que a migrao e melhoria dos processos j existentes fossem concludas.
Como conseguimos manter o foco e o escopo do projeto sem grandes alteraes, conseguimos cumprir o cronograma; Com os melhores recursos da nova plataforma, ficou muito
mais fcil tratar o back-log.
Na execuo desse projeto, dividimos as atividades em pequenos projetos que iam sendo

17

desenvolvidos e entregues; Dessa forma, comparando com projetos anteriores onde

incluia-se tudo em um projeto gigante, pudemos perceber que muito mais fcil desenvolver as atividades fragmentando um grande projeto em atividades menores, do que pegar
um projeto enorme e querer desenvolve-lo inteiro.
Normalmente em projetos muito grandes,
comete-se o erro de olhar a data final de
entrega, muitas vezes um a dois anos
frente e achar que a data no chegar
nunca, ocasionando um certo relaxamento no inicio do projeto, perdendo um
tempo precioso, que far falta depois. O
Ideal neste caso fragmentar o projeto em
entregas menores,

com prazos mais

curtos, mas, h situaes onde isso no possivel, deve-se ento deixar bem claras as
etapas/fases do projeto assim como definio de datas e focar na entrega da prxima
etapa, no permitindo o relaxamento da equipe.

18

Projeto 9: Reengenharia de Sistema (Transporadora)

Nesse projeto, eu iniciei como lder tcnico da
equipe de desenvolvimento/codificao e j no
incio eu discordava de uma situao atpica em
projetos. No projeto haviam dois gerentes, um era
responsvel pela equipe tcnica e o outro pela rea
de negcios, eles tambm acumulavam a funo de
analistas de negcios.
Todas as reunies eram muito tensas porque eu, vendo os atrasos, pressionava-os para
que fosse colocada uma terceira pessoa para gerenciar o projeto, liberando-os para fazer
os levantamentos dos processos e concluir as especificaes que estavam sob suas responsabilidades.
A insistncia era principalmente porque a minha equipe j havia concludo o desenvolvimento da estrutura do sistema, (Padres de codificao, Camadas de acesso ao banco de
dados, Funes de consistncia, Menu, Controle de acesso, Controle de verso, etc...) e
estava parada aguardando o fechamento do escopo e a liberao dos processos, para
iniciar a codificao das telas e regras de negcio, pois no vamos perspectivas dessas
definies serem concludas.
Uma outra falha grave que eu apontava, que foi responsvel pelo meu desligamento do
projeto, foi discordar dos Gerentes do projeto/Analistas de negcio em relao a abordagem na definio de como os processos seriam no novo sistema.

19

Eles queriam repensar todos os processos de forma diferente do que era feito at ento Achavam que deveriam esquecer o sistema existente; Eu insistia que a base deveria ser os
processos do sistema existente, incluindo novas funcionalidades, que bem ou mal atendiam a empresa at ento. E na minha opinio, deveramos melhorar esses processos pois a
empresa no estava mudando seu ramo de negcio.
O Projeto estava previsto para ser realizado em 18 meses, fui desligado do projeto antes de
completar um ano. O projeto continuou e continuaram com a ideia de refazer tudo, o que
eu julgava errado, Ignorando o que j existia e no era ruim, tambm mantiveram os
dois gerentes de projeto, com eles acumulando atividades de analista de negcio.
Passado mais 30 meses, com gastos 3 vezes maiores que o estimado inicialmente, o
projeto foi abortado, sem um nico mdulo desenvolvido.
Aqui vale aquele velho ditado popular: Cachorro com dois donos morre de fome! Projeto
com 2 gerentes ou processos com mais de um responsvel tambm no andam. Vrias
pessoas podem ser envolvidas em um processo, mas, algum e apenas uma pessoa deve
ser definida com responsvel.
Outra questo importante a ser destacada e que na minha opinio vale para qualquer
empresa que j utiliza um sistema de gesto, mesmo que os sistemas estejam tecnologicamente defasados, a substituio ou o redesenvolvimento do sistema para melhorar os
processos atravs da utilizao dos novos recursos tecnolgicos, proporcionados por
ferramentas mais atuais e no h a necessidade de repensar a empresa como um todo,
decidir que o novo sistema tudo tem que ser diferente se o negcio da empresa no

20

mudou.
claro que nem tudo deve ser mantido exatamente como est, pois se fosse assim, no
justificaria o investimento que est sendo feito em melhorias, mas em geral, se a empresa
est crescendo, sendo lucrativa e ganhando mercado, isso significa que uma parcela
significativa dos processos precisam apenas ser melhorados; no pecado partir do que
j existe sem precisar reinventar a roda.
Nos meus quase 30 anos de atuao na area de informtica, eu nunca via a verso 2 de um
software, sem ter passado pela verso 1. Quando formos reescrever um sistema, porque
no considerar que o que existe a verso 1, trabalhando nela para melhor-lo e dessa
forma criar a verso 2. Alguns mais crticos iro me contradizer dizendo que existe o DB2
(gerenciador de banco de dados da IBM) e nunca existiu o DB1. Realmente no existiu um
gerenciador de banco de dados chamado DB1, mas, o primeiro banco de dados comercial
da IBM se chamava SQL/DS e foi at a verso 1.35 e na sua verso 2, passou a ser chamado
de DB2.

21

Projeto 10: Reengenharia de sistema (Software House)

O Projeto no qual estou trabalhando atualmente o desenvolvimento de uma ferramenta
para auxiliar outras empresas na migrao e redesenvolvimento de sistemas de gesto.
A idia surgiu depois da constatao de que muitas empresas ainda tem sistemas de
gesto desenvolvidos em tecnologias antigas, tem seus ERPs desenvolvidos em linguagens
descontinuadas pelos fabricantes, essas empresas esto tendo dificuldades para migrar
ou reescrever seus sistemas em plataformas atuais, por vrias questes como: Alto custo
do projeto, falta de pessoal qualificado na nova tecnologia, dificuldade para manter dois
sistemas em paralelo por muito tempo, etc.
O objetivo da ferramenta que desenvolvemos, ser auxili-los na migrao/redesenvolvimento, possibilitando maior produtividade aos programadores, tornando os processos mais gieis, reduzindo a curva de aprendizado da equipe na nova tecnologia a ser adotada e reduzindo tempo e os custos envolvidos.
Nesse projeto, conseguimos aplicar muito do que aprendemos com os erros e acertos de
outros projetos em que tivemos a oportunidade de participar. Utilizamos a ferramenta
para reescrever um ERP em Microsoft C# com suporte a vrios gerenciadores de bancos de
dados.
Esse projeto foi diferente dos demais porque no tinha uma equipe dedicada, foi planejado para ser desenvolvido em paralelo com outras atividades da empresa, usando apenas
o tempo ocioso de cada profissional, ou seja, a prioridade era manter o sistema atual em
produo, usando nesse desenvolvimento quem estivesse sem atividades, e ai est o maior

22

problema!
Gerenciar uma equipe que est atuando em mais de uma atividade ao mesmo tempo,
quando as coisas no acontecem, a desculpa de que a primeira atividade no foi feita
porque estava fazendo a segunda e a segunda no foi feita porque estava fazendo a
primeira, vira uma bola de neve.
O artifcio utilizado para conseguir manter o foco da equipe foi definir a manuteno do
sistema que est em produo como atividade prioritria e o desenvolvimento da ferramenta como atividade secundria, com isso, focvamos a cobrana em cima das atividades de produo, mantendo a ateno e a motivao da equipe no segundo projeto,
destacando o aprendizado e a atualizao do conhecimento atravs da oportunidade de
trabalhar com as mais modernas tecnologias do mercado e que estavam sendo aplicadas
no desenvolvimento da nova ferramenta.
O que destacamos nesse projeto a dificuldade para gerenciar equipes que precisam
atuar em mais de uma atividade em paralelo. Muitos tcnicos conseguem administrar isso
muito bem, mas a maioria das pessoas, quando colocados nessa situao acabam no
conseguindo fazer bem nem uma coisa e nem outra. Quando so interrompidas para
fazer outra atividade, muitos no conseguem voltar no mesmo ponto em que estavam,
diminuindo a produtividade e os erros se tornam mais frequentes.

23

Dicas para
desenvolvimento
de projetos

24

Cada profissional de desenvolvimento de software tm um sentimento sobre aquilo

que realmente importa. Alguns profissionais podem achar que o que realmente importa pensar cuidadosamente em todas as decises de design concebveis antes de
implement-las, para outros, o importante a tecnologia a ser utilizada, para outras o
foco est nos processos de negcio e tambm h aqueles que acham que importante
a liberdade para criar e inovar.
Na minha opinio, o maior problema em desenvolvimento de software que as pessoas se concentram em aes individuais e o desenvolvimento de um software envolve
muitos fatores e praticamente impossivel uma unica pessoa ter todas as competncias e conhecimentos necessrios. Isso faz com que qualquer desenvolvimento um
pouco mais complexo, acabe envolvimento muitas pessoas com perfs, conhecimentos
e competncias distintas e por isso, o que realmente importa o trabalho em equipe e
a conduo do projeto de tal forma que possa ser utilizado o potencial mximo de
cada colaborador, proporcionando a cada envolvido as condies para que ele possa
dar o melhor de si em favor da equipe e da organizao.
Na prtica, o que importa a utilidade e a qualidade do produto final e o que pretendemos apresentar a seguir so dicas que acreditamos que possam facilitar o trabalho e a
gesto dos envolvidos em projetos, reduzindo os problemas mais comuns e dessa
forma contribuindo para que os prazos sejam cumpridos, os oramentos sejam
respeitados e a qualidade seja a desejada.

25

Dimensionamento
Limitar o que ser feito e o que no ser feito
Dimensionar o projeto ou definir o escopo alinhar as expectativas do cliente com as
idias dos desenvolvedores. O cliente de um projeto de software tem um conjunto de
problemas que deseja solucionar com o sistema e possui algumas idias sobre que funcionalidades podem resolver esses problemas. Por sua vez, desenvolvedores possuem
conhecimento sobre aspectos tcnicos que influenciam a forma de solucionar o problema
do cliente.
O escopo do projeto a definio do trabalho que deve ser realizado para se obter um
produto ou servio com determinadas caractersticas e recursos. Comece por definir o que
deve ser feito e defina tambm o que no ser feito. Nesse processo, evite utilizar termos
muito abrangentes e que depois possam ser usados para adicionar atividades que no
foram contempladas (no estavam previstas).
comum as pessoas da area de tecnologia se perdem em discusses interminveis sobre
recursos do produto final que o tornariam perfeito, mas, preciso traar os contornos do
projeto e definir uma linha divisria entre o que deve ser feito e o que no deve ser. Por
outro lado, partir de uma descrio genrica e comear a desenvolver, no final, quem
contratou vai achar que est faltando coisa e quem trabalhou para desenvolver, ir achar
que ficou no prejuizo porque fez mais do que estava previsto.
Vamos considerar o exemplo de um projeto de desenvolvimento de um sistema de contas
a receber. Apresentar uma proposta de custo e prazo partindo apenas dessa definio, o

26

desenvolvedor pode entender que a empresa j tem um sistema de vendas atravs do qual
foram captados os pedidos e gerado as notas fiscais, que essas notas fiscais passaram por
um processo de faturamento que gerou os ttulos e o escopo do projeto apenas emitir os
boletos e efetuar e registrar o recebimento dos ttulos considerando juros e multas por
atraso e/ou desconto por pagamento antecipado, mas, quem est contratando pode
entender que para receber preciso vender, faturar e depois de receber. Ainda h a
necessidade de contabilizar as entradas e gerar as informaes de comisses a serem
pagas, etc e se esse entendimento no estiver claramente definido, entendido, documentado e alinhado entre quem est contratando e quem ir desenvolver antes do projeto ser
iniciado, o stress inevitvel.
Outra considerao importante no querer fazer o sistema perfeito logo na primeira
verso. Para no perder tempo em discusses interminveis sobre recursos do produto
final que o tornariam perfeito sem decepcionar o cliente, defina o que ser feito na
primeira verso e o que ficar para ser feito nas verses posteriores.
Para voc no se perder numa lista interminvel de caractersticas da verso 1, uma boa
idia pedir ao cliente que liste s que o que absolutamente essencial. Claro que se
voc der a ele muito tempo para responder, tudo ser absolutamente essencial. No
adianta, temos de ser realistas porque o tempo curto e procisamos escolher s o que
realmente importante. Se escrever cortar como dizem os grandes escritores, a arte de
se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo
de necessidades do cliente.

27

Planejamento
Prazos e Equipe
Definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas
para poder planejar como ser feito e com isso ter uma idia de quando poder ser entregue. O objetivo chegar ao WBS (Work Breakdown Structure), onde temos as unidades de
trabalho com tempo medido em dias ou horas de trabalho. Como regra, uma atividade
deve ocupar entre 8 e 100 horas, nem mais, nem menos.
Nesse contexto, deve ser elaborado um oramento considerando quantas horas de cada
profissional sero necessrias. Veja um modelo simples:
Atividade
Gerenciamento
Anlise

Tarefa 1
8
12

Programao

30

25

Testes /
Documentao

12

Implantao
Total

Tarefa 2 Tarefa n
8
8
18
20

T.Total (h)
24
50

Custo/h
160,00
80,00

Custo
3.840,00
4.000,00

36

91

60,00

5.460,00

12

12

36

30,00

1.080,00

50,00

300,00

64

65

78

168

14.680,00

Montar este modelo essencial para obter uma idia dos custos envolvidos e para isso,
voc precisa saber o custo-hora de cada profissional e estimar o tempo que cada um
gastar no projeto. Depois tambm ser necessrio montar um cronograma relacionando
as atividades aos recursos (profissionais) e assim definir quando cada atividade ir
acontecer.
Na estimativa, considerar apenas o tempo que o profissional estar efetivamente atuando

28

no projeto e nos perodos em que o profissional no est no projeto, deve-se planejar sua
alocao em outras atividades que estaro absorvendo seu custo nesses perodos em que
ele no necessrio no projeto.
Um dos principais cuidados que devem ser tomados no gerenciamento de projetos
manter o seu escopo. Projetos que ficam mudando o escopo durante sua execuo tm
srias dificuldades em cumprir o cronograma e estouram o oramento. O risco mais
comum o escopo ir crescendo a medida que o cliente vai entendendo suas necessidades e
reformulando seus objetivos. Essa situao muito comum e necessrio uma srie de
precaues antes mesmo de iniciar qualquer desenvolvimento, como por exemplo:
- Documentar meticulosamente o escopo do projeto. Este documento resume o que ser
feito, com que caractersticas e com que recursos (funcionalidades) Sempre que possvel
incluir diagramas e informaes de fluxo para que no haja dvidas dos envolvidos sobre
o que ser feito;
- No iniciar o projeto antes de definir o escopo. nada acontece antes que as necessidades
estejam detalhadas e formalmente aprovadas e o cronograma e as funcionalidades
estejam bem definidas;
- Todos os envolvidos devem ter conscincia que aps o escopo do projeto ser fechado e o
projeto ser iniciado, somente ser realizado o que est explicitamente detalhado e o que
no foi mencionado est implicitamente excludo.
- Estratgias e cenrios econmicos mudam, mas no possvel modificar o escopo do
projeto a cada novidade de mercado. Por isso fundamental ter um sistema bem definido

29

de gerenciamento de mudanas.
- raro iniciar e finalizar um projeto sem nenhuma mudana de escopo com incluso de
novas necessidades, por isso necessrio deixar muito claro que novas demandas implicaro em novos custos e antes de aceitar incluir novas necessidades, tambm dever estar
definido quanto ir custar e quem ir pagar a conta.
- comum os clientes de software houses (ERPs
de mercado), tentar convencer o desenvolvedor
a incorporar suas necessidades ao sistema sem
custo, justificando que com aquela funcionalidade seu sistema vai vender muito mais.
Normalmente quando o cliente no est
pagando, ele est muito mais propenso a pedir
coisas que normalmente no pediria e com isso
torna o sistema mais aderente ao negcio dele, mas, acaba por criar problemas para os
outros clientes e que se refletem em problemas para a Software House. Por isso, no faa
nada de graa e mesmo que a empresa resolva absorver parte do custo, defina muito bem
o que a software house est disposta a absorver.

30

Comunicao
Unica em nome do grupo
A Comunicao lida com a necessidade de fornecer informaes aos stakeholders (envolvidos/interessados), com o objetivo de diminuir a resistncia e as barreiras na execuo do
projeto e apia a mudana de cultura, pois alinha o conhecimento dos envolvidos s
mudanas que podero ocorrer, mas, no se restringe a isso, pois quando falta comunicao, os boatos e outras formas de rudos tomam seu lugar. Na falta de verso oficial, ficam
circulando informaes que podem minar a moral da equipe e levantar suspeitas sem
fundamento.
No que se refere ao andamento do projeto, um ponto importante estabelecer um canal
unico de comunicao, evitando dessa forma que determinados membros da equipe
utilizem o projeto para seu prprio marketing pessoal ou para externar crticas a outros
membros da equipe. Nesse sentido, qualquer comunicao relacionada ao projeto deve
ser impessoal e objetiva. Qualquer crtica ou problema de membros da equipe deve ser
resolvida dentro da equipe e no deve envolver pessoas que no podero participar da
soluo do problema.
O gerente de projeto deve evitar a prtica conhecida por "rdio-peo", dando informaes
claras e confiveis sobre o status do projeto. Certamente esta uma rea em que a diplomacia essencial. Se h um problema, o gerente de projetos pode e deve falar sobre ele,
informando que est trabalhando na soluo, e no apenas comunicar que o problema
existe. Problemas sem uma perspectiva de soluo so angustiantes e causam um desconforto na equipe que muitas vezes desnecessrio.

31

A comunicao no se restringe ao fornecimento de status do projeto, mas, tambm

envolve todas as decises de projeto, porque sempre que h a necessidade de envolvimento de vrias pessoas comum ocorrerem divergncias de opinies e as decises sobre
quem dever fazer determinada atividade e como e quando ser feito, devem ser documentadas e comunicadas, pois quando os problemas ocorrerem, pessoas deixarem de
fazer o que deveriam e envolvidos precisam ser responsabilizados, s vale o que est
escrito.
Lembro-se de um gerente que com frequncia falava: o que no est escrito, no foi dito e
embora possa parecer uma contradio, no decorrer do projeto a opinio das pessoas
muda e nessa correria em que vivemos, as pessoas esquecem o que foi conversado ou
decidido, por isso a importncia de documentar e comunicar e quando houver divergncias, vale o que est escrito .
O Ato de documentar importante inclusive para que as pessoas reflitam melhor sobre o
processo e embora durante uma reunio um determinado processo possa ter sido exaustivamente discutido. Ao documentar a soluo, sempre surgem detalhes novos que podem
melhorar ou inviabilizar o que foi discutido e decidido em reunio. Tambm comum que,
embora em uma reunio ocorra o concesso sobre determinado processo, algumas pessoas saiam com entendimentos diferentes porque criaram imagens mentais diferentes e ao
ler um documento ou vendo o desenho de um fluxo em documentos que precisam dar o
aceite, percebam que ocorreu um erro de entendimento.

32

Documentao
O Que deve e o que no precisa documentar
Em atividades de desenvolvimento de software, desperdcio tudo aquilo que, embora
esteja no projeto, no agrega qualquer valor para o cliente ou para o produto final. Esses
desperdcios podem ser facilmente identificveis pela equipe, mas muitas vezes no so
to ntidos, consumindo tempo e recursos preciosos. Um dos problemas mais comuns o
excesso de documentao.
Embora documentar seja fundamental, tudo o que feito em excesso acaba sendo prejudicial e a utilizao de tcnicas para modelagem de processos de negcios, como o fluxograma, diagrama de blocos funcionais de fluxo e/ou diagrama de fluxo de controle, facilitam o entendimento do processo e so mais uteis que descries textuais de processo. Os
diagramas no substitem totalmente as descries textuais, mas, atravs da utilizao de
descries textuais em conjunto com diagramas do fluxo do processo possvel reduzir a
quantidade de documentao e ainda facilitar o entendimento por parte dos envolvidos
fazendo com que todos tenham a mesma viso e ainda gerando assim documentos mais
suscintos e teis.
Em projetos de TI comum a participao de pessoas de diferentes areas com a utilizao
de termos que nem sempre fazem sentido para pessoas de outras areas, mas, os diagramas podem ser considerados uma linguagem universal e com isso, podem ser mais
facilmente compreendidos por pessoas de qualquer area da empresa.
Geralmente feito um grande esforo no incio do projeto para documentar todos os
requisitos do software, porm no momento da implementao muitos requisitos acabam

33

sendo modificados e nem sempre a documentao atualizada. Macro especificaes dos

processos com as linhas gerais do que deve ser desenvolvido e uma maior proximidade do
programador com o analista, permitindo que o programador tire suas dvidas a medida
que elas forem surgindo, pode ser mais til e produtivo que uma especificao em pseudocdigo onde o programador s precisa converter a especificao em linguagem de programao.
Algumas empresas criam especificao de cada uma das telas que sero desenvolvidas,
porm, na maioria dos sistemas em torno de 50% das telas so cadastros simples com as
funcionalidades de incluso, consulta, atualizao e excluso, conhecidos como telas
padro CRUD. No faz sentido ter a uma expecificao para cada uma dessas telas, sendo
que um modelo de dados bem feito juntamente com um documento genrico definindo os
termos gerais e o padro de codificao de telas CRUD suficiente para que qualquer
programador desenvolva o programa, pois a maioria dos programadores que eu conheo
sequer vai se dar ao trabalho de ver a especificao.
Tambm comum em projetos de software, serem criados documentos em que so registrados os conhecimentos obtidos durante o projeto, porm, estes documentos raramente
ou nunca so lidos. Pensar alternativas melhores para manter o conhecimento na empresa pode ser interessante para evitar este desperdcio.

34

Padronizao
Produtividade e manutenes futuras.
Com o amadurecimento do mercado que se torna cada vez mais competitivo e do prprio
usurio final que passou a ser mais exigente, est cada vez mais claro que desenvolver
software de forma profissional um dos grandes desafios.
Uma reclamao frequente dos gestores de TI est relacionada dependncia que possuem em relao a determinadas pessoas para realizar os ajustes no software e que muitas
vezes vem a prejudicar tanto a empresa como o prprio profissional. A empresa fica
atrelada a uma pessoa especfica para fazer a manuteno e o prprio profissional fica
impedido de assumir uma nova funo por causa dessa dependncia para a manuteno
do sistema.
Esse tipo de dependncia muito difcil de ser eliminado e alm do conhecimento de
tecnologia, podemos destacar os seguintes fatores:
Conhecimento das regras de negcio que geralmente no esto documentadas;
Falta de um padro de desenvolvimento;
O Conhecimento das regras de negcio a parte mais complicada de passar de um profissional para outro, pois envolve fatores como: conhecimento do mercado no qual a empresa atua, regras de clculo de impostos e outras particularidades da empresa, mas, isso
pode ser facilitado com a documentao de fluxos e modelagem dos processos de negcio.
O problema que a grande maioria das empresas no tem qualquer documentao e
quando tem, essa documentao est desatualizada. A alternativa reduzir a quantidade

35

de documentos, focando nos processos mais importantes e fazendo um esforo para

manter esses documentos atualizados, considerando inclusive nas estimativas de projeto
o tempo necessrio para isso.
Com relao ao padro de desenvolvimento,
a soluo criar-lo e adot-lo para os novos
desenvolvimentos, garantindo que todas as
novas funcionalidades sigam o mesmo
modelo de codificao e interface, permitindo
que mais pessoas sejam agregadas ao projeto
e proporcionando uma manuteno futura
mais fcil, de forma a reduzir a dependncia
das pessoas que desenvolveram o sistema.
Com um padro criado, h inclusive ferramentas (exemplo: TFS) integradas ao ambiente
de desenvolvimento que podem ajudar a garantir que o padro seja respeitado. A programao orientada a objetos favorece a reutilizao de cdigo e se bem utilizada, tambm
ajuda na padronizao.
Em um primeiro momento, voc pode at estar se perguntando por que se preocupar com
um simples padro de nomes. Quando falamos em projetos de software com vrias
pessoas participando e depois dando manuteno. O controle torna-se importantssimo
para fazer com que todos desenvolvam da mesma forma e voc tenha a possibilidade, a
qualquer momento, de substituir ou agregar mais pessoas ao projeto e essas tenham uma
adaptao mais rpida, pois vo continuar desenvolvendo no padro que j esto acostumados.

36

Uma prtica comum em muitas empresas terceirizar o desenvolvimento de seus sistemas

e muitas vezes cada mdulo fica com estrutura prpria (Menu, Controle de acesso,
Bibliotecas de acesso a banco de dados, rotinas de consistncia e algumas vezes, at o
padro de telas). Para evitar esse tipo de problemas recomendvel que as empresas
dediquem mais tempo na criao de uma estrutura de sistema mais robusta e flexvel e
que possa ser compartilhada entre todos os mdulos e sistemas. A criao e compartilhamento desse tipo de funcionalidade favorece a padronizao, alm de dar maior produtividade e evitar que a cada novo mdulo que desenvolvido, ocorra perda de tempo
recriando o que j existe.
O sistema de gesto no caso de software houses o principal patrimnio da empresa, mas,
mesmo em empresas de outros segmentos, o ERP tem papel fundamental em todos os
processos. Um software mal estruturado e de difcil manuteno compromete a imagem
da empresa perante seus clientes e pode prejudicar inclusive a competitividade no mercado, pois em um mundo globalizado as empresas precisam reagir cada vez mais rpido s
mudanas e o sistemas de gesto o primeiro ponto a ser ajustado. Se a manuteno ou
criao de novas funcionalidades difcil e cara, a empresa corre o risco de ser deixada
para trs por concorrentes que utilizam sistemas com maior flexibilidade e agilidade. A
tecnologia importante, mas, de nada servir se for mal utilizada, se os processos e o
sistema no estiverem estruturados e padronizados.

37

Envolvimento
Conhea e Interaja com sua Equipe
O gerente de projetos exerce um papel fundamental e deve ser o elo de ligao entre todos
os envolvidos no projeto, por isso, destacamos a importancia de que o gerente do projeto
conhea os interesses e as competncias de todos os envolvidos. Imagine como arriscado
contar com um membro da equipe que no est disposto a colaborar. Ele pode ser um
problema mais do que uma soluo dentro do grupo: sabendo disso, melhor substitu-lo
chamando outra pessoa. O conhecimento da equipe tambm fundamental quando h
a necessidade de definir algum processo ou situao nova que foi detectada durante o
desenvolvimento, o gerente do projeto nem sempre pode aguardar a prxima reunio e
por isso precisa saber quem a pessoa mais indicada para esclarecer ou definir o que
fazer, colocando os envolvidos em contato. H tambm ocasies onde os tcnicos se
deparam com situaes e problemas e no sabem o que fazer. Ele deve conhecer as
competncias dos demais membros da equipe que podem auxiliar, evitando que membros da equipe fiquem parados por falta de definies ou por dificuldades tcnicas.
Eu entendo que tudo o que est relacionado ao projeto deve passar pelo gerente do projeto
e sempre que possvel deve-se evitar o contato direto entre os demais membros da equipe.
O gerente do projeto quem sabe, ou deveria saber, o que cada um est fazendo, se pode
ou no ser interrompido e principalmente, quem a pessoa mais indicada para realizar
cada tarefa ou apoiar na realizao dela, com base em competncias e principalmente em
disponibilidade, pois nem sempre a pessoa mais indicada est disponvel para ajudar no
momento que precisamos.

38

Quando comea a ocorrer a interao desordenada entre os membros da equipe sem o

conhecimento do gerente do projeto, comum chegarmos em reunies e levantarmos
problemas que j esto solucionados ou encaminhados, mas, o mais crtico o fato de
profissionais com deficincias tcnicas
ficarem recorrendo o tempo todo a outros
membros da equipe para ajud-lo, atrapalhando a produtividades do restante da
equipe e criando constrangimentos dos
outros profissionais que tero que responder
por atrasos e problemas de qualidade em
suas atividades, motivados por frequentes
interrupes de outros tcnicos. Por isso, a
importncia de conhecer os membros da equipe e no passar atividades que esto acima
das condies do tcnico e quando realmente houver a necessidade de passar, pois
necessrio formar e preparar as pessoas para assumir desafios maiores, j poder contar
com o apoio e acompanhamento de pessoas mais experientes, considerando isso no
cronograma de atividades.
Atividades de desenvolvimento de sistemas so atividades intelectuais e demandam
concentrao das pessoas, por isso, a minha insistncia em evitar que ocorram frequentes
interrupes dos tcnicos enquanto esto desenvolvendo atividades mais complexas e que
demandam raciocnio lgico e criatividade. No que em outras areas isso seja desnecessrio, mas, em desenvolvimento de sistemas, interrupes frequentes e ambiente inadequado atrapalhando o raciocnio, so associados a baixa produtividade e erros de sistema.

39

Um fator importante evitar que pessoas que no participaro da soluo de um problema especfico seja envolvidas nas interminveis trocas de emails que so comuns no nosso
dia a dia e tambm em projetos de desenvolvimento. Se a equipe tcnica que precisa de
concentrao em suas atividades for envolvida, a consequncia a perda de foco e a cada
vez que o profissional interrompe suas atividades para ler e responder mensagens que
nem sempre dizem respeito s suas funes, ela dispersa a ateno e isso leva a queda na
produtividade, alm de erros que muitas vezes podem ser fatais.
Na minha opinio, a funo de um gerente de projetos vai muito alm de definir e cobrar
prazos e apresentar relatrios de andamento. Embora em empresas maiores, um gerente
de projetos atue em vrios projetos ao mesmo tempo e no consiga ter essa proximidade
com a equipe. Nesses casos, normalmente h a funo de coordenador ou lider e ele deve
assumir esse papel de facilitador e elo de ligao entre os membros da equipe e os demais
interessados (stakeholders), envolvidos no projeto.

40

Motive
e melhore o comprometimento da equipe
O desenvolvimento de software diferente da
maioria das atividades humanas pois o resultado intangvel e por isso, muito difcil de ser
mensurado. Em geral, as pessoas trabalham
semanas e at meses antes de apresentar
qualquer resultado analisavel. Se na equipe
houver pessoas desmotivadas e no comprometidas, elas no tero muita dificuldade para
realizar outras atividades no relacionadas ao projeto e as vezes sem qualquer relao
com a empresa, enganando e fazendo o tempo passar sem que nada de til seja produzido. Por outro lado, a tecnologia e os desafios de fazer coisas novas a cada dia proporcionados pela area de TI podem funcionar como motivadores para fazer com que as pessoas se
envolvam e mantenham o foco no projeto.
Por isso, os lideres e gerentes de projetos devem encarar o desafio de motivar e de fazer
sua equipe ter qualidade crescente e para isso alguns fatores so importantes:
a) Selecione pessoas competentes:
Pessoas competentes so pessoas com vocao para a tarefa. H muita gente formada e
pouca gente realmente competente. Para a empresa prosperar, ela precisa de pessoas
talentosas e no apenas de diplomas. Pessoas erradas no lugar errado, contaminam o

41

restante do grupo e j ouvi muitas reclamaes de determinados membros da equipe de

que tinham a sensao que estavam carregando outros nas costas.
b) Tenha uma estratgia de envolvimento para as pessoas:
A frmula da motivao contnua no ambiente de trabalho fazer com que a equipe esteja
motivada e para isso as pessoas precisam ter desafios bem definidos, metas realistas e
recompensas. Quando o que interessa o resultado, quem supera as metas precisa ser
recompensado.
c) Treine as pessoas:
Principalmente na rea de tecnologia onde tudo muda muito rapidamente, as pessoas
precisam ter algum incentivo para conseguirem acompanhando essa evoluo.

diferentes perfs profissionais e alguns tem iniciativa e facilidade para buscar o conhecimento e esses podem ser incentivados atravs de oportunidades de pesquisa e inovao,
outros j no tem a mesma disciplina e muitas vezes precisam de treinamentos formais
para adquirir esses treinamentos. O Importante manter as pessoas sentindo-se teis e
valorizadas pela empresa e em contra-partida, a empresa ter pessoas qualificadas para
realizar suas tarefas.
d) Separe um tempo para as atividades de inovao:
essencial para qualquer ser humano sentir-se valorizado e a oportunidade de participar
e contribuir em projetos de inovao um excelente estimulo para isso. Em qualquer
ambiente de negcios as empresas so cada vez mais obrigadas a inovar e em projetos de

42

TI isso ainda mais exigido, ou seja, as oportunidades de envolver as pessoas em projetos

de inovao so ainda maiores que na maioria dos segmentos, ento devemos utilizar
essas oportunidades para envolver as pessoas, dando a elas a oportunidade de participarem das solues de inovao e dessa forma fazendo com que sintam-se uteis e motivadas.
Muitos gestores preferem substituir os funcionrios antigos por pessoas novas com a
alegao de que precisam trazer sangue novo para oxigenar a organizao, mas, na
realidade apenas uma tcnica para trazer pessoas de sua confiana e eliminar qualquer
foco de resistncia a mudanas. Esse tipo de atitude, alm de descartar profissionais que
detm importantes conhecimento sobre a empresa e seus processos, conhecimentos esses
que poderiam ser muito teis ao projeto, pode tambm causar srios problemas para
pessoas que durante muito tempo dedicaram-se empresa e agora sero descartados no
mercado e encontraro dificuldades para se recolocar. Na minha opinio, por mais que
esses profissionais possam estar desatualizados em relao a tecnologia que ser adotada no novo projeto, mais fcil trein-los na tecnologia que dar aos novos profissionais o
conhecimento sobre os processos de negcio da empresa. Envolver esses profissionais
antigos em um projeto novo e desafiador ser para ele o incentivo que ele precisa para
encontrar a motivao e com a participao na definio do que ser feito, dificilmente
essa pessoa ser um foco de resistncia s mudanas que muitos gestores temem e tentam
evitar.

43

Marketing
Proporcione visibilidade rea e aos prossionais de TI
O objetivo de grande parte dos projetos de TI melhorar os processos da empresa e
facilitar o trabalho de colegas, porm, na maioria das vezes as atividades so realizadas e
no so divulgadas, com isso, perde-se uma oportunidade de dar maior visibilidade
rea de TI perante o restante da empresa.
Estabelecer uma rotina de comunicao das
melhorias e mudanas feitas no sistema
importante para que as pessoas tomem conhecimento das novas funcionalidades, mas,
tambm pode ser usado para promover as
pessoas que participaram do projeto e dessa
forma, levantar a autoestima dos colaboradores.
Na maioria das empresas, j existe a comunicao de paradas para trocadas de verso do
sistema, mas, apenas informam-se datas e horrios que o sistema ficar indisponvel e
perde-se a oportunidade de divulgar o que mudou nessa verso do sistema. Tambm
possvel utilizar essa mesma comunicao para divulgar os envolvidos no projeto e dessa
forma dar um pouco de visibilidade s pessoas da rea de TI e tambm melhorar a moral
do grupo.
O efeito psicolgico de relacionar as pessoas que participaram dos projetos vai muito

44

alm de melhorar a autoestima dos envolvidos, pois tambm pode refletir na qualidade do
trabalho medida que ningum quer ser relacionado a algo que deu problemas e com
isso, todos no projeto sero mais cuidadosos no processo, desde a anlise, passando pela
programao e testes para que o processo entre em produo com mais assertividade e
com isso, todos se preocuparo no apenas com o seu trabalho, mas, tambm com o
trabalho dos demais.
Por outro lado, o gestor dever estar preparado para os casos de membros da equipe com
questionamentos de que na sua viso, determinada pessoa que tem o nome relacionado
ao projeto no colaborou, ou atrapalhou mais do que ajudou e tambm estar levando o
mrito. Mesmo assim, acredito que vale a pena divulgar porque as pessoas se sentiro
valorizadas e tambm sero mais cuidadosas em funo dessa exposio.
Com essa abordagem, as aptides comportamentais dos membros da equipe sero
aperfeioadas, aumentando o comprometimento e melhorando as habilidades para
realizar trabalhos em equipe de todos os envolvidos e as pessoas que querem fazer apenas
o seu papel, se sentiro incomodadas e "convidadas" a mudar ou mudar (de atitude ou de
emprego).

45

Gerencie
os Conitos e Administre as Perdas
No h como prever todos os possveis problemas que podem ocorrer durante o projeto,
mas, possvel preparar-se para que os efeitos e consequncias desses problemas sejam
minimizados.
A adaptao perda de um profissional
importante do projeto pode ser mais fcil se
forem tomados alguns cuidados como por ex:
Realocar um profissional j familiarizado com
o projeto para a funo desempenhada pelo
profissional que saiu e contratar outro para a
funo do que foi realocado. Ao fazer isso, o
profissional que j est familiarizado com a
empresa e seus padres, se adaptar mais rapidamente e mais rapidamente estar
produzindo. Se a mudana representar uma promoo ou oportunidade de promoo,
poder servir tambm como uma nova motivao para esse profissional que j est na
empresa, tornando-o ainda mais produtivo.
O novo profissional contratado para fazer a funo do profissional realocado, tambm
ter uma adaptao mais rpida porque ter algum que conhece o trabalho para consultar e quem pode pedir suporte, reduzindo a sua curva de aprendizado e facilitando sua
adaptao.

46

Quando um novo profissional contratado, natural que durante a fase de adaptao ele
precise da ajuda de colegas que j esto na empresa h mais tempo e isso um dos motivos mais frequente de reclamao de funcionrios mais antigos, e quando uma pessoa sai
outra contratada para assumir o seu lugar e precisa da ajuda de novos colegas que
esto na empresa a mais tempo e ganham menos que ele. Eu mesmo j ouvi muita lamentao de colegas afirmando ironicamente que esto fazendo o trabalho do novo funcionrio e ento devem ficar com parte do salrio dele.
Tambm natural que novos funcionrios, embora possam ter trabalhando em empresas
semelhantes, no conheam os processos de negcio e a cultura da nova empresa. A
apresentao dos valores, viso, misso da empresa, a histria, a estrutura organizacional
que normalmente ocorre quando um novo funcionrio entra nas empresas no suficiente. Tambm no adianta passar um manual desatualizado de 5000 paginas para que o
novo funcionrio leia em um dia, mas, ter um manual com a metodologia e os padres da
empresa um bom comeo e podem ajudar bastante nessa adaptao.
Com relao aos conflitos, algo natural da diversidade humana e fruto das experincias
pessoais de cada individuo e das formas distintas de cada um enxergar uma mesma
situao. A ausncia de conflitos no significa necessariamente que no existem problemas. Entretanto, conflitos tambm proporcionam aos indivduos a oportunidade de
crescimento. Na administrao dos conflitos, o gestor pode simplesmente abaf-los ou
ignor-los, mas, tambm pode transform-los em fonte de ideias novas, medida que
conseguir transform-los em discusses abertas sobre determinados assuntos, permitindo a expresso e explorao de diferentes pontos de vista, interesses e valores.

47

Geralmente os conflitos ocorrem quando uma das partes envolvidas percebe que a outra
frustrou ou ir frustrar os seus interesses e expectativas, dificultando o atingimento de
seus objetivos pessoais e isso normalmente acaba afetando o atingimento dos objetivos
do setor e da empresa como um todo. Nesse contexto o gestor somente consegue agir e
sanar os problemas medida que toma conhecimento da existncia da disputa ou insatisfao, por isso, importante que o gestor tenha uma postura que permita o estabelecimento de um canal de comunicao com seus subordinados de tal forma que eles possam
expor suas insatisfaes e aflies com a expectativa que isso possa se transformar em
aes adequadas e positivas, sem a preocupao de qualquer tipo de represlia ou bronca.

48

10

Adote e use uma metologia

Embora haja quem diga que a melhor metodologia o bom senso, a formalizao e uso de
uma metodologia importante porque permite
evitar prticas que levam ao insucesso de
muitos projetos. Mesmo que a metodologia no
seja nenhuma das difundidas no mercado,
importante documentar as prticas recomendadas pela empresa, definindo as linhas
mestras do processo de desenvolvimento, como os padres, as fases do projeto e o que se
espera como resultado da concluso de cada fase.
O que temos em comum entre todas as metodologias, est a necessidade de documentar,
validar e obter o aceite dos processos nas vrias fases do projeto, pois, quando h problemas ou divergncia de interesses, o que vale o que est documentado e aprovado. Se
nada foi formalizado e houver divergncias no momento de fazer uma entrega, o stress
inevitvel porque ningum quer assumir o erro para no parecer incompetente e para no
ter que arcar com as consequncias.
Em funo da rigidez dos mtodos tradicionais de desenvolvimento de software, muitas
empresas preferem adaptar a metodologia s suas necessidades para deixa-las mais
aderentes aos seus processos e isso valido, pois permite flexibilizar um pouco mais o
processo e com isso quebrar a resistncia de muitos profissionais. Qualquer que seja a
metodologia a ser seguida h a necessidade de manter o controle sobre os recursos que

49

sero utilizados no projeto. Somente com controle possvel ter equipes mais eficientes e
garantir maior grau de acertividade em termos de prazos e custos.
Embora o mercado oferea vrias metodologias, a opo pela metodologia a ser utilizada
deve ser tomada a partir de alguns fatores como: as exigncias de cada mercado em que a
empresa atua, a disponibilidade de mo-de-obra e a cultura organizacional necessria
para adot-la. O tamanho/durao do projeto, a criticidade dos processos envolvidos e a
proximidade com o cliente final tambm devem ser considerados para definir o grau de
flexibilidade da metodologia.

50

Concluso
Embora eu saiba que as dicas que foram expostas nesse e-book no
so novidade para a maioria das pessoas que iro l-lo, acredito que
todos ns precisamos ser constantemente lembrados do que j sabemos para no deixarmos de praticar.
H uma diferena muito grande entre o saber e o fazer, de nada
adianta saber se no aplicamos o conhecimento no nosso dia a dia. E
parece que isso no algo inerente ao momento que estamos vivendo, ou fruto dessa profuso de novas tecnologias e metodologias.
Se abrirmos a Bblia em Joo 13, v. 17. Teremos a seguinte citao: Se
sabeis estas coisas, bem-aventurados sois se as fizerdes..
Baseado nisso, acredito que nosso E-Book ter atingido o objetivo, se
conseguirmos fazer com que essas informaes cheguem ao maior
numero de pessoas para lembr-las do que j sabem e para que
comecem ou voltem a praticar.

51

Diagramao e Design

creative studio

www.preissdesign.com.br

www.mtmsistemas.com.br