Комментарии 53
Отменил бы совещание.
Что бы ты изменил в процессе обсуждения, если бы был уверен, что твой собеседник забудет всё, о чём вы говорили?Для обсуждения использовал бы только текстовый обмен сообщениями, с сохранением истории переписки (практически любой современный мессенджер это может).
У нас удалённая команда, и если не все участники онлайн, то между некоторыми сообщениями бывает таймаут по часу. При таких паузах очень трудно восстанавливать контекст. День или два на обсуждение топика, для которого требовалось 30 минут.
Если «доклад» закончился и начались «вопросы из зала», то есть активная переписка, то кто-нибудь потеряет «тему» текущей беседы и может начать отвлекаться.
Или вдруг в том же чате начнётся второе обсуждение — такая каша получается.
Для себя в команде мы решили чаты (Slack) использовать для неформальных разговоров, для составления повесток встреч и резюме, для обмена кусками кода, ссылками, объявлений и прочих вещей, где напечатать проще, чем сказать.
Гораздо эффективнее решать вопросы во время конференции (онлайн или оффлайн). При этом участники более собраны, от темы можно постараться не отклоняться, долго разговор не затягивать, лишних участников не привлекать, всех присутствующих выслушать.
Автор поднял отличную тему. Замечаю сам по новичкам, что надеются на память. Вспоминаю себя таким же, но после пары проколов стал фиксировать.
если бы был уверен, что твой собеседник забудет всё, о чём вы говорили
Если хотите узнать мнение читателей этой статьи о конференции, в которой СОБЕСЕДНИКИ ЗАБУДУТ всё, о чём ОНИ говорили, то так и формулируйте вопрос!
Вы же хотите добиться однозначного взаимопонимания с вашими собеседниками, но при этом сами пишите одно, а судя по вашему ответному комментарию — подразумеваете совсем другое.
В таком случае вам ничего не поможет ни текстовый обмен, ни диктофоны, ни прочие ухищрения!
Я вам советую сначала научиться формулировать ваши высказывания, вопросы и т.п. так, чтобы ваши собеседники интерпретировали их также как и вы (ну или максимально близко к вашему пониманию).
Неосознанно.Да тут вашим собеседникам чтобы понять вас, кроме текста, голоса и видео надо еще и энцефалограмму вашего мозга записывать :)
… я мысленно представлял себе…
Мне кажется ...
А если без шуток и по теме, то не стоит вам употреблять такие слова, если вы действительно хотите однозначного понимания. Когда научитесь всегда четко излагать свои мысли и задавать вопросы/отвечать только по существу — большая часть ваших проблем эффективной коммуникации исчезнет сама собой, особенно если вы будете это делать культурно и вежливо.
Ну а диктофон и запись телефонных разговоров меня много раз спасало в разных жизненных ситуациях, и было полезным не только для работы. Если вы понимаете о чем я. ;)
Где-то встречал эволюционную цепочку организации дел:
- Я ничего не забываю, все в голове
- Файлики-имейлы-поститы
- Лайтовая тудушка вроде встроенной в айфон
- Хардкорная тудушка вроде OmniFocus (персональный) и JIRA, Asana и Trello (групповые).
Не знаю, на какой ступене был директор и его компания, но судя по тому, что услышал — на второй.
Вопрос памяти — это вопрос и психологии. Тот, кто не в состоянии ничего запомнить обычно не любит свою работу или устал от неё, но с другой стороны, такие люди обычно точно могут назвать то, к чему они неравнодушны.
На любое из этих утверждений можно ответить «с чего бы это вдруг?».
Есть, есть такая связь… а то что коммент был в "астрологическом" стиле — ну, так получилось, я не смотрел на него с такой точки зрения.:)
(https://en.wikipedia.org/wiki/Emotion_and_memory)
Но момент где и как вести не решена однозначно. Поделитесь, пожалуйста, своим опытом кто и как чем пользуется?
Со временем накапливается такой приличный объем информации, в котором невозможно что либо найти потому что она в сыром виде. Ни на видео, ни на аудиозаписи диктофона, даже на бумаге ни чего не найти. Кто как это решает? После совещаний перерабатывает материал в структурированный вид?
Получается, что специально не ведём и не структурируем. Долго не храним. К задачам Trello/Jira аттачим или линкуем файлы, если надо. А когда задача выполнена и проверена, файлы больше не нужны.
Или ты про детали реализации, не про сам факт наличия фичи?
Со временем накапливается такой приличный объем информации, в котором невозможно что либо найти потому что она в сыром виде. Ни на видео, ни на аудиозаписи диктофона, даже на бумаге ни чего не найти. Кто как это решает? После совещаний перерабатывает материал в структурированный вид?
Мы скринкасты не храним, используем их только короткое время после митинга, чтобы восстановить потерянные фрагменты, потом удаляем. Поэтому у нас нет проблемы с систематизацией аудио/видео материалов.
Самые важные скринкасты хранятся в облаках (Dropbox, Google Drive), а «подшиваются» в Slack, в отчёты (Google Docs/Evernote) и в задачи (Todoist/Jira/Trello), но это на усмотрение того, кто пишет скринкаст. Бывает скринкаст используется только чтобы выдрать из него крохотный кусочек или скриншот, а целиком гигабайтный видео файл не нужен.
А вот с фото, с картинками, с макетами, с прототипами проще. Они либо аттачатся к задачам, либо линкуются через «облака» (Monosnap/Dropbox). Картинка в контексте задачи. Вот и систематизация.
2) Поступающая информация разделяется на категории задач, мусора и справочной.
Задачи ведутся в соответствующем инструменте (и туда прикрепляются необходимые для выполнения материалы, если они не требуют архивирования — в противном случае они дублируются в справочную), мусор игнорируется или удаляется, справочная информация структурируется так, чтобы при необходимости ее можно было легко достать. Это уже дело очень личное, кому что удобнее.
Лично я использую майндкарты, где структурируются взаимосвязи или происходит группировка (если она может быть сделана иерархичной) и выделенную папку для архива (туда складываются непосредственно материалы, разложенные по подпапкам). В майндкарте у узла есть линк на подпапку, где лежит соответствующий узлу материал.
При внесении я пишу для себя, получившего амнезию — не «о пр.арх.пр», а «Проект1. Совещание 15.09. Проблемы архитектуры проекта». Времени тратится при записи чуть больше, но потом не приходится вспоминать и гадать, что имел в виду автор.
В майндкарте мне проще такое засунуть в «Проекты» — «Проект1» — «Совещания» — «09» — «15» и назвать «Проблемы архитектуры проекта».
Но повторюсь — логика структурирования информации у каждого своя, и надо инструмент затачивать под свои шаблоны памяти, а не наоборот.
Что бы ты изменил в процессе обсуждения, если бы был уверен, что твой собеседник забудет всё, о чём вы говорили?Добавил бы больше картинок.
А вообще проблема тут в двух вещах — либо обсуждают что-то недостаточно интересное, раз забывается, либо недосып. Обычно оба варианта сразу.
Алгоритм:
1. Исключить физиологические причины
2. Провести совещание
3. Все что забыли, должно быть забыто
Есть большой минус в том, что это _очень незаконно_ в большинстве стран, без получения предварительного согласия на запись от вашего собеседника.
То есть в одной компании. Ну или между заказчиком и исполнителем.
Лично мне было неудобно разговаривать с собеседником через WhatsUp, потому что я никак не мог включить запись. От этого много нервничал и переспрашивал по 2-3 раза. Поэтому иметь специальный софт или устройства для записи телефонных разговоров — это удобно.
Или вот такой ещё, не очень бюрократический вариант: до встречи составляли повестку, а после встречи -план решения. То есть список вопросов, которые должны были обсудить, и сразу же список задач. Задачи из этого списка потом постепенно связывались с задачами из Jira.
Ведение протокола обязательно. Я, как правило, указываю в потоколе: тему встречи, порядковый номер (если встреча по обсуждаемому вопросу не однократная), дата\время встречи, место встречи, продолжительность, состав участников. Если кто-либо подключается по видео или телефону также отмечаю особо (поскольку могут быть технические сбои, которые не распознают очные участники). В случае назначения очного совещания с представителями подрядчиков\исполнителей в большом составе, при входе регистрируют участников или в процессе совещания по столу пускают листок для самозаписи: компания, должность, ФИО.
Состав указывается в порядке уменьшения должностного уровня в компании. Первым всегда указывается персонал компании или подразделения, которое является Заказчиком. Затем компании (подразделения) участники встречи в алфавитном порядке.
Раздел «Обсудили», раздел «Решили» с указанием ответственных и сроками решения.
В протоколе обязательно используются многоуровневые нумерованные списки, чтобы можно было сослаться по номеру, а не «предпоследний абзац на третьем листе с обратной стороны».
Проект протокола рассылается секретарём (это функция одного из участников, если не привлекается специально обученный сотрудник) всем участникам встречи для рецензирования. После внесения изменений и\или уточнения пунктов протокол утверждается председателем совещания. Как правило, это участник встречи со стороны Заказчика, имеющий наибольшую должность. Допускаются совещания, проводимые по ВКС, когда на экране расшаривается проект протокола и в него в реальном времени вносят изменения и уточняют формулировки. Как правило, он сразу готовится на ресурсе, доступном всем участникам.
Как мне кажется, это весьма удобный подход, минимизирующий риски от остроты памяти человека и систематизирующий поручения и достигнутые договорённости.
Описанный подход "записывай всё" хорошо рассмотрен в книге Фила Портера "Съесть или быть съеденным" (гуглите сами). Я лишь добавлю несколько плюсов записывания поручений и несколько маленьких хитринок, которыми пользуюсь сам.
- записывайте всё, что вам говорят, указывайте так же дату и время — пригодится, когда начнутся ссылки на то, что позже задача менялась или уточнялась, сможете сослаться на хронологию;
- если руководитель имеет привычку "забывать" и "уточнять" детали после постановки задачи, фиксируйте, кто помимо вас слышал то, что вам говорили;
- каждому руководителю или коллеге — свой цвет ручки, либо указывайте фамилию;
- носите свою записную книжку с собой всегда, записывайте все поручения, которые получаете;
- если уточняете задачу большого босса у своего непосредственного начальника, записывайте, что именно он говорит — потом сможете прикрыться перед большим боссом;
- не делайте перед коллегами секрета из того, что ведёте записи — играя в открытую, вы заставите их хорошо обдумывать то, что они говорят;
- никому не давайте свою записную книжку (всегда Ваш, капитан Очевидность);
- можно ставить рядом с поручениями кружки. Когда задача будет выполнена, поставьте галочку. Если отменена — косую черту. Провалена — крест (можете дорисовать глаза, зубы и кости снизу). Интересная статистика получается.
Плюсую хорошую идею. Взял на заметку.
Как ни шаманил, сканер не удачно воспроизводит второй экземпляр. Вживую смотрится существенно лучше, даже написанное чернилами.
Использование копировальной бумаги возможно, но более хлопотно и не чисто получается.
В комментариях к разным статьям habrahabr.ru периодически обсуждают, нужно ли веб-разработчикам высшее образование в области ИТ? Отвечу: да, потому что тут закрепляется навык конспектирования, быстрого письма.
А если это высшее образование в области философии? Там ведь тоже развиваются навыки конспектирования.
Я чуть подвис.
Высшее образование в философии — мне не встречалось такое требование в вакансиях на веб-разработчика.
А если речь идёт об учёной степени «Доктор философии» (Ph.D., D.Phil.), то википедия говорит, что
Несмотря на название, в настоящее время степень не имеет никакого практического отношения к философии (только историческое) и присуждается почти во всех научных областях, например: доктор философии по литературе или доктор философии по физике.
И при этом PhD может быть специалистом (экспертом) в предметной области автоматизации. Так что я не могу ответить на вопрос однозначно.
При обсуждении нужности высшего образования в области ИТ как правило обсуждают актуальность полученных в ВУЗе знаний.
Однако вы написали, что высшее образование в области ИТ нужно, потому что закрепляется навык конспектирования. Философы на лекциях тоже конспетируют и не исключено, что побольше программистов. И, если пользоваться вашим аргументом, то можно обосновать утверждение, что веб-разработчикам нужно закончить философский факультет :).
Вообще на современное высшее образование очень противоречивое мнение. Тебе, возможно, попадался на глаза цикл статей сервиса JavaRush. Примеры:
Я не разделяю эту точку зрения, если что. У ВУЗов есть своя цель и если она совпадает с целью студента — то этот симбиоз будет полезен обоим.
Записывай всё