How to Identify a Good Certificate?

How to Identify a Good Certificate?

An article by: Mahbouba Gharbi and Dr. Carola Lilienthal

Introduction

A new trend has been apparent in IT for about fifteen years now: Not only may we learn throughout life, but we can acquire certificates for having expanded our knowledge. Two words in this last sentence should make the interested reader sit up and take notice: “acquire” and “knowledge”.

A certificate must be paid for! Therefore, the first question we want to ask ourselves is whether you can buy a certificate without having substantially increased your knowledge. How are certification procedures organized to prevent such malpractice?

Secondly, we turn to the question of what certificates can or do verify: theoretical knowledge – i.e., everything that can be learned from books, or real practical experience that grows and changes over the years. Should certificates perhaps even have an expiration date? Are there certificates that check whether I maintain or expand my knowledge and experience once certified? Which promises are used to advertise certificates and what can you make of these promises?

Certification procedure

There is a wide range of certificates on offer, yet most certificates and certification procedures are based on a similar process with some comparable variants. Figure 1 shows the basic pattern for certification procedures.

If a training provider wants to offer a training course for a certificate, they first have to consider whether they are able to teach the topics contained in the syllabus (step 1 in figure 1). If this is the case, the training provider must be licensed by the board responsible for this certificate (step 2). With the corresponding license agreement, the board ensures that the training provider implements the board’s syllabus and, if necessary, has the quality of its training materials assured by the board. If you are a prospective examinee looking for a training provider for a certificate, you should always check if the training provider actually holds the required license.

Once the examinee has found a training provider that suits them, they register for the respective training course and pay the training course fee (step 3+4). If the examinee wants to take the exam right after the training course, the training provider registers the examinee for the exam with a certification body shortly before or during the training course (step 5). Certification bodies are authorized for the examination by the board responsible for the certificate. The question pool from which the certification body compiles the examination questionnaires is developed by the same independent board that defined the syllabus for the training course.

Most training courses are organized in such a way that the examination can be taken directly after a training course that lasts several days (step 6). For this purpose, the certification body appoints an independent non-specialist examiner to conduct the exam on site. The exam is administered by a non-specialist examiner in order to prevent them from helping the examinees with the exam in any case.

The certification body receives an examination fee from the examinee for this service (step 7). The examiner has the examinee complete a multiple-choice test (step 9) – either digitally or on paper. They received the tests in paper form from the responsible certification body (step 8). Following the examination, the digital tests are evaluated directly by the certification body (step 11) and the result is announced (step 12). If exam sheets in paper form are used, the examiner sends the completed exam sheets back to the certification body (step 10). There, the answers are evaluated, and the number of correct answers is determined (step 11). The examinee is then informed about their result by email. If the examinee has given enough correct answers, they receive their certificate (step 13).

Figure 1: Certification procedure from the perspective of the examinee [DST]

This process, which at first glance seems relatively complicated for the examinee, was created to counteract the danger presented in the introduction that certificates can simply be bought.

A good certificate is characterized by the fact that the definition of the contents, the training course, and the examination are the responsibility of different institutions that are independent of each other (see figure 2).

Figure 2: Division of tasks [DST]

There are different variants to this comprehensive certification procedure for individual sub-processes:

  1. Preparation without training course (see figure 3)
  2. Remote examination (see figure 4)
  3. Public examination
  4. Examination at a test center

If an examinee wants to take the exam for a certificate without preparation by a training provider, the examination fee is somewhat higher for most certificates (step 5 in figure 3). Books are offered for most certificates to facilitate self-study (step 6 in figure 3).

Figure 3: Preparation without training course [DST]

For the exam, the examinee has the three alternatives listed above.

Since the coronavirus pandemic, many training courses are offered remotely, and therefore location-independently, so a remote examination is the logical step. For this reason, a remote exam is now offered with many certificates. The exam is taken remotely by the examinee and is monitored by an examiner who connects to the examinee’s computer and watches the examinee with a camera. Thus, the need to travel is eliminated for all parties involved. Procedures that allow for online exams to be taken without supervision, on the other hand, invite malpractice.

Figure 4: Remote examination [DST]

In addition, some certification procedures offer examinees the possibility of attending a public examination or a test center where they take their exam under personal supervision.

So, to summarize the answer to our first question: In procedures that follow the process presented here with a separation of responsibilities and where the exam is taken under supervision, it is ensured that you cannot buy the certificate.

