Quando uma pequena empresa começou, havia apenas algumas pessoas que fabricavam produtos. No momento, não há necessidade de nenhum gerenciamento. Você pode se encontrar e discutir muitas coisas. No entanto, como a empresa continua a crescer e desenvolver mais e mais produtos, os líderes e backbones técnicos cairão em atividades de negócios de baixo nível e pesadas. Isso geralmente leva a um fenômeno: a empresa parece estar ficando cada vez maior, todos estão ficando ocupados, mas os produtos estão cada vez piores e o tempo de P&D está cada vez mais incontrolável.
Quando esses problemas ocorrem, todos normalmente começam a introduzir vários sistemas de gerenciamento, o mais comum dos quais são vários softwares de gerenciamento de processo. Quando introduzimos esse tipo de processo de gerenciamento, muitas vezes temos ilusões irrealistas, tais como: pode supervisionar automaticamente o trabalho de todos os funcionários, pode registrar automaticamente a carga de trabalho de tudo e automaticamente lembrar a todos o que fazer a seguir. Infelizmente, se esse tipo de software for usado para gerenciamento de depósitos ou caixas de supermercados, é muito eficiente, mas se usado para gerenciamento de desenvolvimento de software, será insatisfatório.
Qual é a causa subjacente de tal confusão de gerenciamento? Lembro-me de que certo especialista em educação nos Estados Unidos certa vez disse algo a respeito: "Devemos educar nossos cidadãos para que sejam inteligentes o suficiente para operar o sistema automatizado e estúpidos demais para aceitar todos aqueles empregos ruins." Simplificando, se você deseja que esse tipo de sistema de processo automatizado funcione sem problemas, ele exige que os funcionários vinculados ao sistema sejam funcionários tolos.
A pesquisa e o desenvolvimento de software são atividades puramente mentais com alto QI. Os engenheiros de software são, em sua maioria, intelectuais que foram treinados por muitos anos. A inquietação interna e os desejos humanos causarão conflitos frequentes entre o pessoal e os sistemas. O desempenho mais típico é que todos estão dispostos a aproveitar as lacunas no processo, especialmente as lacunas nos vários mecanismos de avaliação de KPI. Isso deixará os membros da equipe muito ansiosos por sucesso rápido e benefícios de curto prazo, e ninguém considera os interesses de longo prazo da empresa, o que acaba levando a mais lutas internas do que colaborações.
Depois que uma empresa atingiu um determinado nível, definitivamente não funcionará sem gerenciamento, e a gestão de processos tradicional também não funcionará. A gestão parece ser a única maneira de indivíduos e empresas crescerem. Existe uma estratégia melhor?
O sistema de gestão da qualidade total (TQM) passa muito tempo criticando várias avaliações de KPI e enfatizando a liderança pessoal. Depois de entrar em contato com a TQM, senti que havia descoberto outro caminho e encontrado um sistema de gerenciamento de P&D de software de baixo custo adequado para pequenas equipes com membros ativos.
Acho que a característica mais importante deste sistema de gestão é o respeito pela natureza humana. A maioria dos engenheiros de P&D de software tem um forte desejo de crescer. O sistema de gerenciamento impulsionado pelas necessidades endógenas dessa natureza humana de nível inferior pode ser menos compreendido da perspectiva dos gerentes profissionais, mas há menos resistência no processo de implementação e o efeito é óbvio.
É preciso enfatizar que o sistema de gestão da qualidade total (TQM) é mais uma metodologia, um tanto semelhante ao Tao. É necessário combinar as características do produto real e considerar várias restrições, como a capacidade dos membros da equipe de construir estratégias viáveis, que já se assemelham às técnicas. Nesta seção, descreveremos algumas estratégias que nossa equipe gosta de usar, mas devido às diferentes restrições, todos podem apenas entender, é difícil copiar.
◇◇◇
O sistema de documentos é uma tarefa muito confusa no processo de desenvolvimento de software. Muitos envios de produtos da empresa são apenas um amontoado de códigos. Se um funcionário-chave se demitir, será difícil para as gerações futuras assumir o cargo. Isso causará grandes perdas à empresa e até mesmo levará à fragmentação das linhas de produtos relacionadas.
Todos podem perceber naturalmente que esse estado não está certo, então em algum momento em que o trabalho não esteja ocupado, o líder vai pedir a todos que façam os documentos. Infelizmente, esse tipo de documento temporário elaborado para atender aos requisitos da liderança tem pouco valor na maioria dos casos, por exemplo, se os documentos não corresponderem ao código, podem até ter um efeito negativo. Muito trabalho duro, desperdiçou muita mão de obra e recursos materiais, e finalmente se transformou em um monte de trabalho inútil.
Como resolver o dilema do documento?
O sistema de gestão da qualidade total enfatiza a orientação para as pessoas, e os documentos são produzidos por pessoas, portanto, elas devem servi-los. Com base nessa filosofia, nossa equipe chegou a um consenso básico: apenas escreva documentos úteis e escreva documentos úteis. Com base neste conceito de design, a estrutura do sistema de documentos de suporte de P&D construída por nossa equipe é mostrada na figura abaixo (Observação: documentos relacionados, como iniciação do projeto, pesquisa do usuário, resumo de requisitos e aceitação são os documentos de processo de nível superior da empresa. O sistema de documentos nesta seção se refere apenas a Documentos de suporte para o trabalho de P&D):
Os documentos de projeto de arquitetura, que foram explicados várias vezes acima, não são apenas usados para orientar o projeto de arquitetura de produto, mas também uma missão importante para auxiliar a equipe na comunicação interna e chegar a um consenso. Quando um recém-chegado se junta, também é necessário compreender o documento de design de arquitetura antes de iniciar um trabalho específico. Para atingir esses objetivos, os documentos de design de arquitetura são principalmente gráficos, complementados pelas descrições de texto necessárias.
Em nosso plano, não há documento específico de design detalhado. O documento de design detalhado se concentra na descrição de cada módulo de software. Alguns módulos são relativamente simples, apenas uma descrição do design de arquitetura; alguns módulos têm abstrações de interfaces mais complexas, e seria melhor se houvesse um parágrafo de texto para descrever suas ideias de design; alguns módulos são adequados para a adoção de status A programação de computadores, neste momento seu documento de design detalhado é um diagrama de estado.
Após anos de prática, nossa equipe gosta da estratégia de código e documentação. Integrar documentos de design detalhados e código é, antes de tudo, para facilitar a revisão.Se você puder primeiro entender as idéias de design ao revisar o código, a eficiência da revisão pode ser muito maior. Além disso, com o auxílio do mecanismo de revisão, também ajuda a manter os documentos e o código sincronizados.
Na arquitetura distribuída, é necessário construir um link de comunicação baseado na rede lata, e a máquina de estado é a mais adequada para uso no momento. O código a seguir é a máquina de estado do link de comunicação da rede CAN. Após um treinamento de longo prazo, todos já estão familiarizados com este diagrama de estado baseado em texto. Se houver vários caminhos de estado, estaremos acostumados a usar diferentes linhas de comentário para descrever.
/* 主CPU和各扩展CPU连接状态机 */
#define LINK_STATE_IDLE 0 /* 初态。成功发出连接命令后进入LINK状态 */
#define LINK_STATE_LINK 1 /* 连接态
* 接收到板类型进入状态TIME,发送对时命令,并设置连接正常;
* 超时后重发连接命令,并设置连接异常
*/
#define LINK_STATE_TIME 2 /* 对时态。超时后发送对时命令,进入RX态 */
#define LINK_STATE_RX 3 /* 接收态
* 接收任何帧时返回TIME状态;
* 超时后返回LINK状态,发送连接命令,并设置连接异常
*/
A lista de verificação de revisão de código é um documento de equipe iterativo contínuo, seu principal objetivo é orientar o processo de revisão de código. O documento checkList de revisão de código é o ativo mais valioso dentro da equipe, mas importante não significa emergência. Normalmente todos estão presos em um trabalho específico, ninguém vai tomar a iniciativa de construir o documento, precisa ser complementado por alguns sistemas para garanti-lo. Por exemplo, se o auditor encontrar um problema comum, ele precisa considerar se adiciona a lista de verificação; por exemplo, depois que um bug é resolvido, ele também precisa considerar se adiciona a lista de verificação simultaneamente, ..., no trabalho real, é necessário esclarecer quais posições ou empregos têm manutenção de lista de verificação Responsabilidade.
Ao construir uma lista de verificação, estamos acostumados a adicionar um escritor a cada registro. A lista de verificação é a riqueza da equipe. Freqüentemente, usamos a lista de verificação como base para o treinamento e avaliação do novato. Ela não apenas ajuda a equipe a manter o ritmo, mas também ajuda a cultivar a liderança dentro da equipe. É uma honra para a equipe. Muitas pessoas gostam muito desta homenagem, por isso participarão ativamente da manutenção do checklist, o que também ajuda a formar excelentes auditores.
Mais uma coisa precisa ser adicionada: o documento da lista de verificação não deve ser simples de usar. Algumas empresas acham que suas listas de verificação são pequenas e precárias no início, então, rapidamente copiam muitas delas e, eventualmente, as tornam inutilizáveis. Menos é mais, lento é rápido, continue a construir com base nas características de sua empresa, equipe e produtos, selecione e complete um por um, mantenha a disponibilidade e evite a formalização.
◇◇◇
Na pesquisa e desenvolvimento de software embarcado em produtos industriais, o fator "pessoas" é sempre o primeiro. Como construir uma equipe de talentos positivos pode ser a primeira tarefa do líder de equipe.
Para formar uma equipe de talentos, precisamos treinar, mas o motivo é simples e a realidade é constrangedora. Muitas empresas recebem um treinamento inicial intensivo quando os funcionários entram na empresa. Depois de explicar o sistema básico da empresa, eles ficam em estado de estoque. Até onde todos podem ir depende mais do esforço pessoal e da sorte.
Eu pessoalmente não gostei do modo de treinamento centralizado. Lembro-me que meu treinamento inicial foi uma explicação de um professor para outro. Fiquei sonolento ouvindo. Deve haver mais treinamento no processo de desenvolvimento de produto subsequente, mas geralmente falta.
O treinamento é difícil de implementar. Ao mesmo tempo, há muitos empregos no local de trabalho que as pessoas não estão dispostas a fazer. Lembra dos dois anéis que mencionei antes?
No trabalho real, todos preferem o trabalho de escrever código, mas não gostam do trabalho de revisão de código e teste de integração. Se não houver um requisito de especificação de código uniforme, ler o código de outras pessoas é uma coisa muito dolorosa e é ainda melhor reescrevê-lo você mesmo. Da mesma forma, se não houver arquitetura unificada e pensamento de interface, o teste de integração também será difícil de implementar.
Eu me pergunto se você pode perceber que a revisão de código é, na verdade, uma tarefa mais avançada do que a codificação. Antes da revisão do código, você não deve apenas pensar na estrutura geral do programa, mas também levar em consideração várias perspectivas, como produtos e equipes, e até mesmo aprender a tolerar outros funcionários. Mais importante, a revisão é a melhor estratégia de treinamento.
A princípio, tive um mal-entendido de que o trabalho de teste é de nível relativamente baixo e é um tipo de trabalho "bobo". Na verdade, o teste de integração também é um trabalho mais avançado. Não é necessário apenas pensar se a implementação interna do módulo é razoável, mas também testar se os módulos são compatíveis e, mais frequentemente, é preciso pensar com base na perspectiva do produto. Semelhante à auditoria, o teste de integração também é uma estratégia de treinamento para programadores de módulo.
Similar a isso, trabalhos como decomposição e sincronização de problemas e exclusão mútua no local do projeto também requerem uma certa habilidade de lidar com eles. Elimine mal-entendidos de todos e redefina essas tarefas no processo de desenvolvimento de produtos, não só para evitar o constrangimento de algumas tarefas que ninguém está fazendo, mas também para selecionar automaticamente o escalão de talentos.
Entre os funcionários comuns, um funcionário com grande habilidade, atitude séria e certa liderança dentro da equipe irá naturalmente se tornar um funcionário de apoio e um auditor.Neste momento, sua tarefa será sublimada para: revisar o código dos funcionários comuns. Auxiliar quando é difícil encontrar uma anormalidade, e substituir rapidamente temporariamente quando alguém pede licença ou deixa o emprego, realiza a codificação de módulos de um certo grau de dificuldade e teste de integração de nível de produto.
Com a iteração contínua desse sistema de seleção de pessoal, gerentes de produto nascerão entre auditores, líderes de linha de produto nascerão entre gerentes de produto e arquitetos nascerão naturalmente entre gerentes de linha de produto. Esse tipo de arquiteto que cresce naturalmente geralmente tem fortes habilidades de liderança e coordenação, muito mais fortes do que as atribuídas pelo líder.
Se você quiser ganhar mais dinheiro e ter uma posição superior, deve ter a capacidade de treinar pessoal de nível superior e crescer para funcionários de apoio de nível superior. Este tipo de estrutura de talentos é um modelo de organização escalonado apoiado em camadas, desde que seja bem dividido Trabalho, movido pela natureza humana, uma excelente equipe auto-iterativa é construída naturalmente.
Um ponto adicional é que, ao apoiar o trabalho dos funcionários, eles geralmente adotam uma estratégia de homem para homem no local. Existem duas estratégias de marcação de pessoas: uma é fazer o trabalho sozinho e deixar o recém-chegado observar e aprender, e a outra é fazer o trabalho e observar sozinho. Essa estratégia é bastante eficiente e pode descobrir rapidamente os problemas dos recém-chegados, o que é muito mais eficiente do que apenas revisar os resultados finais.
◇◇◇
Sistema de documentos, construção de equipes, esse tipo de trabalho é o problema antigo e difícil no trabalho tradicional de pesquisa e desenvolvimento. Agora, com a ajuda de um sistema de gestão de qualidade total (TQM), e impulsionado por uma humanidade positiva, desmontamos essas tarefas e as integramos em assuntos diários específicos, e a execução tem uma sensação de fluxo suave.
Reconstruir todo o processo de P&D com esse conceito acabará por formar um sistema de gestão eficiente que parece não ter gestão.
———————————————
Eu sou Xiaomaer, um engenheiro de software embarcado que anseia por consciência e alma. Dê as boas-vindas à sua empresa e viaje. Se estiver interessado, você pode adicionar uma conta pessoal do WeChat nzn_xiaomaer para se comunicar, e você precisa anotar a palavra " dimensão diferente ".