Довгі мітинги vs. Фокус уваги та пам’ять

Як довго можна зберігати фокус уваги? У кожного є своя межа, після якої потрібна пауза. Навіть у машин буває переповнення буфера, дані не встигають оброблятися. У людини теж трапляється подібне.

Інформацію треба подавати дозовано та послідовно, щоб вона створювала ясність, а не купу розрізнених шматків. Плюс у всіх різна точка старту, різні попередні знання з теми мітингу.

У ході довгого мітингу, у когось раніше, у когось пізніше, втрачається фокус уваги та здатність сприймати інформацію. «В одне вухо влетіло, в інше вилетіло».

Розтягнуті мітинги заважають у роботі. В одних випадках це мікроменеджмент, який забирає час. В інших випадках це довгий потік інформації, яку неможливо повноцінно засвоїти у такому темпі.

Наприкінці дзвінка, на питання «чи все зрозуміло?» ви можете отримати обережну відповідь «так» або мовчання. Коли ви, влаштував довгий дзвінок, отримуєте таку відповідь, то в перекладі правдивою та прагматичною мовою це запросто може означати таке:
«насправді ми всі вже втомилися і взагалі слабо розуміємо, і ще ми соромимося ставити питання, тому що є купа моментів, які ми розуміємо не до кінця, ми просто не хочемо переривати весь процес або розтягувати його на зайву годину, ми краще розберемося з цим пізніше».

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ех були ж часи колись
сидиш в охвісі, довгий мітинг, шось розказують... можна нічого не робити та ще й зп капає ))
а зарз сидиш дома і фігачиш

В одній конторі було що щось обговорювати треба 4-5 годин — фактично, повний день. Разів 10 так.
Рішення — графік перерв. 45 хвилин розмова — 15 перерва на все що треба. Рівно за графіком. Насильно зупиняти посеред промови, якщо інакше люди не розуміють.
З третього разу проблем вже не було, люди звикли.

було що щось обговорювати треба 4-5 годин — фактично, повний день

Це вже щось схоже на якийсь саботаж.

Ні, це або ніхто не розуміє що потрібно робити — або не керований процес. Умовно 4 різних керівника в одному і тому самому колективі, при чому їх повноваження не розподілені і перекликаються (при чому справжніх фінансові важелів керівництва нема в жодного, тобто крім психолігчного пресингу ніяких механізмів керування нема в усіх чотирьох). От і створюється наради на весь день, де ці 4 керівника з одного єдиного виконавця вимагають звітність по черзі, при чому не вирішуючи жодної його проблеми з нестачаю обладнання наприклад, скажімо для енвів — щоб розділити авто-тести і BA які своїми екперементами їх постійно ламають. Як то кажуть — «Двое пашут — семеро руками машут», класика Meting Driven Development-а.

Може, у вас так і було, але мій приклад не про такі жахи.

Ну спробуйте подумати і дослідити — якого біса у вас 4 години нарад ? Усього дві причини і буває. Або нема чітких цілей роботи чи навіть взагалі ніяких цілей, просто десь забілиними треба бути наприклад. Або недієва структура керування, яка не надає можливість досягнути цілей. Як базис порушений базовий принцип єдино-началля, відомий з древніх часів, коли армії і держави з цим принципом перемогли усі інші. І перше і друге веде до не бажання нікого, брати на себе відповідальність за результати що в решті призводить до постійних наради на які кличуть усіх підряд. Не одноразово вдавалось припиняти ті наради, після того як я казав «гаразд от тут така-то проблема і я це зроблю».

якого біса у вас 4 години нарад ?

Перегляд архітектури рішення, по великих компонентах.

Усього дві причини і буває.

Якщо у вас проблеми в керуванні, не треба думати, що вони такі у всіх.

Як базис порушений базовий принцип єдино-началля, відомий з древніх часів

Фантазії, фантазії...

Це не першопричина. Самі подумайте задля чого переглядати архітектуру ПЗ затвердженого проекту ? Тут два або. Це або — бізнес зріс і вимагає розвитку ПЗ задля його забеспечення. Скажімо Amazon 6 разів переробляв архітектуру, і 6 версія це те, що зараз знаємо як AWS та Micro-Service Design. Тоді кожна така переробка була окремо продуманим проектом, з затвердженим бюджетом строками, відповідальними особами і т.д. Друге або це — бізнес, тобто замовник сам не розуміє — а що він робить. Умовно замовив вантажний рікша велосипед на трех колесах, а виявилось — що треба конвеєрна лента. Так, утсорсу якщо чесно це насправді подобається — бо чим це довше і ще краще ще людей треба щоб закрити виявлений аврал, тим більше галера заробить. Так от швидше за усе у вас друге, інакше ви писали про корпоративну культуру Amazon там чи Google.