Knowledge or experience?

But what about the second issue? What do certificates verify? Theoretical knowledge or practical experience? Well, this question actually depends on the type of certificate!

Any certificate that only consists of a multiple-choice test merely requests theoretical knowledge. The boards, of course, try to create exam questions that can be answered with practical experience only, but that is very difficult with the multiple-choice pattern.

Certificates that fall into this category usually carry the label “Foundation Level”. The Foundation Level is explicitly advertised by the providers as a basic certificate [FGG10]. The examinee masters a field’s basic concepts afterwards. These basic terms can be learned, their meaning can be explained to the examinee. After the exam or training course, the examinee speaks the language of this domain.

Certificates that build on the “Foundation Level” usually go beyond a pure multiple-choice test. These certificates often carry the addition “Advanced Level”, and sometimes “Professional” or “Master”. For these advanced certificates you have to demonstrate practical experience in some way.

For some certificates you must provide testimonials from your employers for projects that fit the topic of the certificate: e.g., 18 months of testing tasks in projects, or 18 months of project management or subproject management.

Some other advanced certificates include an oral examination in addition to the multiple-choice test. In some cases, there is no training course in the traditional sense, but an attempt is made to simulate a kind of project situation in which the participants work together in the respective field.

Then there are some certificates that come with the unpleasant feature of having to be renewed regularly every three or five years. Either the exam must be taken again, or the examinees have to collect credit points that prove certain activities in the certified domain: Conference attendance, presentations, lectures, article publications. This ensures that the examinees’ experience does not become obsolete.

As far as the question of knowledge and experience is concerned, we note that the basic certificate, the Foundation Level, resembles a theoretical driving test. The theory, i.e., the conceptualization and the rules, are mastered, but there is no practical experience. In this respect, the basic certificates should always be taken for what they are: Theoretical knowledge that must be acquired in order to complete advanced certificates.

Conclusion

If you are looking for further training with a certificate, plan for a basic certificate and corresponding advanced certificates, depending on your current level of knowledge. Only advanced certificates can really testify your practical experience.

Furthermore, you should insist on a proctored examination and only choose certificates with a clear separation of responsibility for content, training course, and examination.

While researching the right training provider, don’t let yourself be fooled by pretty brochures and appearances. Try to get an idea of whether the training managers you are being offered spend most of their time on projects in the field – which means they only earn money with training courses occasionally. If you have found such a training provider, it is much more likely that you will come out of the training course not only with a certificate, but with actual practical advice.

We hope that equipped with this knowledge, you will be able to assess the quality of certificates offered on the market and to identify the most suitable further training for yourself.

[FGG10] Fahl, W.; Ghadir, P.; Gharbi, M.: Vom Sinn und Unsinn einer Zertifizierung für Softwarearchitekten – CPSA‑F: Ein gemeinsamer Nenner für Softwarearchitekten (EN: On the Sense and Nonsense of a Certification for Software Architects – CPSA‑F: Common Ground for Software Architects); Sonderdruck OBJEKTspektrum 11/2010

[DST] The process models are domain stories: www.domainstorytelling.org

Anpassungsfähigkeit bei Softwarearchitekten

Anpassungsfähigkeit bei Softwarearchitekten

Axel Feix spricht im Interview darüber, was Anpassungsfähigkeit für ihn als Softwarearchitekten bedeutet, warum sie für den Projekterfolg so wichtig ist und welcher Druck damit auch verbunden sein kann.

Axel Feix hat langjährige Projekterfahrung als Analyst und Softwarearchitekt. Er unterstützt Kunden als Senior Consultant und Trainer bei der Einführung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich für was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenhält.

Was bedeutet es für dich als Softwarearchitekt anpassungsfähig zu sein?

Feix: Nachdem die Definitionsphase im Projekt abgeschlossen ist und feststeht, wie die Softwarearchitektur grundsätzlich aussehen soll, sind die Leitplanken für den Softwarearchitekten vorgegeben. Wenn die Entscheidung auf eine Web-Anwendung gefallen ist, dann wird daraus keine Embedded-Anwendung mehr. Die Softwarearchitektur muss in dem festgelegten Rahmen aber trotzdem verhandelbar bleiben, ohne dabei den Blick auf das Endprodukt zu verlieren. Welches Framework wird in welcher Version verwendet? Welche API wird eingesetzt? Das sind Fragen, über die noch diskutiert werden kann und muss.

