![\"efic\u00e1cia](\"\/app\/uploads\/2024\/05\/1tR8fGHRhmgTIZqb1ad_X-Q.jpeg\" "\\"efic\u00e1cia")
<\/p>\n
Todos n\u00f3s queremos ser magros e \u00e1gil<\/a> para que o resultado das nossas actividades, medido em n\u00fameros, seja o mais elevado poss\u00edvel. Mesmo que concentremos a maior parte da nossa energia na redu\u00e7\u00e3o das perdas, no final, temos em conta o lucro que aumentou gra\u00e7as \u00e0s poupan\u00e7as geradas.<\/p>\n Estas poupan\u00e7as caem no mesmo saco que os restantes factores e ficam dispon\u00edveis apenas para os mais curiosos. Desta forma, perdemos o foco e, sem querer, omitimos muitas coisas valiosas dados<\/a> e, em \u00faltima an\u00e1lise, a intelig\u00eancia.<\/p>\n Aprender com os seus pr\u00f3prios erros \u00e9 uma compet\u00eancia particularmente \u00fatil (embora dispendiosa), mas a cultura organizacional<\/a> e a diplomacia inerente a esta capacidade nem sempre ajudam. Muitas vezes, escondemos o impacto negativo das finan\u00e7as com palavras de \"cortina de fumo\". Quando um investidor grita \"Perdi o meu dinheiro!\", o gestor comunica-o ao equipa<\/a> ao dizer \"dev\u00edamos ser mais eficazes\" e todos n\u00f3s procuramos, por defeito, novas solu\u00e7\u00f5es e melhorias - em vez de olharmos para tr\u00e1s, estamos constantemente \u00e0 procura de formas de avan\u00e7ar.<\/p>\n Entretanto, as perdas s\u00e3o muitas vezes a chave para tirar as conclus\u00f5es corretas. Se passarmos por cima de certas etapas do processo sem a devida considera\u00e7\u00e3o, as solu\u00e7\u00f5es seguintes estar\u00e3o muito provavelmente infectadas com os mesmos erros.<\/p>\n Exemplo:<\/em><\/strong>\u00a0<\/p>\n Uma pequena equipa de JS<\/a> Os programadores n\u00e3o fornecem a funcionalidade dentro do prazo previsto. O investidor, querendo acelerar o desenvolvimento, ordena a contrata\u00e7\u00e3o de um novo programador. A introdu\u00e7\u00e3o de uma nova pessoa no projeto ir\u00e1 distrair a equipa, o que atrasa ainda mais o progresso do projeto.<\/p>\n Se o investidor compreendesse melhor as raz\u00f5es da inefic\u00e1cia da equipa, concluiria que esta s\u00f3 utiliza o seu potencial em 60-70%. Um melhor equipamento e alguns dias de trabalho dedicados \u00e0 automatiza\u00e7\u00e3o do trabalho resolveriam o problema.<\/p>\n Infelizmente, agora tem de pagar a outro programador que trabalhar\u00e1 com o mesmo equipamento e a sua efici\u00eancia ser\u00e1 tamb\u00e9m de 60-70%.<\/p>\n Solu\u00e7\u00e3o A:<\/strong><\/p>\n \nA partir de agora o projeto custa $20,200 \/ m\u00eas<\/p>\n Despesas totais em 12 meses: 12 * 20.200 + 10.000 = $252.400<\/p>\n Solu\u00e7\u00e3o B:<\/strong><\/p>\n \nA partir de agora, os custos do projeto: $30.000 \/ m\u00eas<\/p>\n Despesas totais em 12 meses: 12 * 30.000 = $360.000<\/p>\n Dois promotores a trabalhar a 100% fazem aproximadamente o mesmo que tr\u00eas promotores a trabalhar a 60-70%. O investidor pagar\u00e1 mais de $ 100.000 a mais pela mesma capacidade de processamento por ano devido a uma decis\u00e3o de conce\u00e7\u00e3o incorrecta!<\/p>\n A agilidade no processo n\u00e3o significa necessariamente esfor\u00e7ar-se por obter uma cobertura de teste 100% ou bater o recorde de desempenho. Embora estas m\u00e9tricas forne\u00e7am uma vis\u00e3o geral do estado t\u00e9cnico do projeto, s\u00e3o t\u00e3o insignificantes do ponto de vista do cliente final que, num processo verdadeiramente \u00e1gil, n\u00e3o \u00e9 necess\u00e1rio atingi-las num estado ideal, uma vez que n\u00e3o trazem resultados reais. mercado<\/a> valor.<\/p>\n O desenvolvimento de solu\u00e7\u00f5es t\u00e9cnicas perfeitas requer um grande empenho da equipa e uma comunica\u00e7\u00e3o muito mais extensa. Como resultado, os patches trabalham mais lentamente e o projeto torna-se pesado devido ao excesso de desenvolvimento.<\/p>\n Desenvolvimento \u00e1gil<\/a> tem como objetivo fornecer uma c\u00f3digo<\/a> com um esfor\u00e7o m\u00ednimo. O teste de c\u00f3digo \u00e9, sem d\u00favida, uma boa pr\u00e1tica e os testes dizem muito sobre o funcionamento do c\u00f3digo, mas n\u00e3o devem ser feitos s\u00f3 por fazer e gabar-se disso - a qualidade t\u00e9cnica \u00f3ptima das solu\u00e7\u00f5es situa-se algures entre o m\u00ednimo determinado pelo equipa de desenvolvimento<\/a> e o m\u00e1ximo que \u00e9 limitado pelo or\u00e7amento.<\/p>\n Em \u00faltima an\u00e1lise, a perfei\u00e7\u00e3o n\u00e3o leva a lado nenhum. Curiosamente, at\u00e9 a quest\u00e3o da seguran\u00e7a est\u00e1 sujeita a esta regra - teoricamente, qualquer sistema pode ser pirateado. No entanto, o m\u00ednimo de desenvolvimento acima mencionado deve ser correspondentemente mais elevado e relevante para o peso, a escala e o custo das potenciais consequ\u00eancias de erros de c\u00f3digo. Muitas vezes, em vez de escrever o m\u00f3dulo de in\u00edcio de sess\u00e3o de raiz, que est\u00e1 sempre sobrecarregado com um elevado risco de erro e de introdu\u00e7\u00e3o de vulnerabilidades de seguran\u00e7a, \u00e9 melhor utilizar, por exemplo, o bot\u00e3o \"Iniciar sess\u00e3o com o Google\", cuja implementa\u00e7\u00e3o correta \u00e9 relativamente r\u00e1pida e segura.<\/p>\n Desde que o objetivo seja um tempo de coloca\u00e7\u00e3o no mercado curto, os pressupostos demasiado ambiciosos revelam-se contraproducentes. Num processo aparentemente perfeito, o excesso de entusiasmo pode ser um desperd\u00edcio de recursos<\/a>.<\/p>\n O design centrado no utilizador \u00e9 fixe. A coopera\u00e7\u00e3o centrada no ser humano \u00e9 mais importante. Quando a equipa comunica no mesmo comprimento de onda, pode reduzir espontaneamente outras perdas potenciais.<\/p>\n A UX<\/a> O designer que est\u00e1 atualizado com as tecnologias de front-end n\u00e3o ir\u00e1 propor uma solu\u00e7\u00e3o na MVP<\/a> que consumir\u00e1 um tempo excessivo na fase de execu\u00e7\u00e3o.<\/p>\n Um programador de front-end que conhe\u00e7a as heur\u00edsticas de usabilidade ser\u00e1 capaz de ajustar a interface a uma determinada resolu\u00e7\u00e3o de ecr\u00e3 sem envolver o designer de experi\u00eancia do utilizador - corre\u00e7\u00e3o r\u00e1pida, pr\u00e9-visualiza\u00e7\u00e3o, aceita\u00e7\u00e3o.<\/p>\n Trabalhar numa aplica\u00e7\u00e3o requer a sincroniza\u00e7\u00e3o das actividades de pessoas com perfis de compet\u00eancias completamente diferentes. \u00c9 necess\u00e1rio conhecer a distribui\u00e7\u00e3o das compet\u00eancias na sua equipa para fornecer efetivamente valor aos seus clientes.<\/p>\n Uma equipa empenhada e sincronizada \u00e9 um gerador de poupan\u00e7as fundamental. Este tipo de agilidade requer um desenvolvimento \u00f3timo do produto<\/a>.<\/p>\n O bom desempenho da equipa, entendido desta forma, \u00e9 extremamente dif\u00edcil de alcan\u00e7ar, especialmente na era da trabalho remoto<\/a>. As empresas que s\u00e3o \"amigas do controlo remoto\" h\u00e1 anos t\u00eam uma vantagem significativa neste dom\u00ednio em rela\u00e7\u00e3o \u00e0s que foram for\u00e7adas a sintonizar a organiza\u00e7\u00e3o durante o confinamento e s\u00f3 agora est\u00e3o a aprender novos m\u00e9todos e formas de comunica\u00e7\u00e3o.<\/p>\n No contexto das crescentes necessidades de comunica\u00e7\u00e3o, ferramentas como Whimsical, Miro, Mural, Figma e Balsamiq registam um aumento impressionante de popularidade.<\/p>\n \u00c9 certo que o confinamento e a necessidade de trabalhar \u00e0 dist\u00e2ncia contribu\u00edram para esta explos\u00e3o de utilizadores. Penso que a sele\u00e7\u00e3o da ferramenta deve corresponder \u00e0s prefer\u00eancias individuais, mas vejamos o caso do Miro:<\/p>\n A populariza\u00e7\u00e3o de tais ferramentas conduz naturalmente ao aumento da popularidade das pr\u00f3prias metodologias. Quem comprou o Miro para trabalhar em personas tem acesso a dezenas de outros modelos que podem ser interessantes e afetar positivamente o trabalho di\u00e1rio da equipa.<\/p>\n Deve sempre munir-se de ferramentas que simplifiquem o fluxo de informa\u00e7\u00e3o no projeto. A abertura a novas ferramentas e m\u00e9todos \u00e9 tamb\u00e9m uma das bases de um projeto eficaz. desenvolvimento de produtos<\/a>.<\/p>\n Designers experientes tanto da interface como da arquitetura de software<\/a> Normalmente, notamos v\u00e1rias solu\u00e7\u00f5es potenciais que devem ser verificadas no in\u00edcio da coopera\u00e7\u00e3o e procuramos eficazmente inspira\u00e7\u00f5es adequadas ou mesmo solu\u00e7\u00f5es prontas no mercado. Um bom exemplo \u00e9 a estrutura Material UI, que \u00e9 normalmente uma aposta segura na fase de prot\u00f3tipo<\/a>.<\/p>\n Por vezes, basta rever algumas implementa\u00e7\u00f5es no Behance ou no Dribble e utilizar a inspira\u00e7\u00e3o para desenvolver um mood board e depois pass\u00e1-lo ao programador. Esta pessoa utiliz\u00e1-lo-\u00e1 para criar um prot\u00f3tipo<\/a> que pode ser apresentado aos primeiros utilizadores para recolher feedback. Este esfor\u00e7o org\u00e2nico para obter um processo eficaz em pessoas empenhadas e com esp\u00edrito de design \u00e9 natural.<\/p>\n Se pretende fornecer produtos digitais de forma eficiente, tem de deixar as pessoas fazerem o seu trabalho. Sabe qual o valor\/servi\u00e7o que quer fornecer aos seus clientes - isso \u00e9 suficiente. Uma equipa de projeto competente e bem gerida saber\u00e1 melhor como fornecer esse valor\/servi\u00e7o o mais rapidamente poss\u00edvel com a necess\u00e1ria rela\u00e7\u00e3o custo-efic\u00e1cia.<\/p>\n Mostre a sua confian\u00e7a, partilhe a responsabilidade e abra-se a uma verdadeira comunica\u00e7\u00e3o bidirecional para que os seus produto<\/a> ser\u00e1 melhor e o fardo de fazer tudo sozinho sair\u00e1 dos seus ombros, o que muitas vezes se revela uma viagem desgastante para fundadores e empres\u00e1rios! Em The Codest<\/a>A nossa empresa, que tem como objetivo a reten\u00e7\u00e3o de clientes e colaboradores, aplica este princ\u00edpio n\u00e3o s\u00f3 aos projectos, mas tamb\u00e9m aos processos internos - \u00e9 provavelmente por isso que temos elevadas taxas de reten\u00e7\u00e3o de clientes e colaboradores (hist\u00f3ria ver\u00eddica, ambos> 90%).<\/p>\n Trate-se com um pouco de pregui\u00e7a, transfira corajosamente a responsabilidade e deixe de lado qualquer trabalho redundante que n\u00e3o seja necess\u00e1rio para avan\u00e7ar - as funcionalidades que seriam \"boas de ter\" podem sempre esperar.<\/p>\n O processo de cria\u00e7\u00e3o de um produto digital \u00e9 uma colis\u00e3o constante de diferentes perspectivas, experi\u00eancias e fontes de informa\u00e7\u00e3o - cada uma dessas colis\u00f5es acarreta o risco de se tomar uma decis\u00e3o de conce\u00e7\u00e3o errada.<\/p>\n Uma boa comunica\u00e7\u00e3o interna reduz este risco, mas \u00e9 apenas uma das faces da moeda. A quest\u00e3o de como se manter em contacto com o mercado continua por responder.<\/p>\n Business Intelligence, Apoio ao Cliente, departamentos de investiga\u00e7\u00e3o UX e muitos outros - tal como a equipa de desenvolvimento<\/a>Devem esfor\u00e7ar-se por obter o m\u00ednimo necess\u00e1rio para dar respostas espec\u00edficas \u00e0s perguntas feitas pelo propriet\u00e1rio do produto ou pela equipa UX.<\/p>\n A pr\u00f3pria marca e a estrat\u00e9gia de comunica\u00e7\u00e3o da marca s\u00e3o igualmente importantes. Servem para construir uma rela\u00e7\u00e3o qualitativa com os clientes, o que se traduz no seu empenhamento. Se quiser fazer perguntas aos clientes, deve certificar-se de que eles est\u00e3o dispostos a responder a essas perguntas. O tom da sua voz \u00e9 importante.<\/p>\n \u00c9 certo que estar em contacto permanente com o mercado permite definir as traject\u00f3rias certas para que o projeto voe. Menos \u00f3bvio \u00e9 o facto de a necessidade deste contacto dever ser considerada logo no in\u00edcio do projeto, antecipando as compet\u00eancias certas da equipa (para fazer as perguntas certas e responder-lhes) e construindo uma estrat\u00e9gia de produto que envolva os grupos-alvo.<\/p>\n Considerando todas as quest\u00f5es acima mencionadas, podemos observar v\u00e1rios problemas que surgem regularmente no processo de conce\u00e7\u00e3o:<\/p>\n - estar demasiado orientado para o lucro e evitar olhar para os fracassos,<\/p>\n - imprecis\u00e3o e n\u00e3o fazer uma radiografia dos pr\u00f3prios erros,<\/p>\n - perseguir um produto perfeito que tem na sua cabe\u00e7a, mas que n\u00e3o \u00e9 o que o mercado precisa,<\/p>\n - implementa\u00e7\u00e3o excessivamente zelosa de processos de livros did\u00e1cticos - desenvolvimento e conce\u00e7\u00e3o excessivos,<\/p>\n - a inflexibilidade do trabalho em equipa e o facto de obrigar os trabalhadores a permanecerem apenas nas suas \u00e1reas de especializa\u00e7\u00e3o,<\/p>\n - comunica\u00e7\u00e3o ineficaz,<\/p>\n - tend\u00eancia para reinventar a roda.<\/p>\n A otimiza\u00e7\u00e3o do processo numa escala macro inclui a soma das poupan\u00e7as. Para enfrentar corretamente os desafios acima referidos, \u00e9 necess\u00e1rio envolver os seus colegas para que apresentem abertamente ideias para melhorar o processo.<\/p>\n Por vezes, basta falar menos e ouvir mais atentamente os subordinados, os clientes, os parceiros - de acordo com o papel e a responsabilidade de cada um - para alcan\u00e7ar o sucesso.<\/p>\n Quando n\u00e3o \u00e9 suficiente, o mais prov\u00e1vel \u00e9 estar a investir demasiado<\/a>. Tem demasiado dinheiro?<\/p>\n Ler mais:<\/strong><\/p>\n Desafios do CTO - aumento de escala e crescimento de produtos de software<\/a><\/p>\nLi\u00e7\u00f5es aprendidas com os fracassos<\/h2>\n
\n
\n
Construir um produto perfeito \u00e9 como perseguir o coelho<\/h2>\n
\u00c9 bom saber tudo sobre algo e algo sobre tudo<\/h2>\n
Equipamento potente antes de partir<\/h2>\n
![\"Miro\"](\"\/app\/uploads\/2024\/05\/miro.png\" "\\"Miro\\"")
<\/p>\nPode (e deve) ser pregui\u00e7oso<\/h2>\n
Concentrar-se em encontrar as respostas corretas<\/h2>\n
Conclus\u00f5es<\/h2>\n
![\"Calem-se](\"\/app\/uploads\/2024\/05\/meme.png\" "\\"Calem-se")
<\/p>\nCalem-se e levem o vosso dinheiro! Ah, e para al\u00e9m disso:<\/h2>\n
\n