Jobeinblicke mit den Salesforce-Entwicklern Katja und Michael

Was macht ein Salesforce Entwickler den ganzen Tag?

Katja: Konfigurieren und Programmieren –  aber nicht nur. Zuerst geht es einmal darum, die Anforderungen zu verstehen, die in Abstimmung mit unseren Kunden und dem Projektteam umzusetzen sind.

Michael: Pendeln. Und zwar zwischen den beiden Welten der deklarativen Entwicklung – also das, was man im System per Konfiguration hinbekommt –  und der tatsächlichen Programmierung. Je nach Projekt bewerten wir, auf welchen Weg wir im Team setzen, um die Kundenanforderungen bestmöglich umzusetzen. Meistens ist es eine Mischung aus beiden Ansätzen und sobald Programmierungen erforderlich sind, kommen unsere Kenntnisse ins Spiel.

 

Welche Fähigkeiten und Kenntnisse braucht man, um in eurer Rolle durchzustarten?

Michael: Auf jeden Fall Grundlagen der Programmierung – erst einmal unabhängig von einer bestimmten Programmiersprache.

Katja: Man sollte sich auch in Datenobjekten und in Datenstrukturen zurechtfinden, denn darauf basiert Salesforce. Es gibt für unterschiedliche Belange unterschiedliche Objekte mit unterschiedlichen Feldern und Eigenschaften. Dieses Wissen lernt man aber schon in der gängigen Softwareentwicklung. Dann ist es natürlich günstig, wenn man eine Programmiersprache beherrscht. Das muss nicht zwingend Java sein, ist aber von Vorteil, da Apex – die Salesforce-eigene Programmiersprache – sich stark an Java anlehnt.

 

Was mögt ihr besonders an eurem Job?

Katja: Ich finde es immer wieder toll, was wir mit Salesforce aus dem Stehgreif heraus machen können. Wenn man sich nah am Standard bewegt, ist die Schnelligkeit, eine Lösung zu bauen, absolut beeindruckend. Dadurch kann man zum Beispiel mit dem Kunden gemeinsam in ein paar Klicks ein beispielhaftes Layout erstellen oder ändern. Die Kunden fühlen sich dann sehr gut abgeholt, weil sie verstehen, wie ihre Lösung entsteht und eigene Ideen anbringen können, die man direkt im System ausprobieren kann.

Michael: Mir gefällt die Kreativität, die wir brauchen, wenn wir zwischen dem Konfigurieren und dem Programmieren agieren. Nicht jede Kundenanforderung lässt sich immer unmittelbar in eine Konfiguration übersetzen, sondern benötigt manchmal individuelle Anpassungen. Dabei stoßen wir  mitunter an Limits, die Salesforce vorgibt, um ihre Plattform zu schützen, damit kein Missbrauch betrieben wird. Die Mechanismen zu finden, mit diesen Limits zu arbeiten, aber gleichzeitig die Anforderungen zu erfüllen, ist herausfordernd und bedarf kreativer Lösungsansätze.

 

Jede Medaille hat ja zwei Seiten: Gibt es auch einen unbeliebteren Teil in eurer Rolle?

Beide wie aus einem Mund: Die Limits (lachen).

Michael: Salesforce ist als proprietäres System anzusehen. Wenn man es als Entwickler aus der Java-Welt gewohnt ist, nach dem Open-Source- und Community-Modus zu agieren, dann funktioniert dieser Ansatz bei Salesforce nicht. Das ist schon erstmal eine Umstellung.

Katja: Richtig. Man muss am Anfang lernen damit umzugehen, dass es ein paar bequeme Handgriffe aus Java im Salesforce so nicht gibt und bewährte Ansätze aus anderen Programmiersprachen nicht so funktionieren, wie man es vielleicht kennt. Dafür bietet Apex neue Herausforderungen und andere Rahmen, in denen es trotz Limits Spaß macht, sich zu bewegen.

 

Was macht für euch die Zusammenarbeit im CoE Salesforce in der T-Systems MMS aus?

Katja: Ich finde den Teamspirit und die Motivation super. Die Kolleginnen und Kollegen organisieren in Eigeninitiative regelmäßig wertvolle Austauschrunden, zum Beispiel die „20 Minutes“. Bei diesem Format sprechen wir regelmäßig über aktuelle Salesforce-Themen und geben Projekt- und Methodenwissen sowie Best Practice aneinander weiter. Gerade wenn man intensiv im Projektalltag vergraben ist, helfen solche Treffen,  den Blick über den Tellerrand beizubehalten und zu sehen, wer sich gerade mit welchen Themen befasst und was es neues gibt.

Michael: Bevor ich in Salesforce-Projekte involviert war, hatte ich fast nur Kontakt mit Entwicklern; vielleicht war noch ein Projektleiter dabei. Im CoE Salesforce ist das anders, da arbeiten viele Rollen miteinander. Das bringt eine ganz andere Dynamik mit sich und mir gefällt die Vielfältigkeit der Charaktere, mit denen ich dadurch zu tun habe. Im Rahmen jeder Rolle – ob Consultant, Entwickler, Vertrieb oder Projektleiter – trifft man auf einen anderen Typen Mensch. Es gibt Kollegen, die haben keinen originären IT-Hintergrund, sondern sind ausgebildete Juristen oder Psychologen und bringen dadurch ganz neue Blickwinkel in Gespräche mit ein. Auch kulturell gesehen sind wir inzwischen ein bunt gemischter Haufen, mit dem die Zusammenarbeit sehr gut funktioniert.

 

Ihr seid beide beim Dev Day tätig, einem Austauschformat für Entwickler am Standort Dresden.  Was motiviert euch dieses Format mitzugestalten?

Katja: Der Dev Day ist eine tolle Veranstaltung, die ich schon oft besucht habe. Ich wollte dann einfach selbst mal hinter den Kulissen mitarbeiten und so kam ich dazu, aktiv mitzuwirken.

Michael: Ich finde dieses Austauschformat zwischen Entwicklern sehr nützlich, gerade um sich auch mal  über Unternehmensgrenzen hinweg zu unterhalten. Potenziellen Bewerbern für die Position eines (Salesforce-) Entwicklers  kann ich die Teilnahme nur empfehlen. Dort man sich bei den verschiedenen Communities umhören, sich von ihrem Berufsalltag erzählen lassen und sich damit ein sehr gutes Bild machen – zum Beispiel vom Arbeiten bei uns in der T-Systems MMS.

 

Und die letzte Frage: Was würde die Welt ohne Salesforce-Entwickler machen?

Katja: Vermutlich mehr auf standardisierte Prozesse und weniger auf individuelle Anpassungen setzen. Das ist an sich erstmal nicht verkehrt. Aber jedes Unternehmen bringt andere Anforderungen mit, die auch einen ausgefeiltenSystemstandard mitunter an Grenzen bringen können. Und dass diese Grenzen nicht zur Einschränkung für unsere Kunden werden,  das stellen wir sicher.

Michael: So ist es. Und unserer Rolle kommt damit eine wichtige Bedeutung bei,  wenn es um die Skalierung von Projektgrößen geht. Je mehr Anwender die Plattform nutzen, desto weiter bewegen sich Projekte mitunter vom Standard weg, weil sie zu komplex werden. Abbildbar sind sie dann nur noch, in dem wir die vorhandenen Konfigurationsmöglichkeiten auf Entwicklungsebene erweitern.