Als sie Sie eingestellt haben, haben sie wahrscheinlich einige Beispiele Ihrer vorherigen Projekte überprüft. Sie sollten kein Verfechter einiger spezifischer Technologien sein. Sie sollen ein Experte sein, der seinen eigenen Hintergrund einbringen und zur Innovation Ihrer Unternehmensprojekte beitragen kann. Die Vielfalt der Technologiekultur ist bereichernd.

Aus dieser Sicht sprechen Sie sich nicht für eine bestimmte Technik (sagen wir Layout) aus, nur weil sie Ihr vertrauter Grund ist. Sie sind in UX, also kennen Sie den Deal: "Kennen Sie zuerst Ihren Benutzer. Und dann Design dafür." Verwenden Sie Metriken, Usability-Beispiele, vergleichen Sie sie mit der Konkurrenz usw. Sie haben sich nicht überverkauft, sondern sind nur ein weiterer Gesichtspunkt für das globale Know-how Ihres Teams. Manchmal ist Ihre Lösung die beste, manchmal nicht. In den meisten Fällen setzt sich die Lösung aus allen Erkenntnissen zusammen und erreicht schließlich einen "ausgereiften" Zustand.

Mein Rat lautet: Konzentrieren Sie sich nicht auf Ihre Unterschiede (Sie wurden nicht über Nacht zum schlechtesten Designer, und das waren sie auch nicht Sie täuschen sich über Ihr Fachwissen), konzentrieren sich auf die endgültigen Ziele. Sie haben einen Zielbenutzer, also entwerfen Sie dafür.

Keine Erfahrung ist irrelevant. Es scheint jedoch, dass Ihr Ansatz nicht zu Unternehmen und Team passt.

Lernen Sie die Seile, lernen Sie ihre Methodik und bewegen Sie sich vorwärts. Ihre Erkenntnisse, die sich Problemen aus einem anderen Blickwinkel nähern, werden sich als nützlich erweisen und Ihnen später Respekt einbringen.

Als Ingenieur muss ich mich mit sehr unterschiedlichen Netzwerken auseinandersetzen, die auf unterschiedliche Weise aufgebaut sind, auch wenn dies im Kern der Fall ist Sie alle machen das Gleiche. Der wichtigste Faktor ist das Lernen und Arbeiten mit dem, was vorhanden ist, bevor Änderungen vorgenommen werden.

Lernen.

Bei allen neuen Positionen lernen Sie etwas, aber was Sie in der Vergangenheit gelernt haben, verschwindet nicht oder wird irrelevant. Ich kenne jetzt einige Sprachen und alle arbeiten in meinem Kopf zusammen, um mich flexibler zu machen. Ich benutze COBOL nicht mehr (wer tut das?!), Aber einige der Dinge, die ich aus meinen COBOL-Codierungstagen gelernt habe, sind geblieben. Das Gleiche gilt für C ++ / C #, obwohl ich jetzt in VB.NET arbeite.

Wenn es um eine neue Vorgehensweise geht, vertrauen Sie mir, Sie werden jedes Mal etwas Neues haben, wenn Sie Jobs tauschen. Von Prozessen und Verfahren über Pflichten bis hin zu Codestandards. Das Unternehmen weiß, dass die Anpassung einige Zeit in Anspruch nimmt (hoffentlich) und wird dies berücksichtigen. Wenn Sie zurückfallen, indem Sie Ihren Weg weiter präsentieren und ihren Weg nicht einschlagen, können Sie Probleme haben. Sie können dies auf den Kopf stellen, indem Sie es einfach auf ihre Weise tun ... aber Ihr Fachwissen in einen Vermögenswert verwandeln. "Ich sehe, dass wir das tun, und ich habe es so gemacht, aber meiner Erfahrung nach habe ich gesehen, dass ein anderer Weg effizienter sein könnte." Die meisten Chefs hören sich alles an, was einen Prozess verbessert, auch wenn sie ihn nicht übernehmen, solange Sie es auf ihre Weise getan haben, bevor Sie Ihren Vorschlag machen.

