Разработка технической документации и технические писатели Технические писатели и разработка технической документации технические писатели в Телеграм 

 obmen_soobsheniyami.png Чат для технических писателей 
 Зарегистрируйтесь
Страницы: 1 2 След.
RSS
Как техническому писателю получать консультации от разработчиков? Инструкция к применению, Учимся мягко и настойчиво выбивать всею информацию от программистов!
  1. Как вас консультируют разработчики?
 
Поделимся опытом в добывания информации от разработчиков. Как вы узнаете про новый функционал, каким образом записываете информацию (диктофон, текстовые заметки, примечания/правки в документации...).
 
Мой первый шаг - наладить доброжелательные отношения. При общении стараюсь быть вежливой и ненадоедливый. Всегда предлагаю такой вариант: "Василий (например), я сейчас пишу руководство по работе с модулем "<Название модуля>". Я изучила функционал, но у меня есть некоторые вопросы. Когда вам было бы удобнее меня проконсультировать? Консультация по времени примерно займет <ваша оценка в часах или минутах>". Конечно, предварительно я действительно трачу время на изучение функционала, записываю себе вопросы и уже с этим перечнем иду к программисту в назначенное время. В конце беседы всегда спрашиваю: "В каком формате вам можно задавать небольшие вопросы, которые могут возникать в процессе разработки документа?" Конечно, вопросы должны быть по существу и по адресу.
Короче, моя тактика такова, что я не спрашиваю, можно мне задавать вопрос или нет. Я просто спрашиваю, только стараюсь это делать максимально удобно для программиста. Если встречается программиста, который отказывается отвечать на мои вопросы, регулирую этот вопрос через начальство с качественным обоснованием, почему мне нужна консультация.
techwriter.ru.com
 
Цитата
writer пишет:
Поделимся опытом в добывания информации от разработчиков. Как вы узнаете про новый функционал, каким образом записываете информацию (диктофон, текстовые заметки, примечания/правки в документации...).
Сейчас я работаю по Agile. Мне он нравится тем, что я равный член команды и участвую в процессе обсуждения доработок, планировании работ, их оценке. Каждый день у нас stand up, на котором я могу озвучить свои результаты, и главное, вопросы и трудности, которые у меня возникают. Поскольку задачи ставятся на команду, а не на конкретного участника, то в достижении цели заинтересованы все, из-за чего автоматически устанавливаются отношения взаимопомощи. Считаю, что пока что это самая удачная практика в моей карьере технического писателя, а работаю я им почти 9 лет :)))
techwriter.ru.com
 
techwriter права, самое главное доброжелательные отношения, тогда и спрашивать можно спокойно и сколько нужно.
Торопливость в выводах может привести к неприятностям
 
Мне кажется, что если речь сразу заходит о "добыче информации тисками", то тут дело не только в налаживании отношений, но и вполне себе административный момент организации работы над проектом, в разрешении которого должен участвовать руководитель проекта.

У нас в последнее время дали установку, что "дергать" разрабов можно в конкретные часы. Я пишу прогеру - мол, "Можно подойти?"  Тоже заранее готовлю вопросы по той информации, что у меня есть (а обычно все в одной базе пишут, что было сделано, как может повлиять на работу  с существующим функционалом, и все такое прочее) - и.... PROFIT =)

UPD. OOPS, кажется, я дважды ответила на опрос.
Изменено: Elanor - 25.07.2014 11:32:48
 
Цитата
techwriter пишет:
Сейчас я работаю по Agile. Мне он нравится тем, что я равный член команды и участвую в процессе обсуждения доработок, планировании работ, их оценке. Каждый день у нас stand up, на котором я могу озвучить свои результаты, и главное, вопросы и трудности, которые у меня возникают. Поскольку задачи ставятся на команду, а не на конкретного участника, то в достижении цели заинтересованы все, из-за чего автоматически устанавливаются отношения взаимопомощи. Считаю, что пока что это самая удачная практика в моей карьере технического писателя, а работаю я им почти 9 лет ))
Я работала по Agile и считаю этот опыт самым негативным и непродуктивным за всю мою трудовую деятельность.
"Равным членом" в команде можно быть в любой нормальной организации.

Как у Вас происходит оценка затрат? У Вас не возникают ситуации, когда программисты оценивают написание порядка 10 страниц документации в 4 идеальных часа? И причем искренне удивляются, а что нужно разве больше? Хотя на написание своего скрипта в несколько строчек они также отводят 4 идеальных часа.
На основании чего Вы сами оцениваете затраты программиста на задачу?
Изменено: убожетымой - 26.07.2014 17:51:47
 
Цитата
убожетымой пишет:
Я работала по Agile и считаю этот опыт самым негативным и непродуктивным за всю мою трудовую деятельность.
"Равным членом" в команде можно быть в любой нормальной организации.

