Reported speech w praktyce: jak przekazywać informacje z zebrań i maili po angielsku

Po co w pracy reported speech: konkretny kontekst biurowy

Sytuacje w pracy, w których reported speech jest niezbędny

W środowisku biurowym mowa zależna pojawia się wszędzie tam, gdzie trzeba przekazać dalej to, co ktoś powiedział lub napisał. Najczęstsze sytuacje:

• relacjonowanie przebiegu zebrania zespołu lub spotkania z klientem,
• pisanie maila z podsumowaniem ustaleń (minutes, summary, follow-up),
• przekazywanie dalej poleceń, próśb i uwag szefa,
• streszczanie maili od klienta innym osobom w firmie,
• raportowanie w języku angielskim, co kto obiecał, zastrzegł lub odmówił.

Za każdym razem, gdy mówisz po angielsku coś w stylu „Szef powiedział, że…”, „Klient pytał, czy…”, „Ona prosiła, żeby…”, korzystasz z reported speech – nawet jeśli nie nazywasz tego po imieniu. Świadome opanowanie tej struktury pozwala brzmieć precyzyjnie i profesjonalnie.

Różnica między cytowaniem a parafrazowaniem

W relacjonowaniu wypowiedzi masz dwie główne opcje:

• Direct speech (mowa niezależna) – cytujesz czyjeś słowa dokładnie:
  
  The manager said, “We need to reduce costs.”
• Reported speech (mowa zależna) – przekazujesz sens wypowiedzi:
  
  The manager said (that) we needed to reduce costs.

Mowa niezależna bywa potrzebna, gdy liczą się dokładne słowa: w cytowaniu skargi klienta, przy przytaczaniu fragmentu umowy czy dokładnego sformułowania, które może mieć znaczenie prawne lub wizerunkowe. W większości biurowych sytuacji ważniejszy jest jednak sens, nie każde słowo, dlatego dominuje reported speech.

Kiedy przytaczać słowa dosłownie, a kiedy wystarczy sens

Praktyczna zasada: im wrażliwsza wypowiedź, tym większy sens ma cytat. Im bardziej dotyczy ona czynności i ustaleń, tym lepiej sprawdza się mowa zależna.

• Lepiej cytować dosłownie, gdy:
  • klient użył mocnych słów („This is unacceptable…”),
  • przekazujesz czyjś kontrowersyjny komentarz,
  • cytujesz zapis z umowy, regulaminu, oferty.
• Wystarczy sens, gdy:
  • przekazujesz decyzje: He said (that) we would change the deadline.
  • opisujesz prośby lub zadania: She asked me to send the report.
  • streścisz maila: They wrote that they needed more details.

Raportując ustalenia, zwykle nie ma czasu ani potrzeby cytować każdej wypowiedzi. Liczy się, żeby jasno przekazać: kto co powiedział, co ustalono, jakie są terminy i odpowiedzialności.

Krótki przykład: mini-spotkanie projektowe

Wyobraźmy sobie 10‑minutowe spotkanie projektowe w poniedziałek rano. Podczas daily stand-upu padają wypowiedzi:

• „I’ll prepare the draft by Wednesday.”
• „We need feedback from the client this week.”
• „Can you send me the updated figures today?”

Twój przełożony nie był obecny i pyta, co ustalono. Możesz zrelacjonować:

• Anna said (that) she would prepare the draft by Wednesday.
• Tom mentioned (that) we needed feedback from the client this week.
• He asked me to send him the updated figures today.

Nie cytujesz dokładnych słów, ale przekazujesz informację, kto się czego podjął i jakie są oczekiwania. To właśnie praktyczne użycie reported speech w biznesie.

Co sprawdzić po tej sekcji

• Krok 1: wypisz 3 sytuacje z ostatniego tygodnia, gdy przekazywałeś dalej czyjeś słowa (po polsku).
• Krok 2: zaznacz, które z nich dotyczyły zebrań, a które maili.
• Krok 3: przy każdej sytuacji dopisz po angielsku krótki wstęp typu He said that… / She asked if… / They told us that….

Jeśli potrafisz wskazać co najmniej 2 konkretne zadania, w których przyda ci się mowa zależna w mailach lub rozmowach, znasz już realny kontekst, w którym warto nad nią pracować.

Podstawowy schemat reported speech – pierwszy krok

Krok 1: dobór czasownika wprowadzającego

Reported speech zawsze zaczyna się od czasownika, który mówi, jak relacjonujesz wypowiedź. Najczęstsze w pracy to:

• say – ogólne „powiedzieć”:
  
  He said that…
• tell (sb) – „powiedzieć komuś”:
  
  She told me that…
• ask – pytać, prosić:
  
  They asked if… / He asked me to…
• explain – wyjaśnić:
  
  He explained that…
• mention – wspomnieć:
  
  She mentioned that…
• promise – obiecać:
  
  He promised that… / He promised to…

Przy tell niemal zawsze potrzebny jest odbiorca: tell me, tell us, tell them, tell the team. Przy say odbiorca występuje rzadziej i zwykle z „to”: He said to me that…, ale w praktyce biznesowej wygodniej używać He told me that….

Krok 2: konstrukcja zdania – prosty wzór

Najprostszy wzór zdania oznajmującego w reported speech to:

Osoba + czasownik wprowadzający + (that) + zdanie.

Przykłady bez zmiany czasów (czasowniki w czasie Present Simple dla bieżących, świeżych relacji):

• He says (that) he is busy. – Mówi, że jest zajęty.
• She tells me (that) she needs more time. – Mówi mi, że potrzebuje więcej czasu.
• They explain (that) the project is behind schedule. – Wyjaśniają, że projekt jest opóźniony.

Przy relacjonowaniu po czasie częściej użyjesz Past Simple:

• He said (that) he was busy.
• She told me (that) she needed more time.
• They explained (that) the project was behind schedule.

Na tym etapie kluczowe jest zbudowanie nawyku: zawsze zaczynaj od osoby + czasownika wprowadzającego. Nie skacz od razu do „że…”.

Krok 3: kiedy można pominąć „that”

Słowo that w reported speech łączy część wprowadzającą z resztą zdania. W mowie potocznej często się je pomija, zwłaszcza po say i tell, ale w tekstach formalnych (raporty, maile służbowe) bywa bardzo przydatne, bo porządkuje długie zdanie.

• Możesz pominąć „that”, gdy:
  • zdanie jest krótkie i proste:
    
    He said he was tired.
  • wypowiedź jest ustna, nieformalna:
    
    She told me she’d be late.
• Lepiej zostawić „that”, gdy:
  • zdanie jest dłuższe:
    
    He said that he would send the updated report by Friday at the latest.
  • piszesz formalnego maila lub raport:
    
    They explained that the delay was caused by unexpected technical issues.

Dla osób uczących się wygodniejsze jest niepomijanie „that” na początku – zmniejsza to ryzyko błędów i pomaga pilnować struktury zdania.

Proste pary zdań: direct speech → reported speech (bez zmiany czasu)

Na początek warto poćwiczyć same konstrukcje, jeszcze bez cofania czasów. Przykłady z życia biurowego:

• „I’m busy today.” → He says (that) he is busy today.
• „We need more information.” → They say (that) they need more information.
• „The system is down.” → She explains (that) the system is down.
• „You’re doing a great job.” → He tells me (that) I’m doing a great job.

