Faz parte do senso comum associar a progressão de carreira à cargos de liderança. As mudanças no mercado de trabalho tornam outros formatos de carreira cada vez mais evidentes. A carreira de especialista, por exemplo, é uma possibilidade que faz sentido em muitas áreas, especialmente no universo da tecnologia.  Ser líder, seja de uma equipe ou de uma organização, é um papel bastante complexo que exige diversas competências. Entre elas, gestão de pessoas. As competências voltadas para pessoas, trazem um desafio considerável, com o qual nem todos se identificam.  O fato é que ser líder não é a única forma de crescer na carreira e atuar estrategicamente na organização trazendo impactos para o negócio. Por isso, nesse artigo vamos discutir um dos formatos de carreira que temos na Softplan, em Y, além de explorarmos alguns aspectos da carreira de especialista. Continue a leitura para conferir! Para além da liderança: carreira em Y e a possibilidade de ser um especialista Ao longo do tempo ficou claro que nem todos se identificam com o caminho de carreira que leva à gestão, e que nem sempre ser bom tecnicamente é indicativo para seguir no caminho de liderança. Uma carreira de especialista, por exemplo, pode ser muito mais interessante para várias pessoas.  Hoje temos  caminhos mais flexíveis para que a progressão de carreira seja uma escolha alinhada com aquilo que a pessoa realmente se identifica. A seguir vamos falar sobre um formato específico utilizado aqui na Sotplan, a carreira em Y, e como ela pode te ajudar a se tornar um especialista.  Como funciona a carreira em Y? A Softplan, para proporcionar essa autonomia de carreira aos Softplayers, contempla a carreira em Y.  E o que isso significa?  Significa que nossos Softplayers podem se desenvolver para atuar como líderes e direcionar sua carreira para cargos de gestão, ou focar na atuação técnica e se desenvolverem enquanto especialistas (imagem1). Legal, né? A carreira de especialista, tem tanta relevância quanto à de gestão, além de representar um papel estratégico para o negócio. O especialista tem a vantagem do foco, de investir na busca vertical pelo conhecimento, ou seja, torna-se referência técnica. Entende-se que o especialista é capaz de realizar análises complexas, liderar projetos técnicos, analisar escopos e enxergar padrões de necessidades, fomentar a escolha de ferramentas, ser estratégico na resolução de problemas, contribuir para a transformação e inovação tecnológica e dos produtos, entre outras funções.  É um profissional com potencial para trazer inovação, experiência consolidada, participar ativamente da capacitação de equipes e decisões estratégicas em diversos níveis (equipe, unidade, corporação).  Exemplo de aplicação da carreira em Y  Para deixar mais claro o funcionamento da carreira em Y, e como os diferentes graus de especialização se encaixam nela, vamos para um exemplo prático. Pensando na carreira de Software Developer, essa estrutura ficaria assim: Na imagem 2 fica visível que a estrutura de cargos de liderança e especialista se sobrepõem. Em alguns momentos, uma ultrapassa a outra. Ou seja, é possível alcançar cargos estratégicos e progredir financeiramente em ambos os caminhos.  Conforme apontado anteriormente, é esperado que o especialista dê conta de atividades diversas, atuando como um consultor interno, como referência técnica.  Porém, é necessário que além das habilidades técnicas, outras skills sejam desenvolvidas, as chamadas Soft Skills. O especialista técnico precisa desenvolver habilidades de comunicação e negociação, por exemplo. Afinal, em diversos momentos será necessário engajar o time na identificação e resolução de problemas, na adoção de novas práticas, ferramentas e/ou tecnologias, etc.  Ainda, espera-se que haja o compartilhamento desse conhecimento técnico desenvolvido e adquirido pelo especialista, e novamente serão requisitadas diversas soft skills. Ou seja, é um papel complexo e desafiador tal qual o papel de liderança, embora cada um tenha suas especificidades. Outras ferramentas de plano de carreira na Softplan A carreira em Y é só uma das ferramentas de plano de carreira na Softplan. Também contamos com outros projetos que trazem ainda mais robustez para essa estrutura tão importante. Alguns deles, são:  Plano de desenvolvimento Individual (PDI): uma ferramenta importante para guiar e acompanhar o desenvolvimento das skills identificadas como necessárias para progressão e desenvolvimento de carreira;  Avaliação de desempenho 360º: proporciona uma rica rede de feedbacks que irão trazer diversas possibilidades de desenvolvimento e reconhecimento de habilidades;  Processo Seletivo Interno (PROSIN): que proporciona autonomia de carreira, possibilitando transitar entre novas áreas e/ou cargos, etc.   Independentemente da sua escolha, o direcionamento na carreira é essencial para alcançarmos os nossos objetivos profissionais, afinal, se não sabemos aonde queremos chegar, qualquer caminho serve, não é mesmo?! ¹Frase adaptada da obra Alice no País das Maravilhas. Gostou de saber um pouco mais sobre carreira de especialista e suas principais implicações? Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira! Até a próxima!

