Wie gehen Sie mit Over-the-Head-APIs / -Technologie um?

11

Ich denke, die meisten Menschen waren in dieser Situation.

Die erste Projektplanung beginnt. Die Anforderungen sind umrissen. Nach Überprüfung der Architektur und Sortieren durch APIs / Frameworks wird die Anpassungstechnologie ausgewählt. Die Entwicklung beginnt.

Und dann geht es los. Sobald Sie einige vermeintlich einfache unterstützende Dinge tun müssen, schlägt das Framework / die API fehl und anstatt zu arbeiten, kämpfen Sie am Ende gegen die Technologie. Die Recherchezeit steigt sprunghaft, die Foren schweigen, nichts scheint getan zu werden, und selbst wenn Sie etwas zum Arbeiten bringen, sind Sie sich nicht sicher, ob es richtig gemacht wurde.

Wie gehen Sie in diesen Situationen um? Gehen Sie auf Hacks, recherchieren Sie weiter, was sagen Sie dem Management?

technology research

— Codierer
quelle

+1: Was für eine großartige Frage. Würdig +10. Ich habe die gleiche Erfahrung gemacht.

— Jim G.

Das ist eine gute Frage. So oft habe ich gesehen, wo Wörter wie "Hebel" und "Synergie" verwendet wurden, um Sachen von Drittanbietern zu verkaufen. Dann wirst du darin eingeschlossen und sie gehen und ziehen es unter dir hervor. (MS macht das gerne.) Inzwischen sind die ursprünglichen Evangelisten längst verschwunden.

— Mike Dunlavey

9

Prototyp, Prototyp, Prototyp !!

Wenn Ihr Team mit einem bestimmten Framework nicht vertraut ist, erstellen Sie einen Prototyp, um zu bewerten, wo die Schwachstellen liegen.

Matt Raible (Java Web Framework Comparator) schlägt vor, wenn möglich eine Woche lang mit einem Framework zu arbeiten.

Das Prototyping umfasst die Untersuchung der Community-Unterstützung hinter einem Framework und anderen Faktoren

— Martijn Verburg
quelle

+1 für Prototyp. Es ist ein unschätzbarer Meilenstein, wenn etwas tatsächlich funktioniert, selbst wenn es mit Klebeband zusammengesetzt und mit Stöcken abgestützt wird und abstürzt, wenn Sie es fünf Minuten lang in Ruhe lassen.

Wenn die anfängliche Projektplanung beginnt, wie in der Frage angegeben, bedeutet dies, dass der Startschuss für das Projekt bereits gegeben wurde und somit BEREITS an den Kunden verkauft wurde. Also ... wenn es kein "Prototyping" gibt und diese Kosten in Stunden in diesen PSP einbezogen werden, gibt es kein Prototpying. Idealerweise möchten Sie, dass dies bereits vor dem Verkauf der Lösung erfolgt. Also bevor ein oder mehrere Projekte herausrollen. So lange vor diesem Projekt möchten Sie "Prototyping" als Teil der benötigten Stunden und einige Evaluierung setzen. Dies ist für die meisten Kunden schwierig, da sie eine Lösung wünschen.

— Edelwasser

en dan willen ze ook nog de genaue Serverspezifikationen van te voren ....

— edelwater

6

Das Verwalten externer Abhängigkeiten ist der Fluch vieler IT-Projekte. Vor vielen Jahren haben die erfahrenen Programmierer, mit denen ich zusammengearbeitet habe, immer sichergestellt, dass sie die Kontrolle über ihre Abhängigkeiten haben - normalerweise indem sie darauf bestanden, dass Quellcodelizenzen gekauft wurden.

Persönlich war das nicht mein Ansatz. Ich neige dazu, unter dem Versprechen zu sein, über die Schule des Denkens zu liefern. Es gibt Zeiten, in denen ich meinen Hals herausstrecken musste, aber ich recherchiere vorher privat, um 99% sicher zu sein - normalerweise mache ich ein privates Projekt oft in meiner eigenen Zeit, um sicherzustellen, dass die Technologie liefern kann. In der Tat Prototyp, testen, validieren, dann versprechen.

Es gibt Situationen, in denen ich erwischt werde - und entweder zurückgehen oder erfinderisch sein muss. Ein kreativer Geist mit viel Erfahrung hilft hier, aber auch das Gespräch mit anderen Menschen. - und nicht immer Programmierer. Manchmal kommen die Lösungen von wirklich seltsamen Orten.

