Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 43
Вам нужен ещё один словарь - между вашими аналогиями и реальными понятиями))
Такой словарь и есть моя книга). Там каждая аналогия получает техническое пояснение. В ней есть не только термины. Цель книги — более быстро погрузиться в мир IT нетехническому специалисту.
более быстро погрузиться в мир IT нетехническому специалисту.
А зачем оно ему? И зачем он в IT? Знание нескольких buzzwords ничего не даст мимокрокодилу. Все раано что я узнал, чем сфинкс отличается от сфинктера - тепкрь я в некотором роде египтолог. И медик.
Вы сравниваете знание египтологии с пониманием среды, в которой работаешь. Более точная аналогия: врач, который знает, чем артерия отличается от вены — не для того, чтобы делать операцию, а чтобы понимать слова хирурга и согласованно с ним работать. Именно этому — эффективной работе в команде — и учит книга.
Врачу, который знает, что артерия отличается от вены (и все), я бы доверил разве что утку выносить. Настоящие врачи учат анатомию и физиологию по настоящему. Даже если не хирурги.
Вы правы — такому врачу действительно нельзя доверять операции. Но представьте, что в клинику приходит менеджер по закупкам, которому нужно выбрать между артериальным и венозным катетером. Ему не нужно знать физиологию как хирург — но без понимания разницы между артерией и веной он не сможет даже заказать правильные расходники.
И снова мимо ;) чтобы выбрать между артериальным и венозным катетером - нужен настоящий врач. Чтобы закупить одно или другое согласно плану - достаточно уметь читать. На упаковке написано же.
Кажется, мы говорим о разных вещах. Вы — о том, как выполнить разовое действие по инструкции. Я — о том, как понимать систему в целом, чтобы принимать осознанные решения.
Моя книга как раз и объясняет эту систему: от архитектуры и выбора технологий до процессов. Если хотите составить мнение не по заголовкам, а по сути — готов предоставить вам полноценный экземпляр. Если интересно конечно)
Почему вы отвечаете как ии?
А статья странная. Она как будто для неайтишных друзей айтишника (которому все эти термины прекрасно известны и точно не из таких статей на хабре), которые хотят понимать, что их товарищ там лопочет)
А может проще, продуктивнее и менее инфантильно почитать книги или хотя бы статьи в области, где вы работаете, причем, лучше на английском? Все (99%) "непонятные" слова ИТ-жаргона это английские термины, иногда слегка русифицированные. В плюс к пониманию терминов вы получите хотя бы начальные знания в области, где вы работаете и не будете говорящими попугаем, не понимающим смысла произносимого.
Вы правы, знание английского сильно помогает. Но моя задача — не стать разработчиком, а наладить коммуникацию между бизнесом и техникой. Книга как раз и помогает перестать быть «говорящим попугаем», дав понимание сути процессов, а не просто заучивание слов. Это экономит время команды и бизнеса.
"Представьте, что ваше приложение — это книга в библиотеке" - это суть? Понимание хотя бы основных принципов версионности, организации работы, архитектуры системы - это "стать разработчиком"?
Почему я, начав писать программы для медицины, читал книги по физиологии, лаборатории, организации медицинских процессов? Надо было "представьте, что ваши кровеносные сосуды - это железная дорога с паровозиками. Ишемия - это когда на рельсы упало дерево и паровозики не могут ехать...".
Детский сад. Гнать таких "менеджеров", "аналитиков". Позор.
Вы путаете два разных этапа обучения. Ваш путь — это путь углубления, когда специалист погружается в смежную профессиональную область. Это достойно уважения.
Но мой подход решает задачу на этапе входа. Когда человек впервые слышит слово «деплой», ему не нужна лекция про системы версионирования — ему нужно понять базовую суть, чтобы перестать паниковать и начать осмысленно участвовать в диалоге.
Сравнивать сложные медицинские процессы с «паровозиками» — это передергивание. Мои аналогии — это не замена знаниям, а первый шаг к ним. Пока вы предлагаете новичку читать «Биохимию крови», я помогаю ему запомнить, что «лейкоциты — это солдаты, которые борются с инфекцией». Без этого первого шага погружение будет сложнее.
Каков интеллектуальный уровень ваших читателей, если они не могут понять "Лейкоциты - один из видов клеток крови, которые выполняют функции борьбы с инфекцией" и им нужно говорить про солдат, паровозиков, библиотеки и рестораны?
Простой поиск в гугле по "клетки крови" дает
Клетки крови — это три основных типа форменных элементов, которые находятся в крови: эритроциты (красные кровяные тельца), лейкоциты (белые кровяные тельца) и тромбоциты (кровяные пластинки). Эти клетки производятся в костном мозге и выполняют важные функции: эритроциты переносят кислород, лейкоциты обеспечивают иммунную защиту, а тромбоциты участвуют в свертывании крови.
Чтобы понять это нужно быть врачом-гематологом, учиться 6 лет?
Чтобы понять статью в гугле "версионное управление" - нужно быть разработчиком?
Речь не об интеллекте, а о когнитивной эффективности. Мозг человека, незнакомого с темой, гораздо легче и прочнее запоминает информацию, если она «упакована» в яркий образ, а не в сухое определение. Ваше определение, безусловно, точное, но оно требует от новичка дополнительных усилий по расшифровке терминов.
Разные задачи требуют разных инструментов. Вы предлагаете человеку справочник, я — работающую картинку в голове. И для первого шага второе почти всегда эффективнее. Это, конечно, лишь мое ИМХО, и я никому его не навязываю. Ваша точка зрения мне ясна.
Ясно, ладно. "Специалист", не могущий понять простое определение и требующий паровозиков. Я бы очень не хотел такого видеть ни в моей команде, ни представителем заказчика. К себе такого не возьму или уволю, если проявится. От заказа с такими заказчиками - откажусь. Себе дороже.
Вот только картинка в голове может отличаться от реальности, и неизвестно, когда вылезет различие.
Такой человек может уронить прод и сказать: ничего страшного, задеплойте ещё раз.
Я б понял, если бы вы ребенку или там бабушке этими аналогиями объясняли, чем вы занимаетесь на работе. Странновато видеть, что человек, чьей профессиональной деятельностью является работа с тем, что под терминами скрывается, понимает эти вещи как аналогии с ресторанами и бульдозерами.
Странно, но этот «странноватый» подход называется «моделирование предметной области», и его используют как раз для создания общего языка между технарями и нетехнарями. Аналогии — это инструмент, а не признак уровня понимания. Аналогии — самый быстрый способ добиться понимания с коллегами из маркетинга, отдела продаж или заказчиком. Это не заменяет глубоких знаний, а убирает барьеры для совместной работы.
Я улыбался и кивал, не понимая ровным счетом ничего
Кул стори. Чувак пришел на работу, но даже терминов не знает.
Было именно так). Сейчас помогаю другим избежать этого.
А как же злая хрюша, которая отсеивает неудачников по формальным признакам?
«Злая хрюша» часто отсеивает не неудачников, а тех, у кого просто другой бэкграунд. Я даю людям карту, чтобы их оценивали по реальным компетенциям, а не по умению играть в слова. За незнанием терминов часто скрывается ценный для команды нетривиальный опыт.
Тут бы пример. Пришел на совецание к программистам филолог. Или медик. Зачем он туда пришел?
Интересный вопрос. Если я его правильно понял, отвечу так:
Филолог на совещании по голосовому помощнику поможет правильно построить диалоги, чтобы бот понимал не только команды, но и интонацию, и стилистику. Без него получится робот, с которым неприятно говорить.
Медик в команде, разрабатывающей медгаджет, объяснит, как врачи ставят диагнозы в реальности. Это убережет команду от создания «технически идеального», но клинически безполезного прибора
Это называется представитель заказчика. Или приглашенный эксперт. Им совершенно не обязательно понимать внутреннюю кухню программистов, тем более на дошкольном уровне. Не обязательно быть поваром чтобы оценить вкус блюда.
Совершенно верно — это представитель заказчика или приглашённый эксперт. Но даже эксперту нужно эффективно общаться с командой.
Мой личный пример: я пришёл в IT из госзакупок, где был сильным тендерным специалистом. Но на начальных этапах я не сразу понимал как разрабатываются мобильные приложения и о чем говорят разработчики. Мне не нужно было становиться программистом — но чтобы использовать свой экспертный опыт в тендерах, мне нужно было быстро освоить процессы разработки. Поэтому я написал книгу, которая позволяет быстрее понимать все процессы и быстрее влиться в коллектив.
Автор, а что по поводу "замержить пул-реквест" из первого же предложения? Пока в процессе перевода?
Спасибо, что выделили этот момент! Это не незаконченный перевод, а готовый пример из рабочего лексикона. «Замержить пул-реквест» — как раз и значит утвердить и объединить изменения в коде.
Дорогой автор, а в своём ли вы уме ?! Не надо пытаться в ИТ, если вы собираетесь мыслить аналогиями! Вот просто не надо!
Я не знаю как вам это объяснить... Никто же не пытается объяснить конструирование самолетов аналогиями из архитектуры или из автомобилестроения! Ибо даже если колесо автомашины и шасси МС-21 имеют что-то неуловимо общее - их назначение и функция сильно не совпадают!
Уж если вы хотите функционировать в профессии - дайте себе труд разобраться в том, что там происходит и какие законы действуют! Не можете - попробуйте свои силы в чем-нибудь менее demanding - например, в перетягивании каната... А создавать иллюзию понимания у дилетанта - не надо. И без вас есть масса курсов, где этих дилетантов пекут на конвейере... А нам потом в индустрии с ними жить...
Уважаемый коллега, вы невольно подтвердили главный тезис моей работы. Проблема не в аналогиях, а в том, что многие технические специалисты, подобно вам, считают: чтобы участвовать в диалоге об IT, нужно иметь соответствующий диплом.
Вы сравниваете с самолётостроением — и это прекрасный пример. Пилоту не нужно уметь проектировать шасси, чтобы эффективно управлять лайнером. Но он обязан понимать, что такое «угол атаки» и «турбулентность» — ровно так же, как менеджеру проекта нужно понимать, например, что такое «спринт» и «деплой», чтобы эффективно управлять продуктом.
Моя книга не учит «конструировать самолеты» и не ограничивается аналогиями. Её цель — дать «пилотам» и «авиадиспетчерам» общий язык для работы. Поэтому в ней, помимо объяснения логики через образы, есть главы про архитектурные паттерны, жизненный цикл продукта, языки программирования и методологии разработки — все то, что позволяет нетехническому специалисту осознанно участвовать в обсуждении архитектуры, оценке сроков и выборе стека технологий.
А бояться «дилетантов» — это странно для профессионала вашего уровня. Настоящий эксперт как раз умеет объяснять сложное просто. И именно такие специалисты, способные к диалогу, а не к отгораживанию, и создают по-настоящему сильные команды.
Когда пилота обучают, ему говорят: "Представь, что ты дуешь на чашку с чаем. Там поднимаются маленькие волны. Вот это и есть турбулентность." Или все-таки говорят про изменение скорости и плотности окружающего воздуха и изменении подъемной силы вследствие этого?
В книге после каждого технического объяснения (что такое деплой, API, микросервисы) идёт простая аналогия для закрепления. Это не замена знаниям, а способ сделать их доступными — как в вашем примере с турбулентностью, где физика следует за образом. Тут все почему то думают я только про аналогии говорю)) Это всего лишь инструмент)
Я, как говорится "вашу книгу не читал, но осуждаю ее". Нет претензий против изложения базовых понятий простым, доступным языком. Если это у вас есть - прекрасно! Действительно, мне не нужно, чтобы мой продавец, консультант или заказчик "был разработчиком".
Но ваши аналогии "магазин, библиотека, паровозики и зайчики" это ужас.
Спасибо за честность! Мои аналогии — не догма, а попытка найти общий знаменатель для людей из абсолютно разных сфер. Конечно, для опытного технаря сравнение с «рестораном» может резать слух.
Возможно, вы подскажете — как бы вы сами объяснили суть, например, деплоя или API нетехническому специалисту, чтобы он не просто кивнул, а действительно понял? Ваш опыт был бы крайне ценен. Я не вешаю на себя ярлык "Суперэксперта", просто пытаюсь донести сложное — простым языком.
API. Практически все современные системы состоят из двух частей: клиентской (front-end, фронтенд), с которой взаимодействует человек-пользователь и серверной (back-end, бэкенд), где данные хранятся, обрабатываются. Очень часто системы общаются между собой, например, бухгалтерской системе может понадобиться текущий курс доллара или системе планирования туристической поездки нужно узнать текущую погоду в каком-либо городе. Способ такого общения, форматы данных, адреса, к которым нужно обращаться называются API - Application Programming Interface.
как бы вы сами объяснили суть, например, деплоя или API нетехническому специалисту, чтобы он не просто кивнул, а действительно понял?
А зачем ему, правда? Ну он сможет не просто кивать, а с умным видом.
Идите, гм.. в сад! Я с чувством холодного бешенства отношусь к "эффективным менеджерам", которых с института убеждают что они могут управлять чем угодно - сегодня макарнной фабрикой, а завтра - нефтезаводом. И ладно бы все они были родственниками членов совбеза РФ - и претендовали бы сразу на должность зам.пред.правления! (видит бог, на этой должности уже можно ничего не делать, а просто регулярно приходить за зарплатой!).
Но если вы собираетесь реально взаимодействовать с командой - убирайте в юх свои аналогии, берите учебник, и разбирайтесь в теме. Команда простит вам некоторую поверхностность и отсутствие практического опыта. Команда не простит вам лицемерия, и попытки делать вид что вы в теме...
И да, я не любитель совка - ибо его застал. Но принцип подбора руководящих кадров оттуда: руководитель подбирается только с опытом работы в отрасли - горячо одобряю!
чтобы участвовать в диалоге об IT, нужно иметь соответствующий диплом
Смотря о чем диалог. И какая роль специалиста. Если просто кивать - диплом не нужен, действительно.
У меня паранойя или весь текст и комменты написала нейронка?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как понимать разработчиков через простые аналогии