Предположим, вы в системных аналитиках недавно, например, на позиции джуна. Вы уже представляете, в чем заключается работа, и планируете развиваться в этой сфере. Еще с вами багаж общих IT-знаний, умение гуглить и/или грамотный ментор.

Через какое-то время вы осваиваетесь в изначальном проекте. Но системная аналитика, как оказалось, штука очень интересная. Поэтому вы начинаете искать, во что бы еще вляпаться — чтобы накопить больше разнообразного опыта. Компания идет навстречу и доверяет вам еще пару проектов в обмен на обещание, что качество и сроки не пострадают.

Вы принимаете условия и ввязываетесь в челлендж.

Что-то похожее когда-то происходило и со мной: становление как специалиста, желание этот процесс ускорить, постоянное поглощение информации на тему системного анализа и так далее.

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

А вдруг даже маститые системные аналитики увидят что-то через мой опыт под новым углом :)

N.B. Замечание выше про технические навыки было важным. Эта статья больше про развитие soft skills. Случаи, когда базовых hard skills нет совсем, здесь не рассматриваются.

Задача

Получить максимум пользы и опыта от нескольких проектов, не заставив страдать последние. И, конечно, сохранив свое собственное ментальное здоровье. 

Стратегия

1. Принять ограничения, на которые нельзя повлиять.

2. Найти время и не тратить его впустую.

3. Подстроить темп развития под рабочие задачи.

Принимаем ограничения

В этом разделе примем следующее:

1. Вы напишете ерунду — в большей или меньшей степени
   Заранее соглашаемся со своими ошибками

2. Объять необъятное — не самая лучшая идея
   Отказываемся от идеи познать все на проекте

Вы напишете ерунду — в большей или меньшей степени

Стоит сразу принять то, что ваши первые N постановок будут... не слишком хороши. Это связано как с пониманием и привыканием к техническому стеку, так и с выработкой собственного стиля постановок, соответствующего принятому на проекте.
И это норма!

Старшие коллеги были на вашем месте и прекрасно понимают, что новичку приходится непросто (а если коллеги не понимающие — то зачем вообще такие коллеги?). На старте работы в вас ищут мысли по решению проблемы, а не конкретные и точные ответы.

Стоит заранее принять возможные ошибки, подготовиться к уточнениям со стороны разработки и/или бизнеса и впитывать-впитывать-впитывать. Хорошая новость — корректировать постановки придется всегда, даже когда вы станете продвинутым аналитиком. Регулярная перетасовка требований — это часть суровой реальности нашей работы. 

Объять необъятное — не самая лучшая идея

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

Если хочется узнать больше о системах как таковых, в том числе, чтобы понять, откуда же такой уровень неопределенности, можно ознакомиться с книгой Джозефа О’Коннора «Искусство системного мышления: необходимые знания о системах и творческом подходе к решению проблем».

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

Для себя я выбрала проблемно-ориентированный способ исследования системы (problem-oriented research)  — есть конкретная задача, для ее решения необходимы конкретные знания. Таким образом, проект постигается постепенно, без перегрузок мозга. Да, иногда мне приходится говорить: «Я не знаю», затем идти за уточнениями, но это естественная часть обучения и погружения в проект.

Ищем время

Попробуем найти время, работая с такими моментами, как:

1. Отказать нельзя работать
   Адекватно оцениваем свои силы и не боимся про это говорить

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

3. Боль или не боль
   Копаемся в первопричинах поставленных задач

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

5. Спасение утопающего — дело рук аналитика
   Решаем потенциальное непонимание в момент его появления

6. Больше решительности → меньше митингов
   Берем на себя ответственность

7. Шаблонизировали, шаблонизировали да и вышаблонизировали
   Облегчаем создание постановок

Отказать нельзя работать

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

Это, конечно, прекрасно, только вот вашему руководству нужен качественный результат и продуктивный работник, у которого не слипаются глаза от переработок в ночи. Будьте честными перед собой и начальством. Не потянете — не влезайте, успеете еще поучаствовать в проектном марафоне :)

Разберу на своем примере. Грамотно распределить силы между тремя проектами мне больше всего помогли три основных фактора:

• все проекты на разной стадии развития;
  А это означает, что и вовлечение аналитика везде разное. Потянуть несколько проектов в активном развитии было бы нереально.

• проекты построены на схожей архитектуре;
  Мне не пришлось вникать сразу в три разных технологических стека.

• над первым проектом я уже работала больше полугода.
  Т.е. представление архитектуры какое-никакое, но присутствовало, вместе с пониманием взаимодействия с разработкой и бизнесом. 

Не изобретать велосипед, если это возможно

