Gran parte delle abilità comunicative. Dovresti anche sapere che essere scettici riguardo ai nuovi strumenti è comune nell'industria del software. Maggiori informazioni su questo più tardi.

Primo: il tuo mindset

• Non stai vendendo quindi non ne hai voglia. Stai gentilmente presentando una soluzione a un problema comune, quindi sii fiducioso. (In realtà se si commercializza un prodotto, si consiglia anche di avere quest'ultima mentalità.)
• Siate pronti a essere respinti. Non puoi mai essere sicuro di convincere tutti ogni volta. Inoltre, è comune nei team di sviluppo del software essere (erroneamente) scettici o addirittura pigri su:
  1. Riutilizzo del codice che ha bisogno di apprendere.
  2. Utilizzo di nuovi strumenti avanzati adeguati per risolvere nuovi tipi avanzati di problemi.
  3. Test delle unità di scrittura.

Secondo: la tua presentazione

Dale Carnegie nel suo libro classico, "Come conquistare gli amici e influenza le persone" ha molte cose da dire su questo argomento. Una di queste cose è che devi indicare i loro problemi e le tue soluzioni per loro piuttosto che affermare i tuoi desideri e le tue emozioni. A seguito di tale lead:

- Trova i problemi che puoi risolvere

Cerca di trovare le principali preoccupazioni comuni nella tua organizzazione che gli strumenti possono in qualche modo risolvere. Inizia con loro (ad esempio, ricorda l'altro giorno in cui stavamo parlando di come eseguire regolarmente i nostri test mette troppo sui nostri piatti? ... e poi porta a strumenti Contiuous Integration.)

• Trova ed elenca i problemi che la tua squadra crede siano anche loro. In questo modo non dovrai convincerli che esiste un problema prima di presentare la soluzione. Vincere una discussione è davvero difficile. Vincere due argomenti in una sessione è davvero difficile.
• I problemi che menzioni non devono essere direttamente correlati alla soluzione che stai fornendo. Devi solo essere in grado di iniziare dal problema e portare alla tua soluzione. naturalmente, le soluzioni dovrebbero essere abbastanza pratiche o sembreresti come preeching. Non preech. mai.

- Rispondi prima di chiederlo

Cerca di rispondere agli argomenti che indovina davvero che la gente inizierebbe prima di avviarla. Ciò rende la tua argomentazione più solida e convincente.

• Non essere ovvio in questo. Miscela quelle risposte nel contesto della presentazione. Per esempio. nella prima parte di questa risposta ho evidenziato 3 comuni scetticismi nello sviluppo del software. Metto il soggetto nel secondo oggetto! Vedi cosa ho fatto lì?!

Infine devo sottolineare ancora una volta che si dovrebbe evitare a tutti i costi preeching. mantenere sempre una mente aperta.

Sono stato in situazioni come questa prima. Una cosa da evitare è saltare subito a dire "Dovremmo adottare lo strumento X, a causa della ragione Y." Questo probabilmente innescherebbe la risposta di cui ti preoccupi.

Uno degli approcci che ha funzionato per me in passato è quello di identificare effettivamente un punto di miglioramento. Ad esempio, potresti indicare qualcosa nei tuoi processi che richiede molto tempo. Se è quindi possibile identificare uno strumento che aiuta a migliorare su quel punto, e si può dimostrare, ciò potrebbe consentire un approccio più aperto.

Qualcosa che è sempre molto importante in queste situazioni è ascoltare i tuoi colleghi. Potrebbero fornire qualche prezioso feedback. O potrebbero venire con una soluzione migliore. Potrebbero esserci anche casi in cui stanno solo cercando di bloccarti con argomenti irrilevanti, nel qual caso dovresti essere pronto a rispondere di conseguenza.

Un altro approccio è quello di dimostrare casualmente uno strumento a un collega. Il modo in cui puoi farlo è quello di avere lo strumento aperto sul tuo computer con uno scenario demo pronto e quando un collega guarda sul tuo schermo, mostragli quello con cui stai giocando. Linee come "Ho giocato con questo per vedere se è buono. Guarda, fa questo che è bello". può aiutare.

Un'altra cosa da tenere a mente è quella di essere onesti su tutti gli strumenti, compresi gli inconvenienti. Ciò aumenterebbe la sensazione che stai provando a risolvere un problema, non introducendo altro overhead.