Recentemente, fui encarregado de mais tarefas de planejamento de alto nível devido à saída do principal desenvolvedor da minha equipe. Eu odeio planejamento a longo prazo. Meu cérebro simplesmente não parece preparado para isso, e não estou interessado o suficiente para dedicar tempo para aprendê-lo (é difícil o suficiente acompanhar o lado da programação da imagem).
Ainda é possível ser um bom programador sem ser um planejador de alto nível?
Como programador sênior, espera-se que seja bom planejar o produto inteiro e escolher uma data de conclusão?
Respostas:
Os planos detalhados do projeto a longo prazo são notórios por serem geralmente muito imprecisos. A funcionalidade do sistema mudará inevitavelmente antes do lançamento, e as pessoas geralmente passam muito tempo trabalhando nas especificidades que entram na especificação apenas para que os interessados possam dar uma olhada superficial na melhor das hipóteses.
Você deve ler mais sobre o planejamento ágil ; pode achar que ele se encaixa mais na sua mentalidade. Muitas metodologias ágeis tentam encontrar maneiras de se afastar do planejamento detalhado e de longo prazo.
As metodologias ágeis tentam minimizar especificações técnicas e documentação detalhadas em favor do código de auto-documentação e histórias de usuários atômicas isoladas e , finalmente, software funcionando. Em uma equipe Agile eficiente, haverá um tempo mínimo gasto no planejamento.
Leia o Agile Manifesto e veja o Scrum . Use o método de desenvolvimento iterativo e desenvolvimento de sistemas dinâmicos para orientar o projeto.
A principal desvantagem das abordagens ágeis é que você deve admitir abertamente que não conhece o escopo exato do seu projeto , e conseguir a adesão da gerência a essa ideia pode ser extremamente difícil e geralmente leva um tempo. Veja esta pergunta e resposta e este post para obter algumas dicas sobre isso.
No entanto, é certamente verdade que, ao tornar-se um programador mais sênior, você provavelmente fará menos codificação, mas acho que em uma equipe Agile, em vez de significar que você escreve mais especificações técnicas, isso significa que você gasta mais tempo gerenciando e ensinando os membros da sua equipe e a tomada de decisões arquitetônicas sobre o código.
fonte
Sim, é possível. No entanto, se você deseja ser um bom engenheiro ou arquiteto de software, é aí que o seu planejamento de alto nível entra em ação. Para mim, a principal diferença entre um programador e um engenheiro tem sido a capacidade de ver o quadro geral.
fonte
Por um tempo sim. É possível fazer isso por muito tempo? Não.
Atualmente, com muitos empregadores, é procedimento operacional padrão fornecer aumentos competitivos no
custo de vida. Se você não se aperfeiçoar, não tente resolver problemas maiores e mais difíceis, esses aumentos competitivos no setor custarão o preço do mercado em cinco ou dez anos. Continue assim e seu empregador começará a procurar um motivo para se livrar de você, e sua empregabilidade em outros lugares também será drasticamente diminuída.fonte
Claro, você pode ser um bom programador, do ponto de vista de um programador. Do ponto de vista da gerência, há outra questão. Na minha experiência, estar envolvido no processo de planejamento é a melhor maneira de 1) obter tarefas de programação mais interessantes e 2) fazê-las da maneira que desejar.
Em outras palavras, quando se trata de planejamento de curto prazo, muitas opções estão fora de questão. Se a sua solução preferida demorar seis semanas, mas apenas o orçamento duas, você está preso com o que eles decidiram. Se você tiver preocupações sobre algo que eles já discutiram no planejamento de longo prazo, eles não vão querer reformulá-lo.
Se você está feliz com esse estado de coisas, mais poder para você. A maioria das pessoas fica menos satisfeita com a experiência que obtém.
O pequeno segredo sujo é que ninguém é muito bom em planejamento e estimativa de longo prazo. Planejadores melhores são aqueles que estão cientes de suas limitações, então acredite ou não, você está à frente da curva. Obtenha algum treinamento em contabilidade para incerteza na estimativa. Observe técnicas como agendamento baseado em evidências ou scrum, que dependem de dados históricos para mostrar o quão precisas são suas estimativas. Você será mais feliz a longo prazo se tiver uma palavra maior no seu trabalho.
fonte
Resposta curta: Sim, é possível.
No entanto, quanto mais você obtiver experiência com o tipo de projeto envolvido, melhores serão as idéias de planejamento. Idealmente, como programador, temos alguma abordagem sobre como resolver o problema ou procuramos por um. Assim, se conhecermos a abordagem, poderemos começar a pensar no planejamento :)
Outra rota possível é que um programador que se torne um bom planejador também acabe indo para o Gerenciamento de Projetos. Portanto, se você tiver interesse no gerenciamento de projetos, poderá envidar algum esforço extra nessa direção.
fonte
Sim e não são suas respostas.
Por um lado, você está sendo levado para o gerenciamento de projetos. Na IMO, todos os bons programadores têm algum grau de capacidade de gerenciamento de projetos, mas são conjuntos de habilidades diferentes. A capacidade de planejar a longo prazo melhora sua capacidade de se comunicar com o gerenciamento de projeto real. Portanto, "não", você não pode ser um bom programador sem a capacidade de planejar a longo prazo.
Dito isto, o gerenciamento de projetos é um conjunto de habilidades diferentes que agrada a aspectos relacionados, mas diferentes da programação. Então aqui é onde o "sim" entra em jogo. Você não precisa ser um gerente de projetos para ser um ótimo programador.
Para sua situação específica, tente se tornar mais objetivo sobre o que a empresa precisa e o que você gosta de fazer. Há um excesso de ego refletido em sua pergunta e isso influencia sua capacidade de olhar para essa situação. Se você puder encontrar maneiras de contribuir mais para o seu empregador enquanto ainda faz as coisas que gosta, considere-as e converse sobre o assunto com seu chefe.
fonte
Planejamento e o chefe da Bungie
Dilbert tem muitas tiras sobre o chefe da bungie. Nossos desafios e expectativas sobre o planejamento podem ser a causa e o efeito da liderança. Minha experiência em uma empresa da Fortune 100 foi que, em um ano, todos que começaram o ano como líder de projeto saíram. Talvez isso tenha acontecido devido ao problema de planejamento. Não tenho certeza se o seu antigo lead foi embora por esse motivo, mas quando sua função exige que você faça um plano com um compromisso, se ele não ocorrer, geralmente o resultado será uma saída relacionada ao prazo.
Contexto Organizacional do Planejamento
Se você não se sente à vontade com o planejamento, talvez não se sinta à vontade em responder pelos compromissos assumidos com o marketing ou outras partes interessadas antes que os problemas a serem resolvidos sejam documentados ou compreendidos. Este é um bom instinto.
O planejamento é uma ferramenta importante. Não a negligencie. Não entenda mal.
O planejamento está integralmente vinculado a compromissos, responsabilidade e poder de negociação. O planejamento ágil tem muitos méritos. Você deve conhecer suas técnicas, bem como as técnicas das metodologias planejadas. Sua organização pode ter sua própria abordagem, obter conselhos e trabalhar com alguém que sobreviveu à liderança de muitos projetos, e muitos são surpreendentemente úteis.
Um exemplo simples de planejamento - não deve ser sobre software ...
Se uma empresa de coberturas viesse à minha casa para oferecer um substituto, se eles oferecerem muito baixo, poderão perder dinheiro no trabalho, mas se fizerem lances muito altos, não conseguirão o emprego. De qualquer forma, eles estão fora do negócio. Em sua nova função, se você ficar muito baixo, executará o projeto até que a responsabilidade comece, e você terá problemas. Se você estimar um projeto com preenchimento suficiente para garantir o sucesso dentro do prazo, muitos simplesmente escolhem alguém para liderar. O kicker é que você não é como o carpinteiro. Ele pode ver o tamanho do telhado e possui dados históricos sobre quanto tempo esse tamanho leva.
Tornando-se um Planejador Melhor
Você pode considerar algum tipo de treinamento. Nas metodologias ágeis e nas metodologias planejadas mais recentes, a estimativa é uma atividade de toda a equipe. Consequentemente, você deve considerar também receber treinamento para sua equipe.
Por experiência, posso dizer que pode ser frustrante obter estimativas dos membros da equipe que a adiarão, fazer estimativas em dois minutos com base no nome da tarefa, sem referência a um requisito ou descrição de recurso ou ao código existente, ou que insistem em que várias das tarefas que você lista podem ser realizadas em uma fração de dia, mesmo que os projetos anteriores tenham passado semanas em questões semelhantes.
Existem vários cursos e certificações de treinamento para gerentes de projeto, mas eu prestaria atenção em um que fosse credenciado independentemente. Vale a pena pensar duas vezes antes de optar por certificar com abordagens baseadas em metodologias planejadas, se você espera trabalhar com equipes Agile (ou o contrário).
SLIM é um método inventado por Putnam depois de trabalhar na GE e outras empresas em projetos de DoD na década de 1970. O SLIM é influente e sua empresa, QSM, oferece uma certificação que parece fluir de uma ferramenta que eles fazem. Dependendo se sua empresa adotou sua ferramenta, ela pode não ter valor ou alto valor.
Steve McConnell (autor do Code Complete) também escreveu um livro sobre estimativa de software, e sua empresa Construx ministra duas aulas para créditos de PDU credenciados pelo Project Management Institute. Eu tenho o livro dele, e se eu quisesse aprender sobre o tópico via treinamento em sala de aula, provavelmente escolheria o Construx. Eles também fazem treinamento em Scrum e administram várias avaliações de scrum credenciadas através do Scrum.org.
Outra fonte que poderia fornecer excelente treinamento acadêmico sobre estimativa de projetos de software seria o grupo de Barry Boehm na USC , com base em seu extenso trabalho em modelagem de custos construtivos COCOMO e COSYSMO, que tem sido usado na NASA e em outros grandes empreiteiros para estimar projetos muito grandes. Não tenho certeza se sou um verdadeiro crente no COCOMO, mas gosto do trabalho empírico que eles fizeram para correlacionar os efeitos dos fatores de escala e custo na duração do cronograma.
Também encontrei um capítulo de um livro publicado por O'Reilly que discute brevemente os principais métodos de estimativa de software, incluindo Watts Humphreys PROBE e o jogo de planejamento de Kent Beck. O PROBE inclui uma noção de que os engenheiros rastreiam as métricas em sua própria produtividade e as aplicam à parte que lhes foi atribuída em novos projetos. O Planning Game é altamente colaborativo entre desenvolvedores e outras partes interessadas.
fonte