Самі подумайте задля чого переглядати архітектуру ПЗ затвердженого проекту ?

Я ж кажу — фантазії :)
Про «затвердженого», «переглядати»... стиглі рамки якоїсь рігідної методології, яка ніяк не збігається з іншими (навіть настільки ж рігідними;))

Так от швидше за усе у вас друге, інакше ви писали про корпоративну культуру Amazon там чи Google.

Я згадував стартап на ~20 розробників, який успішно побудував продукт, що прожив 5 років з нами і ще в дещо зміненому стані — ще 10 без нас.

Ви просто талант з використання довідника «стеля» :))

От прямо, а то я не працював в стартапі, навіть не в одному. Рігідні технології і т.д. То усе однаково кінчається, шалені овертайми до стану no life — а грошей кіт на плакав (у розробників). BTW Продукти які тоді стартували досі ще подаються. Затверджено це не про журнали обліків журналів, це про чіткі та ясні строки, наявні ресурси обладнання та бюджети. Тобто теорітичну можливість виконати заплановане в наявні строки та бюджет (і так це цікавить будь якого замовника чи інвестора, який за це платить гроші). Облік журналів та довідки про наявність довідки, це теж зазвичай про не бажання нізащо відповідати, а не про ефективність — тільки з іншої сторони. Просто замість пустих мітингів виписки, та спеціфікації специфікацій і сертифікати на сертифікат. Наради потрібні як і документи, та звісно воно може зайти занадто далеко і коли годину йде обговорення копіювання файлу, і коли на це треба написати 15 документів, та отримати 8 апрувів.

От прямо, а то я не працював в стартапі, навіть не в одному.

Схоже, у успішному і спокійному — майже ні. Слід залишився тільки од тих, де метушня, маячня і фінально закономірний крах.

То усе однаково кінчається, шалені овертайми до стану no life — а грошей кіт на плакав (у розробників).

Ага-ага.

Затверджено це не про журнали обліків журналів, це про чіткі та ясні строки, наявні ресурси обладнання та бюджети.

Саме так.

та звісно воно може зайти занадто далеко і коли годину йде обговорення копіювання файлу, і коли на це треба написати 15 документів, та отримати 8 апрувів.

Не зрозуміло, кому ви заперечуєте:)

От одразу крах, пишу же обидва живі здорові. І геймдев контора і продуктова. Продукт, що ми робили в продуктовій там зараз взагалі флагманський. Стахановство — це природа стартапу, так само як і співробітники віком до 25. Як тільки вони починають розуміти — що щось тут не так, світле майбутнє настає зовсім не у них в кращому випадку у засновників, йдуть далі на кращі умови, а на їх місце беруть нових випускників універів. Якщо ціль на роботі — заробити, а не працювати як не в себе на усіх спеціальностях одразу, то якраз і треба планування, проектування, розділення праці бізнес плани і т.д. А дурака робота любить. Система де усе роблять три людини працюючи по 12-14 годин на день, не надає гарантії результату. Крім того, що тих трех відверто лошать.

Це побудова планів на півроку-рік. Можна собі дозволити.

Це особливий випадок, тоді може бути оправдано, якщо такі мітинги 1-2 рази на рік.

Квартальне планування, чи там PI з SAFe який +/- те саме, це вже не нарада, це методолгія роботи. Хоча там такі самі проблеми бувають, бо до PI потрібно бути підготовленими, а не приходити туди не розуміючі а якого дідька ви взагалі робите і який результат від діяльності очікується (бачів таке декілька разів, за зо відповідальні заслужено отримала м’якого наганяя від реліз трейн інжененра). Такі 3 дні виделіні на планування та узгодження роботи колективів, потім рятують від місяцяв де кожень день по 4 години нарад, а то і по 6. PI особисто я не називав би нарадою, так само як і тренінги наприклад чи лекції в універі. Це просто різновид роботи. Та і там, має місце регламент, агенда, перерви і т.д.

З свого досвіду довгих мітингів на декілька питань, то зазвичай там:
— прямо в реалтаймі обговорювані речі тезово записувались десь на конфлюенсі
— зразу після мітингу організатор відправляв follow-up мейл з підсумками і to do до наступного разу, якщо це серія мітингів
Тобто при потребі до цього всього можна вернутись і пригадати. Якщо цього немає, то це пуста трата часу, але тоді питання до організатора мітингів, чи він розуміє взагалі, що і навіщо він робить?

питання до організатора мітингів, чи він розуміє взагалі, що і навіщо він робить

Вони просто звикли так працювати.

Мені здалося, що деякі люди звикли все вирішувати мітингами. Тобто, у них на будь-яку проблему перша думка — не «Треба подумати чи зробити research» а «Треба зробити мітинг».