Als Softwarearchitekt finde ich es wichtig, mir darüber im Klaren zu sein, dass ich nicht die Weisheit mit Löffeln gefressen habe. Lösungen werden nicht nur fachlich, sondern auch technisch im Team entschieden und das heißt, sich auf gute Argumente einzulassen und aufgeschlossen zu sein. Wenn ein Entwickler oder eine Entwicklerin etwas Cleveres auf die Beine gestellt hat, dann sollte das innerhalb der Leitplanken auch umgesetzt werden. Nur so entsteht am Ende eine gute und vor allem langlebige Softwarearchitektur.

Warum ist die Anpassungsfähigkeit für einen Softwarearchitekten so wichtig?

Feix: Anpassungsfähigkeit für mich als Softwarearchitekt ist wichtig, weil heutzutage alles agil entwickelt wird. Dabei kommt es immer wieder vor, dass Dinge wichtig werden, an die anfangs nicht gedacht wurde oder die keinen hohen Stellenwert hatten. Da denke ich zum Beispiel an die neuen Anforderungen, die es seit der Pandemie in Bezug auf Behörden gibt. Diverse Angelegenheiten, die Bürgerinnen und Bürger immer vor Ort geregelt haben, müssen jetzt auch auf den mobilen Endgeräten funktionieren.

Der technische Wandel ist schnell. Es heißt, etwa alle zwei Jahre werden die alten Technologien durch neue Technologien ersetzt und das Know-how bedarf einer Auffrischung. Wer sich bemüht, immer vorne auf der Buchwelle mitzuschwimmen, um auf dem neuesten Stand zu bleiben, der kann auch anpassungsfähig auf den technischen Wandel reagieren. Neu ist aber nicht immer besser. Anhand von Erfahrungswerten sollte kritisch hinterfragt werden, ob und wie neue Technologien zum eigenen Vorhaben passen und wie sie gewinnbringend eingesetzt werden können. Was heute gehypt wird, kann in wenigen Jahren schon wieder von der Bildfläche verschwinden.

Deshalb müssen Softwaresysteme von Anfang an anpassungsfähig gebaut werden, aber auch als Softwarearchitekt sollte ich mich auf neue Entwicklungen einlassen. Anpassungsfähigkeit ist ein lebenslanger Lernprozess.

In welchen Phasen des Projekts oder in welchen Situationen braucht ein Softwarearchitekt besonders viel Anpassungsfähigkeit?

Feix: Als Softwarearchitekt brauche ich zu Beginn des Projekts besonders viel Anpassungsfähigkeit, bis die Softwarearchitektur durch das Board genehmigt ist. Im Board gibt es viele Stakeholder und alle Interessen sollten angemessen berücksichtigt oder wegdiskutiert werden. Wenn die Softwarearchitektur dann auf die Projektwirklichkeit trifft und das umgesetzt werden soll, was konzipiert wurde, dann müssen die nicht-funktionalen Anforderungen wie Barrierefreiheit, Skalierbarkeit und IT-Sicherheit bedacht werden. Dazu sind eine Reihe von Workshops notwendig, um die Entwicklungsteams auf ihre Aufgaben vorzubereiten und für die Herausforderungen zu sensibilisieren. Gute Ideen vonseiten des Teams sollten in die Detaillierung der Softwarearchitektur einfließen und in der Architekturdokumentation dokumentiert werden. Außerdem kann es Überraschungen organisatorischer Art geben, weil ein Framework oder eine API nicht mehr verfügbar ist, auf die man gesetzt hat. Oder Vertragspartner wurden gewechselt, sodass mit neuen Datenbanken und Produkten gearbeitet werden muss.

Wann herrscht ein ‚zu viel‘ an Anpassungsfähigkeit und wie lässt sich dieses Problem in der Praxis vermeiden?

Feix: Ein „zu viel“ an Anpassungsfähigkeit in der Softwarearchitektur herrscht dann, wenn es keine klaren Strukturen und Verantwortlichkeiten mehr gibt. Wenn es mehrere APIs gibt, die das Gleiche tun, nur an anderen Stellen in der Softwarearchitektur. Das verschlammt die ganze Struktur. Bei Problemen sollte der Softwarearchitekt meiner Meinung nach immer auf das Team zurückgreifen. Er ist bestenfalls Teil eines Querschnittteams oder einer Community of Practice (COP) mit den wichtigsten Vertretern aus Entwicklung, UX-Design, Test und so weiter. Insbesondere die Lead Entwickler spielen eine wichtige Rolle. Die Softwarearchitektur sollte vorgestellt werden, sodass das Team Feedback geben kann und Kompromisse gefunden werden, die die Entwickler und den Architekten zufriedenstellen. Dabei kann dann auch mal klassisch über Optionen abgestimmt werden. Auch hier ist wichtig: Immer im Rahmen der Leitplanken und das vereinbarte Endprodukt nicht vergessen!