Как у Вас происходит оценка затрат? У Вас не возникают ситуации, когда программисты оценивают написание порядка 10 страниц документации в 4 идеальных часа? И причем искренне удивляются, а что нужно разве больше? Хотя на написание своего скрипта в несколько строчек они также отводят 4 идеальных часа.
На основании чего Вы сами оцениваете затраты программиста на задачу?
Какой конкретно документации вы пишете 10 страниц 4 часа? ;)
Программисты, может, и не очень умеют оценивать: иногда завышают, иногда недооценивают. Но моя оценка в итоге и становится той, которая указывается для задачи. Видимо, есть доверие моему опыту.
Я их задачи оцениваю, исходя из собственного опыта. Они подробно рассказывают, что и как будут делать, а я примерно оцениваю. Пока что "попадаю" в 70% случаев. Иногда тоже завышаю, но трагедии в этом нет. Да и трагедии в том, что задача выполняется дольше запланированного времени, тоже нет ;)
techwriter.ru.com
 
Я, конкретно, за 4 часа никакой документации  10 часов не напишу. Это программисты были уверены, что я столько писать должна, ибо "что там делать". А редактуру 200 страниц они не стесняясь оценивали в 2 часа работы

У Вас, наверно, не Agile, в полном понимании этого слова, а подобие )) Т.к. итоговая оценка затрат по agile не будет равна оценки затрат одного человека, несмотря на то, доверяют вашему опыту программисты или не доверяют
Изменено: убожетымой - 28.07.2014 22:17:02
 
У нас тоже Agile, интересный опыт, но это никак пока не помогает в получении информации, все равно программистов "не трогать", разбираться должен во всем сам.
У меня вообще такое видение написания документации:
  1. Постановка задачи на разработку доков на какой-то функциоанал.
  2. Описываешь сам, что понял в неких тезисах, подходишь к разработчикам, спрашиваешь: так или нет все это работает?
  3. Если в принципе все правильно, идешь пишешь первый драфт документа.
  4. Отдаешь на вычитку (при этом править должны прямо в тексте, а не говорить словами где и что не так).
  5. Вносишь правки... опять отдаешь на вычитку  и так еще пару раз.
  6. Перевязываешь ленточкой доки и кладешь в общий доступ)
 
Мы тоже стараемся программистов не трогать. Но не потому, что они такие "небожители", а потому что есть аналитики — люди, которые пишут ТЗ и знают, как что должно работать. Они всегда в курсе работ по своим ТЗ, т.е. могут ответить, почему что-то не соотв. ТЗ: либо доделают, либо не смогли и останется так. Т.е. общая схема такая: читаем ТЗ — смотрим функционал — задаем вопросы аналитику. Также с аналитиком согласовываем, так сказать, "расстановку акцентов" в описании функционала: общее назначение, основные возможности, примеры. Т.е. это не план описания, а то, что надо обязательно донести до пользователя.
Написала и думаю: прям идиллия получается. Конечно, нет — случаются и накладки (изменения, не отраженные в ТЗ, изменения, "не дошедшие" до писателей, простая запарка), но основа всего, как здесь уже отмечали, это доброжелательные отношения, т.е. никто ни от кого не отмахивается. Как-то оно так сразу повелось ))
 
Мы тоже основываемся на ТЗ и на реализованный продукт. Если возникают несоответствия - обращаемся к разработчикам. Аналитиков как токовых нет, поэтому все вопросы к разработчикам и руководителю проекта. Если слишком часто не приставать к разработчикам, а собирать вопросы и конкретизировать их, то разработчики ведут себя доброжелательно и стараются нам помочь  :D
 
Цитата
убожетымой пишет:
У Вас, наверно, не Agile, в полном понимании этого слова, а подобие )) Т.к. итоговая оценка затрат по agile не будет равна оценки затрат одного человека, несмотря на то, доверяют вашему опыту программисты или не доверяют
Ну, если я ставлю оценку больше или меньше всех, я же обосновываю, почему так, разве нет? И если аргументированно обосновываю, то почему со мной не должна согласиться команда?
techwriter.ru.com
 
Цитата
убожетымой пишет:
Я, конкретно, за 4 часа никакой документации10 часов не напишу. Это программисты были уверены, что я столько писать должна, ибо "что там делать". А редактуру 200 страниц они не стесняясь оценивали в 2 часа работы
А какую документацию вы пишете, если не секрет?
techwriter.ru.com
 
Цитата
Ирина Сидорова пишет:
Мы тоже стараемся программистов не трогать. Но не потому, что они такие "небожители", а потому что есть аналитики — люди, которые пишут ТЗ и знают, как что должно работать.
К сожалению, я не могу их не трогать :)) Я работаю в команде, которая пишет ядро и пишу огромное руководство разработчика. Программист - основной консультант для меня. Аналитики вообще не в курсе, что и как они делают. Поэтому у меня наоборот: с программистами общаюсь каждодневно, с аналитиками - почти нет.
techwriter.ru.com
 
