Definição
Aceite por completo as suas vulnerabilidades para poder melhorar a sua vida, o seu trabalho e os seus relacionamentos.
Ser Imperfeito¶
- A imperfeição e a vulnerabilidade são dois aspectos que são incessantemente escondidos pela sociedade;
- A sensação de que não somos bons o suficiente nos coloca em um ciclo de comparação, vergonha e desmotivação;
- Entender onde estamos contra o que lutamos e a onde precisamos chegar creio que podemos fazer isso melhor ao examinarmos a ideia tão difundida e nunca nos julgarmos bons o bastante;
- Precisamos ser os mais bonitos, ter o corpo perfeito, de ser o bastante em casa, no trabalho e na cama, não podemos ter defeitos e nem nossas fraquezas.
- Vivemos tentando negar nossos defeitos e fraquezas, resistindo à verdade e nos sucumbindo a uma vida de ilusões;
- E como dizia Carl Gustav Jung, "O que você RESISTE, PERSISTE".
- A mulher é muito afetada, primeiro pela aparência:
- Que mulheres sejam magras, jovens ou bonitas o bastante;
- Pressão da maternidade: se vão casar, quando vão casar, quando vão ter filhos, quando vão ter o segundo filho, como está a educação dos filhos;
- As mulheres sejam perfeitas;
- Com os homens, a pressão está totalmente em uma única mensagem dura e impiedosa:
- Não seja considerado fraco;
- Não tenha medo e não fracasse;
- Nossa cultura valoriza o sucesso, a força, a vitória. Por causa disso, nós fomos educados a considerar a vulnerabilidade como algo ruim, como um sinal de fraqueza, de fracasso, de decepção.
- A vulnerabilidade é uma força que está na raiz de sentimentos positivos.
- A vergonha impede você de mostrar o seu trabalho em público, de expressar os seus sentimentos, de tentar coisas novas.
- Existe um preço muito alto que nós pagamos para evitar o sentimento de não merecimento.
Showciedade a Epidemia de Narcisismo¶
- Você compara as suas férias com as dos outros, a sua casa, a sua carreira, a sua própria vida.
- Inversão dos Pronomes pessoais:
- Um grupo de pesquisadores fez uma análise em três décadas de canções que chegaram ao topo das paradas de sucesso eles registraram uma tendência estatística significativa para o narcisismo;
- A hostilidade na música popular em consonância com a hipótese encontrar uma diminuição expressiva do uso de nós e nosso e um aumento do uso de Eu e meu os pesquisadores também relataram um declínio das palavras relacionadas a solidariedade emoções positivas e um aumento das palavras relacionadas a ira e comportamentos anti-sociais como ódio;
- Epidemia do narcisismo argumentaram que a incidência do transtorno de personalidade narcisista mais que dobrou nos Estados Unidos nos últimos dez anos então é isso estão cercadas de narcisistas nós nos transformamos em uma sociedade de pessoas egoístas e pretensiosas que só se interessam por poder sucesso beleza e em se tornarem importantes.
- Será que estamos com o ego tão inflado que acreditamos ser superiores mesmo quando não estamos contribuindo com nada relevante nem produzindo algo de valor se você é como eu provavelmente estará.
- E é óbvio, quando paramos para analisar, como esses dois arquétipos nos colocam em caixas que na grande maioria das vezes não cabemos...
Resumo¶
Seja mais vulnerável e libere seu potencial¶
- E por muitas vezes nós deixamos grandes momentos da vida passar, porque temos medo de nos tornarmos vulneráveis.
- Se você já esteve em um relacionamento, você já teve medo de mostrar o quanto você ama seu parceiro ou parceira, porque se você o fizesse, você se sentiria vulnerável?
- E outra, você já esteve em um momento muito, mas muito feliz da sua vida, um momento de pura felicidade, mas que no momento seguinte foi tomado por imagens de coisas terríveis acontecendo com você...
- QUANDO PASSAMOS NOSSAS VIDAS (consciente ou inconscientemente) FUGINDO DA VULNERABILIDADE, NÓS NOS FECHAMOS PARA AS INCERTEZAS, OS RISCOS E A EXPOSIÇÃO EMOCIONAL DA ALEGRIA.
Não fuja de vulnerabilidade, aceite.¶
- E um dos problemas de não aceitar a vulnerabilidade, é que queremos ser perfeitos em tudo.
- "Se não formos, o que os outros vão pensar?"
- E aí nos cobramos excessivamente e não aceitamos nossas falhas e imperfeições;
- Não que deveríamos viver totalmente zens e sem cobrança nenhuma, mas por quantas vezes você já deixou de fazer algo com medo de errar, ou ficou estressado porque estava se cobrando demais?
- Sabe aquela primeira pessoa que você conversa quando acorda, aquela que você olha no espelho... você é amigo dela? Sim, estou falando sobre você mesmo: você é seu amigo?
- Então, converse com você mesmo com o mesmo amor e compaixão que você conversa com seus maiores amigos e com as pessoas que você ama.
Seja o seu próprio amigo¶
E essas foram 3 das outras grandes ideias contidas no livro A CORAGEM DE SER IMPERFEITO, algo que todos nós tínhamos que tirar um tempinho para pensar. Não é possível ser corajoso sem ser vulnerável.
- A sensação de que você não é suficiente gera um ciclo vicioso de comparação, vergonha e desmotivação que te impede de evoluir.
- E se na verdade criar uma cultura de vulnerabilidades for a melhor estratégia para atingir o seu pleno potencial?
- E se mostrar as suas imperfeições em público for o melhor caminho para perder a vergonha de quem você realmente é?
- Quando cometemos algum erro, podemos ficar com um sentimento de vergonha.
- E essa vergonha nos impede de atingir o nosso potencial.
- Você vai descobrir como esse sentimento de vergonha gera uma sensação de não merecimento.
- O medo de se desconectar do grupo social
- Vergonha é o medo de se desconectar do seu grupo social por não ser bom o suficiente.
- Você com certeza já deixou de fazer alguma coisa por ter vergonha do que os outros vão pensar.
- Nós evoluímos para buscar a companhia das outras pessoas, para pertencer a uma sociedade, para ter a proteção de um grupo.
- Essa necessidade humana básica de conexão, amor e pertencimento é muito forte.
- Somos biologicamente selecionados para nos importarmos com a opinião dos outros.
- E por isso nós temos tanto medo do que os outros vão pensar de nós.
- A vergonha vem do nosso medo de não sermos merecedores do amor, da conexão ou do pertencimento ao nosso grupo social.
- Muitas vezes esse receio até impede que você faça ou mostre o seu trabalho, já que você não quer ter a sensação de que não merece pertencer ao seu grupo.
- Esse tipo de comparação gera em você um sentimento de vergonha, um medo de que você não é ou não tem o suficiente, e que por isso não merece participar de um certo grupo social, de receber amor e conexão de outras pessoas.
Muitas vezes esse sentimento leva a uma desmotivação, a uma paralisia: já que aqueles padrões de comparação são inalcançáveis, já que você não merece ter tudo aquilo, então você simplesmente desiste de tentar melhorar. Esse ciclo vicioso pode ser quebrado se você admitir e começar a expor para você mesmo e para todo mundo quais são as suas vulnerabilidades.
- A nossa cultura atual traz uma sensação de que nós nunca somos o suficiente, de que nunca temos o suficiente.
- Estamos sempre vendo nas redes sociais realizações profissionais, fotos de férias, quantidades de amigos… muitas vezes até com inveja do que as outras pessoas estão fazendo.
- Nós tentamos superar essa inveja, essa sensação de escassez, querendo sempre ser mais, ter mais, fazer mais, sempre presos ao nosso próprio ego.
- A passar a enxergar a vulnerabilidade não como uma fraqueza, mas sim como uma força, como algo que está na raiz de emoções positivas como amor, empatia e satisfação com a vida.
- Expor suas vulnerabilidades requer coragem porque é muito mais fácil evitar toda possibilidade de rejeição ou fracasso simplesmente evitando tomar qualquer risco.
- Realmente, se você ficar quieto sem fazer nada, não vai receber nenhuma crítica, mas também não vai se desenvolver.
- É preciso ter coragem de ser imperfeito.
- De mostrar o seu trabalho mesmo com falhas, de expor suas ideias mesmo que elas tenham alguns erros, de se arriscar a fazer algo que você ainda não domina.
- Se você aceitar que a vulnerabilidade é uma força, então você pode abraçar completamente as suas imperfeições.
Aliás, você até pode usar essas imperfeições a seu favor.
- Nós sempre tentamos esconder as nossas vulnerabilidades porque aprendemos desde crianças que ser vulnerável era algo ruim, uma característica negativa.
- Mas agora aprendemos que a vulnerabilidade na verdade é uma qualidade, uma força, algo que está na raiz de muitas emoções positivas.
- Quando você aceita, abraça e até expõe as suas vulnerabilidades, fica muito mais simples você encontrar espaços para se desenvolver a sua vida, o seu trabalho e os seus relacionamentos.
- Ao mesmo tempo, fica mais fácil você ter empatia com as emoções das outras pessoas, permitindo que você se conecte com os outros de um jeito mais natural.
- No campo profissional, a melhor maneira de progredir é se arriscando e ousando expor o seu trabalho para a crítica dos seus colegas.
- Se você passar a vida fazendo apenas o que já domina fazer, evitando o risco de fracasso, você não vai aprender coisas novas e não vai progredir na carreira.
- É preciso ter coragem para ser imperfeito, pois nós fomos educados para ter medo das críticas.
- Quem importa é a pessoa que luta, que erra e tenta de novo e de novo. Na pior das hipóteses, se ela falhar, pelo menos ela vai falhar agindo. O crítico que só olha de longe não está agindo.
- E quem não age corre o risco de viver uma vida fria, tímida, vazia... sem conhecer nem vitória nem derrota.
- Abandonar a vergonha é o melhor caminho para aceitar por completo as suas imperfeições. Vergonha é o medo de expor as próprias vulnerabilidades.
- Por isso, se você quer usar as suas imperfeições a seu favor, você precisa deixar a vergonha de lado.
- Muitas vezes, o sentimento de vergonha é muito mais doloroso do que o fato do qual você está se envergonhando.
Os problemas que criamos na nossa cabeça são muito mais poderosos do que os problemas que enfrentamos na vida real.
- Na sabedoria popular, nós dizemos que os adolescentes se preocupam muito com o que os outros pensam deles.
- Os adultos já não se importam mais com o que os outros pensam deles.
- E os idosos, mais sábios, finalmente descobrem que na verdade ninguém pensava tanto neles como se imaginava.
- Se o seu receio do que os outros pensam é tão grande que impede você de viver a vida, então é hora de realizar mudanças.
- O melhor jeito de diminuir o poder desse sentimento de vergonha é tendo clareza sobre quais medos são esses.
- Quanto menos você fala sobre ela, mais controle a vergonha tem sobre a sua vida.
- Por isso, verbalizar a sua vergonha deixa você mais resiliente a ela.
- Você fica pensando que se for uma pessoa mais rica, mais bonita ou mais bem sucedida, então vai ter menos sofrimento na sua vida.
- As suas imperfeições não podem ser eliminadas, mas no máximo escondidas.
- Tentamos esconder as nossas fraquezas.
- Escondemos dos outros e até de nós mesmos.
- Em vez disso, você poderia abrir mão desse sentimento de nunca ser ou ter o suficiente.
- Poderia abrir mão desse desejo de querer sempre se aproximar da perfeição.
- E simplesmente se contentar com quem você já é, aceitando as suas vulnerabilidades.
- Existe uma antiga prática do estoicismo que é conhecida como Amor Fati [https://arata.se/oi218].
- A coragem de ser imperfeito traz melhorias para casas, escolas e empresas.
- Em ambientes competitivos como escolas, empresas e às vezes até dentro de casa, muitas pessoas tentam demonstrar invulnerabilidade.
- Por tudo que já conversamos aqui, dá para entender que esse é um comportamento tóxico.
- Casas, escolas e empresas seriam ambientes bem mais leves se as pessoas estivessem dispostas a assumir as próprias imperfeições, se fossem abertas sobre as próprias emoções, se aceitassem os próprios defeitos.
- Por isso, se tiver a oportunidade, experimente levar para a sua casa, escola ou empresa a ideia de que vulnerabilidade é algo positivo.
- Que não precisamos ter vergonha de quem nós somos.
- A Coragem de Ser Imperfeito pode ser um livro transformador, se você adotar para a sua vida a ideia de abandonar a vergonha, aceitar as suas imperfeições e principalmente usar as suas vulnerabilidades como algo positivo.
- Para isso, você precisa ser aberto sobre as suas emoções com você mesmo e com os outros.
- Precisa ser aberto para tomar riscos, aceitar críticas, enfrentar os próprios medos.
- Isso só pode ser feito quando você tiver clareza de que a vergonha é simplesmente o medo do que os outros vão pensar de você.
- Entendendo e principalmente verbalizando a sua vergonha, você fica mais resiliente a ela, aceitando a sua vulnerabilidade e abrindo caminho para uma vida com mais felicidade.
- Esse é um treinamento online que usa técnicas comprovadas da psicologia positiva para você aumentar os seus níveis de felicidade por meio de exercícios práticos que você pode começar a fazer hoje mesmo.
- Basta acessar https://arata.se/felicidade
-
Ter vergonha o medo do ridículo e a depreciação são usados para controlar as pessoas e mantê-las na linha apontar culpados é uma prática comum o valor de alguém está ligado ao sucesso a produtividade ou a obediência humilhações linguagem abusiva são frequentes e quanto ao favoritismo o perfeccionismo é uma realidade comparação a competição saudável pode ser benéfica mas a comparação e disputa o tempo todo velada ou abertamente a criatividade tem sido sufocada as pessoas são confinados a padrões estreitos em vez de serem valorizadas por suas contribuições e talentos específicos a um modo ideal de ser ou um tipo de habilidade usado como medida de valor para todos As pessoas estão com medo de correr riscos ou tentar coisas novas e três desmotivação as pessoas estão com medo de correr riscos ou tentar coisas novas é mais fácil ficar quieto do que compartilhar ideias histórias e experiências a impressão geral é de que ninguém está realmente prestando atenção ou escutando todos estão se esforçando para serem vistos e ouvidos e quando vejo essas perguntas e penso sobre a nossa macro sociedade a mídia e o panorama social econômico e político minhas respostas são sim sim e sim
-
Vulnerabilidade não é algo bom nem mau não é o que chamamos de emoção negativa e nem sempre é uma luz uma experiência positiva ela é o centro de todas as emoções e sim se sentir é estar vulnerável acreditar que vulnerabilidade seja fraqueza é o mesmo que acreditar que qualquer sentimento seja fraqueza abrir mão de nossas emoções por medo de que o custo seja muito alto significa nos afastarmos da única coisa que dá sentido e significado à vida nossa rejeição da vulnerabilidade deriva com frequência da associação que fazemos entre ela e as emoções sombrias como o medo a vergonha o sofrimento à
É uma sentença declarativa aparentemente verdadeira mas que leva a uma contradição lógica ou simplesmente a algo que contradiz a intuição.
Paradoxo do Pinóquio¶
Pinóquio é reconhecidamente um dos ícones da cultura moderna, criado como um boneco de madeira que sonha em ser um menino de verdade, ele é mais conhecido por suas mentiras.
Trata-se de um conflito de lógica baseado na famosa história infantil do boneco Pinóquio, cujo nariz crescia sempre que o mesmo contava uma mentira.
Mas se Pinóquio dissesse “Meu nariz irá crescer agora”, você sabe dizer o que aconteceria? Seu nariz iria crescer ou não?
- A sentença do mentiroso nos leva a uma contradição quando tentamos determinar se ela é verdadeira ou não.
- Ou seja, se a afirmação de Pinóquio for verdadeira então seu nariz crescerá, o que significa que ela é falsa.
Neste caso, duas hipóteses, igualmente válidas poderiam acontecer:
- O nariz de Pinóquio não cresce. Então ele disse uma mentira, portanto, o nariz deve crescer;
- O nariz de Pinóquio cresce. Então ele disse uma verdade, portanto, o nariz dele não tinha motivo para ter crescido.
Paradoxo da Escolha¶
Barry Schwartz - Um maior número de escolhas concede-nos mais liberdade. No entanto, demasiadas opções limitam-nos a capacidade de decisão.
Crise de indecisão e insatisfação nos consumidores, em vez de impulsionar as compras.
Não é suposto contentarmo-nos com nada, a menos que seja o melhor. O mundo digital está a agudizar o problema, porque, ao abrir um mundo de possibilidades infinitas, também criou o FOMO (fear of missing out - medo de perder) e um medo cada vez maior de fazer a escolha errada, num mar de ofertas.
A escolha num leque alargado de opções pode provocar mais stress, mais erros,menos satisfação e, até, burnout.
Quando a oferta é muito ampla, pode ser que as pessoas não consigam escolher o produto mais adequado e até deixem de fazer a compra.
Essa ideia pode soar contraditória, mas é exatamente isso que acontece na mente humana, que se vê sobrecarregada e confusa diante de tantas opções no mercado atual.
Paradoxo da Escolha agindo no nosso dia a dia.¶
- Quanto tempo você passa escolhendo o que assistir na Netflix, Apple TV, Disney+, etc?
- Resposta: É provável que o consumo tome muito mais tempo na sua vida hoje em dia, porque o número de opções aumentou.
- Resposta: Ou, deixei de escolhar, o software de Stream, escolhe para mim.
A responsabilidade é enorme, pois cabe a você entender as características de cada produto, comparar marcas, pesquisar preços e definir prioridades.
- Paralisia - Aprendizado e ao desenvolvimento intelectual.
- Custo da oportunidade e comparação - Ela sente que tem algo a perder, ou seja, um custo.
- Transferência de responsabilidade - A responsabilidade sobre uma decisão ruim se transfere totalmente para o consumidor, se escolher errado, fica o sentimento de que a culpa é dele e não da empresa, que ofereceu muitas chances.
- Arrependimento - Ela vai se lembrar das vantagens daquelas que rejeitou.
A empresa, produto tem que existir além de seu criador. Entenda que criação é diferente de criatividade, mas é óbvio, que a criação pode inserir em criatividade, ou seja, trago algo criativo ou com uma outra leitura.
Outros Paradoxos¶
- Fábrica de Botas: Fábrica de Botas um botando a culpa no outro.
- Paradoxo Homer Simpson: "CULPA É MINHA E COLOCO EM QUEM EU QUISER"?
- Paradoxo da Laranja : Bolo de Limão (casca) e Suco de Laranja (Sumo). Apenas UM LARANJA.
- Paradoxo do KuDum: Se você não estimula, tira de um cú de um, coloca no cú de outro.
Conceitualmente refere-se ao mundo das ideias e do pensamento humano.
Pode ser definido como o conjunto de todas as mentes humanas interconectadas, tendo sua origem do grego νους (nous, "mente")
em um sentido semelhante à atmosfera e biosfera.
Os seres humanos têm um impulso inato para competir por status social; ele está conectado por nossa história evolutiva.
A maioria das formas que os humanos têm de se organizar são adaptações à escassez e à carência.
Nossa sociedade é predominantemente uma economia de troca.
O status social é determinado não pelo que você controla, mas pelo que você dá.
Como se pode maximizar a qualidade se não há uma métrica para qualidade?
Você pode não trabalhar para obter reputação, mas a reputação é um pagamento real com consequências se você fizer bem o trabalho.
Sociologia¶
Em 1991, aos primeiros experimentos de Linus Torvalds, William e Lynne Jolitz, na construção do Linux, a característica mais importante do Linux, no entanto, não era técnica, mas sociológica, todos acreditavam que qualquer software tão complexo quanto um sistema operacional tinha que ser desenvolvido de forma cuidadosamente coordenada por um grupo relativamente pequeno e unido de pessoas,a qualidade era mantida não por padrões rígidos ou autocracia, mas pela estratégia ingenuamente simples de lançar toda semana e obter feedback de centenas de usuários em poucos dias, criando uma espécie de seleção darwiniana rápida nas mutações introduzidas pelos desenvolvedores.
- Linus Torvalds
- Libere cedo e frequentemente, delegue tudo o que puder, esteja aberto ao ponto da promiscuidade — foi uma surpresa;
- Release early. Release often. And listen to your customers;
- Linus estava mantendo seus hackers/usuários constantemente estimulados e recompensados — estimulados pela perspectiva de ter uma parte da ação que satisfizesse o ego, recompensados pela visão de melhoria constante (mesmo diária) em seu trabalho.
- Eric S. Raymond, CUNHOU a lei de Linus: "Dada uma base grande o suficiente de beta-testers e co-desenvolvedores , quase todos os problemas serão caracterizados rapidamente e a correção óbvia para alguém." - "given enough eyeballs, all bugs are shallow".
- Restrições legais de várias licenças, segredos comerciais e interesses comerciais.
- O desenvolvedor que usa apenas seu próprio cérebro em um projeto fechado vai ficar para trás do desenvolvedor que sabe como criar um contexto aberto e evolucionário no qual o feedback explorando o espaço de design, contribuições de código, detecção de bugs e outras melhorias vêm de centenas (talvez milhares) de pessoas.
- Linux foi o primeiro projeto para o qual foi feito um esforço consciente e bem sucedido para usar o mundo inteiro como seu pool de talentos.
- Conjunto de costumes cooperativos que pudessem permitir que os desenvolvedores atraíssem codesenvolvedores e obtivessem o máximo aproveitamento do meio.
- Memórias de um revolucionário Pyotr Alexeyvich Kropotkin: "Entre agir com base no princípio de comando e disciplina e agir com base no princípio do entendimento comum.";
- Mutual Aid: An Illuminated Factor of Evolution, "Contra a competição, pela cooperação.", pois derrubou dogma crucial ao liberalismo e demonstrou a centralidade da cooperação – nas sociedades e na própria evolução das espécies.
Expressões
Ter uma definição clara dentro da mesma organização é vital para adotar uma cultura InnerSource dentro da sua organização.
Sem um entendimento claro e direção correta, é fácil para os membros da equipe se perderem em sua própria direção de onde ir.
O que vivenciei?¶
Qual é a parte mais desafiadora do desenvolvimento de software na sua organização?
- Sobrecarregado com a quantidade de código que precisa manter em sua organização?
- Equipes escreveram códigos que duplicam funcionalidades escritas por outra equipe?
- Equipes reescrevem o código que herdaram porque não o entendem ou acham que não é bom, apenas para encontrar problemas encontrados antes?
- Você conhece algum código em execução em produção que você não se sentiria confortável em mostrar a outra pessoa?
- Você conhece equipes que lutam para se comunicar e colaborar efetivamente apesar das fronteiras temporais, geográficas e culturais?
- Você reconhece oportunidades para aumentar os níveis de abertura, transparência e participação dentro da sua organização?
Por que?¶
- A "abertura" do projeto se estende a muitas equipes dentro da organização;
- A reutilização de código em toda a organização cresce imensamente;
- A colaboração entre equipes se torna relativamente sem atrito;
- O desenvolvimento se torna mais rápido;
- A documentação de qualidade é detectável;
- Permanece sob a visão e o controle de uma única organização.
Quais os Benefícios?¶
- Quais benefícios do InnerSource seriam mais impactantes para sua equipe?
- Quais benefícios seriam mais imediatos?
- Quais benefícios são mais necessários?
- Como cada um dos membros da sua equipe responderia a essas perguntas?
- Como vocês, como membros da equipe, quebram os silos?
- Onde estão os pontos problemáticos ou gargalos dentro da sua equipe ou organização?
Defina as estratégias¶
- Quais são alguns objetivos comuns pelos quais a organização pode trabalhar?
- Quais são alguns critérios de sucesso iniciais que promoveriam o compartilhamento do progresso em direção a essas metas?
- Quais comportamentos você atualmente incentiva e motiva os funcionários a adotar?
- Como os métodos existentes poderiam ser utilizados para esta iniciativa?
- Quais projetos internos vêm à mente quando você pensa em colaboração (não precisa ser focado no desenvolvedor)?
- O que você acha que faz com que esses projetos sejam bem-sucedidos?
- O que você pode usar nesses projetos para essa iniciativa?
- O que você gostaria de medir para identificar o sucesso da iniciativa?
- A transparência melhora a colaboração e permite que qualquer pessoa na empresa veja quando um projeto está saindo dos trilhos e ajude a corrigi-lo.
O que precisa MUDAR?¶
- Informações que a documentação fornece - Leia;
- Acesso que vem em reuniões, canais de comunicação e etc - Relacionamento;
- Permissão que deve se tornar parte da cultura;
- Quais comportamentos e mentalidades precisam mudar para atingir esse objetivo?
- Quais barreiras precisam ser quebradas para atingir esse esforço de mudança?
- Como podemos construir relacionamentos significativos fora dos silos em que as pessoas existem?
- Quais benefícios são obtidos com isso?
Como Implantar?¶
- Cultura: Quão receptiva é sua organização, culturalmente, à maneira de trabalhar da InnerSource?
- Capacitação do Desenvolvedor: Se você perguntasse a um grupo aleatório de desenvolvedores em sua organização o quanto eles se sentem capacitados para trabalhar com outras equipes, o que você acha que eles diriam?
- Governança: A comunidade de desenvolvedores dentro da sua organização recebe o suporte necessário?
Disfunções¶
- Ausência de confiança: Sem confiança, você não pode ter debates e conflitos saudáveis, porque as pessoas têm medo de serem honestas umas com as outras.
- Medo de conflito: Para construir conflito produtivo você precisa primeiro construir confiança, desenvolver segurança psicológica, para que as pessoas se sintam livres para serem honestas umas com as outras.
- Falta de comprometimento
- Evitar a responsabilização: As ideias são avaliadas apenas por seus méritos.
- Desatenção aos resultados
Ingredientes culturais¶
- Transparência: tanto em termos de processo como de participação;
- Engajamento: os colaboradores estão altamente engajados, há conflito produtivo;
- Assíncrona: a comunicação é assíncrona, permitindo a participação de toda a organização
Prática | Entenda |
---|---|
Colaboração | Facilita a colaboração entre diferentes equipes, permitindo que todos contribuam para projetos de forma mais fluida, independentemente de sua função ou localização. |
Transparência | O código e os processos são mais visíveis, o que ajuda a aumentar a transparência e a confiança dentro da organização. |
Reutilização de Código | Estimula a reutilização de código existente, economizando tempo e recursos ao evitar a duplicação de esforços. |
Práticas de Desenvolvimento Ágil | Muitas das práticas de desenvolvimento ágil, como revisões de código e testes contínuos, são frequentemente integradas ao InnerSource. |
Cultura de Aprendizado | Promove uma cultura de aprendizado contínuo, onde os desenvolvedores podem aprender uns com os outros e melhorar suas habilidades. |
Ferramentas e Processos | Utiliza ferramentas comuns de gerenciamento de código-fonte e colaboração, como GitHub ou GitLab, para facilitar o trabalho conjunto. |
Regras da Casa¶
Uma diretriz de contribuição fornece documentação CLARA, sobre como um colaborador pode contribuir, bem como formaliza as responsabilidades dos desenvolvedores que aceitam alterações de código em seu projeto.
Essas diretrizes não devem ser padronizadas em toda a organização, mas os itens abaixo são recomendados:
- Nomes dos responsáveis;
- Informações necessárias sobre contribuição;
- Convenções de código;
- Convenções de teste;
- Convenções de ramificação;
- Convenções de mensagens de confirmação;
- Etapas para criar uma boa solicitação de pull;
- Como enviar solicitações de recursos;
- Como enviar relatórios de bugs;
- Como enviar problemas;
- Como contribuir para a documentação;
- Quaisquer dependências;
- Cronograma do processo de construção;
- Cronograma de sprint;
- Roteiro;
Committer Confiável (TC)¶
O papel dele é ajudar a orientar os contribuidores e a mover as mudanças de código adiante. Algumas de suas outras responsabilidades incluem:
- Escrever e manter diretrizes de contribuição
- Revisões de código em PRs
- Manter dependências do projeto
- Fornecer orientação e suporte
- Lidere discussões e ajude a resolver problemas
O esperado¶
- Melhor código integrado;
- Melhor revisão de código;
- Melhoria no tempo de resposta de solicitação de pull (PR);
- Conhecimento mais claro para refatoração;
- Mais documentação com menos problemas e redução de gargalos;
Governança¶
Como uma organização, você pode ter certeza de que qualquer código não público permanecerá seguro dentro do seu ambiente — e somente desenvolvedores com permissões apropriadas poderão contribuir?
- Forneça os fluxos de trabalho que as equipes possam usar para criar um modelo;
- Forneça um repositório de TEMPLATES com exemplos:
- README(s);
- Modelos de problemas e solicitações de pull;
- Arquivos CONTRIBUTING;
- LICENÇA;
- CODEOWNER;
- Arquivos gitignore, etc.
- Crie uma equipe innersource DAR orientação quando ACIONADA;
Medições¶
- % de problemas criados por colaboradores externos
- Capacidade de resposta (por exemplo, com que rapidez alguém responde a um problema aberto por um colaborador externo)
- % de PR que vêm de colaboradores externos
- % de PRs de equipes externas que são mescladas
- % de avaliações que vêm de colaboradores externos
- % de reutilização de código em projetos
- % de repositórios que usam componentes do InnerSource (diretrizes de contribuição gerenciadas, TCs atribuídos, )
- Estabelecer e agendar um workshop de hack-a-thon para alinhar o propósito com a prática
- Familiarize-se com o portal interno da sua organização para o InnerSource
- Estabelecer convenções de pesquisa/marcação
- Estabelecer documentação de modelo e diretrizes de configuração de repositório
- Diretrizes de contribuição, documentação passiva, etc.
Quais problemas o InnerSource resolve?¶
A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa. Imagine duas equipes na mesma empresa entregando softwares separados, com o software de uma equipe dependendo do da outra.
Em organizações tradicionais, somente a equipe anfitriã pode alterar seu código. Outras equipes devem enviar solicitações e esperar até que sua importância seja reconhecida. Com a InnerSource, uma equipe externa que precisa urgentemente de uma mudança pode codificá-la ela mesma, com a orientação da equipe anfitriã.
O InnerSource se aplica ao mesmo tipo de situação em que uma equipe consumidora não consegue obter o que precisa por meio de solicitação de recurso. O InnerSource fornece uma maneira para as equipes obterem os benefícios de wait it out, workaround e escalar sem as desvantagens associadas.
- A equipe convidada ou colaborador solicita um recurso da equipe anfitriã.
- O proprietário do produto garante que as histórias de usuário que representam a solicitação de recurso sejam criadas, seja por membros da equipe convidada ou da equipe anfitriã. (Sprint - Jake Knapp)
- Essas histórias devem descrever o recurso solicitado em termos aceitáveis para a equipe convidada.
- Elas também listam quaisquer detalhes da equipe anfitriã sobre como o recurso deve ser entregue para que o trabalho seja aceito.
A InnerSource também fornece uma melhoria geral à cultura de ENGENHARIA pois os DEVs têm a chance de trabalhar com uma variedade maior de novas tecnologias e pessoas.
O InnerSource dá a uma empresa uma estratégia escalável para equipes convidadas obterem solicitações de recursos quando precisarem, sem o fardo de manutenção a longo prazo. A empresa como um todo ganha, pois o tempo das equipes convidadas é colocado em código que outros podem usar.
Seu cerne, estão quatro princípios que formam a base de qualquer instância bem-sucedida da InnerSource. Esses princípios têm inspiração em projetos de código aberto bem-sucedidos e são necessários para que a InnerSource alcance os benefícios descritos anteriormente.
Os princípios são:
- Abertura: Os projetos devem ser detectáveis e bem documentados por meio dos arquivos README.md e CONTRIBUTING.md na raiz do repositório.
- Transparência: Equipes convidadas possam contribuir significativamente para um projeto, a equipe anfitriã deve ser transparente . Isso significa que as equipes convidadas devem ser capazes de ter uma compreensão de:
- O projeto/repositório e sua direção;
- Requisitos de recursos pendentes;
- Progresso nos requisitos de recursos;
- Tomada de decisão da equipe anfitriã;
- Mentoria Priorizada: Os colaboradores nas equipes convidadas são promovidos para que entendam o suficiente sobre o projeto/repositório da equipe anfitriã para alterá-lo com sucesso;
- Contribuição Voluntária ao Código: A equipe convidada doa voluntariamente o código para a equipe anfitriã e a equipe anfitriã o aceita voluntariamente.
A InnerSource dá a esses gerentes uma chance de se envolverem mais em discussões que cruzam os limites organizacionais, e seu rastro de registros preserva evidências de suas contribuições.
Como o InnerSource requer contribuições de muitas equipes diferentes, os planos devem ser publicados e compartilhados. Isso não só permite a coordenação, mas destaca as contribuições que um gerente e sua equipe fazem para a organização maior.
A InnerSource pede documentação e transparência tanto no código quanto nas diretrizes. Se um desenvolvedor-chave sair ou estiver ocupado, o conhecimento estará disponível para outros.
Padrões corporativos:¶
Padrões, processos e documentação são elementos importantes de colaboração que permitem que várias equipes produzam código para um projeto compartilhado.
Compartilhar padrões, processos e documentação junto com o próprio código os torna explícitos, bem como fáceis de consumir e manter.
Controle de versão, painéis de mensagens e outras ferramentas preservam um registro do que aconteceu e de quem contribuiu. A transparência e o acesso aberto que eles criam garantem visibilidade e, portanto, permitem o devido crédito por realizações em projetos da InnerSource.
Colaboradores, committers confiáveis e donos de produtos mantêm mais discussões sobre projetos para colaborar na busca de soluções.
A contribuição de outros donos de produtos incorpora conhecimento valioso sobre seus usuários, o histórico de seus projetos, obstáculos a serem observados e outras coisas. Isso faz com que a comunicação extra valha a pena.
A equipe técnica geralmente sai da faculdade ou de outros programas de treinamento com habilidades em programação e, talvez, engenharia e gerenciamento de projetos.
As pessoas não podem participar de uma meta compartilhada se não tiverem as mesmas visões de metas-chave e maneiras de prosseguir.
Pessoas de fora geralmente trazem perspectivas importantes, tanto sobre as necessidades do usuário quanto sobre métodos robustos para atender a essas necessidades.
Elas podem revisar os padrões da sua equipe e até mesmo contribuir para eles. Tanto os donos do produto quanto os responsáveis confiáveis devem solicitar contribuições para os padrões.
Os projetos da InnerSource que desejam atingir altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos durante todo o ciclo de vida do software.
A publicação de documentos internos Requests for Comments (RFCs) permite discussões no início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.
Adotar a abordagem Innersource dentro de uma organização pode trazer diversas vantagens, especialmente em termos de eficiência interna, colaboração e inovação. Para que não haja dúvidas sobre as diferenças de innersource e Open Source, elaboramos o quadro abaixo:
Aspecto | Open Source | InnerSource |
---|---|---|
Origem | The Cathedral and the Bazaar - Eric S. Raymond | O'Reilly, Tim (2000-12-01). "Open Source and OpenGL". |
Definição | Software cujo código-fonte é aberto ao público e qualquer pessoa pode contribuir. | Uso dos princípios do Open Source dentro de uma organização, com colaboração interna. |
Acesso ao Código | Código-fonte disponível publicamente para qualquer pessoa. | Código-fonte aberto apenas para membros internos da organização. |
Colaboração | Colaboração global, com contribuições externas de qualquer desenvolvedor. | Colaboração restrita a membros internos da empresa ou organização. |
Objetivo | Fomentar inovação, transparência e benefícios para a comunidade global. | Melhorar a colaboração interna e reutilização de código dentro da organização. |
Licenciamento | Licenças permissivas (MIT, GPL, Apache, etc.) que permitem modificação e distribuição. | Licenciamento interno, com políticas corporativas para uso e contribuição do código. |
Governança | Governança descentralizada, baseada em meritocracia e contribuições da comunidade. | Governança centralizada, controlada pela estrutura hierárquica da organização. |
Exemplos | Linux, Kubernetes, Mozilla Firefox. | --- |
Benefícios | - Inovação rápida com contribuições externas. - Transparência e confiança. - Apoio comunitário global. | - Melhoria da colaboração entre equipes internas. - Reutilização de código, redução de redundância. - Maior controle sobre o desenvolvimento. |
Desafios | - Gerenciamento de contribuições externas. - Manutenção de projetos a longo prazo. | - Barreiras culturais internas. - Limitação de inovação pela falta de contribuições externas. |
Assim, InnerSource é um desenvolvimento histórico baseado no movimento Open Source junto com outras tendências em software.
O InnerSource difere do código aberto clássico por permanecer dentro da visão e do controle de uma única organização.
A "abertura" do projeto se estende por muitas equipes dentro da organização.
O software InnerSource continua sendo proprietário da empresa, mas dentro dele é aberto para qualquer um usá-lo e contribuir com ele.
O desenvolvimento se torna mais rápido à medida que os programadores aprendem a usar testes unitários, cobertura de código e integração contínua para remover bugs em um estágio inicial do desenvolvimento.
Os comentários escritos trocados entre os membros da equipe, embora ocupem algum tempo, mais do que se pagam ajudando novos programadores a aprender o sistema mais rápido.
Os programadores aprendem a documentar melhor seu código, tanto formalmente (como comentários e documentação no código) quanto informalmente (em listas de discussão).
Permite que desenvolvedores de software contribuam para os esforços de outras equipes, promovendo transparência e abertura para contribuições de outros.
Qualquer um pode usar, modificar e compartilhar livremente softwares desenvolvidos de forma institucional, para qualquer propósito com a ideia de que compartilhar código leva a um software melhor e mais confiável.
Para tal observa-se duas práticas atuais no mundo de desenvolvimento: Innersource e Boilerplate code.
- InnerSource em sua equipe é estabelecer metas, marcos e, em seguida, criar uma lista de verificação de itens que precisam ser realizados em sua equipe para atingir essas metas.
- Boilerplate code refere-se a trechos de código que se repetem e que frequentemente aparecem em muitos projetos ou partes do código. Esses trechos geralmente não contêm lógica específica, mas são necessários para a estrutura do programa, temdo como uma ideia a reutilização esse código para economizar tempo e evitar erros ao reescrever o mesmo código repetidamente.
O código padronizado é um texto em linguagem computacional que você pode reutilizar com pouca ou nenhuma alteração em diversos contextos diferentes.
- Códigos aparentemente repetitivos e transformá-los em padrões.
- Barateamento do código, pois já foi testado e ele funciona.
- Aprimoram continuamente seus códigos pois realizam testes de software e verificações de qualidade - CONTÍNUA;
- Reduzem o risco de erros de codificação e melhoram a qualidade do software.
- Declaração de classe, Views, APIs e etc.
- Criação de um contexto para um conjunto de pares nome-valor que o Oracle Database armazena na memória.
- Estude o poder da linguagem PL/SQL ou de Qualquer Outra.
- O tempo de latência do ORDS não poderá exceder a 10 ms;
Coisas que um não programador pode fazer¶
Comece a ouvir : Tudo em código envolve outras pessoas. Você está procurando se juntar a uma equipe, e isso significa entende-la e como ela funciona.
Participe de uma lista de discussão : Para muitos projetos, a lista de discussão é o principal canal de comunicação sobre o desenvolvimento do projeto.
Siga um Blog : Blogs mantidos por desenvolvedores geralmente dão informações sobre o que está por vir em lançamentos futuros e o que é preciso para chegar lá.
Trabalhe com Tickets/Issues : O código é o coração de qualquer projeto de código, mas não pense que escrever código é a única maneira de contribuir. A maioria dos projetos tem um sistema de tickets de problemas publicamente visível, vinculado à página inicial do site do projeto e incluído na documentação. É o principal canal de comunicação entre os usuários e os desenvolvedores. Mantê-lo atualizado é uma ótima maneira de ajudar o projeto.
Diagnosticar um bug : Bugs são frequentemente mal reportados. Diagnosticar e triar um bug pode ajudar a economizar tempo dos desenvolvedores com o trabalho braçal de descobrir as especificidades do problema.
- Se um usuário relatou, "O software não funciona quando eu faço X", gaste algum tempo para descobrir as especificidades do que acontece nesse problema.
- É repetível? Você pode criar um conjunto de etapas para causar o problema repetidamente?
- Você pode restringir o problema, como acontecer apenas em um navegador, mas não em outro, ou em uma distribuição, mas não em outra? Mesmo que você não saiba o que causa o problema, o esforço que você coloca em restringir as circunstâncias torna mais fácil para outra pessoa consertá-lo.
- O que quer que você descubra, adicione ao ticket no sistema de bugs para que todos vejam.
Fechar bugs corrigidos : Frequentemente, os bugs são corrigidos na base de código, mas os tickets relatados sobre eles não são atualizados no sistema de tickets. Limpar esse lixo pode ser demorado, mas é valioso para todo o projeto. Comece consultando o sistema de tickets para tickets mais antigos que um ano e veja se o bug ainda existe. Verifique o log de alterações de lançamento do projeto para ver se o bug foi corrigido e pode ser fechado. Se for conhecido que foi corrigido, anote o número da versão no ticket e feche-o.
Teste um beta ou candidato a lançamento : Qualquer projeto que seja projetado para rodar em múltiplas plataformas pode ter todos os tipos de problemas de portabilidade. Quando um lançamento se aproxima e um beta ou candidato a lançamento é publicado, o líder do projeto espera que ele seja testado por muitas pessoas diferentes em muitas plataformas diferentes. Você pode ser uma dessas pessoas e ajudar a garantir que o pacote funcione na sua plataforma.
Corrigir um bug : Geralmente é aqui que os colaboradores que querem começar a trabalhar no código começam. É simples: encontre um bug que pareça interessante no sistema de tickets e tente corrigi-lo no código. Documente a correção no código, se for apropriado. É uma boa ideia adicionar um teste ao conjunto de testes para testar o ponto do código que você corrigiu; alguns projetos exigem que as correções de bugs incluam testes. Mantenha notas enquanto você vasculha essa base de código desconhecida. Mesmo que você não consiga corrigir o bug, documente no ticket o que você descobriu como parte da tentativa de correção. O que você encontrar ajuda aqueles que vêm depois de você.
Escreva um Teste : A maioria dos projetos tem um conjunto de testes que testa o código, mas é difícil imaginar um conjunto de testes que não pudesse ter mais testes adicionados a ele. Se você encontrar um bug, tente escrever um teste que o reproduza. Se você não puder reproduzir o bug, escreva um teste que falhe. Se você não puder escrever um teste que falhe, escreva um teste que passe. Se você não puder escrever um teste que passe, escreva um teste que falhe. Se você não puder escrever um teste que falhe, escreva um teste que passe. Se você não puder escrever um teste que passe, escreva um teste que falhe. Se você não puder escrever um teste que falhe, escreva um teste que passe.
Adicione um comentário : Ao vasculhar o código, você pode encontrar alguns pontos que são confusos. Provavelmente, se você ficou confuso, outros também ficarão. Documente-os no código e envie um patch. Trabalhe com documentação A documentação é normalmente a parte de um projeto que recebe pouca atenção. Ela também pode sofrer por ter sido escrita do ponto de vista daqueles que estão familiarizados com o projeto, em vez dos olhos de alguém que está começando a entender.
Trabalhe com a Comunidade : O código aberto é apenas parcialmente sobre código. A comunidade faz o código aberto funcionar. Aqui estão algumas maneiras de ajudar a construí-lo.
Responda a uma pergunta : A melhor maneira de ajudar a construir a comunidade é ajudando os outros. Responder a uma pergunta, especialmente de alguém que está apenas começando, é crucial para ajudar o projeto a crescer e prosperar. O tempo que você leva para ajudar um iniciante, mesmo que ele esteja fazendo uma pergunta em que você poderia facilmente dar um rápido "RTFM", compensa no futuro, pois consegue outro membro ativo da comunidade. Todo mundo começa em algum lugar, e os projetos precisam de um fluxo constante de pessoas para que continuem vitais.
Escreva uma postagem de blog/wiki : Se você tem um blog, escreva sobre suas experiências com o projeto que está usando. Conte sobre um problema que você enfrentou usando o software e o que você fez para resolvê-lo. Você estará ajudando de duas maneiras, tanto ajudando a manter o projeto na mente de outras pessoas ao seu redor, quanto criando um registro para qualquer outra pessoa que tenha seu problema no futuro e pesquise na web pela resposta. (Um blog de suas aventuras técnicas também é uma excelente maneira de mostrar experiência no mundo real com o software em questão na próxima vez que você for procurar um emprego usando-o.)
Melhore um site : Se você tem habilidades em web design e pode ajudar a melhorar o site, e assim a imagem pública do projeto, esse é um tempo bem gasto. Talvez o projeto pudesse usar uma reformulação gráfica, ou um logotipo para identificar o projeto. Essas podem ser habilidades que faltam na comunidade. Eu sei que adoraria se pudesse obter alguma ajuda de design gráfico nos sites dos meus projetos.
Escreva Documentação técnica : Se você consegue escrever sobre como um aplicativo ou software funciona, você pode escrever documentação técnica sobre ele. Especialmente projetos de código aberto que buscam atualizar, renovar, expandir ou criar documentos técnicos para o público em geral ler. Quanto mais você escrever em inglês simples, melhor. A melhor parte é que você não precisa ser um programador para escrever documentos técnicos.
Ensine e ajude os outros : A melhor maneira de aprender mais sobre um tópico é tentar ensiná-lo. O melhor professor é aquele que consegue explicar coisas complexas com exemplos simples. Então você precisa tentar ser o melhor professor para ser o melhor aprendiz e o melhor no seu mundo de programação. Ensinar os outros fará você se sentir melhor consigo mesmo e ajudará você a obter melhores habilidades e conhecimento em sua profissão. Quando você receber ajuda de alguém, não guarde para si mesmo, compartilhe com os outros. Faça do mundo um lugar melhor para se viver.
Consumerização¶
Os softwares ERPs, acumulam, tecnologias e funcionalidades para atender uma grandiosidade empresarial (indo contra os cenários atuais com os processos ágeis – Lean IT, SCRUM e etc.), que por muitas vezes não aplicáveis a instituição e/ou adotam tecnologias, que foram abandonadas pelo mercado ou não amigáveis ou com raros profissionais, por exemplo o FORMS, OAF, PEOPLECODE e etc.
Esta claro com esta pesquisa, que a diferença entre software corporativo e consumidor necessita diminuir e que os consumidores, usam softwares mais envolventes e intuitivos: iFOOD, UBER, LinkedIn, WhatsApp e etc., sendo óbvio, as perguntas:
- Como diminuir este hiato entre estas camadas ou diminuir esta sensação?
- Como aumentar a satisfação do cliente, sem tornar o Aplicativo corporativo apenas um repositório?
- Como medir o processo se por um lado, o fornecedor do software, nos monetiza, por Aplicativo em alguns casos e em outros pelo conjunto da obra?
- Como diminuir a sensação, sem aumentar o número de sistemas - FRONT END?
- O mais importante é que você seja capaz de articular as coisas que são de valor para você e que você possa definir formas de medi-las.
- Tudo é uma mudança; trate-o de acordo. A mudança é feita por, para e com pessoas. Trate-as com respeito e elas criarão valor.
- Você não está no negócio para ganhar dinheiro. Esse não é o seu propósito.
- Se você não consegue responder 'Qual é o valor disso?', você precisa dar uma boa olhada no trabalho que está fazendo e avaliar por que ele está sendo feito.
- A maioria das organizações está no negócio de gerar, registrar e usar o conhecimento para criar valor na 'era da informação' de hoje.
- Se a coisa a fazer é importante o suficiente, divida-a em pequenos pedaços, priorize esses pedaços, comece a trabalhar neles e preveja quando eles estarão prontos com base na taxa de entrega real, em vez de adivinhar.
- Década de 90 – Paul R. Timm - 50 Poderosas Ideias Para Voce Manter Seus Cilentes - Será que a frase não foi distorcida? Satisfazer x Submissão?
- Século 21 – Roger Fisher/William Ury/Bruce Patton - Como chegar ao Sim - A negociação de acordos sem CONCESSÃO
- É preciso respeitar os direitos do cliente, mas também os princípios que regem a organização;
- Atender os anseios do cliente a qualquer custo nunca será um bom negócio;
-
Política do Ganha a Ganha;
-
CAIRREIRA DRIVE DEVELOPMENT (Temoq eur trazer tudo para a nossa carreira e não para o produto)
- Commenting For Better Reach (CFBR): O CFBR, também conhecido como “Commenting For Better Reach” é uma estratégia de usada por usuários ou empresas para comentar as postagens de outras pessoas para melhorar seu próprio alcance e visibilidade.
Pilares da Codificação/Tenha em Mente¶
- O melhor código é aquele que não precisa ser escrito;
- Qualidade não é negociável;
- O que nasce perfeito, nasce tarde;
- Só fazemos código do zero se for estritamente necessário, usaremos tudo que conhecemos que está pronto;
- A complicação do nosso é código é proporcional a complicação da nossa feature;
- Prioridade máxima é funcionar de acordo com o caso de uso;
- Eric Evans e os padrões sugeridos no DDD?
- O que Martin Fowler escreveu em Refactoring
- Ironico a origem do termo cascata é frequentemente citado como sendo um artigo publicado em 1970 por W. W. Royce
Métricas¶
- Dora Métrics
- Se for falar de Métricas, como Chidamber & Kemerer chegaram no seu conjunto de métricas?
- Como que a métrica de coesão foi questionada?
- Taxa de rotatividade (churn rate);
- Duração da sessão;
- DAU (Daily Active Users) e MAU (Monthly Active Users);
As coisas lá o nível de bagunça estão associados com a distância entre o lugar onde a coisa deveria estar e o lugar onde ele está de fato.
O arquiteto de muitas formas ajuda o time a definir uma organização ou seja qual é o lugar certo de cada coisa e e depois de definir o lugar certo de cada coisa tentar ajudar o time a colocar as coisas.
Os principais bloqueadores associados ao InnerSource foram a cultura organizacional (pensamento em silos), falta de tempo para contribuir, falta de conscientização geral e falta de adesão da gestão intermediária.
O dono de um projeto de software é a pessoa que tem o direito exclusivo, reconhecido pela comunidade em geral, de distribuir versões modificadas.
- Criar um projeto: um mantenedor desde seu início e o mantenedor ainda está ativo;
- Propriedade do projeto passada a você pelo proprietário anterior (isso às vezes é conhecido como "passar o bastão").
- Adquirir propriedade de um projeto é observar que ele precisa de trabalho e que o proprietário desapareceu ou perdeu o interesse.