Эджайл и технические коммуникации: 4 обязательных пункта, чтобы стать членом эджайл-команды (часть 1)

20.01.2014

Мы продолжаем цикл статей, посвящённых такому понятию, как эджайл. Сегодня речь пойдёт о том, почему технический писатель должен стать частью команды и как это сделать.

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

Говорите

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

Говорите, причём детально, на конференциях; они предоставляют ??шанс общаться с инженерами по развитию и контролю качества (QE) на плановой, регулярной основе. Помните, что во время конференции вы должны дать – и получить – подробную, конкретную информацию. Будьте прямы, не стесняйтесь, если информация, которую дают другие, не в полной мере удовлетворяет вашим потребностям. Запросите больше деталей.

Например, если вы объявляете «Я создаю справку для программы Feature X» вы не вовлекаете остальную часть команды. Вам нужна помощь или дополнительная информация для создания справки? Вы обнаружили проблемы или ошибки, которые мешают завершению вашей задачи? Не нужно ли сейчас другому члену команды что-либо сделать? Лучше, если встреча будет строиться как-то так: «Я почти завершил создание структуры справки для мастера, который использует программа Feature X. Разработчик Салли, мне нужно объединиться с вами, чтобы показать, что я сделал в файле соответствия, и мы смогли подключить справку к коду страницы мастера. Я также добавляю эти темы в оглавление файла .chm».

(продолжение следует)

Источник: Agile and Tech Comm: Four Must-do’s to Become a Key Agile Team Member

Тэги: командная работа, организация работы, роли, советы, эджайл