На проекте скорее всего уже существует набор гласных и не очень договоренностей относительно того, как что-то схожее необходимо разрабатывать. Это могут быть мелочи, например,  snake_case или camelCase принят в наименованиях параметров. Или что-то покрупнее, например, способы вывода информации на UI. И знание таких «правил» сильно облегчает аналитику работу — достаточно ориентироваться на них. Плюс ко всему это поддерживает систему в унифицированном виде. Здесь совершенно не имеется в виду, что предлагать новых решений не нужно совсем — но предложения должны быть разумными и обоснованными.

Боль или не боль

Еще один хороший способ разгрузить себя — думать о том, что на самом деле болит у пользователя. Разберу на примере.

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

Аналитика настораживает нетипично большое число опаздывающих, поэтому он просит задать клиенту несколько уточняющих вопросов.

В итоге выясняется, что у клиента сломано считывающее устройство для пластиковых карт на входе в офис, поэтому часть информации о проходах не фиксируется в системе.

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

Да, хороший аналитик — немного сотрудник техподдержки, докапывающийся до истинной причины хотелок. 

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

Семь раз перечитай, один раз согласуй

У аналитиков есть две крайности при написании постановок.

Первая — написать хоть что-то, чтобы быстрее согласовать. А подробностями наполнять в ходе разработки и тестирования. Этот подход в большей мере отвечает гибким методологиям разработки. Вторая — сразу написать качественную постановку с необходимой степенью детализации.

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

Мне кажется, что между «напиши сразу с подробностями» и «напиши идею, а там разберемся» много промежуточных точек, этакий спектр возможных написаний постановок. И в какой точке этого спектра остановиться — задача многопараметрическая, в нее входят, например, квалификация аналитика и разработчиков, релизная политика и так далее. Создание постановки под конкретный проект — это умение выделить ту часть спектра, которая полезна в конкретной ситуации. Для себя я выбрала левую часть этого спектра — потому что мне комфортнее тратить меньше времени на сопровождение разработки и тестирования, и я справляюсь с созданием постановок с нужной степенью детализации в установленные сроки. К сожалению, это не означает, что я никогда не исправляю и не дополняю :)

Спасение утопающего — дело рук аналитика

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

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

Но спасая других, важно не забыть спасти и себя, когда понадобится. Если предложенное коллегами решение хоть сколько-то непонятно, нужно обязательно разобраться: изучить источники, найти примеры, расспросить автора идеи. До тех пор, пока не получится связно рассказать решение своими словами.

Больше решительности → меньше митингов

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

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

Шаблонизировали, шаблонизировали да и вышаблонизировали

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

В процессе можно нарабатывать и свои шаблоны. К примеру,у вас есть периодическая задача реализации загрузки документов нового для системы формата. А это означает, что нужно добавить шаблоны документов на backend и вывести их на UI с корректными названиями. Поскольку набор действий всегда одинаковый, можно оформить себе шаблон, который будет кочевать из постановки в постановку.

Также полезно спросить других коллег-аналитиков на предмет таких шаблонов и не забывать делиться своими :)

Развиваемся

Развиваемся посредством:

1. Аналитическое Что? Где? Когда?
   Учимся постоянно задавать вопросы

2. Не «сложно», а «нужно подумать»
   Соглашаемся принимать челленджи

3. Любопытство — не порок
   Ищем пути улучшения

Аналитическое Что? Где? Когда?

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

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

P.S Конечно, здесь нужна разумная балансировка — не стоит уматывать коллег раньше времени :)

Не «сложно», а «нужно подумать»

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

Любопытство — не порок

….а главное преимущество развивающегося аналитика. Причем не только в сфере технологий, которые вы используете на проекте.

В книге Джули Дирксен про обучение получение новых знаний человеком сравнивалось со складыванием вещей в шкаф.

Новое знание — огромная куча вещей, и от того, как хорошо вы разложите их в шкаф, будет зависеть, насколько хорошо вы усвоите материал. А вот полочки в шкафу — это предыдущий бэкграунд. Чем он богаче — тем больше полочек у вас есть и тем больше шансов разложить вещи грамотно с первого раза. Поэтому проявлять любопытство полезно, ни в коем случае не ограничивая себя изучением технологического стека. В принципе, это полезно не только аналитику :)

Вместо вывода

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

Иногда самые очевидные вещи укладываются в голове и приживаются в практике, только когда прочтешь или услышишь их от кого-то.

Очень здорово, если вы нашли для в статье полезные для себя подходы: научились смирению (с ограничениями :) ), поняли как беречь время или увидели пути развития.

Мои согласования обычно заканчиваются фразой «Вопросы, предложения, угрозы?»
Так и здесь, если у вас есть проверенные практики, положительный и негативный опыт, вы категорически (не)согласны с материалом статьи — буду рада всем дискуссиям в комментариях!