A Programação assíncrona é uma forma de evitar delays ou tempos de espera na execução de um programa. Quando estamos executando algo sincronicamente, podemos ter bloqueios no processo pela necessidade de esperar alguma execução de código. Isso pode  bloquear o programa como um todo até que termine a execução deste passo. Async e Await são as palavras chaves usadas no C# para usar a programação assíncrona. Nesse conteúdo vamos explicar o que é programação assíncrona e como utilizá-la.  Quando usar a programação assíncrona?  Podemos usar programação assíncrona sempre que tivermos um procedimento que possa ser independente, tais como: Leitura e escrita de um arquivo; Chamadas de recursos 3rd party; Lógicas independentes que podem ser separadas da execução da thread principal. Tipos de retornos Void: quando utilizamos este retorno em um método async, estamos assumindo que ele irá ser executado em uma thread paralelizada, mas não poderá ser awaitable. Ou seja, não poderemos usar o atributo await nele para esperar o seu resultado. Este conceito é chamado de "Fire and forget". Task: corresponde a um retorno do tipo void, mas que é awaitable. Ou seja, podemos usar o await para esperar a sua execução. Já em um método void, nãohaverá retorno de tipo algum. Task T: este retorno é também awaitable, mas nele teremos um generic que indica o tipo do retorno que estamos esperando, sendo T, qualquer tipo que desejarmos. Na prática O SO gerencia a thread do sistema sendo uma única thread que executa passo a passo de forma procedural, ou seja de maneira síncrona. Quando trabalhamos com formato assíncrono, podemos ter várias execuções de processos (threads) sem bloquearmos a thread principal ou as demais se assim desejarmos. Dessa forma, podemos trabalhar de forma paralelizada. Observe uma chamada síncrona: Chamada Assíncrona: Algumas vezes, necessitamos o resultado de uma chamada feita de modo assíncrono para o prosseguimento de nossa operação. Nesses casos, podemos usar o operador await. O operador Await se faz necessário quando precisamos de um resultado em meio a um processo para continuar, fazendo com que nosso procedimento aguarde o retorno do que estamos chamando. Isso tudo sem bloquear a thread principal, o que significa que a aplicação não fica travada. É importante lembrar que, para o desenvolvedor, o uso do async await pode parecer muito com o uso do formato síncrono.Porém, por baixo dos panos, não é bem assim que funciona. Abaixo, apresento exemplos de como usar o async await de forma síncrona e paralelizada. Apenas para ilustrar, temos os métodos de Get que buscam os dados na api pública da JsonPlaceHolder, que nos retorna coleções de objetos Json para simularmos uma massa de dados obtida ( https://jsonplaceholder.typicode.com ): Neste endpoint temos a execução síncrona dos métodos. Mesmo eles sendo Async, chamamos eles com o .Result() para que sejam executados de maneira síncrona. Neste segundo exemplo, já de forma assíncrona, executamos os métodos, porém aguardamos sua execução com o await. Em teoria, isso funcionaria de forma semelhante a execução síncrona, com a diferença de que para cada execução temos uma thread nova, mesmo que as outras aguardem o seu término: Neste terceiro endpoint temos uma otimização do conceito assíncrono. Comparando com o anterior, podemos ver que, no início do método, disparamos as chamadas dos métodos Get e atribuímos às variáveis. Neste cenário, threads diferentes são disparadas para cada chamada, e isso é possível porque ainda não precisamos dos seus valores. Mas quando vamos utilizar os seus valores para algo, necessitamos que eles estejam prontos. Aí sim utilizamos o await, para que se a thread de chamada do método Get ainda não tiver terminado a sua execução o sistema espere ela, ou elas… Dessa forma, concluímos que a utilização do async await vai além de apenas utilizá-lo no código, onde métodos que contém o async/await não necessariamente estão sendo executados de forma paralelizada. Para obtermos tal resultado, devemos pensar melhor na estrutura de sua utilização e como queremos que os processos se comportem. De um modo geral, processos async/await bem estruturados nos retornam ganho de tempo por podermos executarmos “n” processos de forma assíncrona. Gostou de saber um pouco mais sobre Programação Assíncrona e suas principais implicações? Confira mais conteúdos como esse em nosso blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira! Até a próxima!