Ich finde es generell wichtig, dass man sich auf eine gemeinsame Softwarearchitektur einschwört und das Architekturmanagement im Team am Leben erhält. Wenn dann mal neue Leute dazukommen, lassen sich schnell mithilfe des Teams und der Architekturdokumentation alle auf den gleichen Wissensstand bringen. So gibt es nicht nur einen gemeinsamen Code, sondern auch eine gemeinsame Softwarearchitektur. Wenn ich als Entwicklungsteam an der Entstehung und der Entwicklung von etwas beteiligt bin, kann ich mich auch besser daranhalten.

Die Welt verändert sich immer schneller. Verspüren Softwarearchitekten einen Druck anpassungsfähig zu sein und wenn ja, ist dieser über die letzten Jahre gewachsen?

Feix: Ich glaube, dass der Druck gewachsen ist, weil das IT-Management gerne sagt, dass Softwarearchitekten nur im ersten Teil eines Projekts notwendig sind. Wenn die Softwarearchitektur erst mal steht, haben sie nichts mehr zu tun, aber das stimmt natürlich nicht. Bis das Projekt live geht, gibt es ständig neue Anpassungen, die Prüfungsbedarf haben. Neben Frameworks, die evaluiert und Architekturentscheidungen, die getroffen werden müssen, achtet der Softwarearchitekt im Sprint darauf, dass nicht nur fachliche, sondern auch technische Anforderungen umgesetzt werden. Gerade das Refactoring ist wichtig, damit eine Softwarearchitektur klar bleibt und nicht versumpft. Mit jedem Sprint lagert sich ein kleines bisschen Bodensatz an, der aus neuen Anforderungen und neuen Funktionalitäten besteht. Der Softwarearchitekt schöpft diesen Bodensatz ab, damit neue Anforderungen umgesetzt werden können. Neue Anforderungen vom Fachteam müssen zusammen mit dem PO und dem Entwicklungsteam natürlich auch auf Umsetzbarkeit und notwendige Änderungen an der Architektur geprüft werden.

Bei all diesen Aufgaben ist es von großem Vorteil, als Softwarearchitekt anpassungsfähig zu sein, um verschiedene Rollen einnehmen zu können. Für das Team ist es beispielsweise wichtig, den Softwarearchitekten als starken Fürsprecher zu haben, wenn es um technische Schulden geht und der dann auch vor der Projektleitung dafür eintritt, die Softwarearchitektur sauber zu halten.

 

Vielen Dank an Axel Feix für dieses Interview.

 

Was sagen Sie zum Thema Anpassungsfähigkeit bei Softwarearchitekt:innen?

Wie würden Sie auf die Fragen antworten? Wir freuen uns auf den Austausch in den Kommentaren!

Soft Skills in der IT: Feedback und Konfliktfähigkeit in agilen Teams

Softwareentwicklung in agilen Teams stellt hohe Anforderungen an jedes einzelne Teammitglied. Während den fachlichen und technischen Skills für gewöhnlich die höchste Aufmerksamkeit gewidmet wird, fallen die Soft Skills naturgemäß mit schöner Regelmäßigkeit unter den Tisch. Das ist gleich aus mehreren Gründen paradox: Scrum dient nicht in erster Linie der Verwaltung von Tasks und deren termingerechter Umsetzung, sondern der Organisation des Teams, das mit der Umsetzung betraut ist. Das bringt zwangsläufig den Faktor „Mensch“ ins Spiel.

Im „Daily Scrum“ bleiben oft nicht mehr als fünfzehn Minuten, um die Befindlichkeit der Kollegen, schwelende Konflikte und Unstimmigkeiten im Team zu erfassen. Wer hier nicht eine gehörige Portion Empathie mitbringt, kann schnell mit Problemen konfrontiert werden. Zusammenarbeit ermöglicht erst wahre Teamfähigkeit und dazu gehören zielgerichtetes Feedback sowie Konfliktfähigkeit. Das sind die Themen für diesen zweiten Artikel aus unserer Soft Skills Reihe. Im ersten Teil ging es um Best Practices in der Kommunikation und Gesprächsführung.

