jump to navigation

Cliente em primeiro lugar? 14/06/2012

Posted by Zaratin in Projetos.
Tags: , ,
add a comment

Achei esse texto aqui no Administradores que fala que o cliente não deve ser colocado em primeiro lugar, concordo, sem a menor dúvida.

Sim, o cliente é muito importante para o seu negócio, mas não é mais importante que seus colaboradores. Isso fica ainda mais intensificado no aquecido mercado de TI brasileiro.

Qualidade e prazo combinados com o cliente devem sempre ser uma prioridade das empresas, porém isso não deve estar acima da qualidade de vida dos seus colaboradores, pois se estiver, eles irão embora. Falo isso por experiência, conheço muita gente na área de TI, principalmente em SP e o turnover é um problema grave enfrentado pelas empresas e contorná-lo é responsabilidade dos gestores.

Ou seja, não adianta prometer entregas e prazos para o cliente que você e sua equipe não irão conseguir cumprir com qualidade ou dentro do horário “normal” de trabalho, isso pode funcionar no curto prazo, porém irá trazer problemas muito maiores no longo prazo e aumentar consideravelmente o turnover.

Pretendo escrever em breve um post sobre turnover, custo e curva de aprendizado.

Anúncios

Dicas / Truques #3 para criação de cronograma de desenvolvimento de software (tradução) 13/06/2012

Posted by Zaratin in Desenvolvimento, Projetos.
Tags: , ,
add a comment

O Jean-Baptiste Queru soltou a terceira dica dele, segue a tradução.

Link para o original:

https://plus.google.com/112218872649456413744/posts/9oYqAoSRaR4

Com um pouco de cuidado é possível criar cronogramas razoavelmente precisos para desenvolvimento de softwar. No entando, desenvolvimento não é a única parte/tarefa de
engenharia de software. Debugging (me recuso a traduzir) é um aspecto que toma um tempo significante. Por conta disso, Debugging não pode ser ignorado no cronograma.

O problema é que o tempo de debugging não pode previsto: Se fosse possível saber quais bugs seriam feitos durante o desenvolvimento, esses bugs não seriam feitos.

A única maneira de prever é fazer estimativas brutas, que podem ser lapidadas por uma equipe. Como uma regra, quando estiver planejando o tempo utilizado, o ponto de
inicial é assumir que o tempo de debugging será o mesmo de desenvolvimento. Essa não é uma regra, e a realidade irá variar de acordo com a equipe e produto/projeto,
mas é melhor do que nada.

Quando todo o desenvolvimento for finalizado e o único trabalho restante for o debugging, é possível olhar com mais precisão. Nesse ponto, minha regra de ouro para
ponto de partida é que cada bug leva cerca de meio dia ser resolvido. É importante lembrar do primeiro artigo da série onde analistas não tem 100% do tempo deles
disponível, então não é provável um analista resolver 10 bug em uma semana, e a realidade será próxima de 5 bugs corrigidos por semana.

Para finalizar, bugs são imprevisíveis e diferentes. Se analistas tendem a corrigir os bugs fáceis primeiro, os únicos bugs que irá restar são os difíceis. Para evitar situações onde os bugs mais críticos e sem previsão são deixados por último, é importante fazer a correção de forma balanceada. Hoje, minha tática preferida é gerar um hash com o número do bug e priorizar a ordem ordenando as hashkeys.

Não importa o método, planejar qualquer faze de debugging é imprevisível e imprecisa. A única maneira de melhorar nesse ponto é coletar informação dos ciclos de desenvolvimento anteriores e aplicar nos ciclos futuros com o mesmo time e/ou produto.

Posts futuros nessa série irão falar sobre alocações incertas em grandes equipes e estouros de cronograma.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0

Veja também a parte #1 da série sobre quanto tempo de um analista pode realmente ser considerado no cronograma
https://rzaratin.wordpress.com/2012/05/31/dicas-truques-1-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/

Veja também a parte #2 da série sobre construição de cronogramas quebrando as tarefas em tarefas menores
https://rzaratin.wordpress.com/2012/06/01/dicas-truques-2-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/

Qual a diferença entre SaaS e SOA? 12/06/2012

Posted by Zaratin in Desenvolvimento, Projetos.
Tags:
2 comments

