Уже сейчас можно начинать придумывать идеи и вопросы нашим заказчикам.

❓ Кто наши заказчики? Иннокентий и Татьяна Носонберги — мультимиллиардеры, красавцы, филантропы и вот это вот все.
да-да, у меня и у Кеши будет небольшое раздвоение личности, мы и ведущие, и заказчики

💡 А что хотят заказчики? Построить отель, бюджет неограничен. Хотелки — в брифе (см.картинку).

💃🕺 А кто же вы?
Основные действующие лица в этой игре. Вы — эксперты по дизайну, постройке отелей. На игре мы разделим вас на команды (дизайн-бюро). Каждая команда будет выявлять хотелки заказчика и предлагать свой проект.
А пока до игры есть время, можете подумать и покреативить над идеями, как реализовать желания из письма)

На днях столкнулась с очень интересной документацией на работе.
Задача - разработать внутренний портал для компании, с которого она сможет получать данные внешних систем, обрабатывать их и отправлять в другие системы.
И в рамках наших интеграций нам конечно же нужно получать некоторые справочники с указанных внешних ресурсов.
Некоторые ресурсы ведут себя вполне понятно и выдают справочники по запросу GET, а вот второй ресурс оказался необычным.
На первый взгляд найти методы получения справочников нам не удалось - и не удивительно, в доступной нам API документации практически не было GET запросов.
Не буду рассказывать весь исследовательский путь (причем спросить мы у партнера как получить справочники не могли, а заказчик не ведал технических подробностей)
Перейдем к сути.
Оказалось что для получения справочников используется запрос POST.

Итак, почему же POST?
1. Система заказчика регистрирует количество запросов от каждого клиента, запросом POST на стороне контрагента фиксируется каждое обращение нашего клиента к API
2. Соображения безопасности. GET-параметры передаются через URL. Это означает, что все параметры сохраняются в журналах сервера и истории браузера.
Параметры запроса POST обычно не регистрируются.

Для примера: Facebook повсеместно использует запросы POST.
Насколько это реально безопаснее и насколько это архитектурно обосновано судить не берусь, не мой уровень к сожалению.
Но зато, теперь вы тоже знаете, что можно получать данные не только стандартным GET и не будете удивлены, не найдя подходящего GET запроса. а сразу прошерстите еще и POST.
Пример смотри по ссылке (https://partner.thetradedesk.com/v3/portal/api/doc/BidList#:~:text=see%20two%20examples.-,Look%20Up%20Bid%20Lists,-Use%20the%20following)

Принцип, с помощью которого вы резко улучшите качество постановки задач

Он очень прост. Детально описывать, что ты считаешь плохим, а что хорошим результатом. Даже если ты сам этого не знаешь и будешь принимать решение по чуйке — так и говорить, а не строить хорошую мину при плохой игре.

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

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

"Подмети в комнате" — плохая постановка.
"Подмети в комнате. Помимо пола, я проверю все углы и если в одном из них найду грязь, то заставлю переделывать" — хорошая.

В этом же ключевой смысл буковки M из SMART. Но на практике это в постановках задач почти не встречается. А зря.