È per questo che c'è il tuo manager. Se hai problemi a ottenere le informazioni di cui hai bisogno per svolgere il tuo lavoro e poiché non hai l'autorità di ordinare a nessuno di aiutarti, il tuo manager dovrebbe parlare con l'altro manager e risolverlo.

Per ripetere: non hai potere. Non puoi far fare niente a nessuno. Non è questione di essere indipendenti. Il lavoro del tuo manager non è quello di inseguire nessuno. Il lavoro del tuo manager è parlare con un altro manager che può dire ai suoi subordinati di aiutarti. Se non vuole farlo, allora non sta facendo il suo lavoro.

Lo facevo per vivere. Quello che trovo è che le persone temono l ' idea che il loro tempo possa essere sprecato. Se gli fai sapere in anticipo che rispetti il ​​loro tempo, sarà molto più probabile che facciano uno sforzo.

Di solito, dopo aver messo insieme il sommario (e averlo approvato), ho suddiviso tutti gli argomenti e "assegnato" mentalmente i dettagli / le lacune mancanti a persone note per essere gli esperti interni o ingegneri originari. Dicevo loro in anticipo che avrei avuto bisogno di X quantità di tempo per coprire i seguenti dettagli e includere tutte le domande nella stessa email. Ho fatto loro sapere che c'erano 2 fasi: la fase di raccolta delle informazioni e, successivamente, la fase di editing per l'accuratezza.

Ingegneri timidi inaccessibili? Nessun problema, se invii loro un'e-mail in anticipo con il tuo elenco di domande specifiche e una stima del tempo. La maggior parte delle persone collaborerà se sa che non è un tempo indefinito.

A volte ci sono vere barriere linguistiche, quindi potresti aver bisogno di fonti alternative. Ma quelle stesse persone potrebbero essere disposte a rivedere i dettagli tecnici / accuratezza sui passaggi di modifica, dopo aver arricchito l'intero manuale / documento. Anche un registratore ha aiutato molto (specialmente quando qualcuno parla di cose pelose che non puoi capire al primo passaggio e usa un gergo con cui non convivi come fanno loro). Per non parlare dei mumbler!

