Get best of the week

Auftragsentwicklung von Elektronik. Projektberechnung




Jeden Monat kommen Dutzende von Anwendungen fĂŒr die Entwicklung der Elektronik zu uns. Und jeder potenzielle Kunde möchte wissen, welche Kosten fĂŒr die Lösung seines Problems anfallen, unabhĂ€ngig davon, wie gut er es versteht. Kann ein Vertragsentwickler allen gefallen? Wie kann man die "Hoffnungslosen" im Voraus aussortieren? Wie kann man Projekte bewerten, die eine Chance auf Entwicklung haben? Dies ist unser neuer Artikel.

Welche Projekte sollten nicht berĂŒcksichtigt werden


Als wir anfingen, schien jede Bewerbung in der Mail ein Geschenk des Schicksals zu sein. Wir haben uns mit unserem gesamten kleinen Team zusammengesetzt und festgestellt, wie cool wir dieses Projekt umsetzen. Es schien notwendig, jedem potenziellen Kunden das grĂ¶ĂŸtmögliche Detail zu geben. Es ist notwendig, die wichtigsten technischen Lösungen auszuwĂ€hlen, die Arbeit in Phasen und einzelne Aufgaben aufzuteilen, ein Gantt-Diagramm zu zeichnen, die Kosten des Produkts zu berechnen und all dies so detailliert wie möglich in einem kommerziellen Vorschlag (KP) zu beschreiben. Wir haben bis zu mehreren Tagen fĂŒr jeden CP aufgewendet, und die Kunden haben ewige Überlegungen angestellt. Im Laufe der Zeit kam das VerstĂ€ndnis, dass man keine Zeit mit Ingenieuren verschwenden und Projekte ohne Zukunft aussortieren kann


noch bevor man in technische Details eintaucht. ZunĂ€chst ist es notwendig, die Ernsthaftigkeit der Absichten des zukĂŒnftigen Kunden zu verstehen. Leider sind Anfragen wie "Ich habe gestern im Internet ein GerĂ€t fĂŒr 50.000 Rubel gesehen, mach es mir fĂŒr 30.000 Rubel" hĂ€ufiger als wir möchten.

Was mĂŒssen wir fragen, um die Erfolgschancen des Projekts einzuschĂ€tzen?


  1. Warum benötigt eine Organisation ein bestimmtes Produkt (Produkterstellungsziele)? Wir mĂŒssen die genaueste Formulierung der GeschĂ€ftsaufgabe herausfinden. Deshalb filtern wir TrĂ€umer mit der nĂ€chsten "brillanten Idee" einer automatisierten Badematte mit Bluetooth und einer mobilen Anwendung heraus.
  2. Wer ist der Initiator des Projekts (DM)? Wir finden heraus, wer fĂŒr die Technologie verantwortlich ist und wer das Budget zuweist. In der Regel handelt es sich dabei um unterschiedliche Personen, und sie erfordern unterschiedliche VerkaufsansĂ€tze.
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

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


-




Damit der Kunde und das Projekt alle Anforderungen erfĂŒllen, beginnen wir mit der Bewertung. Die Bewertung ist ungenau und nicht geeignet. Wenn wir noch keine TK haben, erhalten wir eine ungeeignete Bewertung mit einem großen Spread. Schrieb TK - erhielt eine ungenaue Bewertung. Ohne TK hat der Score eine Toleranz von ± 400% oder mehr. Dies nennt man den Kegel der Unsicherheit: Die Grafik ĂŒber die Schnittstellen, aber das Wesentliche bei verschiedenen Projekten ist das gleiche. Je mehr wir wissen, desto weniger Unsicherheit. Nehmen Sie sich keine Zeit und MĂŒhe fĂŒr TK.




