0
Planejando sua aplicação - Primeira parte
Projetando sua aplicação - Primeira parte
Tópicos:
- Argumentos a favor do planejamento;
- Coletando os dados necessários;
- Iniciando o planejamento.
Primeiramente, vou defender argumentos a favor da importância de projetar uma aplicação.
Em determinado momento de minha vida já chamei meu professor de TSPD (Técnicas de Sistemas de Processamento de Dados) de "Ultra-Acadêmico", no sentido pejorativo da palavra. Hoje em dia defendo a etapa do planejamento tanto quanto defendo o ajuste fino.
Uma lista ordenada de argumentos a favor da projeção talvez facilite a compreensão:
1 - Você deixará ainda mais longe o fantasma do re-trabalho. Como bem sabemos, re-trabalho significa perda de produtividade (mais especificamente prejuízo), o que torna-o uma verdadeira entidade maldosa-fantasmagórica quando se está do lado interessado em resultados do balcão;
2 - O planejamento facilita a fragmentação de uma grande tarefa em uma árvore, facilitando dessa forma também a tercerização de mão de obra e o trabalho em equipe;
3 - Orienta o desenvolvimento fazendo com que o desenvolvedor/programador não perca o foco de trabalho, bem como consiga traçar/seguir uma linha lógica de produção;
4 - Proporciona uma visão bem mais ampla do projeto de sistema e seu fluxo de informação; Esta vantagem particularmente faz com que o desenvolvedor consiga cercar eventuais erros, bem como criar uma metodologia de trabalho para começar e terminar a aplicação.
Acho que estas vantagens conseguiriam até me convencer em minha época de maior revolta. Garanto que mais argumentos serão identificados por leitores mais atenciosos no decorrer do artigo.
Primeiro passo - Coletando as informações necessárias.
Faça a pergunta "Para que este sistema servirá!?" inúmeras vezes para quem interessa até que esteja certo que sabe perfeitamente a resposta.
Se já existir um sistema rodando e sua função for melhorá-lo, peça uma conta de operador e encontre os pingos nos is das poeiras nos menores cantos escuros da aplicação.
Gaste tempo conversando com usuários do sistema, principalmente os mais velhos e/ou com mais tempo de casa; Eles normalmente têm muito a falar sobre seus problemas e quase em todos os casos pensam em formas de melhorá-lo quando amaldiçoam o programador em seus súbitos de raiva.
Vá até a fonte dos processos e veja-os acontecendo, leia formulários, abra arquivos, converse com as pessoas que estão ligados a eles perguntando-lhes como o fluxo de trabalho poderia ser melhorado.
Tenha certeza que entendeu tudo o que quer sistematizar em suas maiores minúcias antes de iniciar o planejamento. Projetos de sistemas normalmente estão esperando uma falha do projetista para pegá-lo de contra-pé, normalmente quando grande parte do trabalho já foi concluída.
Na maioria dos casos, o trabalho é no mínimo parcialmente perdido. Em todos os casos ele precisa ser adaptado à nova consideração.
Segundo passo - Iniciando o planejamento
Pegue tudo o que anotou sobre os procedimentos manuais que irá sistematizar e faça o esquema da informação circulando entre eles. Faça-o em um programa de flow (se não tiver conhecimento das entidades, faça em papel mesmo).
Um exemplo (pense nisso desenhado)
- A solicitação vai para A, que recebe o papel contendo XY dados e envia para a pilha de papel A1;
- B pega a pilha A1 diariamente e consulta no estoque sobre a disponibilidade de matéria prima. Caso haja suficiente, envia um comunicado para C com as informações XYZ solicitando permissão para cumprir a solicitação;
- C preenche formulários, consulta o histórico de B e verifica se ele tem pendências no momento. Se tiver, agenda a solicitação, notifica cliente, A e B. Se não, notifica B que ele tem permissão e guarda os formulários em um arquivo para fazer estatísticas posteriormente.
Por aí vai.
Ninguém consegue imaginar os procedimentos acima descritos no exemplo na vida real... Nem eu.
Entretanto, ele serviu também para ressaltar a seguinte máxima, que deverá ser sempre lembrada por um Desenvolvedor/Analista/Projetista ao sentar em sua mesa para startar uma aplicação:
"Pior do que não utilizar a informática é utilizá-la para sistematizar uma hierarquia de processos burocrática e ineficaz."
Acabado o esboço do planejamento, leve sua papelada às pessoas responsáveis faça a informação navegar pelo seu esquema, deixando em aberto para as considerações coerentes.
Faça pequenas modificações (isso sempre ocorre) e guarde muito bem seus rabiscos. Eles servirão de referência pelos próximos passos do projeto.
A primeira parte do artigo termina por aqui. Até a próxima.
Estarei à disposição para qualquer consideração.
Um grande abraço.
lmaxcar@yahoo.com.br
No segunda parte deste artigo, abordarei os seguintes tópicos:
- Escolhendo a arquitetura (aqui que entra o PHP);
- Um overview sobre as features de seu projeto;
- Criando o alicerce de sua aplicação.
Tópicos:
- Argumentos a favor do planejamento;
- Coletando os dados necessários;
- Iniciando o planejamento.
Primeiramente, vou defender argumentos a favor da importância de projetar uma aplicação.
Em determinado momento de minha vida já chamei meu professor de TSPD (Técnicas de Sistemas de Processamento de Dados) de "Ultra-Acadêmico", no sentido pejorativo da palavra. Hoje em dia defendo a etapa do planejamento tanto quanto defendo o ajuste fino.
Uma lista ordenada de argumentos a favor da projeção talvez facilite a compreensão:
1 - Você deixará ainda mais longe o fantasma do re-trabalho. Como bem sabemos, re-trabalho significa perda de produtividade (mais especificamente prejuízo), o que torna-o uma verdadeira entidade maldosa-fantasmagórica quando se está do lado interessado em resultados do balcão;
2 - O planejamento facilita a fragmentação de uma grande tarefa em uma árvore, facilitando dessa forma também a tercerização de mão de obra e o trabalho em equipe;
3 - Orienta o desenvolvimento fazendo com que o desenvolvedor/programador não perca o foco de trabalho, bem como consiga traçar/seguir uma linha lógica de produção;
4 - Proporciona uma visão bem mais ampla do projeto de sistema e seu fluxo de informação; Esta vantagem particularmente faz com que o desenvolvedor consiga cercar eventuais erros, bem como criar uma metodologia de trabalho para começar e terminar a aplicação.
Acho que estas vantagens conseguiriam até me convencer em minha época de maior revolta. Garanto que mais argumentos serão identificados por leitores mais atenciosos no decorrer do artigo.
Primeiro passo - Coletando as informações necessárias.
Faça a pergunta "Para que este sistema servirá!?" inúmeras vezes para quem interessa até que esteja certo que sabe perfeitamente a resposta.
Se já existir um sistema rodando e sua função for melhorá-lo, peça uma conta de operador e encontre os pingos nos is das poeiras nos menores cantos escuros da aplicação.
Gaste tempo conversando com usuários do sistema, principalmente os mais velhos e/ou com mais tempo de casa; Eles normalmente têm muito a falar sobre seus problemas e quase em todos os casos pensam em formas de melhorá-lo quando amaldiçoam o programador em seus súbitos de raiva.
Vá até a fonte dos processos e veja-os acontecendo, leia formulários, abra arquivos, converse com as pessoas que estão ligados a eles perguntando-lhes como o fluxo de trabalho poderia ser melhorado.
Tenha certeza que entendeu tudo o que quer sistematizar em suas maiores minúcias antes de iniciar o planejamento. Projetos de sistemas normalmente estão esperando uma falha do projetista para pegá-lo de contra-pé, normalmente quando grande parte do trabalho já foi concluída.
Na maioria dos casos, o trabalho é no mínimo parcialmente perdido. Em todos os casos ele precisa ser adaptado à nova consideração.
Segundo passo - Iniciando o planejamento
Pegue tudo o que anotou sobre os procedimentos manuais que irá sistematizar e faça o esquema da informação circulando entre eles. Faça-o em um programa de flow (se não tiver conhecimento das entidades, faça em papel mesmo).
Um exemplo (pense nisso desenhado)
- A solicitação vai para A, que recebe o papel contendo XY dados e envia para a pilha de papel A1;
- B pega a pilha A1 diariamente e consulta no estoque sobre a disponibilidade de matéria prima. Caso haja suficiente, envia um comunicado para C com as informações XYZ solicitando permissão para cumprir a solicitação;
- C preenche formulários, consulta o histórico de B e verifica se ele tem pendências no momento. Se tiver, agenda a solicitação, notifica cliente, A e B. Se não, notifica B que ele tem permissão e guarda os formulários em um arquivo para fazer estatísticas posteriormente.
Por aí vai.
Ninguém consegue imaginar os procedimentos acima descritos no exemplo na vida real... Nem eu.
Entretanto, ele serviu também para ressaltar a seguinte máxima, que deverá ser sempre lembrada por um Desenvolvedor/Analista/Projetista ao sentar em sua mesa para startar uma aplicação:
"Pior do que não utilizar a informática é utilizá-la para sistematizar uma hierarquia de processos burocrática e ineficaz."
Acabado o esboço do planejamento, leve sua papelada às pessoas responsáveis faça a informação navegar pelo seu esquema, deixando em aberto para as considerações coerentes.
Faça pequenas modificações (isso sempre ocorre) e guarde muito bem seus rabiscos. Eles servirão de referência pelos próximos passos do projeto.
A primeira parte do artigo termina por aqui. Até a próxima.
Estarei à disposição para qualquer consideração.
Um grande abraço.
lmaxcar@yahoo.com.br
No segunda parte deste artigo, abordarei os seguintes tópicos:
- Escolhendo a arquitetura (aqui que entra o PHP);
- Um overview sobre as features de seu projeto;
- Criando o alicerce de sua aplicação.
Comentários:
Mostrando 1 - 10 de 10 comentários
Não pude conter a vontade de participar deste assunto que tanto afeta a todos desta área.....
No levantamento das informações é importante ressaltar que nas entrevistas com usuários não informar coisas que não devem saber, tipo o sistema irá automatizar todo este departamento fluindo melhor as informações e doctos, sobrando tempo para trabalhos + nobres, mas na mente dos usuários isso acarreta em pensamentos tipo pronto dessa vez estamos na rua ou no mínimo corremos o risco disso, Daí a atitude deles é totalmente contra a implantação do sistema e muitas vezes fazem de tudo para não dar certo..
No levantamento das informações é importante ressaltar que nas entrevistas com usuários não informar coisas que não devem saber, tipo o sistema irá automatizar todo este departamento fluindo melhor as informações e doctos, sobrando tempo para trabalhos + nobres, mas na mente dos usuários isso acarreta em pensamentos tipo pronto dessa vez estamos na rua ou no mínimo corremos o risco disso, Daí a atitude deles é totalmente contra a implantação do sistema e muitas vezes fazem de tudo para não dar certo..
06/02/2004 8:59am
(~20 anos atrás)
Parabéns Luiz,
Vc realmente disse tudo !!!!
Por mais que tenhamos feito diversos projetos, sempre somos tentados a encurtar o tempo dos mesmos!!!
E sempre acontece a mesma coisa, torna o desenvolvimento mais lento em virtudes do re-trabalho.
Um abraço e obrigado por dispor de seu tempo para ajudar a comunidade.
Aguardarei os próximos capitulos.
Leonil
Vc realmente disse tudo !!!!
Por mais que tenhamos feito diversos projetos, sempre somos tentados a encurtar o tempo dos mesmos!!!
E sempre acontece a mesma coisa, torna o desenvolvimento mais lento em virtudes do re-trabalho.
Um abraço e obrigado por dispor de seu tempo para ajudar a comunidade.
Aguardarei os próximos capitulos.
Leonil
31/01/2004 9:09am
(~20 anos atrás)
Caro "Shadow",
Você levantou um ponto muito interessante... Acredito que o tema vale alguns comentários.
Concordo plenamente quando afirma que uma consultoria não deve "comportar-se como um empregado"; Aliás, se esta fosse a postura desenvolvida por um(a) Consultor(a, ia) o propósito profissional para sua existência não estaria sendo eventualmente desconsiderado?
A questão é que vejo diferença entre "agregar valor" ao produto e estimular devaneios gratuitos sobre funcionalidades não previstas. Interesses de Gerentes de relacionamento e de Desenvolvimento devem estar absolutamente integrados antes de qualquer interação com o cliente.
Se o profissional responsável pelo atendimento/relacionamento plantar determinadas projeções absurdas sobre funcionalidades de uma aplicação que já foi escopada pelo departamento de produção, certamente problemas acontecerão futuramente. Normalmente o Desenvolvedor precisa dar um jeito (re-trabalho, café+coca, estouro de prazo) para enfiar um pé 44 em um sapato 38. O problema agrava-se proporcionalmente à incrementação de pés número 44.
Então, concluo acreditando que a imaginação do cliente e do Gerente de relacionamento dever serem estimuladas somente na etapa de Planejamento do Projeto. Lembrem-se sempre dos sapatos número 38!
Agradeço muita sua participação, Shadow.
Um grande abraço.
Você levantou um ponto muito interessante... Acredito que o tema vale alguns comentários.
Concordo plenamente quando afirma que uma consultoria não deve "comportar-se como um empregado"; Aliás, se esta fosse a postura desenvolvida por um(a) Consultor(a, ia) o propósito profissional para sua existência não estaria sendo eventualmente desconsiderado?
A questão é que vejo diferença entre "agregar valor" ao produto e estimular devaneios gratuitos sobre funcionalidades não previstas. Interesses de Gerentes de relacionamento e de Desenvolvimento devem estar absolutamente integrados antes de qualquer interação com o cliente.
Se o profissional responsável pelo atendimento/relacionamento plantar determinadas projeções absurdas sobre funcionalidades de uma aplicação que já foi escopada pelo departamento de produção, certamente problemas acontecerão futuramente. Normalmente o Desenvolvedor precisa dar um jeito (re-trabalho, café+coca, estouro de prazo) para enfiar um pé 44 em um sapato 38. O problema agrava-se proporcionalmente à incrementação de pés número 44.
Então, concluo acreditando que a imaginação do cliente e do Gerente de relacionamento dever serem estimuladas somente na etapa de Planejamento do Projeto. Lembrem-se sempre dos sapatos número 38!
Agradeço muita sua participação, Shadow.
Um grande abraço.
30/01/2004 8:26am
(~20 anos atrás)
Olá, gostei do artigo, e só tenho a dizer que: por mais que seja ruim prometer mundos e fundos ao cliente, é importante você dizer algo que o cliente goste de ouvir. Agregar valor ao produto que está sendo vendido é sempre melhor do que fazer apenas o que o cliente manda.
Quando o cliente contrata uma consultoria para desenvolver seu software, ele espera que esta seja sua parceira, ajudando ele a enxergar e melhorar os processos com a ajuda da informática. Mas se a consultoria fica apenas como um "empregado" que só faz o que eles mandam, então é certo que o cliente nunca mais vai te procurar para os proximos projetos.
T+
Quando o cliente contrata uma consultoria para desenvolver seu software, ele espera que esta seja sua parceira, ajudando ele a enxergar e melhorar os processos com a ajuda da informática. Mas se a consultoria fica apenas como um "empregado" que só faz o que eles mandam, então é certo que o cliente nunca mais vai te procurar para os proximos projetos.
T+
27/01/2004 10:39am
(~20 anos atrás)
Muito bom o artigo.. eu programo a 2 anos e agora que comecei a desenvolver projetos de verdade (antes só fazia uns scripts aqui, outros ali), e sempre li sobre a necessidade de se projetar, mas nunca obtive informações detalhadas.
Vou aguardar o próximo artigo, que me ajudará também nos próximos semestres da faculdade. :)
obrigado e parabéns, Luiz.
Vou aguardar o próximo artigo, que me ajudará também nos próximos semestres da faculdade. :)
obrigado e parabéns, Luiz.
26/01/2004 2:49pm
(~20 anos atrás)
Caro Marcelo,
Agradeço muitíssimo seus elogios e parabenizações. Comentários como estes são acima de qualquer coisa motivação para mais contribuições à comunidade.
Postei este artigo pois imaginei que minhas experiências poderiam adicinar conteúdo à montanha de conhecimento produzida. Com certeza a maioria do público do PHPBrasil já passou ou vai passar por uma situação similar.
Sobre seu comentário, acredito também que a interface cliente-aplicação deve sempre ser composta por alguém envolvido diretamente à produção.
Um abraço.
Agradeço muitíssimo seus elogios e parabenizações. Comentários como estes são acima de qualquer coisa motivação para mais contribuições à comunidade.
Postei este artigo pois imaginei que minhas experiências poderiam adicinar conteúdo à montanha de conhecimento produzida. Com certeza a maioria do público do PHPBrasil já passou ou vai passar por uma situação similar.
Sobre seu comentário, acredito também que a interface cliente-aplicação deve sempre ser composta por alguém envolvido diretamente à produção.
Um abraço.
25/01/2004 9:52pm
(~20 anos atrás)
Quem já esteve a frente de um projeto de grande porte saberá dar valor ao artigo.
Realmente este talvez seja o melhor artigo do nosso site.
Só um comentário adicional..
Como colocaram ai de promessas maravilhosas que o seu sistema irá fazer, em muitos casos apresentar o sistema ao cliente (e ai digo o projeto) não fica a cargo do programador e sim de alguma outra pessoa (vamos mais longe, provavelmente alguém que não saiba como funciona patavinas de uma linha de código) e dai é que nascem as promessas...
E ai.. era uma vez!
Novamente parabéns pelo artigo, aguardo ai os próximos !
Realmente este talvez seja o melhor artigo do nosso site.
Só um comentário adicional..
Como colocaram ai de promessas maravilhosas que o seu sistema irá fazer, em muitos casos apresentar o sistema ao cliente (e ai digo o projeto) não fica a cargo do programador e sim de alguma outra pessoa (vamos mais longe, provavelmente alguém que não saiba como funciona patavinas de uma linha de código) e dai é que nascem as promessas...
E ai.. era uma vez!
Novamente parabéns pelo artigo, aguardo ai os próximos !
23/01/2004 2:23pm
(~20 anos atrás)
Jayr,
Você levantou uma questão muito importante no processo de produção de um sistema, sobre a qual tenho algumas considerações complementares.
Recomenda-se que o Desenvolvedor/Projetista/Programador tenha uma idéia clara do sistema funcionando antes de conversar diretamente com as pessoas envolvidas (usuários).
Vejo duas formas de deixar usuários frustrados, as quais podem ser tranquilamente cercadas e evitadas:
- Não cumprir as promessas maravilhosas declamadas no período de coleta de dados (isso acontece normalmente quando a pessoa que vai até o núcleo de processos não tem experiência de contato com o público, e sob pressão dos usuários assume compromissos que não conseguirá cumprir depois... Neste caso não é uma boa idéia soltar o programador no cliente sozinho);
- Trabalhos incompletos, sistemas imperfeitos, charlatanismo de qualquer tipo.
Acredito que se a estrutura de procedimentos for reformulada pelo projetista e se as eventuais mudanças trouxerem ganhos palpáveis a quem paga a conta (aumento da produtividade, redução da propabilidade de erro, aumento das possibilidades de auditoria e controle), não haverá usuários frustrados para jogar pedra.
Sua frase serve sempre:
"Saiba trabalhar com pessoas além dos computadores"
Agradeço seu comentário.
Você levantou uma questão muito importante no processo de produção de um sistema, sobre a qual tenho algumas considerações complementares.
Recomenda-se que o Desenvolvedor/Projetista/Programador tenha uma idéia clara do sistema funcionando antes de conversar diretamente com as pessoas envolvidas (usuários).
Vejo duas formas de deixar usuários frustrados, as quais podem ser tranquilamente cercadas e evitadas:
- Não cumprir as promessas maravilhosas declamadas no período de coleta de dados (isso acontece normalmente quando a pessoa que vai até o núcleo de processos não tem experiência de contato com o público, e sob pressão dos usuários assume compromissos que não conseguirá cumprir depois... Neste caso não é uma boa idéia soltar o programador no cliente sozinho);
- Trabalhos incompletos, sistemas imperfeitos, charlatanismo de qualquer tipo.
Acredito que se a estrutura de procedimentos for reformulada pelo projetista e se as eventuais mudanças trouxerem ganhos palpáveis a quem paga a conta (aumento da produtividade, redução da propabilidade de erro, aumento das possibilidades de auditoria e controle), não haverá usuários frustrados para jogar pedra.
Sua frase serve sempre:
"Saiba trabalhar com pessoas além dos computadores"
Agradeço seu comentário.
20/01/2004 9:18pm
(~20 anos atrás)
Vamos com muita calma no que você esta colocando aqui.
Uma das coisa que mais faço hoje, é pegar serviços que foram iniciados por uns, avaliá-lo, joga-lo fora e recomeçar tudo.
O porque isso aconteçe esta exatamente na colheta de dados, onde as pessoas que entendem tudo de informática e não manjam nada de pessoas, sairam passeando pela empresa colhetando dados e levantando expectativas maravilhosas nos futuros usuários frustados.
Veja bem, as pessoas que utilizarão seu sistema, já trabalham no serviço a anos ou decadas e, para eles desse modo funciona. Quando você vai colhetar os dados, eles passam o que pensam e esperam um milagre. Se você não souber parar este fenômeno, seu serviço será perdido pois, por melhor que seja seu sistema, ele nunca fará o que os usuários esperam.
ENTÃO: Ao passear pela empresa e fazer seus levantamentos, saiba trabalhar com pessoas além dos computadores SENÃO...
Uma das coisa que mais faço hoje, é pegar serviços que foram iniciados por uns, avaliá-lo, joga-lo fora e recomeçar tudo.
O porque isso aconteçe esta exatamente na colheta de dados, onde as pessoas que entendem tudo de informática e não manjam nada de pessoas, sairam passeando pela empresa colhetando dados e levantando expectativas maravilhosas nos futuros usuários frustados.
Veja bem, as pessoas que utilizarão seu sistema, já trabalham no serviço a anos ou decadas e, para eles desse modo funciona. Quando você vai colhetar os dados, eles passam o que pensam e esperam um milagre. Se você não souber parar este fenômeno, seu serviço será perdido pois, por melhor que seja seu sistema, ele nunca fará o que os usuários esperam.
ENTÃO: Ao passear pela empresa e fazer seus levantamentos, saiba trabalhar com pessoas além dos computadores SENÃO...
20/01/2004 2:57pm
(~20 anos atrás)
Só queria fazer uma sugestão
Depois de todo este processo e exaustivo levantamento, VALIDEM AS TELAS com as pessoas interessadas
Isso realmente te isenta de uma culpa futura
[]s
e + uma vez parabens pelo artigo, ira ajudar muitos na comunidade