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

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

Повторяю: у вас нет власти. Вы не можете никого заставить что-либо делать. Это не вопрос независимости. Работа вашего менеджера не в том, чтобы кого-то преследовать. Работа вашего менеджера состоит в том, чтобы поговорить с другим менеджером, который затем может попросить своих подчиненных помочь вам. Если она этого не хочет, значит, она не выполняет свою работу.

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

Обычно после составления оглавления (и получения его утверждения) я разделял все темы и мысленно «назначал» недостающие детали/пробелы людям, известным как штатные эксперты или инженеры-инициаторы. Я бы сказал им заранее, что мне потребуется X времени, чтобы осветить следующие детали, и включить все вопросы в одно и то же электронное письмо. Я сообщил им, что было 2 этапа: этап сбора информации, а затем этап редактирования для обеспечения точности.

Застенчивые недоступные инженеры? Нет проблем, если вы заранее отправите им электронное письмо со списком конкретных вопросов и оценкой времени. Большинство людей будут сотрудничать, если они знают, что это не бесконечная трата времени.

Иногда существуют настоящие языковые барьеры, поэтому вам могут понадобиться альтернативные источники. Но эти же люди могут захотеть просмотреть технические детали/точность проходов редактирования после того, как вы доработаете все руководство/документ. Магнитофон также очень помог (особенно, когда кто-то говорит о волосатых вещах, которые вы не можете понять с первого раза, и использует жаргон, с которым вы не живете, как они). Не говоря уже о бормотунах!

Одна вещь, которая мне очень помогла, это посещение пары совещаний по дизайну продукта (или что-то подобное в вашем случае), особенно если вы можете сделать это на ранней стадии. Таким образом, вы будете «настоящим», а не посторонним, о котором они могут даже не знать. Кроме того, вы можете заранее оценить, кто будет доступен. Это может или не может быть практичным в вашей ситуации. Заключать контракты — это здорово, но, как вы сказали, хитрость в том, что вы — аутсайдер, который должен производить как инсайдер.

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

Разработчики (или, если на то пошло, любые эксперты в предметной области), как правило, плохо реагируют на то, что люди спрашивают их о вещах, на которые МСП уже ответили. Это верно для технических писателей, тестировщиков, специалистов по поддержке клиентов и, возможно, других. Таким образом, ваша работа начинается намного раньше, чем документирование в основном работающей функции. Были ли функциональные спецификации? Обзоры дизайна? Обсуждение требований? Вы читали эти документы и ходили на эти встречи? Задавали ли вы вопросы о том, как эта функция будет работать на раннем этапе? (Нет, тогда вы не можете предвидеть все вопросы, но некоторые из них могут прийти вам на ум.) Вы участвуете в процессе ?

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

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

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

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

• Быть конкретной. "Как работает сервер?" широкий и расплывчатый; разработчик, вероятно, думает, что вы просите класс. «Как сервер обрабатывает слишком много входящих запросов?» это лучше.

• Покажи, что ты уже сделал. Можно ли хотя бы частично ответить на этот вопрос, используя программное обеспечение? Тогда сделайте это. «Я пытался отправить кучу запросов так быстро, как только мог перемещаться по вкладкам браузера, но не смог заставить его потерпеть неудачу» показывает, что вы пытались помочь себе. Или, если это не то, что вы можете разумно протестировать (вам потребуются десятки тысяч запросов, и вы не знаете, как написать код для скрипта), покажите фоновые усилия каким-то другим способом: «Я проверил дизайн spec, и я видел раздел о том, как мы должны справиться с этим случаем, но я не понимаю, что вы сказали о пулах потоков и очередях с приоритетом».

• Если у вас продолжают возникать одни и те же вопросы , спросите, как ловить рыбу: «Мне нужно знать, какой код ошибки мы вернем, если X, и я знаю, что спрашивал о коде ошибки для Y на прошлой неделе. можно посмотреть эти?" Иногда вы не можете, или это не стоит усилий, или это уведет вас в заблуждение, но демонстрация того, что ваш первый инстинкт — «попробовать понять это» вместо «спросить разработчика», приносит брауни баллы в моем опыте.

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

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

Ваш первый абзац противоречит сам себе:

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

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

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

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

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

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

Ненавижу говорить вам, что это не уникальная проблема. Даже если вы чей-то начальник, такое может случиться.

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

У вас в коробке как минимум два инструмента.

1] В любое время, когда кто-то может вас отшлепать, он это сделает. Помните это! Ну так что ты делаешь? Прогуляйтесь. Каждую неделю выбирайте время, которое вам больше всего подходит (меняйте день и время каждую неделю), подходите к каждому из разработчиков и начинайте задавать вопросы. Будьте сердечны. Скажи привет. Представьтесь. Объясните свою проблему и как они могут помочь с улыбкой. Скажи спасибо. Будьте максимально любезны и нежны, но твердите, что вам нужны ответы на ваши вопросы. Если не сейчас, то позже. Дайте понять, что вы здесь не для того, чтобы усложнять им жизнь. Если после обеда лучше, то хорошо. После обеда так. Если они продолжат вас обманывать, просто объясните, что руководство, скорее всего, будет задавать вопросы и что вы бы предпочли это сказать ?? чрезвычайно полезно, а не особенно полезно. Два других приема, которые помогают, — это говорить тихо, естественным тоном, чтобы никто другой вас не услышал. Так вы узнаете гораздо больше. Кроме того, если вы разговариваете с ними, становитесь так же низко или ниже, чем они. Я присел на корточки, чтобы это произошло. Улыбка. Будь дружелюбным. Через некоторое время вы можете быть удивлены тем, что они начинают рассылать подробности по электронной почте по ходу дела. Они знают, что поставлено на карту для вас и для них, и теперь вы являетесь членом команды. Это может занять несколько недель, чтобы действительно начать работать хорошо. Пока они понимают, что это не одноразовое поведение, они смягчятся. Они знают, что поставлено на карту для вас и для них, и теперь вы являетесь членом команды. Это может занять несколько недель, чтобы действительно начать работать хорошо. Пока они понимают, что это не одноразовое поведение, они смягчятся. Они знают, что поставлено на карту для вас и для них, и теперь вы являетесь членом команды. Это может занять несколько недель, чтобы действительно начать работать хорошо. Пока они понимают, что это не одноразовое поведение, они смягчятся.

