-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathatom.xml
598 lines (453 loc) · 76.9 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="https://www.w3.org/2005/Atom">
<title>Leandro Alvares da Costa</title>
<link href="https://leandroadacosta.com/atom.xml" rel="self"/>
<link href="https://leandroadacosta.com"/>
<updated>2018-07-26T16:25:08-03:00</updated>
<id>https://leandroadacosta.com</id>
<author>
<name>Leandro Alvares da Costa</name>
<email>[email protected]</email>
</author>
<entry>
<title>Hiring developers in a Series-A startup stage</title>
<link href="https://leandroadacosta.com/hiring-developers-in-a-series-a-startup-stage/"/>
<updated>2017-03-13T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//hiring-developers-in-a-series-a-startup-stage</id>
<content type="html"><p>After some time with this blog switched off, I decided to switch it on again and write about how to hire right software developers to strongly grow your technical team in a Series-A startup stage. I want to share it through my experience.</p>
<p>In my last executive position, I had the opportunity to co-found a successful startup in Brazil in 2012. We have built a digital lending platform called BankFacil - now named <a href="https://www.creditas.com.br">Creditas</a>. We grew up from five to over a hundred people in almost five years. Between 2015 and 2016, after we got a Series-A investment, we scaled the company up by nearly three times, from around 30 to 100 in the whole startup and the product/technical team from approximately 10 to 30. When you set up a business, you wear a lot of hats, and at that time as CTO I spent far more time hiring than another time before. This year (2017), <a href="https://www.crunchbase.com/organization/bankfacil">Creditas got a Series-B round</a>, and they are again growing and hiring.</p>
<p>I’m living in Melbourne, Australia at present, and I have been working as tech advisor at <a href="https://www.rapidoo.com.br">Rapidoo</a> since I left Creditas in August 2016. Rapidoo is a digital invoice factoring in Brazil and recently has been growing and hiring developers too.</p>
<h2 id="seeking-the-best-developer">Seeking the best developer</h2>
<p>At BankFacil I had interviewed more than 1000 people in my last year, and we hired around 20 of them. It meant an average of four interviews per work day in 365 days. We achieved less than 2% of successful hires in the end. We didn’t hire just software developers, but also people as product managers, product designers, data engineers and data scientists.</p>
<p>We selected top professionals and created excellent teams. After many interviews, we developed our interview process which consisted of five parts. Here I outline them for the software engineer interview process:</p>
<h2 id="the-interview-process">The interview process</h2>
<h3 id="1-applications-filtering">1) Applications filtering</h3>
<p>We spread the job opportunities through many channels - this post won’t cover how we did it. Once the candidates completed the hiring application online and sent it to us, we quickly did a standard filter of their applications to remove the unqualified candidates within 48 hours. For the candidates who were successful after this first stage, we made contact and sent a coding challenge. When they finished and sent it back, we analyzed it and asked them for an interview in person.</p>
<h3 id="2-culture">2) Culture</h3>
<p>This was the most significant part of the process. Here we investigated the culture in general. Do our values match the candidate’s values? We had a favorable environment and a nice office, and this package also demonstrated our culture to them. Other important questions we asked the candidates: Do you like reading? What is your dream? Why did you choose us? What is your hobby? What do you think about our business/mission? What are you passionate about? How was the team you are/were working on?</p>
<h3 id="3-tech-culture">3) Tech culture</h3>
<p>I contributed to developing at BankFacil a robust technical culture based on open-source, a community spirit, maintenance of a quality software, an Agile development culture, and be conscious that the theory and the practice have both coming together while developing software. It was essential to attract the professionals with right mindset.</p>
<p>We asked the candidates questions like: Have you been to any community events? Have you read any relevant books recently? Have you ever contributed to open-source? Why did you choose this profession? What is a genuinely good team for you?</p>
<h3 id="4-technical-skills-questions">4) Technical skills questions</h3>
<p>Once the cultural questions were all answered, we moved on to ask questions about technical and team skills. I knew that what was important was “show me the code” rather than talking about coding, but we asked them about some situations like: “Could you draw on the board your best architecture that you have developed in the past, please?”. That question was perfect to see their communication skills and to understand if they could explain things to us or not and express themselves well. The communication skill is completely crucial for small problem solving teams. If is not able to do that at least adequately, you will have a big problem. Your whole team will get stressed in many situations while solving or understanding problems.</p>
<h3 id="5-pair-programming">5) Pair programming</h3>
<p>This step is the best part of the process :) We did it using the candidate’s coding challenge results or a new one if they hadn’t been able to solve it before. We asked them to refactor a feature or include something new. The pairing is so important because it show us a lot of things about the candidates, like their ability, talent, knowledge, and intelligence. Don’t miss it if you want to find the right developer for your team.</p>
<h2 id="how-was-the-process-organized">How was the process organized?</h2>
<p>It’s important to mention we started this process with ten product/technical people already in place, in other words, we already had two senior lead developers to help with hiring when we began scaling, and after that, we found more three great lead developers.</p>
<p>The process from stage 2 to stage 5 took between 30 minutes and 3 hours. It depended on how many steps of the process a candidate passed. The culture, tech culture and tech skill questions parts were conducted by me. The 1st part of analyzing the results of the code challenge and the 5th part of pair programming were done by a lead developer together with the candidate. As a way to build a health culture and to disseminate the process to the team, from the 2nd to 4th, a lead developer accompanied me. At the end of these steps the team also was invited to meet the candidate. Leonardo Andreucci was the CPO - now the current CTO of Creditas, he also was at some those steps when was necessary.</p>
<p>In some cases depending on the seniority and position, the candidate was invited to have a talk with the CEO and other directors at the end of the whole process.</p>
<h2 id="which-were-my-learnings">Which were my learnings?</h2>
<p>We had great benchmarks in our team to compare the new hires with, and we were able to aim to hire a variety of people to create winning teams. I prefer working with a professional who has more action than talent. To be intelligent is fundamental.</p>
<p>Following those steps was crucial for us to find the best professionals for our context, size, and culture.</p>
</content>
</entry>
<entry>
<title>Usando Jekyll + Plugins com GitHub Pages</title>
<link href="https://leandroadacosta.com/usando-jekyll-plugins-com-github-pages/"/>
<updated>2013-03-05T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//usando-jekyll-plugins-com-github-pages</id>
<content type="html"><p>Usar <strong>Jekyll</strong> com <strong>GitHub Pages</strong>, funciona muito bem, mas se for adicionar algum <strong>plugin do Jekyll</strong>, não funciona, o <strong>GitHub Pages</strong> não dá suporte. Depois de pesquisar um pouco, achei uma <strong>abordagem simples</strong> e fácil de solucionar isso. Como eu quis usar plugins - no seu caso isso pode ser opcional - aqui neste meu <a href="/novo-blog-no-ar">novo blog</a> eu desenvolvi usando <strong>Jekyll + Plugins</strong> e hospedadei no <strong>GitHub Pages</strong>.</p>
<h2 id="breve-introdução">Breve introdução</h2>
<p>Leia caso não saiba do que se trata.</p>
<h3 id="o-que-é-github-pages">O que é GitHub Pages</h3>
<p>É um caminho fácil, simples e de graça para <strong>hospedar o site</strong> do seu projeto ou por exemplo seu blog pessoal. No site do <a href="https://pages.github.com">GitHub Pages</a> explica tudo como funciona.</p>
<h3 id="o-que-é-jekyll">O que é Jekyll</h3>
<p>É uma forma simples de <strong>gerar sites estáticos</strong> em <strong>Ruby</strong>. Tem várias vantagens. O mais legal é que o <strong>GitHub Pages</strong> oferece <strong>suporte</strong> para usar <strong>Jekyll</strong>. As coisas funcionam como mágica :). Só acessar o repositório do <a href="https://github.com/mojombo/jekyll">Jekyll</a> no <strong>GitHub</strong> e ler a documentação para colocar seu primeiro site no ar.</p>
<h3 id="o-que-é-jekyll-plugin">O que é Jekyll plugin</h3>
<p>O <strong>Jekyll plugin</strong> permite criar <strong>conteúdos específicos</strong> e <strong>customizados</strong> no site. Por exemplo, neste blog eu usei um plugin que dei o nome de <a href="https://github.com/leandroadacosta/leandroadacosta.github.com/blob/source/_plugins/code_tag.rb">code_tag.rb</a> para facilitar a leitura de trechos de código que escrevo nos posts ao usuário. Basicamente o plugin faz o <em>highlight</em> automático do texto - gerando HTML e CSS - de acordo com o tipo de linguagem que desejar, seja Ruby, HTML, CSS, etc.</p>
<h2 id="solução">Solução</h2>
<p>Para usar <strong>plugins customizados + GitHub Pages</strong> é preciso de começo separar em duas branchs:</p>
<ul>
<li><code class="highlighter-rouge">branch source</code> onde está o <strong>código fonte</strong>.</li>
<li><code class="highlighter-rouge">branch master</code> onde está o <strong>código final gerado pelo Jekyll</strong>.</li>
</ul>
<p>Adicionar no <code class="highlighter-rouge">.gitignore</code> a pasta <code class="highlighter-rouge">/_site</code> que é gerada pelo <strong>Jekyll</strong>. Este simples detalhe permite trocar da <strong>branch source</strong> para <strong>master</strong> e ainda manter os arquivos gerados na pasta <code class="highlighter-rouge">/_site</code>.</p>
<p>Para acontecer a mágica, é preciso mover os arquivos finais de dentro da pasta <code class="highlighter-rouge">/_site</code> para a pasta raiz da <strong>branch master</strong> e comitar na master esses arquivos gerados antes de dar push pro <strong>GitHub</strong>. Para entender melhor, veja abaixo:</p>
<figure class="highlight"><pre><code class="language-bash" data-lang="bash">git checkout <span class="nb">source</span>
// seja lá qualquer alteração feita
git status &amp; git add &amp; git commit
jekyll
git checkout master
cp -r _site/<span class="k">*</span> . <span class="o">&amp;&amp;</span> rm -rf _site/ <span class="o">&amp;&amp;</span> touch .nojekyll
git status &amp; git add &amp; git commit
git push -all origin</code></pre></figure>
<p>Pronto. A parte chata é que você move e comita na <strong>branch master</strong> os códigos gerados pelo <strong>Jekyll</strong>. A parte boa é que você tem a <strong>branch source</strong> pra trabalhar tranquilamente no seu site e, o melhor de tudo, funciona com <strong>Jekyll plugins</strong>.</p>
<p>Pra facilitar a tarefa de copiar, criei um alias no meu bash:</p>
<figure class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="nb">alias </span>jekyll-copy<span class="o">=</span><span class="s2">"cp -r _site/* . &amp;&amp; rm -rf _site/ &amp;&amp; touch .nojekyll"</span></code></pre></figure>
<p>Veja todo o código dessa abordagem de duas branchs no <a href="https://github.com/leandroadacosta/leandroadacosta.github.com">repositório deste blog</a>.</p>
<p>Espero ter ajudado.</p>
</content>
</entry>
<entry>
<title>Novo blog no ar</title>
<link href="https://leandroadacosta.com/novo-blog-no-ar/"/>
<updated>2013-01-28T00:00:00-02:00</updated>
<id>https://leandroadacosta.com//novo-blog-no-ar</id>
<content type="html"><p>Olá pessoal, meu novo blog está no ar depois de algum tempo com o antigo blog em WordPress e sem postar novidades.</p>
<p>Além de posts novos, as principais novidades são:</p>
<ul>
<li>Design responsivo</li>
<li>Desenvolvido com <a href="https://github.com/mojombo/jekyll">Jekyll</a> em vez de WordPress.</li>
<li>Hospedado por <a href="https://pages.github.com">GitHub Pages</a></li>
<li><a href="https://github.com/leandroadacosta/leandroadacosta.github.com">Código fonte disponível</a> no <strong>GitHub</strong>. Pull requests são bem-vindos também :)</li>
<li><a href="/atom.xml">Feed RSS</a></li>
</ul>
<p>Para entender melhor porque desenvolvi este novo blog usando <strong>Jekyll</strong>, fiz um post explicando como <a href="/usando-jekyll-plugins-com-github-pages">usar Jekyll + Plugins com GitHub Pages</a>.</p>
<p>Mais coisas estão por vir.
<br />
Grande abraço.</p>
</content>
</entry>
<entry>
<title>TDC 2012 São Paulo Highlights</title>
<link href="https://leandroadacosta.com/tdc-2012-sao-paulo-highlights/"/>
<updated>2012-07-18T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//tdc-2012-sao-paulo-highlights</id>
<content type="html"><p><a href="/img/posts/tdc-2012/tdc-2012-sao-paulo-1.jpg"><img src="/img/posts/tdc-2012/tdc-2012-sao-paulo-1.jpg" alt="TDC 2012 São Paulo" style="max-width:640px" /></a></p>
<p>Sábado 07/07/2012 participei da conferência de desenvolvedores de software (<a href="https://www.thedevelopersconference.com.br/tdc/2012/index.html" target="_blank">TDC 2012 São Paulo</a>) na Universidade Anhembi Morumbi. Antes de falar sobre as palestras deixo um recado: ir a eventos é sempre muito bom, além do networking ser importante, vejo a troca de experiências como o maior benefício. O profissional de TI que não tem o senso de comunidade, está deixando de lado algo muito valioso.</p>
<p><a href="/img/posts/tdc-2012/tdc-2012-sao-paulo-4.jpg"><img src="/img/posts/tdc-2012/tdc-2012-sao-paulo-4.jpg" alt="TDC 2012 São Paulo" style="max-width:640px" /></a></p>
<p>O evento aconteceu de 4 a 8 de Julho. Consegui ir somente no Sábado (dia 07) na <a href="https://www.thedevelopersconference.com.br/tdc/2012/saopaulo/trilha-ruby#programacao" target="_blank">trilha de Ruby</a> - sim, somente a linguagem Ruby, sem falar do framework <a href="https://rubyonrails.com.br/" target="_blank">Rails</a>. Das palestras, que por sinal foram muito boas, consegui tirar alguns pontos importantes que gostaria de compartilhá-los.</p>
<p><a href="/img/posts/tdc-2012/tdc-2012-sao-paulo-3.jpg"><img src="/img/posts/tdc-2012/tdc-2012-sao-paulo-3.jpg" alt="Ricardo Valeriano - TDC 2012 São Paulo" style="max-width:640px" /></a></p>
<p>O dia começou com a palestra do grande <a href="https://blog.ricardovaleriano.com/" target="_blank">Ricardo Valeriano</a> sobre "<strong>A ferramenta ideal: uma questão de perspectiva.</strong>" e, como sempre, deu um show de dinamismo, descontraindo bastante a galera com seus slides cheios de <em>memes</em>, gostei bastante. Seguem os <em>highlights</em>:</p>
<ul>
<li>Desenvolver software é muito complexo, em sua maioria criasse um legado a longo prazo que não é sustentável. No começo e durante o desenvolvimento os profissionais tomam decisões sobre quais ferramentas vão usar - seja lá qual for, seja uma api específica, um framework, a linguagem a utilizar, ou etc. - sem entender completamente o porque, sem saber criticar as suas escolhas. Se preocupar sempre com o legado é essencial, no futuro pode ser outra pessoa ou equipe que vai encontrar um monstro ou um projeto bem estruturado, pense nisso. O projeto tem que se manter sustentável ao longo do tempo. Tenha em mente e entenda sempre as desvantagens da decisão tomada, assim você conseguirá evoluir o software com qualidade.</li>
<li>Domine a linguagem ao ponto de criticar os pontos negativos. Não existe tecnologia ruim, a decisão depende do contexto, depende da pessoa e do momento.</li>
</ul>
<p><a href="https://cassiomarques.wordpress.com/" target="_blank">Cassio Marques</a> foi o único que falou de Rails além de Ruby. Cassio palestrou sobre "<strong>Porque você não deve usar os callbacks do ActiveRecord</strong>" (<a title="Porque você não deve usar os callbacks do ActiveRecord" href="https://speakerdeck.com/u/cassiomarques/p/porque-voce-nao-deve-usar-os-callbacks-do-activerecord" target="_blank">slides da palestra</a>), achei muito interessante os pontos abordados. Seguem os <em>highlights</em>:</p>
<ul>
<li>O teste está lento? Não sabe porque? Cuidado! Lembre-se que os callbacks do ActiveRecord nos seus modelos são executados quando você persiste objetos durante a execução dos testes.</li>
<li>Não coloque regras de negócio nos callbacks pois será difícil de manter. Sendo assim, não tenha medo de isolar essa lógica criando outras classes se você está desenvolvendo orientado a objetos. Lembre-se que cada objeto deve fazer o mínimo possível e tem que fazer isso bem. Cuidado com convenções, elas são boas para criar um framework, mas não necessariamente para o contexto necessário para seu código.</li>
<li>Ao codificar tenha em mente a clareza ao invés de não concisão. Como assim? É quando você acha que é o expert por escrever seu código de um jeito bonitinho, por exemplo, deixando o código com tudo inline só porque no Ruby é legal. Na verdade isso pode ser ruim, pois bonito é muitas vezes diferente de um código com <a href="https://blog.caelum.com.br/codigo-conciso-claro-e-breve/" target="_blank">clareza e concisão</a>, cuidado.</li>
</ul>
<p><a href="https://blog.qmx.me" target="_blank">Douglas 'qmx' Campos</a> palestrou sobre "<strong>Ruby é lento?</strong>", ele abordou alguns pontos fortes e fracos da linguagem e a comparou com outras linguagens também, foi bem interessante. Seguem os <em>highlights</em>:</p>
<ul>
<li>Ruby não é lento, mas pode ser lento, tudo depende de como foi usado. Ruby foi feito para deixar o programador feliz, quero dizer que tem muitas formas legais de programar as coisas e justamente por causa disso pode ser que fique lento. O desenvolvedor tem que saber que quanto mais poder e flexibilidade ele tem em mãos com a linguagem, maior é a responsabilidade dele em não fazer cagada com a performance.</li>
</ul>
<p>E por fim uma dica, essa foi dada por <a href="https://nandovieira.com.br" target="_blank">Nando Vieira</a>:</p>
<ul>
<li>Você perde muito tempo configurando ambientes desde o zero para o desenvolvedor novo na equipe ou empresa? Dê uma olhada nisso: <a href="https://vagrantup.com/" target="_blank">https://vagrantup.com</a>.</li>
</ul>
<p>Bom, foi o que consegui resumir das palestras. Espero ter ajudado.
Um abraço.</p>
</content>
</entry>
<entry>
<title>O que os líderes empreendedores devem fazer - Parte 1</title>
<link href="https://leandroadacosta.com/o-que-os-lideres-empreendedores-devem-fazer-parte-1/"/>
<updated>2012-03-13T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//o-que-os-lideres-empreendedores-devem-fazer-parte-1</id>
<content type="html"><p>Compartilho com vocês um texto retirado do livro da série <strong>Harvard Business Essentials</strong> de 2005 chamado <strong>Ferramentas para empreendedores</strong> escrito por Richard Luecke.</p>
<h2>Conselhos práticos</h2>
<p>Felizmente, o sucesso e o crescimento são compatíveis com o espírito empreendedor. Mas o que a liderança pode fazer para garantir a vitalidade contínua desse espírito quando o negócio começa a se estabelecer e crescer? Este é o primeiro post de outros que farei contendo conselhos práticos para permanecer agressivo, inovador e com capacidade de resposta às condições de mercado. Vamos ao primeiro:</p>
<h2>Preserve uma cultura favorável à inovação</h2>
<p>Compreende-se bem o impacto da cultura organizacional na criatividade e na geração de idéias. Na ausência de uma cultura que dê este apoio, a criatividade e a inovação não germinarão nem crescerão.</p>
<p>Um exemplo de cultura infértil é uma cultura caracterizada por um foco para dentro, procedimentos extensos para resolver questões por consenso e 'rejeição', arrogância criada pelo sucesso anterior e um senso de direito, por parte de alguns funcionários, a ter os cargos garantidos sem uma contrapartida. Se a cultura de sua empresa está assumindo estas características, então é pouco provável que a criatividade e a inovação floresçam. Pior ainda, as pessoas mais inventivas ficarão desestimuladas e deprimidas, e procurarão trabalho em outro lugar.</p>
<p>Estas perguntas o ajudarão a determinar se sua empresa está perdendo o espírito criativo:</p>
<ul>
<li>Nosso sucesso está nos deixando convencidos e complacentes?</li>
<li>Nós somos focalizados para dentro?</li>
<li>Nós castigamos os que falham ao assumir riscos?</li>
<li>As pessoas criativas e as novas idéias são mal recebidas e desprezadas nesta empresa?</li>
<li>Nós não recompensamos atos de criatividade?</li>
<li>Somos burocráticos na forma como lidamos com as novas idéias?</li>
<li>A hierarquia e seus símbolos se insinuam por nossa cultura?</li>
</ul>
<p>Se você respondeu sim a qualquer uma destas perguntas, é preciso fazer uma avaliação séria e um ajuste em sua cultura organizacional.
Nos outros posts escreverei outras dicas do que os empreendedores devem fazer para manter vivo o espírito empreendedor.
Um grande abraço!</p>
</content>
</entry>
<entry>
<title>Scrum, 8 erros comuns da reunião diária</title>
<link href="https://leandroadacosta.com/scrum-8-erros-comuns-da-reuniao-diaria/"/>
<updated>2012-01-17T00:00:00-02:00</updated>
<id>https://leandroadacosta.com//scrum-8-erros-comuns-da-reuniao-diaria</id>
<content type="html"><p>Texto retirado e resumido do original publicado na revista <a href="https://www.mundoj.com.br/" target="_blank">MundoJ</a> por Dairton Bassi (<a title="Twitter de Dairton Bassi" href="https://twitter.com/dbassi" target="_blank">@dbassi</a>): "Você é Ágil Mesmo? Erros Comuns de Equipes que Pensam ser Ágeis. Detalhes que podem fazer a diferença para a sua equipe".</p>
<h2 id="reuniões-diárias">Reuniões diárias</h2>
<p>As reuniões diárias, em Scrum chamadas de daily scrum, e em XP, de stand up meetings, devem acontecer em pé e diariamente, em local e horário determinados pela equipe, com duração máxima de 15 minutos. Essa prática é fundamental para equipes ágeis, pois é ela quem demarca um ciclo diário de trabalho. A reunião serve para manter todos sincronizados sobre novidades, dificuldades e avanços recentes no projeto e também para fazer um planejamento do dia.</p>
<p>Erros e implicações comuns:</p>
<ol>
<li><strong>Reunião diária a cada três dias:</strong> Se não ocorrem todos os dias, prejudicam a comunicação dentro da equipe. A ausência da reunião diária também impacta no planejamento porque quando o intervalo entre as reuniões aumenta, a equipe passa a ter ciclos de trabalho maiores, o que faz com que a equipe tenha menos visibilidade sobre a evolução do seu trabalho no decorrer da iteração.</li>
<li><strong>Reuniões com longa duração (mais de 15 minutos):</strong> É um sintoma de que a equipe não está se comunicando o suficiente durante o resto do dia. Podem causar a ausência de reuniões nos próximos dias, pois, por falar bastante, a equipe pode ficar com a falsa sensação de que não há assuntos novos no outro dia. Também incentivam que a conversa deixe de acontecer em pé. Em geral, o papo começa em pé, mas os participantes vão se sentando à medida que a conversa de alonga.</li>
<li><strong>Na sala de reuniões:</strong> Cria um ambiente propício para que a conversa se prolongue e que os participantes se sentem. A conversa deve ser feita com praticidade e objetividade, preferencialmente em frente ao quadro de tarefas, assim a equipe pode visualizar o que tem pra fazer e atualizar o quadro.</li>
<li><strong>Reunião de report ao ScrumMaster / Coach / Líder:</strong> Cada integrante deve informar à equipe o que fez e o que pretende fazer, como uma ferramenta para atingir o objetivo da iteração. Se a reunião é realizada sempre com o objetivo de "prestar contas" ou contar as novidades ao ScrumMaster/líder, a equipe não é autogerenciável e nem possui autonomia para tomar suas decisões.</li>
<li><strong>Reunião de 2 minutos:</strong> Esporadicamente é normal que haja uma muito rápida, mas se, dia pós dia, a reunião dura pouquíssimos minutos, ela está sendo feita apenas para cumprir o protocolo e provavelmente não está agregando o valor que poderia.</li>
<li><strong>Detalhamento e explicações de soluções na reunião:</strong> Se os assuntos rondarem um nível muito baixo de detalhes técnicos, provavelmente não será interessante nem útil para todos. Pode-se apenas dizer: "isso pode ser resolvido com a seguinte técnica e eu posso ajudá-lo". Ao final da reunião essas explicações podem ser passadas individualmente.</li>
<li><strong>Horário flutuante:</strong> É interessante que a equipe defina a hora exata, por exemplo, às 10h, assim todos se organizam para estarem disponíveis. Quando combinado um horário aproximado, como, por exemplo, pela manhã, ou após o almoço, é difícil encontrar um momento em que todos estão livres para fazer a reunião. Neste caso a reunião sempre é procrastinada. Com freqüência esse adiamento se torna um cancelamento.</li>
<li><strong>Participação parcial na reunião:</strong> Não deve ser feita em paralelo com outras atividades, ou seja, sem foco na reunião. Isso acontece, por exemplo, quando alguém diz: "podem começar a reunião que estou meio ocupado, qualquer coisa eu falo aqui do meu lugar mesmo". Os bons modos para reuniões diárias incluem chegar no horário, não ficar mexendo no celular, não manter conversas paralelas e não interromper a reunião diária de outra equipe.</li>
</ol>
<p>Alguém já caiu em algum desses erros? Nós aqui da Cocento já e conseguimos ajustar e nos corrigir.
Ótimas dicas do Dairton Bassi. Espero ter ajudado compartilhando também no blog.</p>
</content>
</entry>
<entry>
<title>Significância leva às pessoas ao sucesso</title>
<link href="https://leandroadacosta.com/significancia-leva-as-pessoas-ao-sucesso/"/>
<updated>2012-01-06T00:00:00-02:00</updated>
<id>https://leandroadacosta.com//significancia-leva-as-pessoas-ao-sucesso</id>
<content type="html"><p>Compartilho com vocês um texto escrito por <a href="https://www.judithmbardwick.com/" target="_blank">Judith M. Dardwick</a>, a autora aborda o lado humano da gestão de pessoas, onde a significância leva às pessoas ao sucesso.</p>
<p>Veja como Dardwick comenta o caminho para o sucesso das pessoas, onde eu concordo plenamente.</p>
<blockquote>As pessoas bem sucedidas, se sentem desafiadas, com poder significante.</blockquote>
<p>O que significa isto? Eis as definições, com as palavras dos próprios empregados:</p>
<h2>Desafio</h2>
<ul>
<li>Quero continuar aprendendo.</li>
<li>Quero responsabilidades diferentes.</li>
<li>Quero correr algum risco.</li>
<li>Quero cada dia diferente do outro.</li>
<li>Quero que meu trabalho seja divertido.</li>
</ul>
<h2>Busca de Poder</h2>
<ul>
<li>Quero tomar decisões importantes.</li>
<li>Quero a oportunidade de ser criativo.</li>
<li>Quero que as pessoas me respeitem.</li>
<li>Não quero ter de pedir permissão.</li>
<li>Não quero ter de fazer as coisas rotineiramente.</li>
<li>Quero ser responsável e que as pessoas confiem em mim.</li>
<li>Realmente me preocupo com esta coisa e sou uma das pessoas que estão brigando por ela.</li>
</ul>
<h2>Significância</h2>
<ul>
<li>Quero sentir que eu conto.</li>
<li>Quero crer que o meu trabalho é importante.</li>
<li>Quero fazer mais do que juntar papéis e ir a reuniões.</li>
<li>Existe um objetivo no que faço.</li>
<li>Estou fazendo algo que os outros realmente gostam.</li>
<li>O que estou fazendo é significativo. Isto faz uma diferença. Eu faço falta aqui.</li>
</ul>
<p>Como podemos observar, o lado humano da gestão de pessoas também é extremamente importante para o sucesso das pessoas e para os resultados da organização.</p>
<p>E como você se sente ao trabalhar no dia a dia?
Espero ter ajudado. Um abraço.</p>
</content>
</entry>
<entry>
<title>Cultura de Conquista - Parte 2</title>
<link href="https://leandroadacosta.com/cultura-de-conquista-parte-2/"/>
<updated>2011-11-28T00:00:00-02:00</updated>
<id>https://leandroadacosta.com//cultura-de-conquista-parte-2</id>
<content type="html"><p>Na <a title="Cultura de Conquista – Parte 1" href="/cultura-de-conquista-parte-1/" target="_blank">primeira parte deste post</a> foram abordados aspectos relacionados ao estado de conquista, são eles: terras altas da “Conquista”, produtividade, criatividade, violação das normas estabelecidas e equipes de trabalho. Daremos continuidade a <strong>segunda e última parte</strong> da cultura de conquista.</p>
<h2>Por que é tão difícil?</h2>
<p>É importante lembrar que, em princípio, onde existe "<a title="Perigo na Zona de Conforto" href="/perigo-na-zona-de-conforto/" target="_blank">zona de conforto</a>", qualquer movimento conquistado gera medo, por isso é tão difícil.</p>
<p>Pesquisas psicológicas confirmam que a <strong>motivação</strong> é maior quando as probabilidades de sucesso são de 50%. As pessoas não se sentem realmente estimuladas para desenvolver trabalhos difíceis demais. Então, para criar uma conquista psicológica, deve-se levar as pessoas à uma faixa média de risco. O objetivo é criar <strong>medo</strong> mas, principalmente, criar <strong>ansiedade</strong> alta o bastante para estimular a <strong>conquista</strong>.</p>
<p>Você vai precisar de <strong>coragem</strong> e força para manter a <strong>pressão</strong> por tempo o suficiente para convencer as pessoas que a festa finalmente acabou. Durante esse tempo, o moral vai declinar. Haverá protestos, atrasos e resistências. Medidas drásticas podem ser imprescindíveis. A visão, somente, não vai levar as pessoas até a "Conquista" - <em>você vai precisar de uma vara mais do que de uma cenoura</em>. Todavia, a pressão é apenas a metade da prescrição. <em>A outra metade é o apoio</em>. Enquanto estiver fazendo pressão você deve também fornecer informação, conselho e as ferramentas para judar as pessoas a alcançar os níveis requeridos de realização sob este novo regime. Simultaneamente, <em>não aplique tanta pressão que as pessoas passem do medo ao pânico</em>.</p>
<h2>Crie oportunidades para desafio e risco</h2>
<p>Para aumentar a pressão, você tem de, primeiro, <strong>identificar</strong> o que constitui <strong>trabalho real</strong>, decidir como <strong>avaliá-lo</strong> e, então, reforçar suas avaliações encorajando riscos e tentando pagar pelo <strong>desempenho</strong> das <strong>competências</strong>. Avalie o desempenho real das competências apresentadas (<strong>conheça nosso produto</strong> para <a title="CHA Master" href="https://www.chamaster.com/" target="_blank">Avaliação de Desempenho por Competência</a>). Crie oportunidades para desafio e risco, liberando as pessoas para fazer tarefas específicas e rotação de tarefas - <em>job rotation</em>. A cada ano, 25% da tarefa de uma pessoa deve ser novidade. E não puna quem corre riscos. Inove. Faça!</p>
<h2>Diminua a hierarquia e aumente a visibilidade dos colegas</h2>
<p>Você pode aumentar a visibilidade do empregado diminuindo a hierarquia. <strong>Organizações</strong> mais <strong>enxutas</strong>, mais estáveis, oferecem poucos nichos onde as pessoas possam se esconder.</p>
<p>Muito interessante, a <a title="Nissan" href="https://www.nissan.com.br/" target="_blank">Nissan</a> - uma empresa japonesa fabricante de automóveis -, não usando relógios de ponto, se gaba de ter o melhor nível de comparecimento ao trabalho dos Estados Unidos. Pelo menos duas coisas provocam isso:</p>
<ol>
<li>As pessoas trabalham em equipes de mais ou menos vinte membros, assim os ausentes são realmente notados.</li>
<li>Os japoneses auto-suficientes, ao contrário de seus parceiros americanos, não usam trabalhadores substitutos para cobrir o espaço dos ausentes. Os membros da equipe têm de tapar a brecha eles mesmos.</li>
</ol>
<h2>Demissão por não-desempenho</h2>
<p>Você pode ter de demitir os ociosos para conseguir a crença dos céticos. Se a demissão for necessária, deixe bem claro que os demitidos eram subprodutores que receberam ampla avaliação, orientação e apoio para ajudá-los a ter um desempenho em níveis aceitáveis.</p>
<h2>Acabe com a Zona de Conforto</h2>
<p>Após toda mudança os sobreviventes tendem a cair novamente na armadilha da zona de conforto - psicologia do direito "Adquirido". A liderança terá e fazê-los voltarem ao estado de "Conquista", com uma ligeira passagem pelo <strong>medo</strong>, mais uma vez - e talvez outra e outra vez, até que a lição seja aprendida.</p>
<p>Para banir a zona de conforto, você terá de fazer as pessoas trabalharem como <strong>equipes</strong> de colaboradores permanentes enquanto você estabelece a direção, motiva e explora as <strong>energias coletivas</strong> e <strong>criativas</strong> de todos os envolvidos.</p>
<p>--</p>
<p>Resumo retirado do texto: O Hábito do “Direito Adquirido”: Ele está nos matando por Judith M. Bardwick.</p>
<p>Espero ter contribuído positivamente. Um abraço.</p>
</content>
</entry>
<entry>
<title>Validando a solução junto ao cliente com Mockups</title>
<link href="https://leandroadacosta.com/validando-a-solucao-junto-ao-cliente-com-mockups/"/>
<updated>2011-11-17T00:00:00-02:00</updated>
<id>https://leandroadacosta.com//validando-a-solucao-junto-ao-cliente-com-mockups</id>
<content type="html"><p>Compartilho com vocês uma experiência na prática que tivemos recentemente em um cliente, sobre como nos ajudou, e muito, iniciar o desenvolvimento do software <strong>centrado na usabilidade do usuário</strong>.</p>
<h2>Primeira reunião</h2>
<p>Fizemos uma reunião presencial - na parte da manhã - de 2 horas no cliente para entender a necessidade de negócio. Parece simples, mas, tem uma questão muito importante nesta fase, que é <strong>separar o problema da solução</strong>. Pensando desta forma, conseguimos focar e entender os problemas atuais, suas causas e efeitos.</p>
<p>Após ter definido parte do conceito, achamos que, para validar o entendimento, seria legal rabiscar naquele momento alguns pré-protótipos frente ao cliente. Foi bem interessante pois conseguimos - além de verbalizar - mostrar no papel nosso entendimento, foi mais fácil para ambos, onde saímos mais confiantes.</p>
<h2>Lição de casa</h2>
<p>No mesmo dia, após o almoço - <strong>sem burocracia</strong> - voltamos e começamos um <em>brainstorm</em> com somente 2 pessoas, onde desenhamos na lousa e rabiscamos os primeiros <strong>protótipos</strong> no papel. O interessante neste processo, é que fizemos várias <strong>dramatizações</strong> - isso acontece direto, cada um encenando vários papeis relacionados ao negócio que estávamos resolvendo. Chega a ser engraçado, mas é muito <strong>produtivo</strong> e <strong>importante</strong>.</p>
<p>Ao final do dia, tínhamos em mãos toda uma visão da solução - centrada no usuário. Veja, fizemos tudo isso, em apenas um dia. Há, espera aí, você está me dizendo que desenho em lousa e papel é solução? E ainda tem mais, como já é solução se nem foi validada junto ao cliente. Direi como agimos para resolver esses fatos.</p>
<h2>Validando junto ao cliente</h2>
<p>No outro dia, logo cedo, estávamos conversando sobre a forma menos burocrática possível e <strong>ágil</strong> de validar a solução junto ao cliente. A forma que fazíamos em outros projetos era marcar outra reunião para levar todos os protótipos em papel e demonstrar ao cliente. Sempre foi muito ágil e produtivo. Neste caso, em praticamente 2 dias conseguiríamos validar toda uma visão de proposta de solução. Mas! Como sempre, queria <a title="Perigo na Zona de Conforto" href="https://leandroadacosta.com/2011/10/25/perigo-na-zona-de-conforto/" target="_blank">conquistar</a> algo diferente. Tinha na manga <strong>um jeito novo</strong> para testar.</p>
<p>Fui ao evento <a title="RubyConf 2011 " href="https://rubyconf2011.akitaonrails.com/" target="_blank">Ruby Conf 2011</a> nos dias 03 e 04 de novembro e assisti a palestra <strong><a title="Melhores Softwares através da Interface" href="https://www.eventials.com/rubyconfbr/recorded/M2UzZTJkMzY2MzdiNTg2NTUxNWM1MzI3NWY1YjRhMzYjIzQwMw_3D_3D" target="_blank">"Melhores Softwares através da Interface"</a></strong> do <strong><a href="https://twitter.com/danielvlopes" target="_blank">Daniel Lopes</a></strong>. Por sinal, <strong>excelente palestra</strong>. Ele enfatizou a importância do Designer de Interface saber programar, dos benefícios de começar o software pela interface, e uma forma diferente de validar propostas de solução - protótipos - junto ao cliente.</p>
<p>O que o Daniel passou de diferente do que já trabalhamos aqui na Cocento Tecnologia - e que achei muito legal - foi o <strong>jeito pragmático de validar junto ao cliente</strong>.</p>
<h2>Validando a proposta de solução com Mockups</h2>
<p>A idéia passada pelo <strong>Daniel Lopes</strong> é, em vez de validar os protótipos em papel ou photoshop/fireworks, é validar direto em <strong>protótipos funcionais</strong> - com fluxo entre as telas - já <strong>implementados em código</strong> - ruby/java/php/etc e html, css e js. E foi o que fizemos, logo na parte da manhã do segundo dia, criamos o projeto no GitHub implementamos as telas já em Ruby on Rails. Para isto, segue o conceito de <strong>Mockups</strong> apresentada pelo Daniel:</p>
<p>Definimos a rota:</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="no">Example</span><span class="o">::</span><span class="no">Application</span><span class="p">.</span><span class="nf">routes</span><span class="p">.</span><span class="nf">draw</span> <span class="k">do</span>
<span class="n">scope</span> <span class="s1">'/mockups'</span><span class="p">,</span> <span class="ss">:constraints</span> <span class="o">=&gt;</span> <span class="nb">lambda</span> <span class="p">{</span> <span class="o">|</span><span class="n">e</span><span class="o">|</span> <span class="n">not</span> <span class="no">Rails</span><span class="p">.</span><span class="nf">env</span><span class="p">.</span><span class="nf">production?</span> <span class="p">}</span> <span class="k">do</span>
<span class="n">match</span> <span class="s1">'/:action'</span><span class="p">,</span> <span class="ss">:controller</span> <span class="o">=&gt;</span> <span class="s1">'mockups'</span><span class="p">,</span> <span class="ss">:actions</span> <span class="o">=&gt;</span> <span class="sr">/[^/</span><span class="p">]</span><span class="o">+</span><span class="sr">/
end
end</span></code></pre></figure>
<p>Criamos o controller:</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">class</span> <span class="nc">MockupsController</span> <span class="o">&lt;</span> <span class="no">ApplicationController</span>
<span class="k">def</span> <span class="nf">books_list</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">new_book</span>
<span class="k">end</span>
<span class="k">end</span></code></pre></figure>
<p>Para cada método do controller implementamos a view em HTML, CSS e JS para simular alguns comportamentos, por fim, linkamos os fluxos entre elas:</p>
<figure class="highlight"><pre><code class="language-text" data-lang="text">|~app/
| |+assets/
| |~controllers/
| | |-application_controller.rb
| | `-mockups_controller.rb
| |+helpers/
| |+mailers/
| |+models/
| `~views/
| |~layouts/
| | `-application.html.erb
| `~mockups/
| |-books_list.html.erb
| `-new_book.html.erb</code></pre></figure>
<h2>Resultado final</h2>
<p>Tínhamos no final do segundo dia um <strong>protótipo</strong> totalmente <strong>funcional</strong> e <strong>bonito</strong>. Pera aí, como em um dia conseguiram deixar o layout bonito? Vou abrir o segredo com vocês :). Para agilizar o processo, usamos todo um padrão para o front-end do <a title="Twitter Bootstrap" href="https://twitter.github.com/bootstrap/" target="_blank">Twitter Bootstrap</a>.</p>
<p>Fizemos a reunião no terceiro dia e o <strong>feedback</strong> foi <strong>excelente</strong>. <strong>Cliente</strong> muitíssimo <strong>satisfeito</strong> e a nossa equipe também. O importante é frisar que fizemos a primeira reunião de entendimento da necessidade até a codificação e validação em apenas 3 dias.</p>
<p>--</p>
<p>E você? Como faz para agilizar, diminuir os riscos e ser produtivo nas validações de proposta de solução junto ao cliente lá na sua empresa e/ou equipe?
Um abraço.</p>
</content>
</entry>
<entry>
<title>Cultura de Conquista - Parte 1</title>
<link href="https://leandroadacosta.com/cultura-de-conquista-parte-1/"/>
<updated>2011-11-12T00:00:00-02:00</updated>
<id>https://leandroadacosta.com//cultura-de-conquista-parte-1</id>
<content type="html"><p>Dando sequência ao post anterior, sobre o <a title="Perigo na Zona de Conforto" href="/perigo-na-zona-de-conforto" target="_blank">Perigo na Zona de Conforto</a> do hábito do <strong>Direito Adquirido</strong>. Falaremos da <strong>cultura de conquista</strong>. A conquista tem seu fator psicológico, poderíamos dizer que seria o estado de conquista em vez de cultura.</p>
<h2>Terras altas da "Conquista"</h2>
<p>Os gestores que lideram colocando as pessoas em um <strong>ambiente</strong> de <strong>não-hierarquia</strong> onde produzem mais, <strong>pensam criativamente</strong>, trabalham junto <strong>como uma equipe</strong> e são levadas a desenvolverem suas <strong>competências, </strong>fazem com que suas organizações saiam da areia movediça do<strong> direito "Adquirido" </strong>às terras altas da<strong> "<strong>Conquista</strong>"</strong>.</p>
<p>Um ambiente de conquista fornece <strong>oportunidades de conseguir</strong> e requer trabalhadores para fazer isso. Os empregados não têm medo de agir - porque se sentem importantes - e a pressão para serem bem sucedidos torna o trabalho estimulante.</p>
<h2>Produtividade</h2>
<p>O fato de fazer as pessoas trabalharem e esperar que façam o melhor desenvolve a <strong>confiança</strong> e a <strong>independência</strong>. A confiança e a coragem resultante da conquista do próprio caminho produzem grandes <strong>solucionadores de problemas</strong>.</p>
<p>Quando se leva os empregados a desenvolver um conceito de conquista, <em>dá-se-lhes poder para conseguir, para resolver problemas, para progredir, para mudar e se adaptar</em>. Enrolar-se em um cobertor de segurança burocrática nunca resolveu problema ou reduziu a ansiedade.</p>
<h2>Criatividade e Violação das Normas Estabelecidas</h2>
<p>A ligação entre a <strong>conquista</strong> e a <strong>inovação</strong> é especialmente importante no cenário competitivo do fazer-ou-morrer de hoje. Conquistas e concessão de poder são pré requisitos para a <strong>criatividade</strong>, especialmente onde avanços maiores estão envolvidos. A criatividade exige aquilo que os psicólogos chamam de <em>"violação das normas estabelecidas"</em> - ver as coisas de <strong>modo diferente</strong> de como têm sido vistas antes. A <strong>violação das normas</strong> envolve <strong>riscos</strong>, porque ser diferente geralmente é visto - pelo menos no início - como estar errado.</p>
<h2>Equipe de trabalho</h2>
<p>A equipe de trabalho falha sob a psicologia do direito "Adquirido" porque as pessoas se preocupam demais em <strong>se proteger</strong>. Liderar ou treinar as pessoas para trabalhar como equipe é algo que entra por uma orelha e sai por outra, pois as pessoas estão <strong>inseguras</strong> demais para <strong>contribuir</strong> para o <strong>bem-estar</strong> dos <strong>colegas</strong>, que poderiam acabar bem melhores que eles.</p>
<p>Por outro lado, as pessoas que trabalham em um ambiente de "Conquista" são membros de equipe com autoridade - e competidores também. Ninguém quer deixar a equipe cair. Há uma atmosfera de tensão criativa, uma certa mistura de cooperação e competição que leva a um risco criativo, erradica a complacência e assegura melhores decisões.</p>
<p>--</p>
<p>Resumo retirado do texto: O Hábito do “Direito Adquirido”: Ele está nos matando por Judith M. Bardwick.</p>
<p>Aqui no trabalho estamos constantemente buscando o estado/cultura de conquista.</p>
<p>A <a title="Cultura de Conquista – Parte 2" href="/cultura-de-conquista-parte-2/" target="_blank"><strong>segunda parte</strong> deste post</a> falo mais da busca de uma <strong>organização vitoriosa</strong> da cultura de conquista, aspectos como: <strong>pressão</strong>, <strong>desempenho</strong>, <strong>medo</strong> e <strong>estilo de liderança</strong>. Um abraço.</p>
</content>
</entry>
<entry>
<title>Perigo na Zona de Conforto</title>
<link href="https://leandroadacosta.com/perigo-na-zona-de-conforto/"/>
<updated>2011-10-25T00:00:00-02:00</updated>
<id>https://leandroadacosta.com//perigo-na-zona-de-conforto</id>
<content type="html"><p>Este post é um resumo - com minhas considerações - do oficial resumo chamado: <em><strong>O Hábito do "Direito Adquirido": Ele está nos matando</strong> por Judith M. Bardwick</em>.</p>
<p>Retrata um <strong>problema</strong> desconcertante que poucas <strong>organizações</strong> têm coragem de enfrentar de cabeça erguida. Para entendermos melhor, vamos a nascente do conceito "Direito Adquirido", descrito pela autora.</p>
<h2>Não tolere trabalho não-produtivo</h2>
<p>Judith explica que o que <strong>deteriorou o caráter</strong> dos empregados e das organizações americanas foi a prosperidade dos EUA. Graças a prosperidade do após-guerra, quase todos os trabalhadores americanos recebiam <strong>promoções</strong> e <strong>aumentos</strong> regulares - <strong>independentemente</strong> da <strong>qualidade</strong> do seu <strong>trabalho</strong>. É a herança arruinada dos tempos de prosperidade posteriores à Segunda Guerra Mundial. E onde não há qualquer senso de urgência, a motivação decai e a vitalidade evapora, deixando atrás de si um resíduo de complacência e apatia. Mesmo os bons perdem o estímulo quando vêem <strong>trabalho não-produtivo tolerado</strong>.</p>
<p>É preciso entender que as <strong>condições</strong> da rígida economia de hoje <strong>demandam mudança</strong>. O <strong>desafio</strong> como executivo deve ser o de <strong>levar</strong> os <strong>colaboradores</strong> da psicologia do "Direito Adquirido" para a de "<strong>Conquista</strong>".</p>
<blockquote>Eu quero pessoas que desafiem seus chefes todo dia: Por que você me manda fazer essas coisas inúteis? Vai ser normal a pessoa dizer: Droga, não estamos chegando lá. Vamos tratar de fazer isto.</blockquote>
<p>Isto é poder. Eis como Jack Welch, Diretor da General Electric e um campeão de trabalhadores conquistadores os vê como empregados conquistadores.</p>
<h2>Não proteja-os do risco</h2>
<p><strong>Proteja-os do risco</strong> e estará <strong>destruindo</strong> sua auto-estima e roubando-lhes a oportunidade de serem <strong>pessoas fortes e competentes</strong>. A confiança vem do fato de vencer o desafio. Sem confiança, ninguém corre riscos. Sem correr riscos ninguém desenvolve a coragem.</p>
<p>Embora saibamos que a produtividade sofre quando a ansiedade - por causa do risco - é alta, esquecemos de ver o efeito destrutivo da ansiedade muito baixa. Os empregados que recebem mas não produzem, perdem seus parâmetros.</p>
<p>Falando claramente, <strong>tolerância</strong> demais <strong>cria fraco desempenho</strong>. As pessoas produzem precariamente quando não são consideradas responsáveis. Elas se tornam <strong>acomodadas</strong> e <strong>indiferentes</strong> ("Se o resultado não faz diferença, porque tentar?").</p>
<h2>Quebre os padrões</h2>
<p>As <strong>organizações</strong> precisam de <strong>pessoas confiantes</strong> o suficiente para <strong>enfrentar</strong> os <strong>problemas</strong> ecléticos de amanhã, <strong>capazes</strong> de se <strong>adaptar às mudanças</strong>, de <strong>ter disciplina</strong> para <strong>perseverar</strong> e de ter <strong>coragem</strong> para iniciar e <strong>inovar</strong>. Alcançar um estado no qual as pessoas são revigoradas pelo <strong>desafio</strong> e a conscientização de que seu trabalho será premiado com base no trabalho executado que, por sua vez, implica na apresentação de competências humanas importantes.</p>
<p>Necessário frisar-lhes que não se pode levar os empregados diretamente de um extremo ao outro. Pode-se primeiro induzi-los a uma permanência no estado do medo, o medo do risco, ou seja, o risco da mudança.</p>
<p>É difícil destroçar o conceito do "Direito Adquirido", por que geralmente está codificado nas regras e políticas da companhia, tornando a mudança para a psicologia da "Conquista" um choque maior na escala Richter da corporação.</p>
<h2>Buscar o estado de "Conquista"</h2>
<p>Temos uma dura tarefa pela frente. Deveríamos trocar o nome “zona de conforto” para “zona de perigo”.
No post <a title="Cultura de Conquista – Parte 1" href="/cultura-de-conquista-parte-1/">Cultura de Conquista</a> descrevo o posto à cultura do Direito Adquirido.</p>
<p>Espero ter contribuído de alguma forma.
Um abraço.</p>
</content>
</entry>
<entry>
<title>Prática do Sentimento de Produtividade</title>
<link href="https://leandroadacosta.com/pratica-do-sentimento-de-produtividade/"/>
<updated>2011-10-14T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//pratica-do-sentimento-de-produtividade</id>
<content type="html"><h2>Uma questão corriqueira</h2>
<p>Em todas as equipes de desenvolvimento de software conversamos sobre <strong>produtividade</strong>. Nunca passava despercebida em nosso dia a dia. Ela era, e é, motivo de discussão - sempre saudável - em todas as <a href="https://www.flickr.com/photos/cocento/5404128051/in/set-72157625920297498" target="_blank">reuniões diárias</a> e <a href="https://www.flickr.com/photos/cocento/5540468736/in/photostream" target="_blank">retrospectivas</a> dos sprints. Sempre algum membro da equipe perguntava como foi a produtividade no dia ou no sprint.</p>
<!--more-->
<h2>Uma forma diferente</h2>
<p>Todos sabem a importância de serem produtivos e que a <strong>produtividade não quer dizer trabalhar mais horas</strong>. Produtividade está muitas vezes relacionada ao foco, entendimento do que é preciso ser feito, ambiente de trabalho e também ao processo da gestão do projeto. Uma prática que vem ajudando bastante à <strong>identificar os pontos</strong> que influenciam na produtividade é a <strong>reunião diária</strong> e - com muito mais importância - a <strong>retrospectiva</strong> do sprint. Havia um problema de que uns influenciavam os outros na hora de falar. Como produtividade é um assunto permanente em nossas reuniões, dentro de mim ecoava um sentimento de que algo poderia ser melhorado neste sentido.</p>
<p>Achei uma <strong>forma diferente</strong> de falarmos de produtividade quando assisti a <strong>palestra "Melhorando um ambiente ágil."</strong> da <a href="https://twitter.com/cecifernandes" target="_blank">Cecília Fernandez</a> no evento da <a href="https://www.qcon.com.br/" target="_blank">QCon São Paulo 2011</a>. A cultura da <a href="https://www.caelum.com.br" target="_blank">Caelum</a> propicia a melhoria contínua e a Cecília apresentou várias práticas diferentes para promover um ambiente agradável de trabalho. Uma delas era relacionada a produtividade, com essa dica em mãos tive a oportunidade de praticar com a nossa equipe. Na retrospectiva de hoje colhemos alguns <strong>feedbacks</strong> legais, gostaria de compartilhá-los com vocês. Bom, <strong>vamos a prática</strong>, explicarei de forma simples e objetiva.</p>
<h2>Prática do sentimento de produtividade</h2>
<p>É muito simples! Colamos do lado da porta de saída um quadrinho como este:</p>
<p><a href="/img/posts/sentimento-produtividade.jpg"><img src="/img/posts/sentimento-produtividade.jpg" alt="Sentimento de Produtividade" style="max-width:400px" /></a></p>
<p>Cada <strong>pessoa</strong> que saia, riscava - de forma muito <strong>sincera</strong> - como estava se <strong>sentindo</strong> em relação a sua <strong>própria produtividade</strong> (baixa, normal ou alta). Foi bem <strong>interessante a experiência</strong>, no primeiro e segundo dia achamos <strong>um pouco estranho</strong>, mas logo no final da semana e começo da segunda semana, <strong>enxergamos alguns benefícios</strong>. Sentimos mudanças no lado <strong>psicológico</strong> e no lado <strong>comportamental</strong>.</p>
<h3>Lado psicológico:</h3>
<ul>
<li>Bem estar ao sair de um dia produtivo em equipe.</li>
<li>Equipe mais preocupada com o resultado.</li>
<li>Auto análise da produtividade individual e em equipe.</li>
<li>Auto motivação para o próximo dia quando o dia atual - ou anterior - é pouco produtivo.</li>
</ul>
<h3>Lado comportamental:</h3>
<ul>
<li>Aumento do foco.</li>
<li>Aumento da comunicação.</li>
<li>Maior preocupação em fazer o trabalho em equipe.</li>
</ul>
<h2>Benefícios</h2>
<ul>
<li>Conseguimos prezar mais a produtividade do time do que a individual, entendendo o papel produtivo de cada membro para o time.</li>
<li>Melhoramos nosso foco promovendo a produtividade.</li>
<li>Aumentamos nossa cobrança.</li>
<li>Nas retrospectivas não discutimos mais a produtividade em si, e sim, quais foram as barreiras que atrapalhavam a produtividade.</li>
</ul>
<p>Ainda estamos experimentando esta prática, enquanto tivermos efeitos positivos, continuaremos aprimorando.</p>
<p>Espero que tenham gostado.
E você? Topa fazer um quadrinho de sentimento de produtividade para sua equipe? Conte sua experiência :)</p>
</content>
</entry>
<entry>
<title>A arte de ser Mensch</title>
<link href="https://leandroadacosta.com/a-arte-de-ser-mensch/"/>
<updated>2011-10-12T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//a-arte-de-ser-mensch</id>
<content type="html"><p>Este post foi embasado no livro <a href="https://www.submarino.com.br/produto/1/1470751/arte+do+comeco:+o+guia+definitivo+para+iniciar+o+seu+projeto,+a" target="_blank">A arte do começo por Guy Kawazaki</a>. Como esta mencionado no livro: <em>Mensch</em> é o termo em <em><a href="https://pt.wikipedia.org/wiki/L%C3%ADngua_i%C3%ADdiche" target="_blank">iídiche</a></em> que designa uma pessoa ética, íntegra e admirável. O oposto de um <em>Mensch - ser humano -</em> é um <em>Unmensch</em>, que significa uma pessoa absolutamente cruel ou para o mal. A chave para ser um <em>Mensch</em> é ter caráter, dignidade e um senso do que é certo.</p>
<blockquote>"A verdadeira medida de um homem é a maneira como ele trata alguém que não lhe pode ser útil." SAMUEL JOHNSON</blockquote>
<p>O autor Guy Kawazaki incluiu este tópico no livro por dois motivos:</p>
<ol>
<li>Agir de modo que beneficie você e sua empresa em detrimento do restante da sociedade não o tornará melhor.</li>
<li>Se você quiser constituir uma empresa grandiosa e duradoura, precisará estabelecer os mais altos padrões éticos e morais para o seus funcionários.</li>
</ol>
<p>São <strong>três</strong> os <strong>fundamentos</strong> do modo <em>Mensch</em>:</p>
<p><strong>AJUDAR MUITA GENTE</strong></p>
<p>Você precisa somar pontos em seu comportamento durante o tempo que passa neste mundo, e a melhor forma de somar esses pontos é ajudar as pessoas. Não é puro ajudar aquelas pessoas de que você vai precisar um dia. As ajudas que valem mais são: ajudar pessoas em que nunca se sabe se elas possam ajudá-lo um dia; sentir alegria interior em ajudar o próximo; e querer somar pontos cármicos só por via das dúvidas, caso esta teoria esteja correta.</p>
<p><strong>FAÇA O QUE É CORRETO</strong></p>
<p>Fazer o que é correto - não o que é fácil, conveniente, que economiza dinheiro ou que o permita sair ileso. Certo é certo, errado é errado. Sem dúvida, existem verdades absolutas na vida, e os <em>Mensches</em> valorizam e colocam em prática essa verdade.</p>
<p><strong>RETRIBUIR À SOCIEDADE O QUE ELA LHE DÁ</strong></p>
<p>Há muitas "moedas" com que se pode pagar à sociedade esses favores. Fazer doações em dinheiro é apenas uma delas - outras incluem doar tempo, conhecimento e apoio emocional. Os <em>Mensches</em> usam essas moedas para se doar aos outros. O conceito-chave é que o Mensch retribui - ou seja, por algo de bom já recebido -, em vez de estar "pagando adiantado" pelo que espera receber depois.</p>
<p><strong>O autor recomenda um exercício para reflexão:</strong> O fim de sua vida chegou. Relacione as três coisas pelas quais você quer que as pessoas se recordem de você.</p>
<p>E você? Se considera um <em>Mensch</em>? Envie comentários :)</p>
</content>
</entry>
<entry>
<title>Idéia inovadora, Startup!</title>
<link href="https://leandroadacosta.com/ideia-inovadora-startup/"/>
<updated>2011-10-06T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//ideia-inovadora-startup</id>
<content type="html"><p>Surgiu uma <strong>idéia inovadora</strong>, então logo nasce uma <strong>startup</strong>!</p>
<p>Para quem não sabe o termo startup se refere as empresas recém-criadas, em fase de desenvolvimento e evolução do modelo de negócio - aquelas que surgem na garagem, no fundo de quintal de casa, no próprio escritório ou através de projetos investidos por grandes empresas ou incubadoras.</p>
<p>Definição de startup: “Uma instituição humana desenhada para entregar um novo produto ou serviço sob <strong>condições</strong> de <strong>extrema incerteza</strong>” por <strong>Eric Ries</strong>.</p>
<p><a href="/img/posts/startup.jpg"><img src="/img/posts/startup.jpg" alt="Startup a nova tendência." style="max-width:393px" /></a></p>
<p>São elas as <strong>iniciantes</strong> neste mercado imenso e competitivo - geralmente formada por <strong>jovens empreendedores</strong> - que estão em constante busca por inovação e acima de tudo sonham em melhorar o mundo com seus projetos. São elas que lançam produtos e serviços para <strong>solucionar problemas</strong> e <strong>facilitar a vida das pessoas</strong>, são elas que aceleram a economia e principalmente ajudam a contribuir com <strong>algo realmente significativo</strong> para o <strong>mundo</strong>.</p>
<p>A Apple, Microsoft, Google, Facebook, Twitter já foram startups um dia, e hoje são empresas de grande porte que ficaram famosas com seus produtos e serviços. É claro que para ter <strong>sucesso</strong> não é simplesmente ter uma <strong>idéia inovadora</strong> e achar que vai <strong>mudar o mundo</strong>. Começar é fácil, o difícil é continuar e <strong>crescer</strong>. Achar um <strong>modelo de negócio certo e que seja escalável</strong> é o fator crítico de sucesso para a maioria das startups, onde muitas falham no meio do caminho.</p>
<p>O que mais admiro no modo de atuar das startups é que elas buscam por inovar através de um sonho de criar algo realmente significativo para o mundo, por serem constituídas por <strong>pessoas</strong> que queiram <strong>contribuir</strong> para a <strong>evolução</strong> da <strong>humanidade</strong>, por saberem <strong>aprender</strong> continuamente, serem <strong>ágeis</strong>, sem burocracia. Ganhar <strong>vantagem</strong> perante a concorrência com sua <strong>leveza</strong>, <strong>audácia</strong> e seu jeito de pensar totalmente <em>Lean</em> já faz parte da característica de uma startup. Qualquer <strong>oportunidade</strong> é considerada um <strong>desafio</strong> e cada conquista é sempre uma grande vitória.</p>
<p>Conclusão, cada vez mais surgem novas empresas com idéias promissoras, não é preciso ter investimento externo para dar um pontapé inicial em um projeto, basta apenas ter força de vontade, coragem, determinação, perseverança e <strong>planejar menos</strong> e <strong>fazer mais</strong>.</p>
<p>Falarei mais sobre Startup e novos conceitos em outros posts.</p>
<p>E você? Conte um pouco da sua experiência com startups também ;)</p>
</content>
</entry>
<entry>
<title>Jogar Counter-Strike me ajudou a ser um profissional melhor</title>
<link href="https://leandroadacosta.com/jogar-counter-strike-me-ajudou-a-ser-um-profissional-melhor/"/>
<updated>2011-03-16T00:00:00-03:00</updated>
<id>https://leandroadacosta.com//jogar-counter-strike-me-ajudou-a-ser-um-profissional-melhor</id>
<content type="html"><p>Piada? Não! Pelo contrário, tenho essa fase da minha vida como um <strong>aprendizado incrível que me acrescentou muito, tanto no lado pessoal quanto no profissional.</strong> Importou tanto para mim que eu cheguei ao ponto de colocar no meu currículo que joguei um tal jogo de computador chamado <a href="https://pt.wikipedia.org/wiki/Counter-Strike" target="_blank">Counter-Strike</a>. Este jogo para aqueles que nunca escutaram, é o jogo de tiro em primeira pessoa mais conhecido e disseminado do mundo, até ai, não importa, o que eu quero é mostrar o porque do aprendizado no final dessa história.</p>
<p>Muitas qualidades eu adquiri logo cedo, dado que joguei este jogo praticamente 3 anos da minha vida, dos 15 aos 18 anos de idade. Quando comecei a jogar, eu era o chamado “newbie” ou seja, principiante. Não queria ser um newbie, acho que ninguém quer ser um newbie no que faz, por isso queria mais, <strong>queria evoluir</strong>. Chegou um certo momento, depois de muitas horas por dia de dedicação jogando em casa e nas quase “falecidas” lanhouses, que peguei jeito na coisa. Isso me fez enxergar <strong>novas possibilidades</strong> de evolução, consegui quebrar as <strong>crenças limitantes</strong> do meu potencial, queria sempre mais, foi quando<a href="https://www.livrariasaraiva.com.br/produto/400448/a-aguia-e-a-galinha/" target="_blank"> descobri que não era apenas uma galinha e poderia ser uma águia</a>, em um encontro numa <em>lanhouse</em>, vi que existiam times e campeonatos na cidade onde morava - Santos / SP, foi daí que surgiu minha motivação.</p>
<p>O jogo permite você jogar em time de 5 pessoas com um Manager opcional, tanto na internet quanto fisicamente numa <em>lanhouse</em>, existem disputas de campeonatos no Brasil e no mundo todo. Logo tracei o meu <strong>objetivo</strong>: ter um time pra ser o melhor do Brasil - entre os 3 melhores já estava ótimo, também coloquei uma <strong>meta</strong> clara: conquistar isso em no máximo 2 anos para parar de jogar e me dedicar as coisas que dão futuro - estudo e trabalho -, heheh.</p>
<p>Fui atrás disso, montei um time onde eu atuava na linha de frente “matando” todo mundo. Jogamos alguns campeonatos até finalmente conseguir ganhar o primeiro na região. A partir dali ficamos conhecidos pela comunidade, conheci novas pessoas e joguei novos campeonatos até conseguir montar um time. Liderei o time e me dediquei com muita <strong>disciplina</strong> e <strong>comprometimento,</strong> todos os dias da semana pelo menos 4 horas de jogo por dia, sem contar os fins de semana, que pela manhã eram regrados de treinos e treinos. Em tal momento defini a minha meta: ser um dos melhores do Brasil no CS em 1 ano e meio, sendo que nessa época já éramos o melhor time da Baixada Santista.</p>
<p>Fizemos uma fusão com outro time para ganhar patrocínio, montamos o The@Game Team, os fracos saíram e os melhores ficaram, nesse eu fiquei como líder e capitão do time. Meu papel foi influênciar todos a seguir rumo a um objetivo compartilhado por todos, ser o melhor time do Brasil. Éramos em cinco no time, treinamos duro, inclusive com vários times de outras cidades e estados. Fomos para o nosso primeiro campeonato brasileiro de Counter-Strike, e de cara ficamos na 16º posição, tal colocação foi desmotivante para alguns que até pensaram em desistir, meu papel foi sempre de <strong>liderar</strong> e <strong>motivar</strong> o time. Fomos para o nosso segundo campeonato, este já fomos um pouco melhor, ficamos na 10º posição. No terceiro, ficamos na 8º posição, um desistiu, pois achou que chegamos ao nosso máximo, que não íamos alcançar nem se quer a quinta posição, ai entramos em pane pois teríamos que treinar tudo de novo. Nessa hora que entrou fortemente o meu papel e o da equipe de <strong>se esforçar mais que a média</strong>. Conseguimos mais um integrante para time, que por coincidência foi <a href="https://twitter.com/brunoadacosta" target="_blank">meu irmão</a>, onde resgatamos todo o gás para <strong>alcançar a meta</strong>.</p>
<p>Fomos para o quarto campeonato, onde obtivemos a melhor colocação da história do time, <strong>ficamos entre os 3 melhores do Brasil</strong> - pra quem lembra, foi em 2004, os times eram: 1º MiBR, em 2º G3X e a gente em 3º The@Game -, ficamos por um “round” ou “ponto” de ir pra Dallas no Texas jogar o campeonato mundial - isso ainda está entalado na garganta, mas tudo bem, mérito deles. O que importa é que alcançamos a meta e não queríamos mais jogar CS depois disso. Acabou por ai, conseguimos chegar ao nosso objetivo.</p>
<p><strong>Conclusão:</strong> aprendi a ser persistente e não desistir nunca.</p>
<p>Levo importantíssimos aprendizados que me fizeram e me fazem largar na frente, amadureci rapidamente como pessoa e profissional, consegui <strong>enxergar</strong> e saber <strong>entender</strong> o valor de muita coisa numa visão prática, como: <strong>liderança</strong>; <strong>gestão de pessoas</strong>; <strong>gestão de conflitos</strong>; <strong>astúcia</strong>; <strong>espírito de equipe</strong>; <strong>motivação</strong>; <strong>adrenalina</strong>; <strong>competição</strong>; <strong>persistência</strong>; <strong>garra</strong>; <strong>disciplina</strong>; <strong>determinação</strong>; <strong>dedicação</strong>; <strong>foco</strong>; <strong>treino</strong>; <strong>auto-organização</strong>; <strong>comprometimento</strong>; e muitas outras qualidades que um esporte de competição proporciona. Resumindo, essas qualidades aprendidas na prática, mesmo de um jogo de computador, levo como <strong>bagagem</strong> pra minha atuação <strong>profissional</strong> e <strong>pessoal</strong> pro resto da vida.</p>
<p>Alguém já jogou algum jogo que o ajudou ser um profissional melhor? Enviem seus comentários :)</p>
</content>
</entry>
</feed>