Der Ursprung aller Konflikte zwischen mir und meinen Mitmenschen ist, dass ich nicht sage, was ich meine, und dass ich nicht tue, was ich sage.

Martin Buber

Die Fähigkeit, sich einer Gruppe anderer Menschen nicht nur anzuschließen, sondern auch, sich in angemessenem Umfang in eine Gruppe einzuordnen, ist von zentraler Bedeutung für eine erfolgreiche Zusammenarbeit. Dabei geht es darum, mit anderen Teammitgliedern und Stakeholdern zusammen sozial zu agieren und sich und sein Können im Sinne einer Gruppenaufgabe optimal einzubringen, egal ob Sie Softwarearchitekt:in, Entwickler:in, Scrum Master, Manager oder Product Owner (alle Geschlechter) sind. Eine Kultur der Zusammenarbeit sollte gefördert werden, in der fachliche und persönliche Auseinandersetzungen konstruktiv möglich sind.

Reflektion fördert erfolgreiche Zusammenarbeit

Zu einer erfolgreichen Zusammenarbeit gehört es seinem Gegenüber ein offenes und ehrliches Feedback zu geben. Feedback ist ein wichtiger, entscheidender Teil der Kommunikation. Außerdem ist es wichtig, zwischen der Person und ihrer Rolle zu unterscheiden. Dadurch fühlt der Angesprochene sich nicht persönlich verletzt, sondern realisiert durch eine Reflexion, dass nicht er persönlich angegriffen wird, sondern die Rolle, die er gerade innehat.

Durch Feedback fördert man die Reflexion aus sich selbst und der Gruppe und verbessert so die Zusammenarbeit im Team. Man selbst teilt einem anderen mit, wie man ihn sieht und wie man ihn versteht. Feedback stellt aber auch einen Lernprozess dar. Durch das Feedback kann man selbst lernen und verstehen, wie andere einen wahrnehmen, wie man auf sie wirkt. Es ist somit zu unterscheiden zwischen Feedback geben und Feedback erhalten. Bei beiden Feedbackarten sind Regeln zu berücksichtigen.

Wie Sie richtig Feedback geben – und Feedback nehmen

Beim Feedback geben ist zunächst einmal zu festzustellen, ob das Feedback überhaupt erwünscht ist. Ist dies der Fall, dann sollte der Feedback-Nehmer bei den getroffenen Aussagen wertgeschätzt werden und die eigenen Empfindungen sollten als „Ich-Botschaft“ z. B. mit „Ich habe gesehen, dass…“ ausgedrückt werden. Hierbei gilt es zu beachten, niemals persönlich oder beleidigend zu werden und Verbesserungsvorschläge sowie Alternativen zum Verhalten des Feedbacknehmers anzubieten, die sich auch tatsächlich umsetzen lassen.

Der Feedbacknehmer muss sich im Vorfeld auch über einige Prinzipien bewusst sein. Er muss sich im Klaren sein, ob er für ein Feedback bereit ist. Ist dies der Fall, dann sollte er dem Feedback-Geber in aller Ruhe zuhören und ihm nicht ins Wort fallen. Lediglich Verständnisfragen sind erlaubt. Außerdem ist die Bereitschaft erforderlich, sich über das Gehörte Gedanken zu machen und danach zu entscheiden, was davon zukünftig im eigenen Verhalten umgesetzt werden soll. Als Feedbacknehmer sollte man auch immer seine Dankbarkeit dem Gesprächspartner gegenüber zum Ausdruck bringen.

Kühlen Kopf bewahren mit guter Konfliktfähigkeit

Konfliktfähigkeit – das heißt der Mut, Konflikte auszutragen, statt ihnen aus dem Weg zu gehen, und die Fähigkeit, sie zu einer tragfähigen Lösung zu führen. Sie sind als Softwarearchitekt:in, Teil des Entwicklungsteams oder Stakeholder in IT-Projekten aufeinander angewiesen und Ihre Soft Skills zur Konfliktlösung werden täglich gefordert. Dabei ist es wichtig, die eigene Wahrnehmung nicht als die alleinige „richtige“ Wahrheit anzusehen.

