{"id":1844,"date":"2018-02-14T13:54:25","date_gmt":"2018-02-14T16:54:25","guid":{"rendered":"http:\/\/www.milfont.org\/tech\/2018\/02\/14\/formato-ideal-para-o-time\/"},"modified":"2018-02-14T13:54:25","modified_gmt":"2018-02-14T16:54:25","slug":"formato-ideal-para-o-time","status":"publish","type":"post","link":"https:\/\/www.milfont.org\/tech\/2018\/02\/14\/formato-ideal-para-o-time\/","title":{"rendered":"Formato ideal para o time"},"content":{"rendered":"

Montando equipes matadoras que voc\u00ea pode\u00a0confiar<\/h4>\n
\n


\n<\/figure>\n

tl;dr<\/a><\/h3>\n

N\u00e3o existe uma f\u00f3rmula pra isso, mas tem como trabalhar.<\/p>\n

Disclaimer<\/h3>\n

N\u00e3o existem dois times iguais simplesmente porque n\u00e3o existem dois seres humanos iguais, cada mudan\u00e7a de um membro voc\u00ea tem um time completamente diferente.<\/p>\n

Portanto j\u00e1 sa\u00edmos com o Mindset de que experi\u00eancias passadas ou paralelas no m\u00e1ximo “ajudar\u00e3o” a guiar o nosso instinto com tend\u00eancias que deram certo ou errado.<\/p>\n

Apelando para o bord\u00e3o: “O todo \u00e9 maior que a soma das partes”.<\/p>\n

Desespero-me?<\/h3>\n

De maneira alguma, vamos aprender com a hist\u00f3ria, sobre o que deu certo e utilizar valores, princ\u00edpios e pr\u00e1ticas que garantam um monitoramento da sa\u00fade do coletivo e construa a cultura e motiva\u00e7\u00e3o adequada a cada indiv\u00edduo.<\/p>\n

Como eram os projetos de produtos de software nos anos\u00a070\/80<\/h3>\n

O formato que as equipes trabalhavam era a produ\u00e7\u00e3o de um software seguindo um modelo tradicional de gerenciamento de projetos, uma equipe desenvolvia e outra recebia para manter.<\/p>\n

\n


\n<\/figure>\n

O que se percebeu na \u00e9poca foi que esse modelo de “On-going” produzia diversos efeitos colaterais no produto final dado que o time que implementava n\u00e3o tinha o mesmo compromisso em qualidade de quem manteria pro resto do tempo em produ\u00e7\u00e3o.<\/p>\n

Al\u00e9m do fato de que projetos usavam times diferentes at\u00e9 na constru\u00e7\u00e3o antes da ida pra produ\u00e7\u00e3o, principalmente entre as fases de concep\u00e7\u00e3o e implementa\u00e7\u00e3o.<\/p>\n

Como a grande maioria dos projetos atrasavam e os testes ficavam como fase final, era comum serem relegados em prol da data de entrega.<\/p>\n

Eram comuns tamb\u00e9m projetos demorarem 2 anos at\u00e9 serem colocados em produ\u00e7\u00e3o, alguns levavam quase meia d\u00e9cada (em off, eu trabalhei em um que levou uma d\u00e9cada pra entrar em produ\u00e7\u00e3o).<\/p>\n

F\u00e1bula da galinho e do\u00a0porco<\/a><\/h3>\n

V\u00e1rios profissionais experientes estavam desenvolvendo um modelo alternativo no in\u00edcio dos anos 90 (alguns iniciaram at\u00e9 um pouco antes), trocando informa\u00e7\u00f5es entre si e por volta do final da d\u00e9cada voc\u00ea tem algumas metodologias e m\u00e9todos bem definidos e maduros.<\/p>\n

Em 2001 nasce o famoso Manifesto \u00e1gil<\/a>, que seria o contrato de valores fundamentais que definia o comum que esses modelos traziam para resolver os problemas na constru\u00e7\u00e3o de Software.<\/p>\n

Em resumo, daqui pra frente a abordagem de pensar em produto em vez de projeto e um time que deveria ter o compromisso na qualidade e ciclo de vida deste produto foi algo que deveria permeiar entre eles.<\/p>\n

\n


\n<\/figure>\n

Entre outras coisas, conceitos como trazer os testes pra frente, j\u00e1 sabemos que sempre vai atrasar algo, ent\u00e3o que a qualidade n\u00e3o seja comprometida.<\/p>\n

Ultimamente Deploy cont\u00ednuo<\/a>, colocar em produ\u00e7\u00e3o desde o primeiro dia pra ir ajustando a arquitetura com ferramental, monitoramento e Status Check<\/a>.<\/p>\n

\n

“Ultimamente” entre aspas duplas, isso j\u00e1 tem pelo menos uma d\u00e9cada.<\/p>\n<\/blockquote>\n

Quem falou primeiro em equipes multidisciplinares<\/h3>\n

V\u00e1rios autores da era Agile estavam referenciando times multidisciplinares e desenvolvimento de produtos.<\/p>\n

Voc\u00ea tem um claro vi\u00e9s da transi\u00e7\u00e3o nessa \u00e9poca no t\u00f3pico “Production Support Team” no livro do Kent Beck, chamado Planning Extreme Programming<\/a> de 2000.<\/p>\n

Trecho desse t\u00f3pico:<\/p>\n

\n

Two or four programmers volunteer to focus on fixing bugs. Each programmer spends a couple of iterations in production support, then rotates back to development. Every iteration there is at least one devel- oper doing their first iteration and at least one doing the second. This works well in that there is a pair that has the responsibility for dealing with support issues and this (usually unpleasant) work is rotated around the team. Actually it\u2019s not the rotation that is key, it is the fact that the team decides themselves how to handle it.<\/p>\n<\/blockquote>\n

Em tradu\u00e7\u00e3o livre:<\/p>\n

\n

Dois ou quatro (1) programadores volunt\u00e1rios para focar no conserto de bugs. Cada programador levaria um par de itera\u00e7\u00f5es no suporte em produ\u00e7\u00e3o, ent\u00e3o rotacionam (2) de volta ao desenvolvimento. Cada itera\u00e7\u00e3o tem pelo menos um dev fazendo sua primeira itera\u00e7\u00e3o e outro fazendo a sua segunda. Isso funciona bem quando um par tem a responsabilidade de lidar com quest\u00f5es de suporte e este (geralmente desagrad\u00e1vel) trabalho \u00e9 rotacionado em torno do time. Na verdade, n\u00e3o \u00e9 a rota\u00e7\u00e3o que \u00e9 a chave, \u00e9 o fato de que o time decide por si s\u00f3 como lidar com isso.<\/p>\n<\/blockquote>\n

(1) Observe que n\u00famero par, pra trabalhar no princ\u00edpio de Pair Programming<\/em> do XP.<\/p>\n

(2) XP tem algumas pr\u00e1ticas como Move People Around<\/em> pra todos no time trabalharem em praticamente todos os requisitos e tecnologias.<\/p>\n

Projeto tem come\u00e7o, meio e fim. Mas um produto de software por ser male\u00e1vel e evolutivo se difere do produto cl\u00e1ssico das literaturas anteriores, dificilmente voc\u00ea vai matar um legado e na minha experi\u00eancia nem faz sentido.<\/p>\n

Afinal se aquela folha de pagamento est\u00e1 funcionando em Cobol, n\u00e3o temos tempo e dinheiro suficiente que demande uma mudan\u00e7a em vez de trabalhar em prol de novas abordagens de neg\u00f3cio.<\/p>\n

Modelo Squads e\u00a0Guildas<\/h3>\n

N\u00e3o poderia deixar de citar o Spotify<\/a> que chamou a aten\u00e7\u00e3o ultimamente para seu modelo multidisciplinar em torno da abordagem de constru\u00e7\u00e3o de produtos. Uma evolu\u00e7\u00e3o do pensamento dessas \u00faltimas duas d\u00e9cadas no m\u00ednimo.<\/p>\n

\n

https:\/\/medium.com\/project-management-learnings\/spotify-squad-framework-part-i-8f74bcfcd761<\/a><\/figcaption><\/figure>\n

Um epis\u00f3dio bem leve e bacana sobre isso voc\u00ea escuta no Hipsters em seguida.<\/p>\n

https:\/\/podtail.com\/en\/podcast\/hipsters-ponto-tech\/<\/a><\/p>\n

Como selecionar o profissional certo?<\/h3>\n

Existem 3 tipos de profissionais quando falamos sobre evolu\u00e7\u00e3o de uma produto em rela\u00e7\u00e3o a tecnologia com times multidisciplinares:<\/p>\n

    \n
  1. Aqueles que por algum motivo se apegam a uma tecnologia e a defender\u00e3o com qualquer argumento para n\u00e3o haver mudan\u00e7a;<\/li>\n
  2. Aqueles que s\u00e3o Early Adopters e n\u00e3o querem trabalhar de forma alguma com legado;<\/li>\n
  3. Aqueles que entendem a necessidade e compromisso de ter que manter o legado, mas se sentem incomodados e gostariam de evoluir pra pr\u00f3xima tend\u00eancia.<\/li>\n<\/ol>\n

    Existem Trade-offs nas 3 abordagens na minha experi\u00eancia, na m\u00e9dia desses profissionais voc\u00ea tem as seguintes caracter\u00edsticas respectivamente:<\/p>\n

      \n
    1. S\u00e3o extremamente especialistas, conhecem a plataforma como ningu\u00e9m e s\u00e3o mais aptos a solucionar problemas do presente, mas alimentam a ojeriza de qualquer mudan\u00e7a e at\u00e9 podem sabotar de forma inconsciente;<\/li>\n
    2. S\u00e3o especialistas em multi plataformas, est\u00e3o preparados para o novo, mas contribuem pouco durante a evolu\u00e7\u00e3o em rela\u00e7\u00e3o a manuten\u00e7\u00e3o do legado, em contrapartida s\u00e3o os guiadores do processo de substitui\u00e7\u00e3o;<\/li>\n
    3. S\u00e3o generalistas que podem atuar nas 11 posi\u00e7\u00f5es (tomando analogia do futebol), n\u00e3o guiar\u00e3o o processo de mudan\u00e7a, mas tamb\u00e9m n\u00e3o ser\u00e3o uma barreira de ado\u00e7\u00e3o.<\/li>\n<\/ol>\n
      \n


      \n<\/figure>\n

      N\u00e3o quero “defecar” regra de qual tipo voc\u00ea deve dar aten\u00e7\u00e3o, acredito que \u00e9 inevit\u00e1vel ter os 3 formatos no seu esquadr\u00e3o, portanto \u00e9 saber liderar e dosar o posicionamento correto de atua\u00e7\u00e3o entre os perfis.<\/p>\n

      Colocar o generalista ou o especialista do legado por exemplo pra puxar uma migra\u00e7\u00e3o vai ser um tiro contra todos, vai conseguir desagradar a gregos e troianos.<\/p>\n

      Da mesma forma que colocar o Early Adopter pra manter legado e corrigir bugs vai s\u00f3 provocar ci\u00fames em quem ama a tecnologia e deveria ser o “dono”.<\/p>\n

      Mas claro, n\u00e3o s\u00e3o conselhos preditivos, existem graus entre os tipos e mais uma vez saber dosar requer um pouco de trabalho.<\/p>\n

      Al\u00e9m da diferen\u00e7a entre especialidade vs generalidade<\/a>, voc\u00ea ainda enfrente a senioridade do profissional<\/a>.<\/p>\n

      Efeito S\u00e1vio, Rom\u00e1rio e\u00a0Edmundo<\/h3>\n
      \n

      Montar um time de estrelas quase nunca\u00a0funciona<\/figcaption><\/figure>\n

      A melhor sele\u00e7\u00e3o brasileira de futebol considerada pelos cr\u00edticos foi a de 82\/86 com craques do porte de Zico e S\u00f3crates perdendo penalti.<\/p>\n

      Voc\u00ea tem v\u00e1rios experimentos que unir muitas estrelas com o ego inflado vai provocar mais danos na moral do time do que resultados, al\u00e9m do que voc\u00ea provavelmente tem o Budget apenas pra montar um time coeso e defensivo com um bom artilheiro na frente e ganhar o tetra.<\/p>\n

      Feedback e\u00a0Cultura<\/h3>\n

      Como citei antes, dificilmente voc\u00ea vai conseguir matar um legado inteiro, ent\u00e3o ter um time que consiga atuar bem em torno dos objetivos do produto demanda cuidar da cultura<\/a> e um processo de Feedback<\/a> que consiga identificar que tipo de profissional trabalha com voc\u00ea e n\u00e3o confiar apenas no instinto na hora de delegar responsabilidades.<\/p>\n

      Muitas vezes voc\u00ea atribui que algu\u00e9m est\u00e1 acomodado ou n\u00e3o gostaria de evoluir uma plataforma, mas a cultura do seu ambiente n\u00e3o privilegia ou piora o desenvolvimento pessoal.<\/p>\n

      Algumas vezes o sujeito s\u00f3 est\u00e1 na hora errada em rela\u00e7\u00e3o as suas motiva\u00e7\u00f5es pessoais ou no time errado para suas habilidades.<\/p>\n

      Mas n\u00e3o quero dizer que voc\u00ea n\u00e3o deve ter profissionais caros e bons, claro que precisa, s\u00f3 que n\u00e3o precisam e dificilmente ser\u00e3o todos ou ter que remontar o time inteiro (aqui existem dezenas de vari\u00e1veis a se discutir).<\/p>\n

      \u00c9 f\u00e1cil?<\/h3>\n

      De forma alguma, mas temos literatura suficiente j\u00e1 “antiga” pra utilizar.<\/p>\n

      \n


      \n<\/figure>\n

      Em resumo o formato que melhor funciona durante toda a hist\u00f3ria do desenvolvimento de software \u00e9 um time multidisciplinar com multisenioridade construindo um produto com autonomia completa se preocupando com todas as pr\u00e1ticas de engenharia em prol da entrega, mas pensando ciclicamente na evolu\u00e7\u00e3o constante e qualidade total.<\/p>\n

      Ent\u00e3o para montar esse time crie uma jornada interessante, convoque m\u00faltiplos perfis adequados para ela e os motive com o objetivo certo, que \u00e9 construir um produto sem defeitos e que entregue valor adequado a quem tem o problema que ele se disp\u00f5e a resolver e est\u00e1 disposto a utilizar!<\/p>\n","protected":false},"excerpt":{"rendered":"

      Montando equipes matadoras que voc\u00ea pode\u00a0confiar tl;dr N\u00e3o existe uma f\u00f3rmula pra isso, mas tem como trabalhar. Disclaimer N\u00e3o existem dois times iguais simplesmente porque n\u00e3o existem dois seres humanos iguais, cada mudan\u00e7a de um membro voc\u00ea tem um time completamente diferente. Portanto j\u00e1 sa\u00edmos com o Mindset de que experi\u00eancias passadas ou paralelas no […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts\/1844"}],"collection":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/comments?post=1844"}],"version-history":[{"count":0,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts\/1844\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/media?parent=1844"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/categories?post=1844"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/tags?post=1844"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}