Всем привет!

Меня зовут Татьяна и я старший технический писатель в компании Orion Innovation. В нашей уже немаленькой команде мы используем довольно обширный стэк инструментов и технологий, но наиболее востребованы и удобны в работе - XML-редакторы с поддержкой DITA архитектуры. Моя статья - для технических писателей. Особенно для тех из нас, кто, как и я, имеет гуманитарное образование. Для разработчиков, особенно фронтендеров, это может показаться элементарными вещами, но для техписов, возможно, будет полезной. 

Привет! Меня зовут Наталья и я DocOps-инженер в компании Yadro.

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

Немного о себе

Я окончила механико-математический факультет, во время учёбы занималась матмоделированием в области авиастроения, затем семь лет работала инженером по локализации и техническим писателем в Xsolla, потом полтора года в роли руководителя команды автоматизации, и вот я DocOps в компании Yadro.

Вступление

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

В сфере управления проектами в компании Orion Innovation я применял разные практики и сформулировал несколько выводов, которыми хотел бы поделиться.

Думаю, что многие пренебрегают процессом управления рисками, так как не понимают зачем уделять ему отдельное внимание и время. Кто-то может парировать, что вы просто не умеете готовить реестр рисков и на его обновление требуется совсем немного усилий, «минут 10». Так может быть и есть в небольшой сплоченной команде, в которой все друг друга хорошо понимают. Однако нужен ли формальный реестр рисков для такой команды? В большинстве же случаев эта активность, выполняемая по запросу сверху, превращается в нудный и затянутый процесс, в котором непросто увидеть пользу.  

Привет, меня зовут Татьяна, я — старший технический писатель в Центре разработки Orion Innovation. Недавно нам пришлось переводить в Agile крупный проект. Несколько Scrum-команд разработчиков, довольно обширный стэк документов, многие из которых устарели просто потому, что в каскадной разработке писатели не успевали их обновлять. Служба поддержки завалена жалобами от пользователей: «Но у вас же так написано, почему не работает?»

Сразу спойлер: интеграция техписов в Agile прошла успешно, хоть и не всегда гладко. Благодаря этому опыту, мы выработали несколько рекомендаций, которыми хочу поделиться.