Wie man mit der Angst vor dem Custom Dev umgehen kann [geschlossen]

8

Ich beschäftige mich mit einem Problem mit meinem derzeitigen Arbeitgeber, das mich ernsthaft dazu bewogen hat, anderswo eine Beschäftigung zu suchen. Sie haben den Eindruck, dass 100% der benutzerdefinierten Entwicklung eliminiert und durch COTS-Produkte wie SharePoint ersetzt werden sollte. Während ich realisiere, dass dies keine realistische Erwartung ist, habe ich es unmöglich gefunden, meine Argumente mit den Leuten im Management zu diskutieren, die diese Ansichten teilen. Ihr Argument beinhaltet normalerweise etwas in der Art eines bereits in SharePoint vorhandenen Features, das Feature X abdeckt, daher ist das Risiko geringer und Tests müssen nicht dagegen unternommen werden.

In diesem Fall haben wir eine Situation, in der eine SharePoint-Liste vollständig unfähig ist, die Erwartungen und Anforderungen der Kunden zu erfüllen. Das Speichern dieser Daten in einer SQL-Datenbank würde jedoch die Anforderungen problemlos erfüllen. Jedes Mal, wenn unser Entwicklungsteam vorschlägt, die Grenzen von SharePoint zu überschreiten, geht das Management jedoch in Flammen auf, wie jede Codezeile zur Komplexität des Projekts beiträgt und das Risiko erhöht. Während dies in einigen Situationen sicherlich richtig ist, ist dies nicht immer der Fall. Ihr Argument ist jedoch, dass seit SharePoint einen Mechanismus zum Speichern von Daten bietet, dass wir es zu 100% nutzen sollten. Unabhängig davon, ob es den Kundenanforderungen entspricht oder nicht.

Ich bin an den Punkt gekommen, dass ich es hasse, zur Arbeit zu kommen, weil ich ständig gezwungen bin, Dinge zu tun, von denen ich weiß (mit 100% iger Sicherheit), dass sie nicht richtig sind und durch kundenspezifische Entwicklung richtig gemacht werden können. Es ist einfach, was scheint, ein unmögliches Argument zu sein, wo ich jedoch arbeite.

Hat jemand von euch eine ähnliche Situation erlebt? Wenn ja, was haben Sie getan, um diese Herausforderungen zu bewältigen?

    
senfo 03.12.2008, 21:23
quelle

12 Antworten

15

Wenn Sie die Vision des Unternehmens nicht teilen und wenn Sie sie nicht aufklären können, dann ist es ein guter Zeitpunkt, um mit der Suche zu beginnen.

Haben Sie darauf hingewiesen, dass es ein Risiko gibt, eine "Lösung" auf einem Client zu erzwingen, die ihnen nicht hilft oder deren Funktionalität fehlt oder die unbrauchbar ist?

Vielleicht mit Plänen, um ihre wahrgenommenen Risiken anzugehen und zu mildern.

    
Tim 03.12.2008, 21:29
quelle
9

Du dokumentierst deine Sorgen und lässt sie über dich wissen, und dann tust du, was sie fragen. Wenn es nicht funktioniert, haben Sie eine Dokumentation, in der Sie die Bedenken aufgeworfen haben. Aber versuchen Sie es so zu machen, dass es funktioniert. Es sieht also nicht so aus, als wollten Sie ihre Pläne untergraben. Sie gehen das größere Risiko ein und bekommen dadurch die größere Verantwortung. Versuchen Sie Ihr Bestes, damit es auf ihre Weise funktioniert und hören Sie auf, sich darum zu sorgen.

    
thursdaysgeek 03.12.2008 21:32
quelle
6

Das hört sich vielleicht schlecht an und ist möglicherweise nicht die gewünschte Antwort. Es gibt eine wenig bekannte Abteilung in meinem Büro namens "The Skunk Works". Die Leute entscheiden sich auf eigene Faust (in der Regel während der Mittagspause oder der Kompilierzeit), kleine Programme zu schreiben, die dem Unternehmen helfen. Der Spaß daran ist das Ergebnis, das dem Unternehmen nichts "kostet".

