Наличие технического писателя в команде воспринимается либо как нечто само собой разумеющееся, либо как нечто вызывающее вопросы “Ты кто? Ты что тут делаешь?”.

Но когда технический писатель уходит из команды, его отсутствие можно сравнить с отсутствием маленького кусочка в большом и сложном паззле. Без этого кусочка можно обойтись. Но внимательный наблюдатель заметит, что картина команда не полная, в ней явно кого-то не хватает. 

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

Почему же такой человек в один прекрасный день может взять и уйти? 

В этой статье хочу поделиться своим опытом, без отсылки на умные исследования Гарварда и Стэнфорда. Для себя выделила пять причин. Ими делюсь.

1. Нет включения в командную работу.

2. Нет обратной связи.

3. Нет цели.

4. Нет контроля.

5. Нет ценности.

Заранее благодарю за комментарии и дополнения.

Причина 1. Нет включения в командную работу

Мы плывем в одной лодке. Слышали такое выражение у себя в команде? По-моему, это очень верное сравнение: работы команды над проектом в ИТ с работой экипажа корабля. 

На корабле не должно быть ни одного лишнего человека. На корабле у каждого есть своя четкая задача, свое место. Есть члены экипажа, которые могут заменять друг друга. Но это не значит, что каждый может заменить каждого. А если кто-то делает свою работы плохо или нечестно, то он ставит под угрозу не только свою жизнь, но и жизнь всех своих товарищей.

А теперь представьте, что одного из членов экипажа просто не замечают. Его не берут на общие собрания. Ему не передают никаких важных новостей. Никто не интересуется его проблемами и вопросами. Каково ему? Захочется ли ему выполнять свою работу? А если и захочется, будет ли и сможет ли он выполнять ее хорошо и с удовольствием?

В реальной жизни все может быть не так драматично. Но теперь возьмите небольшую команду во главе с проджект-менеджером в любой ИТ компании. И замените того человека на корабле, на человека, ответственного за документацию на проекте. На техписателя. 

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

Нет, он не должен самостоятельно напрашиваться. Не должен сам писать своему менеджеру и проситься на митинг. Если менеджер приглашает разработчика – создателя фичи – на демо, почему он не приглашает человека, который будет объяснять, как эта фича работает, – техписателя?

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

Поэтому: не забывайте про своих техписателей, когда дело касается работы всей команды. Техписатель – это тот человек, который совершенно добровольно и осознанно берет на себя такую обязанность, как документирование вашего проекта. (Не каждый ведь пойдет на такое.) Но для этого ему нужна информация. 

Если техписатель в какой-то момент митинга поймет, что здесь он нужную информацию не получит, пусть себе вежливо отключается (или выходит из кабинета). Но а если на этом митинге он наконец-то поймет, зачем разработали новую фичу? Если на митинге он задаст вопрос, который не задал никто до него, и это поможет решить какую-то важную проблему, из-за которой фича не отрабатывала, как должно? 

Техписатель – полноправный член экипажа на вашем корабле. Его ошибка может стоить успеха всего проекта. Поэтому вовлекайте его в проект полностью и всегда. А не только тогда, когда – по вашему мнению – должно быть начато документирование. Этим вы не только облегчите его работу, но и дадите почувствовать себя нужным человеком в команде. А это очень важно для качественного результата. Но вы это и сами знаете, да?

Причина 2. Нет обратной связи

Если новой фичей начнут пользоваться сразу после релиза, то документацией по этой фиче начнут пользоваться после n-ной неудачной попытки получить нужный результат. Так бывает во всех продуктах. И даже если документ реально поможет пользователю получить от новинки то, что он хочет, автор документа вряд ли об этом узнает. 

Документация зачастую должна быть готова к релизу. И ответственность за ее качество и своевременную публикацию несет технический писатель. Если фичу можно протестировать сразу после окончания разработки и дать оценку ее функциональности  и пользе, то документацию… Документ тоже можно протестировать сразу после его написания. 

Документ можно, как минимум, вычитать. Как максимум, можно пройтись по пошаговой инструкции, которая в нем составлена, и проверить полученный результат. И после нескольких кругов правок документ можно опубликовать и быть уверенным в его правильности. А еще можно настроить коммуникацию с клиентами или пользователями, поинтересоваться, все ли им понятно. 

А теперь поднимите руки те, у кого в команде так заведено. Особенно те, у кого техписатель один на всех.

Если у вас налажена вычитка документации – мое почтение. Если у вас есть возможность делать автотесты в документации – вы просто круты! А если у вас еще нет ни того, ни другого и вашему техписателю с этим живется вполне хорошо, советую вам все таки заглянуть в один из его документов.

Мы люди. И мы не можем всегда все делать правильно. Да еще и так, чтобы другим было понятно.

Поэтому: налаживайте процесс вычитки документации у себя в команде. Давайте своему техписателю обратную связь. Как положительную, так и конструктивно отрицательную, если вам или пользователям что-то не нравится. 

Мой личный опыт дал мне понять, что если по документу “все хорошо” или к нему “нет замечаний”, значит, никто мой документ не читал. Потому что все не может быть всегда хорошо. Потому что я – человек и я могу сделать опечатку, если и не логическую ошибку. За первое просто неудобно перед людьми, за второе… Можно схлопотать от руководства и клиента. Но и первого, и второго можно избежать, если просто проверить документ. Хотя бы один раз, свежим взглядом.

