Итак, перед первым обращением непосредственно к разработчику следует подготовить «рыбу» документа, предзаполненный вариант, который вы и будете обсуждать с программистом. Почему это нужно сделать. Очень часто представление об объеме нужной информации отличается у техписа и разработчика. Возможно, в документации будет достаточно пары предложений, а человек, думает, что там нужно описывать все от начала времён, понимает, что это большой объем и из-за этого нервничает, скрывается. Поэтому нужен образец, где будет показан минимально допустимый уровень этой информации. Я считаю, что писать примерный текст нужно непосредственно в документ, не в комментариях и не в формате «вопрос-ответ». Во-первых, потому что тратится время на написание формулировки: «Правильно ли я думаю, что тут вот то-то и то-то происходит или тут может быть как-то вот так....». Во-вторых, многие начинают отвечать там же в комментариях, завязывается ожесточенная переписка (ага, в комментариях) и документ превращается в кашу.
Вписывайте фразу сразу в документ, так, как она должна быть: «Данная функция предназначена для (или выполняет) то -то» и уже это предложение отмечаете примечанием (если что, я все это время подразумеваю работу в Word): «Вася, откорректируй как правильно/как сейчас». Если у вас несколько разработчиков, лучше в примечании писать имя, чтобы разработчики смотрели не все примечания, а только те, которые относятся к их части работы.
Вот эту «рыбу» документа, надо отправить разработчику со словами: «Вася, посмотри, пожалуйста. Там отмечены пункты, по которым от тебя требуется информация. Было бы хорошо, если бы ты посмотрел его до конца завтрашнего дня». Обязательно обозначайте срок, один-два дня желательно иметь в запасе. Это первое обращение к разработчику.
Любому разработчику нужно время:
- просмотреть документ;
- понять, какой объем информации от него требуется;
- понять, нужно ли ему выполнять какие-то действия дополнительно.
Потому что, если описывается какая-то старая программа (пусть даже пару месяцев прошло) не факт, что человек сможет вам дать информацию вотпрямщас. Возможно, там уже нет нужных данных; возможно, ему нужно что-то дополнительно установить/развернуть/настроить (особенно, если вам нужные какие-то скриншоты или примеры кода); могли поменяться какие-то ссылки/адреса и т.д., и т.п. Дайте время подготовиться к общению.
Я считаю, что вполне допустимо на следующий рабочий день, уточнить посмотрел ли он документ и может ли ответить, когда примерно получится пообщаться. Если в этот момент уже выяснится, что времени нужно много, то сразу обращайтесь к его руководителю, чтобы программисту выделили время на работу с документацией. Если этого времени нет, смиритесь с тем, что придется как-то по верхам описывать и ждать замечаний.
Вторая встреча. Это уже непосредственно общение – т.е. совместный проход по документу, вписывание нужных формулировок, либо рассказ, о том, как это работает, либо демонстрация работы, причем по возможности лучше делать запись. Если есть возможность, включите запись экрана, потому что тяжело долго удерживать внимание: вы можете моргнуть, разработчик в это время нажмет на какую-то кнопку, произойдет какая-то магия, а вы не поймете, что он сделал. А в записи всегда можно и посмотреть, и скриншоты дополнительные сделать. В общем - удобно. И это ускоряет процесс: не всегда получается в ходе обсуждения подобрать какую-то удачную формулировку. Вроде бы своими словами все получается хорошо и понятно, но начинаешь писать и понимаешь, что что-то не то. Поэтому чтобы не тратить время разработчика на придумывание этих формулировок, можно потом еще раз запись прослушать и уже сформулировать красиво.
И третье соприкосновение, когда вы отправляете вариант на «посмотреть». Тут от человека требуется бегло просмотреть нужные пункты и что-то, может быть, подправить. При этом разработчик уже понимает тот объем информации, который от него требуется, понимает в каких формулировках это должно быть описано. И такая корректировка времени много не занимает.
Вот такое мое идеальное видение процесса.