VOLTAR
Perseguir unicórnios é um passatempo muito caro. Todos os anos, as empresas em fase de arranque consomem milhares de milhões para que apenas uma entre dezenas ou centenas possa lucrar milhões. Os fundadores e os proprietários de produtos angariam dinheiro junto dos investidores e sacrificam a sua independência para conquistar o mercado mais rapidamente. No entanto, na maior parte das vezes, acabam por não angariar fundos suficientes. Talvez tenha sido correto dizer "cala-te e aceita o teu dinheiro" no momento certo?
O dinheiro domina tudo à minha volta. Mesmo as organizações mais turquesas não o podem negar. O desenvolvimento de projeto Os métodos de gestão, a afinação e otimização dos processos ou a motivação dos trabalhadores são basicamente desencadeados pela necessidade universal de dinheiro. A agilidade de conceção envolve alguns riscos.
Todos nós queremos ser magros e ágil para que o resultado das nossas actividades, medido em números, seja o mais elevado possível. Mesmo que concentremos a maior parte da nossa energia na redução das perdas, no final, temos em conta o lucro que aumentou graças às poupanças geradas.
Estas poupanças caem no mesmo saco que os restantes factores e ficam disponíveis apenas para os mais curiosos. Desta forma, perdemos o foco e, involuntariamente, omitimos muitos dados valiosos e, em última análise, inteligência.
Aprender com os seus próprios erros é uma competência particularmente útil (embora dispendiosa), mas a cultura organizacional e a diplomacia inerente a esta capacidade nem sempre ajudam. Muitas vezes, escondemos o impacto negativo das finanças com palavras de "cortina de fumo". Quando um investidor grita "Perdi o meu dinheiro!", o gestor comunica-o ao equipa ao dizer "devíamos ser mais eficazes" e todos nós procuramos, por defeito, novas soluções e melhorias - em vez de olharmos para trás, estamos constantemente à procura de formas de avançar.
Entretanto, as perdas são muitas vezes a chave para tirar as conclusões corretas. Se passarmos por cima de certas etapas do processo sem a devida consideração, as soluções seguintes estarão muito provavelmente infectadas com os mesmos erros.
Exemplo:
Uma pequena equipa de programadores sénior de JS não fornece funcionalidades dentro do prazo previsto. O investidor, querendo acelerar o desenvolvimento, ordena a contratação de um novo programador. A introdução de uma nova pessoa no projeto irá distrair a equipa, o que atrasa ainda mais o progresso do projeto.
Se o investidor compreendesse melhor as razões da ineficácia da equipa, concluiria que esta só utiliza o seu potencial em 60-70%. Um melhor equipamento e alguns dias de trabalho dedicados à automatização do trabalho resolveriam o problema.
Infelizmente, agora tem de pagar a outro programador que trabalhará com o mesmo equipamento e a sua eficiência será também de 60-70%.
Solução A:
A partir de agora o projeto custa $20,200 / mês
Despesas totais em 12 meses: 12 * 20.200 + 10.000 = $252.400
Solução B:
A partir de agora, os custos do projeto: $30.000 / mês
Despesas totais em 12 meses: 12 * 30.000 = $360.000
Dois promotores a trabalhar a 100% fazem aproximadamente o mesmo que três promotores a trabalhar a 60-70%. O investidor pagará mais de $ 100.000 a mais pela mesma capacidade de processamento por ano devido a uma decisão de conceção incorrecta!
A agilidade no processo não significa necessariamente esforçar-se por obter uma cobertura de teste 100% ou bater o recorde de desempenho. Embora estas métricas forneçam uma visão geral do estado técnico do projeto, são tão insignificantes do ponto de vista do cliente final que, num processo verdadeiramente ágil, não é necessário atingi-las num estado ideal, uma vez que não trazem resultados reais. mercado valor.
O desenvolvimento de soluções técnicas perfeitas requer um grande empenho da equipa e uma comunicação muito mais extensa. Como resultado, os patches trabalham mais lentamente e o projeto torna-se pesado devido ao excesso de desenvolvimento.
Desenvolvimento ágil tem como objetivo fornecer uma código com um esforço mínimo. O teste de código é, sem dúvida, uma boa prática e os testes dizem muito sobre o funcionamento do código, mas não devem ser feitos só por fazer e gabar-se disso - a qualidade técnica óptima das soluções situa-se algures entre o mínimo determinado pelo equipa de desenvolvimento e o máximo que é limitado pelo orçamento.
Em última análise, a perfeição não leva a lado nenhum. Curiosamente, até a questão da segurança está sujeita a esta regra - teoricamente, qualquer sistema pode ser pirateado. No entanto, o mínimo de desenvolvimento acima mencionado deve ser correspondentemente mais elevado e relevante para o peso, a escala e o custo das potenciais consequências de erros de código. Muitas vezes, em vez de escrever o módulo de início de sessão de raiz, que está sempre sobrecarregado com um elevado risco de erro e de introdução de vulnerabilidades de segurança, é melhor utilizar, por exemplo, o botão "Iniciar sessão com o Google", cuja implementação correta é relativamente rápida e segura.
Desde que o objetivo seja um tempo de colocação no mercado curto, os pressupostos demasiado ambiciosos revelam-se contraproducentes. Num processo aparentemente perfeito, o excesso de entusiasmo pode ser um desperdício de recursos.
O design centrado no utilizador é fixe. A cooperação centrada no ser humano é mais importante. Quando a equipa comunica no mesmo comprimento de onda, pode reduzir espontaneamente outras perdas potenciais.
Um UX designer que esteja atualizado com as tecnologias de front-end não irá propor uma solução na fase de MVP que consumirá um tempo excessivo na fase de execução.
Um programador de front-end que conheça as heurísticas de usabilidade será capaz de ajustar a interface a uma determinada resolução de ecrã sem envolver o designer de experiência do utilizador - correção rápida, pré-visualização, aceitação.
Trabalhar numa aplicação requer a sincronização das actividades de pessoas com perfis de competências completamente diferentes. É necessário conhecer a distribuição das competências na sua equipa para fornecer efetivamente valor aos seus clientes.
O bom desempenho da equipa, entendido desta forma, é extremamente difícil de alcançar, especialmente na era da trabalho remoto. As empresas que são "amigas do controlo remoto" há anos têm uma vantagem significativa neste domínio em relação às que foram forçadas a sintonizar a organização durante o confinamento e só agora estão a aprender novos métodos e formas de comunicação.
No contexto das crescentes necessidades de comunicação, ferramentas como Whimsical, Miro, Mural, Figma e Balsamiq registam um aumento impressionante de popularidade.
É certo que o confinamento e a necessidade de trabalhar à distância contribuíram para esta explosão de utilizadores. Penso que a seleção da ferramenta deve corresponder às preferências individuais, mas vejamos o caso do Miro:
A popularização de tais ferramentas conduz naturalmente ao aumento da popularidade das próprias 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ário da equipa.
Deve sempre munir-se de ferramentas que simplifiquem o fluxo de informação no projeto. A abertura a novas ferramentas e métodos é também uma das bases de um projeto eficaz. desenvolvimento de produtos.
Designers experientes tanto da interface como da arquitetura de software Normalmente, notamos várias soluções potenciais que devem ser verificadas no início da cooperação e procuramos eficazmente inspirações adequadas ou mesmo soluções prontas no mercado. Um bom exemplo é a estrutura Material UI, que é normalmente uma aposta segura na fase de protótipo.
Por vezes, basta rever algumas implementações no Behance ou no Dribble e utilizar a inspiração para desenvolver um mood board e depois passá-lo ao programador. Esta pessoa utilizá-lo-á para criar um protótipo que pode ser apresentado aos primeiros utilizadores para recolher feedback. Este esforço orgânico para obter um processo eficaz em pessoas empenhadas e com espírito de design é natural.
Se pretende fornecer produtos digitais de forma eficiente, tem de deixar as pessoas fazerem o seu trabalho. Sabe qual o valor/serviço que quer fornecer aos seus clientes - isso é suficiente. Uma equipa de projeto competente e bem gerida saberá melhor como fornecer esse valor/serviço o mais rapidamente possível com a necessária relação custo-eficácia.
Mostre a sua confiança, partilhe a responsabilidade e abra-se a uma verdadeira comunicação bidirecional para que os seus produto será melhor e o fardo de fazer tudo sozinho sairá dos seus ombros, o que muitas vezes se revela uma viagem desgastante para fundadores e empresários! Em The CodestA nossa empresa, que tem como objetivo a retenção de clientes e colaboradores, aplica este princípio não só aos projectos, mas também aos processos internos - é provavelmente por isso que temos elevadas taxas de retenção de clientes e colaboradores (história verídica, ambos> 90%).
Trate-se com um pouco de preguiça, transfira corajosamente a responsabilidade e deixe de lado qualquer trabalho redundante que não seja necessário para avançar - as funcionalidades que seriam "boas de ter" podem sempre esperar.
O processo de criação de um produto digital é uma colisão constante de diferentes perspectivas, experiências e fontes de informação - cada uma dessas colisões acarreta o risco de se tomar uma decisão de conceção errada.
Uma boa comunicação interna reduz este risco, mas é apenas uma das faces da moeda. A questão de como se manter em contacto com o mercado continua por responder.
Business Intelligence, Apoio ao Cliente, departamentos de investigação UX e muitos outros - tal como a equipa de desenvolvimentoDevem esforçar-se por obter o mínimo necessário para dar respostas específicas às perguntas feitas pelo proprietário do produto ou pela equipa UX.
A própria marca e a estratégia de comunicação da marca são igualmente importantes. Servem para construir uma relação qualitativa com os clientes, o que se traduz no seu empenhamento. Se quiser fazer perguntas aos clientes, deve certificar-se de que eles estão dispostos a responder a essas perguntas. O tom da sua voz é importante.
É certo que estar em contacto permanente com o mercado permite definir as trajectórias certas para que o projeto voe. Menos óbvio é o facto de a necessidade deste contacto dever ser considerada logo no início do projeto, antecipando as competências certas da equipa (para fazer as perguntas certas e responder-lhes) e construindo uma estratégia de produto que envolva os grupos-alvo.
Considerando todas as questões acima mencionadas, podemos observar vários problemas que surgem regularmente no processo de conceção:
- estar demasiado orientado para o lucro e evitar olhar para os fracassos,
- imprecisão e não fazer uma radiografia dos próprios erros,
- perseguir um produto perfeito que tem na sua cabeça, mas que não é o que o mercado precisa,
- implementação excessivamente zelosa de processos de livros didácticos - desenvolvimento e conceção excessivos,
- a inflexibilidade do trabalho em equipa e o facto de obrigar os trabalhadores a permanecerem apenas nas suas áreas de especialização,
- comunicação ineficaz,
- tendência para reinventar a roda.
A otimização do processo numa escala macro inclui a soma das poupanças. Para enfrentar corretamente os desafios acima referidos, é necessário envolver os seus colegas para que apresentem abertamente ideias para melhorar o processo.
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çar o sucesso.
Quando não é suficiente, o mais provável é estar a investir demasiado. Tem demasiado dinheiro?
Ler mais:
Desafios do CTO - aumento de escala e crescimento de produtos de software
Que BD escolher para o seu tipo de dados específico no seu projeto de software
Portuguese 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Spanish 
Dutch 
Estonian 
Greek 
Czech