Die Einschränkung einer differenzierten Wahrnehmungsfähigkeit ist ein typisches Kennzeichen von eskalierenden Konflikten. Deshalb ist es notwendig, die eigene Wahrnehmung und damit auch verbunden die Interpretation der Ereignisse nicht absolut zu setzen, sondern einer Überprüfung und Korrektur zu unterwerfen und damit auch die eigenen Anteile am Konflikt zu erkennen. Die Bereitschaft hierfür ist bereits ein wichtiger Schritt zur Anerkennung von Rechten der anderen Konfliktpartei. Zusätzlich sollte die Lösung des Konflikts sich an den Interessen aller Beteiligten und allen Betroffenen orientieren. Es sollten Vorteile für möglichst alle Parteien geschaffen werde und großen Wert auf eine rationale Konfliktaustragung ohne Kontrollverlust gelegt werden. Außerdem ist es ratsam, eine dritte Partei mit einzubeziehen, wenn die Verhandlungen ins Stocken geraten und kein Fortschritt erkennbar ist.

Doch mit kühlem Kopf und guter Konfliktfähigkeit werden sie diese täglichen Herausforderungen meistern, denn wie schon der französischer Moralist Joseph Joubert sagte: „Das Ziel eines Konflikts oder einer Auseinandersetzung soll nicht der Sieg, sondern der Fortschritt sein.“

Was ist Ihre Meinung?

Welche weiteren Praxis-Tipps haben Sie zum Thema Feedback und Konfliktfähigkeit? Welches Thema darf auf keinen Fall in unserer Soft Skills Reihe fehlen? Schreiben Sie es gerne in die Kommentare. Wir freuen uns auf den Austausch!

Sie möchten Ihre Soft Skills auf ein neues Level bringen?

Dann empfehlen wir Ihnen unser 3-tägiges Training ‚Soft Skills für Softwarearchitekten (SOFT)‘. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem Soft Skills Training 30 Credit Points im Kompetenzbereich Kommunikation. Zum Soft Skills Training

Soft Skills in der IT: Jeder hat sie, fast keiner schöpft ihr volles Potenzial aus

Soft Skills in der IT: Jeder hat sie, fast keiner schöpft ihr volles Potenzial aus

Neben den Hard Skills, also dem fachlichen Know-how, sind auch die richtigen Soft Skills eine wichtige Fähigkeit am Arbeitsplatz. Gerade im Projektmanagement sind “weiche” Fähigkeiten wie Moderation und Empathie entscheidend, da sowohl Projektleiter:innen als auch Softwarearchitekt:innen und -entwickler:innen stets mit anderen Abteilungen verbunden sind und effektiv kommunizieren müssen. In drei Teilen möchten wir Ihnen wichtige Soft Skills an die Hand geben, damit Sie Ihr Kommunikations- und Konfliktmanagement auf ein neues Level bringen! Im ersten Teil geht es um Best Practices in der Kommunikation und Gesprächsführung. Dabei ist es egal, ob sie Java-Entwickler:in, Scrum Master, Manager oder Product Owner (alle Geschlechter) sind: gerade im Hinblick auf agile Vorgehensweisen in der IT ist heute jedes Teammitglied kommunikativ gefordert.

„Ein Redner kann sehr gut informiert sein, aber wenn er sich nicht genau überlegt hat, was er heute diesem Publikum mitteilen will, dann sollte er darauf verzichten, die wertvolle Zeit anderer Leute in Anspruch zu nehmen.“

(Lee Iacocca *1924).

Kommunikationsfähigkeit: nonverbal und verbal

Die Wirkung der Mimik, Gestik und Körpersprache wird oftmals unterschätzt, obwohl nonverbale Kommunikation mit über 90 % ein wesentlicher, erfolgsabhängiger Bestandteil unseres täglichen Lebens ist. Glaubwürdigkeit entsteht dadurch, dass die verbale und nonverbale Kommunikation miteinander übereinstimmen.

In Bezug auf die Gestik und die dazugehörige Körpersprache ist bei Meetings von mehreren Personen im Projekt darauf zu achten, dass die Positionierung der Teilnehmer:innen auf gleicher Augenhöhe stattfindet. Dadurch wird unnötiges Konfliktpotenzial, das sich aufgrund der ungleichberechtigten Positionierung der Gesprächspartner:innen ergibt, verhindert. Es sollte darauf geachtet werden, den persönlichen Raum aller Person nicht zu verletzen. Wenn Sie mit allen Gesprächspartner:innen an einem Tisch sitzen, achten Sie drauf, dass die relevanten Dokumente in der Mitte liegen. Noch besser ist es, Besprechungen vor einem Whiteboard durchzuführen, da hierdurch die gleiche Augenhöhe garantiert wird. Bei elektronischen Dokumenten sind Beamer und Flipchart als Präsentationsmedien zu bevorzugen.