Una cosa che mi ha aiutato molto è stata partecipare a un paio di riunioni di progettazione del prodotto (o qualunque cosa sia l'equivalente nel tuo caso), soprattutto se puoi farlo presto. In questo modo sarai "reale", invece di un estraneo di cui potrebbero o non potrebbero nemmeno sapere. Inoltre puoi valutare chi sarà accessibile, in anticipo. Questo può o non può essere pratico nella tua situazione. Contrattare è fantastico, ma come hai detto tu, il trucco è che sei un outsider che deve produrre come un insider.

Sono uno scrittore tecnico che lavora con sviluppatori remoti - con questo intendo dire a 500 miglia di distanza, non "in ufficio solo alcuni giorni". Ci sono due chiavi per risolvere questo problema e finora ne hai chiesto solo uno (inducendoli a rispondere). Ci arriveremo, ma prima parlerò dell'altro.

Gli sviluppatori (o qualsiasi esperto in materia, se è per questo) tendono a non rispondere bene le persone chiedono loro cose Le PMI hanno già risposto. Questo è vero per scrittori di tecnologia, tester, addetti all'assistenza clienti e probabilmente altri. Quindi il tuo lavoro inizia molto prima rispetto alla documentazione della funzionalità per lo più funzionante. C'erano specifiche funzionali? Revisioni di design? Discussioni sui requisiti? Hai letto quei documenti e sei andato a quelle riunioni? Hai fatto domande su come funzionerà la funzione all'inizio? (No, allora non puoi anticipare tutte le domande, ma alcune potrebbero venire in mente.) Fai parte del processo ?

Se non è così che lavorano gli scrittori nella tua organizzazione, Ti esorto a fare il possibile per cambiarlo. Se la cultura è "lo sviluppatore lancia un rilascio oltre il muro a QA e doc quando ha finito", combatterai per sempre questa battaglia "troppe poche informazioni, troppo tardi". Se è il tipo di organizzazione in cui puoi interrompere quelle riunioni, inizia a presentarti. se non lo è, collabora con il tuo manager per ottenere un accesso più rapido alle informazioni e ai piani prima che siano scolpiti nella pietra.

(Sì, questo significa che alcune cose che impari presto dovrai disimpararle in seguito ; i piani cambiano. Avendo fatto in entrambi i modi nel corso della mia carriera, posso dire con sicurezza che è meglio avere un accesso anticipato. Prendi appunti in modo da poter ricontrollare più tardi quando la verità muta.)

C'è un vantaggio in questo approccio oltre al semplice accesso alle informazioni. Vuoi che gli sviluppatori si abituino a vederti a quelle riunioni (fisicamente o virtualmente). Vuoi che inizino a pensare a te quando hanno bisogno di discutere un cambiamento con qualcuno. Il mio team di sviluppo mi tratta come un membro del team in quasi tutti gli aspetti (non devo eseguire il debug dei guasti della suite di test :-)), e non è un caso. L'ho coltivato.

Ora, tutto ciò che è stato detto, arriviamo alla domanda che hai posto: come ottenere (a) qualsiasi e (b) risposte migliori alle tue domande. Sono d'accordo con altri consigli che hai ricevuto sull'invio di e-mail con domande / argomenti specifici e sulla pianificazione di riunioni quando necessario, ma oltre a questo: fai buone domande. Con questo intendo:

• Sii specifico. "Come funziona il server?" è ampio e vago; lo sviluppatore probabilmente pensa che tu stia chiedendo un corso. "In che modo il server gestisce troppe richieste in arrivo?" è meglio.

• Mostra ciò che hai già fatto. È una domanda a cui puoi rispondere almeno in parte utilizzando il software? Allora fallo. "Ho provato a inviare una serie di richieste il più rapidamente possibile tra le schede del browser, ma non sono riuscito a farla fallire" mostra che hai cercato di aiutare te stesso. Oppure, se non è qualcosa che puoi ragionevolmente testare (avrai bisogno di decine di migliaia di richieste e non sai come scrivere il codice per scrivere lo script), mostra lo sforzo in background in qualche altro modo: "Ho controllato il design spec e ho visto la sezione su come dobbiamo gestire questo caso, ma non capisco cosa hai detto sui pool di thread e le code di priorità ".

• Se continui ad avere gli stessi tipi di domande, chiedi come pescare: "Ho bisogno di sapere quale codice di errore restituiamo se X e so di aver chiesto informazioni sul codice di errore per Y la scorsa settimana. C'è un punto nel codice in cui posso cercarli? " A volte non puoi o non ne vale la pena o ti porterà fuori strada, ma mostrare che il tuo primo istinto è "provare a capirlo" invece di "chiedere allo sviluppatore" fa guadagnare punti nella mia esperienza.

• Quando chiedi loro di recensire qualcosa, (a) dì loro cosa stai cercando e (b) scegli come target in modo appropriato. Gli sviluppatori sono le persone migliori da esaminare per l'accuratezza tecnica; dovresti cercare la tua correzione di bozze o il tuo giro di marketing altrove. Se hanno visto bozze precedenti, evidenzia cosa c'è di diverso in questa e come hai risposto ai loro commenti precedenti.

Infine, se la tua organizzazione ha tester, allora hai un alleato naturale. Entrambi avete bisogno delle stesse informazioni. Prova a collaborare con loro.

Il tuo primo paragrafo è in contraddizione con se stesso:

Sono uno scrittore tecnico che lavora in ufficio 1 giorno a settimana. Il lavoro che svolgo non richiede molto lavoro di squadra perché sono l'unico scrittore, ma ho bisogno di ottenere informazioni dagli sviluppatori.

È chiaro che non puoi lavorare in totale isolamento dagli altri persone, dal momento che dipendi da loro per ottenere le informazioni di cui hai bisogno. Tuttavia, dici che non hai bisogno del lavoro di squadra per svolgere il tuo lavoro.

La tua mancanza di tempo in ufficio è probabilmente un fattore che contribuisce e entrare più spesso probabilmente risolverebbe molti dei problemi che hai stanno affrontando. Sembra che tu stia combattendo contro "lontano dagli occhi, lontano dalla mente". Più interazioni faccia a faccia con il tuo manager, gli sviluppatori e i responsabili dello sviluppo faranno molto per risolvere questo problema.

Un altro problema è che il ruolo di un redattore tecnico è frainteso. Un lavoro precedente era in un'organizzazione con un piccolo team di scrittura tecnica e molte persone non capivano effettivamente quale valore aggiungessero o quali fossero i loro ruoli / responsabilità. Dal parlare con loro, questo è abbastanza comune in molte aziende, quindi dovrai iniziare l'istruzione. Se il tuo capo non vuole inseguire le persone, dovrai essere tu a inseguire le persone. Poiché inseguire costantemente le persone è una perdita di tempo, ti consigliamo di parlare con il tuo capo della possibilità di istruire il resto del personale su ciò che fai rispetto a qualsiasi prodotto o servizio fornito dalla tua azienda, come ti adatti al processo e le cose di cui hai bisogno per poter svolgere il tuo lavoro in tempo.

Una volta che sei di fronte alle persone più spesso e le istruisci su ciò che stai facendo, molti dei problemi che dovrai affrontare diminuiranno. Il team di sviluppo che non si preoccupa della documentazione è una questione culturale molto più profonda in quel team che probabilmente è fuori dal tuo controllo. Il tempo di crisi estremo intorno alle versioni è anche indicativo di altri problemi di processo o di progetto che sono probabilmente anche a un livello più alto.

Se c'è resistenza alle soluzioni, non sei in grado di istruirlo, non lo sei. Non riesci a trovare il tempo con le persone per svolgere il tuo lavoro, non sei in grado di convincere i manager a sbloccarti: sono segni di problemi organizzativi più profondi.

Mi dispiace dirtelo, questo non è un problema unico. Anche quando sei il capo di qualcuno, questo può accadere.

Il suggerimento di coinvolgere il tuo manager è un consiglio valido. Tuttavia, dire che sei impotente è un po 'esagerato.

Hai almeno due strumenti nella tua scatola.

1] Ogni volta che qualcuno può farti saltare in aria, lo faranno. Ricordati che! Allora cosa fai? Fai una passeggiata. Scegli un'ora ogni settimana che più ti si addice (varia il giorno e l'ora ogni settimana) e vai da ciascuno degli sviluppatori e inizia a fare domande. Sii cordiale. Di Ciao. Presentati. Spiega il tuo problema e come possono aiutarti con un sorriso. Dì "Grazie. Sii il più gentile e gentile possibile, ma sii fermo che hai bisogno di una risposta alle tue domande. Se non ora, sarà più tardi. Mettilo in chiaro, non sei lì per rendere la loro vita più difficile. Se dopo pranzo va meglio, va bene. Dopo pranzo lo è. Se continuano a stupirti, spiega semplicemente che la direzione probabilmente farà domande e che preferiresti dire così ?? è estremamente utile invece di non particolarmente utile. Altri due trucchi che aiutano sono parlare a bassa voce con un tono naturale in modo che nessun altro possa davvero sentire. In questo modo impari molto di più. Inoltre, se stai parlando con loro, abbassati o abbassati di quanto non siano. Mi sono accovacciato sulle mie cure per farlo accadere. Sorridi. Essere amichevole. Dopo un po ', potresti essere sorpreso che inizino a inviare i dettagli via e-mail mentre procedono. Sanno cosa è in gioco per te e per loro e ora sei un membro della squadra. Potrebbero essere necessarie alcune settimane per iniziare davvero a funzionare bene. Finché capiscono che non si tratta di un comportamento occasionale, cedono.

