Como você lida com APIs / tecnologia overhead

Eu acho que a maioria das pessoas já esteve nessa situação.

O planejamento inicial do projeto começa. Os requisitos estão descritos. Após a revisão da arquitetura e a classificação por APIs / Frameworks, a tecnologia de ajuste é escolhida. O desenvolvimento começa.

E então começa. Assim que você precisa fazer algumas coisas supostamente simples de suporte, o framework / API começa a sair pela culatra e, em vez de fazer qualquer trabalho, você acaba lutando contra a tecnologia. O tempo de pesquisa dispara, os fóruns são silenciosos, nada parece ser feito, e mesmo quando você faz algo funcionar, você não tem certeza de que foi feito corretamente.

Como você gerencia nessas situações? Você gosta de hacks, pesquisa mais, o que diz à gerência?

Protótipo, Protótipo, Protótipo !!

Se sua equipe não estiver familiarizada com uma estrutura específica, faça um protótipo de algo para avaliar onde estão os pontos problemáticos.

Matt Raible (responsável pelo comparador de estruturas da Web Java) sugere trabalhar com uma estrutura por uma semana, se possível.

A prototipagem inclui investigar o apoio da comunidade por trás de uma estrutura e outros fatores

Gerenciar dependências externas é a desgraça de muitos projetos de TI. Muitos anos atrás, os programadores experientes com quem trabalhei sempre se certificaram de ter controle sobre suas dependências - geralmente insistindo na compra de licenças de código-fonte.

Pessoalmente, isso não tem sido a minha abordagem. Eu tenho a tendência de ser menos promissora do que entregar uma escola de pensamento. Há momentos em que tive que esticar o pescoço para fora, mas faço pesquisas particulares antes para ter 99% de certeza - geralmente fazendo um projeto privado, muitas vezes no meu tempo, para garantir que a tecnologia possa funcionar. Com efeito, protótipo, teste, valide e prometa.

Há situações em que sou pego de surpresa - e tenho que voltar atrás ou ser criativo. Ter uma mente criativa com ampla experiência ajuda aqui, mas o mesmo acontece com conversar com outras pessoas. - e nem sempre programadores. Às vezes as soluções vêm de lugares muito estranhos.

Como para lidar com a gestão, a chave é a honestidade. Converse cedo e com frequência. Não deixe para o último minuto, pois decepcionar gerentes / clientes no dia anterior a uma grande entrega apenas faz você parecer amadores. Ser capaz de dizer 2 meses antes do prazo que os gerentes precisam escolher entre deixar alguns recursos e / ou adiar o envio pode não ser popular no momento, mas permite que o restante da organização faça seu trabalho e planeje . A chave para ser capaz de fazer isso é ter um bom sistema de gestão de tarefas que rastreia vezes e estimativas de tarefas. Tendo evidência sólida para fazer backup de seu ponto de vista torna muito mais provável para você ser ouvido.

"Como você gerencia nessas situações?" O que eu vi / experimentei:

o ponto 1 que eu concordo com Ptolomeu: seja honesto:

Se for realmente um problema: vá para a sala, conte o problema, sente-se para aguardar a resposta da raiva e depois ... trabalhe em direção a um novo plano / solução. (o cara não está com raiva de você pessoalmente).

Existem cursos de TI que lidam apenas com essa situação. Você é colocado com atores e eles colocam o cliente irritado que ouve essas notícias. Você recebe muitas dicas sobre isso. Parece estúpido, mas provavelmente só depois de fazer isso você percebe o valor disso. Saí com uma folha com 80 pontos para lembrar nessas situações ... (e prática).

Essa situação é típica, provavelmente ainda mais hoje, onde os orçamentos são limitados, as vendas são feitas com a "menor oferta", o planejamento que você deu é cortado 5 vezes antes de ser aceito pelo cliente ... (incluindo o protótipo desde que ele está contratando você porque você é o especialista e, caso contrário, são outras 10 pessoas esperando ") etc ...

- Outra coisa pode ser o pensamento lateral: se não puder ser feito dessa maneira, tente propor algo completamente diferente que ofereça o mesmo valor para o cliente. Se a tecnologia não funcionar de forma alguma / estiver quebrada / sair do negócio / etc ... Se o cliente comprar, poderá fornecer o mesmo valor no final. Mas trazê-lo também é bastante difícil. (para alguns e totalmente não para outros). Você precisa de caras realmente experientes para isso. Uma situação semelhante é que a tecnologia ainda não está pronta ... leva alguns meses ... Portanto, você precisa convencer o cliente a replanejar e aceitar o replanejamento e o impacto em sua organização ...

- Outra 'lição aprendida' é invocar os veteranos assim que você perceber que ela vai nessa direção. Eles geralmente lidam com projetos problemáticos e são realmente úteis nessas situações. Frequentemente, eles viajam apenas de projetos problemáticos para projetos problemáticos.

- Outra lição aprendida é deixar seu material arquitetônico passar por canais de verificação, especialmente em projetos maiores. Uma assinatura pode cobrir sua bunda. (salve todos os seus e-mails LOL)