Fråga:
Hur säger jag till någon att vara kortare och meddela mig mindre ofta?
Premier Bromanov
2016-04-29 04:10:01 UTC
view on stackexchange narkive permalink

Jag ska försöka hålla det kort och kortfattat för att undvika "ventilering" snarare än att förklara.

Kort historia, jag använder skype för att kommunicera med någon som mitt företag har avtalat med. Jag är programmerare och han är designer. Han designar med hjälp av ett system som jag ständigt bygger när han använder det. Det är mindre än idealiskt, men vi gör vad vi kan med den tid och pengar vi har.

Problemet är att han meddelar mig med varje liten hicka. Inte bara buggar, ibland un-reproducerbara buggar, ibland udda beteenden, ibland spekulationer om ett fel, ibland saker han själv har rätt att fixa, men oftast är det vagt. Jag inser att detta inte nödvändigtvis är ett objektivt problem som de flesta står inför, men jag vill bli störd så att jag kan fokusera. Jag vet att kommunikation är bra. Det här är 100% ett problem jag försöker lösa för att hålla mig på gott humör när stressnivåerna är höga. Jag är rädd att jag närmar mig en brytpunkt och kan säga något skadligt. Såvitt jag vet är han inte medveten om att han stör mig, men jag vet inte hur jag ska berätta för honom.

Hur kan jag berätta för honom på ett professionellt sätt att jag bara vill bli meddelad av ett fel / problem om det är reproducerbart och om han kan förklara exakt vad som händer?

Som en varning måste jag vara tillgänglig när som helst, för när han har buggar slutar hans arbete. Om jag slutar kommunicera slutar han arbeta och projektets slut är nära.

Motstå bara frestelsen att svara
@prusswan Att ignorera någon som - för allt - en klient är inte en bra idé.
Svara inte på allt. Gör en punkt att bara svara på meningsfulla samtal
Jag har uppdaterat frågan för att inkludera det faktum att jag behöver vara tillgänglig när jag kan vara.
Sju svar:
keshlam
2016-04-29 05:16:28 UTC
view on stackexchange narkive permalink

Ge honom ett strukturerat fel / rapporteringssystem och uppmuntra honom att använda det. Även en wiki kan pressas till tjänst för detta, även om strukturerade sorterbara / sökbara poster är bättre. Det finns många hantverksverktyg för detta, men jag kommer att beskriva målen.

Skapa en standarduppsättning av information för att samla in för felrapporter (vi kallar dessa "måste-instruktioner") . Påminn honom om att det är extremt svårt att åtgärda ett problem som du inte kan se hända, så du behöver logg-ögonblicksbilden på ett minimum och helst behöver du en beskrivning av en sekvens av åtgärder som på ett tillförlitligt sätt provocerar problemet, en ögonblicksbild / prov / detaljerad beskrivning av det felaktiga / suboptimala resultatet / beteendet, och en skiss över vilken effekt användaren förväntade sig / vill se istället.

Uppmuntra honom att bedöma svårighetsgraden av problemet, från "trevligt att ha" till "kosmetiskt", "irriterande men jag har en lösning för det", "trasigt men jag behöver det inte riktigt än "," trasig och jag behöver fixa den snart "," trasig och jag kan inte använda eller skicka den så här "upp till" trasig och jag kan inte ens utveckla andra delar av systemet förrän det är fixat "och" herregud , om ledningen såg detta skulle de sparka oss båda. " Eller liknande termer. Vissa företag skiljer svårighetsgraden (hur dåligt påverkar användarna) från prioritet (utvecklarens beslut om vad man måste arbeta med först, inte alltid samma ordning).

Detta fångar feedback från användaren - vilket är enormt värdefullt även om det ibland är irriterande - utan att störa dig för annat än stora katastrofer, och lagra det i en form som du kan använda direkt istället för att behöva transkribera dig själv till en databas. Det fångar också diskussioner och filer som behövs för att lösa problemen.

Detta skalas inte direkt; för stora företag och stora produkter kan du inte räkna med att kunder skriver anständiga problemrapporter och behöver ha personer som kan intervjua / vägleda dem för att ge rätt information innan den kan läggas in i databasen. Men din direktstödssituation, med en kund som är ivrig att hjälpa till att göra verktyget perfekt, skickar en idealisk möjlighet att "distribuera" detta och samtidigt göra upplevelsen bättre för både utvecklaren och användaren.

Jag är utvecklare och jag är väldigt mycket den här typen av kunder. Ju mer jag gillar något, desto mer kommer jag att försöka göra det ännu bättre. Allt det buller som kommer in är backhanded applåder; det betyder att kunden tycker att du har något som är värt att förbättra!