2] Se non sei in grado di fare una passeggiata, un altro ottimo strumento è la responsabilità. Odio essere una seccatura (PIA), ma a volte, questa è la tua unica opzione, tuttavia, non dovrebbe essere la tua prima opzione. Se stai inviando messaggi di posta elettronica, metti in copia il tuo capo. Chiedi una risposta a tutti. Se non rispondono a tutti, inoltra qualsiasi risposta al tuo capo con un cc all'individuo. Archivia tutto per sempre. Lo stesso con il tuo capo. Presto, tutti inizieranno a rendersi conto che c'è responsabilità e che non rispondere è un suicidio professionale. Certamente, hai almeno documentato il motivo per cui hai problemi a svolgere il tuo lavoro. Puoi spiegarlo al tuo capo. Spiega che stai fatturando ore che non sono produttive e che preferisci che non fosse così. Questa è comunque una buona opzione, sicuramente per CMMI, ISO e altri motivi, tuttavia preferisco l'opzione 1 come migliore.

Ho scoperto che entrambe le opzioni funzionano bene. Ci vogliono settimane prima che tutto inizi a funzionare bene. Tuttavia, con l'opzione 1, ti stai preparando per un successo incredibile. Ho usato questa tecnica quando ho rilevato progetti falliti per una telecomunicazione globale che aveva l'occhio del CEO / Presidente del consiglio di amministrazione. Più usavo l'opzione 1, più persone si rendevano conto che stavo facendo loro un favore e la quantità di collaborazione che ottenevo era sbalorditiva. In effetti, ho avuto un impatto maggiore rispetto ai loro capi che mi amavano perché li ho fatti sembrare belli anche senza che la direzione capisse davvero il motivo. Tutti vincono.

