alguns preditores: como entrou no governo? (concurso? indicação política?) é sócio de empresa? já foi punido antes? cargo? filiado a partido político? ... centenas de outros preditores
como funciona? modelo é treinado com base em casos passados: fornecedores que já foram punidos pelo governo federal + fornecedores que não foram punidos
alguns preditores: doação de campanha? quantos funcionários? existe há quanto tempo? quantos lances? escopo de atividades? ... centenas de outros preditores
SISAM: app da Receita que encontra erros em declarações de importação redes bayesianas aprende c/ poucos exemplos fácil de retreinar gera automaticamente textos que explicam os problemas encontrados
#1 o que fazer com as previsões? o que fazer com as previsões? demite servidor? desqualifica licitante? a tecnologia avança mais rápido que a legislação problema relacionado: grande qtde. de previsões; é impossível dar vazão a tudo
#2 obter os dados órgãos não compartilham dados entre si nem mesmo quando os dados são públicos (!) “ok, mas só se firmarmos um convênio” “ok, mas a extração custa R$ 39.844.095.098.490.802.984.309.582.304” “como assim você queria os dados atualizados?” “como assim você queria todos os dados?”
#3 entender os dados principal base do governo federal – ComprasNet – não tem documentação “quem tinha essa documentação era o Zé das Couves mas ele se aposentou...” mito: “ciência de dados é 80% pré-processamento e 20% modelagem” realidade: ciência de dados é 80% entender os dados e 20% pré- processamento e modelagem
#4 limpar os dados salários como string CPF/CNPJ como float DD/MM/AA, MM/DD/AA, AA/MM/DD na mesma coluna -9, -1, -999, etc, como missing data (acaba entrando no cálculo das médias) valores absurdos (ex.: contrato de TI de US$ 1 quatrilhão)
#6 liberdade p/ experimentar às vezes um trabalho de semanas não dá em nada muitos falsos positivos, muitos falsos negativos, o problema deixou de ser relevante, etc é difícil estimar prazos (finais ou intermediários) chefia precisa estar ok com isso mas mais importante: é preciso poder errar perante os colegas “psychological safety” http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its- quest-to-build-the-perfect-team.html
#7 ouvir o usuário quem é o usuário? outros órgãos? cidadão? usuário não está pagando pelo serviço, então tem menos propensão a dar feedback não dá pra ouvir o usuário só no final, depois que o app levou meses p/ ser desenvolvido e o órgão gastou $$$$$ difícil lição: data product bacana != data product útil “fator uau” não prediz sucesso de funcionalidade CÉREBRO: grafo gravitacional na visualização de redes societárias usuário: “pq essas bolinhas ficam dançando na minha frente??”
#8 recrutamento difícil achar pessoal c/ a qualificação necessária estatística/mineração & desenvolvimento de software & domínio do negócio recrutamento é engessado no serviço público salários não são negociáveis concurso premia quem decora leis paliativos: negociar fringe benefits (horário flexível, trabalho remoto, capacitação) PNUD terceirização
#9 open office layout é péssimo p/ a produtividade mas é a norma especialmente p/ quem escreve código: leva ~25 minutos p/ retomar a produtividade após uma interrupção http://thetomorrowlab.com/2015/01/why-developers-hate-being-interrupted/ http://swizec.com/blog/why-programmers-work-at-night/swizec/3198 http://paulgraham.com/head.html http://tosbourn.com/a-pragmatic-approach-to-dealing-with-interruption-whilst- you-are-developing/ http://blog.ninlabs.com/2013/01/programmer-interrupted/ http://blog.fogcreek.com/protecting-developer-time-with-cases-not-chat/
treinamento https://www.coursera.org/learn/machine-learning https://br.udacity.com/course/intro-to-computer-science--cs101/ mais sugestões em http://thiagomarzagao.com/resources/ chefia precisa tratar horas de capacitação como horas de trabalho não tem atalho! quem não sabe fazer não sabe delegar
não é possível fazer ciência de dados sem: saber programar conhecer os algoritmos usados “por dentro” se você programa e conhece os algoritmos, não precisa do SAS
sobre cientista de dados atualmente no Observatório da Despesa Pública da CGU professor de estatística e machine learning (thiagomarzagao.com/teaching) pesquisador (thiagomarzagao.com/papers) entusiasta de LEGO Mindstorms (github.com/thiagomarzagao/ev3py) Ohio State University [email protected], @tmarzagao
thiagomarzagao
skrb
oracle4engineer
techtekt
ciniml
microcms
weblyzard
minorun365
sprasiainc
ks91
vividtone
hazumirr
frogandcode
chriscoyier
reverentgeek
colly
addyosmani
davidbonilla
rasmusluckow
bcantrill
holman
kneath
andyhume
kevinliebholz