Projeto final com erro

Quando você assume um papel de responsável (gerente, líder ou analista) isto faz parte de suas atribuições.
E realmente nem sempre vai contar com a mesma equipe e pior as vezes pega projetos em que a equipe esta desmotivada. Mas se você aceita o poder de decisão terá a responsabilidade ("com grande poderes grandes responsabilidades").

O que a maioria dos iniciantes não percebeu é que TI abrange muito a questão de relacionamento, administrar pessoas, saber se expressar, entender as pessoas e capacidade de abstração. A parte da codificação é a mais tranquila, por mais complexa que seja, poie envolve a máquina.

Claro que se você quer ficar como programador a vida toda, principalmente júnior, então terá menos responsabilidade e claro salário. Agora de modo geral com a experiência e vivência vem as promoções e claro cobrança.

Qualquer projeto em qualquer área necessita de uma definição de escopo e descrição dos requisitos. Então é importante quem for criar/gerenciar o projeto compreender o que foi pedido e conseguir transformar isto em projeto através de artefatos de área em si (por exemplo: engenharia: plantas, ti: caos de uso e e tc.).

Só como exemplo, de como é difícil nos comunicarmos de forma clara e concisa, no seu próprio post teríamos de definir o que você quiz dize com "erros". Seriam erro nas funcionalidades ou erro de escopo, especificação da infra ou por exemplo o projeto não atende a expectativa do usuário?

Outro detalhe a equipe poderíamos colocar: cliente/usuário, líder do projeto, analista negócio, analista sistema, arquiteto, analista de requisitos, desenvolvedor ou testador.

No fundo codificar é o mais simples, pois é algo mais palpável e além das IDE´s e compiladores exibirem os erro mais básico, na execução podemos verificar se esta funcionando como esperado.

A dificuldade é conseguir extrair do cliente qual a necessidade e sintetizar isto de forma clara, concisa, coesa, confiável e correta.

As vezes pego no pé da galera do fórum por não conseguirem criar um post com um enunciado claro e compreensível, não é o caso do seu post, mas é justamente por ter vivido transtornos com profissionais que não conseguem ter capacidade de se expressar por escrito.

Acho que já é um bom começo. Vamos ver outras opiniões.

Ótimo inicio, descreveu bem todo um processo de desenvolvimento. Vamos aguardar as outras respostas.

Acompanhando, legal a proposta do post.

Poxa, que pergunta!!! Isso vai gerar boas respostas, mas ficarei como espectador e talvez pergunte com o decorrer dos posts.

Ainda aguardando senhores.

Não tenho experiencia, mas todos devem se comprometer com o projeto, quem gerencia, é o gerente de projetos, mas ele não é deus para saber de tudo.

É uma ideia, realmente a culpa não se deve cair em todos, os envolvidos devem fazer o que está pedido/documentado.

Na vida real isso não deve acontecer, alguem assumir os erros, por isso deve-se ter o controle total de todo o projeto, então se sair algo errado a culpa vai para o gerente de projetos. Estou errado?

Sinceramente não sei, mas parece que sim.

Alguem sabe algo sobre a área de gerencia de projetos?

[url]https://brasil.pmi.org/brazil/AboutUs/WhatIsProjectManagement.aspx[/url]

Erros e bugs, por mais que se teste, sempre aparecem quando o projeto vai para ambiente de produção. Isto acontece por que o artefatos (requisitos, caso de uso, roteiro de teste e etc) são mal feitos ou porque algum detalhe ou especificidade passou pela equipe de sistema e usuário/cliente. Então este tipo de erro não é agradável, mas podem ocorrer. Claro que se for algo sério com perda ou atualização indevida de registro ai ferra tudo.

O que é realmente grave é o projeto não atender a expectativa do cliente, a arquitetura definida não suportar a carga de serviço, o projeto não faz o que se propôs entro outros. Se isto acontecer vai ficar feio para toda a equipe de modo geral.

Mas a culpa recai sobre o gerente de projeto, líder de projeto ou analista responsável e não sobre a equipe (alguns projetos não tem gerentes e somente líder outro somente um analista responsável). Afinal o objetivo do gerente/líder/analista é justamente acompanhar o projeto e garantir que os prazos, custos e qualidade sejam mantidos. Então eles devem levantar/detalhar os riscos, fazer reuniões de ponto de controle, levantar;detalhar as contingencias e mitigá-las e garantir que o produto entre esteja dentro dos padrões de qualidade exigidos pelo cliente. Claro que a visão seria mais macro, por isto o gerente/líder/analise deve selecionar uma equipe de confiança, pois não dá para acompanhar tudo no detalhe.

Já vi muito gerente e lideres serem demitidos por fracasso em projetos. A culpa seria somente dele? Não! Mas a equipe foi ele que selecionou e acompanhou então a culpa recai sobre ele. E depois demitir um gerente/líder é menos traumático que demitir toda a equipe.

Trabalhei um projeto enorme de 18.000 pontos de função (cada ponto cotado em 1.000 rais) um equipe de mai de 100 profissionais e foi um fracasso.

E ja trabalhei em projeto que tinha tudo para tudo para dar errado, no caso o cliente não queria o sistema foi imposto pelos superiores dele, mas depois algumas reuniões e acertos deu tudo certo.