Цитата
writer пишет:
У нас тоже Agile, интересный опыт, но это никак пока не помогает в получении информации, все равно программистов "не трогать", разбираться должен во всем сам.
У меня вообще такое видение написания документации:
Постановка задачи на разработку доков на какой-то функциоанал. Описываешь сам, что понял в неких тезисах, подходишь к разработчикам, спрашиваешь: так или нет все это работает? Если в принципе все правильно, идешь пишешь первый драфт документа. Отдаешь на вычитку (при этом править должны прямо в тексте, а не говорить словами где и что не так). Вносишь правки... опять отдаешь на вычитку и так еще пару раз. Перевязываешь ленточкой доки и кладешь в общий доступ)
Да, очень важно организовать фидбек на документацию, которую пишешь :) Но это сложный вопрос отдельной темы :)
techwriter.ru.com
 
Цитата
techwriter пишет:
Цитата
Ирина Сидорова пишет:
Мы тоже стараемся программистов не трогать. Но не потому, что они такие "небожители", а потому что есть аналитики — люди, которые пишут ТЗ и знают, как что должно работать.
К сожалению, я не могу их не трогать ) Я работаю в команде, которая пишет ядро и пишу огромное руководство разработчика. Программист - основной консультант для меня. Аналитики вообще не в курсе, что и как они делают. Поэтому у меня наоборот: с программистами общаюсь каждодневно, с аналитиками - почти нет.
Вы, случайно, работаете не на  проекте от Luxoft'a на внедрении erp-системы (молочный завод)?
//просто из того,  что вы рассказываете у меня возникли такие подозрения // :oops:
Изменено: убожетымой - 30.07.2014 21:21:32
 
Цитата
убожетымой пишет:
Цитата
techwriter пишет:
Цитата
Ирина Сидорова пишет:
Мы тоже стараемся программистов не трогать. Но не потому, что они такие "небожители", а потому что есть аналитики — люди, которые пишут ТЗ и знают, как что должно работать.
К сожалению, я не могу их не трогать ) Я работаю в команде, которая пишет ядро и пишу огромное руководство разработчика. Программист - основной консультант для меня. Аналитики вообще не в курсе, что и как они делают. Поэтому у меня наоборот: с программистами общаюсь каждодневно, с аналитиками - почти нет.
Вы, случайно, работаете не на проекте от Luxoft'a на внедрении erp-системы (молочный завод)?
//просто из того, что вы рассказываете у меня возникли такие подозрения //  :oops:
Да, там и работаю :) Отличное место для технического писателя.
techwriter.ru.com
 
Цитата
techwriter пишет:
Цитата
Вы, случайно, работаете не на проекте от Luxoft'a на внедрении erp-системы (молочный завод)?
//просто из того, что вы рассказываете у меня возникли такие подозрения //  :oops:  
Да, там и работаю  :)  Отличное место для технического писателя.
Да, мир технического писателя тесен))
 
Цитата
writer пишет:
Да, мир технического писателя тесен))
Да, у меня были случаи работы с одними же и теми людьми по два раза :)) Причем всегда все по объявлениям устраивались :)))
techwriter.ru.com
 
techwriter, а коуч все еще с Вами работает или уже на голом энтузиазме держитесь? ))
Радов-кий все еще тимлид?

можете не отвечать, если не хотите, или в личку ответить, у меня простое любопытство, как там сейчас
Изменено: убожетымой - 31.07.2014 22:54:27
 
Цитата
убожетымой пишет:

techwriter   , а коуч все еще с Вами работает или уже на голом энтузиазме держитесь? ))
Радов-кий все еще тимлид?

можете не отвечать, если не хотите, или в личку ответить, у меня простое любопытство, как там сейчас
Да все отлично там сейчас)
techwriter.ru.com
 
Поднимаю тему:
Какие вопросы вы задаете разработчикам при "первом контакте" по новому функционалу?
 
Цитата
writer пишет:
Какие вопросы вы задаете разработчикам при "первом контакте" по новому функционалу?
1. Определяем цели.




2. Выбираем носителя информации из числа разработчиков

..



3. Подходим и просим:  "Мне нужна твоя одежда, ботинки и мотоцикл!"




Не забывая добавить "Пожалуйста", чтобы не ломать никому руки..
 
если, например, этот пункт Выбираем носителя информации из числа разработчиков , реализовать нельзя? Т.е нужно самому разбираться в том , что сделано используя таски и какую-то рабочую документацию, в которой пара строчек о том как это должно работать)?
 
Цитата
writer пишет:
если, например, этот пункт Выбираем носителя информации из числа разработчиков , реализовать нельзя? Т.е нужно самому разбираться в том , что сделано используя таски и какую-то рабочую документацию, в которой пара строчек о том как это должно работать)?
Или носитель информации уволился несколько лет назад :)))
techwriter.ru.com
Страницы: 1 2 След.
Читают тему