Det här är verkligen vägen att gå. Jag tycker att Trello fungerar bra som ett gratis, enkelt system för detta.
Jag går den här vägen, även om jag inte använder något officiellt "system" eller felspårningsprogram, bara Flow och ett skype-meddelande. Vi får se hur det går.
bethlakshmi
2016-04-29 19:43:45 UTC
view on stackexchange narkive permalink

En större grupp skulle använda en buggintagsprocess som gav en viss grad av abstraktion. Jag håller med om att det mest användbara svaret är att komma till någon form av aggregering / separering av buggar - men du kommer att behöva lära den här personen grunderna för felrapportering eftersom han i princip är ditt QA-team. Att undervisa människor som inte har arbetat i en utvecklingsroll kan vara knepigt, eftersom du måste ta reda på hur du kan rama in det du behöver på ett sätt som de kan förstå.

Detta skulle vara mitt tillvägagångssätt:

  1. Ange dina behov på ett icke-anklagande sätt - du behöver en chans att fokusera på ditt arbete utan avbrott, och ha en så tydlig beskrivning av problemet som möjligt när du arbetar med buggar. Om du avbryts varannan eller varannan timme lider ditt arbete - du gör fler misstag, det tar längre tid och att förlora en chans att fokusera på arbetet gör dig frustrerad. Det är viktigt att skilja orsaken till problemet (hans handling att avbryta dig) med människan som orsakar det.
  2. Föreslå en lösning som fortfarande kan tillgodose hans behov - han behöver (1) ett sätt att berätta vad som är fel så att du kan fixa det i rätt tid, (2) ett sätt att få omedelbar hjälp när problemet är en absolut blockerare för att få någonting gjort. Lösningar kommer sannolikt att inkludera:

    • ett primitivt buggspårningssystem - det kan bara vara ett Google-dokument eller ett github-problem - så länge felet är diskret, skrivet tydligt och spårbart, du har grunderna. Helst har du ett format av information du behöver från honom för att lösa problemet och han har en tydlig indikation från dig om var dina framsteg är med att fixa det. Det finns många bra system och mallar där ute för detta
    • ett kriterium för vad som utgör en avbrottsvärd nödsituation - ja, han behöver ett sätt att avbryta dig - om din senaste version helt enkelt inte fungerar är det inte rättvist för honom att behöva vänta på ett blockerande problem. Men ni två måste komma överens om vad det är - vanligtvis saker som "app startar inte", "app svarar inte på något sätt på användaråtgärder", "kan inte starta eller slutföra kritiskt arbetsflöde under några omständigheter". Vanligtvis är allt där användaren kan hitta en lösning inte kritisk.
  3. Be om hans feedback / oro - Diktera inte , ställa frågor - hur ofta kan ni två träffas på de buggar han hittar? Vilket sätt att samla buggarna är mest användbart för honom? Vad är en blockerare / nödsituation i hans värld och hur ofta dyker det upp? Håller han med om den här processen? Har han en bättre idé?

  4. Granska fel och ställa frågor / ge feedback när du går . Generellt med en icke-utvecklare / icke-QA-intressent kommer det att finnas en inlärningskurva om hur man skriver en bra felrapport. Jag kommer inte att säga "icke-tekniskt" - det finns väldigt tekniska människor som är dåliga bugreporter, eftersom de aldrig behövde fixa / hitta ett fel i en formell dev-miljö. Längs undervisningen kan du upprepa stegen ovan - berätta för killen varför du behöver informationen, ge honom ett format för att ge den in och visa honom under vilka förhållanden du behöver informationen.

Om du är ett team för två personer, var öppen för tanken att ord inte är det enda sättet att skriva en buggrapport - till exempel vår QA (som är riktiga QA-personer) har gjort utmärkta videor för oss här - de använder skärmdump, spelar in vad de gör och vad de ser - vi kan se varje bit data, varje knappklick och exakt hur systemet reagerade (som mätbar belastning tid!) på det sättet. Olika människor är bra på att kommunicera på olika sätt, och du kan behöva anpassa varandra och arbeta med varandras begränsningar.

Ställ in regelbundet lite tid för att brainstorma förbättringar av processen - vad behöver ni båda, hur ska ni få det att hända? Du kan till och med föreslå en tidsruta - "låt oss prova detta i fyra veckor och sedan checka in med varandra och se om det hjälpte".

Dawny33
2016-04-29 05:10:14 UTC
view on stackexchange narkive permalink

Jag håller med Prusswans kommentarer. Att svara på varje chatt ger honom en antydan om att du är öppen för sådana konversationer, och det gör bara situationen värre.