Gruppengespräche

In der Gruppe zu sprechen, bedeutet auch, die Gruppe in Ihrer Gesamtheit zu integrieren. Wenn Ihnen eine Frage eines Gruppenmitglieds gestellt wurde, antworten Sie bitte immer in die Gruppe hinein. Führen Sie keine Einzelgespräche mit Gruppenmitgliedern. Gruppengespräche zeichnen sich durch Teamfähigkeit aus und das bedeutet konstruktiv zusammenarbeiten, Ideen durchsprechen und Meinungen diskutieren! Neben der Arbeitskoordination können in Gruppensitzungen anstehende Probleme gemeinsam gelöst und allgemein relevante Informationen ausgetauscht werden.

Einzelgespräche

Bei Einzelgesprächen ist es besonders wichtig, die Person direkt gegenüber anzusehen. Bei einer Frage direkten Blickkontakt zu suchen und die Körpersprache seines Gesprächspartners zu beobachten. Die Körpersprache sollte auch vor, während und nach der Antwort intensiv beobachtet werden, denn der Köper lügt nie.

Ein paar Hinweise, wie ein Gespräch gut gelingt:

  • Bereiten Sie sich auf die Inhalts- und Beziehungsebene des Gesprächs gut vor.
  • Behalten Sie das Gesprächsziel immer im Blick.
  • Bringen Sie immer Ihre Wertschätzung zum Ausdruck.
  • Bemühen Sie sich, ihre Gesprächspartner:innen zu verstehen und selbst verstanden zu werden

Stellen Sie Fragen, die das Gespräch vertiefen:

  • Wie kann ich das verstehen?
  • Was kann ich mir konkret darunter vorstellen?
  • Warum ist das so?
  • Klären Sie sofort Unklarheiten.
  • Benutzen Sie eine klare und anschauliche Sprache mit Beispielen.
  • Lassen Sie sich nicht unterbrechen, aber unterbrechen Sie einseitige Monologe.
  • Fassen Sie sich kurz!

Aktives Zuhören

Das aktive Zuhören ist eine zentrale Gesprächsführungstechnik, um von der Empfängerseite aus das Gespräch zu verbessern. Aktives Zuhören ist ein Basic für alle Softwarearchitekt:innen. Es hilft, Vertrauen aufzubauen, Missverständnisse zu vermeiden und durch non-direktives Feedback zu lernen. Aktives Zuhören zeichnet sich durch die offene und empathische Grundeinstellung, das authentische und gleichbleibende Auftreten und durch die positive Bewertung des Gesprächspartners oder der Gesprächspartnerin aus. Dabei wird nach Carl R. Rogers das Verstehen des Sprechers unterstützt durch:

  • Auf das Gegenüber einlassen, konzentrieren und dies durch die eigene Körperhaltung ausdrücken
  • Mit der eigenen Meinung zurückhaltend umgehen
  • Nachfragen bei Unklarheiten
  • Zuhören heißt nicht gutheißen
  • Pausen sind auszuhalten, sie können ein Zeichen sein für Unklarheiten, Angst oder Ratlosigkeit
  • Auf die eigenen Gefühle achten
  • Die Gefühle des Gegenübers erkennen und ansprechen
  • Bestätigende kurze Äußerungen
  • Geduld haben und den Gesprächspartner nicht unterbrechen, sondern ausreden lassen
  • Blickkontakt halten
  • Sich durch Vorwürfe und Kritik nicht aus der Ruhe bringen lassen
  • Empathie ausüben und sich innerlich in die Situation des Sprechers versetzen

Erfolgsrezepte für Ihr nächstes Gespräch

Daraus lassen sich eine ganze Reihe von Best Practices für Ihr nächstes Gespräch ableiten:

  • Paraphrasieren Sie die Aussage, also wiederholen diese mit Ihren eigenen Worten
  • Sprechen Sie direkt die Gefühle des Gegenübers an, indem Sie diese und somit auch ihn/sie widerspiegeln
  • Stellen Sie mehrfach Fragen zu den Inhalten
  • Ist Ihnen etwas unklar, bitte sofort nachfragen, um sich zu vergewissern
  • Im Anschluss zum Fortfahren animieren
  • Wägen Sie Inhalte für sich ab