Якщо задача — «розібрати карбюратор», а команда — це я і дві мої подружки (і ми всі троє не знаєм що таке карбюратор) то скільки не мітингуй — проблема не вирішиться.

В точку. P.S. Хоча повний інтеренет гайдів по зборці-розборці карбюраторів, та прочитати їх тобто взяти на себе відповідальність значно складніше ніж скликати нараду і покликати туди просто усіх, раптом хтось вміє розбирати карбюратори.

Це якраз мій PM)) Як тільки в нас зʼявляється питання до іншої команди, одразу пропонується мітинг — навіть якщо питання і відповідь на нього можна сформулювати парою речень)

Інша команда, тут якраз вірно. У іншої команди є свої цілі, свої задачі та свої строки. Що з рештою переростає в переговори, типу ти мені я тобі. Єдине що, можна іноді і без мітингів вирішити якоюсь банальною перепискою і т.п. Хороший у вас PM, є такі які просто скажуть вам розібратись з цим усим і доповісти про успішне виконання к такій-то годині, при цьому і вам і йому сусідня команда скаже підти в зад, бо в них і без того завантаження максимум чи просто проігнорує. Як на мене — хороший керівник вирішує проблеми, поганий лише створює.

Технічні деталі не вирішуються розмовами, які, ще й на додачу, ніхто не конспектує (а у нас мітинги — це просто поговорити, ніяких follow up після мітингу не буде, хто як зрозумів і що запамʼятав — незрозуміло). Тому, мітинги підійдуть для якихось загальних обговорень, а для технічних деталей письмова комунікація must have.
Бо в мене колись був такий прикол, коли колега сказав імплементувати фічу певним чином, а через місяць видав, що він такого не говорив — плавали, знаємо, повторень не хочу.
Ми навіть зі сторонніми сервісами чудово комунікуємо письмово (деякі з них взагалі надають перевагу тільки письмовій комунікації, а мітинги — тільки для чогось надзвичайного).
Тому, навіть для іншої команди чудово створюється тікет в Джирі і задаються питання в коментах, якщо щось незрозуміло. Якщо ж сусідня команда захоче послати в зад, то туди ж вона пошле й пропозицію провести мітинг — спираючись на брак часу, навантаження чи ще на щось.

які, ще й на додачу, ніхто не конспектує (а у нас мітинги — це просто поговорити, ніяких follow up після мітингу не буде, хто як зрозумів і що запамʼятав — незрозуміло).

І це головна принципова помилка. Я не агітую за усні наради з кожного приводу, але якщо щось суттєве обговорили, то зафіксувати письмово — обовʼязково. Коли різні сторони фіксують різне — теж узгодити. Ідеально — у вигляді документу, з яким всі згодні.

а для технічних деталей письмова комунікація must have.

Це інше питання. Звісно, чого нема на папері (навіть якщо папір це email чи wiki) — того нема, і вивіряти технічні деталі треба в самоті і тиші.

Тому, навіть для іншої команди чудово створюється тікет в Джирі і задаються питання в коментах, якщо щось незрозуміло.

Угу. Тільки краще б була не JIRA:) але то окреме питання.

вивіряти технічні деталі треба в самоті і тиші.

Супер-абсолютно супер-згоден.

Transcribe >> GPT Summarize

А в это время ты можешь делать другую работу

Якщо коротко то міти непотрібні. Весь час в роботу, якщо питання запитали, по ділу і далі працюєте. Міти локають усіх і у більшості випадків марна трата часу.

Але повино буте чітке тз, юзкейси, все прописано,розбито по таскам, та все що потрібно для виконання таски підготовленно, притому дизайнер сам знає що вам потрібен дизайн, бізнес аналіст що вам потрібно тз та юз кейси,та спілкується с замовником, тестер готовий тестувати, пм грамотно це все менеджерити та нікого не відволікати(хоча по суті і пм не потрібен, якщо все налаштувано добре).

Чим більший і довший у вас фокус та увага, тим більше ви отримуєте винагороду і там складніші проблеми можете вирвшувати, і краще і комфортніше жити!)

Найдовші мітинги, що у мене були, тривали десь по три — три з половиною години. Ми домовилися робити перерви, і все стало більш-менш нормально. Зараз буває що дві години підряд (два міта кожен може бути годину), але теж робим перерву.

Шо цікаво, в мене знайомий казав, що у них на проекті був експеримент по pair programming. Тобто, вони постійно кодили весь робочий день в парі.

Оце я б здохла! Мені НЕ проблема багато годин кодити, але паралельно з кимось розмовляти — я б видохлася за пару годин.

