Pensamentos e provocações levemente acoplados sobre Pessoas, Produtos, Processos e Sistemas.

1. CotAções
Pensamentos & Provocações
Levemente Acoplados

2. Jim Highsmith
Agile Project Management
Addison-Wesley, 2010
Líderes de projetos eficazes
valorizam pessoas,
produtos e processos
– nesta ordem.

3. James O. Coplien & Gertrud Bjørnvig
Lean Architecture for Agile Software Development
Wiley, 2010
Talvez metade do
desenvolvimento de software seja
sobre coisas nerd acontecendo
em quadros brancos e teclados.
Mas a outra metade é sobre
pessoas e relacionamentos.

4. Tom DeMarco & Timothy Lister
Peopleware
Dorset House, 1987
Nosso negócio é muito mais
sociológico do que tecnológico;
depende mais de nossas habilidades
para conversar com outras pessoas
do que das habilidades para
conversar com computadores.

5. Lyssa Adkins
Coaching Agile Teams
Addison-Wesley, 2010
Problemas em projetos sempre
podem ser rastreados até
alguém que não conversou com
outro alguém sobre algo
importante.

6. Gerald M. Weinberg
The Secrets of Consulting
McGraw-Hill, 1985
A despeito do que o cliente
possa lhe dizer, sempre existe
um problema.
Não importa o que pareça a
princípio, o problema é sempre
com as pessoas.

7. Thorstein Veblen
Por piores que sejam, mudanças
sempre agradam alguém.
Por melhores que sejam,
mudanças sempre vão
desagradar alguém.

8. W. Warner Burke
citado em Management 3.0 Workout / Champfrogs Checklist
www.management30.com/workouts, 2013
Pretender que mudanças em
organizações sejam racionais
é algo bem irracional.

9. Jack Welch, GE
citado em A Empresa Conectada
Dave Gray – O’Reilly/Novatec, 2013
Mude antes que você seja
obrigado a fazê-lo.

10. Craig Larman & Bas Vodde
Scaling Lean & Agile Development
Addison-Wesley, 2009
Se não há conflito aparente,
o time está com problemas.

11. Jim Highsmith
Agile Project Management
Addison-Wesley, 2010
Um número significativo de
projetos fracassados se
caracteriza por interfaces
ruins entre o time de produto
e o time de desenvolvimento.

12. Donald G. Reinertsen
Managing the Design Factory
The Free Press, 1997
As interfaces de um sistema
são suas fontes primárias de
valor e complexidade.

13. Donald G. Reinertsen
ibidem
Não há ferramenta de
comunicação mais poderosa
do que o correto
particionamento de um
sistema.

14. Brad Silverberg, Microsoft
citado em Scaling Lean & Agile Development
Addison-Wesley, 2009
O software tende a espelhar a
estrutura da organização que o
criou. Se você tem uma
organização grande e lenta, é
forte a possibilidade de gerar
um sistema grande e lento.

15. Jurgen Appelo
Management 3.0 Workout / Delegation Boards
www.management30.com/workouts, 2013
Sistemas complexos
sobrevivem e prosperam
porque o controle é
distribuído.

16. Gerald M. Weinberg
O Líder Técnico
Makron Books, 1994
Em um ambiente complexo,
mesmo o líder mais orientado
para tarefa é forçado a colocar
as pessoas em primeiro lugar
ou o trabalho não será bem
sucedido.

17. Jurgen Appelo
Management 3.0
Addison-Wesley, 2011
Gerentes de projetos existem
para servir os times, não
para controlá-los.
Eles estão aí para gerenciar
projetos, não pessoas.

18. Ricardo Semler
citado em A Empresa Conectada
Dave Gray – O’Reilly/Novatec, 2013
Se você quiser que as
pessoas ajam como adultas,
é preciso tratá-las como
adultas.

19. Barry W. Boehm
Software Engineering Economics
Prentice Hall, 1981
Uma gerência fraca pode
aumentar os custos de
software mais rapidamente
do que qualquer outro fator.

20. Gary Hamel
O Que Importa Agora
Campus, 2012
O primeiro passo, o mais
importante, para qualquer
organização que pretenda
desenvolver a capacidade de
inovação contínua é
ensinar as pessoas
a ver o mundo com novos olhos.

21. Frederick W. Taylor
O estudo e até a invenção são
uma distração mental...
Um enorme prazer,
e não um trabalho.

22. Silvio Meira
Novos Negócios no Brasil
Casa da Palavra, 2013
[...] toda boa empresa é uma
boa escola.
E não há exceções.

23. Hugh MacLeod
Ignore Everybody
Portfolio, 2009
Não é o que o software faz.
É o que o usuário faz.

24. Gerald M. Weinberg
O Líder Técnico
Makron Books, 1994
Qualquer problema real tem
mais uma solução,
que ninguém descobriu,
ainda.