L'email è un modo scadente per pianificare e seguire le attività. Devi sollevare il problema al tuo capo che dovrebbe quindi programmare un incontro con il capo degli sviluppatori. Lo scopo dovrebbe essere quello di definire alcune definizioni di Fatto per gli sviluppatori, in base alle quali un'attività o una User story dovrebbe essere contrassegnata come completa solo se vengono soddisfatti anche i requisiti della documentazione (simile alle linee guida per la codifica, ai test unitari ecc. ). Sembra un approccio difficile, ma o.t.o.h., questo elimina ogni argomento o emozione dalla discussione. Dopo diversi anni di lotte, l'ingegneria del software moderna è giunta a un accordo sul fatto che i passaggi di qualità come l'analisi del codice statico, i test unitari ecc. Dovrebbero essere integrati nel processo piuttosto che lasciarlo al caso. La documentazione non è ancora del tutto disponibile poiché è difficile da automatizzare e anche la quantità di documentazione sufficiente è ancora oggetto di dibattito. Tuttavia, se la tua azienda avesse deciso che dovrebbe esserci la documentazione, allora anche quell'attività dovrebbe essere incorporata nel processo.

Il tuo compito come redattore tecnico dovrebbe quindi essere quello di discutere la qualità della documentazione, non cercando di convincere tutto il tempo se avrebbero documentato affatto

Sei un portatore di interessi nel processo di sviluppo e, in quanto persona che ha i tuoi stakeholder, direi che sei un maiale piuttosto che un pollo (qualcuno che non ha solo un coinvolgimento, ma un impegno).

Inserisci te stesso nel processo di gestione del progetto / scrum. Partecipa alle riunioni di stato / standup e comunica a tutto il team di progetto che il tuo contributo è stato bloccato, che non raggiungerai l'impegno che ti è stato delegato e che hai accettato in merito alla prossima versione spedibile. Ottieni criteri di accettazione (requisiti) e attività utilizzabili nelle storie in primo piano, in modo che la "definizione di fatto" di quella storia includa il tuo contributo.

Ciò che fa è migliorare la responsabilità delle altre persone nei tuoi confronti e la tua visibilità sul altri che partecipano al processo. Compresi gli stakeholder aziendali. Fornisce inoltre alle persone di cui hai bisogno il tempo e l'attenzione per darteli, poiché fa parte della pianificazione delle capacità e della stima dello sviluppo.

Le e-mail timide ottengono risposte timide, le e-mail assertive ottengono risposte assertive.

Come altri hanno detto, quando possibile è meglio intensificare questo problema attraverso la catena di gestione. Se l'azienda ha deciso consapevolmente di non destinare risorse sufficienti alla documentazione, è qualcosa da sollevare durante la revisione dopo la spedizione. Ma la domanda sembra cercare una soluzione quando la direzione non ha visto un problema in arrivo finché non sono stati troppo sovraccarichi per reagire.

Altre persone hanno descritto i passaggi necessari per convincere le persone che conosci le tue cose. Se hai fatto tutto questo e ancora non riesci a ottenere una risposta, prova a inventare una risposta che sembri plausibile, quindi inviala tramite posta elettronica agli sviluppatori dicendo "Penso che sia giusto. Conferma da <date>, quando lo aggiungerò alla documentazione ufficiale ".

Se la tua comunicazione mostra chiaramente la tua chiarezza di pensiero e rispetto per i tuoi colleghi, faranno un rapido calcolo mentale: se non rispondo, questa persona è probabilmente abbastanza articolata da fissarmela; se rispondo, mi guadagnerò il rispetto che mi hanno dato .

Ovviamente questo approccio ha i suoi rischi, ma se hai escluso la soluzione giusta (escalation attraverso la direzione) , questa potrebbe essere la scommessa che hai.

Risposta breve, direi, non puoi "convincere" le persone a rispondere alle tue email ...

... e risposta lunga, direi, personalmente, come mi piace essere avvicinati ai problemi significa chiedere aiuto ...

... quindi per una risposta più lunga, direi, non puoi "convincere" le persone a rispondere, ma puoi fare in modo che il tuo email più "attraenti per la risposta".

Questo per dire, dal punto di vista dello sviluppatore che viene chiesto, sarei più propenso ad aiutare se mi venisse chiesto solo di correggere le bozze, invece di essere chiesto di fornire.

