Автор статьи: Марина Васильева
Консультант департамента 1С КОРУС Консалтинг
Привет, я Марина, аналитик 1С, уже полгода занимаюсь развитием учетной системы заказчика (1С ERP). Меня подключили к проекту на этапе сопровождения. Я тогда только устроилась в КОРУС. Мне нужно было заменить текущего ключевого участника команды (его очень ждали на другом проекте). К тому моменту коллеги уже запустили основные процессы – работала цепочка оформления продажи клиентам, перемещения товаров между складов, складское хранение, закупки у поставщика. Команда работала четко и слажено.
Внедренная система сильно отличалась от типовой конфигурации. В частности, ребята разработали новые документы, а привычные операции оформлялись в непривычных рабочих местах (в 1С «типовая конфигурация» – это система от вендора «из коробки». Она дает возможность решать базовые учетные задачи. Например, оформить заказ клиента и продать ему товар).
Туда же добавились сложные процессы заказчика: много направлений бизнеса, импортные закупки, расчеты в валюте. Первое время я приходила на встречи и не понимала, о чем речь и как работает система. А в проект нужно было включаться оперативно (классика).
Сегодня я ключевой участник команды, веду блок «Продажи». Уже через две недели после старта работы я сама спокойно ставила задачи разработчикам. А через месяц – почувствовала себя уверенно внутри проекта. И есть то, что помогло мне максимально быстро въехать в курс дела, не потратив кучу нервов и времени.
В чем разница функционала аналитика в начале проекта и на этапе развития системы
Функции аналитика меняется от этапа к этапу. На старте ты в основном занимаешься изучением потребностей бизнеса, описанием процессов и моделированием будущей системы. На этом этапе у тебя есть все шансы глубоко изучить процессы заказчика.
На следующем этапе (разработка) ты ставишь задачи, передаешь их коллегам разработчикам, тестируешь. На старте в системе еще ничего не доработано. Ты можешь сам выбрать вариант реализации, продумать детали взаимодействия с другими блоками.
Перед запуском проводятся различные приемо-сдаточные испытания. Проходит обучение пользователей. Аналитик готовит сценарии тестирования, проводит демонстрации, собирает обратную связь для доработок. Это важный этап. Ему может быть посвящена отдельная статья, так как от качества обучения во многом зависит последующее количество исправлений.
В момент запуска аналитик превращается в сотрудника поддержки. Помогает пользователям, и исправляет баги. Это напряженный этап. Многие скажут, что он самый сложный.
И наконец про этап развития. Здесь аналитик также занимается поддержкой системы, сбором требований к доработкам текущего функционала. Система уже рабочая. Участники команды знают процессы и как найти подход к разработчикам, ключевым заказчикам. А те уже привыкли, что аналитик их понимает с полуслова. При сборе требований пользовать может не проговаривать часть деталей, так как считает их очевидными. В системе накоплено много доработок. Ты, как аналитик, можешь быть не согласен с таким вариантом реализации. Сроки запуска обычно сжаты и не всегда есть возможность потратить много времени на доработку. Приходится искать компромисс между функциональностью и трудозатратами. Иногда это приводит к тому, что функционал получается не слишком «дружелюбным» к последующим доработкам. А иногда это рождает очень сложные интерфейсы. Пользователи к ним привыкли, а ты – нет! Твои доработки должны выполняться с учетом уже реализованного функционала. Ты должен понимать текущую архитектуру проекта и учитывать ее в своих решениях. Это непросто.
Основные шаги для включения аналитика в проект
Я выделила четыре ключевых направления, которые нужно изучить и проработать для погружения в проект.
Эффективное погружение в проект – это параллельная работа по всем четырем блокам. На своем примере хочу рассказать, с какими сложностями столкнулась, проходя через них. И что мне в конечном итоге помогло.
Проект: погружение в бизнес-процессы и предметную область
На мой взгляд, основные проблемы возникают на этом этапе. Поэтому начнем с него. Разберем основные сложности.
Запутанные бизнес-процессы, много доработок и нетипового функционала
Можно сказать, что мне очень повезло с моментом включения в проект. Команда как раз готовилась к обновлению системы на новые релиз от вендора. Соответственно, нужно было проверить, что все ключевые процессы будут работать хорошо и ничего «не встанет». У команды были готовые сценарии тестирования функционала. Они стали базой моего знакомства с бизнес-процессами заказчика. Если таких сценариев нет – подойдет инструкция по процессу / запись обучающего ролика с пользователями. По этой информации сценарий можно составить самостоятельно.
Что сценарий должен включать: для нашего варианта «знакомства» с системой хватит названия кейса, выполняемых действий (по шагам: что я делаю, куда нажимаю), результата (что произошло в системе) и тестового пользователя. Так же в табличку со сценариями я добавляла результат и вопросы для коллег.
Я брала сценарий / инструкцию по функционалу. И на тестовой базе пыталась повторить эти шаги. Если мой результат не совпадал с тем, что в сценарии или инструкции – я писала наставнику и задавала вопрос.
После прохождения основных кейсов картинка немного начала складываться. Для себя я сделала вывод, что это отличный способ познакомиться с проектом и реализованной системой.
Вот так выглядела моя табличка со сценарием:
Проблемы с документацией (или ее отсутствие)
Конечно, с погружением в проект может помочь качественная документация. Но с ней все не так однозначно.
Если это крупный сданный проект, то ситуация «полное отсутствие документации» маловероятна. Скорее наоборот – есть какое-то огромное ТЗ и инструкции, написанные перед сдачей. (Которые сейчас не совсем актуальны!). Непонятно, с чего начать знакомство и не всегда понятно, о чем вообще идет речь.
Я бы посоветовала сразу уточнить у наставника, что читать и в каком порядке. Если с официальными документами беда, то в качестве «документации» можно использовать другие источники.
Используем описание задач в трекере (или любой другой используемой у вас системе описания задач) как источник информации. Открываем общий поиск по задачам, вбиваем ключевые слова Я вбивала название функционала в поиск по задачам. И по каждой более менее подходящей задаче читала описание. Да, конечно, нужно учитывать, что и оно можем быть неактуальным. Но лучше что-то, чем ничего.
Покажу на примере:
Мне была поставлена задача на доработку новой рассылки писем клиентам компании. Какие-то виды рассылок уже были реализованы. Мне нужно было разобраться, как они работают и на основании этой информации описать свою задачу.
Я запустила поиск по задачам в нашем трекере – Jira. Настроила фильтр по проекту внедрения ERP. Нашла похожие задачи. Прочитала постановку к ним и разобралась, как сделан механизм.
Правда нужно быть внимательным! Фильтровать задачи по датам работ, системе. С одной из задач было забавно. Мы дорабатывали отчет по задолженности клиентов. Нашла задачу, которая описывает нужный мне функционал. Но не посмотрела, что это были требования совсем не к ERP.-системе. А к той, что у заказчика была до этого. И задача была создана в 2018 году!!! А я минут 30 разбиралась в ее требованиях))) Конечно, доработка была уже совсем не актуальна!
Улучшить поиск можно, если у вас достаточно технических навыков зайти в хранилище системы и посмотреть, по каким номерам трекера делались доработки по вашему объекту системы. Тогда ищите задачи не по наименованию, а сразу по номеру
Еще я использовала чаты, в которые меня добавили. Все как в прошлом совете – поиск по ключевым словам может помочь найти ответ на ваш вопрос.
Много терминов и непонятных слов
В каждой компании есть свой внутренний сленг. Первое время я приходила на встречи и вообще не понимала, о чем речь. А иногда мне казалось, что я все поняла, но потом выяснялось, что это не так. Например, стандартный для ERP документ «Заказ клиента» заказчик называет «Счет». А для ERP «счет» — это вообще другой документ. Конечно же я подумала, что речь идет о документе «Счет». И написала техзадание на доработку не того документа. Хорошо, что разработчик был знаком с процессами компании лучше меня и попросил еще раз уточнить, что заказчик имел в виду. А могли бы доработать не то!
Я проанализировала этот кейс, поняла свою ошибку. Поговорила с коллегами и получилось следующее:
Сразу после решения проблем с доступами и знакомству с командой нужно попросить у коллег Глоссарий или список терминов, сокращений. На больших проектах часто этот «документ» есть. Это так? Вам повезло! Прочитать, сохранить себе в папочку. С «официальными» сокращениями это поможет. А если такого «документа» нет?
Попросить наставника ввести в курс дела по внутреннему жаргону заказчика. Но есть риск, что наставник может быть слишком глубоко погружен в проект и уже успел забыть, что «КП» это не только коммерческое предложение, но и «Кредитная политика». Поэтому я советую обратиться к другому более «опытному» новичку. Он сам не так давно прошел погружение в проект и знает, с какой проблемой вы столкнулись.
Параллельно со всем этим составляем свой собственный глоссарий. Кстати его потом можно будет использовать для включения в проект других новичков. От руководителя точно получите плюсик за инициативность.
А еще можно написать во внутренний чат:
«Коллеги, привет! За неделю я успела услышать от заказчика много непонятных слов. Уже успела познакомиться с терминами ФОБ, Контейнер, Сборка. Собрала это в словарик. Но все равно многое не понимаю. Например, что коллеги имеют в виду, когда говорят, что заказ «роздан»? Покидайте в чат основные слова / термины, которые специфически используются у заказчика. Я потом их добавлю в словарик для будущих поколений!».
Даже занятые коллеги скорее всего откликнутся и найдут 5 минут, чтобы покидать в вас непонятными терминами. С каждого по термину и уже станет более понятно!
Уточняйте у заказчика
Да, заказчик тоже в курсе что вы пришли в проект только вчера. И да, всегда можно и нужно проговорить «Правильно я понял, что под «Счетом» вы имели документ «Заказ клиента», и мы будем дорабатывать его». Ну и, конечно, всегда лучше спросить о значении термина, если чего-то не поняли. Это займет дополнительную минуту. Зато вы поймете, о чем речь и качественно соберете требования. Но этим советом лучше не пользоваться, если непонятно вообще все))) Тут лучше поставить запись, выслушать проблему заказчика и пойти с вопросами к коллегам.
Правила работы
База, без которой не получится начать работу. Необходимо получить доступы к впн сервисам, трекерам, порталам. Вступить в нужные чаты. Познакомиться с процессом работы с задачей: как и где мне брать задачи, кто определяет приоритет. Как задача ведется по жизненному циклу — кто и когда меняет статусы в трекере. Узнать, как построена работа внутри команды: каналы коммуникации, есть ли ежедневные встречи, ретро, как задачи распределяются по разработчикам, есть ли какие-то дополнительные программы (например, isi retro, отдельные базы для учета времени).
Что будет, если это не сделать: на заре работы на проекте я готовила длинный тест-кейс в базе. И хотела закончить его «завтра утром». В итоге «завтра утром» я зашла в базу, а там пусто! Оказалось, что тестовый пример я проходила на копии, которая каждую ночь перезаливается данными из продуктивной системы. И, конечно, все затерлось! Ура! А могла бы и уточнить, где лучше тестить задачи)
Моя роль в команде и проекте
На начальном этапе важно обсудить РП ваши обязанности. Если на проекте используется инструмент управления проектом (например СППР), данная информация уже зарегистрирована в нем, в том числе требования и ответственные со стороны заказчика. Если же прямо источника информации нет, обязательно уточняем у РП ваш функционал – разграничиваем зоны ответственности и составляем план работ на ближайшее время. Можно зафиксировать это в письменном виде.
Для погружения хорошо начинать с малых задач: багов и небольших доработок по одной функциональной области. Благо на этапе развития такого «добра» обычно полный беклог. Такой подход позволяет по частям погружаться в процессы. Риск «все сломать» довольно низок.
До передачи в разработку первые поставленные задачи я показывала наставнику / архитектору (кто был доступнее в моменте). Уточняла, ничего ли не упустила. Собирала обратную связь по постановке. Корректировала ее.
Кстати, после первой задачи я получила «прекрасную» обратную связь: «Описано все просто супер, но разработчик ничего не поймет!». Оказывается от меня ждали в том числе техническое описание задачи, а я указала только функциональные требования.
Выполнение рекомендаций из пунктов выше позволило мне избежать сложностей на дальнейших этапах погружения. Как оказалось, главное – коммуницировать и задавать вопросы команде. Поэтому перейдем сразу к ней.
Коммуникации
Именно команда играет важную роль в успешном погружении в проект. Потому что коллеги – основной источник информации о проекте. Скорее всего на митинге вас представят команде. РП скажет: «Это наш новый член коллега, давайте все ему помогать». И хорошо, если дадут наставника. Но дальнейшие действия зависят от вас. И, конечно, самая частая проблема:
Коллеги по команде вечно заняты и не могут помочь
Что делать? Для себя я вывела следующие пункты:
Заранее бронировать время занятого наставника / архитектора. Забивать это время в календаре.
Ко встрече готовить список вопросов. Можно вложить его прямо во встречу, чтобы у коллеги была возможность увидеть, что вам нужно.
Узнавать информацию у тех, у кого чуть больше свободного времени. Это могут быть другие консультанты или недавние «новички».
И самое главное. То, что помогло мне. Важно установить личный контакт с участниками команды. Когда я подключилась к проекту, то созванивалась с каждым участником лично. Буквально на пару минут. Мы знакомились, я рассказывала о своем планируемом функционале, коллеги – о своей зоне ответственности. Команда – это ваша опора в проекте. А личный контакт – основа этой опоры.
Во время одной такой встречи выяснилось, что мы с моей коллегой – почти полные тезки! У нас одинаковое имя, девичья фамилия. А еще мы родились и выросли в одном городе. Наш РП пошутил, что слишком уж много совпадений и скоро в проекте откроется портал в другое измерение))
Непонятно, как строить коммуникацию с заказчиками
Хорошо еще на этапе погружения узнать у команды, как и где общаться с заказчиками. Из банального: основной канал коммуникации это skype или почта? А может вообще какой-то мессенджер.
У меня был случай: написала пользователю в почту. Ждала ответ пару дней. А он почтой не пользуется, так как там завал. И все коммуницируют с ним через skype. Мне стоило заранее уточнить у коллег нюансы коммуникации с моими ключевыми пользователями. Например, какие вопросы это могут быть:
как проходят встречи с этим заказчиком? Например, вы больше слушаете или сами штурмите идеи?
Как у заказчика со временем? Он вечно занят и стоит бронировать календарь за неделю? Или можно планировать встречу день в день?
Итого
Что хочу сказать в конце:
Напомню, что успешное погружение в проект состоит из следующих аспектов: регламенты работы, моя роль, выстраивание коммуникаций и знакомство с бизнес-процессами.
Погружаться в проект – сложно. На это не может уйти один день. И даже одна неделя. Это плавный процесс. С каждым днем слова будут становиться понятнее, бизнес-процессы по кирпичикам начнут складываться в единую картинку.
Нет задачи сразу охватить и узнать все и вся. Да, общая логика системы у вас в голове появится. Но даже спустя год (годы?) работы в проекте могут быть блоки, которые для вас не знакомы. И вы всегда сможете разобраться в них по мере необходимости.
Команда – опора на этапе погружения. Важно установить личный контакт, не бояться задавать вопросы. И в обратную сторону быть открытым к вопросам коллег.