E já trabalhei em projeto (controle de licitações) que era ótimo, mas quando da implantação os pregoeiros não quiseram usar e preferiram o pregões presenciais. Os mesmo projeto foi implantado em outro cliente e foi um sucesso.

Então são muitas variantes e tudo pode acontecer, sem você for o ressonável faça tudo para manter a equipe motivada e acompanhe de perto, pois é o seu que esta na reta.

O Gerente meio que fica na corda bamba sempre, por esse lado, nem sempre ele vai pode contar com a mesma equipe, isso sem falar que tambem tem administrar "pessoas", por si só não é nada simples.

Geralmente o gerente de projetos, obrigatoriamente passou pelo desenvolvimento? Exigi-se esse conhecimento técnico?

Um dia queremos ser gerente, mas é um trabalho bem arduo tambem, o que mais me incomoda nessa questão, é que seus resultados dependem do outros, eu imagino a complicação.

Faço das suas palavras a minha, é clichê mas realmente é assim, quem disse que o mundo é justo?

Trabalhando você sempre vai depender dos outros, isto é fato.
Mesmo com freelancer você vai depender do cliente, dos fornecedores e por ai vai.

Em um empresa numa equipe os programadores dependem dos analistas, os analistas do programadores, analista do DBA e as combinações são muitas.

No caso do líder, gerente ou analista responsável eles são pagos para isto e normalmente bem pagos e normalmente tem experiência e algumas regalias.

A uns 25 anos atras trabalhei desde o inicio em um projeto de ponto eletrônico usando Adabas, Natural e PL1. Com a analista responsável saiu o usuário bateu o pé que queria que eu assumisse o projeto e ficasse como líder do projeto. na época eu era programador pleno e na equipe tinha analistas plenos e alguns programadores seniores e no meu caso eu não ganharia nem um centavo a mais. Era um desafio dos maiores, pois alguns integrantes da equipe que tinham cargos e salários maiores que o meu chiaram. Mas aceitei e foi ótimo, pois ganhei muita experiência e posteriormente uma promoção.

Claro se você não esta afim de sofrer pressão e frustrações pode fica como programador ou mesmo analista, depende de como você pretende levar sua carreira.

Mas de acordo com sua experencia, o inicio não foi fácil e nesse caso a oportunidade não bateu na sua porta e sim ela invadiu a sua vida, vc entendeu o que eu quis dizer?
Nesse momento que o cliente bateu o pé dizendo que queria você como lider, você sabia do processo, da função em si?

Neste projeto participei desde do inicio. Só para contextualizar nesta época não havia TCP/IP (na verdade havia mas estava nos primórdios talvez para ARPANet) e no caso os relógios de ponto eletrônicos eram ligados a um Desktop via modem. Este Desktop fazia a coleta dos dados das marcações e utilizando um placa IRMA se conectava ao Mainframe para enviar os dados para o ADABAS (banco de dados).

Como eu tinha boa experiencia com "microinformática", como eram chamados as pessoas que usam microcomputadores, acompanhei o projeto desde do inicio voltado para arquitetura da comunicação relógio/micro/mainframe e principalmente o protocolo de comunicação X25. O sistema foi doado de outra empresa para a empresa em que eu trabalhava mas sem documentação, como eu também conhecia bem de Adabas, Natural e PL1 acompanhei a parte de desenvolvimento.

Então quando a analista saiu eu era a pessoa que conhecia toda a arquitetura além de conhecer todas as funcionalidades do sistema. Por isto o cliente/usuário exigiu que eu fosse o responsável.

Com relação ao projeto em si foi desafiador, mas eu conhecia a parte técnica e as regras de negócio. Quanto a gerenciar uma equipe tive de me virar aprendi na marra. E ainda tinha o problema de gerencia pessoa com cargos maiores que o meu. Só que como viram que eu detinha o conhecimento no final nos entendemos.

O processo de gerenciar vai de conhecer a equipe, ouvir a equipe e usuário, ser claro e transparente, deixar a pretensão e prepotência de lado, não se deslumbrar (vejo muito disto qui no fórum, o camarada faz um "alo mundo" e se acha) e acompanhar de perto o andamento das demandas. No caso a empresa usava uma metodologia para desenvolvimento chamada Oergware, acho que é isto.

Foi duro e complicado, mas valeu mais do que qualquer curso.

Tinha entendido que foi "um tiro no escuro" a sua decisão, mas não, você sabia/conhecia o terreno que estava pisando, mas sem duvida é um desafio sim, gestão é complicado.

Olha passei por esta situação também de dar um tiro no escuro, mas no caso já tinha bem mais experiência.

Era um projeto para automatizaçãode almoxarifado .Net C#, Java, SAP, RFID e coletores de dados que não tinha documentação e a equipe inicial simplesmente se mandou.

Este foi muito trabalhoso, pois a equipe inicial era de 15 pessoas e eu tive me vira comigo, um desenvolvedor e um tester. Fora a complexidade tecnica.

Mas sobrevivi para contar a história.

Nietzsche que era muito sábio já dizia: "Na vida o que não nos mata nos fortalece."

Se você quer mesmo se profissionalizar tem de ter coragem e disposição. Em TI o que mata o profissional é preguiça.

Sábias palavras Jothaz! E Nietzsche também.