Здравствуйте. У Вас отличная статья, что называется, о наболевшем! Я столкнулся со всеми перечисленными Вами пунктами, но выходил из ситуации самостоятельно. Если позволите, попробую кратко изложить свой опыт в режиме «что делал-что получилось», может, кому-то пригодится.
Причина 1. Нет включения в командную работу. Самая рядовая, потому что огромное число работодателей не в курсе, что делает тех.писатель. Более того, данная позиция зависит от специфики компании/продукта. На моей самой первой работе так и было.
Нет, он не должен самостоятельно напрашиваться. Не должен сам писать своему менеджеру и проситься на митинг. Если менеджер приглашает разработчика – создателя фичи – на демо, почему он не приглашает человека, который будет объяснять, как эта фича работает, – техписателя?
Ну здесь, наверное, не напрашиваться стоит, а уверенно донести мысль, что считаешь необходимым свое присутствие на всех мероприятиях команды, объясняя зачем это нужно в контексте твоей работы. Если тимлид/начальник не слышит после первого обращения, можно не переживать — из такой команды бегут и разработчики. Что делал я: вежливо и уверенно объяснял, что я должен присутствовать на этих мероприятиях. Результат: со следующей недели я уже участвую во всех совещаниях, в том числе, в неформальных переговорах на кухне.
Причина 2. Нет обратной связи. Очень вытекает из первой причины. Не понимают, кто такой тех.писатель, и по каким критериям его оценивать. Самое очевидное — наличие документа. Документ готов — хорошо, но читать его нет времени. В этом случае также ничего постыдного нет настойчиво просить ознакомиться с документом. Что делал я: показывал отдельные топики всем, кому мог, когда видел, что время и обстоятельства располагают. Результат: нашел общий язык с разработчиками, после чего они сами в последующих кейсах просили почитать/ознакомиться.
Причина 3. Нет цели. Здесь работа обоюдная: и тимлида/начальника, и писателя. В университете учат всегда в рефератах/курсовых начинать с цели работы. То же самое и на профессиональном поле. Первое, что нужно уяснить любыми возможными средствами — для кого и зачем пишем документ.
У документации должна быть цель. Документация призвана решать конкретную проблему конкретного человека. Будь то пользователь-начинашка, который ищет кнопку “Сделать хорошо” в интерфейсе, или разработчик, которого подключают на новый проект, – документация должна помочь такому пользователю или разработчику.
Что делал я: буквально надоел менеджменту среднего звена своими вопросами, кто же будет пользоваться разрабатываемым документом, и для чего я работаю в данный момент. Результат: со временем (не сразу!) стал четко разграничивать документы по проектам с указанием степени их значимости и равноценно ответственно относиться к разработке каждого. Вроде как, даже мотивация появилась расти дальше.
Причина 4. Нет контроля. Организовывать контроль самому себе — единственный верный выход из данной ситуации. Что делал я: попытался декомпозировать поток задач на листке бумаги, а уже основательно по каждой буквально сел на шею начальнику. А также начал сам отчитываться по корпоративной почте за каждое выполненное поручение в рамках своей же декомпозиции. Результат: начальник в курсе, на какой стадии сейчас ведется разработка документации. Вся переписка на сервере корпоративной почты — можно доказать, чем я занимался и в какой день.
Причина 5. Нет ценности. Здесь мне пришлось тоже брать быка за рога, ибо ненавижу находиться в состоянии потерянности. Что делал я: перестал сам думать, что моя работа никому не нужна. Глубже изучил предметную область, которую документирую, чаще обращался с вопросами к разработчикам и лиду/начальнику. Проявлял жаркую любознательность по каждому техническому затыку со своей стороны (по технологическим стекам изрядно надоел вопросами аналитику). Результат: спустя два месяца не просто говорил на одном языке со всем отделом, но и имел наглость предложить свое видение по тому или иному вопросу.
Вывод: проявляйте инициативу. Забудьте, что инициатива наказуема. Не поощряется здесь — выстрелит в другом месте. Возможно, мой опыт слишком субъективный, и мне просто везло с руководством среднего звена (удавалось до них достучаться), но уверенность и понимание, чего хочешь именно ты, города берет, в чем я убедился на последующих проектах. Из компании, на опыт в которой была отсылка, я уже, кстати, ушел.
Напоследок я бы выделил шестую причину, почему тех.писатель уходит, и она может быть более распространена в проф.среде и менее очевидна на первый взгляд. Причина 6. Нет путей развития как специалиста. Я очень рвался работать в серьезных системах по документированию и практиковать на реальных кейсах подход docs-as-a-code, но компании этого не надо. Всех устраивают отлаженные бизнес-процессы здесь и сейчас, но почему-то на рынке труда на позиции senior почти везде просят уверенные знания Madcap Flare, Framemaker, Robohelp, oXygen и многие другие. А где им взяться, если твоя текущая компания даже не собирается пробовать в эту сторону, не говоря уже про настройку и запуск в рамках производственного процесса? На одних триалах далеко не уедешь, а вся текущая работа настолько выматывает за день (10-12 часов), что вечерами делать свои петы — дело очень тяжелое и далеко не всегда эффективное. Сейчас уже трудно найти команду, где тебе дадут время освоиться с 0 не просто азам, но и уверенной корпоративной работе в Jira+Confluence, а тем более — в Git.
Причина 1. Нет включения в командную работу. Самая рядовая, потому что огромное число работодателей не в курсе, что делает тех.писатель. Более того, данная позиция зависит от специфики компании/продукта. На моей самой первой работе так и было.
Ну здесь, наверное, не напрашиваться стоит, а уверенно донести мысль, что считаешь необходимым свое присутствие на всех мероприятиях команды, объясняя зачем это нужно в контексте твоей работы. Если тимлид/начальник не слышит после первого обращения, можно не переживать — из такой команды бегут и разработчики.
Что делал я: вежливо и уверенно объяснял, что я должен присутствовать на этих мероприятиях.
Результат: со следующей недели я уже участвую во всех совещаниях, в том числе, в неформальных переговорах на кухне.
Причина 2. Нет обратной связи. Очень вытекает из первой причины. Не понимают, кто такой тех.писатель, и по каким критериям его оценивать. Самое очевидное — наличие документа. Документ готов — хорошо, но читать его нет времени. В этом случае также ничего постыдного нет настойчиво просить ознакомиться с документом.
Что делал я: показывал отдельные топики всем, кому мог, когда видел, что время и обстоятельства располагают.
Результат: нашел общий язык с разработчиками, после чего они сами в последующих кейсах просили почитать/ознакомиться.
Причина 3. Нет цели. Здесь работа обоюдная: и тимлида/начальника, и писателя. В университете учат всегда в рефератах/курсовых начинать с цели работы. То же самое и на профессиональном поле. Первое, что нужно уяснить любыми возможными средствами — для кого и зачем пишем документ.
Что делал я: буквально надоел менеджменту среднего звена своими вопросами, кто же будет пользоваться разрабатываемым документом, и для чего я работаю в данный момент.
Результат: со временем (не сразу!) стал четко разграничивать документы по проектам с указанием степени их значимости и равноценно ответственно относиться к разработке каждого. Вроде как, даже мотивация появилась расти дальше.
Причина 4. Нет контроля. Организовывать контроль самому себе — единственный верный выход из данной ситуации.
Что делал я: попытался декомпозировать поток задач на листке бумаги, а уже основательно по каждой буквально сел на шею начальнику. А также начал сам отчитываться по корпоративной почте за каждое выполненное поручение в рамках своей же декомпозиции.
Результат: начальник в курсе, на какой стадии сейчас ведется разработка документации. Вся переписка на сервере корпоративной почты — можно доказать, чем я занимался и в какой день.
Причина 5. Нет ценности. Здесь мне пришлось тоже брать быка за рога, ибо ненавижу находиться в состоянии потерянности.
Что делал я: перестал сам думать, что моя работа никому не нужна. Глубже изучил предметную область, которую документирую, чаще обращался с вопросами к разработчикам и лиду/начальнику. Проявлял жаркую любознательность по каждому техническому затыку со своей стороны (по технологическим стекам изрядно надоел вопросами аналитику).
Результат: спустя два месяца не просто говорил на одном языке со всем отделом, но и имел наглость предложить свое видение по тому или иному вопросу.
Вывод: проявляйте инициативу. Забудьте, что инициатива наказуема. Не поощряется здесь — выстрелит в другом месте. Возможно, мой опыт слишком субъективный, и мне просто везло с руководством среднего звена (удавалось до них достучаться), но уверенность и понимание, чего хочешь именно ты, города берет, в чем я убедился на последующих проектах. Из компании, на опыт в которой была отсылка, я уже, кстати, ушел.
Напоследок я бы выделил шестую причину, почему тех.писатель уходит, и она может быть более распространена в проф.среде и менее очевидна на первый взгляд.
Причина 6. Нет путей развития как специалиста. Я очень рвался работать в серьезных системах по документированию и практиковать на реальных кейсах подход docs-as-a-code, но компании этого не надо. Всех устраивают отлаженные бизнес-процессы здесь и сейчас, но почему-то на рынке труда на позиции senior почти везде просят уверенные знания Madcap Flare, Framemaker, Robohelp, oXygen и многие другие. А где им взяться, если твоя текущая компания даже не собирается пробовать в эту сторону, не говоря уже про настройку и запуск в рамках производственного процесса? На одних триалах далеко не уедешь, а вся текущая работа настолько выматывает за день (10-12 часов), что вечерами делать свои петы — дело очень тяжелое и далеко не всегда эффективное. Сейчас уже трудно найти команду, где тебе дадут время освоиться с 0 не просто азам, но и уверенной корпоративной работе в Jira+Confluence, а тем более — в Git.