Как научиться лучше общаться с коллегами из другой профессии?

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

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

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

Я думаю, что более реалистичный способ общения с программистами для непрограммиста, который просто хочет понять наиболее распространенные концепции и проблемы, связанные с созданием программного обеспечения, - это обычные 1:1 .

Справку о том, как это сделать, можно найти в отличной статье The Update, The Vent и The Disaster . Эта статья написана с точки зрения менеджера команды разработчиков, но, по моему опыту, подобный подход также работал в сотрудничестве между клиентом/дизайнером и программистом, как вы описываете.

... Я не утверждаю, что каждый раз 1:1 — это мучительное занятие по обнаружению глубоко скрытых возникающих бедствий, но вы действительно хотите создать еженедельное место, где может незаметно появиться недовольство. 1:1 — это ваш шанс проводить еженедельное профилактическое обслуживание, а также следить за состоянием своей команды.

...Звук, окружающий успешный режим 1:1, - это тишина. Все выслушивание, вопросы и обсуждения, которые происходят во время 1:1, являются профилактическим обслуживанием со стороны руководства. Вы увидите, когда интерес к проекту начнет ослабевать, и примете меры до того, как это перерастет в неудовлетворенность работой. Вы услышите о напряженности между двумя сотрудниками и модерируете дискуссию до того, как она перерастет в крики на собрании. Ваша награда за культуру здоровых отношений 1:1 — явное отсутствие драмы.

• ^{Сильной стороной вышеприведенной статьи является то, что она самодостаточна , в том смысле, что, помимо объяснения преимуществ, она также предоставляет ряд практических рекомендаций, позволяющих начать практиковать обычные 1:1, не копаясь в других источниках (хотя и в поисках дополнительная информация не помешает, знаете ли).}

С регулярными занятиями 1:1 вы сможете выбрать и сосредоточиться на изучении конкретных тем, которые имеют особое значение в каждый конкретный момент. Если вы сделаете это правильно — если будете говорить, спрашивать и внимательно слушать, — у вас будет достаточно времени, чтобы найти и изучить необходимые ресурсы, не давя на непредвиденные срочные дела: « Ваша награда за культуру здоровых 1:1 — явный недостаток драмы» .

_{Что касается книг, поскольку вы упомянули Code Complete , вероятно, вы не ошибетесь, используя его в качестве общего справочника (здесь я говорю о втором издании, которое я изучал). Это шедевр, фундаментальный и хорошо представленный обзор профессиональной разработки программного обеспечения, дающий глубокий анализ каждой мыслимой области. Поскольку она у вас уже есть, просмотрите главу о методах совместной разработки : насколько я помню, она была наиболее убедительной из всего, что я читал по этим вопросам до сих пор.}

_{Code Complete — действительно глубокий ресурс, отличный для тщательного изучения, но именно из-за этого я бы не стал рекомендовать его кому-то, кто нуждается в быстром введении в концепции разработки программного обеспечения. Что касается последнего, я бы предпочел «Факты и заблуждения программной инженерии» — небольшую, легко читаемую книгу. Ссылки, представленные в каждом разделе, позволяют при необходимости более глубоко изучить тему. Рекомендуемое чтение для тех, кто заинтересован в правильном программном обеспечении.}

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

Для общения важнее понять образ жизни другого человека или группы, чем обязательно знать основные моменты всех ступеней их профессии. Я бы сосредоточился на:

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

• Обнаружение жаргона — в такой работе ТОННА жаргона. Инструменты, языки, процессы, методологии, модели и многое другое — все они имеют уникальные имена. Некоторые охватывают всю отрасль (поставьте перед ним букву J и, вероятно, это что-то связанное с Java), некоторые уникальны для офиса (например, отчет TPS в офисных помещениях). Когда мне приходилось вмешиваться сюда, Википедия была моей первой линией защиты, за которой следовали терминологические словари и внутренние сайты, определяющие процессы.

