Технический писатель в Scrum
Они говорят: переходим на гибкую разработку (Agile). Все будет просто супер. Они, разумеется, не технические писатели. В настоящее время я уже два года работаю на скрам-команды гибкой разработки в качестве инженера по технической документации (иначе говоря, техническим писателем). За это время я прошла несколько эмоциональных стадий: волнение, уверенность, смятение, разочарование, отчаяние, принятие - и снова уверенность. К этой последней уверенности я пришла, глядя, как мои коллеги по техническому перу начинают свой путь в командах гибкой разработки. В их глазах я вижу те же отчаяние и сомнение, что поразили некогда и меня. И, с сочувствием гладя их по плечу, я осознаю, какой путь я проделала, чтобы прийти к пониманию роли технической информации в гибкой разработке. Не бойтесь, говорю я коллегам. Все не так печально, как кажется. Напротив, скоро вы обнаружите, что все это весьма неплохо работает! В чем проблема?Первое, о чем спрашивает любой технический писатель: а как вообще писательство соотносится с гибкими разработками? В этой методологии у среднего участника скрам-команды есть всего одна роль: участник скрам-команды. Неважно, разработчик ты, тестировщик, технический писатель или спец по юзабилити, твоя роль в гибкой разработке - это участник команды. Идея заключается в том, что название должности не должно ограничивать члена команды в процессе разработки продукта. Сегодня член команды что-то разрабатывает, а завтра уже тестирует - в зависимости от своих навыков и текущих потребностей проекта. Идея сама по себе замечательная. Но что она означает применительно к писателям? Производство технического контента и управлением им - навык весьма специализированный. Я не могу писать код. Не могу создать автоматизированный тест и запустить его. А остальные члены команды, в свою очередь, не могут написать технический контент. Что делает технический писатель?Сочувствовать коллегам - дело, может, и неплохое, но думаю, им куда больше поможет не сочувствие, а нечто более полезное. Сделайте глубокий вдох - и читайте дальше. Возможно, эти советы помогут вам проложить путь к успешному старту скрам-команды. Обучите вашу командуКлянусь, что это правда: многие до сих пор думают, что инженеры по технической информации занимаются лишь тем, что вставляют какой-то текст в Word. Пару недель назад некий владелец программного продукта рассказывал мне, что контент создают разработчики, а я просто привожу его в правильный формат. К концу этого разговора мне едва не понадобилась «скорая». Такое мышление лучше истребить на корню. В самом начале проекта соберите всю вашу команду и ключевых игроков от заказчика - и покажите команде, кто вы и чем занимаетесь на самом деле.
Не нужно вдаваться в совсем глубокие подробности - положа руку на сердце, мы же знаем, что вся эта информация команде и заказчикам никогда не пригодится. Вам просто нужно снабдить их сведениями, достаточными для понимания, в чем ваша роль в процессе и сколько усилий вы прикладываете, чтобы выполнять вашу работу. Используйте баклог. Отслеживайте все, что связано с технической информацией в специальном баклоге, чтобы и вы, и остальная команда знали, что еще предстоит сделать. А сделать обычно нужно много чего - и позаботиться об этих задачах может только инженер по технической информации. Например, организовать книжные полки, упорядочить версии контента, переписать существующий контент в сценарии или другие виды документов. Даже если ваша работа - это «всего лишь документы», вы же тоже часть команды, и вам нужно будет отчитываться о своей работе. Не забудьте четко отметить критерии выполнения - чтобы вы могли указать свои достижения по итогам. Кроме того, здраво оценивайте ожидаемые объемы работы, чтобы на планерках вы могли реалистично соотносить с ними собственную скорость. Взгляните на вещи шире. Управление контентом - штука обособленная, как мы с вами уже отметили, но дело в том, что вы - больше, чем просто писатель. Несмотря на то, что ваша работа варится в собственном соку, вы не исключены из процесса напрочь. Каждый раз спрашивайте себя, какой вклад вы можете внести в общую конечную цель. Очевидно, что вы можете писать, но, как остальные члены команды могут помочь вам в сборе информации для документации, так и вы тоже можете вносить свой вклад в юзабилити, комментировать эскизы, выполнять качественное тестирование или проверять на соответствие стандартам. Чем дальше вы выберетесь за рамки технического писательства, тем станете заметнее - и тем полезнее, в конечном счете, для команды. Совершенно не обязательно строчить текст, забившись в уголок. Управляйте вашей скоростью. Управление скоростью - важная задача при планировании спринта. Многих технических писателей тут ожидают подводные камни. Допустим, в начале, в «образовательной сессии», вы уже объяснили всем, насколько ваша роль уникальна - тем осторожнее надо быть при управлении скоростью на индивидуальном уровне. Предположим, ваша команда состоит из пяти человек, работающих полный день - тогда их общую скорость мы примем за 100 баллов, а вам нужно внести 20 баллов своей скорости. Распределите их со всей тщательностью по задействованному на данном этапе функционалу, оцените, сколько времени вам понадобится на документацию - а также на не связанные с документацией задачи, где вы можете помочь. Как правило, времени хватит и еще останется в запасе. Когда вы внесете в свой лог все, что связано с документацией, пройдитесь по другим задачам и найдите себе достаточно работы, чтобы ваша скорость не падала. Так вы будете понимать, в какой степени вы загружены и сколько сможете сделать, а коллеги увидят в вас полноправного члена скрам-команды. Слушайте и говорите - в этом порядке. Никому не хочется выглядеть идиотом. Скорее всего, вы собираетесь еще на планерке спринта задать несколько вопросов. Так вот, если вы будете отвлекаться на свой ноутбук и телефон, то высока вероятность, что вы зададите не умный вопрос в подходящий момент, а просто выставите себя идиотом. Да, совещания могут быть ужасно скучными, особенно если вы слабо понимаете, что происходит, или обсуждение ушло в далекую от вас область. Но если вы сфокусированы, то у вас есть два преимущества: вы научитесь чему-то новому, что выходит за рамки вашей сферы, и сможете задавать правильные вопросы в правильное время. Так вы будете и выглядеть, и быть по факту более ценным членом команды. Кроме того, важно понимать, что для эффективной работы над документацией проекта вам нужно здраво оценивать, сколько усилий потребуется приложить и как распределить собственную скорость. Поэтому вы просто обязаны говорить и задавать вопросы, если хотите хорошо сделать свою работу. Подойдите к этому с умом. Пишите позже. Самый большой подводный камень, с которым сталкиваются технические писатели при гибких методологиях разработки, заключается в том, что продукт постоянно меняется в процессе работы над ним, и если мы документируем все прямо по мере разработки, то время от времени приходится просто выкинуть все написанное ранее и переписать заново. Такова реальность, и с ней приходится жить. Что я могу сказать по этому поводу? Замечательно, конечно, иметь документацию прямо одновременно с разработкой, особенно это хорошо для поддержки последовательных релизов, но в конечном счете, техническому писателю при гибкой разработке приходится выполнять куда больше работы, чем при любой другой методике. Чтобы сделать свою эффективность максимальной, выжидайте с написанием документации до последнего. Если ваша работа по спринту состоит из двух разработок, которые нужно задокументировать, и одного не связанного с разработками документа, сфокусируйтесь сначала над тем документом, что с разработками не связан, и пусть коллеги-разработчики пока занимаются своим продуктом. Ждите до разумного предела, прежде чем начать документирование, потому что все, что сделано изначально, тысячу раз может измениться (например, названия всех кнопок). Это вопрос тонкий, потому что сильно отставать от процесса вам тоже нельзя, и тем не менее - чем дольше вы подождете, тем выше шансы, что в будущем вам меньше придется переписывать ваш документ. И что теперь?Приступайте. Да, вы будете спотыкаться, но сама суть скрам-методики в том, чтобы изучать и адаптироваться. Задумайтесь над этим и сделайте правильные выводы. Гибкая разработка рассматривает каждую ситуацию как уникальную, и вам нужно будет самостоятельно выяснить, что лучше всего подходит вашей скрам-команде. Не забудьте по окончании проекта встретиться с другими членами команды и выяснить, что можно улучшить в вашей роли и ваших методах, чтобы вы стали и эффективнее, и полезнее. Относитесь ко всему не предвзято и позитивно - и вы еще удивитесь, как хорошо гибкая методология может работать на вас.
Об авторе Сара Джонсон. Я специалист по техническим коммуникациям компании CA Technologies, работаю в городе Фрамингаме, штат Массачусетс. Техническим писателем я проработала десять лет, а с гибкими технологиями знакома три года. Хотя моя работа в основном сфокусирована на создании контента, я очень интересуюсь современными трендами в потреблении и представлении информации, которые появляются вместе с новейшими технологиями и инструментами. Я чемпион гибкой методологии и работаю совместно с другими техническими писателями, вырабатывая стратегии успешной интеграции писателей в скрам-команды в качестве специалистов по обобщению информации. В свободное время люблю читать и гулять с собаками.
Оригинал статьи: http://www.agileconnection.com/article/writing-agile-world Перевод: Александра Родсет
|
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