Через тиждень звикнеш. Хоча так навантаження зазвичай вище особливо для сініора в парі. Джуни та мідли з дуже великим шилом в сраці, вони бігом можуть як робити і корисні речі, бо молодої дурі багато — так і на робити великої каки, яку потім довго прийдеться розгрібати. У мене є аналогія — бігають дуже швидко, але зігзагами. Тому і перебігають з рештою пізніше, значно пізніше ніж могли би.

десь по три — три з половиною години

А коли їсти, до туалета ходити, тощо?

Отож ми і попросили перерви робити щогодини. Бо три підряд це жесть.

Зберігати фокус уваги на мітингах мені допомагає зарплата.
Чим вище зарплата, тим простіше це робити.

В компаніях рано чи пізно приходять до висновку, що довгі мітинги з порожньою балаканиною, коли сидять три інженери і п’ять менеджерів і передають один одному подушку спікера, намагаючись зробити світ краще — це гроші.
Це гроші за годину роботи всіх учасників мітингу, це дорого.

Є два типи спілкування, текстом і голосом.
Щоб запобігти ситуаціям, коли в одне вухо влетіло, в інше вилетіло, я надаю перевагу письмовому спілкуванню.
Щось важливе корисно формалізувати в текстовому вигляді (і для себе теж корисно) і запостити в чат команді на обговорення.
На мітингу обговорити якісь важливі речі буває просто неможливо через недостатній кворум.
Спілкування текстом економить час членів команди.

Звісно є теми, які краще обговорювати голосом.
Це просто два різні типи спілкування, у кожного є свої плюси і мінуси.

Як пережити довгі мітинги. Дуже допомагають в цьому 2 моменти:

— agenda
— meeting minutes

Перше дозволяє зрозуміти, в який час потрібно починати слухати. На бекграунді можна робити свою роботу і лише звірятися, чи не настав час слухати уважно.

Друге дозволяє компенсувати те, що раптово прослухав. Тезіси та рішення. В цілому, друге дозволяє взагалі слухати в пів-уха, хіба що запитають щось — тоді треба бути «присутнім», так.

Хоча якщо мова йдеться про постановку та обговорення задач, то треба більше писати прямо туди, де ведуться задачі/таски (Jira чи аналогічне) чи просто конспектувати. Під кінець зустрічі будуть ті самі meeting minutes, але написані не ініціатором мітінга, а тобою.

Так і виходе, що на ці мітинги збирають купу народу, відволікаючи їх від їх безпосередньої роботи — а результату не відбувається. Потім це усе переростає в купу безкоштовних овертаймів, далі скандали плинність кадрів чи втрата клієнта тощо. При чому в досвідчених людей одразу буде — далі, бо вже неодноразово у таке потрапляли. Тому IMHO будь який верхній керівник, який керує програмою чи портфелем якому не фіолетово — що з його бізнесом, мав би на це дивитись. Нажаль, зазвичай на це звертають увагу вже коли все вже усе погано.

Коли нарада занадто довга — а також їх занадто багато, то це насправді показник набагато більших проблем. Зокрема не бажання брати за себе відповідальність через : незрозумілі цілі роботи колективу і кожного особисто, або не зрозумілі методи їх досягнення, відсутність оцінки необхідних ресурсів та людей, або наявна їх відсутність ремурсів через брак бюджету або часу чи і того і іншого одночасно через невірну першочергово оцінку — іноді навмисно зроблену, щоб підписати контракта запропонувавши від початку не реальну ціну. Деколи це навіть свідома бізнес модель. Погана комунікація між підрозділами та суб підрядниками, внутрішня конкуренція, відсутність чітких розділень обов’язків чи компетенцій. Не витримування технології з виробництва, порушення процедур свідоме або через брак відповідних знань з рештою зрив строків через низку якість та переробки. Постійні зміни в цілях, умовно робили велосипеда з’ясувалось — що треба мотоцикла, потім паровоза з рештою — виходе вантажівка на квадратних колесах. Відсутність планування як такого і проектування як такого, більше за те брак відповідних знань з цих дисциплін, культ Карго.

Критична маса технічного боргу.

Технічний борг виник за яких причин?

Whatever. Коментар вище, наприклад. Перелічене там сприяє виникненню технічного боргу.

А конкретно на проєкті, де я зараз, — не знаю. Там таке вже давно, виникло ще задовго до мене.

Мені, напевно, треба писати більше слів, щоб дати чітко зрозуміти, що мое питання стосувалося саме твого проекта і твоєї ситуації, а не інформації в цілому :-)

Якщо ти ключова людина на цьому мітингу, тобі він потрібен щоб вирішити певну проблему то можна і 2 години бути зосередженим.

Якщо тебе це мало стосується, то за кілька хвилин увага буде на іншому вікні, телефоні і т.п.

Підписатись на коментарі