Kiedy opowiadasz o wypowiedzi chwilę po niej, wciąż możesz użyć czasów teraźniejszych w części zależnej, jeśli informacja jest aktualna. Cofanie czasów (backshifting) przyda się szczególnie wtedy, gdy raportujesz po dłuższym czasie albo gdy informacja nie jest już aktualna – do tego wrócimy później.

Co sprawdzić po tej sekcji

• Krok 1: wypisz 3 zdania, których często używasz w raportach lub podsumowaniach, np. „Szef powiedział, że…”, „Klient napisał, że…”, „Ona wyjaśniła, że…”.
• Krok 2: przetłumacz każdy w prostym schemacie:
  
  My boss said (that)… / The client wrote (that)… / She explained (that)…
• Krok 3: sprawdź, czy w każdym zdaniu masz:
  
  osobę + czasownik wprowadzający + (that) + resztę zdania.

Zmiana zaimków, określeń czasu i miejsca – małe słowa, duża różnica

Zasada „kto mówi, komu i o kim” – zmiana zaimków osobowych

Przy reported speech wiele osób skupia się na czasach, a gubi zaimki. Tymczasem to one decydują, czy zdanie ma sens. Kluczowa zasada: zmieniasz perspektywę z mówiącego na relacjonującego.

Przykład: na spotkaniu Ania mówi:

„I will send you the file.”

Ty relacjonujesz to szefowi:

• Nie: She said that I would send me the file.
• Poprawnie: She said that she would send me the file.

Zaimki zmieniają się w zależności od tego, kto teraz opowiada:

• I → he/she (gdy mówisz o kimś innym),
• you → I/we/they (zależnie od tego, kogo dotyczy),
• we → they/we (czasem zostaje „we”, jeśli jesteś częścią tej grupy),
• my/your/our też się przestawiają: my → his/her itd.

Krok 1: zawsze ustal trzy elementy:

1. Kto mówił w oryginale?
2. Komu to mówił?
3. Kto teraz relacjonuje?

Dopiero wtedy dobierz właściwe zaimki. Bez tego łatwo powiedzieć zdanie, które formalnie jest „po angielsku”, ale znaczeniowo nie trzyma się kupy.

Najczęstsze przesunięcia: today, yesterday, last week, here

Przy relacjonowaniu po czasie trzeba często zmienić też określenia czasu i miejsca. Typowe przesunięcia:

Przykłady biurowe:

• „We are sending the report today.” →
  
  They said that they were sending the report that day.
• „We had a meeting here yesterday.” →
  
  She said that they had had a meeting there the previous day.

Jeśli raportujesz bardzo szybko po wydarzeniu i z tej samej perspektywy czasowej, możesz zostawić oryginalne określenia, szczególnie w mowie:

• He just said that he is leaving tomorrow.
• She says she will finish the report today.

Kiedy jednak sporządzasz podsumowanie po spotkaniu lub wysyłasz maila po kilku godzinach czy dniach, bezpieczniej jest przesunąć czasowniki i te małe słowa typu today, yesterday, here. Dzięki temu odbiorca rozumie, kiedy coś miało miejsce, z jego perspektywy, a nie z perspektywy chwili wypowiedzi.

Co sprawdzić po tej sekcji

• Krok 1: zapisz 3–4 zdania z prawdziwych maili lub notatek, w których pojawia się today, yesterday, next week, here, this report.
• Krok 2: przerób je na reported speech tak, jakbyś pisał podsumowanie następnego dnia.
• Krok 3: sprawdź:
  • czy zmieniłeś zaimki zgodnie z zasadą „kto mówi, komu i o kim”,
  • czy przesunąłeś małe słowa czasu i miejsca (today → that day, here → there itd.).

Jeśli taki schemat przećwiczysz na kilku własnych przykładach z codziennych zebrań i korespondencji, reported speech przestaje być zestawem szkolnych reguł, a staje się wygodnym narzędziem: szybciej piszesz podsumowania, precyzyjniej przekazujesz ustalenia i unikasz nieporozumień między zespołami.

Backshifting czasów – kiedy trzeba „cofnąć” czas, a kiedy nie

Przy raportowaniu wypowiedzi po czasie pojawia się kolejne wyzwanie: czy zmieniać czas gramatyczny w części zależnej? W wielu sytuacjach – tak. W niektórych – absolutnie nie, bo zmiana czasu zmieniłaby sens informacji.

Podstawowy schemat zmiany czasów po „said / told / explained”

Najpierw schemat „szkolny”, ale bardzo przydatny w raportach i notatkach ze spotkań. Gdy czasownik wprowadzający jest w czasie Past Simple (np. said, told, explained, asked), czas w zdaniu zależnym zwykle cofa się o jeden „stopień” w przeszłość:

Typowy scenariusz biurowy: podsumowanie po spotkaniu, wysyłane jeszcze tego samego dnia albo następnego. Wtedy backshifting jest naturalny.

• „We are waiting for the client’s feedback.” →
  
  They said that they were waiting for the client’s feedback.
• „We signed the contract yesterday.” →
  
  She said that they had signed the contract the day before.

Kiedy NIE cofać czasu – informacje wciąż aktualne

W komunikacji biznesowej często trzeba podkreślić, że coś nadal jest prawdą. Wtedy możesz zostawić czas teraźniejszy mimo czasownika wprowadzającego w przeszłości.

• „The office is in London.” →
  
  He said that the office is in London. (biuro nadal tam jest)
• „The system is down.” – mówione 2 minuty temu →
  
  He just said that the system is still down.
• „We meet every Monday.” →
  
  She mentioned that they meet every Monday. (nawyk, harmonogram)

Kiedy przygotowujesz podsumowanie na koniec dnia, wiele faktów jest wciąż aktualnych. W takich zdaniach zostawienie Present Simple albo Present Continuous bywa wręcz czytelniejsze:

• John said that he is still waiting for the invoice.
• Maria mentioned that the client is not responding to emails.

Praktyczna wskazówka: jeśli zmiana czasu na przeszły sugerowałaby, że coś jest już nieaktualne, a ty chcesz pokazać, że to wciąż prawda – nie cofaj czasu.

Czas Past Perfect – kiedy wystarczy, a kiedy jest przesadą

Past Perfect (had + III forma) służy głównie do pokazania, że jedno wydarzenie było wcześniejsze niż inne zdarzenie w przeszłości. W raportach:

• „We signed the contract on Monday and sent the documents on Tuesday.” →
  
  He said that they had signed the contract on Monday and (had) sent the documents on Tuesday.
• „We finished the tests before the release.” →
  
  They explained that they had finished the tests before the release.

Past Perfect jest szczególnie przydatny, gdy opowiadasz o dwóch różnych punktach w przeszłości (dzień spotkania i wcześniejsze działania). W prostych zdaniach często brzmi dość formalnie, ale w raportach projektowych bywa bardzo klarowny.

Co sprawdzić po tej sekcji

• Krok 1: znajdź w swoich notatkach 3–4 zdania, które zaczynają się od: „On powiedział, że…”, „Oni wyjaśnili, że…”, „Klient poinformował, że…”.
• Krok 2: przerób je na angielski ze schematem backshiftingu (Present → Past, Past → Past Perfect itd.).
• Krok 3: zastanów się przy każdym zdaniu: czy informacja jest nadal aktualna? Jeśli tak, zapisz też wersję bez cofania czasu i porównaj znaczenie.

