Как вы управляете ожиданиями (или я не могу отключить уведомления, от меня же ждут ответа)?

@MSalamatov, срочно для инициатора естественно :) Если я инициатор - то для меня, если я получатель - то для вызывающего.

@nerealvm, с таким не сталкивался. Для меня такое звучит довольно странно, мягко говоря... Что значит звонить - это агрессивно? Это что за детский сад? :)
Если же серьезно, то в отличие от спамеров и курьеров мои коллеги у меня занесены в телефон и потому я вижу кто мне звонит. Если номер не определился, - с очень большой вероятностью это спамер/курьер. Если номер определился - я могу взвешенно принять решение, в том числе и на основании имени звонящего.
Кроме того, я как Скрам мастер сотни раз наблюдал ситуацию когда переписка приводила к бесплодным и бессмысленным конфликтам у коллег. Но как только я, иногда буквально, "за шкирку" сводил конфликтующих в офисе вместе или "заставлял" созвониться, - случалось чудо! Конфликт быстро прекращался, потому что оказывается друг друга просто не так поняли. У меня даже есть правило "трех комментариев": если в переписке по одному вопросу уже больше трех комментариев - надо созваниваться!
Вообще с моей точки зрения, асинхронная коммуникация хороша для информирования, но очень плоха для выяснения каких-либо вопросов. Кроме того, любой читает переписку из своего состояния и начинает видеть в ней то, что автор ни разу в свои строки не закладывал. Общение по видео/голосу это сразу все пресекает. ИМХО, лучше созвониться на 3 минуты, чем переписываться 10 минут.

@Ingwarr, ну вот так) зумеры выходят на работу видать)

А насчет ассинхронности надо посмотреть. Я замечал, что иногда не получается договориться ассинхронно, когда у тебя весь день в синхронных созвонах, понятно что мыслетоплива на асинхронную коммуникацию не остается. ну и вообще тема разумной ассинхронности сейчас близка. Оставлю ссылочку на видос Димы Лазарева

@nerealvm, Володя, мы ж с тобой на одном тренинге у Димы были. Я хорошо помню его "одержимость" асинхронным общением :)
Например, выяснять требования у заказчика асинхронно займёт в разы больше времени чем синхронно.
Мой посыл всего лишь в том, что асинхронность (как и любой другой инструмент/подход/...) нужно использовать только там где она применима и полезна. У каждого инструмента есть свои границы применения, их важно знать и не пытаться применять инструмент не по назначению. Например, молоток - хороший инструмент для забивания гвоздей, но не подходит для того чтобы пилить дерево.

@Ingwarr, Но ведь требования у заказчика лучше все равно в конце зафиксировать письменно? Я к тому, что для этого кейса лучше всего работает связка «Поставить встречу» - «Написать требования» - «Письменно зафиксировать», так ведь?

@Ingwarr, Игорь, сорян, не признал. все что дальше - бесспорно)

😱 Комментарий удален его автором...

@MSalamatov,
1 вопрос.
На мой взгляд зависит от вида разработки. При заказной разработке требования обязательно надо тщательно и детально зафиксировать. Ведь по ним потом будет вестись приемка сделанного (упрощенно говоря).
При продуктовой разработке, когда в роли "заказчика" выступает Product Owner (т.е. человек являющийся членом команды, а не внешним человеком) это не обязательно. Строго говоря требования в некотором смысле все равно будут фиксироваться. Но в отличие от усредненного заказного проекта, они скорее всего будут фиксироваться упрощенно. Ровно настолько, чтобы не забыть о чем договорились. Ключевое здесь - удовлетворить ожидания Product Owner (PO), а не реализовать требования. В продуктовой разработке часто бывает так, что требования выполнены, а PO все равно не удовлетворен. В таком случае все равно приходится доделывать и/или переделывать дальше. В заказной разработке критерий выполнения - это полное соответствие требованиям, даже если эти требования на момент сдачи проекта уже не актуальны.

2 вопрос.
Про связку я кажется не понял вот что: как это противоречит или связано с моим тезисом "выяснять требования у заказчика асинхронно займёт в разы больше времени чем синхронно."? :)

@Ingwarr, Про 1 - да, похоже все так. Про 2 - не, не противоречит. Скорее дополняет :)

@cartmendum, не обязательно что ты) но вопрос отстраивание своих границ всё же на тебе) мне проще говорить о границах с новыми людьми, чем с теми кому я уже быстро отвечала длительное время) перестройка всегда больно, а еще редко задумываются как это сделать с любовью, а не просто написать «я теперь общаюсь с тобой асинхронно» ))

@teklaron, ага, вот действительно дело про границы. И тогда выходит, что картинка в посте - это как будто некое рекомендуемое описание этих самых границ.

@MSalamatov, точно очень похоже) картинка может быть как док для согласования границ быть)