Så svara bara på de relevanta konversationerna och svara inte för de som är irrelevanta.

Att inte svara alls får dig att se oprofessionellt ut som du med rätta har sagt här. Så gör aktiesvar . Svara på en massa mindre buggar åt gången, efter 5-6 ackumuleras. Det sparar tid och hjälper dig att behålla det förtroende han har på dig.

Detta skulle ge honom en antydan om att du tar värdefull tid en eller två gånger på en dag för att komma tillbaka till honom om de mindre frågorna, och han kommer att respektera din tid och skulle försöka minska antalet från nästa gång, och det skulle inte framställa dig som oprofessionellt.

Jag tror att problemet med det är att buggar kan stoppa hans arbete i sina spår, och då är jag ansvarig för bortkastad tid. Jag kommer att redigera mitt svar för att se om det får mina behov lite bättre
@PremierBromanov Jag tror inte att det skulle stoppa hans arbete, eftersom aktiesvar två eller tre gånger om dagen löser problemet. Det ska vara lite av ett problem först, men han kommer att anpassa sig. Det fungerade riktigt bra för mig.
Kilisi
2016-04-29 11:59:39 UTC
view on stackexchange narkive permalink

Jag hade ungefär samma problem med flera personer som buggade mig hela dagen med obetydliga saker som de kunde räkna ut själva om de försökte. Jag löste det på det enklaste sättet jag kunde tänka mig.

Jag slutade använda Skype och jag har aldrig börjat igen. Alla som har ett problem eller fel eller vad som helst måste mejla mig, när de gör det måste de faktiskt skriva, så de tenderar att tänka igenom saker bättre, specificera problemet ordentligt och alla möjliga andra bra saker.

Bäst av allt kan jag svara när jag vill. Och jag brukar vara kortare och professionell i mina svar, det skär ut chitchatten. Tid är värdefull. Så jag tittar på deras fråga, avfyrar relevanta frågor och väntar på svaren. Snarare än en konversation som vandrar överallt och pratar och upprepar osv. Det gör att jag kan fokusera mycket bättre och ger mig ett solidt pappersspår för referens när jag vill ha det.

PeteCon
2016-04-29 05:19:24 UTC
view on stackexchange narkive permalink

Svara Skype vid bestämda tider på dagen - först på morgonen, direkt efter lunch (eller enligt ett annat schema som är vettigt för dig). Stäng av den för resten av tiden. Annars kommer du aldrig att vara effektiv på ditt jobb.

För att meddela entreprenören, skicka ett e-postmeddelande med honom som en bcc (så att han inte ser alla andra den skickas till) och säga att du av produktivitetsskäl bara tittar på skype och e-post två gånger per dag de närmaste två veckorna.

Xavier J
2016-04-29 20:06:23 UTC
view on stackexchange narkive permalink

Insistera på att ni två använder ett program för bugspårning som Bugzilla. Detta kommer att minska på "bruset" eftersom han förmodligen känner att han inte har något rimligt utlopp för att dela sina bekymmer än att Skype dig hela dagen. Det är nervös.

Ett felspårningssystem kommer att tvinga honom att välja sina ord noggrant för att ge dig möjlighet att göra ditt jobb, utan all fluff.

user49901
2016-04-29 20:55:57 UTC
view on stackexchange narkive permalink

Har du varit där, gjort det.

Saken är, är du din egen chef? Om inte, bör du ta med honom och be om ett sätt att förbättra din prestation som ett team. Nu, chefer (varit där också) gillar inte problem som kommer utan en lösning, du som utvecklare kan skriva om ett par timmar (ja, det kan du) ett felspårningsverktyg om pengar för att skaffa en är ett problem eller om du inte har tid att dra något ur hyllan och lära sig det.

Din chef hjälper dig gärna att ställa in regler och fråga artigt till designern, att spela efter dem, det är inte du som ringer här, du ' har gjort så långt allt du kan.

Nu kommer saker och ting inte att förändras så mycket direkt efteråt, men sedan kan du förbättra det. Från alla buggar du har kan du träffas i slutet av dagen / veckan och betygsätta dem, du måste förstå hans koncept av en propp och du kan till och med ge användbar feedback i gengäld, efter det, förhoppningsvis har du ett sätt att väga frågor och ta reda på saker som kan fixas senare och separera dem från det som verkligen bryter saker. Fortfarande får du chansen att berätta för den här killen att för att fixa de dåliga behöver du tid att fokusera och att du inte vill bli störd under den tiden, verkligen, att vara direkt gör aldrig ont, så länge du inte missbrukar DND status kommer du ha det bra.

TL; DR: Be din chef att ingripa och ta med ett förslag när du gör det.



Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...