"Hey, Chef, ich Ich habe dieses Projekt fertiggestellt. Während ich daran arbeitete, fand ich, dass wir es anders machen KÖNNTEN, was effizienter ist und weniger Wartung erfordert. "

Mach es auf ihre Weise, sag ihnen deinen Weg, lass sie Treffen Sie eine Entscheidung, was mehr in ihre Strategie passt.

Ich würde sagen, es ist tatsächlich ein Bonus für das gesamte Team. Groupthink führt immer nur zu Selbstzufriedenheit und Sie können garantieren, dass zumindest einige Ihrer Benutzer nicht so denken wie die Designer. Je mehr Personen Sie in das Design und die Entwicklung einbeziehen können, die einen anderen Denkprozess oder eine andere Perspektive haben, desto wahrscheinlicher ist es, dass das Endergebnis erfolgreich ist.

Wenn Sie einem neuen Team beitreten, werden Sie immer feststellen, dass die Dinge anders sind, als Sie es gewohnt sind, aber es ist eine Einbahnstraße - eine Gelegenheit für Sie, zu lernen, wie sie Dinge tun, und eine Gelegenheit für das Team um aus Ihren Erfahrungen mit dem "Äußeren" zu lernen.

Flexibilität, Lernen und Kompromisse sind sicherlich wichtig. Aber in der Softwareentwicklung finde ich, dass autodidaktische Freiberufler / Berater einen ganz anderen Ansatz verfolgen als "optimierte" direkte Entwicklungsteams *. Freiberufler wissen auch, dass sie, um bezahlt zu werden (dh ein Unternehmen Geld zu verdienen), das, was benötigt wird, so genau wie möglich liefern sollten, da nicht verwendete / abgelehnte Designs / Code unbezahlte Designs / Code sind.

Freiberufler und Berater konzentrieren sich auf das Geschäft Bedürfnisse und Kundenzufriedenheit neben der Entwicklung. Entwicklungsteams konzentrieren sich auf Geschwindigkeit (insbesondere heutzutage), Bereitstellung und Methoden. Die besten Unternehmen sollten natürlich ein ausgewogenes Verhältnis zwischen beiden haben.

Ein rationaler Ansatz wäre:

• Hilf ich oder störe ich die Teamarbeit?
• Was sind die Best Practices der Branche (Vorsicht vor ungerechtfertigten Bandwaggons)?
• Wie passen aktuelle Praktiken zu den Geschäftsanforderungen des Unternehmens und kommen diesen zugute?
• Sind aktuelle Praktiken für Kunden von Vorteil (oder?) Umsatz steigern)?
• Wie hoch sind die Toleranzniveaus für Änderungen innerhalb und außerhalb der Organisation?

TL; DR: Es gibt kein Richtig oder Falsch. Diskutieren und verhandeln Sie, wo Sie können. Wenn möglich lernen und anpassen. Aber Sie sollten Ihre Leidenschaft, Fähigkeiten oder Fertigkeiten nicht außer Acht lassen. Sie sind vielleicht sowieso für größere und bessere Dinge bestimmt, das kann man an Ihrer Fragestellung erkennen.

* Wenn ich darf, möchte ich auf diesen Punkt näher eingehen. Auf der Kundenseite ist es für jemanden sinnlos, dem Kunden die Welt zu versprechen und kein vernünftiges Verständnis dafür zu haben, wie dies erreicht werden kann. Sie sollten auch nicht die geschäftlichen Anforderungen und Anforderungen erfassen. Umgekehrt sollten Entwicklungsteams Code nicht zerschlagen und nur deswegen trendige Technologien verwenden. Ja, Entwicklungsteams sollten die Freiheit und Flexibilität haben, die von ihnen gewünschten Methoden zu nutzen, aber sie sollten (zweifellos ein überstrapaziertes Wort) auf die Kundenzufriedenheit sowie die externen und internen Geschäftsanforderungen abgestimmt sein. Wer weiß, vielleicht sind Sie auf der ganzen Linie die Person, die diese "Lücke" schließt, falls vorhanden;)