Публикации
На заметку руководителю: Развитие карьерной лестницы технического коммуникатора
12.02.2016
Алисса Фокс, директор по разработке информации и программному управлению компании NetIQ Corporation, обобщает свой опыт по управлению продвижением технических писателей в компании. Из статьи руководители предприятий узнают, по каким критериям организовать карьерные возможности для своих технических писателей, а технические писатели смогут свериться, не пора ли им просить повышение и что нужно делать, чтобы претендовать на более высокие карьерные уровни.
Мы продолжаем слышать об огромном количестве организаций, в которых нет чётко определённого карьерного пути для сотрудников, занятых в области технических коммуникаций. И даже среди тех, где есть «карьерная лестница», по которой персонал может подниматься, масштаб и критерии часто неясные, или, что ещё хуже, устаревшие. Читать дальше…
На заметку руководителю: Бюджетирование команды по разработке информации
27.11.2015
Алисса Фокс, директор по разработке информации и программному управлению компании NetIQ Corporation, рассказывает о том, как продумать бюджет для успешной работы команды по разработке информации. Статья будет полезна руководителям отделов технической документации, менеджерам ИТ-отделов или менеджерам проектов.
Понимание и тщательное отслеживание затрат и доходов, связанных с вашей командой по разработке информации помогает вам ответственно участвовать в формировании общей чистой прибыли вашей компании. Рассмотрите следующие области, когда определяетесь с затратами на следующий финансовый год.
Программное обеспечение, «железо» и инструменты
Выделение средств на покупку инструментов делается не для удовольствия – это необходимость. Если вы не планируете смену основных инструментов, эта бюджетная категория будет в основном включать расходы на обновления или продление подписки на облачные сервисы и техническую поддержку. Однако в зависимости от размера вашей команды стоимость, скажем, обновления FrameMaker, может быть значительной. Эта категория должна включать не только инструменты для авторинга, но и другие платные инструменты, такие как программы для создания графики, софт для работы со скриншотами или программы для совместной работы, которые используются вашей командой. Читать дальше…
Эджайл и технические коммуникации: задаче-ориентированный контент в функцие-ориентированном процессе
20.08.2014
Мы продолжаем уже знакомую вам серию статей от Алиссы Фокс. Она детально углубляется во все тонкости эджайл-процессов и создаёт публикации, чтобы предостеречь нас от возможных ошибок.
Как я уже говорила в статьях Эджайл и технические коммуникации: командный подход ранее в этом году, авторы должны включать задачи своей работы в те же пользовательские истории, которые включают задачи отделов разработки и контроля качества. Такой подход гарантирует, что каждая пользовательская история действительно будет завершена в конце спринта, и помогает членам эджайл-команды из всех функциональных областей работать вместе, чтобы создавать «потенциально готовый к релизу» продукт в каждом спринте.
Несмотря на очевидные преимущества командного подхода, если вы не будете осторожны, структура эджайл-процесса может диктовать, какой контент вы будете писать. Поскольку команды часто попадают в ловушку, определяя пользовательские истории как функции, ваш контент может попасть в ту же ловушку – вы в конечном итоге задокументируете продукт, а не начнёте решать проблемы ваших пользователей с продуктом. Эта статья предлагает некоторые размышления для создания ориентированного на задачи (т.н. «задаче-ориентированного») контента, помогая сфокусировать контент на том, что необходимо пользователям для работы. Читать дальше…
Эджайл и технические коммуникации: работа с удалёнными командами (часть 2)
21.05.2014
Удалённая работа – актуальная и часто обсуждаемая тема. В нашей сегодняшней публикации мы попробуем помочь руководителям глобальных команд решить некоторые проблемы, возникающие при организации удалённой работы.
Знакомимся с членами команды
Некоторые знания о культуре удалённой команды помогут вам предугадать, как они будут взаимодействовать с другими (как с руководителями, так и коллегами) и как их личная жизнь будет пересекаться с работой. Некоторые культуры более иерархичны, некоторые менее. Понимание взаимоотношений различных уровней – это ключ к возможности сотрудничать с ними на их условиях. Это также поможет вам увидеть картину их правил, что необходимо, если вы хотите понять, почему возникло сопротивление к новым процессам и процедурам. И это даст вам возможность работать с ними, чтобы выявить сильные стороны обеих команд.
Возможно, эффективным методом для поддержания гармонии с другими членами команды будут частые встречи один на один или небольшие групповые совещания. Регулярные встречи с членами вашей команды внутри группы – гарант того, что никто не будет чувствовать себя брошенным; они также помогут установить связи, которые помогут вам в трудную минуту. Читать дальше…
Эджайл и технические коммуникации: работа с удалёнными командами (часть 1)
19.05.2014
Алисса Фокс продолжает серию статей, посвящённых эджайлу. Сегодня мы рассмотрим проблемы организации удалённой работы в команде и пути их решения.
Все чаще и чаще мы видим команды, разбросанные по всему миру. Все большее число предприятий функционируют таким образом по целому ряду причин. Всем, кто работает в эджайл-среде, полезно выяснить, как лучше решать проблемы, связанные с моделью глобальной команды.
Трудности работы с удалёнными командами
Часто в удалённой команде встречается ситуация «мы против них», особенно когда две команды собираются вместе в результате слияния. У вас вдруг оказываются большие команды по крайней мере в двух местах, и несложно забыть, что команда где-то в другом месте является частью вашей глобальной группы. Кроме того, если у команд в разных местах разные фоновые знания, различные рабочие процессы и разные культуры, трудность налаживания процесса совместной работы растет в геометрической прогрессии. Читать дальше…
Работа на несколько эджайл-команд (часть 2)
16.04.2014
Заканчиваем статью Алиссы Фокс, посвящённую одному из аспектов эджайл-процесса. Публикация заставляет задуматься, а не ввести ли эджайл-процессы в своей компании. Тем более что выбор среди возможных стратегий довольно велик.
Когда вы работаете на несколько команд, вы можете тратить 4-5 часов в неделю (или больше) на совещания для каждого назначенного проекта. Переговорите с руководителем или менеджером, чтобы распределить нагрузку таким образом, что вы можете делегировать обязательства посещений совещаний другим. Вот несколько предложений:
- Участвуйте только в совещаниях, которые относятся к самому приоритетному проекту на данный момент.
- Попросите человека, проводящего совещания, отправлять отчеты по электронной почте, чтобы помочь тем, кто не может присутствовать на каждом заседании для каждого проекта.
- Попросите руководителя или менеджера посещать некоторые важные встречи, когда вы не можете.
- Перестаньте посещать ненужные встречи. Даже если исторически сложилось, что вы присутствуете на определенного рода встречах, если вы не получаете от них достаточно, чтобы расширить свои знания о продукте или внести вклад в контент, над которым вы работаете, возможно, ваш лучше потратить это время на что-то другое.
- Всё больше и больше распределенных команд работают в эджайл-среде. Многие команды используют онлайн-инструменты для совместной работы для проведения совещаний и создания постоянных отчётов об обсуждениях. Рассмотрите возможность использования онлайн-инструментов для совместной работы для одной или нескольких ваших команд, что позволит вам, если вы пропустите встречу, проверить запись позже.
Работа на несколько эджайл-команд (часть 1)
14.04.2014
Мы продолжаем публикации на тему эджайл-разработки. Сегодня Алисса Фокс поделится опытом, как организовать одновременную работу над несколькими проектами без ущерба для качества.
Обзор
Казалось бы, клише «делать больше с меньшими затратами» в большинстве компаний сегодня является суровой реальностью. Людям надо делать больше, а времени и средств на это у них меньше. Для софтверных компаний один из способов это осуществить – частое и постоянное движение ресурсов между несколькими проектами. Когда моя команда начала использовать процессы эджайл-разработки, мы долго искали информацию о том, как использовать этот процесс при работе на несколько эджайл-команд. Мы обнаружили, что большинство писателей, занимающихся эджайл-разработкой, работали всего с одной командой разработчиков. Как у «плавающих» писателей, у нас теперь есть уникальные проблемы в эджайл-разработке.
Эджайл и технические коммуникации: командный подход (часть 3)
07.03.2014
В завершающей части статьи речь пойдёт о сворминге – что это, и чем хорош этот подход в эджайл-разработке, о работе над ошибками, а также о том, как допускать как можно меньше ошибок при командной работе и, таким образом, копить как можно меньше «технических задолженностей».
Сворминг
Чтобы командный подход стал успешным, инженерам по качеству и членам группы разработки информации нужны хорошая поддержка и обучение, которые помогут им адаптироваться к быстрому темпу эджайл-разработки. Тесное сотрудничество внутри команды может потребовать от ее членов освоения новых навыков, и действительно важно дать им время для этого. Одним из способов это осуществить является сворминг (от англ. Swarming — роение, обозначает совместную работу «всем скопом»).
Эджайл и технические коммуникации: командный подход (часть 2)
05.03.2014
Представляем вам продолжение статьи Алиссы Фокс о работе команд по эджайл-методологии. Сегодня вы узнаете, на ком лежит ответственность за результат при командном подходе, и о том, как обеспечить рациональное использование рабочего времени каждого члена команды вне зависимости от его роли и от времени выполнения своих функций представителями других ролей в команде.
Качество — это ответственность всей команды
Наряду с тем, что использование командного подхода, когда участвует вся команда целиком, даёт множество внутрикомандных преимуществ, наиболее очевидным внешним преимуществом является повышение качества продукта. Вся команда ответственна за разработку, тестирование и документирование по каждой из пользовательских историй до тех пор, пока спринт не будет окончен. Инженеры по качеству направляют эти усилия таким образом, чтобы вся команда работала над обеспечением выполнения всех этапов спринта.
Мы обнаружили, что для достижения наших целей в каждом спринте нам необходимо как можно больше автоматизировать тестирование. Автоматизированное тестирование быстрее, надежнее и менее подвержено ошибкам. Инженеры по качеству взаимодействует с группой разработки, чтобы обеспечить выполнение модульных тестов (unit tests) и повысить внимание к моментам, в которых существуют пробелы. Инженер по качеству должен также направлять усилия на разработку и автоматизацию приемочных тестов (acceptance tests), а также на выполнение исследовательских тестов (exploratory tests). Другими словами, ручное тестирование — это не самый гибкий (agile) способ получения высококачественного продукта. Для получения дополнительной информации о гибком тестировании и различных видах тестирования смотрите блог Лизы Криспин (Lisa Crispin) www.lisacrispin.com.
Эджайл и технические коммуникации: командный подход (часть 1)
03.03.2014
Продолжаем публикации из данной серии. Сегодня мы узнаем, какие ошибки можно допустить даже при введении принципов скрама в команде. Своим опытом поделилась Алисса Фокс, директор по производству информации и программному менеджменту в компании NetIQ, Хьюстон, США.
В предыдущих статьях «Эджайл и технические коммуникации» я рассказывала о преимуществах, которые эджайл-разработка даёт техническим коммуникаторам, особенно в отношении такого понятия как «скрам». В то время как «базовый» скрам поддерживает рабочий процесс и помогает синхронизироваться с остальной частью команды, командный подход к разработке в рамках скрама еще более укрепляет нашу роль в команде, всесторонне повышает эффективность коллективной работы и улучшает качество продукта и документации.