Die Konversation läuft normalerweise so:

"Wir müssen diese Software kaufen" -Boss

"Aber wir hatten dieses Ding seit Monaten. John, schrieb das damals" -Programmer

"?" -Boss

Oft sehen die Entwickler eine Entscheidung als schlecht und erstellen einfach einen parallelen Prozess, der automatisch abläuft. Dann, wenn das Zeug den Fan trifft und die Kunden frustriert sind, ist die alternative Lösung bereits vorhanden.

Ich habe ein Beispiel für eine automatische Release-Maschine. Entwickler haben diese benutzerdefinierten Berichte erstellt. Als unsere Kunden stiegen, nahm die Arbeitsbelastung der Entwickler zu. Das Problem war: "Damit der Kunde den benutzerdefinierten Report-Entwickler bekommen konnte, musste er involviert sein." Also, während das Unternehmen suchte, jemanden einzustellen, um Berichte in Vollzeit zu machen oder Wege zu finden, die Kunden tun zu lassen, schrieb ich eine automatische Freigabemaschine, die nach Berichtsänderungen sucht und sie direkt an den Kunden freigibt. Ich habe auch ein Dienstprogramm geschrieben, mit dem jeder Änderungen an den Berichten vornehmen kann, die einfacher zu verwenden sind als der Entwickler. Als der Chef die Ankündigung machte, dass er versuchte, eine Lösung zu finden, sagte ich ihm, dass es bereits vorhanden sei und dass sogar er Änderungen an Berichten vornehmen und sie veröffentlichen könnte. Jetzt kann jeder die Berichte ändern, normalerweise sind es Management und Kundensupport, die diese Änderungen vornehmen. Die lustige Seite ist, dass Entwickler nicht mehr involviert sind.

Mach es einfach. Wenn Sie sowieso aufhören möchten, könnte es auch versuchen.

    
Jeremiah 03.12.2008 21:37
quelle
3

Verfügt jemand im Management über einen Bestand in SharePoint? Wurde das System vom jüngeren Bruder des CEO entwickelt?

Wenn sie so widerstandsfähig sind, sich zu verändern, sollten Sie den wahren Grund herausfinden, bevor Sie versuchen, mit ihnen zu argumentieren. Sie können behaupten, dass es zusätzliche Komplexität, Schwierigkeitstests usw. gibt, aber wenn Sie jedem Argument mit einem Argument entgegentreten können, das ihre Position bei allem Respekt zeigt, falsch informiert werden und sie immer noch nicht diskutieren, dann können Sie streiten der falsche Punkt.

Wenn sie aus einem nicht-technischen Grund in die Technologie eingeschlossen sind, wie jemand, der einmal gelesen hat, dass SharePoint das ultimative in jeder technischen Situation ist (und natürlich keine Ahnung hatte, worüber der Artikel andere als SharePoint redete) = gut) dann solltest du nicht versuchen zu streiten und deine Energie zu sparen. Für die Jobsuche.

    
Elie 03.12.2008 21:31
quelle
3

Beweise es ihnen. Wenn die Anforderungen eine Liste erfordern, die 100.000 Elemente mit einer mehrspaltigen Sortierung verarbeiten kann, schreiben Sie ein Skript, das 100.000 Testelemente in eine Sharepoint-Liste einfügt, und lassen Sie es versuchen, vorzugsweise mit dem "Kunden", der die Liste anfordert. : -)

    
Ron Savage 03.12.2008 21:32
quelle
2

Ich würde auf jeden Fall meinen Lebenslauf herausbringen und ins Freie, wenn ich du wäre. Nicht nur die Erfahrung, die Sie derzeit frustrieren, kann Ihre Karriereentwicklung auf lange Sicht wirklich beeinträchtigen. Denk nur darüber nach. Während Sie in Ihrer derzeitigen Position mit Ihrem aktuellen Arbeitgeber schmachten, übernehmen andere Entwickler neue Technologien und erweitern ihre Erfahrung.