Was ist Ihre Meinung?

Welche weiteren Praxis-Tipps haben Sie zum Thema Kommunikation und Gesprächsführung? Welches Thema darf auf keinen Fall in unserer Soft Skills Reihe fehlen? Schreiben Sie es gerne in die Kommentare. Wir freuen uns auf den Austausch!

Sie möchten Ihre Soft Skills auf ein neues Level bringen? Dann empfehlen wir Ihnen unser 3-tägiges Training ‚Soft Skills für Softwarearchitekten (SOFT)‘. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem Soft Skills Training 30 Credit Points im Kompetenzbereich Kommunikation. Zum Soft Skills Training

 

Im zweiten Teil unserer Soft Skills Reihe geht es um Feedback und das richtige Konfliktmanagement.

iSAQB CPSA-F® Software Architecture Training now bookable in Spanish and French

iSAQB CPSA-F® Software Architecture Training now bookable in Spanish and French

Hola! Nous avons de bonnes nouvelles! ITech Progress goes International

ITech Progress is the first iSAQB® Accredited Training Provider to offer the basic training for software architecture (CPSA® – Foundation Level) in Spanish and French. The first dates for 2021 can now be booked! After the training, participants can optionally take an online certification exam for the CPSA-F® in Spanish and, from May 2021, also in French.

With the Certified Professional for Software Architecture (CPSA®) certification, the International Software Architecture Qualification Board (iSAQB®) offers an internationally recognized and standardized education and training program for software architects. The training courses at the Foundation Level convey well-founded basics in software architecture, which can be specifically deepened at the Advanced Level.

The two architecture experts Mahbouba Gharbi and Alfredo Delgado Sánchez provide a comprehensive insight into the world of software architecture in their four-day online training courses for the CPSA-F®. Participants learn important methods, techniques and tools through many practical exercises. The compact basic training is aimed at all software architects, senior developers and IT specialists involved in software projects. It improves communication in project teams by using a common technical language and thus helps to develop more understanding for each other. Therefore, this training has also proven to be ideal as project-accompanying training for IT teams.

Training Content:

  • Basic concepts of software architecture
  • Design, development, description and communication of software architectures
  • Methods, techniques and tools for software architects
  • Quality models, characteristics, requirements and assessment
  • Responsibilities and roles of a software architect in a project
  • Practical examples and exercises

At the end of the software architecture training, you will be able to make problem-related design decisions, design and document software architectures for small and medium-sized systems.

The first dates:

The first online training in Spanish will take place from May 18 – 21, 2021 and the first online training in French will take place from November 09 – 12, 2021. All dates, also in German and English, can be found here.

In Spanish you can already find a sample exam and many more informative documents about the Foundation Level for download at iSAQB. The French documents will follow soon!

Up to 6 weeks before the start of the training you can save €100 per person with our Early Bird discount. Additionally, you save €100 per participant if you register together with a colleague from your company.

Advantages of our online training courses:

  • Location-independent real-time learning

  • High level of interactivity through hands-on exercises, breakout rooms and visual collaboration (e.g. Miro)

  • Ideal coaching also in the breakout rooms

  • Small and intensive learning groups with a maximum of 12 participants

Mahbouba Gharbi

Mahbouba Gharbi

Trainer for CPSA-F in French, German and English

Mahbouba Gharbi has been an expert in software architecture for over 20 years and passes on her knowledge as chief architect, consultant, lecturer, trainer and author. She deals with the design and implementation of medium to large software systems. In addition to her work as managing director of ITech Progress GmbH, she is co-founder and CEO of iSAQB e.V. and actively helps design curricula and exams.

Alfredo Delago Sánchez

Alfredo Delago Sánchez

Trainer for CPSA-F in Spanish

With more than 30 years of experience, Alfredo Delgado Sánchez is an expert in the development of IT solutions. In addition to his technical expertise in software architecture, he brings methodical and communicative skills from his activities as a lecturer and IT project manager. With his open-minded nature and know-how around good practices, agile methods, standards and processes, he has made it his mission to share expertise on software architecture.

We advise you on your further education plans and accompany you on your way to becoming a Certified Professional for Software Architecture! If you have any questions, we will be happy to help you at +49 621 595702 41 and Academy@itech-progress.com.