Да, хороший пункт про развитие. Соглашусь. Когда ты в команде один — расти действительно некуда.
Можно трансформироваться в бизнес-аналитика или менеджера проекта, как вариант. Мне предлагали и предлагают именно эти два пути на будущее.
Но в того же бизнес-аналитика лучше переходить в своей же команде, чтобы набраться опыта. И потом уже как бизнес-аналитик идти в другую компанию.
Спасибо, что поделились мыслями. Интересно узнать мнение разработчика на этот счет, правда.
Документация для разработчика — здесь имела ввиду бизнес-описание фичей (что это? зачем? как оно должно работать? какой результат юзер должен получить). У нас есть такое требование к документам. Но опять же мы говорим про разные типы документов. Бизнес-описание фичи (такой себе пресс-релиз) и документация API — это две очень разные вещи.
Что касается «культуры производства», да, часто именно из-за нее документации либо нет, либо она есть, но ею нельзя пользоваться.
По поводу вычитки. Говорю как техпис и только из своего опыта. Уверена, что бывает по-другому. Вычитывать огромный обьем материалов за один раз — дело неблагодарное. Привести в порядок всю существующую документацию, плюс и ту, которой много лет, невозможно. Всегда будет что-то устаревшее. Пока от этого нет лекарства, насколько я знаю.
Как мы пытаемся с этим бороться: Всю боевую мощь техписов бросают на описания новых фичей. Если новая фича как-то связана со существующей, а по существующей есть документация — эта документация проверяется в рамках задачи на новую фичу. Время тоже на это закладывается. Старая документация либо правится, либо сносится в ноль и переписывается.
НО! Так работаю я, в компании, где так можно и за это не ругаются. И я говорю всё же о пользовательской документации. НЕ спецификациях или development guides. Этим у нас занимается архитектор. Пока во всяком случае. Поэтому стратегию вычитки и правок старой документации для себя я пока выработала. Уверена, что буду ее менять со временем.
А то, что даже при таком подходе документация неактуальная всё равно останется — это факт. Пока с ним приходится мириться. Хоть это больно. И решения у меня пока нет.
Отличные мысли и советы! Спасибо, что поделились опытом. Я — техписатель, и передо мной и моей коллегой сейчас стоит задача поддерживать и продвигать нашу базу знаний как внешним пользователям, так и внутри команды. Многие из ваших советов, скажем так, облегчают мою боль. Мы уже пытаемся сделать базу знаний единым golden source и сделать ее удобной для пользования (структура, кросслинковка).
Понравились идеи вот в этом разделе «Угрозы, вымогательства» и вот в этом «Играйте на здоровом самолюбии» :)
«зачем? это же просто текст! такой и я могу написать! а тебе надо просто быть внимательнее!»
Я бы поступила так же, как и вы. Три года — это вы еще молодец :) Я бы так долго не продержалась. (Но это в силу своего характера, наверно.)
А то, что вычитывать документацию нужно — и не техпису, который ее пишет, — это 100%! Это же как code review. Это нормально и правильно. И я не понимаю тех, кто этого не понимает. Мне с такими сложно.
Полностью соглашусь и поддержу все пункты! Читаю и понимаю, что очень во многом поступала так же, как и вы. И это отличные рекомендации!
В моем случае я однажды просто устала. Устала доказывать. Эта усталость накапливалась, а конечное решение было однозначно принято после одного случая с новым проектом. Если коротко и чтобы не нарушать NDA, мне дали 5 дней на документирование проекта, который длился 3 или 4 месяца. Подключили на последней неделе проекта в понедельник с напоминаем о том, что два из трех разработчиков проекта уходят в пятницу. Хотя задолго до этого я спрашивала о документации. Мне говорили «не надо».
Вот тут и бомбануло.
Наверно, дело в моем характере.
Я очень уважаю здоровую напористость и уверенность в людях. Когда вы можете доказывать и убеждать, даже если первые 10 раз вас не хотят слушать. И здорово, когда вы добиваетесь уважения и к вам прислушиваются!
У меня просто не хватило для этого сил, выдержки и желания тогда.
Большое спасибо за отзыв!
Да, знаю о таких случаях. И в моей практике тоже было «переделай всё». Но помог главный разработчик проекта тогда. Он вычитал сам и сказал бизнесу, что всё в порядке. Повезло с человеком :)
Как лекарство от «переделай всё»: можно делиться с другими авторитетными subject matter experts и получать обратную связь от них. Можно общаться с юзерами. (Последнее менее реально, согласна.) Но опять-таки, сложность в том, что такое общение зачастую должно быть одобрено менеджментом.
Если бы мне такое долго не одобряли, в один прекрасный день меня бы в такой компании не стало.
Да, согласна. Хоть и писала по личному опыту, уже вижу, что эти пункты могут быть у человека любой профессии.
И да, думаю, то, с каким настроением выполняется проект, какое отношение к нему еще на этапе заказа, тоже скажется на том, какое отношение будет к документации.
Думаю, тоже от проекта зависит. Нужно понимать, зачем именно нужен техпис, когда в редми репозитория становится много строк. Что ожидают от человека? Чтобы он это всё привел в порядок? Снес начисто и написал всё заново, но уже четко-красиво, со стайлгайдом для девов в придачу?
Мне, бывало, очень не хватало понимания того, чего именно от меня ожидают. На каком бы этапе это ни было, как бы плохо всё с документацией не было, мне лично хочется одного — понимать, что хотят видеть результатом моей работы. Хотя бы промежуточным. Не говорю про конечный.
Интересная мысль. Именно в такой компании я сейчас и работаю — мы разрабатываем и внедряем свой продукт.
Причина — документация это обязательство.
Это зависит от продукта и отношения к тому, как он должен быть показан и передан потенциальным пользователям.
Есть системы, где без хорошей, актуальной документации не обойтись, потому что интуитивно нельзя понять, как этой системой пользоваться.
Конечно, это уже проблема тех, кто разрабатывает систему. Нормально сделаете — сэкономите на техписателе. Но всегда будут обновления, всегда будут доделки, всегда нужно будет вспомнить, а как было вначале, а что по умолчанию должно быть. И вот тут хоть какая-то документация, но поможет.
Опять же, говорю из своего опыта. Возможно, бывает по-другому. Я еще не сталкивалась с проектами, где документация не была нужна от слова совсем. То, как относились к ней и к процессу ее создания, — это другой вопрос.
Лично я соглашусь с вашим комментарием. Документацию сложно писать и сложно поддерживать в актуальном состоянии. Когда техписа нет, рано или поздно за документацию забудут. Или не забудут, но описывать будут только новые фичи. А обновлять документы по существующим никто не будет.
И даже будучи техписом, поддерживать документацию сложно. Потому и да, на документацию ругаются. И читать ее не хотят.
У меня пока нет лекарства для этого. Мы сейчас в процессе — продумываем возможные решения этому…
Сколько работаю техписателем, столько задаюсь тем же вопросом :) Но оказывается, читают.
Мы в компании даже прикручивали инструменты, чтобы смотреть посещаемость документов и собирать обратную связь.
Можно трансформироваться в бизнес-аналитика или менеджера проекта, как вариант. Мне предлагали и предлагают именно эти два пути на будущее.
Но в того же бизнес-аналитика лучше переходить в своей же команде, чтобы набраться опыта. И потом уже как бизнес-аналитик идти в другую компанию.
Надеюсь, ситуация улучшиться.
Да, полностью соглашусь. Очень верная мысль.
Документация для разработчика — здесь имела ввиду бизнес-описание фичей (что это? зачем? как оно должно работать? какой результат юзер должен получить). У нас есть такое требование к документам. Но опять же мы говорим про разные типы документов. Бизнес-описание фичи (такой себе пресс-релиз) и документация API — это две очень разные вещи.
Что касается «культуры производства», да, часто именно из-за нее документации либо нет, либо она есть, но ею нельзя пользоваться.
По поводу вычитки. Говорю как техпис и только из своего опыта. Уверена, что бывает по-другому. Вычитывать огромный обьем материалов за один раз — дело неблагодарное. Привести в порядок всю существующую документацию, плюс и ту, которой много лет, невозможно. Всегда будет что-то устаревшее. Пока от этого нет лекарства, насколько я знаю.
Как мы пытаемся с этим бороться: Всю боевую мощь техписов бросают на описания новых фичей. Если новая фича как-то связана со существующей, а по существующей есть документация — эта документация проверяется в рамках задачи на новую фичу. Время тоже на это закладывается. Старая документация либо правится, либо сносится в ноль и переписывается.
НО! Так работаю я, в компании, где так можно и за это не ругаются. И я говорю всё же о пользовательской документации. НЕ спецификациях или development guides. Этим у нас занимается архитектор. Пока во всяком случае. Поэтому стратегию вычитки и правок старой документации для себя я пока выработала. Уверена, что буду ее менять со временем.
А то, что даже при таком подходе документация неактуальная всё равно останется — это факт. Пока с ним приходится мириться. Хоть это больно. И решения у меня пока нет.
Понравились идеи вот в этом разделе «Угрозы, вымогательства» и вот в этом «Играйте на здоровом самолюбии» :)
Я бы поступила так же, как и вы. Три года — это вы еще молодец :) Я бы так долго не продержалась. (Но это в силу своего характера, наверно.)
А то, что вычитывать документацию нужно — и не техпису, который ее пишет, — это 100%! Это же как code review. Это нормально и правильно. И я не понимаю тех, кто этого не понимает. Мне с такими сложно.
В моем случае я однажды просто устала. Устала доказывать. Эта усталость накапливалась, а конечное решение было однозначно принято после одного случая с новым проектом. Если коротко и чтобы не нарушать NDA, мне дали 5 дней на документирование проекта, который длился 3 или 4 месяца. Подключили на последней неделе проекта в понедельник с напоминаем о том, что два из трех разработчиков проекта уходят в пятницу. Хотя задолго до этого я спрашивала о документации. Мне говорили «не надо».
Вот тут и бомбануло.
Наверно, дело в моем характере.
Я очень уважаю здоровую напористость и уверенность в людях. Когда вы можете доказывать и убеждать, даже если первые 10 раз вас не хотят слушать. И здорово, когда вы добиваетесь уважения и к вам прислушиваются!
У меня просто не хватило для этого сил, выдержки и желания тогда.
Да, знаю о таких случаях. И в моей практике тоже было «переделай всё». Но помог главный разработчик проекта тогда. Он вычитал сам и сказал бизнесу, что всё в порядке. Повезло с человеком :)
Как лекарство от «переделай всё»: можно делиться с другими авторитетными subject matter experts и получать обратную связь от них. Можно общаться с юзерами. (Последнее менее реально, согласна.) Но опять-таки, сложность в том, что такое общение зачастую должно быть одобрено менеджментом.
Если бы мне такое долго не одобряли, в один прекрасный день меня бы в такой компании не стало.
И да, думаю, то, с каким настроением выполняется проект, какое отношение к нему еще на этапе заказа, тоже скажется на том, какое отношение будет к документации.
Про утверждение о поиске работы — соглашусь. Хороший перечень того, что должно быть в документации.
Мне, бывало, очень не хватало понимания того, чего именно от меня ожидают. На каком бы этапе это ни было, как бы плохо всё с документацией не было, мне лично хочется одного — понимать, что хотят видеть результатом моей работы. Хотя бы промежуточным. Не говорю про конечный.
Это зависит от продукта и отношения к тому, как он должен быть показан и передан потенциальным пользователям.
Есть системы, где без хорошей, актуальной документации не обойтись, потому что интуитивно нельзя понять, как этой системой пользоваться.
Конечно, это уже проблема тех, кто разрабатывает систему. Нормально сделаете — сэкономите на техписателе. Но всегда будут обновления, всегда будут доделки, всегда нужно будет вспомнить, а как было вначале, а что по умолчанию должно быть. И вот тут хоть какая-то документация, но поможет.
Опять же, говорю из своего опыта. Возможно, бывает по-другому. Я еще не сталкивалась с проектами, где документация не была нужна от слова совсем. То, как относились к ней и к процессу ее создания, — это другой вопрос.
Писала про личные причины увольнения. Но «внешние» также имеют место быть.
И даже будучи техписом, поддерживать документацию сложно. Потому и да, на документацию ругаются. И читать ее не хотят.
У меня пока нет лекарства для этого. Мы сейчас в процессе — продумываем возможные решения этому…
Мы в компании даже прикручивали инструменты, чтобы смотреть посещаемость документов и собирать обратную связь.