Get best of the week

Contrat de développement de l'électronique. Calcul de projet




Chaque mois, des dizaines d'applications pour le développement de l'électronique nous viennent. Et chaque client potentiel veut connaître le coût de la résolution de son problème, quelle que soit sa compréhension. Un développeur de contrat peut-il plaire à tout le monde? Comment éliminer à l'avance les "désespérés"? Comment évaluer les projets qui ont une chance de développement? Ceci est notre nouvel article.

Quels projets ne devraient pas être considérés


Lorsque nous avons commencé, chaque demande par la poste semblait être un cadeau du destin. Nous nous sommes assis avec toute notre petite équipe et avons trouvé à quel point nous mettons en œuvre ce projet. Il semblait nécessaire de donner à chaque client potentiel le maximum de détails. Il faut choisir les principales solutions techniques, décomposer le travail en étapes, en tâches individuelles, tracer un diagramme de Gantt, calculer le coût du produit et décrire tout cela le plus en détail possible dans une proposition commerciale (KP). Nous avons dépensé sur chaque CP jusqu'à plusieurs jours, et les clients ont réfléchi éternellement. Au fil du temps, la compréhension est venue que vous ne pouvez pas perdre de temps les ingénieurs et filtrer les projets sans avenir


avant même de plonger dans les détails techniques. Tout d'abord, il faut comprendre la gravité des intentions du futur Client. Hélas, les demandes comme «J'ai vu hier sur Internet un appareil pour 50 000 roubles, faites-moi de même pour 30 000 roubles» sont plus courantes que nous le souhaiterions.

Que devons-nous demander pour évaluer les chances de réussite du projet?


  1. Pourquoi une organisation a-t-elle besoin d'un produit donné (objectifs de création de produit)? Nous devons trouver la formulation la plus précise de la tâche commerciale. Nous filtrons donc les rêveurs avec la prochaine "idée géniale" d'un tapis de bain automatisé, avec Bluetooth et une application mobile.
  2. Qui est l'initiateur du projet (DM)? Nous découvrons qui est responsable de la technologie et qui alloue le budget. Ce sont généralement des personnes différentes, et elles nécessitent des approches différentes en termes de ventes.
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

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


-




Ainsi, le client et le projet répondent à toutes les exigences, nous commençons l'évaluation. L'évaluation est inexacte et impropre. Si nous n'avons pas encore de savoirs traditionnels, nous obtenons une évaluation impropre avec un large écart. A écrit TK - a reçu une évaluation inexacte. Sans savoirs traditionnels, le score a une tolérance de ± 400% ou plus. C'est ce qu'on appelle le cône d'incertitude: le graphique sur les interfaces, mais l'essence des différents projets est la même. Plus nous en savons, moins d'incertitude. Ne perdez pas de temps et d'efforts sur les savoirs traditionnels.




Nos réunions d'évaluation de projet portent le nom officieux de «Vanga Club». Les participants se familiarisent à l'avance avec le matériel du projet. À l'heure fixée, le Club reçoit: un homme d'affaires, un chef de projet, un ingénieur de circuits de premier plan, un programmeur de premier plan. Parfois, des spécialistes supplémentaires ayant une expertise étroite sont invités, ainsi que des représentants des entrepreneurs. Autant de personnes sont nécessaires pour une revue complète du projet. Le commerçant est content de sa chance et s'efforce de satisfaire le client en simplifiant les exigences. Le chef de projet devra donner vie au projet, il sera responsable du timing, du coût et de la quantité de travail. Son désir est de constituer une réserve, de prendre en compte les risques. Les ingénieurs veulent faire mieux qu'hier. Ils peuvent facilement refuser une option simple mais "inintéressante". Sans chef de projet, vous pouvez prendre une commande sous-estimée, car un homme d'affaires est très éloquent.Sans commerçant, vous pouvez compter tellement que le client ne répond même pas à la lettre.



La réunion commence par une discussion générale du problème pour former une compréhension commune par tous les participants. Ensuite, une structure hiérarchique de travail ( WBS ) est construite pour le projet .
Pour un seul appareil, les composants logiciels et matériels sont attribués. Pour le système, différentes parties sont ajoutées comme le logiciel de test, les simulateurs, la partie serveur, etc. Les pièces résultantes sont divisées en parties plus petites, par exemple, des branches matérielles en deux révisions du PCB et de la conception. L'étape suivante consiste à diviser les pièces en tâches distinctes. Si tout est clair avec la mise en œuvre, les tâches doivent être petites. La tâche "Écrire le firmware" ne correspond pas catégoriquement. Nous considérons des tâches spécifiques normales avec de faibles notes, par exemple: «Pilote MCU I2C», «Raise the Project», «E3 Scheme».
Vous ne devez pas évaluer la complexité des tâches à l'avance, car leur complexité et leurs relations ne deviendront claires que lorsqu'elles seront toutes écrites au tableau.

