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

В нестабильные и кризисные времена руководству компании как никогда важно знать возможности своих сотрудников, их потенциал, вектор развития.

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

Каждый руководитель задавался следующими вопросами:

·         Что можно сделать, чтобы снизить текучку кадров и сопутствующие расходы?

·         Как экономить время дорогих сотрудников на проведение собеседований?

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

·         Как понять, что сотрудник находится на своём месте и занимается тем, что ему интересно?

·         Как понять, кто в случае форс-мажора сможет заменить уникального специалиста?

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

Внедрение оценки компетенций оказалось очень непростой задачей, которая решалась нами в несколько этапов.

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

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

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

Наш случай был такой же. Около 2 месяцев ушло на выявление требований к системе Билинга по учету оплаты за содержание лабораторных животных. Это миллионный оборот клеток, десятки комнат, сотни полок и тарифов, учет особого питания и ежедневный подсчет наличия клеток на конкретном месте; поддержка 8 видов потоков, интеграция с 3 финансовыми системами. И простая задача – сдать проект генерации счетов через 2 месяца, что допускало только один прогон на реальных данных для проверки правильности наших расчетов.

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

• В чем ценность диагностики бизнес-процессов?
• Как «Управленческий баланс» и «Отчет о прибылях и убытках» могут диагностировать процессы компании?
• Почему онлайн, и что это означает практически?
• Почему нельзя использовать бухгалтерские отчеты?
• Как сформировать структуру финансовых отчетов не имея финансовых знаний?
• Как получить список непрозрачных процессов чужими руками?
• В чем универсальность подхода? Новая компетенция бизнес-аналитиков.

Добрый день.

Есть желание поделиться опытом использования Sсrum на базе Jira 6. Расскажу как настроить плагин, проведу обзор основных возможностей и покажу слайды с примерами.

Тезисно план доклада:

1. Как создать первый «дашборд»?

2. Основные параметры настройки «дашборда» (добавление цветовых индикаторов, быстрых фильтров).

3. Планирование с использованием плагина. Версии и спринты.

4. Реализация и мониторинг работ.

5. Закрытие спринта. Ретроспектива и отчеты.

Сталкивались ли вы с ситуацией, когда сотрудники заказчика старательно затягивали проект и вставляли палки в колеса? Или когда кто-то из коллег саботировал работу над задачей и игнорировал ваши замечания? Что можно сделать для решения проблемы, кроме эскалации к руководителям?

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

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

И здесь становится явным то, о чем многие начинающие практики лишь догадываются: системный, а особенно бизнес-анализ в ИТ — это не о "компьютерах", а о "людях". Аналитик, пришедший в профессию со студенческой скамьи, из области разработки или контроля качества (QA), обнаруживает, что не сможет состояться в новой для себя роли, если не станет эффективно коммуницировать с каждым, в чьих интересах или чьими силами выполняется соответствующий проект.

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

Работая с командами, часто приходится сталкиваться с  различного рода карго-суррогатами пользовательских историй, применение которых приносит ощутимый вред и продукту, и процессу разработки. Хуже всего то, что неправильное использование историй не позволяет получать те колоссальные преимущества, которые даёт этот подход. И заодно серьёзно его дискредитирует.

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

В 2013 году я рассказывал об организации, учете и совместном использовании проектной документации. В том докладе была затронута тема взаимодействия хранилища документов SharePoint с системой управления проектами Devprom.

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

Некоторые разделы доклада:

·         Адаптация жизненного цикла пожеланий и задач под потребности команды.

·         О том, как мы планируем релизы.

·         О работе с требованиями и документами.

·         О работе с тестовой документацией.

·         Полезные привычки проектной работы в Devprom (и не только).

Без нудной теории. Только практика. Кратко. Без воды. Что-то может показаться очевидным. Обсуждение по результатам доклада приветствуется.

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

Вспомним первый ЛАФ. Какие темы были в ходу? Как писать требования и что такое Use Case. Потом мы с интересом обсуждали управление изменениями и организацию работ команд аналитиков, а в прошлом году уже начали затрагивать тему Enterprise Architecture.

Хотелось бы продолжить развитие этих тем, углубившись в понятие IT-стратегии.

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

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

Юлия Фокина, Сергей Калинов

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

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

Что нужно знать и помнить, чтобы гарантированно прийти к успеху?

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

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

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

Формат выступления - блиц-доклад или круглый стол (если будет желание публики).

Возможно изменение лектора или ведение доклада с содокладчиком (ФИО укажу позже).

Рассматриваем показатели назначения к уже разработанной и эксплуатируемой системе.

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

Т.е. в соответствующих разделах ТЗ указываем - изменений не требуется (стандартной фразой).

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

Деление показателей назначения на:

- функциональные

- Технологические

- Технические

Рассматриваемые вопросы:

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

- Как эффективно оценить показатели назначения (рекомендации).

- Как не преувеличить объемы бедствия.

- Всегда ли аналитик имеет возможность оценить показатели назначения.

- Какие именно показатели назначения входят в зону ответственности аналитика.

- Какие показатели назначения не входят в зону ответственности аналитика и кто отвечает за них. 

- Где и как должны быть отражены показатели назначения.

- Место работ по показателям назначения при работах аналитиков по шаблонам проектирования. 

Презентация доклада направлена 18.06.2015 почтой.

Теория ограничений как основная схема для бизнес-анализа

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

Бизнес идея, как яйца фирмы

Собственников, которые заказывают музыку, обычно интересует не прибыльность, а стабильность и защита бизнеса. В то же время прозрачность бизнес-процессов и система показателей создает большие риски смены собственников. (В своё время для меня, как бизнес-аналитика - это было достаточно шокирующей информациоей.) Отсюда такой низкий спрос на "эффективность" и аналитику. И обычно ее заказыват, когда хотят её продать или вывести на IPO.

Главное - чтобы никто не отобрал. Эти вопросы решаются обычно силовыми методами: разведка, контразведка, экстрасенсы и юристы. Можно ли защитить бизнес по другому? Создать такою идею, которую не нужно скрывать, но скопировать сложно.

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

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

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

Последний раз я беседовал с руководителем франчайзиговой сети. (Все в курсе, что франчайзи могу клепать новые бизнесы, как автомат. Но что-то у них не получается.) Я задавал вопрос, как обычно в духе теории ограничений: "А что мешает вашему бизнесу расти? Где ограничение?" Он отвечал, что ограничение - это мозги. Не понятно конечно, что такое "мозги" и что делать с ними. Я думаю, что речь идет о способности передавать не только знания и навыки, а передвать идеи и вовлеченность. Кстати "Гарднер" и "Хьюит" утверждают, что наибольшую корреляцию из всех измерямых параметров с прибыльностью фирмы, а значит и с востребованостью всего "аналитического" что с этим связано, имеет вовлеченность руководителей компании.

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