Uma vida, longa ou curta,
É um poema da divindade,
Que transcende absoluto
A mais completa criatividade!
No início tenho tudo que preciso
Tudo que tenho é pouco no final
Mas o que é de fato o final?
Se não o começo de um eterno sorriso!
Em segundos se mede o tempo
Uma flecha que procura um destino
Mas a alma de um senhor menino
Nunca se curva, nem ao tempo!
sábado, 30 de novembro de 2019
quinta-feira, 1 de setembro de 2016
Pensamento 015 - Democracia real é inclusiva
Observando, à distância, a turbulência política da atualidade, espalhada por todo o planeta, chego à seguinte conclusão:
A ALTERNÂNCIA DO PODER PELOS opostos E adversários ACABA REFORÇANDO UM ESTADO DE LOUCURA SOCIAL EM QUE AS PESSOAS SÃO ESTIMULADAS A ESCOLHER UM LADO. PREFIRO A VERDADEIRA DEMOCRACIA, COM TODOS OS LADOS PARTICIPANDO E SENDO RESPEITADOS!
A ALTERNÂNCIA DO PODER PELOS opostos E adversários ACABA REFORÇANDO UM ESTADO DE LOUCURA SOCIAL EM QUE AS PESSOAS SÃO ESTIMULADAS A ESCOLHER UM LADO. PREFIRO A VERDADEIRA DEMOCRACIA, COM TODOS OS LADOS PARTICIPANDO E SENDO RESPEITADOS!
quinta-feira, 27 de outubro de 2011
Pensamento 014 - Gerente de projeto: nem sempre, meu caro!
Muitas organizações tentam garantir que todos os projetos de desenvolvimento de software tenham um gerente com a competência específica de monitorar, controlar e reportar o andamento desses projetos. Contudo, essa "fome" de controle deve ser dosada de acordo com a devida análise de custo/benefício e de riscos associados com a presença ou influência negativa desse controle.
O consagrado Edward Yourdon tem alertado para o fato de que projetos cujo retorno estimado de investimento é baixo costumam exigir muito mais controle (orçamento, prazo etc.) do que os projetos dos quais se espera uma elevada taxa de retorno de investimento.
Nos projetos que valem mais à pena, pelo valor gerado para a organização, será que precisamos mais de um gerente de projeto do que de um lider preocupado com o bom relacionamento dos stakeholders, com a construção de um ambiente que promova o bem-estar, a motivação e o aprendizado das pessoas chave (equipe de desenvolvimento e clientes)?
As empresas mais rentáveis deste século aprenderam a valorizar o capital humano e a adaptar suas estruturas de governança de acordo com a realidade de seus clientes internos e externos. Algumas delas chegaram a investir em consultores de relacionamento interpessoal e em treinadores de equipe (coachs): tudo para potencializar a capacidade das pessoas.
Gerente de projetos: nem sempre, meu caro!
O consagrado Edward Yourdon tem alertado para o fato de que projetos cujo retorno estimado de investimento é baixo costumam exigir muito mais controle (orçamento, prazo etc.) do que os projetos dos quais se espera uma elevada taxa de retorno de investimento.
Nos projetos que valem mais à pena, pelo valor gerado para a organização, será que precisamos mais de um gerente de projeto do que de um lider preocupado com o bom relacionamento dos stakeholders, com a construção de um ambiente que promova o bem-estar, a motivação e o aprendizado das pessoas chave (equipe de desenvolvimento e clientes)?
As empresas mais rentáveis deste século aprenderam a valorizar o capital humano e a adaptar suas estruturas de governança de acordo com a realidade de seus clientes internos e externos. Algumas delas chegaram a investir em consultores de relacionamento interpessoal e em treinadores de equipe (coachs): tudo para potencializar a capacidade das pessoas.
Gerente de projetos: nem sempre, meu caro!
sexta-feira, 2 de setembro de 2011
Sobre o papel do especialista e do generalista na área de TI
Em Dados e usuários acima do hardware e software, há um comentário questionando: "Então os administradores de dados estavam certos?". Esse questionamento me inspirou a expressar minha visão sobre o papel do especialista e do generalista na área de TI (Tecnologia da Informação).
Para prestarmos um bom (ou excelente) serviço de TI, precisamos conhecer nosso cliente e suas necessidades de informação. Se focarmos muito nas questões tecnológicas e não prestarmos a atenção devida ao nosso cliente, poderá ser um pouco dramático quando nos dermos conta de que as necessidades de nosso cliente não estão sendo atendidas por nossa "solução" (vai ver que as necessidades dele mudaram, vai ver que o cliente mudou, vai ver que o mercado já oferece uma solução mais adequada etc.).
No parágrafo anterior, escrevi na primeira pessoal do plural (nós) para dar a noção de uma equipe prestando um serviço de TI e de que "conhecer nosso cliente" é um problema ou necessidade dessa equipe, não necessariamente de um indivíduo ou especialista.
Nesse ponto, já é possível perceber a necessidade de consistência entre a visão geral, externa, e a visão técnica, interna, do(s) serviço(s) a ser(em) prestado(s). O ideal seria que o profissional de TI tivesse tempo e trranquilidade para se dedicar às duas visões. Porém, a realidade das organizações que se beneficiam da TI vem desafiando esse profissional com serviços cada vez maiores ou mais complexos (às vezes, críticos). Nesse contexto, surge então a necessidade de distribuir responsabilidades.
Alocar especialistas (designers de interação, arquitetos de software, programadores, especialistas de teste, especialistas em bancos de dados etc.) parece ser uma solução natural, boa e necessária para projetos de grande porte ou de grande complexidade. Porém, alguns cuidados precisam ser tomados:
E qual o papel do generalista, se é que ele é importante? Na realidade, o sucesso do projeto depende muito da atuação dos generalistas - aqueles que conseguem acompanhar um determinado projeto sob diferentes perspectivas, especialmente sob o ponto de vista externo (cliente e usuários). O bom generalista, sem risco de comprometer sua visão panarômica, deve ter conhecimento e experiência técnicas suficientes para avaliar a qualidade técnica dos produtos entregues e serviços prestados pela equipe. Muitas equipes chamam esse sujeito de coach (eXtreme Programming) ou arquiteto (Unified Process).
Em projetos de pequeno porte, é possível alocar uma equipe pequena próxima ao cliente para, juntos, desenvolverem um novo produto ou serviço de TI. Nesse caso, é melhor que cada membro atue como generalista (ainda que atue como especialista em determinados momentos).
Em projetos que necessitem da alocação de profissionais especializados, convém valorizar e multiplicar os generalistas da equipe para reduzir os riscos que rondam esse tipo de projeto.
Para prestarmos um bom (ou excelente) serviço de TI, precisamos conhecer nosso cliente e suas necessidades de informação. Se focarmos muito nas questões tecnológicas e não prestarmos a atenção devida ao nosso cliente, poderá ser um pouco dramático quando nos dermos conta de que as necessidades de nosso cliente não estão sendo atendidas por nossa "solução" (vai ver que as necessidades dele mudaram, vai ver que o cliente mudou, vai ver que o mercado já oferece uma solução mais adequada etc.).
No parágrafo anterior, escrevi na primeira pessoal do plural (nós) para dar a noção de uma equipe prestando um serviço de TI e de que "conhecer nosso cliente" é um problema ou necessidade dessa equipe, não necessariamente de um indivíduo ou especialista.
Nesse ponto, já é possível perceber a necessidade de consistência entre a visão geral, externa, e a visão técnica, interna, do(s) serviço(s) a ser(em) prestado(s). O ideal seria que o profissional de TI tivesse tempo e trranquilidade para se dedicar às duas visões. Porém, a realidade das organizações que se beneficiam da TI vem desafiando esse profissional com serviços cada vez maiores ou mais complexos (às vezes, críticos). Nesse contexto, surge então a necessidade de distribuir responsabilidades.
Alocar especialistas (designers de interação, arquitetos de software, programadores, especialistas de teste, especialistas em bancos de dados etc.) parece ser uma solução natural, boa e necessária para projetos de grande porte ou de grande complexidade. Porém, alguns cuidados precisam ser tomados:
- É necessário articular e gerenciar o trabalho dos especialistas, pois muitas vezes, e por razões variadas, a eles não é dada a oportunidade de conhecer a realidade dos clientes/usuários dos serviços. Para suprir essa carência de informação, que pode comprometer o projeto como um todo, costuma-se tomar algumas medidas preventivas: escrever e manter especificações (construídas e versionadas por especialistas), realizar reuniões periódicas (para acompanhamento de projeto, para validação de especificação, de protótipo ou de produto etc.) envolvendo o cliente e toda a equipe, inspeção contínua (possivelmente automatizada) dos componentes especializados, entre outras.
- É necessário garantir que as escolhas técnicas de cada especialista sejam compatíveis entre si. A integração contínua é uma forma bastante eficiente de se atingir esse objetivo. Com essa prática, o componente (mesmo que parcial) construído por um determinado especialista é verificado e integrado aos demais componentes disponíveis, se possível várias vezes por dia, todos os dias da semana, durante boa parte do ciclo de vida do produto: desenvolvimento, implantação e operação.
E qual o papel do generalista, se é que ele é importante? Na realidade, o sucesso do projeto depende muito da atuação dos generalistas - aqueles que conseguem acompanhar um determinado projeto sob diferentes perspectivas, especialmente sob o ponto de vista externo (cliente e usuários). O bom generalista, sem risco de comprometer sua visão panarômica, deve ter conhecimento e experiência técnicas suficientes para avaliar a qualidade técnica dos produtos entregues e serviços prestados pela equipe. Muitas equipes chamam esse sujeito de coach (eXtreme Programming) ou arquiteto (Unified Process).
Em projetos de pequeno porte, é possível alocar uma equipe pequena próxima ao cliente para, juntos, desenvolverem um novo produto ou serviço de TI. Nesse caso, é melhor que cada membro atue como generalista (ainda que atue como especialista em determinados momentos).
Em projetos que necessitem da alocação de profissionais especializados, convém valorizar e multiplicar os generalistas da equipe para reduzir os riscos que rondam esse tipo de projeto.
quarta-feira, 31 de agosto de 2011
Pensamento 013
Cada pedaço de software tem um contexto (sistemas, processos,
legislação, riscos etc.). Maturidade requer aprendizado desse contexto.
Receio que muitos, profissionais e acadêmicos de TI, levarão décadas até concluir que a maturidade ou excelência no desenvolvimento de software NÃO pode ser alcançada de forma abrangente (como pregam alguns promotores da certificação profissional). O que ocorre, de forma abrangente, é que a maturidade ou excelência só pode ser alcançada (de forma comprovável) dentro de um contexto/escopo muito específico, como por exemplo: para um determinado sistema, subsistema, componente ou funcionalidade (feature) governado por um determinado conjunto de clientes e mantido por uma determinada equipe técnica com um determinado conjunto de práticas e ferramentas.
Receio que muitos, profissionais e acadêmicos de TI, levarão décadas até concluir que a maturidade ou excelência no desenvolvimento de software NÃO pode ser alcançada de forma abrangente (como pregam alguns promotores da certificação profissional). O que ocorre, de forma abrangente, é que a maturidade ou excelência só pode ser alcançada (de forma comprovável) dentro de um contexto/escopo muito específico, como por exemplo: para um determinado sistema, subsistema, componente ou funcionalidade (feature) governado por um determinado conjunto de clientes e mantido por uma determinada equipe técnica com um determinado conjunto de práticas e ferramentas.
domingo, 26 de junho de 2011
Pensamento 012
As melhores companhias dependem de sua própria reputação.
As medianas dependem de certificações e avaliações.
As medianas dependem de certificações e avaliações.
quarta-feira, 25 de maio de 2011
Pensamento 011
Governança existe para preservar os interesses de quem tem poder.
Profissionalismo existe para preservar os interesses dos demais.
Profissionalismo existe para preservar os interesses dos demais.
Assinar:
Postagens (Atom)