Unsere Projektbewertungstreffen tragen den inoffiziellen Namen „Vanga Club“. Die Teilnehmer machen sich vorab mit den Materialien des Projekts vertraut. Zur festgesetzten Zeit erhĂ€lt der Club: einen GeschĂ€ftsmann, einen Projektmanager, einen fĂŒhrenden Schaltungsingenieur und einen fĂŒhrenden Programmierer. Manchmal werden zusĂ€tzliche Spezialisten mit engem Fachwissen sowie Vertreter von Auftragnehmern eingeladen. FĂŒr eine umfassende ÜberprĂŒfung des Projekts werden so viele Personen benötigt. Der HĂ€ndler ist mit seinem GlĂŒck zufrieden und bemĂŒht sich, den Kunden durch Vereinfachung der Anforderungen zufrieden zu stellen. Der Projektmanager muss das Projekt zum Leben erwecken, er ist fĂŒr den Zeitpunkt, die Kosten und den Arbeitsaufwand verantwortlich. Sein Wunsch ist es, eine Reserve zu bilden, Risiken zu berĂŒcksichtigen. Ingenieure wollen es besser machen als gestern. Sie können eine einfache, aber "uninteressante" Option leicht ablehnen. Ohne einen Projektmanager können Sie eine unterschĂ€tzte Bestellung annehmen, da ein GeschĂ€ftsmann sehr eloquent ist.Ohne HĂ€ndler können Sie so viel zĂ€hlen, dass der Kunde den Brief nicht einmal beantwortet.



Das Treffen beginnt mit einer allgemeinen Diskussion des Problems, um allen Teilnehmern ein gemeinsames VerstĂ€ndnis zu vermitteln. Anschließend wird eine hierarchische Arbeitsstruktur ( PSP ) fĂŒr das Projekt erstellt .
FĂŒr ein einzelnes GerĂ€t werden Software- und Hardwareteile zugewiesen. FĂŒr das System werden verschiedene Teile wie Testsoftware, Simulatoren, Serverteile usw. hinzugefĂŒgt. Die resultierenden Teile werden in kleinere Teile aufgeteilt, z. B. Hardware-Zweige in zwei Revisionen der Leiterplatte und des Designs. Die nĂ€chste Stufe besteht darin, die Teile in separate Aufgaben aufzuteilen. Wenn bei der Implementierung alles klar ist, sollten die Aufgaben klein sein. Die Aufgabe "Firmware schreiben" passt kategorisch nicht. Wir betrachten normale spezifische Aufgaben mit kleinen Bewertungen, zum Beispiel: "MCU I2C Driver", "Raise the Project", "E3 Scheme".
Sie sollten die KomplexitÀt von Aufgaben nicht im Voraus bewerten, da ihre KomplexitÀt und Beziehungen erst dann klar werden, wenn sie alle an die Tafel geschrieben sind.

Allen Aufgaben wird Arbeit in Stunden zugewiesen. Die Methode ist eine Expertenbewertung . Eine Uhr kann Werte aus einer Anzahl von Zweierpotenzen annehmen: 2, 4, 8, 16, 32, 64, 128 ... Aufgaben mit einer Bewertung von 128 Stunden oder mehr werden angezeigt, wenn die Implementierung nicht klar ist. Dies bedeutet, dass es sich lohnt, Arbeiten durchzufĂŒhren, um die Anforderungen zu klĂ€ren, die Anwendbarkeit der Technologie zu ĂŒberprĂŒfen und manchmal sogar nur Google zu zerstreuen und zu rauchen .
Nach meinen Beobachtungen ist es möglich, die Genauigkeit der Bewertung zu erhöhen, indem zunÀchst die Meinung weniger erfahrener Entwickler eingeholt wird. So lernen sie, Aufgaben selbst schneller zu bewerten. Wenn sich bereits ein seriöser Ingenieur ausgesprochen hat, stimmen alle anderen seiner Meinung zu. Und wenn die Arbeit an dem Projekt beginnt, werden die Aufgaben höchstwahrscheinlich nicht von ihm gelöst, sondern von denen, die nichts gesagt haben. Wir werden ihre EinschÀtzung immer noch hören, aber nicht zum richtigen Zeitpunkt.
Wenn alle Aufgaben ausgewertet sind, fassen wir die Ergebnisse zusammen und fĂŒgen der Debugging-Software 30% und den Softwaretests weitere 30% hinzu. Diese Zahlen stammen aus Statistiken ĂŒber abgeschlossene Projekte.
Infolgedessen erscheint das folgende Bild auf der Tafel:



