Обратная связь по задачам
Этот пост из серии #механический_менеджмент логически продолжает тему про Push и Pull. Здесь мы разберёмся как люди из разных систем могут сообщать друг другу о статусе выполнения каких-то задач.
В программировании есть несколько способов запросить и получить информацию о чём-либо. Эти подходы легко перекладываются на менеджмент. Вот они:
- Частый опрос (Short polling)
- Длинный опрос (Long Polling)
- Хуки (Hooks)
- Двусторонняя связь (Duplex)
Частый опрос (Short polling)
Если смотрели Шрека, то есть знаменитая сцена с Ослом - "мы уже приехали?". По сути, вы раз в X минут спрашиваете сотрудника готово или не готово. Сотрудник отвечает моментально. Как только получаете "готово", начинаете делать свои задачи.
Вы каждый раз открываете канал связи и получаете ответ с задержкой, при этом вторая сторона на вас повлиять не может.
Длинный опрос (Long Polling)
Очень похоже на частый опрос, но сотрудник отвечает не моментально. Больше похоже на электронную очередь - вам дают талончик, вы зависаете и ждёте ответа. Спустя час получаете "не готово, придите ещё через час".
В жизни аналогия не очень, но в автоматизации бывает полезно. Сервисы не долбятся каждую минуту друг к другу, а посылают один запрос и ждут на него ответа. Это снижает сетевую нагрузку и в какой-то степени увеличивает скорость ответа. Но нагружает другую сторону количеством открытых соединений. То есть в маленьком помещении накапливается большая очередь ожидающих.
Вы тоже каждый раз открываете канал связи, просто делаете это реже, а задержка возникает только если вторая сторона вас сбросила и пришлось переподключаться. При этом вторая сторона на вас повлиять не может.
Хуки (Hooks)
Набор инструкций что сделать, когда какое-то событие произошло. Вы не опрашиваете сотрудника, а даёте ему две инструкции. Первая описывает основную задачу, вторая - что делать сразу после выполнения задачи. Например: "как только закончишь делать отчёт, перезвони мне (callback) и сообщи, что отчёт готов, а потом отправь его следующим адресатам...".
Можно сказать, что тут нет канала связи, кроме первичной передачи инструкций. Если во второй инструкции были задачи что-то изменить в вашей системе, то это произойдёт. Например, сотрудник придёт к вам в кабинет и положит отчёт на стол.
Двусторонняя связь (Duplex)
Это, скорее, работа в паре. Когда вы и другой сотрудник решаете какую-то задачу и он влияет на вас, вы на него. Созвон в Зуме или работа бок о бок в офисе. В веб-разработке для этого используются websockets.
Вы один раз открываете канал связи и гоняете данные туда-сюда с минимальной задержкой и обе системы могут друг на друга влиять. Но при этом тут тоже работают хуки, т.к. вы, как инициатор такого общения, сами решаете какие действия вашего сотрудника должны менять окружающий мир.
Напоследок
На самом деле, у нас всего один способ взаимодействия — запрос-ответ, он же call-response, он же request-response. Всё остальное — навороты над этим делом.
К слову, если вы наблюдали какие подходы из программирования хорошо ложатся на реальный мир, расскажите об этом в комментариях.