Ultimamente tenho visto muita gente falando sobre SaaS e SOA, mas será que as pessoas que estão usando esses termos tem alguma ideia do que eles são e qual o uso deles? Pelo que andei lendo e conversando com algumas pessoas, muita gente nem sabe o significado real das palavras, apenas joga a sopa de letrinhas. Se você quer trabalhar com TI, mesmo sendo RH ou Vendas, acho essencial para um bom profissional conhecer bem os termos da área.

Em resumo SOA é uma arquitetura de desenvolvimento e deploy que pode ser utilizada no desenvolvimento de softwares. Em geral esses softwares são para uso interno nas empresas e desenvolvidos sob-medida.

SaaS é um modelo de negócio para produtos vendidos sob demanda. Ou seja, em geral são produtos feitos para serem usados na web e sem customização para determinada demanda.

Para quem quiser ler mais à respeito, alguns links

http://pt.wikipedia.org/wiki/Service-oriented_architecture

http://pt.wikipedia.org/wiki/Software_como_servi%C3%A7o

http://software.intel.com/en-us/blogs/2008/08/18/soa-and-saas-whats-the-difference//

http://blogs.msdn.com/b/hanuk/archive/2007/04/08/saas-and-soa.aspx

Fecho o texto pedindo para ninguém confundir SaaS com SAS http://pt.wikipedia.org/wiki/Serial_Attached_SCSI

A situação com o chefe está complicada? Aprenda a “educá-lo” 04/06/2012

Posted by Zaratin in Projetos.
Tags:
add a comment

Achei um texto muito interessante que explica um pouco como devemos educar chefes, sim, somos funcionários e devemos ter nossa vida pessoal e descanso também preservados. Outro ponto interessante e que o brasileiro precisa desenvolver, aprender a dizeR NÃO. É muito importante saber impor os limites e definir priridades. Artigo completo: http://www.administradores.com.br/informe-se/carreira-e-rh/a-situacao-com-o-chefe-esta-complicada-aprenda-a-educa-lo/55751/ Na minha visão uma pessoa é contrata de deve estar disponível naquele horário e isso deve ser regra e não excessão. Se a regra da sua empresa é trabalhar 10h/dia, fim de semana, feriado e afins sem pagar nenhum extra por isso, você está errado e está trabalhando na empresa errada. Não adianta reclamar todos os dias do emprego, do chefe, do colega e não fazer absolutamente nada para mudar isso, o mercado de TI está aquecido e oportunidades não faltam.

Plano de saúde pode ser mantido após demissão 01/06/2012

Posted by Zaratin in Projetos.
Tags:
add a comment

Ja faz um tempo que escuto sobre o assunto, mas agora sai a resolução da ANS. Em resumo, após uma demissão sem justa causa, o funcionário poderá manter o plano de saúde por no mínimo 6 meses e no máximo 2 anos pagando o valor integral do mesmo. Outra regra muito importante é que para ter esse direito, o funcionário tem que ter contribuído no pagamento do plano de saúde.

Mais detalhes e regras nessa matéria:

http://g1.globo.com/concursos-e-emprego/noticia/2012/06/norma-que-mantem-plano-de-saude-demitido-e-aposentado-entra-em-vigor.html

Só não entendo o motivo do funcionário ter que ter contribuído financeiramente com o plano para ter o benefício se ele será pago integralmente pela pessoa após uma demissão. Outro ponto muito importante é que isso não irá afetar o custo de nenhuma empresa.

Dicas / Truques #2 para criação de cronograma de desenvolvimento de software (tradução) 01/06/2012

Posted by Zaratin in Projetos.
Tags: , , , ,
add a comment

O Jean-Baptiste Queru soltou a segunda dica dele, segue a tradução.

Link para o original: https://plus.google.com/u/0/112218872649456413744/posts/hGfwXrURjZD

Em desenvolvimento de software, os detalhes são os grandes vilões. Tarefas que parecem simples em alto nível, geralmente revelam complexidades inesperadas quando investigados os detalhes.

Esse é o motivo de ser impossível estimar o tempo de uma tarefa olhando apenas no alto nível. A única maneira de estimar o tempo é quebrar as tarefas, pequenas o suficiente para serem colocadas na cabeça de uma pessoa.

Além disso, como todo analista é diferente, cada tarefa deve ser estimada pelo analista que irá efetivamente fazer o trabalho. Estimar o tempo de cada tarefa individualmente é parte do design do projeto. *

