Вступление

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

Как показывает практика, начинающие специалисты, как и я когда-то, сталкиваются с типичными подводными камнями, которые затрудняют успешное выполнение задач.

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

Список вредных советов

Верь на слово коллегам и пользователям. Они опытнее. Зачастую они проработали в этой компании много лет и знают лучше, как должна работать та или иная фича. Поэтому не углубляйтесь, сэкономьте время и пишите сразу.

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

Опиши все что только можешь в ТЗ: и текущую работу системы, и новые фичи. Так разработчик сразу поймет, что именно нужно сделать.

На доработках посложнее испугался, что разработчик не уловит контекст и не поймет, что именно нужно дорабатывать. Решил описать как сейчас документ доходит до своего текущего состояния и что для этого необходимо сделать пользователю. Документ получился объемным и совершенно бестолковым: вопросов к такому ТЗ было куда больше.

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

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

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

Аналогичная подсказка. На самом деле технический документ должен быть понятным и точным. Старайся сконцентрироваться на результате доработки, а не на Пулитцеровской премии для своего документа. Разбивай сложные мысли на более простые.

Не используй макеты, схемы и таблицы. Они будут только мешать. Лучше напиши, что новое поле должно находиться между полями 2 и 4, слева, с неймингом в две строки. Чем больше текста, тем круче специалист.

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

Форматирование? Это не курсовая работа. Оставь это студентам и школьникам с рефератами. Мы уже на серьезном уровне.

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

Оффтоп. Когда мне нужно объяснить человеку далекому от ИТ отрасли чем занимается системный аналитик, то привожу в пример курсовые работы, которые дают общее представление как выглядят зафиксированные требования в ТЗ к разработке.

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

Близкий пункт к предыдущему и касается удобства восприятия и написания. К нумерованным таблицам проще ссылаться в тексте. К тому же, это значительно упростит процесс коммуникации между членами команды, при обсуждении конкретной части документа.

Сравни:

 - Радик, у тебя в таблице номер 9 какие-то странные наименования параметра в строке 4

 - Радик, у тебя на странице 15, в той большой таблице какие-то странные наименования параметра на 4 или 5ой строке, та что под ID

Не оформляй перечисления нескольких элементов списком. Зачем увеличивать в объеме текст, который умещается в три строки?

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

Не заморачивайся над использованием одних и тех же понятий. «Документ», «Сущность», «Объект» - в целом все одно и то же. Разберутся.

При написании технической документации всегда помни, что она не художественная. Техническая документация должна быть ясной и последовательной. Употребление одних и тех же терминов в одном и том же контексте поможет избежать путаницы и повысит качество твоей работы. Для того чтобы показать на сколько богат лексикон пишите статьи на Хабре

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

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

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

Универсальный совет, для всех сотрудников. Если в голове возникли вопросы и не смог на них найти ответ – задай их коллеге. Товарищ направит тебя в нужную сторону, скинет руководство, объяснит. На самом деле, задавать вопросы — нормально. Ненормально, если ты из раза в раз задаешь один и тот же вопрос.

Не продумывай отрицательные пользовательские сценарии. Только положительные: это проблема пользователя, что он может нажать не туда и сломать процесс

Зачастую проработка отрицательных сценариев поможет тебе продумать реализацию задачи до мельчайших подробностей и сделать конечный продукт готовым и качественным.

Не участвуй в обсуждениях и митингах. Чем меньше взаимодействий, тем лучше.

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

Оставь документацию на потом. Лучше решить текущие задачи, а на документы всегда найдется время.

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

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

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

Считай, что твои идеи всегда самые лучшие. Не слушай критику.

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

Итоги

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

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

Давайте учиться на ошибках друг друга.

*все изображения сформированы при помощи нейросети Flux