Reported speech z czasownikami opisującymi postawę i reakcje

W raportach ze spotkań często nie wystarczy napisać, co ktoś powiedział. Trzeba też oddać nastawienie, np. że ktoś się zgodził, sprzeciwił, zaproponował kompromis. Wtedy przydają się czasowniki typu agree, promise, refuse, offer, suggest.

Agree, refuse, promise – krótkie struktury bez „that”

Niektóre czasowniki naturalnie łączą się z bezokolicznikiem (to do) zamiast z „that”:

• agree to do something – zgodzić się coś zrobić
• refuse to do something – odmówić zrobienia czegoś
• promise to do something – obiecać coś zrobić
• offer to do something – zaoferować zrobienie czegoś

Przykłady ze spotkań:

• „I’ll prepare the slides.” →
  
  He agreed to prepare the slides.
• „I won’t sign this contract.” →
  
  She refused to sign the contract.
• „I’ll call the client today.” →
  
  He promised to call the client that day.
• „I can help with the migration.” →
  
  She offered to help with the migration.

Taka forma jest wyjątkowo zwięzła i świetnie pasuje do notatek ze spotkań, w których wyliczasz, kto co zadeklarował.

Suggest, recommend – gerund, a nie bezokolicznik

Inna grupa to czasowniki, po których zwykle pojawia się forma z -ing (gerund):

• suggest doing something – zasugerować zrobienie czegoś
• recommend doing something – rekomendować zrobienie czegoś

Typowe błędy to wstawianie po nich bezokolicznika z „to” (suggest to do) – lepiej tego unikać.

• „Let’s move the deadline.” →
  
  He suggested moving the deadline.
• „You should check the figures again.” →
  
  She recommended checking the figures again.

Gdy chcesz dodać, komu coś zasugerowano, masz kilka opcji:

• She suggested that we should review the budget.
• She suggested reviewing the budget.

W notatkach projektowych najczęściej wystarczy druga, krótsza wersja.

Informowanie o czyjejś opinii: think, believe, admit

Przy przekazywaniu, co ktoś sądzi lub przyznaje, użyjesz konstrukcji z „that”:

• think that… – uważać, że…
• believe that… – wierzyć, uważać, że…
• admit that… – przyznać, że…

Przykłady:

• „This solution is too expensive.” →
  
  They thought that the solution was too expensive.
• „We didn’t test this scenario.” →
  
  He admitted that they hadn’t tested that scenario.
• „Our communication is not clear enough.” →
  
  She admitted that their communication was not clear enough.

Takie czasowniki dobrze oddają ton spotkania: czy ktoś był przekonany, zaniepokojony, czy raczej przyznał się do błędu.

Co sprawdzić po tej sekcji

• Krok 1: przejrzyj ostatnie podsumowanie ze spotkania i zaznacz tam, gdzie pisałeś po polsku: „zgodził się, że…”, „odmówił…”, „zasugerował…”, „przyznał, że…”.
• Krok 2: zapisz po 1–2 angielskie zdania z agree to, refuse to, promise to, offer to, suggest -ing, admit that.
• Krok 3: sprawdź, czy:
  • po agree/refuse/promise/offer użyłeś formy to + bezokolicznik,
  • po suggest/recommend nie wstawiłeś błędnego to do, tylko formę z -ing lub that.

Reported speech w pytaniach – jak raportować „kto o co pytał”

Pytania w reported speech wyglądają inaczej niż zwykłe zdania oznajmujące. W mailach i notatkach rzadko przepisujesz pytanie dokładnie tak, jak padło – częściej zapisujesz, kto o coś pytał i jaka była treść pytania.

Pytania typu „yes/no” – if / whether

Jeśli oryginalne pytanie można było zrozumieć jako „tak/nie”, w reported speech użyjesz if lub whether. Szyk zdania wraca do układu oznajmującego (bez inwersji).

• „Do you need any help?” →
  
  He asked if I needed any help.
• „Have you finished the report?” →
  
  She asked whether we had finished the report.
• „Will the client join the call?” →
  
  They asked if the client would join the call.

Typowe błędy:

• *He asked me if did I need any help. – błędna inwersja (kolejność jak w pytaniu).
• *She asked me do I want to join. – brak „if / whether” i zły szyk.

Prosty schemat:

1. czasownik wprowadzający: He asked / She wanted to know,
2. if / whether,
3. osoba + czasownik (w normalnym szyku oznajmującym, z backshiftingiem, jeśli trzeba).

Pytania szczegółowe – question words (who, what, why, how)

Gdy oryginalne pytanie zaczyna się od who, what, when, where, why, how, w reported speech używasz tego samego słowa, ale znowu rezygnujesz z szyku pytającego.

• „Where are you working now?” →
  
  She asked where I was working then.
• „Why did they change the deadline?” →
  
  He asked why they had changed the deadline.
• „How much will it cost?” →
  
  They asked how much it would cost.

Kluczowa różnica: w reported speech po słowie pytającym stosujesz zwykły szyk zdania oznajmującego, bez przestawiania orzeczenia przed podmiot.

• Nie: *She asked where was I working.
• Tak: She asked where I was working.

Raportowanie pytań w podsumowaniu mailowym

W podsumowaniach po spotkaniach przydatna bywa forma, która od razu pokazuje, kto zadawał pytania:

• John asked if the budget was final.
• Anna wanted to know when we would receive the specifications.
• The client asked why the release had been postponed.

Jeśli chcesz wyróżnić najważniejsze pytania w notatkach, możesz nawet zebrać je w punktach:

• John asked whether the budget was final.
• Maria asked what the main risks were.
• The client asked how we would handle the migration.

Co sprawdzić po tej sekcji

• Krok 1: wypisz 4–5 pytań, które naprawdę padły na ostatnim spotkaniu (po polsku lub po angielsku).
• Krok 2: przerób każde na reported speech w dwóch wersjach:
  • z imieniem: John asked if…,
  • w wersji ogólnej: They asked if… / Someone asked why….
• Krok 3: upewnij się, że:
  • po if / whether nie ma szyku pytającego (bez: *if did we…),
  • po who / what / why / how używasz szyku oznajmującego (why they changed, a nie *why did they change),
  • czas cofnięty jest o jeden „krok”, jeśli pytanie jest w czasie przeszłym względem chwili raportowania.

Dobry test: przeczytaj swoje zdanie na głos. Jeśli po if / whether / why / how brzmi jak normalne zdanie oznajmujące, idziesz w dobrą stronę.

Gdy te schematy wejdą w nawyk, robienie notatek po angielsku po każdym spotkaniu stanie się dużo prostsze: zamiast zastanawiać się nad gramatyką, skupisz się na treści i priorytetach, a język „zrobi się” niejako przy okazji.

Reported speech w mailach – jak porządkować informacje z korespondencji

W mailach rzadko cytujesz kogoś słowo w słowo. Częściej streszczasz w jednym zdaniu, co ktoś napisał, poprosił albo obiecał. Reported speech jest tu idealnym narzędziem.

„He said in his email that…” – proste raportowanie treści wiadomości