25. Pablo Picasso
citado em The Art of Project Management
Scott Berkun – O’Reilly, 2005
Computadores são inúteis.
Eles só podem te dar
respostas.

26. James Robertson
Business Analysis and Leadership
Kogan Page, 2013
O escopo do problema é
maior, significativamente
maior, que o software.

27. Frederick P. Brooks
The Mythical Man-Month - Anniversary Edition
Addison-Wesley, 1995
A correta definição sobre
o que precisa ser feito
é a parte mais difícil do
desenvolvimento de sistemas.
Nenhuma outra compromete tanto
um projeto quando mal executada.
E nenhuma é mais difícil de ser
corrigida.

28. Karl E. Wiegers
More About Software Requirements
Microsoft Press, 2006
Verdade cósmica nº 1:
Se você não aprender bem os
requisitos, não fará a menor
diferença o quão bem trabalhe
no restante do projeto.

29. Usuário Anônimo
citado em Requirements-Led Project Management
Suzanne & James Robertson – Addison-Wesley, 2005
Sim, eu sei que
foi isso que eu pedi.
Mas não é disso
que eu preciso.

30. James O. Coplien & Gertrud Bjørnvig
Lean Architecture for Agile Software Development
Wiley, 2010
Bons ciclos de feedback dão
aos clientes a oportunidade
de refletir sobre aquilo que
eles estão pedindo.

31. Executivo Anônimo
citado em Agile Software Requirements
Dean Leffingwell – Addison-Wesley, 2011
Teria sido bem mais fácil
se você tivesse desenhado.

32. PV
FAN – Formação de Analistas de Negócios
finito, 2007 ~ 2014
To Be - As Is = Reqs

33. Tim Brown
Change by Design
Harper Business, 2009
Palavras e números são bons,
mas é desenhando que
revelamos simultaneamente as
características funcionais
e o conteúdo emocional
de uma ideia.

34. Scott Berkun
The Art of Project Management
O’Reilly, 2005
Se não pode ser desenhado
nem rabiscado, então
não pode ser construído.

35. Gerald M. Weinberg
The Secrets of Consulting
McGraw-Hill, 1985
Se não pode dar jeito na coisa,
dê-lhe destaque.
Se não puder destacar, disfarce-a.
Se alguma coisa está disfarçada,
é preciso dar um jeito nela.

36. Thomas Watson, IBM
citado em The Art of Project Management
Scott Berkun – O’Reilly, 2005
Se você quer ter sucesso,
dobre sua taxa de fracassos.

37. Jason Fried & David H. Hansson
Getting Real
37signals, 2007
Seu produto tem uma voz –
e ele está conversando com
seus clientes
24 horas por dia.

38. Craig Sampson, IDEO
citado em Requirements-Led Project Management
Suzanne & James Robertson – Addison-Wesley, 2005
A mensagem mais memorável
que uma empresa pode passar é
um produto bem feito – ela só
perde para as mensagens de
um produto mal feito.

39. Suzanne Robertson & James Robertson
Requirements-Led Project Management
Addison-Wesley, 2005
Alguns produtos são pouco
mais que uma ideia.
É isso, o produto é tão
simples que ele é pouco mais
que uma ideia.

40. Frederick P. Brooks
The Mythical Man-Month - Anniversary Edition
Addison-Wesley, 1995
A complexidade é uma
propriedade essencial do
software, não uma acidental.

41. Jurgen Appelo
Management 3.0
Addison-Wesley, 2011

42. Jurgen Appelo
Management 3.0
Addison-Wesley, 2011
A única representação
precisa de um sistema
complexo é o próprio
sistema.

43. Tom DeMarco & Timothy Lister
Peopleware
Dorset House, 1987
Documentação volumosa é
parte do problema,
não da solução.

44. Jim Collins
Good to Great
Harper Business, 2001
O propósito da burocracia é
compensar a incompetência e
a falta de disciplina.

45. Thomas A. Stewart
A Riqueza do Conhecimento
Campus, 2002
As empresas são organismos
vivos; Os documentos são
como defuntos.

46. Jim Highsmith
Agile Project Management
Addison-Wesley, 2010
A questão não é
documentação;
é compreensão.

47. James O. Coplien & Gertrud Bjørnvig
Lean Architecture for Agile Software Development
Wiley, 2010
A maneira correta de ver o
desenvolvimento de software
é que tudo o que acontece
após a primeira compilação
bem sucedida é manutenção.

48. Jurgen Appelo
Management 3.0
Addison-Wesley, 2011
Se você introduzir um novo
produto de software em um
ambiente, o ambiente vai
mudar, consequentemente os
requisitos do produto
também mudarão.