2] Если вы не можете прогуляться, то еще одним отличным инструментом является подотчетность. Я ненавижу быть занозой в заднице (PIA), но иногда это ваш единственный вариант, однако он не должен быть вашим первым вариантом. Если вы отправляете электронное письмо, копия вашего босса. Прошу ответить-все. Если они не отвечают всем, перешлите любой ответ своему начальнику с копией обратно этому человеку. Сохраняйте все навсегда. То же самое с вашим боссом. Скоро все начнут понимать, что существует ответственность и что отсутствие ответа равносильно карьерному самоубийству. Конечно, вы, по крайней мере, задокументировали, почему у вас возникают проблемы при выполнении вашей работы. Вы можете объяснить это своему начальнику. Объясните, что вы оплачиваете часы, которые непродуктивны, и что вы предпочитаете, чтобы это было не так. В любом случае это хороший вариант, конечно, для CMMI, ISO и других причин, однако я предпочитаю вариант 1 лучше всего.

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

Вы заинтересованы в процессе разработки, и как человек, у которого есть свои собственные заинтересованные стороны, я бы сказал, что вы свинья, а не курица (тот, кто не просто вовлечен, но и привержен).

Включите себя в процесс управления проектами/Scrum. Посещайте статусные / стендап-совещания и сообщайте всей команде проекта, что ваш вклад заблокирован, что вы не выполните обязательство, которое было делегировано вам, и которое вы приняли в отношении следующего готового к выпуску релиза. Добавьте критерии приемки (требования) и практические задачи в тематические статьи, чтобы «определение готовности» этой истории включало ваш вклад.

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

Электронная почта — плохой способ планировать и выполнять задачи. Вам нужно поднять проблему перед своим начальником, который затем должен назначить встречу с начальником разработчиков. Цель должна состоять в том, чтобы определить некоторое определение «Готово».для разработчиков, при этом задача или пользовательская история должны быть помечены как выполненные только в том случае, если также соблюдены требования к документации (аналогично рекомендациям по кодированию, модульным тестам и т. д.). Это звучит как жесткий подход, но, о боже, это исключает любые аргументы или эмоции из обсуждения. После нескольких лет борьбы современные разработчики программного обеспечения пришли к соглашению, что качественные шаги, такие как статический анализ кода, модульные тесты и т. д., должны быть встроены в процесс, а не оставлены на волю случая. Документация по-прежнему отсутствует полностью, поскольку ее трудно автоматизировать, а также вопрос о том, сколько документации достаточно, до сих пор обсуждается. Но тем не менее, если ваша компания решила, что должна быть документация, то и эта задача должна быть встроена в процесс.

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

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

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

Другие люди описали шаги, необходимые для того, чтобы убедить людей, что вы знаете свое дело. Если вы сделали все это и все еще не можете получить ответ, попробуйте придумать ответ, который кажется правдоподобным, а затем отправьте его по электронной почте разработчикам и скажите: «Я думаю, что это правильно. Пожалуйста, подтвердите до <дата>, когда Я добавлю его в официальную документацию» .

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

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

Короткий ответ, я бы сказал, вы не можете «заставить» людей отвечать на ваши электронные письма...

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

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

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

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

Когда меня попросили предоставить, я (мог) почти почувствовать, что вы могли бы найти ответ самостоятельно.

Как говорится, на мед больше мух наловишь, чем на уксус.

В то же время я бы не стал ждать разработчика, если бы мой дедлайн подмаялся.

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

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

Но, возможно, именно так вы уже делали это.

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

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

Если вы не получили ответ, напишите их менеджеру что-то вроде: «Привет, я отправил Стиву электронное письмо с запросом этой информации. Мне это нужно к концу дня, но я еще не получил ответ, можете ли вы убедиться, что я его получу? "

Теперь вы привлекли к ответственности Стива и его менеджера.

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

При необходимости предъявите бумажный след.

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

Во-вторых, решите проблему с вашим боссом. Опять же, вы сделаете работу, но у нее могут быть некоторые стратегии. В какой-то момент вы достигнете момента, когда вы не получите то, что вам нужно вовремя, так что вы с этим делаете? Сколько времени разумно для вас, чтобы сказать: «Если у меня нет чего-то, мне нужно «x» времени до срока, как мы можем изменить график/расставить приоритеты?» Извините, но те, кто принимает решения, должны столкнуться с проблемой. Сосредоточьтесь на том факте, что вы хотите делать все вовремя, но у вас нет полномочий требовать от всех ответственности за получение необходимой вам информации. Документируйте все запросы и поставки.

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

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

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

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