Heute werde ich darüber sprechen, wie IT-Beratung am Beispiel von Big Data funktioniert, meine persönlichen Erfahrungen teilen, wie ich in diesen Bereich gekommen bin, und Fallstudien sowie Ratschläge geben, wer und warum Sie sich in der Beratung versuchen sollten.
Ich habe die Abteilung Mechanik und Mechanik von VN absolviert Karazina stieg in die DataArt-Position des Java Trainee ein und arbeitete dort die nächsten 6 Jahre. Meine Karriere entwickelte sich schnell aufgrund der Tatsache, dass die Liebe zusammenkam, um komplexe Rätsel zu lösen, mein angeborener Wunsch zu lernen, ständig etwas Neues für mich und ein Team von Mega-Profis zu finden. Einmal fühlte ich mich zu einem internen IoT-Projekt hingezogen, bei dem wir zusammen mit anderen Enthusiasten herausfanden, wie Sensoren an einen Mikrocontroller angeschlossen werden, wo diese riesigen Datenmengen gespeichert werden (und vor allem ist dies erforderlich?), Wie sie später verarbeitet und in Echtzeit verfolgt werden Zustand des Systems, Vorhersage von Ausfällen, wo und wie alles gehostet werden soll usw. So kamen wir schnell zu den Fragen und Aufgaben von BigData.
Dies gab meiner Entwicklung einen starken Impuls und ermöglichte es mir, in mehr als 15 IoT- und BigData-Projekten zu arbeiten, regelmäßig am Vorverkauf teilzunehmen, auf Konferenzen und mit Bildungskursen zu sprechen. Meine Position in dieser Zeit hat sich von Senior Developer zu Big Data Architect geändert. Anfangs war es interessant, aber im Laufe der Zeit wurde es für mich zur Routine. In den meisten Fällen ging ich zum Projekt, die ersten ein oder zwei Monate waren sehr aktiv, ich etablierte Prozesse, die Kommunikation mit dem Kunden und dachte über die Architektur nach, und danach wurde ich einer in diesen. Blei, PM, Business Analyst und viele andere)) Nach sechs Monaten wurde alles zu einem endlosen Murmeltier-Tag.
Auf der Suche nach neuen Erfahrungen und Herausforderungen bin ich daher zu SoftServe gewechselt. Nach fast einem Jahr kann ich meine Erfahrungen und Visionen darüber teilen, wie hier alles funktioniert.
Schauen wir uns zunächst an, wie der Beratungsprozess funktioniert. In der Tat sind die meisten IT-Mitarbeiter an dem Projekt beteiligt, wenn bereits ein Vertrag, ein Budget und ein Manager vorhanden sind und relativ klar ist, was, wann und mit welchem Team Sie tun müssen. Nur wenige Menschen fragen sich, wie im Prinzip neue Projekte in das Unternehmen gelangen und was in der Anfangsphase damit passiert.
Tatsächlich können im Leben eines jeden Projekts die folgenden Phasen unterschieden werden:
- Vorverkauf
- Entdeckung
- PoC / MVP
- Implementierung
- Unterstützung
Entdeckungsphase - genau für diese Beratung sind wir alle hier. Sobald der Vertrag unterschrieben ist, geht jemand aus der Beratungsgruppe zum Kunden. Idealerweise schließt sich ihm ein Business Analyst mit einem UX-Designer an (ich rate Methodikinteressierten, sich über den Design Thinking-Ansatz zu informieren, dessen Wirksamkeit ich in meiner eigenen Praxis bereits mehr als einmal erlebt habe). In einem idealen Ideal geht auch ein Engagement Manager, der sich um alle Fragen der Organisation des Prozesses kümmert, und ein Spezialist mit engem Profil.
- Vor Ort - in der realen Kommunikation mit dem Kunden sammeln wir so viele Informationen wie möglich.
- Offsite - zusammen mit dem Team analysieren wir alles, was wir ausgraben konnten, entwerfen das System, schreiben die Risiken und den Implementierungsplan vor.
Bei der Ausgabe stellt diese Gruppe dem Client ein Dokument zur Verfügung, das Folgendes enthält:
- Allgemeine Beschreibung des aktuellen Status des Systems;
- Szenarien für die Verwendung eines zukünftigen Produkts;
- Priorisierte Architektur- und Geschäftstreiber;
- Anforderungen an Datenvolumen, Verarbeitungsgeschwindigkeit, zulässige Verzögerung;
- Eine architektonische Vision, die alle bisherigen Anforderungen widerspiegelt;
- Der ausgewählte Technologie-Stack (dessen Auswahl auf einer Kompromissanalyse möglicher Implementierungsoptionen im Kontext der Systemanforderungen basiert);
- Schätzung und Rückstand (Aufgabenliste) für die nächste Vase, Entwicklungsplan;
- Risiken und mögliche Wege, um sie zu vermeiden.
Wenn alles gut geht und der Kunde die nächste Phase unterschreibt, arbeitet der Architekt seit einiger Zeit (meistens in Teilzeit) an diesem Projekt. Bis der Prozess etabliert ist, ist der Arbeitsumfang klar und der Kunde zufrieden. Wenn alle hier glücklich sind und die Zusammenarbeit fortsetzen möchten, folgen Proof of Concept (PoC), Minimum Viable Product (MVP) und weitere Implementierung und Support.
Es scheint, dass dieser gesamte Prozess klar, strukturiert und verständlich ist. In der Praxis ist jedoch nicht alles so einfach. Schauen wir uns mögliche Szenarien an.
Hier kommt ein potentieller Kunde zu uns. Das Verkaufsteam führt die ersten Anrufe / Kundgebungen durch, um zu verstehen, welche Art von Problem gelöst werden muss, und wendet sich an engere Spezialisten. Wenn das Projekt Kenntnisse über den Big Data-Stack erfordert, kommt der potenzielle Kunde zu meiner Gruppe.
Der nächste Schritt besteht darin, den Schwierigkeitsgrad der Aufgabe zu verstehen und festzustellen, welche Experten benötigt werden. Es gibt mehrere Möglichkeiten.
Der Kunde weiß überhaupt nicht, was er will
Meistens geschieht dies bei großen und erwachsenen Unternehmen, die verstehen, dass sie Geld verlieren, aber nicht verstehen, warum. Oder sie verstehen, haben aber keine Ahnung, wie sie das beheben können.
Aus eigener Erfahrung kann ich sagen, dass Sie in einer solchen Situation häufig erst geschäftliche Probleme lösen müssen und erst dann die Technologie. Sie müssen darauf vorbereitet sein, dass es nicht einfach ist und möglicherweise Interessenten auftauchen, die versuchen, Sie in ihre politischen Spiele einzubeziehen.
Zum Beispiel führte mich einer der CTOs, mit denen ich glücklicherweise vertraut war, einmal zu einer strategischen Kundgebung, um den Kauf einer Lizenz für ein beliebtes Produkt zu besprechen. Der offizielle Grund für mein Erscheinen war nur eine Bekanntschaft. Der Verwaltungsrat freute sich über den bevorstehenden Deal und lobte seine zukünftigen Partner. Als ehrliche und nachdenkliche Person stellte ich ein paar inhaltlichere Fragen, wie sie sich integrieren werden. Es gab keine Antwort, aber der Deal wurde abgesagt. Ich verließ den Besprechungsraum und fragte den CTO, ob ich mit meinen Fragen zu weit gegangen sei und ob ich in alles hätte einsteigen sollen. Darauf antwortete der "geheime Kardinal": "Alles ist super, ich habe dich dafür dorthin gebracht."
Wie vermeide ich das? Nein, das ist Beratung. Darauf muss man vorbereitet sein, bei dem mir natürlich persönliche Kenntnisse der Psychologie, erfahrenere Kollegen und persönliche Erfahrungen helfen.
Der Kunde hat eine Vision vom Endprodukt, benötigt jedoch unser Fachwissen, um sicherzustellen, dass er Recht hat.
In Bezug auf die Zeitkosten wahrscheinlich die rentabelste Option. Es wird viel weniger Aufwand betrieben, um ein Problem zu finden. Die Kommunikation mit einem Kunden ist viel produktiver, wofür Ihre Meinung immer noch maßgeblich ist.
Es gibt jedoch Fallstricke. Für einen unserer Kunden im Discovery-Finanzsektor war die Phase für 4 Wochen, 2 Wochen für Onsite und Offsite ausgelegt. Der Kunde sagte 2 Wochen vor Ort kein Wort, dass er bereits seine eigene Vision von Architektur hat. Es gab eine Diskussion über einige konzeptionelle Dinge, aber es gab nie ein Gespräch über einen Technologie-Stack. Und in der Mitte der 4. Projektwoche, als wir bereits eine Tonne Material angesammelt, gesammelt, priorisiert und die Hauptanforderungen in der endgültigen Lösung reflektiert hatten, beginnt der Kunde während der Präsentation der Architektur zu ärgern und zu sagen, dass wir ihn nicht gehört haben. Es stellte sich heraus, dass unsere Aufgabe nicht darin bestand, etwas Neues zu erfinden, sondern zu erraten, was sich bereits im Kopf unseres Hauptakteurs befand. Vielen Dank an meinen großen Chef, der bei diesem Anruf war und schnell herausgefunden hat, in welche Richtung der Wind wehte. Ein paar Schlüsselwörter und der Kunde sind wieder zufrieden, und für die verbleibenden Tage ändern wir das Konzept vollständig, reflektieren alle Anforderungen und Risiken, aber bereits in der mit dem Kunden vereinbarten Architektur.
Wie vermeide ich das? Validieren, validieren und validieren Sie Ihre Entscheidungen erneut beim Kunden. Je früher und öfter, desto besser. Es ist besser, mehrmals in Teilen zu sagen, was alle bereits verstanden haben, als 4 Wochen später zum ersten Mal, um die endgültige Architektur zu zeigen. Dies betrifft nicht nur die Architektur, sondern auch die Herangehensweise an Discovery als Ganzes.
Der Kunde hat eine sehr genaue und detaillierte Vision des Produkts, von Ihnen benötigt er nur die Ausführung
Einerseits ist es bequem. Keine Notwendigkeit, die Anforderungen herauszufinden, mit der Dokumentation herumzuspielen, am Ende zum Kunden zu gehen. Nehmen und tun. Aber oft funktioniert es nicht so. Schon in den ersten Tagen wird deutlich, dass die Vision des Kunden alles andere als ideal ist, da bei weitem nicht alle Risiken und Anforderungen berücksichtigt wurden, Schätzungen deutlich unterschätzt werden und es äußerst schwierig ist, diese Idee zu vermitteln, da der Kunde fest von seiner Entscheidung überzeugt ist.
Wie soll man sich in dieser Situation verhalten? Meiner Meinung nach sollten Sie zunächst die Rentabilität des Projekts in Bezug auf die Ressourcen des Teams bewerten, die Sie dafür ausgeben müssen. Schließlich bringen solche Projekte nicht immer viel Gewinn, und Sie müssen viel Energie dafür aufwenden. Wenn wir uns für diesen Kommentar entscheiden, versuche ich, dem Kunden die Idee zu vermitteln, dass wir als erfahrene Berater, die viele Projekte umgesetzt haben, versuchen, unsere Erfahrung zu nutzen, um die rationalste Lösung für sein Problem zu finden, und die vorgeschlagene Idee nicht nur blind umzusetzen. Ich informiere auch darüber, dass der obligatorische Teil unserer Arbeit darin besteht, ihn vor allen möglichen Risiken zu warnen und gegebenenfalls Empfehlungen zu geben, wie diese vermieden werden können. Das heißt, Sie müssen Glaubwürdigkeit verdienen und sicherstellen, dass der Kunde beginnt, Ihnen zuzuhören.
Sie müssen immer in der Lage sein, sowohl dem Kunden als auch den Projektkollegen zuzuhören und sie zu hören. Schließlich sind die Herausforderungen, denen wir gegenüberstehen, oft nicht technischer Natur.
Zusammenfassend kann ich sagen, dass Beratung für diejenigen ist, die nicht still sitzen und keine Angst haben, etwas Neues auszuprobieren. Wenn Sie seit mehr als einem Jahr an demselben Projekt arbeiten, hat Sie die Arbeit gelangweilt, aber die Angst, etwas zu ändern, verfolgt Sie - versuchen Sie, etwas mehr Verantwortung zu übernehmen. Bezahlen Sie für einen Ausbildungskurs, überlegen Sie sich und bieten Sie dem Kunden Optimierung an, vermitteln Sie ihm seinen Wert, verkaufen Sie ihn. Schnappen Sie sich etwas Neues und verlassen Sie Ihre Komfortzone. Denken Sie daran, dass es keine schlechten Erfahrungen gibt und selbst ein Misserfolg eine Lektion bringt, was bedeutet, dass wir besser werden. Wenn das Experiment erfolgreich ist, verschwindet die Angst und Sie sind voller Stolz und dem Wunsch, weiterzumachen, noch besser und mehr zu tun. In diesem Moment können Sie sicher zu uns kommen!