Предположим, вы в системных аналитиках недавно, например, на позиции джуна. Вы уже представляете, в чем заключается работа, и планируете развиваться в этой сфере. Еще с вами багаж общих IT-знаний, умение гуглить и/или грамотный ментор.
Через какое-то время вы осваиваетесь в изначальном проекте. Но системная аналитика, как оказалось, штука очень интересная. Поэтому вы начинаете искать, во что бы еще вляпаться — чтобы накопить больше разнообразного опыта. Компания идет навстречу и доверяет вам еще пару проектов в обмен на обещание, что качество и сроки не пострадают.
Вы принимаете условия и ввязываетесь в челлендж.
Что-то похожее когда-то происходило и со мной: становление как специалиста, желание этот процесс ускорить, постоянное поглощение информации на тему системного анализа и так далее.
Проходя по шагам процесса, я собрала свои шишки и плюшки. Поскольку учиться на своем опыте — это хорошо, а на чужом — уже следующий уровень, я бы хотела своим опытом поделиться. Возможно, кто-то, кто находится в похожей ситуации, найдет те или иные практики и подходы полезными.
А вдруг даже маститые системные аналитики увидят что-то через мой опыт под новым углом :)
N.B. Замечание выше про технические навыки было важным. Эта статья больше про развитие soft skills. Случаи, когда базовых hard skills нет совсем, здесь не рассматриваются.
Задача
Получить максимум пользы и опыта от нескольких проектов, не заставив страдать последние. И, конечно, сохранив свое собственное ментальное здоровье.
Стратегия
Принять ограничения, на которые нельзя повлиять.
Найти время и не тратить его впустую.
Подстроить темп развития под рабочие задачи.
Принимаем ограничения
В этом разделе примем следующее:
Вы напишете ерунду — в большей или меньшей степени
Заранее соглашаемся со своими ошибкамиОбъять необъятное — не самая лучшая идея
Отказываемся от идеи познать все на проекте
Вы напишете ерунду — в большей или меньшей степени
Стоит сразу принять то, что ваши первые N постановок будут... не слишком хороши. Это связано как с пониманием и привыканием к техническому стеку, так и с выработкой собственного стиля постановок, соответствующего принятому на проекте.
И это норма!
Старшие коллеги были на вашем месте и прекрасно понимают, что новичку приходится непросто (а если коллеги не понимающие — то зачем вообще такие коллеги?). На старте работы в вас ищут мысли по решению проблемы, а не конкретные и точные ответы.
Стоит заранее принять возможные ошибки, подготовиться к уточнениям со стороны разработки и/или бизнеса и впитывать-впитывать-впитывать. Хорошая новость — корректировать постановки придется всегда, даже когда вы станете продвинутым аналитиком. Регулярная перетасовка требований — это часть суровой реальности нашей работы.
Объять необъятное — не самая лучшая идея
Начинающие аналитики зачастую не понимают, как можно решать задачи без всех вводных.
Вот как-то так, с некоторой постоянной степенью неопределенности и придется дальше жить свою рабочую жизнь. Даже если проект новый, то, что вы не знаете, будет присутствовать всегда. Не говоря уже о проекте, который развивался длительное время до вашего прихода.
Если хочется узнать больше о системах как таковых, в том числе, чтобы понять, откуда же такой уровень неопределенности, можно ознакомиться с книгой Джозефа О’Коннора «Искусство системного мышления: необходимые знания о системах и творческом подходе к решению проблем».
Попытка узнать о проекте сразу все, вплоть до конкретных связей в базе данных, ни к чему хорошему не приведет. Скорее всего, вы не успеете переработать такой объем информации, запутаетесь и привнесете хаос в постановки и работу всей команды.
Для себя я выбрала проблемно-ориентированный способ исследования системы (problem-oriented research) — есть конкретная задача, для ее решения необходимы конкретные знания. Таким образом, проект постигается постепенно, без перегрузок мозга. Да, иногда мне приходится говорить: «Я не знаю», затем идти за уточнениями, но это естественная часть обучения и погружения в проект.
Ищем время
Попробуем найти время, работая с такими моментами, как:
Отказать нельзя работать
Адекватно оцениваем свои силы и не боимся про это говоритьНе изобретать велосипед, если это возможно
Изучаем типовые практики на проектеБоль или не боль
Копаемся в первопричинах поставленных задачСемь раз перечитай, один раз согласуй
Пишем грамотные постановки сразуСпасение утопающего — дело рук аналитика
Решаем потенциальное непонимание в момент его появленияБольше решительности → меньше митингов
Берем на себя ответственностьШаблонизировали, шаблонизировали да и вышаблонизировали
Облегчаем создание постановок
Отказать нельзя работать
Как бы вам не хотелось прыгнуть выше головы, спокойно и взвешенно обдумайте, сколько задач/проектов вы можете вести одновременно — и правильно поставьте запятую в предложении из заголовка. Самое страшное — стать заложником идеи «Чем больше задач я возьму, тем лучше я покажу свою мотивацию».
Это, конечно, прекрасно, только вот вашему руководству нужен качественный результат и продуктивный работник, у которого не слипаются глаза от переработок в ночи. Будьте честными перед собой и начальством. Не потянете — не влезайте, успеете еще поучаствовать в проектном марафоне :)
Разберу на своем примере. Грамотно распределить силы между тремя проектами мне больше всего помогли три основных фактора:
все проекты на разной стадии развития;
А это означает, что и вовлечение аналитика везде разное. Потянуть несколько проектов в активном развитии было бы нереально.проекты построены на схожей архитектуре;
Мне не пришлось вникать сразу в три разных технологических стека.над первым проектом я уже работала больше полугода.
Т.е. представление архитектуры какое-никакое, но присутствовало, вместе с пониманием взаимодействия с разработкой и бизнесом.
Не изобретать велосипед, если это возможно
На проекте скорее всего уже существует набор гласных и не очень договоренностей относительно того, как что-то схожее необходимо разрабатывать. Это могут быть мелочи, например, snake_case или camelCase принят в наименованиях параметров. Или что-то покрупнее, например, способы вывода информации на UI. И знание таких «правил» сильно облегчает аналитику работу — достаточно ориентироваться на них. Плюс ко всему это поддерживает систему в унифицированном виде. Здесь совершенно не имеется в виду, что предлагать новых решений не нужно совсем — но предложения должны быть разумными и обоснованными.
Боль или не боль
Еще один хороший способ разгрузить себя — думать о том, что на самом деле болит у пользователя. Разберу на примере.
Клиент звонит в техподдержку и требует подробный кастомизированный отчет по опаздывающим сотрудникам — их стало слишком много. Нужные данные в системе есть, поэтому сотрудник техподдержки заводит задачу на разработку.
Разработка видит, что ни требований, ни чего-то подобного им нет, и призывает на помощь аналитика.
Аналитика настораживает нетипично большое число опаздывающих, поэтому он просит задать клиенту несколько уточняющих вопросов.
В итоге выясняется, что у клиента сломано считывающее устройство для пластиковых карт на входе в офис, поэтому часть информации о проходах не фиксируется в системе.
Стандартная процедура ремонта считывателя решает проблему клиента, и необходимость индивидуального отчета отпадает. Гипотетически, можно рассмотреть возможность информирования техника или иного ответственного лица о неисправности считывателя, но это не всегда реализуемо в силу технических особенностей взаимодействия считывателя с системой контроля доступа.
Да, хороший аналитик — немного сотрудник техподдержки, докапывающийся до истинной причины хотелок.
Когда кто-то приходит с идеей — хорошая практика взять время на «подумать». Можно посоветоваться с более опытными коллегами, если вы еще не готовы сами провести исследование на выявление болячки. Возможно, озвученное требование заказчика не является первопричиной его обращения.. В конце концов, это время на «подумать» окупится более рациональным решением проблемы, а как бонус — заказчик станет даже счастливее, т.к. его истинная проблема решена.
Семь раз перечитай, один раз согласуй
У аналитиков есть две крайности при написании постановок.
Первая — написать хоть что-то, чтобы быстрее согласовать. А подробностями наполнять в ходе разработки и тестирования. Этот подход в большей мере отвечает гибким методологиям разработки. Вторая — сразу написать качественную постановку с необходимой степенью детализации.
На моей практике были проекты и с тем, и с другим вариантами. И, по моим прикидкам, написать один раз подробно или много раз дописывать — занимает одно и то же время. Только при постоянном переписывании вы не можете оторваться от сопровождения разработки и заняться другими задачами/проектами.
Мне кажется, что между «напиши сразу с подробностями» и «напиши идею, а там разберемся» много промежуточных точек, этакий спектр возможных написаний постановок. И в какой точке этого спектра остановиться — задача многопараметрическая, в нее входят, например, квалификация аналитика и разработчиков, релизная политика и так далее. Создание постановки под конкретный проект — это умение выделить ту часть спектра, которая полезна в конкретной ситуации. Для себя я выбрала левую часть этого спектра — потому что мне комфортнее тратить меньше времени на сопровождение разработки и тестирования, и я справляюсь с созданием постановок с нужной степенью детализации в установленные сроки. К сожалению, это не означает, что я никогда не исправляю и не дополняю :)
Спасение утопающего — дело рук аналитика
На согласовании постановок полезно быть внимательным к реакциям членов команды. Обычно по голосу и тону вопроса можно понять, что человек не уверен в предлагаемых решениях и/или не понял, в чем они заключаются. Если непонимание относится к предлагаемому в постановке или бизнес-смыслу процесса, аналитику стоит сразу прийти на помощь. Как вариант — отдельно созвониться с коллегой после согласования. Чем отчетливей каждый член команды понимает что мы делаем, зачем и почему именно так — тем проще будет идти сопровождение разработки и тестирования.
История о подобном «понимании» людей — это история об эмоциональном интеллекте. Книг и статей по нему очень много, как одну из базовых выделю Дэниела Гоулмана «Эмоциональный интеллект. Почему он может значить больше, чем IQ»
Но спасая других, важно не забыть спасти и себя, когда понадобится. Если предложенное коллегами решение хоть сколько-то непонятно, нужно обязательно разобраться: изучить источники, найти примеры, расспросить автора идеи. До тех пор, пока не получится связно рассказать решение своими словами.
Больше решительности → меньше митингов
Аналитик должен иметь смелость принять на себя ответственность за решения — особенно спустя некоторый срок работы на проекте. Если хочется оградить себя от возможных проблем фразой: «Я сделал это так, потому что это подтвердил Ваня Иванов» — лучше не ходить в аналитику. Стоит понимать, что на вас также есть ответственность, и разумно ею распоряжаться.
Однако, эта ответственность имеет и свои преимущества. Если вы понимаете, как должно отрабатывать то или иное решение, грамотно зафиксировали замечания более опытных коллег в постановке и готовы отвечать за эту постановку — вам не нужны постоянные митинги и досогласования. Избавиться от них совсем не выйдет, но самостоятельно принять решение о переименовании параметра вполне можно.
Шаблонизировали, шаблонизировали да и вышаблонизировали
Скорее всего, на проекте, на который вы попали, уже есть устоявшиеся способы описания какого-либо функционала, например, методов API. Такие шаблоны сильно сокращают время создания постановок, и, зачастую, в них уже заложены типовые вопросы от разработки — вам достаточно грамотно заполнить шаблон, и вопросов к вам от тех, кто будет работать по вашей постановке будет меньше.
В процессе можно нарабатывать и свои шаблоны. К примеру,у вас есть периодическая задача реализации загрузки документов нового для системы формата. А это означает, что нужно добавить шаблоны документов на backend и вывести их на UI с корректными названиями. Поскольку набор действий всегда одинаковый, можно оформить себе шаблон, который будет кочевать из постановки в постановку.
Также полезно спросить других коллег-аналитиков на предмет таких шаблонов и не забывать делиться своими :)
Развиваемся
Развиваемся посредством:
Аналитическое Что? Где? Когда?
Учимся постоянно задавать вопросыНе «сложно», а «нужно подумать»
Соглашаемся принимать челленджиЛюбопытство — не порок
Ищем пути улучшения
Аналитическое Что? Где? Когда?
Эти и другие открытые вопросы должны сопровождать аналитика на ранних этапах деятельности. Поначалу, аналитик, особенно начинающий, сам не предлагает способы решения задач — он собирает материал, разбирается, уточняет у ответственных за функционал, как это лучше решить.
И в момент таких уточнений и сбора информации, придется побыть надоедливым. Полезно спрашивать, что мы хотим иметь на выходе, зачем использовать такие технологии, почему принято подобное решать именно так и так далее, и так далее. Спрашивать у всех — от дизайнера до архитектора. Учиться по книжкам и статьям хорошо, но реальный рабочий опыт этого не заменит — так почему же не взять во внимание и чужой опыт?
P.S Конечно, здесь нужна разумная балансировка — не стоит уматывать коллег раньше времени :)
Не «сложно», а «нужно подумать»
Не отказывайтесь от задач, которые представляют для вас некоторый челлендж в плане решения. Да, страшно. Да, сложно. Но сидение на однообразных понятных задачах никогда не поможет вам вырасти. Скорее всего, если вам предлагают задачу, то верят, что вы с ней справитесь, пусть и не совсем самостоятельно.
Любопытство — не порок
….а главное преимущество развивающегося аналитика. Причем не только в сфере технологий, которые вы используете на проекте.
В книге Джули Дирксен про обучение получение новых знаний человеком сравнивалось со складыванием вещей в шкаф.
Новое знание — огромная куча вещей, и от того, как хорошо вы разложите их в шкаф, будет зависеть, насколько хорошо вы усвоите материал. А вот полочки в шкафу — это предыдущий бэкграунд. Чем он богаче — тем больше полочек у вас есть и тем больше шансов разложить вещи грамотно с первого раза. Поэтому проявлять любопытство полезно, ни в коем случае не ограничивая себя изучением технологического стека. В принципе, это полезно не только аналитику :)
Вместо вывода
Каждый аналитик в процессе работы накапливает выводы и способы решения всяких проблемных ситуаций. Это и есть опыт! У каждого он свой, и шишки набивать бывает полезно. Но, как сказано выше, учиться на чужих ошибках и открытиях часто безболезненнее.
Иногда самые очевидные вещи укладываются в голове и приживаются в практике, только когда прочтешь или услышишь их от кого-то.
Очень здорово, если вы нашли для в статье полезные для себя подходы: научились смирению (с ограничениями :) ), поняли как беречь время или увидели пути развития.
Мои согласования обычно заканчиваются фразой «Вопросы, предложения, угрозы?»
Так и здесь, если у вас есть проверенные практики, положительный и негативный опыт, вы категорически (не)согласны с материалом статьи — буду рада всем дискуссиям в комментариях!