@nerealvm и @MSalamatov, когда начинал внедрять ДТ, создавал регулярную задачу по разбору входящих раз в два дня. 2-3 месяца назад отказался, вроде стал периодически сам проверять, но регулярно продалбывал какой-то один из ящиков входящих, на фоне заметил, что раз деятельность у меня разная, то порой я продалбываю задачи именно определённой сферы деятельности (управленческая и исполнительная). Решил попробовать создать режим рабочего дня (в котором я буду проверять определённые входящие, в определённое время и дам время для управленческих задач). Подсмотрел на форуме многосделал у Руслана Козика чек-листы на вечер. Как понял идею - не тратить силы на продумывания чем примерно буду заниматься и сделать список по порядку. Пытался разобрать отдельно входящие из почтов и чатов, входящие из рабочей программы, устные входящие от сотрудников.

Вот чек-лист режима рабочего дня:

1. Выполнить хотя бы одну зелёную задачу — 1-2 помидора
2. Проверить календарь (настроиться что-то просто вычеркнуть из списка, если время занято встречами) — 30 секунд
3. Выполнить хотя бы одну управленческую задачу — 1-2 помидора
4. Выполнить нужную на сегодня задачу — 1-2 помидора
5. Обработать чаты и уведомления в Юджайле — 15 минут
6. Обработать рабочую почту, корпоративную почту, мессенджеры — 15 минут
7. Позвонить/написать кому нужно — 15 минут
8. Выполнить другие нужные на сегодня задачи — 1-2 помидора
9. Посмотреть одну задачу на потом, которую можно сделать, и сделать — 1 помидор
10. Ответить на вопросы сотрудников — 1 помидор
11. Заполнить в Юджайле информацию по выполненным задачам — 1 помидор
12. Проверить встречи, которые надо записать в календарь — 15 минут
13. Выполнить задачи на сегодня (что можно и на что есть силы и время, но чтобы ещё провести ежедневный обзор и заполнить календарь)
14. Провести ежедневный обзор дня в notion — 15 минут

Но очень не пошло. Думал почему.

• Всё же, наверное, банально список перегружен по пределу впихуемости. Каждый день случается что-то, что твоё время работы съедает (пытался частично предусмотреть пунктом 2).
• А может стоит начать со списка поменьше. Банально замахнулся на большое.
• Или не привык к списку.

Но следование пункту 1 давало мотивации) прошёл один курс для себя и хочется по итогу проект реализовать.

Буду признателен, если подскажите из опыта на какой подводный камень я наступил. Пока думаю, что стоит сократить может быть.

Есть ещё идея просто разделить дни недели на определённую сферу работ (контроль проектов, общение и поиск клиентов, развитие бизнес-процесса, обычное юридическое).

@cowabunga, вообще выглядит бодро, но мне кажется перегруз ( возможно надо с усталостью поработать) + нет места для маневра. Иногда мне кажется надо побездельничать или сделать что-то приятное. Ну и отдыха побольше в такой план я бы напихал. Но все ж планировать поминутно день не оч. идея имхо

@nerealvm, спасибо за ответ! Попробую уменьшить количество пунктов (объединить что-то) и добавить как-то отдыха. По поводу поминутного планирования, согласен, не люблю жёсткие рамки, поэтому писал примерное количество помидорок и не более двух (просто уже не знал, как постараться успеть и тут поделать и там посмотреть). Сейчас пришла идея просто добавить памятку, что у меня есть работа по таким-то сферам и держать её перед глазами, отмечать что в этой сфере что-то поделал - значит можно перейти к другой. Возможный минус - станет мешать как неявный список задач, утрачу доверие к явному. Возможное решение - держать памятку перед глазами при обзоре на стадии набора коробочки сегодня (тогда потом и не потребуется).

@cowabunga, вообще кажется, что распланировано без резервов совсем. А в течение любого дня бывает куча непредсказуемостей, от которых защититься можно только избыточностью.

@MSalamatov, спасибо за ответ! Получается, что количество резервов плана прямо пропорционально количеству случайностей, возникающих в период его исполнения? Видимо логичнее заложить побольше резерва и доставать задачи из "на неделе" по мере необходимости.

Хотя. Интересен такой момент. Если ты понимаешь (по опыту), что всего из плана на день не сделаешь, то можешь и перебарщивать с количеством задач, обосновывая - мне так легче выбрать следующие, чем шерстить и выбирать из большего числа "на неделе". Или есть что-то неосознанное, что в любом случае гнетёт тебя количеством несделанных задач, хоть тебе и кажется, что всё норм? Возможно тут выбор из двух зол:

1. тратить мыслетопливо на решение, что сделать из "на неделе";
2. тратить мыслетопливо из-за количества ещё не выполненного.

Наверное, в первом случае ты получаешь небольшой бонус от результата пустого списка на сегодня)

@cowabunga, да, все так про первый вариант. Тут закон впихивания - про попытке впихнуть невпихуемое выпихивается ранее впихнутое. На выбор, приоритет и так далее в заведомо большом списке тоже тратится мыслетопливо.