Спасибо за честность! Мои аналогии — не догма, а попытка найти общий знаменатель для людей из абсолютно разных сфер. Конечно, для опытного технаря сравнение с «рестораном» может резать слух.
Возможно, вы подскажете — как бы вы сами объяснили суть, например, деплоя или API нетехническому специалисту, чтобы он не просто кивнул, а действительно понял? Ваш опыт был бы крайне ценен. Я не вешаю на себя ярлык "Суперэксперта", просто пытаюсь донести сложное — простым языком.
В книге после каждого технического объяснения (что такое деплой, API, микросервисы) идёт простая аналогия для закрепления. Это не замена знаниям, а способ сделать их доступными — как в вашем примере с турбулентностью, где физика следует за образом. Тут все почему то думают я только про аналогии говорю)) Это всего лишь инструмент)
Уважаемый коллега, вы невольно подтвердили главный тезис моей работы. Проблема не в аналогиях, а в том, что многие технические специалисты, подобно вам, считают: чтобы участвовать в диалоге об IT, нужно иметь соответствующий диплом.
Вы сравниваете с самолётостроением — и это прекрасный пример. Пилоту не нужно уметь проектировать шасси, чтобы эффективно управлять лайнером. Но он обязан понимать, что такое «угол атаки» и «турбулентность» — ровно так же, как менеджеру проекта нужно понимать, например, что такое «спринт» и «деплой», чтобы эффективно управлять продуктом.
Моя книга не учит «конструировать самолеты» и не ограничивается аналогиями. Её цель — дать «пилотам» и «авиадиспетчерам» общий язык для работы. Поэтому в ней, помимо объяснения логики через образы, есть главы про архитектурные паттерны, жизненный цикл продукта, языки программирования и методологии разработки — все то, что позволяет нетехническому специалисту осознанно участвовать в обсуждении архитектуры, оценке сроков и выборе стека технологий.
А бояться «дилетантов» — это странно для профессионала вашего уровня. Настоящий эксперт как раз умеет объяснять сложное просто. И именно такие специалисты, способные к диалогу, а не к отгораживанию, и создают по-настоящему сильные команды.
Кажется, мы говорим о разных вещах. Вы — о том, как выполнить разовое действие по инструкции. Я — о том, как понимать систему в целом, чтобы принимать осознанные решения.
Моя книга как раз и объясняет эту систему: от архитектуры и выбора технологий до процессов. Если хотите составить мнение не по заголовкам, а по сути — готов предоставить вам полноценный экземпляр. Если интересно конечно)
Совершенно верно — это представитель заказчика или приглашённый эксперт. Но даже эксперту нужно эффективно общаться с командой.
Мой личный пример: я пришёл в IT из госзакупок, где был сильным тендерным специалистом. Но на начальных этапах я не сразу понимал как разрабатываются мобильные приложения и о чем говорят разработчики. Мне не нужно было становиться программистом — но чтобы использовать свой экспертный опыт в тендерах, мне нужно было быстро освоить процессы разработки. Поэтому я написал книгу, которая позволяет быстрее понимать все процессы и быстрее влиться в коллектив.
Вы правы — такому врачу действительно нельзя доверять операции. Но представьте, что в клинику приходит менеджер по закупкам, которому нужно выбрать между артериальным и венозным катетером. Ему не нужно знать физиологию как хирург — но без понимания разницы между артерией и веной он не сможет даже заказать правильные расходники.
Речь не об интеллекте, а о когнитивной эффективности. Мозг человека, незнакомого с темой, гораздо легче и прочнее запоминает информацию, если она «упакована» в яркий образ, а не в сухое определение. Ваше определение, безусловно, точное, но оно требует от новичка дополнительных усилий по расшифровке терминов.
Разные задачи требуют разных инструментов. Вы предлагаете человеку справочник, я — работающую картинку в голове. И для первого шага второе почти всегда эффективнее. Это, конечно, лишь мое ИМХО, и я никому его не навязываю. Ваша точка зрения мне ясна.
Интересный вопрос. Если я его правильно понял, отвечу так:
Филолог на совещании по голосовому помощнику поможет правильно построить диалоги, чтобы бот понимал не только команды, но и интонацию, и стилистику. Без него получится робот, с которым неприятно говорить.
Медик в команде, разрабатывающей медгаджет, объяснит, как врачи ставят диагнозы в реальности. Это убережет команду от создания «технически идеального», но клинически безполезного прибора
Нет, это для тех, кто приходит в IT, чтобы приносить реальную пользу, а не демонстрировать своё превосходство. Для кого умение наладить диалог между бизнесом и разработкой — это такая же ценная компетенция, как и написание кода
Вы сравниваете знание египтологии с пониманием среды, в которой работаешь. Более точная аналогия: врач, который знает, чем артерия отличается от вены — не для того, чтобы делать операцию, а чтобы понимать слова хирурга и согласованно с ним работать. Именно этому — эффективной работе в команде — и учит книга.
Вы путаете два разных этапа обучения. Ваш путь — это путь углубления, когда специалист погружается в смежную профессиональную область. Это достойно уважения.
Но мой подход решает задачу на этапе входа. Когда человек впервые слышит слово «деплой», ему не нужна лекция про системы версионирования — ему нужно понять базовую суть, чтобы перестать паниковать и начать осмысленно участвовать в диалоге.
Сравнивать сложные медицинские процессы с «паровозиками» — это передергивание. Мои аналогии — это не замена знаниям, а первый шаг к ним. Пока вы предлагаете новичку читать «Биохимию крови», я помогаю ему запомнить, что «лейкоциты — это солдаты, которые борются с инфекцией». Без этого первого шага погружение будет сложнее.
«Злая хрюша» часто отсеивает не неудачников, а тех, у кого просто другой бэкграунд. Я даю людям карту, чтобы их оценивали по реальным компетенциям, а не по умению играть в слова. За незнанием терминов часто скрывается ценный для команды нетривиальный опыт.
Спасибо, что выделили этот момент! Это не незаконченный перевод, а готовый пример из рабочего лексикона. «Замержить пул-реквест» — как раз и значит утвердить и объединить изменения в коде.
Странно, но этот «странноватый» подход называется «моделирование предметной области», и его используют как раз для создания общего языка между технарями и нетехнарями. Аналогии — это инструмент, а не признак уровня понимания. Аналогии — самый быстрый способ добиться понимания с коллегами из маркетинга, отдела продаж или заказчиком. Это не заменяет глубоких знаний, а убирает барьеры для совместной работы.
Вы правы, знание английского сильно помогает. Но моя задача — не стать разработчиком, а наладить коммуникацию между бизнесом и техникой. Книга как раз и помогает перестать быть «говорящим попугаем», дав понимание сути процессов, а не просто заучивание слов. Это экономит время команды и бизнеса.
Такой словарь и есть моя книга). Там каждая аналогия получает техническое пояснение. В ней есть не только термины. Цель книги — более быстро погрузиться в мир IT нетехническому специалисту.
Спасибо за честность! Мои аналогии — не догма, а попытка найти общий знаменатель для людей из абсолютно разных сфер. Конечно, для опытного технаря сравнение с «рестораном» может резать слух.
Возможно, вы подскажете — как бы вы сами объяснили суть, например, деплоя или API нетехническому специалисту, чтобы он не просто кивнул, а действительно понял? Ваш опыт был бы крайне ценен. Я не вешаю на себя ярлык "Суперэксперта", просто пытаюсь донести сложное — простым языком.
В книге после каждого технического объяснения (что такое деплой, API, микросервисы) идёт простая аналогия для закрепления. Это не замена знаниям, а способ сделать их доступными — как в вашем примере с турбулентностью, где физика следует за образом. Тут все почему то думают я только про аналогии говорю)) Это всего лишь инструмент)
Уважаемый коллега, вы невольно подтвердили главный тезис моей работы. Проблема не в аналогиях, а в том, что многие технические специалисты, подобно вам, считают: чтобы участвовать в диалоге об IT, нужно иметь соответствующий диплом.
Вы сравниваете с самолётостроением — и это прекрасный пример. Пилоту не нужно уметь проектировать шасси, чтобы эффективно управлять лайнером. Но он обязан понимать, что такое «угол атаки» и «турбулентность» — ровно так же, как менеджеру проекта нужно понимать, например, что такое «спринт» и «деплой», чтобы эффективно управлять продуктом.
Моя книга не учит «конструировать самолеты» и не ограничивается аналогиями. Её цель — дать «пилотам» и «авиадиспетчерам» общий язык для работы. Поэтому в ней, помимо объяснения логики через образы, есть главы про архитектурные паттерны, жизненный цикл продукта, языки программирования и методологии разработки — все то, что позволяет нетехническому специалисту осознанно участвовать в обсуждении архитектуры, оценке сроков и выборе стека технологий.
А бояться «дилетантов» — это странно для профессионала вашего уровня. Настоящий эксперт как раз умеет объяснять сложное просто. И именно такие специалисты, способные к диалогу, а не к отгораживанию, и создают по-настоящему сильные команды.
Кажется, мы говорим о разных вещах. Вы — о том, как выполнить разовое действие по инструкции. Я — о том, как понимать систему в целом, чтобы принимать осознанные решения.
Моя книга как раз и объясняет эту систему: от архитектуры и выбора технологий до процессов. Если хотите составить мнение не по заголовкам, а по сути — готов предоставить вам полноценный экземпляр. Если интересно конечно)
Совершенно верно — это представитель заказчика или приглашённый эксперт. Но даже эксперту нужно эффективно общаться с командой.
Мой личный пример: я пришёл в IT из госзакупок, где был сильным тендерным специалистом. Но на начальных этапах я не сразу понимал как разрабатываются мобильные приложения и о чем говорят разработчики. Мне не нужно было становиться программистом — но чтобы использовать свой экспертный опыт в тендерах, мне нужно было быстро освоить процессы разработки. Поэтому я написал книгу, которая позволяет быстрее понимать все процессы и быстрее влиться в коллектив.
Вы правы — такому врачу действительно нельзя доверять операции. Но представьте, что в клинику приходит менеджер по закупкам, которому нужно выбрать между артериальным и венозным катетером. Ему не нужно знать физиологию как хирург — но без понимания разницы между артерией и веной он не сможет даже заказать правильные расходники.
Речь не об интеллекте, а о когнитивной эффективности. Мозг человека, незнакомого с темой, гораздо легче и прочнее запоминает информацию, если она «упакована» в яркий образ, а не в сухое определение. Ваше определение, безусловно, точное, но оно требует от новичка дополнительных усилий по расшифровке терминов.
Разные задачи требуют разных инструментов. Вы предлагаете человеку справочник, я — работающую картинку в голове. И для первого шага второе почти всегда эффективнее. Это, конечно, лишь мое ИМХО, и я никому его не навязываю. Ваша точка зрения мне ясна.
Интересный вопрос. Если я его правильно понял, отвечу так:
Филолог на совещании по голосовому помощнику поможет правильно построить диалоги, чтобы бот понимал не только команды, но и интонацию, и стилистику. Без него получится робот, с которым неприятно говорить.
Медик в команде, разрабатывающей медгаджет, объяснит, как врачи ставят диагнозы в реальности. Это убережет команду от создания «технически идеального», но клинически безполезного прибора
Нет, это для тех, кто приходит в IT, чтобы приносить реальную пользу, а не демонстрировать своё превосходство. Для кого умение наладить диалог между бизнесом и разработкой — это такая же ценная компетенция, как и написание кода
Вы сравниваете знание египтологии с пониманием среды, в которой работаешь. Более точная аналогия: врач, который знает, чем артерия отличается от вены — не для того, чтобы делать операцию, а чтобы понимать слова хирурга и согласованно с ним работать. Именно этому — эффективной работе в команде — и учит книга.
Вы путаете два разных этапа обучения. Ваш путь — это путь углубления, когда специалист погружается в смежную профессиональную область. Это достойно уважения.
Но мой подход решает задачу на этапе входа. Когда человек впервые слышит слово «деплой», ему не нужна лекция про системы версионирования — ему нужно понять базовую суть, чтобы перестать паниковать и начать осмысленно участвовать в диалоге.
Сравнивать сложные медицинские процессы с «паровозиками» — это передергивание. Мои аналогии — это не замена знаниям, а первый шаг к ним. Пока вы предлагаете новичку читать «Биохимию крови», я помогаю ему запомнить, что «лейкоциты — это солдаты, которые борются с инфекцией». Без этого первого шага погружение будет сложнее.
«Злая хрюша» часто отсеивает не неудачников, а тех, у кого просто другой бэкграунд. Я даю людям карту, чтобы их оценивали по реальным компетенциям, а не по умению играть в слова. За незнанием терминов часто скрывается ценный для команды нетривиальный опыт.
Спасибо, что выделили этот момент! Это не незаконченный перевод, а готовый пример из рабочего лексикона. «Замержить пул-реквест» — как раз и значит утвердить и объединить изменения в коде.
Было именно так). Сейчас помогаю другим избежать этого.
Странно, но этот «странноватый» подход называется «моделирование предметной области», и его используют как раз для создания общего языка между технарями и нетехнарями. Аналогии — это инструмент, а не признак уровня понимания. Аналогии — самый быстрый способ добиться понимания с коллегами из маркетинга, отдела продаж или заказчиком. Это не заменяет глубоких знаний, а убирает барьеры для совместной работы.
Вы правы, знание английского сильно помогает. Но моя задача — не стать разработчиком, а наладить коммуникацию между бизнесом и техникой. Книга как раз и помогает перестать быть «говорящим попугаем», дав понимание сути процессов, а не просто заучивание слов. Это экономит время команды и бизнеса.
Такой словарь и есть моя книга). Там каждая аналогия получает техническое пояснение. В ней есть не только термины. Цель книги — более быстро погрузиться в мир IT нетехническому специалисту.