Get best of the week

Desenvolvimento de contrato de eletrônica. Cálculo do projeto




Todo mês, dezenas de aplicativos para o desenvolvimento de produtos eletrônicos chegam até nós. E cada cliente em potencial deseja saber o custo de resolver seu problema, independentemente de quão bem ele o entenda. Um desenvolvedor de contrato pode agradar a todos? Como eliminar antecipadamente os "desesperados"? Como avaliar os projetos que têm chance de desenvolvimento? Este é o nosso novo artigo.

Quais projetos não devem ser considerados


Quando começamos, cada aplicativo no correio parecia um presente do destino. Sentamos com toda a nossa pequena equipe e descobrimos como estamos implementando esse projeto. Parecia que era necessário fornecer a cada cliente em potencial o máximo de detalhes. É necessário escolher as principais soluções técnicas, dividir o trabalho em etapas, realizar tarefas individuais, desenhar um gráfico de Gantt, calcular o custo do produto e descrever tudo isso o mais detalhadamente possível em uma proposta comercial (KP). Gastamos em cada CP por vários dias e os clientes foram levados em consideração eterna. Com o tempo, chegou-se ao entendimento de que você não pode perder tempo com engenheiros e filtrar projetos sem futuro


mesmo antes de mergulhar nos detalhes técnicos. Antes de tudo, é necessário entender a seriedade das intenções do futuro Cliente. Infelizmente, solicitações como “eu vi ontem na Internet um dispositivo para 50.000 rublos, faça-o para 30.000 rublos” são mais comuns do que gostaríamos.

O que precisamos perguntar para avaliar as chances de o projeto ser bem-sucedido?


  1. Por que uma organização precisa de um determinado produto (metas de criação de produto)? Precisamos descobrir a formulação mais precisa da tarefa de negócios, para filtrar os sonhadores com a próxima "idéia brilhante" de um tapete de banho automatizado, com bluetooth e um aplicativo móvel.
  2. Quem é o iniciador do projeto (DM)? Descobrimos quem é responsável pela tecnologia e quem aloca o orçamento. Normalmente, são pessoas diferentes e exigem abordagens diferentes em termos de vendas.
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

    • — :
      1. (, )?
      2. ?
      3. (), ? -? ?
    • — : . , , . « », , .
    • ? ? ? — .
  9. ? — :
    • (, )?
    • (, )?
    • ?
    • , ?
    • ( )?
  10. () ( )? «», - . , 9 .
  11. ? , . , , .
  12. (, , , )? « , ». , -.
  13. ? : , .
  14. ? – .
  15. ? (, , , , ). . ?
  16. ? ?
  17. (, , )?
  18. ? .


-




Assim, o cliente e o projeto atendem a todos os requisitos, iniciamos a avaliação. A avaliação é imprecisa e imprópria. Se ainda não temos TK, obtemos uma avaliação inadequada com um spread grande. Escreveu TK - recebeu uma avaliação imprecisa. Sem TK, a pontuação tem uma tolerância de ± 400% ou mais. Isso é chamado cone de incerteza: o gráfico sobre as interfaces, mas a essência em diferentes projetos é a mesma. Quanto mais sabemos, menos incerteza. Não poupe tempo e esforço no TK.




Nossas reuniões de avaliação de projetos têm o nome não oficial de “Vanga Club”. Os participantes se familiarizam com os materiais do projeto com antecedência. Na hora marcada, o clube recebe: um empresário, um gerente de projetos, um engenheiro de circuito líder, um programador líder. Às vezes, especialistas adicionais com conhecimento limitado são convidados, bem como representantes de contratados. São necessárias tantas pessoas para uma revisão abrangente do projeto. O comerciante está satisfeito com sua sorte e se esforça para satisfazer o cliente, simplificando os requisitos. O gerente de projeto terá que dar vida ao projeto, ele será responsável pelo tempo, custo e quantidade de trabalho. Seu desejo é estabelecer uma reserva, assumir riscos em consideração. Os engenheiros querem fazer melhor do que ontem. Eles podem facilmente recusar uma opção simples, mas "desinteressante". Sem um gerente de projeto, você pode fazer um pedido subestimado, porque um empresário é muito eloqüente.Sem um comerciante, você pode contar tanto que o cliente nem responde à carta.



A reunião começa com uma discussão geral do problema para formar um entendimento comum de todos os participantes. Em seguida, uma estrutura hierárquica de trabalho ( WBS ) é construída para o projeto .
Para um único dispositivo, as peças de software e hardware são alocadas. Para o sistema, partes diferentes são adicionadas, como software de teste, simuladores, parte do servidor etc. As partes resultantes são divididas em partes menores, por exemplo, ramificações de hardware em duas revisões do PCB e do design. O próximo estágio é dividir as partes em tarefas separadas. Se tudo estiver claro com a implementação, as tarefas deverão ser pequenas. A tarefa "Gravar firmware" categoricamente não se encaixa. Consideramos tarefas específicas normais com classificações pequenas, por exemplo: “Driver MCU I2C”, “Elevar o projeto”, “Esquema E3”.
Você não deve avaliar a complexidade das tarefas com antecedência, porque a complexidade e os relacionamentos só serão claros quando todos estiverem escritos no quadro.