Najprostszy sposób na przekazanie treści maila to połączenie czasownika raportującego z dodatkiem in his/her email albo in their message.

• „We will deploy on Friday.” (mail od klienta) →
  
  The client said in his email that they would deploy on Friday.
• „I’m on sick leave this week.” →
  
  Anna wrote that she was on sick leave that week.
• „I can join the call tomorrow.” →
  
  John mentioned in his message that he could join the call the next day.

Gdy piszesz dłużej o jednym wątku mailowym, możesz skrócić konstrukcję i pominąć „in his email”, jeśli kontekst jest jasny:

• He wrote that they needed more time.
• She said that the requirements were still not final.

Typowy błąd to zostawianie czasu teraźniejszego przy raportowaniu dawnej wiadomości:

• *He wrote that they need more time. – jeśli raportujesz to później, lepiej:
  
  He wrote that they needed more time.

Prośby i polecenia z maili – ask/tell + to + bezokolicznik

W korespondencji służbowej wiele zdań to prośby albo polecenia. W reported speech często sprowadzisz je do konstrukcji ask/tell someone to do something.

Typowe przekształcenia:

• „Could you send the draft by Thursday?” →
  
  He asked me to send the draft by Thursday.
• „Please update the presentation.” →
  
  She told me to update the presentation.
• „Don’t share this outside the team.” →
  
  He told us not to share it outside the team.

Krok po kroku:

1. Znajdź w mailu prośbę / polecenie (często zaczynają się od could you…, please…).
2. W reported speech użyj: asked (me) to… lub told (us) to….
3. Przy zakazach dodaj not to przed czasownikiem (told us not to share).

W notatkach po zebraniu maili od klienta taka forma pozwala szybko wypunktować oczekiwania:

• The client asked us to prepare a demo version.
• They told us not to change the current scope.

Podsumowywanie wątków mailowych jednym zdaniem

Przy dłuższych dyskusjach mailowych przydaje się zdanie, które zbiera kilka wypowiedzi naraz. Używaj wtedy takich czasowników jak explain, clarify, confirm, insist.

• „We need a signed NDA before we share the data.” (kilka maili) →
  
  The client explained that they needed a signed NDA before they shared the data.
• „The go-live date will not change.” (powtarzane kilka razy) →
  
  They insisted that the go-live date would not change.
• „Yes, the budget is still valid.” →
  
  She confirmed that the budget was still valid.

Co sprawdzić:

• Czy przy prośbach używasz ask/tell someone to do, a nie formy z „that”.
• Czy przy zakazach pamiętasz o not to (nie: *told us to not share w notatkach formalnych).
• Czy nie mieszasz teraźniejszości i przeszłości w jednym zdaniu raportującym starą korespondencję.

Reported speech w notatkach ze spotkań – jak skracać bez utraty sensu

Ręczne przepisywanie pełnych zdań zabiera czas. Łatwiej pracuje się z notatkami, gdy każde zdanie jest krótkie, ale nadal pokazuje, kto co powiedział, zapytał lub obiecał.

Stosowanie skrótów: said that → said, asked if → asked about

W nieformalnych notatkach wewnętrznych często możesz uprościć konstrukcję, skracając said that do said, a asked if/about do krótszych wersji, gdy treść jest oczywista.

• He said (that) the environment was not stable.
• They said (that) they would send the documents on Monday.
• John asked about the risks. (zamiast pełnego: asked what the main risks were, jeśli rozwiniesz to niżej)

Uwaga: skracaj tylko tam, gdzie that naprawdę nie jest potrzebne i nie prowadzi do niejasności. W tekstach formalnych (raport dla klienta, oficjalne minutes) lepiej zostawić pełną formę.

Łączenie kilku wypowiedzi w jeden punkt

Kiedy kilka osób mówi to samo, możesz je połączyć jednym czasownikiem raportującym. Ułatwia to czytanie i pokazuje, że była zgoda lub spór.

• „The deadline is too tight.” (John)
  
  „We won’t manage by Friday.” (Anna) →
  
  Several participants thought that the current deadline was not realistic.
• „I can stay longer.” (Tom)
  
  „I’ll help with testing.” (Sara) →
  
  Tom and Sara offered to support the team after hours.

Praktyczny schemat:

1. Zbierz wypowiedzi o tym samym temacie (deadline, budżet, scope).
2. Zastanów się, czy dominował jeden pogląd (zgoda) czy były rozbieżności.
3. Użyj czasownika agreed, disagreed, were concerned, were confident i ogólnego podmiotu: the team, several participants, some stakeholders.

Przykłady:

• The team agreed that the MVP should include only core features.
• Some participants were concerned that the timeline was too optimistic.

Rozróżnianie faktów od opinii w reported speech

W notatkach warto oddzielić to, co ktoś powiedział, od tego, co jest obiektywnym faktem. Pomagają w tym różne czasowniki raportujące.

• Fact: The current release date is 30 May.
• Reported opinion: They thought that the current release date was too late.

Dobre pary czasowników:

• stated that… – stwierdził, że… (brzmi bardziej formalnie, sugeruje oficjalne stanowisko),
• claimed that… – twierdził, że… (delikatnie sugeruje, że inni mogą się nie zgadzać),
• argued that… – argumentował, że… (pokazuje dyskusję),
• explained that… – wyjaśnił, że… (dobrze do porządkowania nieporozumień).

Przykłady z zebrań:

• The vendor claimed that the delays were caused by missing inputs.
• Anna explained that the team had already implemented the requested changes.
• John argued that a later release would reduce the risk.

Co sprawdzić:

• Czy w notatkach potrafisz wskazać, które zdania opisują fakty, a które opinie (po czasownikach: thought, believed, argued, claimed).
• Czy nie powielasz co zdanie said that, skoro możesz użyć dokładniejszego czasownika lub skrótu.

Reported speech w formie listy zadań i ustaleń

W praktyce biznesowej najbardziej użyteczne są takie notatki, które można szybko zamienić w listę zadań. Reported speech pomaga pokazać, kto zadeklarował wykonanie danego punktu i na jakich warunkach.

Od wypowiedzi do action item – prosty schemat

Wyobraź sobie fragment spotkania:

• „I’ll update the documentation.” (Anna)
• „We’ll contact the client tomorrow.” (sales)
• „Can you send me the test cases?” (QA lead)

Krok 1 – notatki z reported speech:

• Anna agreed to update the documentation.
• The sales team promised to contact the client the next day.
• The QA lead asked us to send him the test cases.

Krok 2 – lista zadań (skrót):

• Anna – update the documentation.
• Sales – contact the client (tomorrow).
• Dev team – send test cases to QA lead.

Reported speech może więc służyć jako „pomost” między surowym zapisem a zwięzłą listą action items.

Precyzowanie odpowiedzialności – who + verb

Na spotkaniach często pada ogólne „we should…”. W notatkach warto przekształcić je na zdania, gdzie jasno widać osobę lub zespół odpowiedzialny.

• „We should inform the client about this risk.” →
  
  They agreed that the project manager would inform the client about this risk.
• „We need to check the legal aspects.” →
  
  It was agreed that the legal team would check the legal aspects.

Przy formie bezosobowej it was agreed that… dobrze jest w tej samej linijce dodać, kto faktycznie ma coś zrobić:

• It was agreed that the technical lead would prepare a migration plan.

Typowe błędy:

• Zapisywanie samych ogólników: *It was discussed that… bez konkretu, co z tego wynika.
• Brak wykonawcy: *It was agreed that the presentation would be updated. – lepiej dodać: by Anna lub nazwać zespół.

Ustalanie warunków i zastrzeżeń

Często ustalenia mają warunki: „jeśli… to…”. W reported speech używaj zwykłych okresów warunkowych, tylko cofaj czasy.

• „If the client approves the design, we’ll start implementation next week.” →
  
  They said that if the client approved the design, they would start implementation the following week.
• „If there are no blockers, we can go live on Friday.” →
  
  It was agreed that if there were no blockers, they could go live on Friday.

W notatkach zadaniowych można to jeszcze uprościć, zachowując sedno:

• Go-live on Friday – if there are no blockers (agreed).

Co sprawdzić:

• Czy każde zadanie w notatkach ma „właściciela” (osobę / zespół) i czasownik w reported speech, który pokazuje, czy to była deklaracja, sugestia czy prośba.
• Czy przy ustaleniach warunkowych poprawnie cofasz czasownik po said/agreed, zostawiając logiczny związek „if… then…”.

Unikanie najczęstszych pułapek w reported speech

Przy pisaniu szybkich notatek łatwo o błędy, które później utrudniają zrozumienie ustaleń. Kilka wzorców pomaga je wyłapać i poprawić.

Mieszanie czasów – kiedy NIE cofać czasownika

Nie zawsze musisz stosować pełny backshifting. Gdy mówisz o czymś, co nadal jest prawdziwe w momencie raportowania, czas teraźniejszy może zostać.

• „The system is unstable.” (wciąż jest) →
  
  She said that the system is unstable. lub …was unstable.
• „We are in the middle of migration.” (wciąż w trakcie) →
  
  They said that they are in the middle of migration.

Konsekwencja jest ważniejsza niż „twarda” zasada. Jeśli w całym podsumowaniu używasz cofniętego czasu, trzymaj się tego stylu; jeśli podkreślasz aktualność, można zostawić teraźniejszość.

Natomiast przy czymś, co jest wyraźnie w przeszłości, cofnięcie jest konieczne:

• „We finished the tests yesterday.” →
  
  He said that they had finished the tests the day before.

Zaimki i „tu / tam / dziś / jutro” – drobne słowa, duże zamieszanie

Przy raportowaniu czyichś słów często trzeba zmienić małe, „niewinne” słowa, które odnoszą się do czasu i miejsca.

Krok 1 – zaimki osobowe:

• „I will send you the report.” →
  
  She said that she would send me the report.

Krok 2 – „tu / tam / dziś / jutro” i inne słowa zależne od kontekstu. Tu najczęściej pojawiają się błędy, bo podczas spotkania „tomorrow” i chwila po nim to już nie ten sam dzień.

• „I’ll call you tomorrow.” →
  
  He said that he would call me the next day.
• „We have a demo today.” →
  
  She mentioned that they had a demo that day.
• „Let’s discuss it here.” →
  
  They suggested discussing it there. (jeśli opowiadasz o rozmowie z innego miejsca)
• „We’ll send it this week.” →
  
  They said that they would send it that week.

W notatkach projektowych najlepiej od razu doprecyzować czas kalendarzowo. Zamiast ogólnego „the next day” możesz zapisać:

• He said that he would call me on Wednesday.
• They confirmed that they would send the offer by Friday.

Krok 3 – łączenie zmian: zaimki + czas + słowa czasu/miejsca. W praktyce w jednym zdaniu często zachodzi kilka modyfikacji naraz, więc dobrze jest rozpisać je sobie etapami.

• Krok 1: czas teraźniejszy → przeszły:
  
  „We are sending the file now.” →
  
  They said that they were sending the file now.
• Krok 2: „now” → „then”:
  
  They said that they were sending the file then.
• Krok 3: doprecyzowanie czasu (np. w mailu po spotkaniu):
  
  They said that they were sending the file at that moment.

W bardziej skomplikowanych wypowiedziach (np. z warunkami i prośbami) dobrym nawykiem jest krótkie zatrzymanie się i sprawdzenie każdego problematycznego słowa osobno: osoby mówiącej (I / we → he / she / they), miejsca (here / there) i czasu (today / that day, next week / the following week).

Co sprawdzić:

• Czy po zmianie zaimków zdanie nadal jasno pokazuje, kto co zrobi (unikaj sytuacji, gdy z we i you robi się nieczytelne „they” i „them” bez kontekstu).
• Czy słowa typu today, tomorrow, here, next week są aktualne z perspektywy dnia pisania notatek, a nie momentu wypowiedzi.
• Czy w ważnych ustaleniach (terminy, zobowiązania) nie zostawiłeś ogólników tomorrow / next week, jeśli da się podać konkretną datę.

Dobrze napisane reported speech sprawia, że po tygodniu czy miesiącu wciąż wiadomo, kto co powiedział, kto za co odpowiada i na jakich warunkach się umawialiście. Zamiast chaotycznych cytatów masz uporządkowany zapis, który można wkleić do maila, protokołu czy systemu zadań – i bez dodatkowych tłumaczeń wszyscy rozumieją go tak samo. Dzięki temu spotkania i maile zaczynają się przekładać na konkretne decyzje i działania, a nie tylko na długie wątki w historii czatu.

Reported speech w mailach podsumowujących – praktyczne schematy

Mail po spotkaniu często jest jedynym trwałym śladem ustaleń. Reported speech porządkuje ten chaos, ale trzeba trzymać się czytelnej struktury i odpowiednich czasowników raportujących.

Struktura maila: decyzje, ustalenia, otwarte tematy

Zamiast jednego długiego bloku tekstu lepiej rozdzielić treść na kilka mini‑sekcji. Każdą da się zbudować na bazie reported speech.

Krok 1 – decyzje (decisions):

• It was decided that the release would be moved to next Monday.
• They agreed that the beta version would be shared only with internal users.

Krok 2 – zadania (action items):

• Anna agreed to prepare the updated roadmap by Thursday.
• The dev team promised to fix the critical bugs before the next sprint planning.

Krok 3 – otwarte kwestie (open points):

• It was mentioned that the budget for Q4 was still unclear.
• They noted that the final go-live date had not been confirmed yet.

Takie pogrupowanie pomaga odbiorcy od razu zobaczyć, co jest pewne, co jest zadaniem, a co wymaga dalszej decyzji.

Co sprawdzić:

• Czy każde zdanie z decyzją ma czasownik typu decided / agreed / confirmed, a nie ogólne discussed.
• Czy zadania w reported speech da się łatwo przepisać do listy „kto–co–do kiedy”.
• Czy otwarte kwestie są wyraźnie zaznaczone, żeby nikt nie wziął ich za podjęte decyzje.

Dobór czasowników raportujących – nie tylko „said”

Używanie w kółko said rozmywa sens ustaleń. Lepiej dobrać czasownik do intencji mówiącego.

Kilka użytecznych grup:

• Decyzje / ustalenia: decided, agreed, confirmed, approved
• Prośby / zadania: asked, requested, instructed, told
• Obietnice / zobowiązania: promised, agreed to, committed to
• Informowanie / raportowanie: reported, informed, explained, mentioned, pointed out
• Sugestie / pomysły: suggested, recommended, proposed

