Latest Post

O “dono” do produto

Como alguns de vocês já sabem, estou desde o final de 2008 no Yahoo!, e junto com uma equipe incrível ajudei a criar o Meme, um novo site de light-blogging que está em versão beta.

Entrei no Yahoo! a convite do Antonio, que acabou me citando nesse post ao explicar um pouco sobre o Meme e como foi desenvolvê-lo usando Scrum desde o começo.

Quero contar pra vocês o que é esta função e como eu vim parar aqui.

Meu papel na equipe é de P.O., ou seja, Product Owner, que traduzindo significa “dono do produto”. O nome é imponente e sugere uma importância crucial, e essa foi mesmo a minha primeira impressão. Mas não é nada ditatorial, o PO tem é a palavra final na priorização das funcionalidades durante o desenvolvimento.

Eu sempre quis implantar métodos ágeis na TV Cultura, onde estava trabalhando antes, e havia começado a estudar o assunto. Mas confesso que não tinha entendido direito o que um PO faz até ler o Agile Estimation and Planning, do Mike Cohn.

Quando recebi o convite para vir pro Yahoo!, o Antonio me disse que fui selecionado por ter “o perfil mais estranho que ele havia encontrado”. Achei graça, mas deve fazer sentido, eu também conheço pouquíssimas pessoas com um perfil similar.

Mas qual é esse perfil? E por que ele se encaixa na função de PO?

Sou jornalista formado, fiz mestrado em engenharia e adoro programar no meu tempo livre.  A multidisciplinaridade sempre me atraiu e por isso acabei – sem perceber – durante toda a vida me preparando para exercer esta função que eu eu nem sabia que iria existir.

Não sou tão bom programador quanto os caras da nossa equipe. Eles me põem no chinelo, fácil. Não sou tão bom repórter quanto meu amigos de redação. O texto deles é muito melhor, sem nem fazer força. Mas sou autodidata e fuçador, atiro para todos os lados. E sempre tive a intuição de que isso – além de ser muito divertido – ia me servir pra alguma coisa no futuro.

E serviu. A função de PO, conforme explicada nos livros, exige um entendimento das pressões externas do mercado, das demandas internas da empresa e do desenvolvimento diário do produto. Em cima de tudo isso, o PO precisa ter uma visão clara do caminho que o produto deve seguir e priorizar as coisas para que essa visão se concretize.

Óbvio que eu não sabia nada disso ao começar, muito menos como era trabalhar em uma empresa multinacional com 15 mil funcionários. Mas fui aprendendo, entendi a lógica do processo e me adaptei sem grandes traumas. Um ano depois, ficou natural transitar entre discussões sobre refatoração de código e iniciativas de marketing. É corriqueiro passar de brigas sobre design de API a apresentações com planejamento para o ano seguinte.

Em um time, ninguém manda em ninguém

Como estou cercado de gente que sabe mais do que eu em suas especialidades, não sou trouxa de sair decretando o que me vem na telha. Em teoria, o PO tem esse poder, mas eu acho bobagem centralizar tanto assim. Sou obrigado a buscar argumentos convincentes – técnicos, teóricos ou políticos – para justificar as decisões do que vai ser feito na seqüência. E assim como posso ser convencido, tento convencer também por meio destes argumentos.

Estar em um time ágil com profissionais de diversas áreas dedicados inteiramente a um produto foi uma novidade que me fez aprender muito. Todos trabalham para entregar o resultado final, e não para concluir a sua parte na linha de produção. A auto-organização e respeito à inteligência do time é essencial. Não existe alguém mandando nos outros para que determinada tarefa seja feita.

O reflexo deste modelo para o PO é que qualquer decisão incomum aos olhos do time vai ser bastante questionada. Estamos todos no mesmo barco, e o fato de termos sucesso ou afundarmos juntos faz com que o grupo queira fazer a coisa certa e seja bastante proativo em relação a isso. Portanto, mais do que ditar a visão a ser seguida, o PO precisa convencer a tripulação a remar pra frente, mostrando por A+B que a direção faz sentido.

Cara nova

Novo tema no blog, ainda em adaptação.
O mais legal é que tem fontes diferentes sem precisar de Flash, usa o Cufón.

Oito princípios para determinar se os dados públicos são realmente abertos

(Traduzido de http://resource.org/8_principles.html)

Um grupo de defensores da divulgação organizada de dados públicos se reuniu e criou a lista que segue, chamada em inglês de Open Government Data Principles.

Segundo eles, dados do governo só podem ser considerados abertos se forem liberados publicamente de acordo com os princípios abaixo. (Mantive os links para os verbetes originais em inglês).

  1. Completos
    Todos os dados públicos estão disponíveis. Um dado público é o dado que não está sujeito a limitações válidas de privacidade, segurança ou privilégios de acesso.

  2. Primários
    Os dados são como os coletados na fonte, com o maior nível possível de granularidade e sem agregação ou modificação.

  3. Atuais
    Os dados são colocados à disposição tão rapidamente quanto necessário para preservar o seu valor.

  4. Acessíveis
    Os dados estão disponíveis para a o maior escopo possível de usuários e para o maior escopo possível de finalidades.

  5. Processáveis por máquinas
    Os dados são razoavelmente estruturados para permitir processamento automatizado.

  6. Não-discriminatórios
    Os dados estão disponíveis para todos, sem necessidade de cadastro.

  7. Não-proprietários
    O dados estão disponíveis em um formato sobre o qual nenhuma entidade tem controle exclusivo.

  8. Livres de licenças
    Os dados não estão sujeitos a nenhuma regulação de direitos autorais, patentes, propriedade intelectual ou segredo industrial. Restrições sensatas relacionadas à privacidade, segurança e privilégios de acesso podem ser permitidas.

A observância aos princípios deve ser revisável (veja item 3 abaixo).

Definições

  1. O significado de “público” :Estes princípios não tratam sobre que dados devem ser públicos e abertos. Privacidade, segurança e outras preocupações podem impedir legalmente (e com razão) que conjuntos de dados sejam compartilhados com o público. Por isso, os princípios especificam apenas as condições que os dados públicos devem atender para serem considerados “abertos”.
  2. O significado de “dados”:Informações ou gravações armazenadas eletronicamente. Exemplos incluem documentos, bases de dados de contratos, transcrições de audiências e gravações audio/visuais de eventos.Embora fontes informativas não eletrônicas, como artefatos físicos, não sejam objeto destes princípios, encoraja-se que elas sejam convertidas para formatos eletrônicos na medida do possível.
  3. O significado de “revisável”:Alguém deve ser designado como contato para responder a pessoas que tentarem utilizar os dados.A pessoa de contato deve estar claramente designada para que possa responder a reclamações sobre violações dos princípios.

    Uma corte administrativa ou judicial deve ter a jurisdição para revisar se a agência aplicou estes princípios apropriadamente.

* * *

E o que isso tem a ver com o Brasil?

Toda entidade pública que gera dados de interesse público deveria liberá-los seguindo os princípios acima. Simples assim. Não importa de onde elas são.

O exemplo mais gritante é o de dados que são acessíveis apenas pelo browser, como a lista de devedores do INSS, que viola claramente o princípio 5 (dados devem ser processáveis por máquinas).

O que os desafios dos posts anteriores incentivam é a aplicação na marra destes princípios aos dados públicos brasileiros.

Latest Tweets

Latest Links