- Débito Técnico é Imposto - Quem prioriza o débito técnico é o time. O P.O. traz a proposta inicial. - O P.O não precisa se preocupar com os débitos técnicos, mas ele precisa entender que o débito técnico entrava novas features. - Mas todos precisam decidir juntos. O que perdemos se não resolvemos determinado débito técnico? - O time precisa trabalhar junto para decidir como time, envolvendo P.O. - O Imposto é uma porcentagem. - Levantar argumentos para fazer o débito técnico: resolvê-lo traria algum valor para o usuário? Ele vai melhorar a vazão de novas features e tarefas? - As pessoas tem a facilidade de não mudar o jeito de fazer as coisas. Estamos acostumados a pensar que o P.O. prioriza, mas precisa existir mais envolvimento, sair mais da zona de conforto e questionar mais. - Tente precificar o débito técnico. Quantos clientes estão indo embora por causa desse débito? Quanto trabalho manual estamos fazendo por causa disso? - Qualquer feature nova cria raízes. Cada novo código vai gerar trabalho de manutenção. - Aproxime suporte com o desenvolvimento. - Hire less, hire later. - Um time grande precisa de mais comunicação e mais organização - times pequenos conseguem andar rápido e se comunicar melhor - Muita interrupção traz problemas de concentração, não resolve problemas - Como fazer para diminuir a interrupção dos desenvolvedores? - Tenha contato pessoal com os clientes. Tanto no jeito de falar, quanto no jeito de atender. - Faça com que as funcionalidades deem durou para ser implementadas e não concorde com tudo. - Procure funcionários que aprendam rápido e tenham facilidade de se adaptar ao ambiente para começar a produzir - Esses funcionários são importantes também para trazer novidades do mercado para experimentar dentro do produto - Easy on, easy off. Fácil do cliente vir, mas é fácil do cliente sair também. É fácil do cliente entrar, mas também é fácil para o cliente cancelar/desistir. - Seja pequeno, para mudar rápido. Não somente ligado ao tamanho do time, mas também na estrutura do projeto. - O OKR é uma maneira disfarçada de implementar uma colaboração entre o time. Existem métricas que satisfazem os gestores, mas quem decide **como** mudar os ponteiros é o time - Devolva seu conhecimento para a comunidade. Mostre o que seu time anda fazendo, o que está usando, o que há de novo no produto e também no que estamos adotando - Escolha ferramentas que o time gosta.
- Débito Técnico é Imposto
- Quem prioriza o débito técnico é o time. O P.O. traz a proposta inicial.
- O P.O não precisa se preocupar com os débitos técnicos, mas ele precisa entender que o débito técnico entrava novas features.
- Mas todos precisam decidir juntos. O que perdemos se não resolvemos determinado débito técnico?
- O time precisa trabalhar junto para decidir como time, envolvendo P.O.
- O Imposto é uma porcentagem.
- Levantar argumentos para fazer o débito técnico: resolvê-lo traria algum valor para o usuário? Ele vai melhorar a vazão de novas features e tarefas?
- As pessoas tem a facilidade de não mudar o jeito de fazer as coisas. Estamos acostumados a pensar que o P.O. prioriza, mas precisa existir mais envolvimento, sair mais da zona de conforto e questionar mais.
- Tente precificar o débito técnico. Quantos clientes estão indo embora por causa desse débito? Quanto trabalho manual estamos fazendo por causa disso?
- Qualquer feature nova cria raízes. Cada novo código vai gerar trabalho de manutenção.
- Aproxime suporte com o desenvolvimento.
- Hire less, hire later.
- Um time grande precisa de mais comunicação e mais organização
- times pequenos conseguem andar rápido e se comunicar melhor
- Muita interrupção traz problemas de concentração, não resolve problemas
- Como fazer para diminuir a interrupção dos desenvolvedores?
- Tenha contato pessoal com os clientes. Tanto no jeito de falar, quanto no jeito de atender.
- Faça com que as funcionalidades deem durou para ser implementadas e não concorde com tudo.
- Procure funcionários que aprendam rápido e tenham facilidade de se adaptar ao ambiente para começar a produzir
- Esses funcionários são importantes também para trazer novidades do mercado para experimentar dentro do produto
- Easy on, easy off. Fácil do cliente vir, mas é fácil do cliente sair também. É fácil do cliente entrar, mas também é fácil para o cliente cancelar/desistir.
- Seja pequeno, para mudar rápido. Não somente ligado ao tamanho do time, mas também na estrutura do projeto.
- O OKR é uma maneira disfarçada de implementar uma colaboração entre o time. Existem métricas que satisfazem os gestores, mas quem decide **como** mudar os ponteiros é o time
- Devolva seu conhecimento para a comunidade. Mostre o que seu time anda fazendo, o que está usando, o que há de novo no produto e também no que estamos adotando
- Escolha ferramentas que o time gosta.