Przykłady z maila podsumowującego:

• John suggested postponing the workshop by one week.
• Mary confirmed that the client had approved the new pricing.
• The support team reported that the incidents had decreased after the patch.
• The CTO committed to sharing the long-term roadmap by the end of the month.

Typowy błąd to neutralne said tam, gdzie grupa faktycznie coś ustaliła:

• *They said that the release would be on Friday. → brzmi jak luźna wypowiedź.
• They agreed that the release would be on Friday. → jasno pokazuje decyzję.

Co sprawdzić:

• Czy przy każdej decyzji używasz decided / agreed / confirmed, a nie said.
• Czy prośby mają czasowniki typu asked / requested, a nie bezosobowe „it was discussed”.
• Czy obietnice i deklaracje są oznaczone jako promised / committed, żeby później łatwiej egzekwować ustalenia.

Mocne vs. słabe sformułowania – jak nie przesadzić

W raportach po angielsku różnica między delikatną sugestią a twardą decyzją bywa subtelna, ale ma duże konsekwencje. Reported speech pozwala tę różnicę zachować.

Przykładowe pary:

• „We could use a different library.” →
  
  He suggested that they use a different library. (sugestia, nie obowiązek)
• „We must use a different library.” →
  
  He insisted that they use a different library. (silne naciskanie)
• „It would be good to involve QA earlier.” →
  
  She recommended involving QA earlier.
• „We will involve QA earlier.” →
  
  They decided to involve QA earlier.

Krok 1 – oceń ton wypowiedzi (sugestia / prośba / nakaz / deklaracja).

Krok 2 – dobierz czasownik:

• sugestia: suggested, proposed, recommended
• mocna opinia: insisted, stressed, emphasized
• nakaz / polecenie: told, instructed, ordered
• deklaracja: promised, committed, agreed to

Krok 3 – zadbaj o to, żeby zdanie w notatkach nie brzmiało „mocniej” niż oryginał. Ktoś, kto tylko „zasugerował”, nie powinien w raporcie „zdecydować”.

Co sprawdzić:

• Czy gdzie pojawiły się lekkie sugestie, nie używasz słów typu decided / insisted.
• Czy polecenia od przełożonych nie zostały opisane za słabo (np. jako suggested, jeśli faktycznie były to instrukcje).
• Czy osoba czytająca mail może z samych czasowników wywnioskować, co było obowiązkiem, a co luźnym pomysłem.

Reported speech w krótkich komunikatach na Slacku / Teams

Nie wszystkie ustalenia trafiają na formalne spotkania. Wątki na Slacku czy Teamsie też często trzeba streścić, zwłaszcza gdy nieobecna osoba pyta: „co ustaliliście?”.

Jak streścić długi wątek w 3–4 zdaniach

Długi czat można skondensować za pomocą kilku zdań w reported speech, bez cytowania każdej wypowiedzi. W praktyce pomaga prosty schemat.

Krok 1 – zidentyfikuj główne wątki (np. problem, decyzja, zadanie).

Krok 2 – po jednym zdaniu reported speech na każdy wątek:

• Tom explained that the current deployment process caused frequent rollbacks.
• They agreed that they would introduce a separate staging environment.
• Anna offered to prepare a draft of the new deployment checklist.

Krok 3 – dopisz terminy i właścicieli, jeśli w wątku się pojawiły:

• It was agreed that the new process would be tested during the next release on Thursday.

Takie 3–4 zdania w kanale zespołu często wystarczą, żeby ktoś po przerwie mógł „wskoczyć” z powrotem w kontekst.

Co sprawdzić:

• Czy nie cytujesz całych wypowiedzi, jeśli można je streścić jednym zdaniem.
• Czy każde główne ustalenie z długiego wątku ma swoje krótkie zdanie w reported speech.
• Czy kluczowe informacje (kto, co, do kiedy) nie zginęły przy skracaniu.

Od nieformalnego tonu do neutralnego raportu

Rozmowy w komunikatorach są kolokwialne, często z użyciem skrótów i emotikonów. W reported speech przenosisz je do neutralnego, „biurowego” angielskiego.

Przykłady transformacji:

• „I’ll ping the client” →
  
  He said that he would contact the client.
• „Let’s ship it and see what happens” →
  
  They suggested releasing it and monitoring the results.
• „I’m not happy with the current design tbh” →
  
  She mentioned that she was not satisfied with the current design.

Zamiast przenosić skróty i żargon, lepiej oddać sens: czy to była krytyka, luźna uwaga, czy konkretna decyzja?

Co sprawdzić:

• Czy nie kopiujesz slangowych słów wprost do raportu, jeśli da się je oddać neutralnie.
• Czy jasne jest, które wypowiedzi były poważnymi ustaleniami, a które tylko komentarzami „na marginesie”.
• Czy ktoś, kto nie zna stylu pisania zespołu, zrozumie tekst bez znajomości żargonu.

Raportowanie pytań, wątpliwości i ryzyk

W notatkach i mailach często trzeba odtworzyć nie tylko to, co ustalono, lecz także obawy i pytania. Reported speech dobrze się do tego nadaje, pod warunkiem poprawnego zapisu pytań pośrednich.

Jak raportować pytania i wątpliwości

W pytaniach zależnych znikają znaki zapytania i inwersja, ale zostaje sens pytania.

Przykłady:

• „When will the client sign the contract?” →
  
  They asked when the client would sign the contract.
• „Do we have enough capacity for this feature?” →
  
  She asked whether they had enough capacity for that feature.
• „Can we postpone the deadline?” →
  
  He wanted to know if they could postpone the deadline.

W notatkach ze spotkania:

• John asked whether the deadline could be moved by one week.
• Mary raised a question about the support coverage during the holidays.

Typowe błędy:

• zostawienie szyku pytającego: *She asked when will the client sign…
• zapomnienie o cofnięciu czasu: *They asked if we have enough capacity… (po czasie przeszłym powinno być had)

Co sprawdzić:

• Czy w raportowanych pytaniach nie pojawia się inwersja (will the client → the client would).
• Czy pytania typu do / does / did zostały przerobione na proste zdania z whether / if.
• Czy wątpliwości są zapisane tak, by uniknąć tonu oskarżycielskiego (np. raised a concern, a nie blamed).

Raportowanie ryzyk i zastrzeżeń

Przy ryzykach ważne jest oddanie tonu: czy ktoś tylko zauważył potencjalny problem, czy mocno ostrzegał. Odpowiednie czasowniki raportujące robią tu różnicę.

Przykłady:

• „There might be issues with performance.” →
  
  They pointed out that there might be issues with performance.
• „If we don’t test it properly, it will fail in production.” →
  
  She warned that if they did not test it properly, it would fail in production.
• „This deadline is very risky for the team.” →
  
  The team expressed concerns that the deadline was very risky.

W raportach z projektów warto też zaznaczyć, co dalej z ryzykiem:

• It was agreed that they would monitor the performance after the release.
• They decided to prepare a fallback plan in case of major issues.

Co sprawdzić:

• Czy używasz czasowników typu warned / expressed concerns / pointed out przy ważnych ryzykach.
• Czy do każdego kluczowego ryzyka dopisano choć jedno zdanie o planie działania.
• Czy raport nie łagodzi zbyt mocno poważnych ostrzeżeń (np. zamiana warned na neutralne said).