Toutes les tâches sont affectées au travail en heures. La méthode est une expertise . Une horloge peut prendre des valeurs à partir d'un certain nombre de puissances de deux: 2, 4, 8, 16, 32, 64, 128 ... Les tâches avec une évaluation de 128 heures ou plus apparaissent lorsque l'implémentation n'est pas claire. Cela signifie qu'il vaut la peine d'effectuer des travaux pour clarifier les exigences, vérifier l'applicabilité de la technologie et parfois même simplement disperser et fumer un google.
Selon mes observations, il est possible d'augmenter la précision de l'évaluation, tout d'abord, en demandant l'avis de développeurs moins expérimentés. Ils apprennent donc à évaluer les tâches plus rapidement par eux-mêmes. Si un ingénieur de bonne réputation s'est déjà prononcé, tout le monde a tendance à être simplement d'accord avec son opinion. Et lorsque le travail sur le projet commencera, les tâches seront probablement résolues non par lui, mais par ceux qui n'ont rien dit. Nous entendrons toujours leur évaluation, mais pas au bon moment.
Lorsque toutes les tâches sont évaluées, nous résumons les résultats et ajoutons 30% au logiciel pour le débogage et 30% supplémentaires au test du logiciel. Ces chiffres sont tirés des statistiques sur les projets achevés.
En conséquence, l'image suivante apparaît sur le tableau:



L'évaluation est généralement accompagnée d'une discussion approfondie des détails, car il peut y avoir de nombreuses options pour résoudre le problème. Cela ne prend donc pas moins d'une heure. Étant donné le temps de préparation, même une évaluation préliminaire du projet peut coûter 5 à 20 heures aux principaux développeurs.

Nous voulons tous créer des produits performants, des appareils électroniques qui profiteront aux gens. Nous discutons de la façon dont les résultats de l'évaluation (délais, ressources) sont cohérents avec les objectifs du projet dans son ensemble. Il peut être intéressant d'offrir au client d'autres moyens. Par exemple, pour réduire les fonctionnalités de MVP, ou pour prendre du matériel plus cher en faveur d'un développement moins cher. Il est utile de calculer grossièrement l'économie globale du projet pour les étapes suivantes: production, production, support. Ces chiffres montrent le poids relatif des ressources et du temps pour les étapes du projet et peuvent changer considérablement leur perception (à la fois la nôtre et celle du client).

Les notes reçues du Wang Club sont entrées dans Redmine. EasyWBS convient pour ajouter rapidement des tâches sous une forme visuelle:




Pour déterminer le moment du développement, nous construisons des tâches de fer en chaînes (cascade). Nous obtenons ce Gantt: pour les logiciels, nous divisons l'intensité du travail en productivité du nombre de personnes qui peuvent être impliquées dans le projet en même temps. Comme vous le savez, ce qu'un programmeur fait en un mois, deux programmeurs en deux mois. Vous ne devez donc pas prendre en compte toutes vos ressources en personnel lors du calcul. De plus, tous les programmeurs ne peuvent pas commencer à travailler dès le début. Il arrive que vous deviez attendre le fer, le vôtre ou acheté. Le même retard peut se produire à la jonction des étapes et des révisions du fer. Pour informer le client, les dates reçues ne peuvent être prises. Sauf avec le préfixe "prévisions optimistes". Il vaut mieux donner une petite marge. Il vous sera utile.






Dans le module Calcul, des tarifs pour les spécialistes sont ajoutés et les coûts pour les co-contractants, la production, les matériaux, les appareils, etc. sont ajoutés. Une excellente offre commerciale pour le client.pdf que nous créons directement à partir d'ici. Découvrez comment nos collègues évaluent les projets différemment en utilisant l'exemple d'une seule demande. Petite analyse de douze KP . Ainsi, le projet est accepté, évalué. Reste à signer le contrat - et allez-y, réécrivez les tâches, changez les solutions techniques, étendez les exigences, changez le projet au-delà de la reconnaissance!









Pour nous, il n'est pas question d'évaluer les projets ou non, car nous faisons des projets pour les clients, cela ne fonctionnera pas pour obtenir un contrat sans évaluation. Mais avec les projets internes aux entreprises, la situation est différente. Souvent, les projets internes ne sont pas évalués. Et très en vain. La conséquence de cette approche est la sous-estimation du temps et des ressources. Ni l'équipe ni la direction ne peuvent évaluer l'avancement actuel du projet. D'où l'incompréhension et la démoralisation de l'équipe.

Et maintenant - allons discuter dans les commentaires de vos approches de l'évaluation de projet!

More articles:


All Articles