А еще правильная обратная связь поможет вашему техписателю развиваться и совершенствоваться. То же самое будет происходить и с документацией на вашем проекте. Ведь это ему не помешает, верно?

Причина 3. Нет цели

У документации должна быть цель. Документация призвана решать конкретную проблему конкретного человека. Будь то пользователь-начинашка, который ищет кнопку “Сделать хорошо” в интерфейсе, или разработчик, которого подключают на новый проект, – документация должна помочь такому пользователю или разработчику.

Поэтому задача написать хоть что-нибудь, просто потому что проект заканчивается, а о нем ни слова не написано, меня лично сбивает с толку. 

Какая информация и от кого мне может понадобиться для создания такого “документа”? Какую проблему я решаю, когда мне нужно написать хоть что-нибудь? Кому я помогу, если я напишу хоть что-нибудь? 

Вы можете ответить: ну, как же, вот уйдет проект в поддержку, – там и пригодится вот это что-нибудь. 

Поэтому: давайте будем ставить четкую задачу техписателю. Мол, нужно описание проекта, которое могло бы помочь ввести в курс дела новенького разработчика, который будет поддерживать этот проект. Например. Цель есть, проблему решаем. Всё отлично!

А если мы решили написать хоть что-нибудь для кого-нибудь, кого проект, возможно, но не факт, может заинтересовать, то и пары предложений будет вполне достаточно. И можно даже не трекать. Кому надо, тот и сам все сможет узнать, верно?

Причина 4. Нет контроля

На первый взгляд отсутствие контроля за работой – это вух-ху! как здорово. 

Никто не проверяет, сколько ты написал за день. Никто не присматривает за тем, чтобы ты случайно не взял задачу с более низким приоритетом, просто чтобы переключить мозги. 

Главное – сдай документ вовремя. Всё. Шикарно же, разве нет? Нет.

И у этой медали есть вторая сторона. Никто не имеет представления, чем конкретно ты занят в данный момент, на каком статусе твои текущие задачи, и как у тебя вообще настроение. Следовательно, любой – пусть будет менеджер – может бросить в тебя новую и, конечно же, очень срочную задачу.

Когда у тебя задач пять, отодвинуть их в сторону и взять шестую с, конечно же, самым высоким приоритетом не сложно. Но а что если у тебя таких задач штук 10-15? И пусть 2-3 из них, ну, не срочные, но чем быстрее, тем лучше?

Ты оставляешь их в неопознанном статусе на неопределенное время. Потому что вникнуть в абсолютно новую задачу быстро не получится. Пока вопросы, пока ответы. А там глядишь, и до конца срока дня два осталось. А ты злишься-кипятишься и не укладываешься в них. (Дальше по сценарию.)

Поэтому:  изредка, раз-два в месяц, интересуйтесь, как там вообще у вашего техписателя дела. Обязательно посмотрите, чем он может быть занят в тот момент, когда вы собираетесь обрадовать его новой задачей. И обсудите с ним вместе, как быть. 

Да, самоорганизованность и дисциплина – важные качества техписателя. Техписатель – это самостоятельная боевая единица, как любил говорить один мой знакомый product owner. Но помните, что техписатель – также член команды, работающей над проектом. Насколько же хорошо выполнит свою часть командной работы человек, которого оставили в одиночку разбираться с кучей высокоприоритетных задач?

Причина 5. Нет ценности

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

Если технический писатель работает, “чтобы было” и “потому что у всех есть, пусть у нас тоже будет”,  а не “потому что это всем нужно и мы знаем, как это важно”, то ваш проект будет развиваться по одному из двух сценариев. 

Первый: документация у вас будет, но качество ее будет сомнительным. Вашу команду такое устроит?

Второй: документация у вас будет и будет качественная, но в один не предвещающий ничего плохого день вы получите от вашего техписателя письмо с заявлением о добровольном увольнении. Когда вы на последней встрече 1 на 1 спросите у него, в чем дело, он ответит (если у вас доверительные отношения), что не ощущает, чтобы его работу ценили.

Вот это ощущение отсутствия ценности себя как специалиста в команде очень сложно объяснить. Ты просто чувствуешь это, и всё. Потому что тебя не зовут на демо, тебе не дают обратную связь, тебе не помогают определить цель и твою работу никто не контролирует.

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

Поэтому: осознайте необходимость и ценность хорошей документации на вашем проекте уже сейчас. Спросите себя, зачем вам документация? Кто ее конечный пользователь? Какой она должна быть? Даже если вы не сможете дать четкие ответы на эти вопросы, не переживайте – хороший и ответственный техписатель вам поможет. Но вы должны дать ему хоть какую-то информацию, а еще время и мотивацию для дальнейших исследований. 

Общайтесь с вашим техписателем, контролируйте его работу, погружайте с головой в командную работу, давайте обратную связь. Это тот же разработчик. Тот, который у вас самый ценный и любимый. Только он пишет не код, а документ. Который кстати, в отличие от кода, даже вы сможете прочитать. 

Но если вы не можете дать себе ответ ни на один из вопросов выше, просто не нанимайте технического писателя. Пусть документацию пишут разработчики, QA-инженеры, аналитики, архитекторы, тим лиды, менеджеры. Кто угодно. И чуть позже вы сможете нанять техписателя, потому что поймете, почему же он все таки вам нужен.

Удачи!