Outra dica importante é que estimativa de tempo não pode ser feita por apenas uma pessoa, é sempre melhor feita em dupla. Por ter que explicar a tarefa para outra pessoa, o analista que está estimando o tempo diminui a velocidade da tarefa o suficiente para permitir que possa ver detalhes relevantes.

Minha regra de outro é que tarefas precisam ser quebradas até prazos que demorem entre meio dia e dois dias, com granularidade de meio dia. Tarefas com mais de dois dias são complexas demais para serem estimadas. Tarefas também não podem durar menos de meio dia, por conta do tempo que será necessário para compilar o código, instalar, executar os testes e fazer uma revisão do código.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0

* Aqui coloco um comentário meu, muitos analistas tem o costume de estimar para baixo o tempo de conclusão de uma tarefa, achando que assim irão agradar o gerente, o problema é que isso pode gerar diversos problemas como não entrega da tarefa no prazo estimado, o que pode comprometer todo o cronograma do projeto e o trabalho de outros analistas. Nesse caso acho que é interessante sempre ter um analista sênior acompanhando os mais novos.

Veja também a parte #1 da série sobre quanto tempo de um analista pode realmente ser considerado no cronograma
https://rzaratin.wordpress.com/2012/05/31/dicas-truques-1-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/

Turnover pode custar muito caro para as empresas. 31/05/2012

Posted by Zaratin in Projetos.
Tags: ,
add a comment

No dia 24/05/2012 saiu um artigo bem interessante no site da Info. Em resumo o artigo diz que o custo de um funcionário que fica pouco tempo na empresa chega a quase 2,8 vezes o valor do salário. Isso por conta de todos os custos envolvidos na contratação, RH, treinamentos, curva de aprendizado e tudo mais.

Concordo com o que diz o texto, qualquer profissional que chega na empresa demora um certo tempo até totalmente preparado para o trabalho, acostumado com o ambiente. Todas as empresas deveriam se preocupar bastante com o turnover, isso estará diretamente ligado ao cumprimento de prazos e qualidade do serviço.

Recomendo a leitura do original Link para o texto original

Dicas / Truques #1 para criação de cronograma de desenvolvimento de software (tradução) 31/05/2012

Posted by Zaratin in Projetos.
Tags: , , , ,
add a comment

Semana passada recebi um link de um artigo do Jean-Baptiste Queru (Software Engineer do Google) com dicas sobre estimativa de tempo de tarefas, ele fez algo focado em desenvolvimento de software, mas eu acredito que possa ser utilizado para diversos outros fins. Vou deixar aqui uma tradução do artigo.

Parte #1

Quem quiser ler o orginal, segue o link https://plus.google.com/u/0/112218872649456413744/posts/YZZrAbJeqdb

Criar cronogramas para desenvolvimento de software é difícil. Alguns consideram uma arte obscura. Aprendi alguns truques quem tornam o processo um pouco mais preciso. Aqui vai o primeiro truque.

Analistas vão para reuniões. Eles lidam com papelada. Eles fazem entrevistas. Eles treinam novos analistas. Eles preparam apresentaçãoes e demos. Eles participam de apresentação e demos. Eles vão à conferências. Eles apresentam palestras. Eles lidam com fornecedores. Eles lidam com clientes. Eles lidam com usuários. Eles tiram folgas. Eles perdem tempo com builds quebrados. Eles contribuem com alterações de código. Eles configuram suas estações de trabalho e outras ferramentas. Eles fazem manutenção de código de outras versões/tarefas.

Todas essas tarefas são comuns à Analistas . E elas precisam ser levadas em consideração quando o cronograma está sendo preparado. No entendo, elas não devem ser parte da estimativa de nenhum projeto.

Minha dica para criação de cronogramas é considerar que analistas tem cerca de 50% do tempo deles disponvíel para a tarefa que foi programada. A outra metade vai para as tarefas indiretas mencionadas acima. Se uma tarefa para uma pessoas está estimada em 20 man-days, existe uma boa chance dessa tarefa levar cerca de 2 meses para ser finalizada em condições normais de trabalho.

O valor 50% é apenas uma estimativa. Esse valor fica provavelmente entre 40% e 60% na maioria dos casos. Em casos extremos esse valor pode ser acima ou abaixo. No entando, não existe a menor chance de um analista conseguir produzir 1 man-day por dia de trabalho sem que sejam feitas significantes e insustentáveis horas extras.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0