Поговорим немного о, простихосподи, софт-скилах….
Техписатель - это очень часто про коммуникабельность и умение находить компромиссы. Причем со всеми: с техническими специалистами (разработчиками, инженерами), с представителями заказчика или подрядчика. И если с представителями заказчика, чаще общается ваш менеджер, то с представителями подрядчика иногда приходится взаимодействовать напрямую. И если что-то пойдет не так, можно столкнуться с откровенным саботажем: вы будете получать документацию или в последний момент, или в таком виде, который потребует значительных усилий по переделке.
Поэтому, если вы «принимающая сторона», постарайтесь воздержаться от язвительных комментариев в документации, формулировать вопросы четко и по существу, не перегружать документ, вставляя комментарии там, где и так все понятно. Например, мне встречался документ, где каждое шаблонное название «подсистема» было промаркировано комментарием: «заменить на правильное название». Во-первых, я почувствовала себя умственно неполноценной, а во-вторых, в документ выглядел ужасно и работать с ним было неудобно.
Помните ́ (перефразирую известную фразу): получение хорошей документации – это не главная цель, это – единственная цель. Иногда приходится наблюдать в комментариях пикировки и упражнения в остроумии, ну будьте готовы в этом случае, либо к шквалу встречных вопросов, либо к формальным отпискам. Т.е. если вам чего-то не хватает, не надо писать: «А где таблица?», лучше написать что-то такое: «Пожалуйста, добавьте таблицу такую-то, в ней надо указать то-то/она нужна для того-то». Или: «Схема и таблицы не совпадаю- если в схеме пять таблиц, то ошибку найдут быстро. А если 35? Напишите: «На схеме есть таблица 1, а в описании ее нет. Уточните, пожалуйста». Если совсем непонятно, что написано или вы видите, что ваши замечания не исправляются, то лучше голосом обсудить ситуацию, получить объяснения, почему нельзя сделать так, как вы хотите. Потому что иногда – действительно нельзя сделать все под одну гребенку.
Но вот с кем приходится плотно взаимодействовать, так это с разработчиками. Это главный источник информации для техписа. И основные жалобы у техписов на то, что от разработчика невозможно добиться информации. Я, к счастью, столкнулась с такой ситуацией лишь единожды. Так вот...мое мнение, что если разработчик не может внятно объяснить, что он делает, то он либо не понимает, что он делает или он делает что-то не то, прекрасно это понимает и не хочет, чтобы это стало известно. Это половина случаев.
Вторая половина случаев – это когда разработчику реально некогда. В обеих ситуациях нужно привлекать руководство. Причем – сразу. Я твердо убеждена в том, что когда человек понимает и любит то, что он делает, он всегда с удовольствием расскажет и объяснит. Особенно, в условиях, когда продукт нематериальный. Поэтому, мне думается, что лишний раз, показать, как красиво задумана и реализована функция, программист не откажется.
Что же делать, когда получение информации затруднено? Я сразу скажу, что я категорический противник всяческих манипуляций, как иногда советуют. Хотя бы потому, что на манипуляции иногда просто нет времени. И я категорический противник того, чтобы подходить к разработчику больше трех раз:
· Первый – договариваемся о времени;
· Второй – непосредственно работа (это некоторый отрезок времени, в течение которого вы можете задавать вопросы и получать ответы);
· Третий- присылаем документ на вычитку.
Еще до первого раза, вы должны уже подготовить что-то, с чем вы пойдете к программисту. Об этом поговорим дальше. Опять же: я повторюсь: мне повезло, у меня хорошие коллеги, и я буду рассказывать о том, как плюс-минус происходит у нас.
Чтобы уменьшить стресс с обеих сторон, не писать кляузы и не трясти должностными инструкциями, нужно вносить время, необходимое на консультацию в график разработчика (особенно, если в компании ведется какой-то учет рабочего времени), ставить ему соответствующие задачи, чтобы не получилось так, что он с вами два часа беседовал или два часа писал документацию, а по трекеру он был не занят (тут, кстати, можно столкнуться с противоположной проблемой: человек любит поговорить и проговорит вами не о том, но тут уж сами рулите-с). Еще вы можете сразу поставить задачу руководителю программиста (менеджеру или старшему разработчику). Но, так как люди все-таки разные встречаются, то лучше с ним заранее (например, при приеме на работу или перед началом проекта эту возможность обговорить, чтоб он не подумал, что вы им командуете). Ибо бывает. Есть такие люди, которые очень трепетно относятся к субординации.
Но по моему мнению, назначить задачу сразу на менеджера - будет правильней. Так, у разработчика не возникнет желания вашу задачу отклонить, потому что «вы ему не начальник», а менеджер должен знать реальную загрузку сотрудника и понимать, можно отвлечь разработчика или нет. Если программиста можно и нужно отвлечь, то руководитель проекта просто переназначит задачу на исполнителя. Но может и сказать: «Васе некогда, давай сам объясню». Есть вариант, что он скажет: «Сейчас вот вообще некогда, поэтому это мы писать не будем (или это сейчас описать нельзя)». Тогда вы просто говорите, что документацию сдаете как есть, а если будут замечания, тогда будем обрабатывать их. Какая-то пространная фраза, которой можно «прикрыть» дыру в документации у вас должна быть наготове. Если – допустим- вы сдаете документацию этапами и, например, сейчас вам нужно сдать пояснительную записку, то вы можете сослаться на другой документ, который сдается попозже: руководство администратора или описание информационного обеспечения, смотря что у вас по плану. Только в пояснительной надо это явно прописать: «Схема базы данных приводится в документе таком-то» и там она потом должна быть.
Также вы можете принимать участие в митингах разработчиков и там обозначать свою потребность в общении. Если в коллективе все более-менее нормально, то часто устного распоряжения («Вася, надо помочь с документами») бывает достаточно. Но иногда тут и вскрываются проблемы, например Вася может сказать: «Хорошо, я помогу, но тогда я не успею сделать то-то и то-то». В идеале: руководитель должен расставить приоритеты, а не Вася. Поэтому, если вы сами зададите вопрос, что приоритетней для Васи: доделать какую-то задачу или переключится на документацию, то это может помочь при дальнейшем общении, ну и добавит вам плюсиков в карму.
Написание документации – это такой же важный процесс, как написание кода. И часто именно техписатель - последнее звено, после которого документация уходит на согласование заказчику. Если с документами порядок (считаем, что с программой по умолчанию все хорошо), то подписывается акт и проводится оплата. И если разработчик намеренно скрывает информацию - это вредительство (но кажется, что такие случаи довольно редки), и несвоевременная сдача документации может обернуться штрафами для компании или задержкой выплат (редко кто из разработчиков этого не понимает). Во всех остальных случаях – у программиста есть причина не общаться. Нужно ее, как минимум, выявить.