Es gibt so etwas wie ideologische Unterschiede zwischen den Entwicklern und was die Idee eines Unternehmens für eine Rolle für einen Entwickler ist. Wenn offene Diskussion und Offenheit Sie nirgendwohin bringen, werden Sie nicht wegen mangelnder Anstrengung beschuldigt. Loyalität gegenüber einem Unternehmen ist eine gute Sache, aber die Beziehung muss eine Zwei-Wege-Straße sein.

Leider wird der Wille wahrscheinlich irgendwann erkennen, dass sie in ihren Annahmen falsch liegen - aber Sie können nicht auf diesen Tag warten. Manchmal kommt es nie. Insbesondere (und versteh mich nicht falsch, ich liebe SharePoint, wenn es für das verwendet wird, wofür es bestimmt ist), SharePoint ist der nächste Access geworden, in dem Leute, die Management Magazine lesen, genug davon herumgeworfen sehen, um es zu nennen Messias.

    
Joseph Ferris 03.12.2008 21:35
quelle
2

Ich finde, dass es in der Regel keine Möglichkeit gibt, diese Debatten durch Reden allein zu gewinnen. Viele Manager bilden eine Meinung über ein Produkt oder eine Lösung durch das Lesen von Management-orientierten Artikeln. Sehen Sie, ob Sie einige Gegenartikel finden können.

Wenn Sie Beispiele für Dinge nennen können, zu denen SharePoint nicht in der Lage ist, und Beispiele dafür zeigen, wie Sie diese Probleme mit effektiv lösen können, dann sind Sie auf einem guten Weg.

>

Der Fehler ist zu versuchen, dies zu einem Gespräch über Technologie zu machen, es geht nicht um Effizienz, Kosteneffektivität und Wartbarkeit - das sind die Mantren und Metriken, die nichttechnische Manager dazu bringen, Alternativen in Betracht zu ziehen.

Wenn Sie einen Proof-of-Concept für einige dieser Punkte umso besser zusammenstellen können, hilft Eye Candy wirklich, außerhalb von technischen Teams zu verkaufen.

Endlich, viel Glück:)

    
ahin4114 05.12.2008 13:45
quelle
1

Ich mache dasselbe bei meinem jetzigen Job, es gibt keinen einfachen Weg, mit dieser Art von Situation umzugehen. Alles, was ich tun konnte, ist, meine Argumente zu schlucken, weil sie mich nirgendwohin gebracht haben und tun, wie es mein Management verlangt. Das wird natürlich dem grundsätzlichen Programmierercharakter, die beste Lösung für die jeweilige Aufgabe zu verwenden, nicht gerecht und vielleicht kann man dabei etwas Cooles bauen, aber da sie der Boss sind, ist es wirklich Ihre einzige Lösung. Sie könnten versuchen, Fälle mit Beweisen anzuordnen, bei denen es sinnvoller ist, benutzerdefinierte Lösungen zu verwenden. Aber wenn dein Chef so wie ich ist, wird es nicht weit kommen, bis das schreiende Match beginnt. Die einzige andere Lösung besteht darin, den Lebenslauf abzuwischen und einen neuen Job zu finden.

    
Jeremy Reagan 03.12.2008 21:30
quelle
1

Ich hatte vom ersten Tag an die gleichen Herausforderungen. Das Management hat eine natürliche Abneigung, der Lösung benutzerdefinierten Code hinzuzufügen. In den meisten Fällen war es jedoch möglich zu erklären, dass die richtige Lösung für den Kunden einen benutzerdefinierten Code enthalten würde.

Denken Sie daran, wenn Sie argumentieren, dass Sie den benutzerdefinierten Code in die allgemeine Codebasis einfügen können, dann könnte der Chef die Idee gutheißen.

    
Kasper 03.12.2008 21:34
quelle
1