Quando mi viene chiesto di correggere le bozze, è la mia competenza ed esperienza personali che ti servono.

Quando mi viene chiesto di fornire, mi (potrei) quasi sentire come te avresti potuto cercare tu stesso la risposta.

Come si suol dire, catturi più mosche con il miele che con l'aceto.

Allo stesso tempo, non aspetterei lo sviluppatore se la mia scadenza erano incombenti.

Continuerei a inviare il mio lavoro al mio superiore in tempo con un elenco di documentazione che potrebbe ancora richiedere un professionista ofing (forse aggiungendo anche l'ultima volta che io e lo sviluppatore abbiamo parlato per ogni elemento nell'elenco).

In questo modo, avrei comunque coperto tutte le mie basi mentre imparavo contemporaneamente nuove cose che mi avrebbero aiutato nella mia professione.

Ma forse è così che l'hai già fatto.

In tal caso, mi dispiace che tu sia in un tale sottaceto, ma stai tranquillo, quindi, che sei già proattivo e stai facendo il tuo lavoro.

Una cosa che faccio per assicurarmi che le email ricevano risposta è inviare un'email a una persona alla volta. Ho visto più e più volte, se mandi un'email a un gruppo di persone, cade di lato perché nessuno è necessariamente responsabile. Quindi, se qualcuno del team di sviluppo può aiutarti, scegline uno e inviagli un'email specificatamente.

Quando non ricevi una risposta, invia un'email al loro manager con qualcosa del tipo "Ehi, ho inviato a Steve un'e-mail chiedendo queste informazioni . Ne ​​ho bisogno entro la fine della giornata ma non ho ancora ricevuto risposta, puoi assicurarti che lo riceva? "

Ora, hai reso Steve e il suo manager responsabili.

Se continui a non ricevere risposte, sali di un livello dal superiore di quel manager e richiedi aiuto allo stesso modo finché qualcuno non fa qualcosa.

Mostra la traccia cartacea secondo necessità.

In primo luogo, sarai tu quello che inseguirà le persone perché nessun altro in autorità vuole occuparsi di questo compito.

Secondo, affronta il problema con il tuo capo. Di nuovo, farai il lavoro, ma potrebbe avere alcune strategie. Ad un certo punto, arriverai a un momento in cui non otterrai ciò di cui hai bisogno in tempo, quindi cosa fai al riguardo? Quanto tempo è ragionevole per te per dire: "Se non ho qualcosa di cui ho bisogno 'x' tempo prima che sia dovuto, come possiamo riprogrammare / ridefinire le priorità?" Spiacenti, ma coloro che prendono decisioni devono confrontarsi con il problema. Concentrati sul fatto che vuoi fare le cose in tempo, ma non hai l'autorità di ritenere tutti responsabili per fornirti le informazioni di cui hai bisogno. Documenta tutte le richieste e le consegne.

Oltre a tutto questo, sono spesso molto affrettato a preparare la documentazione, quindi è un grosso problema

Il fatto che tu sia "affrettato" non è un problema, riceverai molta simpatia da chiunque. Devi far sì che il tuo capo si impegni a una data / ora di scadenza in cui se non ottieni ciò di cui hai bisogno entro questo periodo, non viene fatto in tempo.

La parte negativa della tua azienda è quando diverse squadre / divisioni vengono valutate isolatamente. I programmatori se la cavano senza aiutare con la documentazione. In tutta onestà nei loro confronti, se solo sono responsabili del loro codice, avrà sempre la priorità su tutto il resto. Se la documentazione è importante (ovvero la tua azienda ci guadagna direttamente o indirettamente), tutti i responsabili lungo la catena di eventi che lo realizzano dovrebbero condividere la responsabilità e le ricompense. Tu e gli sviluppatori dovreste in un certo senso essere nella stessa squadra quando si tratta di documentazione. Se gli sviluppatori ti ricevono le informazioni in tempo e tu non le consegni, è sul tuo risarcimento e viceversa. Non ci può essere uno scenario in cui una parte inibisca l'altra senza subirne le conseguenze.

Qualunque sia il valore che una determinata documentazione apporta all'azienda, tutti dovrebbero raccogliere i frutti quando è fatta e coloro che soffrono che non fanno la loro parte. Sfortunatamente, le aziende non lo fanno. Capire una struttura del genere dovrebbe essere lo scopo dei manager. Altrimenti, cosa stanno facendo per guadagnare denaro per la sua azienda?