O Privacy by Design, em tradução livre “privacidade desde a concepção”, está vinculado diretamente com a proteção e privacidade de indivíduos. Essa terminologia ganhou forças no Brasil com o surgimento da Lei Geral de Proteção de Dados – LGPD.   Basicamente, entende-se o conceito de Privacy by Design como a aplicação de medidas técnicas para garantir e resguardar a privacidade do usuário, desde o momento da concepção de um produto ou serviço que envolva a coleta de dados pessoais.  Pensando na importância do tema para aqueles que trabalham com Tecnologia da Informação (TI) neste artigo vamos abordar sobre a aplicação do conceito incorporado ao desenvolvimento de produtos e serviços, os pilares que o formam, e a sua relação com a Lei Geral de Proteção de Dados. Continue a leitura! O que é o Privacy By Design?  Para Bioni (2019, p.84), o Privacy by Design “é a ideia de que a proteção de dados pessoais deve orientar a concepção de um produto ou serviços, devendo eles ser embarcados com tecnologias que facilitem o controle e a proteção de dados pessoais.” Mas, engana-se quem pensa que o termo surgiu recentemente! Na década de 90, criou-se a metodologia do Privacy by Design, que ganhou maior visibilidade com a criação das regulamentações de proteção de dados.   A pioneira no tema, Ann Cavoukian, ex-comissária canadense de Informação e Privacidade, estabeleceu princípios para serem tratados como base na aplicação. Assim, o conceito demonstra duas questões importantes: a importância de implementação de configurações de privacidade por padrão;  a necessidade de aplicação de medidas proativas e garantia de transparência com o titular de dados sobre a finalidade da coleta dos dados pessoais.  “Qualquer que seja o sistema envolvido, o Privacy by Design requer que você o construa desde o início, com privacidade como configuração padrão.” - Ann Cavoukian. A integração de medidas de privacidade no início de um projeto está relacionada com a identificação de possíveis problemas em um estágio introdutório. Dessa forma, essa etapa consegue evitar consequências  negativas futuras. Os 7 pilares do Privacy By design Para entender sobre a aplicação do conceito do Privacy by Design, é preciso conhecer os 7 pilares que o formam. Vamos discutir um pouco sobre cada um deles a seguir. Proativo e não reativo O intuito é pensar antecipadamente em possíveis problemas, impedindo que aconteça, buscando soluções, garantindo que, quando implementado determinado produto ou serviço, já estejam tratados possíveis riscos.  Privacidade por padrão Esse princípio estabelece que a proteção dos dados pessoais automaticamente em qualquer processo em um determinado produto ou serviço. Isso garante que o usuário não precise preocupar-se em proteger sua própria privacidade, já que o produto ou processo foi criado pensando na segurança. Privacidade incorporada ao projeto A privacidade do usuário não deve, de nenhuma maneira, ser pensada com um elemento adicional, mas sim como parte do que está sendo desenvolvido e implementado.  Funcionalidade total Também chamado de “soma positiva ao invés de soma-zero”, estabelece que todas as funcionalidades devem estar completas e protegidas, gerando benefícios, tanto para o titular, quanto para a empresa.  Segurança de ponta a ponta É necessário pensar na privacidade dos dados em todas as fases. Assim, garante-se a proteção durante todo o ciclo de vida dos dados: no momento da coleta, durante o tratamento e armazenamento, até o descarte.  Visibilidade e transparência Este pode ser considerado como um dos pilares mais importantes, na qual deve ser garantido ao titular dos dados a transparência, de modo que sempre seja informado sobre a finalidade da utilização dos dados pessoais. Respeito à privacidade do usuário O produto ou serviço deve ser centrado diretamente no usuário, sendo que toda funcionalidade deve visar e garantir a segurança dos dados pessoais.  O que é o Privacy by Design na LGPD? A LGPD não menciona de forma direta em seu texto o termo Privacy by Design. Entretanto, essa legislação está diretamente relacionada com o previsto no artigo 46: “Art. 46. Os agentes de tratamento devem adotar medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito. (…) § 2º As medidas de que trata o caput deste artigo deverão ser observadas desde a fase de concepção do produto ou do serviço até a sua execução.” Assim, podemos entender que o conceito Privacy by Design está relacionado com a aplicação de medidas de segurança para proteção dos dados pessoais. Dessa forma, desde o início da concepção de um produto e serviço, deve-se pensar na privacidade, garantindo, assim, a aderência com disposto no artigo.  Além disso, a adoção de medidas para garantir a privacidade de dados desde a concepção, pode ser vista como uma demonstração de que a empresa está em conformidade com a LGPD.  Esse cuidado evita a aplicação de multas e ocorrência de incidentes de segurança envolvendo dados pessoais.  Qual a diferença de Privacy by Design e Privacy by default? Podemos dizer que o Privacy by Default (privacidade como padrão) faz parte e liga-se diretamente ao Privacy by Design. Isso porque, uma das maneiras de garantir a privacidade desde o momento da criação, é que o produto ou serviço, quando direcionado ao usuário, esteja com todas as medidas para garantir a proteção dos dados implementadas. Sobre essa questão, Pinheiros (2018), pontua:  “Podemos dizer que o Privacy by Design é uma decorrência do Privacy by Default. Em outras palavras, trata-se da ideia de que o produto ou serviço seja lançado e recebido pelo usuário com todas as salvaguardas que foram concebidas durante o seu desenvolvimento. O princípio da proteção de dados por padrão é reconhecer o mínimo necessário em relação aos dados (às finalidades do tratamento pretendido), proibindo que esses dados excedam tais finalidades.” (PINHEIROS, 2018, p.399).  Ou seja, no momento do lançamento do produto ou serviço ao público, é necessário que as configurações de segurança e proteção dos dados estejam aplicadas como medida padrão. De tal modo que, somente haja a coleta dos dados estritamente necessários. Além disso, deve-se conceder ao usuário a autonomia para, se assim desejar, habilitar de forma voluntária as configurações e funcionalidades relacionadas à privacidade.  Conclusão Em suma, a famosa frase criada pelo matemático londrino Clive Humby “os dados são o nome petróleo”, torna-se cada vez mais real, haja vista que, as empresas utilizam os dados como fonte de receita, direta ou indiretamente.  Assim sendo, torna-se cada vez mais necessária a criação de regulamentações para proteção dos dados, dando ao titular autonomia sobre suas informações.   Com isso, cabe às empresas a implementação de medidas para a conformidade de seus produtos e serviços às novas regulamentações, garantindo o direito à privacidade aos titulares de dados. É interessante destacar também que a aplicação do Privacy by Design pode ser vista como um diferencial competitivo. Afinal, empresas que utilizam-se de medidas que garantem a privacidade dos usuários reforçam o compromisso e a preocupação com o bem-estar dos mesmos.  Dessa maneira, há um fortalecimento da confiança de todos os clientes por meio da transparência adotada. Logo, a implementação do conceito de Privacy by Design não só garante a conformidade com as legislações, mas também pode ser visto como um diferencial competitivo, fortalecendo a confiança dos usuários pela transparência adotada.  Gostou de saber um pouco mais sobre Privacy by Design e suas principais implicações? Confira mais conteúdos como esse em nosso blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira! Até a próxima!