49. Jim Highsmith
Agile Project Management
Addison-Wesley, 2010
Não existe produto mais
maleável que o software.
As empresas precisam usar
essa característica a seu favor.
O modelo waterfall nega essa
vantagem.

50. Tom DeMarco & Timothy Lister
Peopleware
Dorset House, 1987
As pessoas que escrevem a
Metodologia são espertas.
Aquelas que devem segui-la
podem ser idiotas.

51. Dave Gray
A Empresa Conectada
O’Reilly/Novatec, 2013
Quanto mais à prova de idiotas
for o sistema, mais restritivo
será o comportamento,
forçando as pessoas a agirem
como idiotas, mesmo quando
algo for contra seu bom senso.

52. Dave Gray
A Empresa Conectada
O’Reilly/Novatec, 2013
Se o seu sistema deve resolver
problemas que você não pode
antecipar, então ele irá falhar
porque sistemas automatizados e
funcionários que são tratados
como idiotas não conseguem
resolver problemas.

53. Gary Hamel
O Que Importa Agora
Campus, 2012
Se a vida tivesse aderido às
regras do Seis Sigma, ainda
seríamos uma geleia viscosa.

54. Jurgen Appelo
Management 3.0
Addison-Wesley, 2011
Modelos de maturidade são
pouco úteis, talvez até um
pouco ofensivos.

55. Gerald M. Weinberg
Software com Qualidade – Medidas de Primeira Ordem
Makron Books, 1994
Todo processo é criado por
pessoas e, dessa forma, pode
ser mudado por pessoas.

56. Jim Highsmith
Agile Project Management
Addison-Wesley, 2010
O fato de uma prática ser
“boa” não significa que ela
deva ser utilizada em todos
projetos.

57. Scott Berkun
The Art of Project Management
O’Reilly, 2005
Ao se envolver com o
gerenciamento de projetos,
você está definindo um campo
de jogo político ao seu redor.
Está contigo definir o quão
insano ou justo ele será.

58. Bob Lewis
IS Survival Guide
Sams Publishing, 1999
Seja sensato no uso de
metodologias, e nunca deixe
ninguém se esquecer que
elas são ferramentas,
não uma razão de ser.

59. Bob Lewis
ibidem
Dê este passo a mais e sua
metodologia se tornará uma
coisa diferente e
assustadora.
Ela se tornará uma religião.

60. Jeff Bezos, Amazon
citado em Adapte-se ou Morra
Fast Company/Sextante, 2010
Se você não consegue
alimentar uma equipe com
duas pizzas, então a equipe
está grande demais.

61. Frederick P. Brooks
The Mythical Man-Month - Anniversary Edition
Addison-Wesley, 1995
Colocar mais pessoas em um
projeto atrasado é como
tentar apagar um incêndio
jogando gasolina.

62. Scott Berkun
The Art of Project Management
O’Reilly, 2005
A elaboração do melhor
cronograma, usando as pessoas
mais capacitadas e sofisticadas
ferramentas, ainda será uma
tentativa de prever o futuro.
Algo que nossa espécie
raramente faz bem.

63. Watts S. Humphrey
Winning with Software
Addison-Wesley / SEI, 2002
Por que profissionais
competentes concordam com
um cronograma quando
não têm a menor ideia de
como irão cumpri-lo?

64. Watts S. Humphrey
ibidem
Por que executivos racionais
aceitam tais cronogramas se
os engenheiros não oferecem
a menor evidência de que
poderão respeitá-los?

65. Donald G. Reinertsen
Managing the Design Factory
The Free Press, 1997
A válvula de escape do
processo de desenvolvimento
deixou de ser o cronograma;
Cada vez mais são os
requisitos do produto.

66. Craig Larman & Bas Vodde
Scaling Lean & Agile Development
Addison-Wesley, 2009
O último projeto simples foi feito
em 1962. Não acredite que exista
algum projeto que não envolva
aprendizagem ou complexidade ou
alguma variabilidade, e que ele
não se beneficiaria do
desenvolvimento ágil.

67. Fred P. Brooks
The Mythical Man-Month - Anniversary Edition
Addison-Wesley, 1995
A complexidade é uma
propriedade essencial do
software, não uma acidental.

68. Jurgen Appelo
Management 3.0
Addison-Wesley, 2011
Em um mundo complexo,
há tempo e espaço para toda e
qualquer ideia. Não faz sentido
discutir quais estão erradas
porque, no final das contas,
todas estão.

69. Compadre Washington
Ou seja,
Não sabem de nada,
inocentes!

70. Roteiro, edição e tradução* por Paulo Vasconcellos
pfvasconcellos.com
finito@pfvasconcellos.com
@pfvasconcellos
LinkedIn.com/in/pfvasconcellos
* Livre, meio desastrada e ocasionalmente tendenciosa.