• В частности, Code Complete — это интересное чтение, потому что оно посвящено разработке хорошего программного обеспечения. Это может быть хорошим ресурсом для этого, так как это все о хороших способах делать вещи, а не о том, как делать основы. Одна вещь, на которую следует обратить внимание, это то, что у любой группы разработчиков программного обеспечения будут свои собственные методы работы, которые могут соответствовать или не соответствовать передовой практике, поэтому будьте осторожны с односторонними предположениями, основанными на книге, подобной этой.

• Поговорите с программистом и клиентом . Иногда знать все о том, как кто-то выполняет свою работу, вредно. Важная часть состоит в том, чтобы быть уверенным, что вы общаетесь четко и оставляете им возможность делать то, что они делают, не создавая препятствий из-за невежества. Много говорите о том, почему вы хотите делать то, что хотите, спрашивайте рекомендации, спрашивайте отзывы о том, были ли вы ясны, просите переформулировать свой запрос или предлагать то же самое - и спрашивайте, почему, почему, почему.

• Попросите засвидетельствовать работу - я обнаружил, что в разработке программного обеспечения есть стиль работы и волшебная химия в том, как человек работает в этой области, которую невозможно обобщить ни в одной книге. Пещера ботаников является ее частью, но это еще не все, и может случиться так, что только пройдя ее, вы поймете, каковы настоящие болевые точки и славные моменты работы. К вашему сведению — Rands in Repose — неплохой сайт для получения дополнительной инсайдерской информации о разработчиках, но он часто может использовать краткие или предполагаемые культурные метафоры, которые могут быть не универсальными для постороннего… не уверен — я когда-либо читал его только с взгляд инсайдера.

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

Вместо этого я бы предложил просто спрашивать о терминах, которые вы не понимаете, по мере их появления или записывать их, если не обязательно, чтобы вы сразу знали их определение, а затем гуглить их. Часто, когда вы изучаете значение одного слова, вы сталкиваетесь с родственными словами, которые не понимаете, и можете спросить о них или найти их в Google.

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

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

Здесь есть несколько отличных ответов на (оригинальный, конкретный) вопрос, но в настоящее время:

Что я могу сделать, чтобы лучше понять наиболее распространенные понятия из другой профессии, чтобы я мог более эффективно общаться и работать с профессионалами и коллегами из этой области, не изучая их профессию?

Я бы предположил, что это пример более широкой ситуации, с которой я часто сталкивался, и не только в индустрии программного обеспечения. С моей точки зрения, цель ОП — создать эффективную многопрофильную команду в кратчайшие сроки.

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

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

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

• у нас есть собственная вики, которая используется для определения жаргона, терминологии, рабочих процессов и процессов. Это часть того, что мы делаем надежно, но это отличное место для начала.
• мы отправляем людей на (формальные) учебные курсы (введение в XXX)
• у нас есть случайные короткие презентации о том, как/почему люди работают определенным образом

Для небольших, гибких (в смысле, не связанных с кодированием!) команд, которые зависят от технических экспертов, хорошо работающих вместе, эти подходы могут помочь сократить время обучения.

Однако я бы предположил, что все «фракции» команды должны встретиться посередине, чтобы это было эффективно.

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

Хотя есть много хороших книг по разработке, одна из лучших серий книг, которые я когда-либо видел, чтобы помочь новичкам и людям, просто интересующимся разработкой, освоить жаргон и на самом деле немного узнать о разработке, — это серия Head First от O'Reily. .

Я включил несколько моих любимых, чтобы поделиться с учащимися ниже

1. Head First Design Patterns — отлично подходит для изучения основ шаблонов проектирования, которые разработчики постоянно используют.
2. Head First Software Development — начните здесь, чтобы получить отличный обзор процесса разработки программного обеспечения и жаргона
3. Head First Programming — это руководство для учащихся, в котором используется Python, но это также отличное место для начала.
4. Head First Object Oriented Design and Analysis — отлично подходит для более глубокого понимания этих методов, которые часто возникают при работе с разработчиками.