Se você está entrando ou faz parte do universo dos produtos, em algum momento deve ter se deparado com o termo product discovery. O conceito tem sido difundido amplamente ao longo dos últimos anos, principalmente depois do “boom” da cultura de produto das empresas por todo o globo. Nesse mundo cada vez mais competitivo, alguns dos principais desafios das empresas são construir produtos que sejam lançados com sucesso e tenham vida longa, sendo amados pelos clientes.  No entanto, não são raras situações em que se investe tempo, dinheiro e muita energia construindo produtos que não despertam interesse nos consumidores. Assim, eles acabam não sendo utilizados e não  alcançando os resultados desejados. Para o desenvolvimento de produtos relevantes e que, de fato, cativem o público, o conhecimento sobre o processo de discovery é essencial. Por isso, neste artigo vou te explicar sobre product discovery: o que é, e como aplicá-lo no dia a dia de um produto digital.  Além disso, vou trazer dicas de como criar produtos melhores e mais assertivos em relação ao desejo de seus usuários. Vamos nessa?  Então, o que é Product Discovery? Product discovery ou descoberta de produto, se traduzirmos para o português, nada mais é do que um conjunto de práticas que estão relacionadas ao entendimento (descoberta) das necessidades do nosso usuário.  No processo de product  discovery, nos preocupamos em entender profundamente o problema antes de pensar em solução. Aplicar um discovery, significa realizar um planejamento e um estudo (feito pelo  time de produto e UX do negócio) sobre as dores do usuário. Esse trabalho pode ser feito sobre um produto que já exista ou algo novo.  Encontrar porquês, investigar, descobrir oportunidades, e, por fim, soluções que gerem valor e sejam viáveis para a empresa é o nosso grande desafio.  Como fazer um Discovery?  A primeira coisa a dizer sobre esse assunto é que não há uma receita de bolo para fazer um bom discovery. Cada time de produto aplica ferramentas dentro das atividades que fazem mais sentido naquele momento. Por outro lado, as equipes sempre devem seguir um planejamento, que vai ajudar nesse processo.  Podemos citar como etapas importantes: Alinhamento das expectativas (entender o momento da empresa, entender o produto que estamos querendo entregar);  Pesquisa (aliado com o time de UX), para entender as dores dos usuários (problemas); Ideação das hipóteses a serem validadas (essa é a hora de ter o máximo de hipóteses possível e alinhar com o time através de dinâmicas); Validação das hipóteses (é o momento de expor o protótipo ao usuário, o mais próximo possível da versão do produto);  Refinamento, que é criar um roadmap e estabelecer um MVP (minimum viable product) alinhado com as estratégias da empresa.  Quando fazer um Discovery? O discovery é essencial no lançamento de um novo produto, mas não se limita a isso. Quando temos uma nova funcionalidade, também podemos avaliar a necessidade de um discovery. Essas atividades podem acontecer em qualquer etapa do ciclo de vida de um produto.  Devemos avaliar as seguintes condições:  O valor que entregaremos é alto? Temos de forma clara o entendimento dos objetivos? Temos recursos disponíveis (disponibilidade de tempo e dinheiro)?  Depois de respondidas essas perguntas, conseguimos ter uma perspectiva das ações que devemos tomar.  Sempre devemos levar em consideração: quanto menos esforço (em implementação) para validar uma hipótese é melhor. Assim, podemos realizar diferentes testes para termos uma perspectiva mais clara do que nosso usuário precisa.  Não basta apenas sair criando novas features e esperar que, com isso, você terá bons resultados. Por isso, devemos ter um mindset de sempre testar nossas hipóteses,  para entendermos se elas fazem ou não sentido para nossos usuários. Quais são as áreas envolvidas no processo de discovery?  A responsabilidade pelas atividades é da gestão de produtos (PM) e UX. No entanto, isso não significa que não há colaboração da engenharia. A engenharia nos sinaliza a possibilidade técnica da solução que estamos propondo.  Dessa forma, a colaboração entre os times melhora muito os processos, fazendo com que todos contribuam para a compreensão da melhor solução (viável, desejável e possível) no produto que estamos trabalhando.  Existe Discovery certo ou errado?  Não podemos dizer que existe erro, e sim que pode ter faltado alguma percepção no projeto. A cada discovery, aprendemos e amadurecemos mais, o que gera maior assertividade no entendimento dos reais problemas dos usuários.  O importante é buscar uma percepção sem viez, entender que devemos coletar o máximo de informações dos nossos usuários antes de tomarmos qualquer decisão baseadas em “achismos”. O discovery nos permite evoluir nas ações que construímos ao longo da jornada de entrega do nosso produto.  Para finalizar, um ponto muito importante a esclarecer é o papel do gestor de produtos. Ele deve fortalecer a cultura de produto na sua empresa, alinhando sempre a estratégia da organização e o propósito do produto a todos os envolvidos (engenharia, comercial, marketing, entre outros). É o papel do gestor de produtos garantir uma visão muito clara do negócio e do valor que o produto gera ao nosso usuário.  Espero ter conseguido tirar algumas dúvidas de vocês sobre o tema! Para quem ficou interessado no assunto, indico algumas referências bibliográficas que podem ajudar a conhecer mais sobre o assunto:  CAGAN, Martin. Inspirado: Como criar produtos de tecnologia que os clientes amam; TORRES, Joaquim. Gestão de produtos de software: Como aumentar as chances de sucesso do seu software;  Você sabe qual é a importância do processo de discovery? – Cursos PM3.  Gostou de saber um pouco mais sobre product discovery e como se dá o seu funcionamento? Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira!