Die Bewertung wird normalerweise von einer eingehenden Diskussion der Details begleitet, da es viele Möglichkeiten zur Lösung des Problems geben kann. Es dauert also nicht weniger als eine Stunde. Angesichts der Vorbereitungszeit kann selbst eine vorlĂ€ufige Bewertung des Projekts 5 bis 20 Stunden fĂŒhrender Entwickler kosten.

Wir alle wollen erfolgreiche Produkte herstellen, Elektronik, die den Menschen zugute kommt. Wir diskutieren, wie die Ergebnisse der Bewertung (ZeitplĂ€ne, Ressourcen) mit den Zielen des gesamten Projekts ĂŒbereinstimmen. Es kann sich lohnen, dem Kunden andere Möglichkeiten anzubieten. Zum Beispiel, um die FunktionalitĂ€t fĂŒr MVP zu reduzieren oder teurere Hardware zugunsten einer gĂŒnstigeren Entwicklung zu verwenden. Es ist nĂŒtzlich, die Gesamtwirtschaftlichkeit des Projekts fĂŒr nachfolgende Phasen grob zu berechnen: Produktion, Produktion, Support. Diese Zahlen zeigen das relative Gewicht von Ressourcen und Zeit fĂŒr die Phasen des Projekts und können ihre Wahrnehmung (sowohl unsere als auch die des Kunden) erheblich verĂ€ndern.

Die vom Wang Club erhaltenen Bewertungen werden in Redmine eingegeben. EasyWBS eignet sich zum schnellen HinzufĂŒgen von Aufgaben in visueller Form:




Um den Zeitpunkt der Entwicklung zu bestimmen, bauen wir Eisenaufgaben in Ketten (Wasserfall). Wir bekommen diesen Gantt: FĂŒr Software teilen wir die ArbeitsintensitĂ€t in die ProduktivitĂ€t der Anzahl der Personen, die gleichzeitig an dem Projekt beteiligt sein können. Wie Sie wissen, tun zwei Programmierer in zwei Monaten, was ein Programmierer in einem Monat tut. Daher sollten Sie bei der Berechnung nicht alle Ihre Personalressourcen berĂŒcksichtigen. Auch können nicht in jedem Projekt Programmierer von Anfang an mit der Arbeit beginnen. Es kommt vor, dass Sie auf Eisen warten mĂŒssen, das Sie selbst gekauft haben. Die gleiche Verzögerung kann an der Verbindung von Stufen und Revisionen von Eisen auftreten. Um den Kunden zu informieren, können die empfangenen Daten nicht genommen werden. Es sei denn mit dem PrĂ€fix "optimistische Prognose". Es ist besser, einen kleinen Spielraum zu geben. Er wird sich als nĂŒtzlich erweisen.






Im Berechnungsmodul werden Tarife fĂŒr Spezialisten und Kosten fĂŒr Mitunternehmer, Produktion, Materialien, GerĂ€te usw. hinzugefĂŒgt. Ein exzellentes kommerzielles Angebot fĂŒr den Kunden.pdf erstellen wir direkt von hier aus. Lesen Sie am Beispiel einer einzelnen Anfrage, wie unsere Kollegen Projekte unterschiedlich bewerten. Kleine Analyse von zwölf KP . So wird das Projekt angenommen, bewertet. Es bleibt, den Vertrag zu unterzeichnen - und fortzufahren, Aufgaben neu zu schreiben, technische Lösungen zu Ă€ndern, Anforderungen zu erweitern und das Projekt bis zur Unkenntlichkeit zu Ă€ndern!









FĂŒr uns steht außer Frage, ob Projekte bewertet werden sollen oder nicht, da wir Projekte fĂŒr Kunden durchfĂŒhren, funktioniert es nicht, einen Vertrag ohne Bewertung zu erhalten. Bei internen Projekten in Unternehmen ist die Situation jedoch anders. Oft werden interne Projekte nicht bewertet. Und sehr vergebens. Die Konsequenz dieses Ansatzes ist die UnterschĂ€tzung von Zeit und Ressourcen. Weder das Team noch das Management können den aktuellen Projektfortschritt bewerten. Daher das MissverstĂ€ndnis und die Demoralisierung des Teams.

Und jetzt - lassen Sie uns in den Kommentaren Ihre AnsÀtze zur Projektevaluierung diskutieren!

More articles:


All Articles