Ich fühle wirklich deinen Schmerz.

Wenn ich es wäre, würde ich meine Freizeit nutzen, um Informationen zu sammeln, die meinen Standpunkt belegen und auf leicht verständliche Weise dokumentieren.

Wenn sie nur Geld verstehen, Geld reden, wenn sie nur Angst verstehen (indem sie "dies" tun, weil sie Angst vor "dem" haben), nutzen sie die Angst und finden sie in "ihrer" Lösung beängstigend.

>

Dokumentieren Sie jede neue Implementierung, die Zeit, das Geld und das Problem, das entsteht. Und dokumentieren Sie stattdessen, was Ihre Lösung wäre.

Sie sehen das Problem wahrscheinlich nicht in ihrer Lösung, weil sie sich darauf konzentrieren, keine Probleme in "Ihrer" Lösung zu haben.

    
Stefan 03.12.2008 21:36
quelle
1

Ich habe an einem Ort gearbeitet, an dem das Management nicht konstruktiv war, nicht ganz so schlecht wie beschrieben, aber schlimm genug.

Es gibt ein paar Optionen. Eine ist, voranzukommen und zu tun, was für den Kunden mit der besten "Preis-Leistungs-Option" getan werden muss. Sie werden wahrscheinlich die Entwickler als Team zusammenbringen müssen, um diesen "zivilen Ungehorsam" zum Funktionieren zu bringen.

Ein energischerer Ansatz, der die Scheiße wirklich zum Fan werden lässt, ist, zum Kunden zu gehen (tue dies nicht, wenn es ein externer Klient ist oder wenn du deinen Job behalten willst) und layoute was passiert passiert mit diesem Projekt, wenn X und Y. Dies ist ziemlich viel erzählt Geschichten außerhalb der Schule und wird schlecht sein, aber unterhaltsam.

Ein etwas besserer Weg ist es, die Kette hochzugehen und einen Sponsor zu finden, der Scheiße für dich passieren lässt. Gehen Sie im Wesentlichen hinter Ihrem Chef zurück. Das mag funktionieren, aber es wird vorhersagbare Ergebnisse für Ihre Beziehung mit Ihrem Management haben.

Zuletzt und am schwierigsten ist es, die Person, die die Ansicht vertritt, dass ein benutzerdefinierter Code schlecht ist, zu identifizieren und sie in eine Konversation einzubeziehen, um herauszufinden, wo sie den Glauben haben, und dem mit Beispielen entgegenzuwirken. Betonung der Konversation, da Sie die zugrundeliegenden Bedenken (die nicht auf benutzerspezifischen Code an sich gerichtet sind) hören und verstehen müssen und diese nur ansprechen, nachdem Sie diese Personen gewonnen haben.

Ich kann Ihnen nicht sagen, welcher Weg am besten funktioniert, weil es so sehr auf die beteiligten Personen ankommt. Alles, was ich weiß, ist, dass du die Leute nicht verändern kannst und nach meiner Erfahrung war der beste Weg, das Problem bisher zu lösen, mit Leuten wegzugehen und zu arbeiten, die nicht so sind ...

    
Nat 03.12.2008 23:24
quelle
0

Wie wäre es mit einem benutzerdefinierten Code? Wenn Sie es stattdessen "vorweggenommene SharePoint-Benutzererweiterungen" nennen, kann dies das Missverständnis, das einen bestimmten Begriff umgibt, mildern.

Auch, wie bereits gesagt wurde, könnte es andere Gründe für Sie geben, warum das Management diese Agenda vorantreibt. Es ist wahrscheinlich am besten, diese nicht zu schnell zu schätzen, da viele davon gültig wären.

Schließlich gibt es viele Orte, die Entwicklung brauchen. Es tut nicht weh, nach einer besseren Übereinstimmung zu suchen.

viel Glück.

    
Randy 25.06.2010 17:38
quelle

Tags und Links