Todas as tarefas recebem mão de obra em horas. O método é uma avaliação especializada . Um relógio pode assumir valores de um número de potências de dois: 2, 4, 8, 16, 32, 64, 128 ... Tarefas com uma avaliação de 128 horas ou mais aparecem quando a implementação não está clara. Isso significa que vale a pena realizar trabalhos para esclarecer os requisitos, verificar a aplicabilidade da tecnologia e, às vezes, apenas dispersar e fumar o google.
De acordo com minhas observações, é possível aumentar a precisão da avaliação, solicitando a opinião de desenvolvedores menos experientes. Então eles aprendem a avaliar as tarefas mais rapidamente por conta própria. Se um engenheiro respeitável já se manifestou, todo mundo tende a simplesmente concordar com sua opinião. E quando o trabalho no projeto começar, as tarefas provavelmente serão resolvidas não por ele, mas por aqueles que não disseram nada. Ainda ouviremos sua avaliação, mas não no momento certo.
Quando todas as tarefas são avaliadas, resumimos os resultados e adicionamos 30% ao software para depuração e outros 30% ao teste de software. Esses números são obtidos das estatísticas dos projetos concluídos.
Como resultado, a seguinte imagem aparece no quadro:



A avaliação geralmente é acompanhada por uma discussão aprofundada dos detalhes, porque pode haver muitas opções para resolver o problema. Portanto, leva não menos de uma hora. Dado o tempo de preparação, mesmo uma avaliação preliminar do projeto pode custar de 5 a 20 horas para os principais desenvolvedores.

Todos nós queremos produzir produtos de sucesso, eletrônicos que beneficiem as pessoas. Discutimos como os resultados da avaliação (cronogramas, recursos) são consistentes com os objetivos do projeto como um todo. Pode valer a pena oferecer ao cliente outras maneiras. Por exemplo, para reduzir a funcionalidade do MVP, ou para usar hardware mais caro em favor de um desenvolvimento mais barato. É útil calcular aproximadamente a economia geral do projeto para estágios subsequentes: produção, produção, suporte. Esses números mostram o peso relativo de recursos e tempo para as etapas do projeto e podem mudar significativamente sua percepção (tanto a nossa quanto o cliente).

As classificações recebidas do Wang Club são inseridas no Redmine. O EasyWBS é adequado para adicionar tarefas rapidamente de forma visual:




Para determinar o momento do desenvolvimento, construímos tarefas de ferro em cadeias (cascata). Gantt: Para o software, dividimos a intensidade do trabalho na produtividade do número de pessoas que podem estar envolvidas no projeto ao mesmo tempo. Como você sabe, o que um programador faz em um mês, dois programadores fazem em dois meses. Portanto, você não deve levar em consideração todos os recursos de seu pessoal ao calcular. Além disso, nem todos os programadores de projetos podem começar a trabalhar desde o início. Acontece que você precisa esperar pelo ferro, seu ou adquirido. O mesmo atraso pode ocorrer na junção de estágios e revisões de ferro. Para informar o cliente, as datas recebidas não podem ser tomadas. A menos que com o prefixo "previsão otimista". É melhor dar uma pequena margem. Ele será útil.






No módulo Cálculo, são adicionadas taxas para especialistas e custos para co-contratantes, produção, materiais, dispositivos etc. Uma excelente oferta comercial para o customer.pdf que criamos diretamente a partir daqui. Leia como nossos colegas avaliam projetos de maneira diferente usando o exemplo de uma única solicitação. Pequenas análises de doze KP . Assim, o projeto é aceito, avaliado. Resta assinar o contrato - e prosseguir, reescrever tarefas, alterar soluções técnicas, expandir requisitos, mudar o projeto além do reconhecimento!









Para nós, não há dúvida de avaliar projetos ou não, porque estamos fazendo projetos para clientes, não funcionará para obter um contrato sem avaliação. Mas com projetos internos nas empresas, a situação é diferente. Freqüentemente, projetos internos não são avaliados. E muito em vão. A conseqüência dessa abordagem é a subestimação de tempo e recursos. Nem a equipe nem a gerência podem avaliar o progresso atual do projeto. Daí o mal-entendido e a desmoralização da equipe.

E agora - vamos discutir nos comentários suas abordagens para avaliação de projetos!

More articles:


All Articles