Łączenie reported speech z formami bezosobowymi

W raportach i protokołach często przeplatają się formy z podmiotem („John said…”) i bezosobowe („It was agreed that…”). Dobrze użyte, ułatwiają czytanie; źle – zaciemniają odpowiedzialność.

Kiedy użyć „it was decided / agreed / noted”

Formy bezosobowe sprawdzają się przy ustaleniach całej grupy albo tam, gdzie nie ma znaczenia, kto dokładnie coś powiedział.

Przykłady:

• It was decided that the pilot would start on March 1st.
• It was agreed that all changes would be documented in the changelog.
• It was noted that the current budget might not cover additional scope.

Warto po takim zdaniu dodać szczegóły, żeby wrócić do konkretnych osób:

• It was agreed that all changes would be documented in the changelog. The dev lead will be responsible for keeping it up to date.

Typowy błąd to nadużywanie bezosobowych form tam, gdzie trzeba wskazać osobę odpowiedzialną. Samo it was agreed nie mówi, kto realnie coś zrobi.

Co sprawdzić:

• Czy przy zdaniach typu it was decided dopisujesz w kolejnych zdaniach, kto wykona decyzję.
• Czy nie ukrywasz odpowiedzialności za pomocą wyłącznie bezosobowych konstrukcji.
• Czy masz równowagę między „głosem grupy” (it was decided) a konkretnymi nazwiskami / rolami.

Łączenie ujęcia ogólnego z konkretnymi osobami

Często potrzebne są zarówno ogólne, jak i szczegółowe informacje. Można to zapisać dwustopniowo.

Krok 1 – ogólne ustalenie:

• It was agreed that the onboarding process would be simplified.

Krok 2 – doprecyzowanie, kto co robi:

• HR said that they would prepare a new checklist for managers.
• The product lead mentioned that she would record a short intro video for new hires.

Krok 3 – dodaj terminy lub kryteria sukcesu, jeśli już padły:

• It was decided that the new process would be tested with the next two hires in May.

Takie połączenie jednego zdania ogólnego i dwóch–trzech zdań szczegółowych dobrze sprawdza się w protokołach ze spotkań zarządu, steering committee czy większych warsztatach. Najpierw informujesz „co w ogóle ustalono”, a dopiero potem rozwijasz, kto dokładnie zabrał głos i jakie wziął zadanie.

Uważaj na jeszcze jeden błąd: mieszanie ujęć w jednym zdaniu, np. *It was decided by John that…. Jeśli decyzja była indywidualna, napisz wprost: John decided that…. Jeśli grupowa – zostań przy formie bezosobowej i pokaż wykonawców w kolejnym zdaniu: It was decided that the pilot would start in June. Anna will coordinate the pilot on the vendor side.

W praktyce projektowej dobrze działa prosty szablon na każdy większy punkt: krok 1 – zdanie z it was decided / agreed / noted, krok 2 – jedno zdanie o odpowiedzialnych osobach, krok 3 – jedno zdanie o terminie albo kolejnym kroku (next steps). Trzy krótkie zdania potrafią zastąpić kilkanaście luźnych komentarzy z calla, które po tygodniu nikt już dokładnie nie pamięta.

Reported speech w mailach po spotkaniu

Mail po spotkaniu to jedno z najczęstszych miejsc, gdzie używasz reported speech. Klucz to połączenie: krótkie podsumowanie, jasne zadania, terminy – wszystko w poprawnej mowie zależnej.

Struktura maila z podsumowaniem ustaleń

Sprawdza się prosty, trzystopniowy układ.

Krok 1 – krótki kontekst:

• Yesterday we discussed the launch plan for the new feature.
• The meeting focused on the remaining blockers and the release date.

Krok 2 – kluczowe ustalenia w reported speech:

• John said that the backend team would finalize the API by next Wednesday.
• Anna mentioned that marketing would need at least two weeks to prepare the campaign.
• It was agreed that the go-live date would be moved to the first week of June.

Krok 3 – zadania i odpowiedzialności (często w formie punktów):

• Tom confirmed that he would prepare the updated timeline by Friday.
• Sarah said that she would share the first draft of the release notes by Monday EOD.

Zauważ, że nawet przy zadaniach możesz użyć reported speech – podkreślasz wtedy, że ktoś sam się zobowiązał, a nie dostał zadanie „z góry”.

Typowy błąd to mieszać style w jednym akapicie: najpierw „we will do it”, zaraz potem „it was agreed that…”. Lepiej w jednej części maila trzymać się spójnie form reported speech, a dopiero w końcowej sekcji zadań przejść do trybu bezpośredniego (Action items) jeśli zespół tak woli.

Co sprawdzić:

• Czy każde ważne ustalenie ma osobne, krótkie zdanie w reported speech.
• Czy w jednym akapicie nie mieszasz chaotycznie we will i it was agreed that bez wyraźnego powodu.
• Czy z maila da się odczytać: kto co powiedział, co przyjęto jako decyzję i kto ma wykonać kolejne kroki.

Neutralne raportowanie sporów i rozbieżności

W mailach po trudnych spotkaniach trzeba oddać różne stanowiska, nie brzmiąc jak adwokat jednej strony. Reported speech pomaga oddzielić fakty od emocji.

Krok 1 – pokaż, że były różne opinie:

• Some participants argued that the current deadline was still achievable.
• Others pointed out that the team might not have enough capacity to deliver all items.

Krok 2 – opisz konkretne stanowiska, bez interpretowania:

• John stated that the scope should remain unchanged to meet the client’s expectations.
• Maria suggested that they should remove two lower-priority items from the current sprint.

Krok 3 – pokaż, do czego ostatecznie doszli:

• In the end, it was decided that two backlog items would be moved to the next release.

Zwróć uwagę na czasowniki: stated, suggested, argued, pointed out opisują ton bez wartościowania. Unikaj słów typu complained, attacked, accused w raportach z pracy – zostaw je dla cytatów bezpośrednich w rozmowach, jeśli już.

Co sprawdzić:

• Czy opisujesz stanowiska stron za pomocą neutralnych czasowników raportujących.
• Czy nie dopisujesz interpretacji do cudzych wypowiedzi (np. He unfairly claimed that… zamiast prostego He claimed that…).
• Czy jasno wynika, która opinia została przyjęta jako wspólne ustalenie.

Reported speech w skrótowych notatkach ze spotkań

Nie każde spotkanie wymaga długiego protokołu. Często masz jedynie krótkie notatki dla zespołu lub dla siebie. Nawet wtedy warto trzymać się kilku prostych wzorców reported speech.

Minimalistyczne notatki: wzorzec trzech linijek

Przy krótkich callach dobrze działa powtarzalny schemat.

Krok 1 – temat:

• Topic: Q3 roadmap and release priorities.

Krok 2 – kluczowe wypowiedzi w reported speech (maksymalnie 3–4 zdania):

• PM said that the client expected the reporting module in Q3.
• The dev lead mentioned that the integration would require at least four weeks.
• It was agreed that the analytics dashboard would be moved to Q4.

Krok 3 – kolejne kroki:

• PM said that she would share an updated roadmap with the client by Friday.

Takie notatki możesz później łatwo rozwinąć do pełnego maila, nie tracąc sensu wypowiedzi.

