Несмотря на очевидные преимущества BI-систем для крупных организаций, многие руководители избегают их внедрения. Однако, те, кто решается оптимизировать работу компании таким образом, сталкиваются с некоторыми проблемами. Незнание этих проблем зачастую заканчивается большим количеством трудоёмкой работы, высокими затратами на поддержание системы и отсутствием ощутимой пользы. В статье перечислены и разъяснены основные трудности, с которыми сталкиваются организации, принимающие решение о внедрении BI-систем.
Неудобство решения для пользователей
Внедрение новой информационной системы нередко вызывает недовольство ряда сотрудников, проявляемое по следующим причинам:
- сложность в освоении;
- представление данных в новом, не соответствующем привычному виде;
- недостаточная скорость обновления данных;
- отсутствие собственного критерия классификации в новой системе.
В данном случае, решением является сотрудничество пользователей с технологическими экспертами, а также уверенность внедряющей стороны в том, что данные собираются в нужном и удобном виде для пользователей. Также IT-службе необходимо убедиться в том, что при необходимости пользователь может углубиться в данные и найти ответ на любой вопрос.
Что прочитать для прохождения интервью на Бизнес Аналитика?
Проблемы, вызванные синхронизацией данных
Имея децентрализованную систему обработки данных, многие сотрудники организации в своих целях составляют прогнозы и рассматривают варианты событий, подставляя в собственные информационные таблицы прогнозируемые, не соответствующие действительности значения. Разумеется, данные изменения не применяются при сдаче отчётов и анализе реальных, сложившихся ситуаций. При внедрении BI-системы такие изменения немедленно вносятся в общую базу данных, вследствие чего могут быть приняты другими сотрудникамии за достоверные.
Проблемы качества данных
Система Business Intelligence должна основываться на абсолютно точных, достоверных, полных и актуальных данных, иначе она становится очередным препятствием, которое необходимо преодолеть (или проигнорировать), чтобы принять хорошее бизнес-решение.
Данную проблему невозможно решить раз и навсегда, за качеством поступаемой информации нужен постоянный контроль.
Переоценка возможностей продукта
Менеджмент организации зачастую полагает, что дорогостоящее приобретение BI-системы принесёт результаты, сопоставимые с затратами на её приобретение и поддержку. Это верное ожидание, однако некоторые руководители склонны считать, что такая инвестиция решит все существующие проблемы в аналитике деятельности компании и других сферах.
Следует понимать, что даже идеально внедрённая BI-система будет способна выполнить только заложенные в неё функции. Решением данной проблемы может являться объективное сопоставление функциональности планируемого к приобретению BI-решения с корпоративными потребностями и ожиданиями.
7. Интервьюируем ЗАКАЗЧИКОВ (выявляем бизнес-требования). Курс бизнес-аналитик с нуля
Отсутствие чёткого плана внедрения BI-продукта
Зачастую BI-система появляется в организации с целью решения какой-либо конкретной задачи. Затем, с ростом производственных мощностей, область применения BI расширяется и охватывает всё больше процессов в компании. Имеет смысл учитывать темпы развития организации и распространять влияние BI-системы пропорционально им, иначе возможно появление существенных пробелов в автоматизации деятельности компании, на ликвидацию которых уйдёт много времени и средств. Несвоевременный подход не позволит внедрённому BI-решению окупиться и стать полноценным инструментом в руках сотрудников компании.
Также необходимо обеспечивать единообразие BI-продуктов во всей компании во избежание лишних усилий для решения одних и тех же задач на разных платформах.
Привлечение аутсорсинговых компаний
Решение об отдаче части функциональных забот на аутсорсинг — в целом верная стратегия, которой придерживаются многие руководители. При таком подходе следует помнить, что сторонним компаниям нельзя доверять профильные и тактические аспекты деятельности организации. BI-система же относится именно к тактическим инструментам, поэтому отдать её внедрение и развитие сторонней компании — значит отдать на аутсорсинг свою стратегию.
Gartner: Почему многие проекты бизнес-аналитики проваливаются
В марте 2020 года аналитическая компания Gartner обнародовала некоторые результаты исследования, в котором рассказала о причинах провала многих проектов в области бизнес-аналитики (BI), а также дала несколько советов ответственным за эти внедрения руководителям.
Как пишет издание CRN в номере от 5 марта 2020 года, технологии бизнес-аналитики и управления большими данными (Big Data) остаются сферой роста для партнерского канала, поскольку клиентам нужны программные решения, сервисы и опыт для внедрения и использования умных технологий для бизнеса, чтобы лучше понимать своих заказчиков и улучшать свои операционные показатели. Но BI-проекты часто терпят неудачу, и вот почему, по мнению Gartner:
Многие проекты бизнес-аналитики проваливаются
- Производители стремятся продавать узкоспециализированные решения в области аналитики, что приводит к фрагментированным, нишевым проектам внедрения, использующим лишь тактические возможности вместо выработки оптимальной стратегии с широким охватом.
- Интернет вещей требует иных знаний и навыков, нежели традиционные проекты бизнес-аналитики. Не имея планов набора специалистов по интернету вещей, организации не смогут успешно использовать IoT-данные и создавать интеллектуальные устройства следующего поколения.
- Некоторые компании пытаются подменить технологию обучением, предоставляя «простые в использовании» и «интуитивно понятные» инструменты бизнес-анализа своим бизнес-пользователям, чтобы они могли сами анализировать данные, не принесет желаемых деловых результатов.
- Всё большее значение приобретает управление аналитикой, но его нельзя осуществлять в отрыве от управления данными.
В Gartner дают несколько рекомендации ИТ-руководителям и менеджерам, ответственным для реализацию BI-проектов. Во-первых, аналитики направлять обучению внедрению инструментов аналитики и аналитических процессов на понимание того, когда и зачем они будут использоваться, а не на то, как использовать конкретные инструменты.
Также эксперты считают необходимым оценивать уже имеющиеся приложения обработки данных, аналитики и бизнес-процессов — возможно, они включают достаточно средств машинного обучения для намеченных вами сценариев использования.
Ещё один совет — продумывать вероятные сценарии использования Интернет вещей в компании и соответствующие требования к аналитике при взаимодействии с бизнес-стратегами и архитекторами корпоративных приложений. Чаще всего проблемой будет понять, как обеспечить обработку потоковых данных от датчиков, но возможны и более сложные сценарии, что потребует встраивания аналитической технологии непосредственно в устройства на границе IoT.
Кроме того, в Gartner рекомендуют расширять управление данными, включив в него управление аналитикой. Не следует выстраивать управление аналитикой как самостоятельный процесс. Сделайте приоритетом согласованный бизнес-результат для конкретного бизнес-кейса или деловой цели.
Технологии бизнес-аналитики и управления большими данными (Big Data) остаются сферой роста для партнерского канала
По прогнозам Gartner, к 2022 году технологии расширенной аналитики будут распространены повсеместно, однако лишь 10% аналитиков будут задействовать весь их потенциал. К этому времени 40% проектов разработки и оценки моделей машинного обучения будут осуществляться в продуктах, в которых основной целью не является машинное обучение.
Также аналитики ожидают, что к 2023 году 90% среди 500 крупнейших в мире компаний объединят управление аналитикой в более широкие инициативы по управлению данными и аналитикой, а к 2025-му порядка 80% потребительских и промышленных товаров, содержащих электронику, будут выполнять аналитические процессы прямо на устройстве. [1]
См. также
Примечания
Источник: www.tadviser.ru
Как в Uplab разрабатывают сайты. Этап аналитики и проектирования
Многие компании боятся рассказывать о том, как они выстраивают работу над проектами, какие инструменты используют и как ведут диалог с клиентами. Мы другие — максимально открыты перед заказчиками и готовы щедро делиться опытом с коллегами из других агентств. Сегодня решили раскрыть все карты — запускаем цикл статей «Разработка сайтов в Uplab», в котором подробно рассмотрим процесс создания и выпуска продуктов для бизнеса. Первый материал посвящен этапу аналитики и проектирования.
Разработка любого цифрового продукта в Uplab — сайтов, мобильных приложений, интернет-магазинов, информационных порталов или сервисов — имеет классическую, но стандартизированную схему выпуска. Охватывает аналитику и проектирование, дизайн, верстку и собственно разработку. Однако подход к каждому из этапов и итерациям в них имеет ряд отличительных особенностей — его мы и раскроем в нашем цикле материалов.
Процесс реализации digital-проектов начинается с проведения аналитики и проектирования, без которых невозможно разработать сайт, который будет эффективно решать задачи заказчика. В этапе участвует сразу несколько специалистов агентства: frontend- и backend-разработчики, специалисты по поисковому продвижению, веб- и бизнес-аналитики. Ведущая роль — у системного аналитика.
За что отвечает системный аналитик
Системный аналитик выполняет основной объем работ по аналитике и проектированию: совмещает в себе функции UX-исследователя, отчасти продуктового менеджера, бизнес-аналитика, проектировщика интерфейсов и, конечно, UX-дизайнера.
Выступает в качестве лица, которое контролирует реализацию подобранных технических решений в отношении удобства взаимодействия пользователя с ресурсом, согласно требованиям заказчика, заявленным срокам и стоимости работ.
Аналитика. Сбор требований, изучение и анализ
На старте системный аналитик определяет, как новый продукт поможет заказчику достичь нужных ему целей, какие потенциальные преграды на пути к этому существуют, как можно изменить ситуацию, как следует измерять успех и каким будет возможное дальнейшее развитие проекта.
Необходимый состав работ по аналитике определяется в самом начале и зависит от разных факторов: типа проекта, предметной области, аудитории, специфики деятельности компании и т.п. В процессе аналитики, он может быть дополнен с появлением новых вводных данных.
Основные работы
Изучение предметной области
Как правило, направления деятельности наших заказчиков имеют узкую специализацию. Если с ней системные аналитики Uplab еще не знакомы, они предварительно изучают предметную область, отраслевые отчеты, статьи и новости в медиа, маркетинговые исследования (если есть), тематические форумы, сообщения в группах социальных сетей, материалы от клиента (внутренние документы с планами отдела маркетинга и продвижения продукции, технологические спецификации, каталоги продукции и др.). Выявляют особенности позиционирования компании на рынке, ее положение, репутацию и т.п.
Интервьюирование экспертов в предметной области
Проводится в основном для проектов со сложной, узкоотраслевой специализацией. Цель — разобраться с предметной областью, узнать, какие проблемы отмечают эксперты и какие они видят решения, получить понимание процессов и особенностей предметной области, пояснение характеристик и спецификаций.
Интервьюирование заказчика
Аналитик проводит интервью представителей бизнеса (стейкхолдеров), чтобы узнать запросы бизнеса, его самоопределение на рынке, ключевых конкурентов, восприятие целевой аудитории, стратегию развития компании, ограничения законодательства; чтобы лучше понять процессы в компании: ограниченность бизнес-процессов, возможность влияния на них, финансовые ограничения (какой функционал, какие покупатели приносят наибольшую прибыль и т.д.), кто по их мнению является основной аудиторией проекта.
Интервьюирование технических специалистов
Для проектов, где требуется интеграция с внутренними системами клиента, дополнительно проводятся интервью с техническими специалистами компании заказчика совместно с разработчиками Uplab. Цель — определить технические возможности и ограничения, особенности архитектуры и настроек внутренних систем клиента, требования к обмену данными и их формату.
Интервьюирование сотрудников отдела продаж
Если проект заказчика направлен на рост продаж, расширение аудитории и рынков, то дополнительно проводится интервью с представителями отдела продаж — они могут дать наиболее достоверную информацию по востребованности конкретных товаров/ услуг, кто является покупателями и пользователями продукта, детально описать стратегию продвижения продукции и процесс продаж в целом, рассказать о возможных проблемах и процессах, нуждающихся в доработках. Дополнительно может быть организовано интервью с сотрудниками отдела маркетинга.
Анализ конкурентов. Бенчмаркинг
Подразумевает изучение и анализ сайтов, приложений или сервисов конкурентов в отрасли заказчика, отраслях, близких по тематике, или кросс-категориях, а также поиск лучших решений по реализации конкретной функции. Дополнительно могут применяться такие методы, как сравнительный анализ, SWOT-анализ и конкурентный UX-анализ.
Анализ текущего состояния проекта
Не проводится при разработке нового продукта. Используется в случае полного редизайна и переосмысления проекта. Предназначен для определения и изучения положительных и отрицательных решений текущей версии продукта, сбора и анализа веб-статистики, анализа поведения пользователя на сайте. Возможные методы — эвристическая оценка и анализ систем веб-аналитики.
Анализ аудитории
Если на сайте заказчика корректно установлены счетчики аналитики и настроены цели на сбор данных, производится анализ поведения пользователей, анализ каналов трафика, а также определяются возраст аудитории, ее сегментирование, паттерны взаимодействия с элементами сайта и другие данные.
Дополнительные работы
Работы, которые проводятся по желанию заказчика, либо необходимы для решения поставленной задачив дополнение к основным. Виды этих работ определяются типом проекта, его сложностью, целями и задачами, бюджетом.
Исследование пользователей
Помогает выявить шаблоны, мотивы и логику поведения пользователей (текущих и потенциальных), понять проблематику предметной области и потребностей пользователей, принять обоснованное решение по вопросам проектирования цифрового продукта.
Системный аналитики определяет подходящий метод на основе предыдущих ограничений и специфики проекта (финансовые и географические ограничения, доступность представителей аудитории). Возможные методы: глубинное интервью, юзабилити-тестирование, удаленное онлайн-тестирование, анкетирование и опросы.
Возможно проведение юзабилити-тестирования как на начальной стадии разработки, так и на конечном продукте в рамках петли улучшений. Полученные в результате исследований данные в дальнейшем могут быть использованы при составлении персон, сценариев и карты путей пользователей.
Чтобы выявить 85% проблем интерфейса, достаточно провести юзабилити-тестирование на 5−8 пользователях-представителях каждой целевой группы аудитории продукта.
Анализ обратной связи
Такой анализ возможен, если заказчик производил сбор обратной связи. Аналитик изучает обращения клиентов заказчика, записи телефонных разговоров из колл-центра и сообщения из техподдержки, чтобы проанализировать жалобы, узнать текущие сложности взаимодействия с интерфейсом и понять, как их можно устранить или минимизировать в случае, если их устранение невыгодно бизнесу.
Метод персон
Персоны — вымышленные персонажи, созданные для представления разных типов потенциальных пользователей продукта. Создаются, чтобы получить надежное и реалистичное представление ключевых сегментов аудитории.
User Story
Краткая формулировка намерения описывает что-то, что система должна делать для пользователя. Структура user story: <роль/персонаж>, я , . Данный метод мы чаще всего используем на сервисных проектах или в тех случаях, когда вводные данные от клиента не дают четкого понимания, какой функционал необходим и зачем.
Эффективнее составлять User Story вместе с клиентом, поскольку совместная работа позволяет находиться в одном информационном поле и максимально точно понять ожидания от продукта. Историям присваивается приоритет по реализации, если необходимо разбить выпуск продукта на релизы.
Как прораб я хочу знать актуальное наличие требуемого товара в магазине и забронировать его, чтобы сэкономить время и не ездить в магазин зря.
Как мама я хочу иметь возможность посмотреть, где находится мой ребенок в данный момент, чтобы не звонить и не тревожить его лишний раз.
Метод Job to be Done применяется на сервисных проектах, когда сложно определить целевую аудиторию. Выполняется аналитиком в паре с представителем заказчика или команде. Направлен на определение результата, который пытается получить пользователь в текущих условиях.
Когда появляются мелкие поломки, я хочу подкопить поломки и вызвать одного мастера, чтобы починить все за один раз, не тратить время и деньги при вызове разных мастеров.
JTBD позволяет понять мотивацию пользователя, выявить направления развития, определить необходимый функционал.
профессор Harvard Business School
Клейтон Кристенсен
В ядре концепции Job to be Done глубокое понимание того, куда именно стремятся ваши клиенты. И это стремление выражается в их действиях. А значит вы можете предложить решение, которое поможет клиентам сделать шаг к следующей цели. В общем Jobs to be Done — это не про разовые события.
Пользовательские сценарии
Самостоятельно, вместе с командой или с заказчиком аналитик определяет шаги, которые должен проделать пользователь для достижения конечной цели. Сценариев может быть несколько. Они используются для проверки созданных прототипов.
Если условий много, то сценарии начинают разветвляться (в зависимости от предыдущих действий). Составляется user flow, который помогает в дальнейшем учесть все сценарии и отработать данные.
Карта путей пользователей (Customer Journey Map)
CJM представляет собой визуализированную историю взаимодействия потребителя с продуктом на разных каналах в определенный период времени. Позволяет от лица клиента объективно проанализировать опыт взаимодействия с продуктом, зафиксировать и устранить возникающие барьеры, предложить рекомендации по улучшению продукта, сформировать и обобщить единый клиентский опыт при омниканальном взаимодействии. Выполняется данный тип работ в основном для сервисных проектов.
Аналитика. Построение информационной архитектуры
После сбора данных и их обработки аналитик приступает к построению информационной архитектуры. Она включает в себя:
Инвентаризация контента (важно определить, какие данные должны быть размещены на страницах и как их можно связать друг с другом).
Группировка информации по ожиданиям пользователей.
Аудит контента (оценка его полезности и общей эффективности для решения поставленных задач и достижения целей проекта).
Разработка таксономии проекта (определение терминологии для классификации и систематизации содержимого ресурса).
Разработка структуры проекта.
Разработка требований к контенту.
Анализ поисковых запросов (выполняется специалистами по поисковому продвижению для лучшего ранжирования сайта в поисковых системах).
Пример структуры сайта
Дополнительно могут проводиться карточная сортировка и подготовка фактуры для копирайтеров.
Карточная сортировка
В основном применяется для сложных структур, тестирования навигации и структуры каталога. В онлайн-сервисах для тестирования пользователи сортируют различные элементы разрабатываемого сайта по нескольким категориям. Данный метод позволяет узнать реакцию аудитории и, как следствие, разработать удобную структуру и навигацию.
Подготовка фактуры для копирайтеров
Выполняется в случае, если разработкой контента полностью занимается Uplab.
Аналитика. Результаты работы
В зависимости от типа работ системный аналитик готовит следующие отчетные документы:
Анализ конкурентов (Google Документ).
Бенчмаркинг (Google Документ).
Сбор требований (Google Документ).
Структура сайта (Изображение или схема в Xmind).
Требования к контенту (Google Таблица и/ или Google Документ).
Отчет c результатами проведения интервью пользователей или юзабилити-тестирования.
CJM (Google Таблица или карта в сервисе MIRO (Realtimeboard)).
Пользовательские сценарии (Google Документ или сценарии в сервисе MIRO (Realtimeboard)).
User Story (стикеры, Google Документ или истории в сервисе MIRO (Realtimeboard)).
User Flow (карта в сервисе MIRO (Realtimeboard) и/ или схема в MS Visio).
Отчет веб-аналитики (Google Документ).
Если сотрудничество с заказчиком не предполагает разработку прототипов и последующие стадии разработки, то отдельно составляется функциональное задание, где описывается основной функционал проекта клиента.
Проектирование
Этап проектирования — важнейший в процессе разработки цифрового продукта. На этой стадии реализации проекта продумывается базовый функционал сайта, определяется его структура, выбирается оптимальный вариант размещения блоков и анализируется эффективность предлагаемой схемы. При этом происходит исследование целевой аудитории, изучаются поведенческие факторы пользователей, принимаются важные юзабилити-решения. Результатом работы на этапе проектирования является прототип.
Для чего разрабатывается прототип
Прототип — схематическое изображение веб-страниц, приложений или сервиса, которое показывает, из каких блоков и сущностей они состоят. Его также разрабатывает системный аналитик при тесном взаимодействии с frontend- и backend-разработчиками, которые выступают консультантами по техническим вопросам. В процессе создания прототипа могут также принимать участие дизайнеры и копирайтеры.
Правильно организовать систему навигации на сайте.
Наглядно представить концепцию будущего сайта до того, как перейти к его графическому оформлению.
Продумать расположение нужных блоков и элементов дизайна.
Продумать возможности взаимодействия посетителей с сайтом.
Сфокусироваться на поставленных целях и задачах.
Выявить лишние, нефункциональные элементы, от которых лучше всего отказаться, или наоборот — дополнить интерфейс важными деталями.
Выпуск прототипа цифрового продукта помогает существенно сократить время разработки сайта и заранее избежать возможных доработок, которые возникают при несоответствии функционала интернет-проекта ожиданиям заказчика.
Какие прототипы разрабатывают в Uplab
Динамический (интерактивный) прототип
Основной вид прототипов, разрабатываемых в Uplab. Имеет возможность перехода между страницами, имитирует работу большинства элементов сайта (слайдеров, всплывающих окон и др.), показывает взаимодействие пользователя с интерфейсом. Представляет собой сжатое наглядное техническое задание, которое позволяет проверить и отобразить основные сценарии проекта.
Степень проработки интерактива зависит от типа проекта, задач, технических ограничений. Однако прототип не может полноценно показать работу будущего сайта, поскольку не обращается к различным системам и базам данных.
Статический прототип
Прототип, выполненный в виде статичных изображений. Элементы на нем некликабельны, содержат комментарии с подсказками, как должен функционировать тот или иной элемент. Могут иметь разную степень детализации: низкую (грубый набросок состава страницы), среднюю и высокую. В основном используются для промо-проектов.
Изначально прототип презентуется команде. Аналитик показывает и рассказывает, что и как сделано, почему были приняты определенные решения, какой ключевой функционал в них заложен, на что стоит обратить внимание. Затем он отправляется на утверждение заказчику.
Завершающей стадией этапа аналитики и проектирования выступает разработка технического задания по проекту, в которой участвуют системный аналитик и технический специалист. Прототип не заменяет и не исключает техническое задание, поскольку не может передать часть взаимодействия пользователей с интерфейсом в силу ограниченности функционала инструментов создания прототипов (мы используем прогрессивные Axure, Sketch и Invision).
Техническое задание составляется по ГОСТ 34 и согласовывается техническим специалистом, дизайнерами и заказчиком.
Аналитики-проектировщики Uplab
После этапа аналитики и проектирования следует дизайн продукта, но об этом подробно поговорим уже в следующей статье.
Источник: www.uplab.ru
В менеджеры проекта с багажом аналитика
Не мудрено, что перемены в жизни человека, незначительные или глобальные, это всегда стресс. Возможно, до дрожи в теле. Новое пугает, но, согласитесь, это не повод стоять на месте.
Именно поэтому смена сферы деятельности часто связана с бабочками в животе. И если вы решили стать на путь менеджера проектов, свернув со скользкой дорожки системного аналитика, то в голове можете услышать, как торжественную музыку, так и волнительный шепот.
Начало
С чего же начать, подумаете вы. Поднимите гордо голову и смело посмотрите на свой новый профессиональный путь.
Если вы имеете несколько лет опыта работы системным аналитиком за плечами, значит, у вас есть отличный багаж знаний для работы менеджером проектов. Не идеальный, но отличный. И чем глубже в лес, чем больше вы втянитесь в проекты менеджером, тем чаще будете думать: спасибо, системный анализ, за то, что ты был у меня.
— Системный анализ и управление проектами — две смежные стези, разница невелика, волноваться не о чем.
— Да разница огромная! Это как слесарь и художник, мало что их связывает.
Давайте не будем слушать и читать на заборах, а разберемся самостоятельно. Что может взять себе хороший менеджер проектов от системного аналитика (органы не предлагать)?
1. Навык работы с документацией.
Системный аналитик формирует документацию проекта: техническое задание, спецификации, описание задач. Что делает хороший менеджер, если в его команде есть системный аналитик? Внимательно изучает документацию проекта и работает с ней.
Что делает хороший менеджер, если в его команде нет системного аналитика? Пишет документацию самостоятельно. Бонусы налицо.
2. Навык «базы знаний проекта».
Системный аналитик — человек, который должен знать максимально все о проекте, начиная с архитектуры, заканчивая размером хедера страниц в пикселях. Чем в данном случае отличается от системного аналитика менеджер проектов? Правильно, ничем. Чем больше менеджер знает о проекте, его деталях и тонкостях, тем лучше всем: команде, клиенту, самому менеджеру. Всем счастье.
3. Умение формировать структуру проекта.
Системный аналитик не только описывает проект на предмет «Чего изволите?», но участвует в формировании будущей системы, устанавливая и описывая взаимодействия сущностей внутри проекта, формируя прототипы интерфейсов, изучая, разрабатывая и фиксируя в документации процессы, которые будут реализовываться посредством системы. Опять же, в команде проекта должен быть как минимум один человек, который сможет это все делать (а лучше вся команда). Если вы менеджер проектов с такими умениями — большой плюс вам в карму.
4. Опыт работы в команде с разработчиками.
Только проработав с разработчиками бок о бок несколько лет, понимаешь, что это не просто люди. Это не просто профессионалы. Это твои коллеги, которым вопросы необходимо задавать правильно, в правильный момент и с правильной интонацией. Иначе можешь оказаться причиной их праведного гнева, а злить и нервировать разработчиков нельзя. Категорически.
Советую вам помнить об этом, если вы пришли в новую для вас команду разработчиков. Я вот не забываю.
5. Терпение. И еще раз терпение.
Системный аналитик — человек внимательный к деталям проекта, к команде разработки, к требованиям заказчика, к документации. И каждый из этих пунктов может ставить условия, вскрывать свои подводные камни, конфликтовать. А ваша задача — терпеливо сгладить все углы и воссоединить все в единое целое: эффективную работу над качественным продуктом.
Не кажется ли вам, что это первостепенная задача менеджера проектов? Так и есть. Совпадение на 100%.
Системный аналитик vs менеджер проектов
И вот, вдруг вам покажется, что системный аналитик и менеджер проектов — это одно и то же. Нет. Совсем не так. Задачи и цели разные, требования тем более, ведь не зря это разные позиции в штатных структурах. Говоря о полезном опыте аналитика для менеджера проектов, не думайте, что весь требуемый багаж знаний и умений у вас уже есть.
Учиться придется многому. Например:
1. Коммуникации с клиентом (не путать с общением внутри команды).
Взаимодействие с представителями клиента — это дипломатия, это наука. Искусству дипломатии посвящено множество книг, и данный скил необходимо в себе тщательно и упорно развивать, если вы хотите стать действительно хорошим менеджером проектов.
2. Крест ответственности.
Вам необходимо привыкать к тому, что теперь вы несете крест ответственности не только за свои деяния, но и за деяния своей команды, даже если это злодеяния. Проект блистает или валится с треском — это ваша вина в любом случае. Ваша команда, проект — это поле созидания: поливайте, удобряйте и следите за урожаем, потому что к успеху всегда причастны все участники, а за проблемы на проекте головой отвечаете вы, менеджер проекта.
3. Умение начать и закончить проект.
Это вопрос опыта, имеющего к системному анализу отношение весьма условное. Когда вы как менеджер реализуете N проектов, вы будете точно знать, что делать на старте проекта и что по его завершению.
4. Планирование.
Без этого навыка менеджер проектов хорошим менеджером проектов не станет. Вы должны уметь планировать время, ресурсы, работы. Только опыт работы менеджером проектов даст вам этот навык.
5. Многозадачность.
Системный аналитик берет задачу и работает над ней и только над ней, пока не завершит. Менеджер проектов работает сразу во многих направлениях, решая несколько задач одновременно. Держите в голове «диспетчер задач» со списком запущенных процессов.
6. Лидерство.
Букет из дипломатии, ответственности, умения общаться, нести ответственность, а также умения раздавать пряники и орудовать кнутом. Нашивка лидера не выдается при приходе в команду или прохождении каких-либо обучающих лидерству курсов, положение лидера зарабатывается. И если вы хотите быть успешным лидером в своей команде, помните: вы работаете с живыми людьми.
Только они могут назвать вас лидером, если вы будете вести себя соответственно. Пробуйте быть лидером и не бойтесь ошибок. Данному навыку надо учиться, учиться и еще раз учиться.
Анализируем
Итак, имея багаж системного аналитика за плечами, стать менеджером проектов все еще сложно, но уже не так, как кажется на первый взгляд.
Можно с уверенностью сказать, что менеджер проектов и системный аналитик решают смежные задачи и нога в ногу ведут проект к светлому будущему. Пожалуйста, не путайте этих людей в проекте, они тянут разные лямки. Если так уж сложилось, что в вашей команде уже есть системный аналитик, и тут появляетесь вы, менеджер проектов со шпагой в руке, не переживайте: задач хватит вам обоим и еще останется.
Мораль же моего рассказа не в том, чтобы вы дерзнули стать на путь менеджера проектов только после трудовой школы системного анализа. Всем и каждому хочется сказать одно: любите перемены и не бойтесь их! Это всегда свежий воздух с легкими нотками ваших прошлых лет и опыта, которые могут стать вашим фундаментом, опорой перед грядущим.
Если вам кажется, что вы встали на новый путь с пустыми руками, обернитесь: позади вас всегда будет ваш багаж знаний и опыта. От вас требуется только внимательно присмотреться к его содержимому.
Источник: inostudio.com