Vivemos um momento de transformações significativas na sociedade, sejam elas relacionadas à evolução humana ou causadas pela recente pandemia de Covid-19. O cenário de mudança exige esforço de adaptação e visão estratégica apurada. Nesse contexto, a capacidade de aprendizagem acelerada é muito útil, especialmente no mercado de trabalho.  Por outro lado, a aprendizagem acelerada tem tudo a ver com a flexibilidade cognitiva. Essa, por sua vez, liga-se à capacidade contínua de aprendizagem da pessoa, o que permite a adequação a diferentes cenários.  Em contextos relacionados à evolução tecnológica, requisita-se ainda mais a flexibilidade cognitiva. Isso porque, a velocidade de transformação de conceitos, técnicas de aprendizagem, ferramentas e procedimentos digitais é ainda maior do que em contextos antes analógicos. Sendo uma empresa de tecnologia, as mudanças do negócio e a evolução do conhecimento técnico são variáveis recorrentes na Softplan. Além disso, geram impacto em toda a estrutura, de processos a produtos fornecidos. A promoção da aprendizagem acelerada também liga-se à visão da liderança. Ela demanda que gestores compreendam a importância do aprendizado contínuo para a sustentabilidade do seu negócio. No conteúdo de hoje vamos contar uma das nossas experiências neste processo de aceleração da aprendizagem. Fique com a gente!  Quais os desafios da aprendizagem acelerada? O desenvolvimento do SAJ (Sistema de Automação da Justiça), exige, não apenas conhecimento em tecnologia, mas também em relação aos processos das instituições clientes e legislações vigentes. Por isso, é necessário para o seu desenvolvimento, a criação, manutenção e disseminação de conhecimentos muito especializados. Além das particularidades do negócio da Softplan, temos ainda o avanço da tecnologia em diferentes segmentos da economia, impactando diretamente na demanda por mão de obra qualificada em TECH. Por isso, iniciamos em 2019 o projeto “Academia de Base”, um dos exemplos de ação com foco na aprendizagem acelerada em um contexto corporativo.  Criamos um modelo de programa de estágio, em que a própria capacitação se revelou também um processo seletivo natural, levando para a efetivação somente os profissionais de fato aptos ao atendimento aos clientes e já adaptados à cultura da unidade.  Já realizamos 4 edições, com mais de 900 inscritos e mais de 60 pessoas capacitadas neste modelo! Como realizamos o projeto “Academia de Base”?  O projeto “Academia de Base” foi desenhado para resolver os desafios relacionados à disseminação de conhecimento especializado no time de Suporte da Unidade de Justiça, focando na inteligência necessária ao atendimento aos clientes da Softplan. As principais características foram:  Programação de fases de capacitação Na programação das fases de capacitação organizamos como se dariam os repasses de conhecimentos sobre: Tecnologia (produto SAJ e configurações);  Regra de negócio (processos do judiciário); Processos e ferramentas de trabalho; Essa etapa foi feita em ondas incrementais de aprendizagem e com realização de atividades práticas (“hands on” na etapa de acompanhamento em campo). Conteúdos adaptáveis  Conteúdo com possibilidades de adaptação para atender às demandas específicas de conhecimento dos times da operação de atendimento. Nesse sentido, permitindo uma certa flexibilidade na modelagem de cada turma. Processo seletivo com base em perfil comportamental  O processo seletivo para participação no projeto foi realizado baseado em perfil comportamental. Ou seja, nossos critérios foram além da seleção por curso de graduação correlacionado ao negócio da Justiça. Instrutores Capacitados e materiais de apoio relacionados Para realizar o projeto, buscamos alocar colaboradores com conhecimento especializado avançado e com ampla experiência no atendimento aos clientes como instrutores. Além disso, realizamos a disponibilização de materiais, bases de dados, bases de conhecimento, documentações de produto e práticas totalmente correlacionados à realidade do trabalho do suporte. Proximidade com a rotina de trabalho Elaboramos um período de “sombra” para os participantes do projeto. Ou seja, nesse momento, os estagiários realizaram o acompanhamento da rotina real de trabalho, definindo mentores para orientação no dia a dia. Acompanhamento contínuo  Promovemos o acompanhamento constante da evolução do aprendizado dos estagiários, incluindo avaliações teóricas, práticas, banca técnica, feedbacks constantes e pesquisa junto aos mentores. Além disso, mapeamos a evolução do conhecimento técnico através de auto avaliação e levantamento de dados de produtividade de cada estagiário no período pós-efetivação. Criação da Marca do projeto Criamos uma marca para o projeto, promovendo o senso de pertencimento dos estagiários a uma iniciativa inovadora de desenvolvimento de carreira, e de alta qualidade como ação educadora. O que aprendemos com o projeto? A aplicação desse projeto resultou em muitas lições. Percebemos que, apesar de não haver uma única fórmula de aprendizagem acelerada, algumas estratégias e ações podem potencializar esse processo.  As principais inferências sobre a relação entre os resultados gerados pela “Academia de Base” e a aplicação de práticas de Gestão do Conhecimento, referenciadas neste estudo, são: Criação de um modelo de replicação do conhecimento especializado para novos colaboradores totalmente escalável quanto à estratégia de seleção, planejamento, execução e monitoramento. Isso confirma a importância de um programa de capacitação incremental e conectado com os conhecimentos requisitados pela operação do negócio; Aplicação do modelo de aprendizagem centrado na prática (experimentação dos processos e dos sistemas). Isso  otimiza o aprendizado para adultos (reforçando a assertividade da escolha de metodologias fundamentadas na andragogia); Valor estratégico da atuação do time da Gestão do Conhecimento para desenho da metodologia, planejamento, logística e execução do programa, implementando práticas da governança multinível recomendada no modelo de Universidade Corporativa em Rede; Aceleração da aprendizagem em função da disponibilização de especialistas de diferentes áreas da vertical de Justiça como instrutores para realização dos tópicos de treinamento previstos no programa, reforçando a importância da aprendizagem organizacional centrada na prática do trabalho cotidiano; Impacto financeiro positivo, justificando o investimento financeiro para contratação de estagiários em modelo de capacitação para melhor assertividade na contratação em modelo CLT, demonstrando que as boas práticas de Gestão do Conhecimento podem ser traduzidas em retorno quantitativo para a organização (custos gerais reduzidos e indicadores de produtividade aumentados). Nossa experiência reforçando os processos de Gestão do Conhecimento evidenciam os impactos positivos gerados por uma estratégia sólida de investimento em ações focadas no capital intelectual. Em síntese: para a obtenção de melhores resultados, investir em pessoas é crucial ! Quer saber mais sobre o assunto? Recomendo:  https://justicadigital.com/unisoft-gestao-do-conhecimento/  https://www.linkedin.com/pulse/acelera%C3%A7%C3%A3o-da-aprendizagem-na-unidade-de-justi%C3%A7a-softplan-prado/?trk=public_profile_article_view Gostou de saber um pouco mais sobre aprendizagem acelerada e como buscamos aplicá-la na Softplan?  Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira!