Co sprawdzić:

• Czy każde zdanie w notatkach to pełna myśl (bez skrótów typu John – API by Wed).
• Czy przy każdym it was agreed jest choć jedno zdanie who will do what.
• Czy po tygodniu da się z notatek zrozumieć decyzje bez zaglądania do nagrania.

Jak zapisywać „luźne” komentarze i pomysły

Podczas zebrań pojawiają się pomysły „na przyszłość”, które nie są decyzjami. Reported speech pozwala je odróżnić od ustaleń.

Przykład z warsztatu produktowego:

• Tom suggested that they could add a beta program for power users.
• Anna mentioned that it might be useful to run a short user survey.
• It was noted that these ideas would be considered after the MVP release.

Zwróć uwagę na czasowniki: suggested, mentioned jasno pokazują, że to nie decyzje. Gdyby pojawiła się decyzja, zmieniasz formę:

• It was agreed that they would run a user survey in September.

Co sprawdzić:

• Czy w notatkach odróżniasz suggested / mentioned od decided / agreed.
• Czy luźne pomysły nie są zapisane tak, jakby były zobowiązaniami.
• Czy przy pomysłach dopisujesz, co się z nimi stanie dalej (np. would be considered).

Przenoszenie dyskusji z e-maili do reported speech

Długie wątki mailowe trudno streścić tak, by były czytelne dla osób spoza dyskusji. Reported speech pomaga skondensować treść bez kopiowania całych wypowiedzi.

Streszczanie długich wątków mailowych

Krok 1 – określ główne punkty sporne lub tematyczne (bez cytowania):

• The discussion focused on the launch date, the legal review and the support model.

Krok 2 – podsumuj stanowiska stron w reported speech:

• The client said that they would prefer to launch before the end of the quarter.
• Legal mentioned that they would need at least two weeks to review the updated terms.
• The support team pointed out that they could not provide 24/7 coverage at this stage.

Krok 3 – pokaż finał wątku:

• In the end, it was agreed that the launch would take place in the first week of the next quarter.
• It was decided that legal would complete the review by the 15th, and support would provide extended business hours instead of 24/7 coverage.

Zauważ, że nie ma tu ani jednego pełnego cytatu z maila, a mimo to czytelnik widzi przebieg i wynik dyskusji.

Co sprawdzić:

• Czy raport zawiera stanowiska wszystkich istotnych stron, a nie tylko twoje.
• Czy nie wstawiasz zbyt wielu bezpośrednich cytatów – zwykle wystarczą 1–2 kluczowe.
• Czy informacja o finale wątku (co ustalono) jest wprost zapisana, a nie ukryta w środku akapitu.

Jak cytować fragmenty e-maili bez chaosu

Czasem potrzebny jest krótki cytat dosłowny, np. gdy liczy się dokładne brzmienie zastrzeżenia klienta. Wtedy łączysz direct speech i reported speech.

Przykłady:

• The client wrote that he was “not comfortable with the current level of reporting”.
• Legal mentioned that the clause on data retention was “too vague and potentially risky”.

Najpierw reportujesz ogólnie, a w cudzysłowie podajesz to, co ma znaczenie prawne lub biznesowe. Nie cytuj całego akapitu – wybierz jedno kluczowe sformułowanie.

Co sprawdzić:

• Czy cytujesz tylko to, co naprawdę wymaga dosłownego przytoczenia (np. ważne sformułowanie prawne).
• Czy przed cytatem jest jasne, kto to napisał lub powiedział.
• Czy cytaty nie dominują tekstu – główny szkielet powinien być w reported speech.

Zaawansowane zastosowania reported speech w pracy

Im wyższy poziom odpowiedzialności, tym częściej trzeba relacjonować cudze decyzje przed szerszym gronem. Wtedy reported speech łączy się z innymi strukturami, np. z pasywem, nominalizacją czy językiem dyplomatycznym.

Raportowanie decyzji przełożonych i zarządu

Gdy przekazujesz dalej decyzje „z góry”, ważne jest rozdzielenie: kto zdecydował, a kto tylko informuje. Reported speech tę różnicę podkreśla.

Przykłady:

• Management decided that the project would be paused until the budget was approved.
• The CFO said that there would be no additional headcount this quarter.
• It was announced that the company would introduce a new performance review process.

Kiedy piszesz mail do zespołu, możesz połączyć reported speech z jasnym komunikatem, co z tego wynika:

• The steering committee agreed that we would focus on the core markets. This means that we will stop pursuing new opportunities in region X for now.

Typowy błąd to pisać wszystko w formie „we decided”, nawet jeśli decyzja zapadła na wyższym szczeblu i zespół nie miał na nią wpływu. Jeśli chcesz być precyzyjny, pokazuj prawdziwy podmiot decyzji: management decided, the client requested, legal advised.

Co sprawdzić:

• Czy jasno wskazujesz, kto podjął decyzję (zarząd, klient, zespół, pojedyncza osoba).
• Czy nie przedstawiasz cudzych decyzji jako wspólnych, jeśli w rzeczywistości takie nie były.
• Czy po każdym zdaniu z reported speech dorzucasz, czego to wymaga od odbiorców (tam, gdzie to potrzebne).

Dyplomatyczne przekazywanie trudnych komunikatów

Przy niepopularnych decyzjach komunikacja bywa delikatna. Reported speech pozwala złagodzić przekaz, a jednocześnie zachować precyzję.

Przykłady z realnych sytuacji projektowych:

• The client indicated that they were not satisfied with the current level of documentation.
• Management mentioned that they expected the team to improve the release quality.
• The vendor acknowledged that there had been delays on their side.

Zamiast ostrych czasowników (complained, blamed, accused) używasz neutralniejszych: indicated, mentioned, stated, expressed concerns, acknowledged. Nadal przekazujesz problem, ale bez zaostrzania tonu.

Co sprawdzić:

• Czy przy trudnych komunikatach korzystasz z neutralnych czasowników raportujących.
• Czy nie „wygładzasz” tak mocno, że oryginalna treść traci ostrość (np. complained → slightly mentioned).
• Czy odbiorca zrozumie skalę problemu, nawet jeśli ton jest dyplomatyczny.

Łączenie reported speech z passivem i nominalizacją

W bardziej formalnych raportach i dokumentach projektowych reported speech bywa mieszane z szykiem pasywnym i rzeczownikami odczasownikowymi (nominalizacją), żeby brzmiało bardziej oficjalnie.

Przykłady transformacji:

• „We will not be able to deliver all items.” →
  
  It was communicated that not all items would be delivered in this release.
• „We should review the security procedures.” →
  
  It was recommended that the security procedures should be reviewed.
• „We need to improve our estimation process.” →
  
  There was a recommendation to improve the estimation process.

Takie ujęcie odsuwa uwagę od konkretnej osoby i przenosi ją na samą treść decyzji lub rekomendacji, co bywa przydatne w dokumentach dla szerokiego grona interesariuszy.

Co sprawdzić:

• Czy świadomie wybierasz formę: personalną (John said…) lub bezosobową (It was recommended that…), zamiast mieszać je przypadkowo.
• Czy nie przesadzasz z passivem – zbyt dużo it was… może utrudniać zrozumienie.
• Czy przy najważniejszych decyzjach nadal da się ustalić, kto był ich źródłem.