Der Schlüssel zum Umgang mit Management ist Ehrlichkeit. Sprechen Sie früh und oft. Überlassen Sie es nicht der letzten Minute, denn wenn Sie Manager / Kunden am Tag vor einer großen Lieferung im Stich lassen, sehen Sie einfach wie Amateure aus. 2 Monate vor Ablauf der Frist sagen zu können, dass die Manager zwischen dem Löschen einiger Funktionen und / oder dem Verzögern des Versands wählen müssen, ist zu diesem Zeitpunkt möglicherweise nicht beliebt, ermöglicht es jedoch dem Rest des Unternehmens, ihre Arbeit zu erledigen und zu planen . Der Schlüssel dazu ist ein gutes Aufgabenverwaltungssystem, das Zeiten und Aufgabenschätzungen verfolgt. Wenn Sie solide Beweise haben, um Ihre Sichtweise zu untermauern, ist es viel wahrscheinlicher, dass Sie angehört werden.

— Michael Shaw
quelle

Ich habe viele der gleichen Dinge getan, die Sie hier erwähnt haben, und es hat sehr gut für mich funktioniert. Nach meinem besten Wissen waren die Kunden, mit denen ich zusammengearbeitet habe, sehr zufrieden mit dem, was ich geliefert habe, weil ich im Allgemeinen die Erwartungen übertroffen habe, die sie hatten. Sie schätzten auch die Kommunikation darüber, wie sich die Dinge entwickelten und wann es Probleme gab, was sie waren und welche Auswirkungen sie hatten.

— Ken Henderson

2

"Wie schaffen Sie das in diesen Situationen?" Was ich gesehen / erlebt habe:

Der Punkt Nummer 1 Ich stimme Ptolemaios zu: Seien Sie ehrlich:

Wenn es wirklich ein Problem ist: Gehen Sie in diesen Raum, erzählen Sie das Problem, lehnen Sie sich zurück, um auf die Wutreaktion zu warten, und arbeiten Sie dann ... auf einen neuen Plan / eine neue Lösung hin. (Der Typ ist nicht böse auf dich persönlich).

Es gibt IT-Kurse, die sich nur mit dieser Situation befassen. Sie werden bei Schauspielern platziert und sie platzieren den verärgerten Kunden, der diese Nachricht hört. Sie bekommen viele Tipps dazu. Klingt dumm, aber wahrscheinlich merkt man erst danach den Wert. Ich ging mit einem Blatt mit 80 Punkten, an die ich mich in diesen Situationen erinnern sollte ... (und üben).

Diese Situation ist wahrscheinlich noch typischer, heute, wo die Budgets knapp sind, der Verkauf mit dem "niedrigsten Angebot" erfolgt und die von Ihnen angegebene Planung fünfmal gekürzt wird, bevor sie vom Kunden akzeptiert wird ... (einschließlich des Prototyps seit "der Einstellung" Sie, weil Sie der Experte sind und ansonsten 10 andere warten ") etc ...

- Eine andere Sache könnte das Querdenken sein: Wenn dies nicht auf diese Weise möglich ist, versuchen Sie, etwas völlig anderes vorzuschlagen, das dem Kunden den gleichen Wert bietet. Wenn die Technologie überhaupt nicht funktioniert / pleite ist / aus dem Geschäft herausspringt / etc ... Wenn der Kunde dies kauft, kann er am Ende den gleichen Wert liefern. Aber es zu bringen ist auch ziemlich schwer. (für einige und ganz und gar nicht für andere). Dafür braucht man die wirklich erfahrenen Leute. Eine ähnliche Situation ist, dass die Technologie NOCH NICHT in der Lage ist ... es dauert einige Monate ... Sie müssen den Kunden also davon überzeugen, die Neuplanung und die Auswirkungen auf seine Organisation neu zu planen und zu akzeptieren ...

- Eine weitere "Lektion gelernt" ist, die älteren Senioren anzurufen, sobald Sie bemerken, dass es in diese Richtung geht. Sie haben sich oft mit schwierigen Projekten befasst und sind in diesen Situationen wirklich hilfreich. Oft reisen sie nur von einem schwierigen Projekt zu einem schwierigen Projekt.

- Eine weitere Lektion besteht darin, Ihre architektonischen Inhalte Verifizierungskanäle durchlaufen zu lassen, insbesondere bei größeren Projekten. Eine Unterschrift kann deinen Arsch bedecken. (Speichern Sie alle Ihre E-Mails LOL)

— Edelwasser
quelle