Теперь я знаю, что поначалу эта серия книг может показаться немного нелепой, но, поверьте мне, они эффективны и действительно интересны для чтения. Если бы мне пришлось выбирать, с чего бы вам начать сначала, будь то книга по разработке программного обеспечения или книга по программированию, просто чтобы получить правильный жаргон и процесс при работе с вашим разработчиком.

Надеюсь, это поможет.

Если я прав, то я считаю, что вы не собираетесь писать длинные коды для проекта. Ваша главная цель — время от времени координировать свои действия с опытными разработчиками.

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

В качестве технических руководителей вы можете воспользоваться некоторыми хорошими книгами по Ruby/Python или даже некоторыми онлайн-курсами, которые можно найти в Интернете. Проверьте http://codeacademy.com/ -> тоже хорошо для начала. Вы можете вики написать такой текст об Agile-разработке Agile Development

Я считаю, что эти пункты помогут вам не только в недавнем проекте, но и при управлении другими проектами.

Краткий ответ: Спросите свой колледж программистов об этих темах, которые могут вас заинтересовать. Я надеюсь, что у вас дружелюбная среда, и он будет более чем счастлив направить вас на правильный источник.

В дополнение к классической книге "Code Complete" настоятельно рекомендую ознакомиться с книгой " Facts and Fallacies of Software Engineering" . Эта книга является своего рода откровением и содержит ряд достоверных фактов, подтвержденных статистикой и исследованиями.

Практика создания программного обеспечения — это технология «новичок в мире». Хотя это может показаться не так для тех, кто проработал в этой области большую часть своей карьеры, в общей схеме профессий разработчики программного обеспечения являются относительными «новичками». В короткой истории области программного обеспечения было выявлено множество фактов и обнародовано множество заблуждений. Этим фактам и заблуждениям и посвящена эта книга.

Однако, в зависимости от требований приложения, над которым вы будете работать, вам также может понадобиться книга для конкретного фреймворка/языка.

Я хотел бы лучше понять ремесло программиста, чтобы улучшить общение с моим программистом, а также с клиентом.

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

Что я могу сделать, чтобы лучше понять наиболее распространенные понятия из другой профессии, чтобы я мог более эффективно общаться и работать с профессионалами и коллегами из этой области, не изучая их профессию?

Вы можете заглянуть в SDLC , который может помочь с большими частями ИТ-проектов, хотя у меня было бы больше искушения предложить знать жаргонные термины, а затем говорить о них в социальной среде, чтобы вы могли понять, что они означают. Kludge, hack и patch — это всего лишь несколько слов, которые, как я полагаю, могут быть легко истолкованы неправильно, если не знать контекст их использования. Ключевым моментом здесь будет использование жаргона, который может быть легко известен, а может и нет. Другой способ — рассмотреть возможность изучения различных компаний в рамках вашей специализации, а также знание множества аббревиатур.

Не стоит недооценивать ценность простого разговора с коллегой-программистом.

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

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

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

В дополнение к другим предложениям книги я бы порекомендовал Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology , в которой описывается ход (вымышленного) программного проекта с точки зрения дизайнера UX. (Эллен Айзекс) и его разработчик (Алан Валендовски), трудности, с которыми они сталкиваются, и компромиссы, на которые они идут, поскольку они должны работать вместе для достижения общей цели.

Как программист, я заметил, что причина напряженности в общении с непрограммистами довольно проста.

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

Большинство людей не думают и не общаются таким образом.

Например, кто-то из отдела продаж может предложить: «Вы знаете, что могло бы помочь, новый инструмент для привлечения потенциальных клиентов!»

Пользователь пользовательского интерфейса думает: «Это будет выглядеть так», без какой-либо определенной точности. Он будет во многом полагаться на свое творческое/художественное чутье и, если он хорош, на надежные принципы дизайна, подкрепленные исследованиями и данными.

Программист подумает: «Как будут генерироваться лиды? Как их хранить? Как их представлять? А как насчет безопасности? Какой тип безопасности? Простое шифрование на транспортном уровне или шифрование данных? Какой тип шифрования? Какой тип блока? режим шифрования?» и т.д. и т.п.

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