Attualmente, sto scoprendo che gran parte della mia giornata è occupata da persone che chiedono conoscenze di dominio / domande di sistema. Questo influisce sulla produttività personale.
Gli sviluppatori dovrebbero imparare a dire "no" di più per essere sicuri che ricevano meno domande ed essere più produttivi, o gli sviluppatori dovrebbero aiutarsi a vicenda? Le cose vengono documentate, ma è spesso più facile chiedere una "domanda veloce".
Come gestisci questo tipo di scenario?
Sono stato in questa situazione prima.
Prima di tutto, non dire di no . Non rifiutare mai di fornire alle persone risposte alle loro domande. Cerca invece di guidarli in un modo "appropriato" per ottenere quelle risposte.
Questo è ciò che ha funzionato per me:
Che ne pensi di produrre un Wiki, così puoi condividere questa conoscenza così quando la gente viene a chiederti puoi dire "hai guardato il wiki?" e poi diventa un'eccellente risorsa di documentazione, in quanto le persone dovrebbero aggiungere la loro esperienza.
Dove lavoro lo facciamo e ho scoperto che nel corso del tempo mi venivano poste solo domande che non erano così ovvie quando hanno ricevuto risposta nel wiki.
Non dire di no. Ma non rispondere immediatamente neanche.
Metti in chiaro che:
e chiedi ai tuoi colleghi di:
È qualcosa che ho fatto con i nuovi colleghi che sono stato assegnato all'allenatore. Funziona abbastanza bene. Salvano le loro domande, rispondendo spesso a loro stesse mentre approfondiscono la questione. E, naturalmente, sanno che quando arriva qualcosa di urgente su cui rimangono bloccati, possono interrompermi.
Parla con il tuo manager e spiega la situazione.
È compito suo garantire la tua produttività e svolgere il tuo lavoro in modo efficace.
Una possibile soluzione potrebbe essere una "domanda ora" - in cui puoi essere contattato solo per domande entro quell'ora della giornata e altrimenti sarebbe vietato.
Per quanto riguarda la condivisione della conoscenza diffusa - ci sono diversi modi per farlo. Esegui sessioni settimanali sul dominio, sulla base di codice, sulle decisioni di progettazione, ecc. Per garantire che tutti siano sulla stessa pagina. Avvia una wiki per documentare questa conoscenza (un glossario è un buon punto di partenza) e ogni volta che qualcuno fa una domanda, aggiungilo alla wiki. Inizia a indirizzare le persone sul wiki e incoraggiarli ad aggiungerle e aggiornarle.
Ovviamente, qualsiasi soluzione che vieni dovrebbe essere adatta a te stesso, al tuo manager e alla società.
Abbiamo avuto una situazione simile nel nostro ufficio che è condivisa tra sviluppatori, tester e l'help desk relativamente piccolo. Quando l'help desk riceveva una domanda a cui non potevano rispondere, chiedevano assistenza a uno sviluppatore o tester. Nel corso del tempo, le persone dell'help desk hanno chiesto meno domande in generale, ma hanno iniziato a chiedere sempre la stessa persona perché quella persona era la più utile o forse la più piacevole da gestire.
Questo ha funzionato bene per tutti tranne uno sviluppatore utile che stava ricevendo tutte le domande (alcune delle quali potrebbero richiedere del tempo). Era molto utile, ma non ha fatto molto sviluppo.
Abbiamo finito con l'istituire uno sviluppatore del giorno che è diventato la persona giusta per tutte le domande dell'help desk. Se la domanda fosse più appropriata per uno sviluppatore diverso, gli avrebbe rivolto la domanda, ma l'help desk doveva iniziare con lo sviluppatore del giorno.
Abbiamo ruotato la responsabilità tra 5 sviluppatori. Ogni sviluppatore ha avuto solo un giorno a settimana di interruzioni importanti e l'help desk non poteva semplicemente aspettare fino al turno del loro favorito, perché potevano trascorrere diversi giorni.
Dovresti prenderlo come un complimento per cui tutti rispettano le tue conoscenze e ti stanno aiutando con piacere. Questo è davvero enorme. Ora devi aiutare i tuoi compagni di squadra a crescere nella loro esperienza e capacità di assistere i colleghi.
Rispondere a domande apparentemente stupide potrebbe far parte del tuo lavoro.
Supponi di essere il doppio della programmazione rispetto a chiunque altro nel team. Raggiungi la soluzione più velocemente di chiunque altro, crea meno bug di chiunque altro, crea una documentazione migliore di chiunque altro. Se questa è la gamma completa delle tue abilità, sarai comunque un programmatore umile agli occhi del tuo datore di lavoro. Un ottimo programmatore, ma solo un programmatore.
Il tuo valore per il tuo datore di lavoro diventa molto più grande se hai anche la possibilità di trasferire quelle abilità fenomenali ad altri membri del team. Secondo gli occhi del tuo datore di lavoro, avere speso tutto o la maggior parte del tuo tempo aiutando e facendo da mentore agli altri potrebbe essere meglio per l'azienda nel suo complesso piuttosto che passare il tempo a programmare.
Dipende molto da chi sta chiedendo, e perché lo stanno specificatamente.
Se sono tutti sviluppatori junior, nuovi assunti o simili, e tu sei uno sviluppatore senior o sembra essere (per qualsiasi motivo) la persona che sa di più sul sistema, potrebbero rivolgersi a te per evitare di fare un un errore che potrebbe rendere PIÙ un lavoro per te a lungo termine, correggendo i propri errori.
Riguardo a come sistemarlo alcune opzioni includono:
Capisco di aver sentito il bisogno di alzarmi e girare l'ufficio a parlare alle persone ogni tanto. Lo faccio da solo quando ho bisogno di schiarirsi la testa e affrontare un problema da una mentalità diversa. Altri potrebbero anche.
Ciò che è terribilmente scortese è quando le persone si presentano e iniziano a fare domande o a discutere con te senza prima chiedere il tuo permesso. Avrai questi in ogni ufficio. Personalmente quando mi avvicino al cubo di qualcuno, dico ciao, e la prima cosa che chiedo è se ora sia un buon momento. Se dicono di no sorrido e dico che verrò più tardi.
Per quanto semplice e ovvio, sembra che alcune persone non lo facciano e da ciò che ho imparato a non dirigere verso la documentazione, a sottili accenni di esasperazione, oa dire che non faranno smettere di farlo. È davvero un dato di fatto che devi solo imparare a gestire per la maggior parte.
supponendo che queste domande siano correlate al lavoro, allora penso che l'unica cosa che devi fare sia prenotare il tuo tempo in modo appropriato. Se trascorri un'ora per aiutare qualcuno in un altro progetto a ottenere un numero di prenotazione per quel tempo, se ti forniscono uno devi avere la prova che sei produttivo, se non puoi fornirne uno allora hai la giustificazione di non spendere il tuo tempo per aiutarli o per indirizzarli verso la gestione.
Che spiegare ciascuno e ogni cosa, guidali semplicemente nel punto in cui possono trovare la risposta. Con il passare del tempo, inizieranno a cercare le risposte da soli
Odio dirlo, ma: Questo è un bene per l'azienda? Se quello su cui stai lavorando è più importante di quello che stanno chiedendo (alla linea di fondo dell'azienda), allora dì "Ti aiuterò quando avrò finito con questo." Se, onestamente, il loro problema è più pressante per il successo dell'azienda, dì "Ti aiuterò in due minuti". E finisci il tuo treno di pensiero sulla programmazione.
Vorrei assolutamente rispondere, ma se diventa troppo ci sono alcune cose che puoi fare per migliorare il processo.
Cerca di insegnare loro a rispondere alle domande stesse: mostra loro dove è possibile trovare la documentazione pertinente, come scoprire chi ne sa di più ecc.
Spiega loro che è bello fare prima una piccola ricerca e se ciò non aiuta a raccogliere alcune domande tali da non venire a te ogni pochi minuti.
Definisci alcune ore di "non disturbo"
Generalmente vedo la domanda rispondere come un aumento della produttività generale dell'impresa, specialmente se si tratta di domande di tipo dominio / business insight che non possono essere solo cercati su google / RTFM.
Se in una determinata ora due persone vengono fermate e io sto lavorando, è meno produttivo di me che spende 10 minuti per rispondere alle domande di ciascuna persona. Il primo asker può quindi lavorare per 50 minuti e gli altri due lavorano per 40 minuti.
Lo vedo come rimozione di blocchi stradali o di colli di bottiglia. Se sei più anziano puoi avere accesso al contesto che gli altri non hanno. Soprattutto se quello che stanno effettivamente facendo è venire da te non con una domanda, ma cercando una decisione da prendere. Puoi avere il contesto per indicarli lungo il percorso giusto (ad esempio, il cliente non ha bisogno di avere quel campanello e fischietto, andare avanti rispetto a quello che è un grande miglioramento, il cliente lo adorerà)
Detto questo, molte delle tecniche elencate altrove per ottenere la conoscenza periodicamente documentata sono anche di vitale importanza per risparmiare tempo a lungo termine.
Trovo che un po '(stress sulla piccola) maleducazione o condiscendenza ben posizionata faccia un lungo cammino verso la risoluzione di questi problemi.
Se la domanda è buona e la persona ha già fatto uno sforzo, fai uno sforzo tu stesso per aiutarli. Questo fa parte del tuo lavoro. Utilizza i suggerimenti in altre risposte per regolare il flusso di domande.
D'altra parte, se ti hanno interrotto invece di leggere i documenti o se hai una domanda chiaramente googlable (che è ciò a cui penso ti riferisci come "una domanda veloce"), dì qualcosa sulla falsariga di "perché non ti basta google questo?" oppure "non puoi leggere tu stesso i documenti?". Potresti considerare l'aggiunta di parolacce se si tratta di una discussione orale e il tuo ambiente di lavoro lo consente. In ogni caso, comunica che non pensi che questa sia stata un'interruzione giustificata.
Non è la risposta da bravo ragazzo, ma devi fare le cose. Se le persone ti interrompono costantemente invece di leggere i documenti, sono i primi a essere maleducati e ad abusare della tua gentilezza. La maggior parte delle persone riceve il suggerimento molto rapidamente.
Come sei sicuro di gran parte della giornata a essere mangiato da questo? Suggerirei di tenere traccia per una settimana per vedere cosa sta realmente accadendo. Magari riceverai qualche domanda al giorno, ma sembra più come se diventassi il tuo highlight / punto debole della giornata. La chiave è prendere alcuni dati rigidi prima solo per confermare ciò che sospetti.
In secondo luogo, dopo aver ricevuto i dati, dai uno sguardo per capire se è stato buono o cattivo rispondere a queste domande. Forse le cose sono andate molto bene perché hai risposto a queste domande e così la tua compagnia ha fatto meglio di quanto avrebbe fatto altrimenti. In alternativa, ora puoi davvero vedere quanto tempo viene distrutto da queste domande. È qui che proverei a formulare varie strategie per migliorare, ma anche a stabilire quali procedure operative generali sono presenti qui. Ad esempio, in alcuni posti in cui ho lavorato non sarebbe inusuale vedere gli sviluppatori chiedere "Qual è il numero di ticket per questa richiesta?" e se non ce n'è uno, chiedi gentilmente alla persona di fare un biglietto e poi sarai felice di aiutarti poiché la richiesta è correttamente tracciata in questo caso. Anche se questo può sembrare fastidioso attenersi alla politica, l'idea è che se c'è un ticket, il lavoro viene tracciato mentre se non c'è, chissà quante domande sono state poste qui.
In terzo luogo, conferma con il tuo manager e i tuoi collaboratori quanto tempo dovrebbe essere speso per fare questo genere di cose. Se sei più anziano nel team o sei in un posto più lungo, potresti aspettarti di trasferire conoscenze e aiutare gli altri ad accelerare. Dovresti essere protetto più di quello che sei ora? Dovresti rispondere ad altre domande e questa è la maggior parte del tuo lavoro ora? Non lo so, ma a un certo punto questa dovrebbe essere una discussione.
Leggi altre domande sui tag domain-model knowledge