Не ошибается тот, кто ничего не делает?
Начинала писать этот пост с мыслями о косяках подрядчиков, делающих ремонт в новой квартире, а заканчиваю после утренних попадавших dq-проверок, последствий моих ошибок🥲
У тех, кто только вкатывается в профессию, порой существует ошибочное представление, что люди с высокими грейдами не ошибаются. Но ошибаться нормально каждому — в конце концов, мы не запрограммированные роботы (да и те не застрахованы от ошибок, ведь их создавали такие же люди😉 ).
На мой взгляд, об уровне специалиста говорит не факт наличия или отсутствия ошибок (хотя после утренних алертов я вновь засомневалась на свой счёт😆 ). Куда важнее реакция после.
Если вернуться к теме ремонта, в очередной раз столкнулась с тем, что люди косячат и при выявлении косяков вместо того, чтобы предоставить мне-клиенту информацию, когда будут исправлены недочеты (и, собственно, исправить их), мастера начинают переводить стрелки друг на друга почему так получилось и ждать варианты решения от меня.
Увы, я сталкиваюсь с подобным и в IT. Вместо того, чтобы признать ошибку и сразу её исправить, люди ищут виноватых, придумывают оправдания или перекладывают ответственность. И это, пожалуй, раздражает больше всего.
На мой взгляд, профессионализм начинается там, где ты можешь сказать: «Да, я накосячил. Вот что произошло, и вот что я уже делаю, чтобы это исправить и как стать лучше». Ведь каждая ошибка — наш урок из которого можно вынести что-то полезное. А главное — это наш опыт.
Ошибаться не стыдно, стыдно делать вид, что виноват не ты, а кто-то другой.
#soft_skills
Начинала писать этот пост с мыслями о косяках подрядчиков, делающих ремонт в новой квартире, а заканчиваю после утренних попадавших dq-проверок, последствий моих ошибок
У тех, кто только вкатывается в профессию, порой существует ошибочное представление, что люди с высокими грейдами не ошибаются. Но ошибаться нормально каждому — в конце концов, мы не запрограммированные роботы (да и те не застрахованы от ошибок, ведь их создавали такие же люди
На мой взгляд, об уровне специалиста говорит не факт наличия или отсутствия ошибок (хотя после утренних алертов я вновь засомневалась на свой счёт
Если вернуться к теме ремонта, в очередной раз столкнулась с тем, что люди косячат и при выявлении косяков вместо того, чтобы предоставить мне-клиенту информацию, когда будут исправлены недочеты (и, собственно, исправить их), мастера начинают переводить стрелки друг на друга почему так получилось и ждать варианты решения от меня.
Увы, я сталкиваюсь с подобным и в IT. Вместо того, чтобы признать ошибку и сразу её исправить, люди ищут виноватых, придумывают оправдания или перекладывают ответственность. И это, пожалуй, раздражает больше всего.
На мой взгляд, профессионализм начинается там, где ты можешь сказать: «Да, я накосячил. Вот что произошло, и вот что я уже делаю, чтобы это исправить и как стать лучше». Ведь каждая ошибка — наш урок из которого можно вынести что-то полезное. А главное — это наш опыт.
Ошибаться не стыдно, стыдно делать вид, что виноват не ты, а кто-то другой.
#soft_skills
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤5💯1
Как открытые вопросы помогают понимать бизнес
Работа системного аналитика всегда начинается с общения с бизнес-заказчиками, которые приходят с самыми разными требованиями: от настройки дашбордов до расчёта новых метрик. Чтобы разговор получился действительно полезным и заказчик смог поделиться всей нужной информацией, важно задавать открытые вопросы.
Это помогает лучше понять контекст задачи, выявить скрытые нюансы и предотвратить ошибки.
Звучит просто, но давайте разберём на примерах.
— Какие данные вы хотите анализировать?
Часто заказчики начинают с обобщений, например, "Нам нужны все данные". Чтобы понять что же именно от нас хотят, можем спросить:
– Какие процессы или метрики для вас наиболее важны?
– Какие системы предоставляют данные для этих метрик?
– Есть ли данные, которые уже не актуальны или которыми не пользуются?
— В каком разрезе нужны данные?
Чтобы данные действительно помогали бизнесу, нужно понимать, в каких разрезах их нужно подавать:
– Какие временные рамки вас интересуют (дни, недели, месяцы)?
– Какие параметры важны (регионы, продукты, каналы продаж)?
– Есть ли специфические сегменты, которые требуют особого внимания?
Пример:
Плохо: "Нужно ли делить данные по времени?"
Хорошо: "Какой временной разрез наиболее полезен для ваших целей?"
— Как вы хотите использовать эти данные?
Чтобы понять цель запроса, можно обсудить ключевые моменты:
– Какие отчёты вы хотите получить?
– Какие решения вы планируете принимать на их основе?
– Можете ли вы показать примеры отчётов, которые сейчас вас не устраивают и чем?
— Какие есть ограничения?
Здесь можем уточнить моменты, которые помогут понять возможные ограничения или сложности:
– Есть ли ограничения по срокам?
– С какой периодичностью нужно обновлять данные, чтобы они оставались актуальными для отчетов? Какие процессы требуют более частого обновления, а для каких можно использовать данные с задержкой?
– Какие бизнес-процессы зависят от этих данных?
— Что делать, если данные противоречат друг другу?
Работая с хранилищем, аналитики часто сталкиваются с конфликтами в данных. Можем спросить:
– Как определять достоверность данных?
– Кто принимает решение при возникновении противоречий?
Пример:
Плохо: "Данные из разных источников не совпадают?"
Хорошо: "Бывали ли случаи, когда данные из систем не совпадали? Как определяется источник правды?"
— Как могут измениться требования в будущем?
Требования к данным меняются со временем. Не всё очевидно заранее, но открытые вопросы помогут заранее предусмотреть будущие доработки:
– Планируете ли вы подключать новые источники данных?
– Какие дополнительные метрики могут понадобиться?
Как задавать открытые вопросы?
Чтобы вопросы работали, следуйте нескольким правилам:
*️⃣ Начинайте с "Почему?", "Как?", "Что?", "Какие?", ...
*️⃣ Избегайте формулировок, которые допускают ответ "да" или "нет".
*️⃣ Стройте вопросы так, чтобы они побуждали к диалогу. Дайте собеседнику возможность пообщаться и поделиться деталями. Это будет полезно и для нас, и для него. Ведь разговор предполагает дополнительное размышление.
Открытые вопросы — это инструмент, который помогает не только уточнить требования заказчика, но и наладить продуктивное взаимодействие. Важно не просто сделать крутое хранилище (которым никто не пользуется), но и отвечающее ожиданиям пользователей. Чем больше информации мы соберём на начальном этапе общения, тем меньше доработок понадобится в будущем.
#soft_skills
Работа системного аналитика всегда начинается с общения с бизнес-заказчиками, которые приходят с самыми разными требованиями: от настройки дашбордов до расчёта новых метрик. Чтобы разговор получился действительно полезным и заказчик смог поделиться всей нужной информацией, важно задавать открытые вопросы.
Открытый вопрос — это такой вопрос, на который нельзя ответить "да" или "нет". Он подразумевает развернутый ответ и побуждает собеседника делиться деталями.
Это помогает лучше понять контекст задачи, выявить скрытые нюансы и предотвратить ошибки.
Звучит просто, но давайте разберём на примерах.
— Какие данные вы хотите анализировать?
Часто заказчики начинают с обобщений, например, "Нам нужны все данные". Чтобы понять что же именно от нас хотят, можем спросить:
– Какие процессы или метрики для вас наиболее важны?
– Какие системы предоставляют данные для этих метрик?
– Есть ли данные, которые уже не актуальны или которыми не пользуются?
— В каком разрезе нужны данные?
Чтобы данные действительно помогали бизнесу, нужно понимать, в каких разрезах их нужно подавать:
– Какие временные рамки вас интересуют (дни, недели, месяцы)?
– Какие параметры важны (регионы, продукты, каналы продаж)?
– Есть ли специфические сегменты, которые требуют особого внимания?
Пример:
Плохо: "Нужно ли делить данные по времени?"
Хорошо: "Какой временной разрез наиболее полезен для ваших целей?"
— Как вы хотите использовать эти данные?
Чтобы понять цель запроса, можно обсудить ключевые моменты:
– Какие отчёты вы хотите получить?
– Какие решения вы планируете принимать на их основе?
– Можете ли вы показать примеры отчётов, которые сейчас вас не устраивают и чем?
— Какие есть ограничения?
Здесь можем уточнить моменты, которые помогут понять возможные ограничения или сложности:
– Есть ли ограничения по срокам?
– С какой периодичностью нужно обновлять данные, чтобы они оставались актуальными для отчетов? Какие процессы требуют более частого обновления, а для каких можно использовать данные с задержкой?
– Какие бизнес-процессы зависят от этих данных?
— Что делать, если данные противоречат друг другу?
Работая с хранилищем, аналитики часто сталкиваются с конфликтами в данных. Можем спросить:
– Как определять достоверность данных?
– Кто принимает решение при возникновении противоречий?
Пример:
Плохо: "Данные из разных источников не совпадают?"
Хорошо: "Бывали ли случаи, когда данные из систем не совпадали? Как определяется источник правды?"
— Как могут измениться требования в будущем?
Требования к данным меняются со временем. Не всё очевидно заранее, но открытые вопросы помогут заранее предусмотреть будущие доработки:
– Планируете ли вы подключать новые источники данных?
– Какие дополнительные метрики могут понадобиться?
Как задавать открытые вопросы?
Чтобы вопросы работали, следуйте нескольким правилам:
Открытые вопросы — это инструмент, который помогает не только уточнить требования заказчика, но и наладить продуктивное взаимодействие. Важно не просто сделать крутое хранилище (которым никто не пользуется), но и отвечающее ожиданиям пользователей. Чем больше информации мы соберём на начальном этапе общения, тем меньше доработок понадобится в будущем.
#soft_skills
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍1