🤓Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью

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

📎 https://vc.ru/life/732388-tehnicheskie-zadaniya-i-it-sistemy-razbiraemsya-kak-ozhidaniya-metchit-s-realnostyu

Друзья! Уже очень скоро состоится наша вторая конференция nextwayconf, которая целиком будет посвящена системному и бизнес-анализу.

Если вдруг вы пропустили предыдущий анонс, вкратце рассказываем о конференции.

Кому точно стоит посетить конференцию:

✅ Системным или бизнес-аналитикам уровня Джун+ (мидл и сеньорам тоже будет интересно)
✅ Тем, кто работает в других IT-профессиях, но сталкивается с задачами по системному и бизнес-анализу
✅ Тем, кто хочет перейти из другой IT-профессии в системный или бизнес-анализ

А вот кому НЕ нужно идти на конференцию:

❌ Тем, кто только хочет прийти в IT и ещё только смотрит в эту сторону
❌ Тем, кто уже и так всё знает и хочет просто прийти потроллить

Спикеры конференции:

Преподаватели школы NextWay и приглашенные гости из Яндекса, Lamoda, Кошелёк, Samokat.tech, Avito.tech, HFLabs, E-escalate, Devexperts, Royal English

Кратко о том, что вас ждёт:

⚡️ Наконец-то разберётесь с НФТ и интеграцией
⚡️ Вам больше не придётся много часов бесплатно исправлять ошибки на этапе внедрения и эксплуатации из-за того, что вы не учли UX. Разберётесь как сделать и пользователю, и себе хорошо уже на этапе проектирования
⚡️ Актуализируете свои знания и закрепите их на практических воркшопах. Это поможет вам избавиться от синдрома самозванца и перестать бояться выхода на рынок
⚡️ Сможете выйти за рамки привычных решений ваших задач. Увидите другие способы выстраивания знакомых вам процессов и расширите свой кругозор
⚡️ Лучше поймёте архитекторов, UX исследователей, product owner’ов и другие смежные позиции. И определитесь, в каком направлении развиваться дальше
⚡️ Узнаете от практиков, что сейчас наиболее востребовано в отрасли. И научитесь с этим работать
⚡️ Разберётесь со спецификой работы с требованиями и user story на английском. И поймёте, для чего это нужно, даже если вы работаете в РФ.

Даты проведения конференции: 29-30 июля
Формат: онлайн + запись
Участие в первом дне - бесплатное

Чтобы зарегистрироваться на конференцию, переходите по ссылке прямо сейчас.

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

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

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

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

На днях столкнулась с очень интересной документацией на работе.
Задача - разработать внутренний портал для компании, с которого она сможет получать данные внешних систем, обрабатывать их и отправлять в другие системы.
И в рамках наших интеграций нам конечно же нужно получать некоторые справочники с указанных внешних ресурсов.
Некоторые ресурсы ведут себя вполне понятно и выдают справочники по запросу 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. Но на практике это в постановках задач почти не встречается. А зря.