Uma pergunta difícil de ser respondida quando trabalhamos com microsserviços é com relação ao “tamanho” adequado das aplicações que constituem o ecossistema.   A princípio, apenas para citarmos alguns exemplos e evidenciar a importância do assunto, serviços de granularidade inadequada podem implicar em:   Aumento do custo de manutenção e do índice de retrabalho das equipes;  Prejuízo nos requisitos não funcionais como escalabilidade, elasticidade e disponibilidade;  Agravamento do impacto de arquitetura descentralizada em termos de performance;  Complexidade acidental no monitoramento e detecção de falhas da aplicação.  Determinar a granularidade adequada é uma tarefa difícil. Provavelmente, não será na primeira tentativa que você obterá sucesso.  Nesse artigo, trarei alguns insights de possíveis cenários que justificam a decomposição de uma aplicação em microsserviços menores para te ajudar nessa questão. Confira! Granular ou modular microsserviços? Para compreendermos melhor as justificativas que irão nos conduzir durante o processo de refinamento da aplicação, devemos esclarecer a diferença conceitual entre os termos “granularidade” e “modularidade”.  Embora intimamente relacionados, tratam de aspectos arquiteturais distintos.   Modularidade, em nosso contexto de discussão, trata da organização interna de uma aplicação em componentes separados de alta coesão e com baixo acoplamento.  Idealmente, toda aplicação (principalmente monolíticas) deve ter essa preocupação, sendo desenvolvida em um formato modular flexível que facilite uma eventual decomposição.  A ausência de modularidade conduzirá o projeto ao perigoso e quase certamente irreversível big ball of mud (ou ainda pior: big ball of distributed mud). Figura 1- Exemplo de módulos coesos com dependência  Granularidade, por outro lado, diz respeito ao tamanho dos nossos módulos e/ou serviços. Em uma arquitetura distribuída é muito mais comum termos problemas com granularidade do que com a modularidade.   O ponto central dessa discussão é que uma arquitetura modular facilita muito a quebra de um serviço centralizado em microsserviços mais refinados, sendo quase um pré-requisito para uma decomposição arquitetural de menor esforço e com risco controlado.  A velha advertência de refatorar um trecho de código problemático antes de alterar seu comportamento também pode, nas devidas proporções, nos servir de orientação. Assim, é uma escolha sábia reestruturar um serviço em um formato modular flexível antes de aplicar as diretrizes que abordaremos na sequência.  Dica: Ferramentas simples como NetArchTest (.NET) e ArchUnit (Java) podem ser utilizadas pelo arquiteto para garantir a modularidade de uma aplicação, seguindo o conceito de fitness functions e arquiteturas evolucionárias! Critérios de desintegração dos microsserviços Afinal de contas, quais seriam os critérios que justificariam quebrar um serviço em aplicações menores?   São eles:  Escopo e funcionalidade;  Código de alta volatilidade;  Escalabilidade e throughput;  Tolerância à falha;  Segurança;  Extensibilidade.  A seguir, explicaremos melhor cada um desses tópicos: Escopo e funcionalidade Essa é a justificativa mais comum na quebra de granularidade de um serviço. Um microsserviço objetiva ter alta coesão. Desse modo, deve fazer uma única coisa e fazê-la muito bem.  A natureza subjetiva desse critério pode induzir a decisões equivocadas de arquitetura.  Como “responsabilidade única” acaba dependendo da avaliação e interpretação individual de cada um, é muito difícil afirmar com precisão quando essa recomendação é válida.  Observe a imagem: Figura 2 – Decomposição de serviço com boa coesão  No exemplo acima, as funcionalidades estão intimamente relacionadas dentro de um mesmo contexto de negócio (notificação). Avaliando apenas do ponto de vista da coesão, é provável que não tenhamos uma boa justificativa para uma decomposição arquitetural. Figura 3 – Serviço tratando de funcionalidades sem relação  Agora, considere um único serviço que gerencia o perfil do usuário e é responsável por manipular uma sessão de comentários. Claramente, estamos falando de contextos de negócio distintos e seria mais fácil de aceitar uma decisão apoiada nessa justificativa.  Para reforçar: este critério, por si só, muitas vezes não justifica a quebra de um serviço. Geralmente, ele é aplicado em conjunto com outros critérios, reforçando a tomada de decisão.   2 – Código de alta volatilidade A velocidade que o código fonte muda é uma ótima diretriz para fundamentar a decomposição de uma aplicação.  Imagine um serviço de títulos financeiros, no qual o módulo de histórico tem novas implementações a cada semana, enquanto os módulos de títulos a pagar e receber são alterados a cada seis meses. Figura 4 – Separando código de alta volatilidade  Nessa situação, a decomposição arquitetural pode ser uma decisão sábia para reduzir o escopo de testes antes de cada liberação.  Além disso, essa decisão também trará ganho de agilidade e manterá nosso risco de deploy controlado, garantindo que o serviço de títulos não seja mais afetado pelas frequentes mudanças na lógica do serviço de histórico.  3 – Escalabilidade e throughput Muito semelhante ao item anterior, o throughput de um serviço pode ser uma ótima justificativa para a quebra da aplicação.  Diferentes níveis de demanda, em diferentes funcionalidades, podem exigir que o serviço tenha que escalar de formas distintas e independentes.  Manter a aplicação centralizada pode impactar diretamente a capacidade e os custos da arquitetura em termos de escalabilidade e elasticidade.  Dependendo do contexto de negócio, este critério, por si só, pode ser suficiente para justificar sua decisão.  Figura 5 – Serviço com diferentes níveis de requisição em tpm (transactions per minute)  4 – Tolerância à falha O termo tolerância à falha descreve a capacidade de uma aplicação de continuar operando mesmo quando uma determinada parte desta aplicação deixa de funcionar.  Vamos considerar o exemplo anterior. Imagine um cenário onde o serviço de histórico, por integrar com diversas aplicações de terceiros fora da nossa arquitetura, costuma falhar com certa frequência, chegando ao ponto de reiniciar todo o serviço de títulos financeiros e gerar indisponibilidade.  Nesse caso, uma decisão compreensível seria: separar a rotina problemática em um serviço isolado. Para, assim, manter nossa aplicação funcional a despeito de eventuais falhas catastróficas no serviço de históricos. Figura 6 – Separando uma rotina problemática para melhorar a tolerância à falha 5 – Segurança Considere o exemplo ilustrado na figura abaixo. Nele, um serviço que trata das informações básicas de um usuário (endereço, telefone, nome etc.) precisa gerenciar dados sensíveis dos seus cartões de crédito.  Essas informações podem ter requisitos distintos com relação ao acesso e a proteção dos mesmos.  Quebrar o serviço, neste caso, pode auxiliar em:  Restringir ainda mais o acesso ao código cujos critérios de segurança sejam mais rigorosos; Evitar que o código menos restrito seja impactado com complexidade acidental de outros módulos.  Figura 7 – Serviços com critérios de acesso e segurança distintos  6 – Extensibilidade Uma solução extensível tem a capacidade de ter novas funcionalidades adicionadas com facilidade conforme o contexto de negócio cresce. Essa habilidade também pode ser um forte motivador para segregar uma aplicação.   Imagine que uma empresa tem um serviço centralizado para gerenciar formas de pagamento e deseja suportar novos métodos.  Certamente, seria possível consolidar tudo isso em um único serviço. Porém, a cada nova inclusão, o escopo de testes se tornaria mais e mais complexo, aumentando o risco de liberação, e, com isso, o custo de novas modificações.  Dessa forma, uma forma de mitigar esse problema, seria separar cada forma de pagamento em um serviço exclusivo. Assim, seria permitido que novos serviços pudessem subir e estender a funcionalidade atual sem impactar o código em produção ou aumentar o escopo de testes, mantendo, assim, o risco de novas implementações sob controle. Figura 8 – Segregação de serviços para permitir extensibilidade  Conclusão Dificilmente um arquiteto irá acertar de primeira. Requisitos mudam. Conforme aprendemos com nossas ferramentas de telemetria e feedback, a decomposição arquitetural de uma aplicação acaba sendo um processo natural dentro de uma aplicação moderna e evolutiva.  Felizmente, temos exemplos baseados na experimentação prática que nos servem de balizadores nessa empreitada:  Garanta que seu serviço possui uma estrutura interna modular flexível;  Avalie com calma os critérios que justifiquem uma decomposição arquitetural;  Considere cada trade-off face às necessidades do seu contexto de negócio.  Por fim, aos leitores que desejam saber mais sobre o tema, recomendo a leitura do livro que fundamentou este artigo: Software Architecture: The Hard Parts. Uma abordagem profunda e prática sobre este e muitos outros desafios enfrentados na arquitetura de software moderna de sistemas complexos.  Posteriormente, na parte II deste artigo, discutiremos os critérios que podem levar um arquiteto a unificar serviços distintos em uma aplicação centralizada. Fique ligado! Gostou de conhecer um pouco mais sobre Microsserviços? Me conte aqui nos comentários!  Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira!