Философия бизнес-анализа в IT-проектах, или кто такие бизнес-аналитики.

16.05.2017 97 Comments

Методология

INFOSTART EVENT EVOLUTION 2013 посвящается…

Небольшая статья о том, какие бизнес-аналитики требуются в успешных проектах.

Философия бизнес-анализа в IT-проектах, или кто такие бизнес-аналитики.

 

Кто должен заниматься бизнес-анализом в IT-проектах?  До сих пор встречается такое мнение:  если требуется создать программу для автоматизации деятельности предприятия, нужно найти программистов и рассказать им, что требуется автоматизировать. Когда-то, лет 20 назад, это могло иметь место. Но сейчас такой подход выглядит так же,  как если для создания нового космического корабля достаточно найти инженера-рационализатора. Программные продукты, как и требования бизнеса к ним, стали гораздо сложнее. Прежде, чем приступить к разработке программного продукта, необходимо выяснить реальные потребности бизнеса,  спроектировать архитектуру системы, организовать работу команды специалистов, разработать программный код, спроектировать пользовательский интерфейс, разработать сопроводительную документацию, протестировать полученный продукт… Даже если будет разработана супер-современная программа с модным интерфейсом и потрясающей производительностью, но она не будет решать задач бизнеса, то такая программа пополнит список академических разработок, которые так и не нашли своего потребителя. Почему так происходит? Потому, что бизнес-требования (или пользовательские требования) давно вышли на первый план. Хороших программистов сейчас гораздо больше, чем удачных программ. Тому есть ряд причин, но самая главная – это непонимание реальных ожиданий потенциальных пользователей системы. И тут на первый план выходят люди, именуемые бизнес-аналитиками.   Их задачей является понять, что хотят заказчики, как должна выглядеть система, как должна себя вести, как донести все эти требования непосредственно до разработчиков и т.д.   Хорошая работа бизнес-аналитика это 80% успеха. Соответственно, аналитик является ключевой фигурой в ИТ-проекте. Беда в том, что хорошие бизнес-аналитики встречаются не так часто. Я бы даже сказал, крайне редко.

Следует иметь ввиду, что бизнес анализ в ИТ-проектах и, например,  в классическом консалтинге, это несколько разные направления, иногда пересекающиеся по используемым приемам и образу мышления. Но мы будем говорить в первую очередь о бизнес-анализе в ИТ-проектах. В литературе встречаются разные классификации аналитиков, из которых обычно выделяются 3: Бизнес-аналитики, системные аналитики  и ИТ-аналитики (аналитики требований). Чем они отличаются, не сложно найти в интернете. Я предпочитаю не усложнять и в ИТ-проектах аналитика называть именно бизнес-аналитиком, как наиболее соответствующую действительности классификацию. Если  говорить о границе между бизнес-аналитиком и системным аналитиком, она действительно может существовать в сложных проектах, когда требуются глубокие технические знания аппаратного обеспечения, протоколов передачи данных, особенностях функционирования серверов на конкретных платформах и пр. Но, на практике, таких специалистов далеко не всегда вообще называют аналитиками. Другими словами, системный аналитик ближе к архитектору.  И эта граница может существенно плавать, в зависимости от квалификации конкретных привлеченных специалистов. Возможно, в очень  крупных западных системах такое разграничение необходимо и оправдано. А аналитики требований, на мой взгляд, вообще частный случай бизнес-анализа.  Конечно, существует и совершенно самостоятельная область бизнес-анализа, основанная на математических методах анализа статистически накопленной информации, но это совсем другое направление (в том числе с другими навыками и особенностями личности).  На этом отступление в сторону классификации заканчиваю, поскольку статья не об этом, а о бизнес-анализе в ИТ-проектах.

Рождаются ли аналитиками? Наверное, при рождении все мы аналитики. Когда ребенок впервые видит окружающий мир, новые предметы, он пытается их исследовать: потрогать, попробовать на вкус, покрутить в руках, бросить, разобратьJ.  Потом человек учится ходить, начинает бегать. Если начать развивать такую врожденную способность, как бегать, можно стать спортсменом. Или не стать. Подобным образом развиваются и аналитические способности. Для этого требуются определенные знания, навыки, практика, упорство.  Поэтому, далеко не каждый взрослый человек является аналитиком на уровне, достаточном для бизнес-анализа.

В переводе с греческого языка, аналитика – «искусство анализа». Определение, данное Аристотелем технике логического анализа. Таким образом, чтобы мыслить аналитически, надо быть немного философом. Смотреть на мир не так, как все. Уметь смотреть на проблему с разных углов, сверху, снизу и сбоку.  Уметь слышать различные точки зрения. Уметь сдерживать эмоции. Забыть утверждение «я всегда прав». Уметь доказывать свою позицию аргументированно и на фактах, а когда нет фактов уметь подключить свою интуицию, основанную на багаже успешных проектов прошлого (как своих, так и чужих). Уметь быстро признавать правильную точку зрения,  независимо от ее авторства. Уметь отделять зерна от плевел. Когда у остальных уже опустились руки, найти слова, чтобы люди вновь поверили в успех. Уметь трансформировать себя в образ собеседника и взглянуть на свои идеи  с другой стороны.  Уметь расставлять приоритеты в беспорядочной массе полученной информации (потоке сознания группы людей). Уметь укрупнить там, где нужно и ровно на столько, на сколько полезно. И одновременно разложить до молекул, если потребуется. Уметь говорить с представителями бизнеса на языке этого бизнеса и одновременно с командой разработки на языке этой команды.   

Не много ли? Так ведь это далеко не все! Кроме замечательных вышеперечисленных качеств, он должен быть еще и грамотным (в смысле языка), уметь системно излагать свои мысли, владеть инструментами для оформления своих мыслей (например, соответствующими программными продуктами), разбираться (или очень быстро учиться) в различных предметных областях (например, отраслях деятельности), разбираться во внедряемом программном продукте (если речь идет об автоматизации), обладать развитыми коммуникативными навыками и уметь расположить к себе собеседника, владеть техникой переговоров и обладать стрессоустойчивостью.  Ну вот… Этого набора, пожалуй, хватит для вполне приличного аналитика. Если Вы не готовы освоить 80% перечисленных способностей, лучше и не начинайте, а то пополните армию  клоунов, именуемых себя аналитиками.

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

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

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

  1. Аналитик имеет возможности не только понимать ожидания Заказчика, но и формировать их. Если аналитик обладает достаточной квалификацией, чтобы оперативно понимать сложность конкретных требований заказчика, он имеет шансы своевременно направить заказчика на более рациональный (менее затратный) путь. В противном случае он может  подписаться под мелкую с точки зрения ценности для заказчика «хотелку», но которая съест серьёзную долю ресурсов проекта. И наоборот, не предложит полезную для заказчика функцию (которой тот будет реально рад), если не будет понимать, что для бюджета проекта это практически ничего не стоит. А такие мелкие полезности создают очень хороший  эмоциональный фон.       
  2. Время, затрачиваемое на коммуникации между аналитиком и разработчиками существенно меньше. Такой аналитик ставит более конкретные задачи
  3. Если речь идет об адаптации существующей системы, аналитик не станет планировать доработку системы, если аналогичного результата можно добиться грамотным использованием существующей. Такое примеры встречаются очень часто.

 

Как стать хорошим бизнес-аналитиком

 

Шаг первый: прочитать предыдущий раздел и подумать: «правильную ли профессию Вы себе выбрали?» Если да, значит не остается другого выбора, кроме как перейти к шагу 2 и начать развивать необходимые навыки. Давайте попробуем составить программу обучения хорошего бизнес-аналитика.


  1. 1.      Личная эффективность и коммуникации

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

1.2.   Освойте основы тайм-менеджмента. Научитесь есть слонов и лягушек (если кто не понял – наберите в Яндексе «Как съесть слона» или «как съесть лягушку», узнаете много интересного). Вам всегда будет не хватать времени. Из литературы можно посоветовать Глеба Архангельского (у него просто компактно собрано то, что встречается в большом количестве переводной литературы по тайм-менеджменту).

1.3.   Освойте навыки написания деловых писем.  Следует обратить внимание как на стиль изложения информации с точки зрения вежливости, так и на структуру. Надо уметь эффективно переписываться не только при помощи официальных писем, но и посредством электронной почты (должны быть простые и понятные сообщения).  

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

1.5.   Изучите правила проведения собраний и рабочих встреч. Можно найти в интернете, посетить курсы или прочесть в книжке — ничего сложного тут нет (в теории). На практике можно столкнуться с трудностями, когда люди начинают кричать, хаотично спорить и пр. Результат от такой встречи будет, как говорится, желать лучшего. Нужно научиться проводить встречи организованно и эффективно. Анализируйте результаты, записывайте свои ошибки, делайте выводы каждый раз, когда считаете встречу недостаточно результативной.

1.6.   Вырабатывайте способность к стрессоустойчивости. Мне не раз приходилось видеть слезы на глазах аналитиков, слушать, какие гады работают у Заказчика и пр. Люди бывают разные, и аналитику неизбежно придется столкнуться со сложными типами личности, с которыми трудно договариваться, настроить на конструктивную работу. Поэтому, нужно быть еще и немного  психологом. Ни в коем случае нельзя подменять стрессоустойчивость безразличным отношением к работе! Это совсем разные вещи. 

2.      Знания и навыки

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

2.2.   Подберите себе какой-нибудь инструмент для наглядного представления информации (в смысле программу). В простейшем случае это может быть и обыкновенный MS Office. (Visio решает  множество задач по наглядному представлению информации)

2.3.   Необходимо понимать архитектуру программного продукта. Еще лучше, если аналитик обладает навыками разработки. Чаще общайтесь с программистами. Посетите курсы для разработчиков, хотя бы основы. Это обязательно даст результат. Или, как вариант, попросите разработчиков организовать для Вас внутренние курсы по архитектуре внедряемой системы.

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

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


3.      Опыт

3.1.   Вы знаете хорошего аналитика из своего окружения  (коллегу, например)?  Если да, проситесь стажером к нему на проект. Отбросьте амбиции. Наблюдайте. Слушайте. Учитесь. Делайте выводы. Это будет отличным стартом.

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

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

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

3.5.   Старайтесь набраться столько опыта, чтобы Вы смогли на 2 шага вперед предугадать то, что захочет клиент.  Это не просто. Существует такое понятие, как неявные требования (или, как их иногда называют «недосказанные», «очевидные», «подразумеваемые», что с точки зрения требований синонимы). В реальности  пренебрежение такими требованиями может вызвать немало вопросов и даже конфликтов. Например, для клиента может быть очевидно, для учета денежных сумм в программе должно быть предусмотрено 20 знаков (у него в существующих программах сейчас так и всегда так было), а во внедряемой системе, к примеру 15. Конечно, обычно это не сложно доработать, но потребует времени. Где-то число не вместится  на форме, где-то придется расширять макеты в печатных формах и пр. Для работы с неявными требованиями удобно использовать контрольные списки («чек-листы»). Содержание таких списков зависит от опыта конкретного консультанта в своей области.  

3.6.   Научитесь излагать свои мысли четко и лаконично. В этом поможет только практика и изучение материалов других аналитиков.


4.      Обучение и перспектива

4.1.   Правильно выбирайте место работы. Если есть ощущение, что на существующем месте работы нет шансов стать толковым аналитиком, хорошо подумайте о смене работы. Хорошие аналитики всегда нужны.

4.2.   Отраслевые знания. В каждом проекте старайтесь изучать отраслевые особенности нового бизнеса. Сделал и забыл – это про другую профессию. Аналитику нужен накапливаемый опыт.

4.3.   Непрерывное обучение. Старайтесь читать книги по бизнес-анализу. Или хотя бы статьи. Если Вы планируете пойти и поучиться на курсах аналитиков, это хорошо. Но рассчитывать, что после таких курсов (и даже после института), человек станет аналитиком, не стоит. Только практический опыт даст реальный результат.

 

Практические рекомендации для улучшения эффективности  извлечения  и анализа информации

 

Для эффективной работы стоит продумать ряд организационных вопросов:

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

2.      Как  фиксировать полученную информацию?  Записывать полученную информацию необходимо в обязательном порядке. Если просто слушать и ничего не записывать, Вы рискуете произвести плохое впечатление. Да и не запомните всего. В простейшем случае можно записывать ручкой на бумаге. Некоторые предпочитают вести запись на компьютере (но я не сторонник такого подхода). Удобно, если Вы узаконите использование диктофона. Тогда ничего не потеряется. Правда, придется тратить время на прослушивание, но если грамотно строить речь исходя из того, что ведётся аудиозапись, то эффективность получится отличная. Есть простые правила для улучшения восприятия аудиозаписи. Когда идет длительное обсуждение или дискуссия, надо всегда подводить итог и  проговаривать то, как Вы поняли услышанное и какие выводы сделаны. Если что-то показывают на компьютере, надо вставлять «голосовые комментарии» —  проговаривать то, что происходит. Когда Вы будете документировать результат и одновременно прослушивать аудиозапись, потерянного времени практически не  будет. А когда научитесь использовать технику аудиозаписи, то достоинства с лихвой перекроют недостатки. Как показывает практика, аудиозапись приходится слушать один или 2 раза параллельно документированию. Отсюда, кстати, можно сделать вывод, что на документирование результата встречи уходит в 1,5-2 раза больше времени, чем на саму встречу (под документированием в данном случае имеется ввиду подробное описание, включая графическую визуализацию процессов при необходимости). Результат договоренностей надо обязательно фиксировать в письменном виде. Хорошей практикой является использование протоколов рабочих встреч. Подготовьте для себя шаблон протокола, где будет информация об участниках встречи, времени, повестке вопросов и результатах.

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


  1. Договаривайтесь и встрече всегда заранее, планируйте достаточное количество времени (обычно 2-3 часа).
  2. Если Вам уже известно что-то о деятельности сотрудника (службы) в качестве начала беседы можно использовать краткое резюме из известной информации примерно на 1-2 минуты. Так и скажите: «По имеющейся у меня информации, Вы занимаетесь … и т.д.», после чего сообщите, что хотите поговорить об этом подробнее
  3.  Может так случиться (точно случитсяJ), что сотрудник начнет рассказывать какие-нибудь тонкости технологии своей работы, которые, по мнению аналитика, не имеют значения на данном этапе работ, или вообще имеют слабое отношение к текущему проекту. А сотрудник может рассказывать об этом долго и увлеченно. Что делать, прерывать или нет? Некоторые специалисты советуют не прерывать ни в коем случае, иначе сотрудник обидится, замкнется и.пр. С другой стороны, если Вы будете его слушать бесконечно, то не переслушаете, а времени потратите много.  Есть разные способы направления диалога в нужное русло. Например, можно  сказать, что «описываемый вопрос очень важен и интересен, но для этого лучше организовать отдельную встречу, а сегодня лучше поговорить о…». Можно дать возможность сотруднику порассуждать над волнующей его темой (если она явно не относится к теме встречи), но заранее определить себе время, которое мы можем на это потратить. Например, если 5 минут не имеют особого значения, пусть выскажется, после чего необходимо скорректировать направление диалога наводящим вопросом.  Кстати, анкеты хорошо помогают держать диалог в конструктивных рамках. Если сотрудник явно начинает уходить в сторону, а в анкете об этом ни слова, можно так и спросить, почему он никак не упомянул об этом в анкете? Если скажет, что забыл, можно просто попросить письменно сформулировать свои мысли и продолжить дальше. Возможно, он скажет, что вопрос имеет низкий приоритет важности и он не стал о нем писать в анкете. Тогда можно предложить перейти к более важным вопросам, а к этому вернуться, если останется время. Не забывайте, что людям свойственно дольше говорить о том, что они лучше знают, а не о том, что от них хотят услышать.
  4. Если возникают вопросы по ходу изложения информации интервьюируемым сотрудником, не всегда следует задавать их сразу. Лучше фиксировать свои вопросы по ходу беседы, а задать их, когда человек закончит мысль. Задавать их сразу следует только тогда, когда они будут уместны в поддержании техники активного слушания. В дискуссии на данном этапе точно вступать не следует.
  5. Обычно в опросах участвует один аналитик. Но, бывает, что опрос провидится и в паре (например, аналитик и стажер, или аналитик и руководитель проекта). В этом случае нужно договориться о порядке задавания вопросов, чтобы не перебивали друг друга, а опрашиваемый сотрудник не чувствовал себя как на допросе. Например, задает вопрос всегда один человек, а когда он получит ответ, спрашивает у второго, есть ли у него еще вопросы на данную тему. Затем перешли к следующей теме и т.д.
  6. Как и в любых переговорах, проговаривайте сами ключевые моменты и получайте подтверждение того, что вы поняли все правильно
  7. Глупых вопросов бывает очень мало. Если есть хоть малейшее сомнение, но вопрос Вам кажется глупым – забудьте об этом. Лучше возьмите и спросите. Даже очевидные вещи бывают неочевидными.
  8. Если опыт позволяет, можно не только задавать вопросы, но и предлагать свои решения. С этим методом нужно быть аккуратнее, т.к. можно сбить с настроя опрашиваемого.  

4.      Как бороться с внутренним сопротивлением при опросе.  Опрос- это по сути первый визуальный контакт консультанта с персоналом. И не все отреагируют на него одинаково. Обязательно найдутся те, кто будет в силу разных причин не заинтересован в том, чтобы кто-то погружался в особенности его деятельности. И Начинающие аналитики даже  не представляют, какие экзотические причины встречаются на практике, что вводит их в депрессию вплоть до увольнения. Как с ними бороться? Лучше всего, постараться найти подход. Если не удается, то самым эффективным способом является углубленная формализация отношений на вверенном такому сотруднику участке. Доводите до руководства, что данный участок деятельности будет вынесен за рамки проекта. Или добивайтесь письменного подтверждения того, что на данном участке будет применяться полностью типовая модель учета, заложенная в программном продукте. Как привило, у руководства не останется выбора, кроме как жестко надавить на такого сотрудника. Но, главное, что бороться с ним Вы будете не за счёт  своих нервов. В большинстве случаев, сопротивление обусловлено тем, что сотрудник занимается не очень нужной работой, или никто вообще не понимает, чем он занимается. Если работа не пыльная и не суетливая, то вполне естественно, что ему ничего не хочется менять, иначе он бы уже ушел на другую работу.  Если ситуация совсем плохая, можно разработать тактику вывода такого сотрудника из проекта. Обычно это заканчивается его увольнением. На практике мне приходилось заниматься довольно жестким прессингом таких сотрудников, но после их ухода проект начинал оживать. Если с подобной ситуацией просто мириться из состояния «клиент всегда прав», проект может зайти в тупик или перейти в разряд глубоко убыточных. Надо четко понимать, что инициаторы проекта подобными лицами не могут быть по определению. Если Вам так кажется, скорее всего, их просто не услышали и проект идет не в том (которое они ожидали) направлении.

 

5. Что делать с вопросами конфиденциальности? Чтобы не возникало вопросов типа «это нам нельзя говорить», «это конфиденциально» и т.п., проговорите заранее, как будет решаться вопрос конфиденциальности. Заключите соглашение о конфиденциальности, если это поможет.

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

7. Непрерывный анализ информации. Даже если Вам говорят много и долго, не вся информация может оказаться полезной. И не вся информация представлена системно. Это и есть работа аналитика – анализировать информацию, а не быть стенографистом, что часто случается среди начинающих аналитиков: «Было заслушано мнение Сергея Петровича по вопросу ввода в программу информации о новом товаре. Сергей Петрович считает, что сначала надо вводить …» — ну что за бред? Хотя взято из реального протокола. Не надо воды в протоколах – только принятые решения.


8.      Техники задавания наводящих вопросов.

  • — Если Вы не уверены, что описываемый процесс выглядит именно так, попробуйте позадавать сценарные вопросы вида «А что, если …»
  •  — Вспомните аналогичный проект и какие трудности в нем возникли. Позадавайте вопросы вокруг причин этих трудностей. Если у Вас не было похожего проекта, спросите у коллег
  • — Изучайте отрасль клиента и не стесняйтесь задавать ему вопросы об отрасли. Рассказывая об отрасли в целом, он обязательно начнет оговариваться в стиле «вот у нас это делается так-то…», что позволит получить дополнительную информацию или поможет сформулировать правильные вопросы.

9. Используйте и развивайте технику активного слушания. Обычно говорят необходимо «Слушать и слышать», подразумевая под термином «слышать» способность понимать то, что хочет сказать собеседник, а не то, что хочется услышать вопрошающему. Еще лучше, если слушать активно, проявляя живой интерес к беседе, но не перебивая. Хотя бы просто кивая головой J

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

  • -Старайтесь формулировать свои мысли лаконично. Это не всегда получается, иногда требуется предоставить вводную информацию, чтобы погрузить человека в тему и настроить на диалог.   Но, в любом случае, надо стараться избегать слов-паразитов, как и просто ненужных слов.
  • -Если можно что-либо сказать проще, говорите проще. Как говорил Лев Толстой: «Все люди, занятые истинно важным делом, всегда просты, потому что не имеют времени придумывать лишнее». Но не стоит забывать и о том, что сказал Эйнштейн: «Сделай так просто, как возможно, но не проще этого».
  • — Если Вы владеете множеством технических или сложных отраслевых терминов – это хорошо. Но не нужно это демонстрировать лишний раз. Особенно, если не все из аудитории владеют подобными терминами на аналогичном уровне. Используйте понятные слова. Замените непонятные на синонимы.  Старайтесь, чтобы Вас понимали, а не просто соглашались из-за того, не понимают Ваших умных фраз. Иногда так случается, что люди стесняются показать свою более низкую компетенцию, и просто соглашаются. Но это не принесет Вам никакой пользы – лишь отсрочит решение проблемы, т.к. ко всему непонятному неизбежно придется вернуться.

 

 

Типичные ошибки аналитиков, связанные с особенностями личности

 

Сначала я назвал этот раздел «Ошибки начинающих аналитиков». Но, потом, вспоминая опыт различных проектов, всплывали подобные ошибки не только у начинающих, но и достаточно квалифицированных специалистов. Все мы люди, все мы можем ошибаться. Это нормально. Но главное – это непрерывно работать над ошибками, учиться на них, и стараться не повторять в будущем. Я постарался собрать наиболее часто встречающиеся случаи. Часть их них является очевидной, и сразу бросается в глаза. Но есть и не очень очевидные проблемы, граничащие с психологией, взаимоотношениями между людьми, умением работать в команде.

  • Отсутствие пунктуальности. Понятно, что пунктуальность важна в любой работе, не только в аналитике. Но для человека, основной работой которого является регулярно с кем-то встречаться, договариваться, задавать вопросы и пр., пунктуальность становится особенно важна.
  • Внешний вид не располагает собеседника. Поскольку приходится встречаться с самыми разными людьми, надо стараться выглядеть так, чтобы располагать людей к беседе.
  • Полученная информация никак не фиксируется. В результате приходится задавать одни и те же вопросы много раз. Об этом мы уже говорили.
  • Не соблюдаются правила вежливости, как при устном общении, так и в деловой переписке.
  • Не выполнение данных обещаний или договоренностей. Не нужно давать обещаний только для того, чтобы сгладить сиюминутные эмоции. Это ухудшит ситуацию в будущем.
  • Раздача заказчику обещаний, не согласованных с руководителем проекта, а также стремление быть для  Заказчика «добрым и пушистым». Это довольно распространенное явление. Бывает, что аналитик обещает Заказчику функциональность, совершенно не думая о том, входит ли она в рамки проекта. Соответственно, Заказчик начинает ее ожидать, говорит «а нам обещали» и пр. Случается и так, что аналитик полностью прогибается под давлением Заказчика, и подписывается под все, что тот требует. Самое удивительное, что чем выше квалификация такого аналитика (который под все прогибается), тем хуже. Возникает следующее явление: аналитик прекрасно понимает, какая функциональность нужна Заказчику, что ему понравится, как это должно выглядеть и как работать. Он хорошо знает внедряемую систему и умеет ставить задачи на ее адаптацию. При  этом требует от команды идеального выполнения своих требований. Соответственно, Заказчик просто счастлив, работая с таким специалистом. Но, беда в том, что  Заказчик не думает о финансовых интересах команды Исполнителя. Как только кто-то начинает пытаться ограничивать рамки, Заказчик тут же отказывается работать с другими людьми и говорит, что будет работать только вот с этим аналитиком, так как только он его понимает и обладает достаточной квалификацией. Такой аналитик становится идеалом для Заказчика. Мне не раз приходилось сталкиваться с такой ситуацией на практике. Обычно подобный подход к работе вырабатывается у тех аналитиков, которые работают преимущественно на окладе и их финансовый интерес мало зависит от сроков достижения результатов. Они начинают страдать паталогическим перфекционизмом.  Ситуация не простая. Самый простой способ борьбы с этим явлением: прямая зависимость дохода от сроков достижения результата. Иногда это приводит к конфликтам и с аналитиком приходится расставаться, хотя он является прекрасным специалистом. Либо надо продавать свои услуги заведомо с огромной маржинальностью, закладывая риски на существенное расширение функционала. Но это сложнее, мы ведь живем в рыночных условиях.  
  • Поведение в стиле «я самый умный».  Случается, что после пары успешных проектов и человека преждевременно загорается на лбу звезда. Он перестает слушать другие мнения, учит Заказчика его же бизнесу, становится невнимателен к мелочам и особенностям конкретных компаний. Не самое страшное явление, т.к. подобную ошибку обычно он видит сам, когда возникают сложности в общении с командой, Заказчиком, или появляются проблемы в проекте из-за неудачно принятых решений.

 

Related Posts

97 Comments

  1. TODD22
    Но, на практике, таких специалистов далеко не всегда вообще называют аналитиками.

    +1 в большинстве случаев их называют «компьютерщики» 🙂

    Проект провалился? Спросите, кто на нем был ведущим аналитиком!

    И при чём тут аналитик? Проект может провалится и не только по тому что «команда» выбрала не верный путь. Есть ещё много различных рисков. Никаким образом не связанных с аналитиком.

    Если есть ощущение, что на существующем месте работы нет шансов стать толковым аналитиком, хорошо подумайте о смене работы. Хорошие аналитики всегда нужны.

    Всегда нужны хорошие «компьютерщики» что бы и 1С знал и windows и принтер мог починить, сеть сделать, сервер смонтировать, а ещё не плохо что бы знал бух учёт, налоговый учёт, МСФО, имел личный автомобиль, умел производить сварочные, электромонтажные и буровые работы, нырять с аквалангом и управлять легкомоторным самолётом. А про аналитиков в нашей деревне никто и не слышал… Может в «нерезиновске» как то по другому.

    Отраслевые знания. В каждом проекте старайтесь изучать отраслевые особенности нового бизнеса. Сделал и забыл – это про другую профессию. Аналитику нужен накапливаемый опыт.

    Не все знания одинаково полезны. Есть отрасли за которые лучше вообще не браться и не знать что там, полученные знания затем никак не монетизировать. Столкнулся с некоторыми отраслями. Знаний нужно много, в специфике разбираться приходится долго. А потом приходит понимание что никому твои знания не нужны. Вернее они нужны, но разумные деньги за это платить никто не хочет. Лучше не отраслевые знания получать а углублять знания по «общим» разделам(зарплата, налоги, бухгалтерия, МСФО, производство) то что востребовано везде. Без работы и денег точно не останешься.

    А в целом статья зачётная.

    Reply ↓
  2. valentin2019

    Полезная информацию + ∞

    Время оно! Статья отражает все существующие процессы, являющиеся фактами.

    Reply ↓
  3. ranger

    +1

    Только я бы еще посоветовал в конце указать использованные источники информации для написания статьи

    Reply ↓
  4. chavalah

    (1) TODD22,

    И при чём тут аналитик? Проект может провалится и не только по тому что «команда» выбрала не верный путь. Есть ещё много различных рисков. Никаким образом не связанных с аналитиком.

    Как причем тут аналитик? Это чисто мое мнение, но я утверждаю, что 80% причин за проваленный проект лежит в области плохой аналитики. Если на проекте грамотно управляли требованиями и ожиданиями Заказчика, то некие возникшие риски, о которых Вы говорите, причиной с вряд ли станут. А если и станут, то как раз попадут в оставшиеся 20%.

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

    Reply ↓
  5. chavalah

    (3) ranger, Статья писалась примерно так: я сел, вспомнил прошедшие проекты, и написал. Писал долго. А вообще это отрывок из неизданной пока книги, авторства моего. Ну а к самой книге список литературы будет обширный.

    Если Вас интересует литература на данную тему, могу что-нибудь посоветовать.

    Reply ↓
  6. TODD22

    (4)И всё же мне кажется что вы путаете руководителя проекта и аналитика. Аналитик должен выполнять свою часть работы и риски проекта не его головная боль. Его задача выполнять свою работу качественно и в срок. А уже провалы и риски дело руководителей проекта. А так получается что аналитик должен ещё и за риски думать и за ожидания заказчика и тд.

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

    И получился «компьютерщик», который и мышь починит и бюджетирование на предприятие поставит… и про ожидания заказчика не забудет 🙂

    Reply ↓
  7. TODD22

    (5)Вот литературу интересно было бы почитать. Приведите список пожалуйста.

    Reply ↓
  8. chavalah

    (6) TODD22, Думать, что делать с рисками, оценивать риски — это да, должен РП.

    А получать исходную информацию ему хорошо бы от аналитика. Что такое риски ИТ-проекта? если отбросить политические игры в стане Заказчика, то все остальное — это просчеты конкретных исполнителей в команде проекта.

    Я их не путаю. Просто аналитик аналитику рознь. А мне приходилось работать и тем и другим, причем несколько лет.

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

    Reply ↓
  9. chavalah

    (7) TODD22, хорошо, подберу и напишу.

    Reply ↓
  10. ranger

    (5) меня очень интересует данная тема и сама статья оказалась как нельзя кстати.Хотелось бы взглянуть как на список использованной литературы,так и на черновик книги 🙂

    Reply ↓
  11. AnryMc

    К сожалению, в наших реалиях, как правило:

    Бизнес-аналитик — это человек который «впихивает» процессы Заказчика в продаваемый продукт…

    Reply ↓
  12. AnryMc

    (6) TODD22,

    Полностью согласен:

    Бизнес-аналитик и руководитель проекта имеют совершенно разные обязанности и сферы ответственности…

    Reply ↓
  13. AnryMc

    Кстати если обратить внимание на аватары то можно точно сказать «кто есть аналитик»

    Reply ↓
  14. Новиков

    Просмотрел всего Гандапаса.

    Прослушал всего Архангельского.

    Прошел тренинг по навыкам написания деловых e-mail.

    Прошел курс по работе с возражениями.

    Прочитал всего Дейла Карнеги.

    Чтобы все это осознать/переварить и хоть КАК-ТО начать применять в жизни (рядового разработчика) потребовалось 2,5 года. Если рассматривать ситуацию как было «ДО» и как стало «ПОСЛЕ», то субъективно стало намного проще и эффективнее делать и свою работу и общаться с армией заказчиков/подрядчиков/руководителей/исполнителей.

    Больше всего понравился Карнеги и Гандапас. Гандапас, вообще очень харизматечный тренер. Смотреть его тренинги — одно удовольствие!

    Reply ↓
  15. chavalah

    (14) Новиков, Да, так и есть, 2,5 года это нормальный срок. Я бы даже сказал, что это небольшой срок.

    А вот интересно, у кого как сложилась статистика в плане пол/возраст хороших аналитиков? Мне вот, например, толковые аналитики попадались чаще девушки 25-30 лет или мужики за 45. Хотя были и исключения из этой статистики.

    Reply ↓
  16. chavalah
    К сожалению, в наших реалиях, как правило:

    Бизнес-аналитик — это человек который «впихивает» процессы Заказчика в продаваемый продукт…

    (11) AnryMc,

    Да, есть такая проблема. Но часто это и ставится задачей — максимально использовать типовой продукт. Здесь надо уметь почувствовать ту грань, когда от типового надо переходить к адаптации.

    Reply ↓
  17. chavalah

    (10) ranger,

    Хотелось бы взглянуть как на список использованной литературы,так и на черновик книги 🙂

    Дело в том, что черновик сейчас «совсем черновик», так что смотреть на него не надо:)). Если есть конкретные вопросы — задавайте, постараюсь ответить.

    А список сделаю.

    Reply ↓
  18. jig

    Грамотно все написано. Спасибо за публикацию.

    Reply ↓
  19. TSSV

    Статья супер! Все в точку! Пишите книгу! Спасибо!

    Reply ↓
  20. Medvedik

    Спасибо, актуальная статья.

    Будучи РП, очень не хватает толкового аналитика, придется растить такого в себе.

    Reply ↓
  21. tango

    (4)

    я утверждаю, что 80% причин за проваленный проект лежит в области плохой аналитики

    ерунда

    смотрите, здесь гораздо реальнее:

    http://forum.infostart.ru/forum24/topic81601/

    Reply ↓
  22. chavalah

    (21) tango,

    ерунда

    смотрите, здесь гораздо реальнее:

    http://forum.infostart.ru/forum24/topic81601/

    А что там реальнее то?

    Урок 1. Ответственность за реализацию проекта лежит только на руководителе проекта со стороны заказчика.

    —

    Руководитель проекта со стороны исполнителя, конечно, тоже должен присутствовать, но нужно осознавать, что у этого человека достаточно простые цели – подписать акты и получить деньги.

    С таким подходом у Вас и следующий проект будет не лучше…

    Урок 2:

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

    А как же быть тому, кому придется спасать проект, или кто этим и так занимается? Просто надо сначала посмотреть на ситуацию, выяснить причины, почему так получилось (если есть проблемы), какие ожидания Заказчика не оправдываются и т.д. А это и есть аналитика.

    Теперь если меня совсем прижмет, я могу работать до 16 часов в день, соответственно умножаем на 2. Получается уже неплохой объём ресурсов, вряд ли на данный проект выделяли намного больше.

    Планировать себе переработку в 2 раза и считать это нормой не есть хорошо. Нужно учиться работать в команде.

    Урок 4.

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

    А это что, не проблема аналитики???

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

    А в целом статья та интересная получилась. И автор искренне так рассуждает. Но описываемые проблемы — это следствие малого опыта. Многие через подобное проходили. И я проходил. Первый проект, за который мне пришлось взяться в 1С, был на УПП, в 2005 году. А я это УПП тогда первый раз и увидел. Описание читал по книжке, которую взял у клиента из коробки, которую тот купил. Причем читал прямо на территории Заказчика, в паузах между диалогами со специалистами. Была середина декабря, а с Нового года надо было внедрять бух учет. Производство, примерно 1000 сотрудников. Куча переносов из разных баз, старых 1С 7.7. и самописных программ. Но нам повезло: собралась команда настоящих профессионалов (5 человек), любящих свое дело. Да, были некоторые проблемы со сроками, работали от рассвета до заката (первое время). Но мы все сделали! И сделали успешно. И до сих пор та компания-франчайзи работает с этим клиентом.

    Reply ↓
  23. chavalah

    (19),(18) Спасибо! Надеюсь, что к лету управлюсь.

    Reply ↓
  24. Гость

    (23) судя по этой публикации книга должна получиться очень стоящая. Хорошо бы увидеть здесь новость о выходе книги. Распространять планируете в бумажном виде?

    Reply ↓
  25. Gilev.Vyacheslav

    (4) топикстартеру:

    — В чем разница между методологом (читай бизнес-аналитиком) и террористом?

    — С террористом можно вести переговоры.

    🙂

    Reply ↓
  26. Ish_2

    (0) Вначале статьи поставлен вопрос :

    Кто должен заниматься бизнес-анализом в IT-проектах?

    Далее неспешные размышлизмы , дескать , бизнес-аналитика — дело непростое.

    Затем предложения «как оно должно быть у людей».

    Ничего не упустил ?

    Для кого статья -то ? Для внедренцев ? .. Так чего тогда «кашу развозить» ?

    Первоначальный вопрос —

    как должна быть распределена роль «Бизнес-аналитика» в проекте ?

    а) в каких проектах и почему эту роль можно «равномерно» распределить между участниками

    («невыделенный» бизнес-аналитик или » мы все тут аналитики!» )

    б) а в каких проектах необходим «выделенный» бизнес-аналитик . Почему ?

    Для а) и б) привести примеры.

    Следующий вопрос :

    Почему случаев а) многократно больше чем б) ?

    — Потому что внедренцы не чтят Аристотеля ?

    — Совсем не читают А.Чавалаха ?

    — Другое ?

    Ответы на эти вопросы сделали бы статью поживее, поинтереснее.

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

    Reply ↓
  27. Арчибальд

    Надо заметить, что термин «аналитик» вообще неудачен. В буквальном переводе — расчленитель. Вот цитата из реферата по философии

    …анализ – процедура мысленного (иногда и реального) расчленения изучаемого объекта на составные части, рассмотрение всех сторон и способов функционирования свойства и изучение их. Расчленение имеет целью переход от изучения целого к изучению его частей и осуществляется путем абстрагирования от связи частей друг с другом.

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

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

    Теперь цитируем статью:

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

    Проще говоря, задача бизнес-аналитика — это синтез системы.

    Далее видим

    Таким образом, чтобы мыслить аналитически, надо быть немного философом. Смотреть на мир не так, как все.

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

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

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

    Reply ↓
  28. AnryMc

    (28) Арчибальд,

    А разве понять из «хотелки» заказчика: «Я хочу, чтобы всё работало…»

    Что нужно конкретно:

    1)…, 2)… и 3)…

    Это не «расчленение»?

    Reply ↓
  29. Ish_2

    И вроде придирка в (28) к автору чистейшей воды :

    ну, называются они так — «бизнес-аналитики» ,

    что не мешает им и «синтезировать» и «анализировать».

    Ан , нет. Замах-то в заголовке какой : «Философия..» — а раз так то ,будь добр -соответствуй.

    Дай разьяснение философическое — или неча в Философию лезть..

    Reply ↓
  30. Арчибальд

    (29) AnryMc, да я ж не против расчлененки. Без нее не обойтись: разобрать, классифицировать. Но в итоге-то должна получиться система, которая не равна сумме составных частей.

    Reply ↓
  31. Арчибальд

    (30) Ish_2, это не придирка, а уместное примечание для будущей книги автора.

    Reply ↓
  32. tango

    (28) Арчибальд,

    задача бизнес-аналитика — это синтез системы.

    построение модели. задача программиста

    Reply ↓
  33. AnryMc

    О «сошлись» два седобородых моряка 😉

    Reply ↓
  34. chavalah

    (3)(7) Обещанный список литературы:

    1. Скотт Беркун — Искусство управления IT-проектами (конспект можно взять тут)

    2. Основы программной инженерии (по SWEBOK). (Доступна в переводе С.Орлика)

    3. Калянов Г.Н. Консалтинг при автоматизации предприятий (отдельные моменты)

    4. Том ДеМарко. Вальсируя с медведями (интересная книга о рисках)

    5. Дж.Ханк Рейнвотер. КАК ПАСТИ КОТОВ. Наставление для программистов, руководящих другими программистами (конспект книги)

    6. Том ДеМарко. Балдеющие от адреналина и зомбированные шаблонами. Поведение команд

    7. С. Архипенков. Руководство командой разработчиков программного обеспечения

    8. К.Демарко, Листер. Человеческий фактор. Успешные проекты и команды

    9. Марианна Броадбент . CIO – новый лидер Постановка задач и достижение целей

    10. Алан Купер. Психбольница в руках пациентов. (ну это почти классика)

    11. Терри Уайт.. Чего хочет бизнес от ИТ

    12. Алистер Коберн. Современные методы описания функциональных требований

    13. Вигерс К. Разработка требований к программному обеспечению (самая известная книга по требованиям)

    14. Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы

    15. Элизабет Халл. Разработка и управление требованиями

    16. Сьюзан Снедакер. Управление IT-проектом, или как стать полноценным CIO

    17. Йордон Эдвард. Путь камикадзе (о выживании в безнадежных проектах)

    18. Джо Мараско. ИТ-проекты фронтовые очерки.

    Reply ↓
  35. chavalah

    (24)Как говорится, «No comments»

    Reply ↓
  36. chavalah

    (25) Ну вообще планирую в издательстве издать. Времени не хватает, как обычно.

    У меня тут идея родилась — подарить 10 экземпляров первым интересующимся:))

    Reply ↓
  37. chavalah

    (27)

    Для кого статья -то ? Для внедренцев ?

    Вообще-то статья для аналитиков. Как выясняется, инфостарт на 98% ресурс чисто программерский.

    Первоначальный вопрос —

    как должна быть распределена роль «Бизнес-аналитика» в проекте ?

    а) в каких проектах и почему эту роль можно «равномерно» распределить между участниками

    («невыделенный» бизнес-аналитик или » мы все тут аналитики!» )

    б) а в каких проектах необходим «выделенный» бизнес-аналитик . Почему ?

    Для а) и б) привести примеры.

    Роль аналитика на проекте никуда распределять не нужно. Другое дело, что ее можно совмещать. Например, если проект небольшой, РП может быть и аналитиком, или вторым аналитиком (например, на отдельные участки системы)

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

    Выделенный аналитик нужен всегда. Если он не нужен на 100% загрузки (проект простой или небольшой), значит нужно выделить его соответственно на ту загрузку, которая нужна. Например, 2 раза в неделю или по какому-нибудь иному расписанию.

    Какой пример Вы хотите услышать? Из практики конкретного проекта?

    Reply ↓
  38. chavalah

    (27)

    Следующий вопрос :

    Почему случаев а) многократно больше чем б) ?

    — Потому что внедренцы не чтят Аристотеля ?

    — Совсем не читают А.Чавалаха ?

    — Другое ?

    Мне это стиль Навального напомнило:))

    В моей практике работает только один вариант: б.

    Меня читать не надо, если не интересно. Есть более известные авторы, например вот: (35)

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

    На эту тему полемизировать не буду. Если у Вас есть конкретный провальный проект — могу помочь спасти. А так просто что-то доказывать не стану.

    Reply ↓
  39. chavalah

    (32)

    (30) Ish_2, это не придирка, а уместное примечание для будущей книги автора.

    Спасибо, Арчибальд, учту! Внес корректировки в текст книги:

    «Один известный специалист по внедрению систем на платформе 1С Александр (ака Арчибальд) на форуме Инфостарт, рассуждая о философской природе анализа пишет: «Надо заметить, что термин «аналитик» вообще неудачен. В буквальном переводе — расчленитель», после чего углубляется в терминологию курса философии. Конечно, тот факт, что в ИТ-индустрии работают разносторонние личности безусловно радует. Однако, не будем впадать в крайности и отвергать термин «Аналитик» из употребления в ИТ-проекте. Что же тогда придется делать с целыми сообществами бизнес-аналитиков, например таких, как uml2.ru или analyst.by?»

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

    Reply ↓
  40. Гость

    (38)

    Вообще-то статья для аналитиков. Как выясняется, инфостарт на 98% ресурс чисто программерский.

    Ничего удивительного. Соотношение как и в жизни. Но это делает статьи по бизнес-анализу применительно к 1С еще ценнее. К тому же и среди 98% программистов хватает тех, кому это интересно.

    Reply ↓
  41. ranger

    (35)О!Спасибо.

    Еще порекомендовал бы по собственному опыту «Приключения ИТ-лидера» http://www.ozon.ru/context/detail/id/4916263/

    Reply ↓
  42. Арчибальд

    (40)

    Однако, не будем впадать в крайности и отвергать термин «Аналитик»

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

    углубляется в терминологию курса философии

    А это навет. Ни в какую терминологию я не углублялся. Только уточнил, что при всей важности анализа (с анализа и классификации начинается любое познание), без синтеза он бесплоден.

    Ну вот хоть посмотреть на фразу из статьи

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

    А архитектура — это что? Результат анализа или таки синтеза?

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

    Reply ↓
  43. tango

    +(43) Арчибальд, «неизбежность анализа при оптимизации прикладного интерфейса в семействе программ 1С:Предприятие»

    Имхо, автор путает роль аналитика с ролью архитектора системы

    Типо как березоцкий в свое время спутал себя с рол

    Reply ↓
  44. chavalah

    (44)

    автор путает роль аналитика с ролью архитектора системы

    Это с какой стороны подойти:

    В западных системах это обычно реально разные люди, но там и подход другой.

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

    А практика большинства проектов примерно такая: «аналитик» (именно в кавычках) рассказывает программисту, что хочет клиент, программист что-то делает, клиент удивляется, РП портит нервы. Нет, не знакомо? А потом еще оказывается, что принятые архитектурные решения вводит ограничения на дальнейшее развитие системы, и приходится все переделывать. Нет, не знакомо? Ну так расскажите свой опыт, чего троллить-то по форуму.

    Reply ↓
  45. Арчибальд

    (45)

    В западных системах это обычно реально разные люди, но там и подход другой.

    Дело не в западе/востоке. Просто когда система разрабатывается (или строится из модулей) архитектор необходим, а когда пиджак уже сшит — на кой нам Слава Зайцев?

    Назовите мне хоть одну компанию 1С-франчайзи в Питере, например, где в штате есть выделенный архитектор?

    Именно. Но они и не занимаются ИТ-проектами вообще. Только конкретными — тюнинг (часто нулевой) типовых конфигураций.

    Reply ↓
  46. awk

    (45) (47) Арчибальд, Как сказал Ходжа Насреддин «И ты прав… И ты прав…» Аналитик — это ключевая роль начальных этапов. Вот только зачастую у нас их игнорируют и начинают проектировать. Потом ничего не получается и приходим к… Ну тут каждый к своему…

    Reply ↓
  47. Ish_2

    (38),(39)

    Конечно, в(27) вариант б) , т.е. выделеннеый аналитик, смотрится посолиднее.

    Но мы рассмотрим более массовый случай a) — «все мы тут — аналититки».

    Воздержися от оценок «хорошо»-«плохо» и ответим на вопрос «Почему так есть?».

    В 90% случаев проект — это доработка типовой 1с- конфигурации.

    Требования к специалистам-доработчикам сформулировал Арчибвльд :

    «пиджак уже сшит — на кой нам Слава Зайцев?» .

    Попросту говоря , в нашем случае требования в «бизнес-аналитику» снижаются :

    достаточно иметь не систематические знания (читай — образование), а некий «набор компетенций».

    Отсюда следует, что функции «бизнес-аналитика» вполне могут быть распределены среди участников проекта.

    Массовость варианта а) обьясняется не всеобщей глупостью.

    Вариант а) — экономичнее. Вот и всё.

    P.S. На возражение «скупой платит дважлы» последует предложение

    «Давайте разберемся почему люди так скупы».

    Может оказаться «скупая» тактика- самая верная.

    P.S.S. Я даже считаю, что вариант а) — столбовая дорога прогресса.

    Reply ↓
  48. tango

    (50) Ish_2, ну да. стоимость проекта — в это все и упирается.

    но архитектор — не для дизайна пинжака, но

    1. гарантия, что хоть один участник знает настраиваемую конфу

    2. не появится избыточных дублей типовых объектов

    3. на появится дублей одного и того же от разных учаснегов (на некотором «проекте» (не будем показывать пальцем — они мне коньяку выкатили) из-за того, что РП имел компетенцию «аналитика», но не программиста, в РКО юзер должен был ПЯТЬ(!!!) раз указать ОДНУ И ТУ ЖЕ аналитику)

    ну, т.е. роль архитектора должна быть на любом проекте

    отдельный человечек на эту роль нужен, если РП — не программер

    оптимально — если один из кодеров хорошо знает конфу и без его согласования не будет добавлен ни один объект

    Reply ↓
  49. Ish_2

    (51)

    роль архитектора должна быть на любом проекте

    Конечно. п.1-3 кто-то должен контролировать.

    Правда , с тобой тут никто не спорит.

    Читаем у автора :

    Назовите мне хоть одну компанию 1С-франчайзи в Питере, например, где в штате есть выделенный архитектор? На практике это отдельная роль, но не отдельный человек. И в зависимости от проекта, эту роль приходится выполнять либо руководителю проекта, либо аналитику . Если квалификация последнего позволяет.Бывает, что эту роль передают опытному разработчику.

    Reply ↓
  50. tango

    (52) Ish_2, ну да, общее место. и о чем тогда (0)?

    вот еще одна такая «публикация»

    http://forum.infostart.ru/forum24/topic82942/

    Reply ↓
  51. Ish_2

    (53) Я предпочитаю вопросы автору задавать явно.

    Например :

    Александр, в Вашей книге будут упомянуты крупнейшие проекты 50-60 гг, осуществленные в СССР ?

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

    Как регламентировались отношения «Заказчик» — «Исполнитель»

    от этапа «Ниокр» до этапа «опытной эксплуатации».

    Нужны ли были тогда «Бизнес-аналитики» ?

    Reply ↓
  52. awk

    (53) tango, (54) Ish_2, Если на ролях аналитика и РП люди с мозгами, то до этапа проектирования (где появляется роль архитектора) доходит только 10% проектов. 90% либо закрываются как нерентабельные(нечего проектировать), либо покупаются коробки(архитектура предопределена).

    Reply ↓
  53. Арчибальд
    Reply ↓
  54. tango

    (55) awk, ну да. фишка в том, что в этих 90 никто не платит за мозги рп-аналитика, поэтому начинаются внедрения-таки

    вот свежий пример

    http://forum.infostart.ru/forum26/topic82990/

    Reply ↓
  55. Ish_2

    Вероятно в (56) , ты хотел сказать много чего разного и много чего интересного.

    Хм.. А получилась пурга какая-то.

    Reply ↓
  56. tango

    (58) Ish_2, да нормально сказал: там, где awk зарубил 90% проектов, Арчи сохранил светлое интим-ностальжи

    **

    заметь, дирректрисса ему до сих пор платит «большую» зарплату

    Reply ↓
  57. awk

    (58) Ish_2, Мысль, в том, что подход правильный — стоит БООЛЬШИХ денег.

    Системный аналитик — он должен работать на проект или на руководителя проекта? Ведь эти цели во многом противоположны.

    (56) Арчибальд, Если убрать откатинг, то РП, аналитик, тестировщик — это роли заказчика. В противовес ролям архитектор, программист, внедренец — роли исполнителей. Но уже второй проект подряд я вижу, что РП отдельно, заказчик отдельно, но все работают на РП. Заказчик матерится, но сменить РП не решается, так как понимает, что это грозит возвратом к началу проекта. ТЗ в голове РП. Я даже шутку придумал: «У нас все готово, но находится в голове РП». Закрыть проект то же не решаются т.к. деньги потрачены.

    Reply ↓
  58. Ish_2

    (59) Ты уловил , а я не заметил.

    Когда начинаешь рассказывать про то что интересно и дорого самому — получается длинно и путанно.

    Вообщем , пурга.

    Reply ↓
  59. AnryMc

    (60) awk,

    «У нас все готово, но находится в голове РП».

    Очень знакомо…

    Reply ↓
  60. Ish_2

    (60)

    «Системный аналитик — он должен работать на проект или на руководителя проекта? Ведь эти цели во многом противоположны.»

    Это вопрос романтика.

    Ответ неинтересный и неромантический :

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

    Интересно другое :

    Арчибальд до сих пор упорно задает этот вопрос.

    Reply ↓
  61. tango

    (63) Ish_2, он не определился 🙂

    Reply ↓
  62. Ish_2

    (64) Вот , представь ,Миша, — ты РП.

    Подходит к тебе бизнес-аналитик (Арчибальд) и говорит :

    Цели РП и Цели проекта могут не совпадать. Лично я полечу прямо на солнце

    буду работать на проект.

    Так выпьем же за здоровье Арчибальда.

    За крепкий клюв и широкие крылья.

    Reply ↓
  63. romansun

    (54)

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

    Показать

    ссылка

    соответвенно сама статья-плач ярославны

    Сложность ERP систем

    и весьма грамотный ответ на неё

    О стилях внедрения крупных ERP-проектов

    Reply ↓
  64. Ish_2

    (66) За ссылки спасибо.

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

    Совершенно очевидно , отношения «Заказчика» и «Исполнителей» должны были как-то регламентироваться.

    Должна была использоваться какая-то технология управления проектом.

    Судя по результатам ( первый спутник, первый космонавт и т.д) можно предположить — технология неплохая.

    Вот я и задал автору будущей книги общий вопрос :

    нынешние проектные технологии это что-то новое ?

    и второй более частный : нужны ли были в проектах 50-60гг. «бизнес-аналитики» ?

    Reply ↓
  65. romansun

    (67)

    угу, я понял

    моё обывательском мнение:

    я лично «за» за аналитика. С ним удобнее. Он разбирается в деталях предметной области. Хорошо разбирается. Ни РП, ни архитектору таких знаний в общем не надо. Разработчикам в целом — тоже не надо. Аналитик следит за документацией… И т.п.

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

    Там очень много пишется про то как мы запроектировали вот так, а потом случайно увидели как люди в реальности этим пользуются — поняли какие мы идиоты.

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

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

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

    Reply ↓
  66. tango

    (65) Ish_2, невозможно, чтобы Арчи ушел от нее. я бы трижды подумал

    Reply ↓
  67. tango

    (67) Ish_2,

    можно предположить — технология неплохая

    — Товарищ Берия, я — не виноват!

    — Канещна не винават, дарагой! Бильби винават — мибитибя расстреляли!

    Reply ↓
  68. tango

    (68) romansun,

    к разработке и глубокому внедрению ПО

    вот бы пример бы какой-нибудь

    Reply ↓
  69. Ish_2

    (68)

    «Вполне вероятно, что финансовый задел в 50-60г был колоссальным на инновационные стратегические проекты.»

    Нет. Задела после 41-45 г. не было.

    «Не справился один институт — полетели головы, сменили на другой институт. И так до положительного результата. Потом, в других похожих проектах работа шла по уж отработанной технологии.»

    Э… Ты не понял. Описанная тобой метода «смены франча» возможна при внедрении 1сУПП.

    Но это не проект 1с УПП.

    Это проект инновационный (см. свою ссылку ) создания невиданной в мире продукции.

    В котором принимали участие сотни производственных предприятий и несколько НИИ.

    Здесь расстрелы и прочие ужасы мало что дадут.

    Нужны технологии управления и превосходные управленцы.

    По — другому ничего не получится .

    Мне так кажется.

    Reply ↓
  70. smaharbA

    дейбилы -3 добавили — на то оне и дейбилф

    Reply ↓
  71. chavalah

    (47) Арчибальд,

    Именно. Но они и не занимаются ИТ-проектами вообще. Только конкретными — тюнинг (часто нулевой) типовых конфигураций.

    Почему Вы так решили? Существует много проектов, где разрабатывались системы практически с нуля. Даже если взять некоторые отраслевые конфигурации, то и там встречаются достаточно большие разработки. Мне, например, приходилось приходилось заниматься проектом по адаптации УПП под ювелирное производство. Весьма не тривиальная задача.

    Reply ↓
  72. chavalah

    (54)

    Александр, в Вашей книге будут упомянуты крупнейшие проекты 50-60 гг, осуществленные в СССР ?

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

    Думаю, что нет. А зачем? Это практическая книга о требованиях в ИТ-проектах, а не об истории и теории. Вы представляете себе ИТ-проекты в 50-х??? Я нет. Как-то сложно говорить о том, где я не был и что не видел. Хотя… Была у нас в отделе, где работал после института одна бабушка. Она практически ничего не делала, была уже на пенсии, но ее не увольняли, поскольку только она знала, как можно запустить см-1420, которая стояла на консервации (весь остальной состав уже обновился). В длину агрегат занимал около 3 метров и занимал половину нашей комнаты отдыха, из-за чего все мечтали от него избавиться. Жесткий диск на 20 Мб весил примерно 20 кг. Там хранились старые архивы работы компании за период, когда персональных компьютеров еще не было. Аппарат мог работать с перфолентой и магнитной лентой. Часть информации была на магнитной ленте. Одна бабина размером как колесо от детского велосипеда. И вот однажды, в конце 90-х, при переделе собственности… поступил запрос на информацию из архивов. 4 суток 3 инженера трудились над запуском компьютера. Множество тумблеров, кнопочек, да еще и часть плат кто-то украл из-за драгметаллла. Это был последний запуск старой доброй см-1420 после чего ее отправили на свалку (но информацию все же вытащили).

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

    А уж как было в 50-х мне неведомо, да и не очень интересно, если честно.

    Reply ↓
  73. chavalah

    (56) Спасибо за развернутое мненние. Вообще-то, в статье не идет речь об этапах проекта и вообще о проектом управлении. В ней ведь говорится лишь о том, каких аналитиков хочется видеть на проектах.

    На самом деле эта статья является одним из разделов главы, которая называется «Введение в бизнес-анализ».

    а вот что касается фразы

    Системный аналитик — он должен работать на проект или на руководителя проекта? Ведь эти цели во многом противоположны.

    прокомментирую так:

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

    Reply ↓
  74. chavalah

    (60)

    «У нас все готово, но находится в голове РП».

    — отличная фраза, надо запомнить:)

    Reply ↓
  75. PAVI

    Александр, спасибо за четкое представление нашей специальности (?!) широкой публике.

    В 2002 г. меня взяли в Рарус в качестве дешевого приложения к мужу-программисту. Через несколько месяцев зарплату подняли вдвое. А когда уезжали на малую родину, то услышала много хорошего в свой адрес. Так в моей трудовой деятельности появилась специальность «бизнес-аналитик».

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

    1.Клиенту нужно именно то, что он просит?

    2.Можно ли реализовать пожелание клиента существующими инструментами?

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

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

    5. Снова вернуться к клиенту и предложить ему возможную схему реализации его пожелания.

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

    С удовольствием буду ждать выхода Вашей книги.

    Reply ↓
  76. tango

    дошло наконец-то и до меня, спасибо (78)

    короче, как-то так

    есть такая профессия: сомелье

    «розливать по стаканам программистам вредно — они начинают сразу пить»

    что тут плохого? — они быстро напиваются (достигают цели проекта), и — самое главное — пьют, сволочи, вместе с клиентом

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

    главное, чтобы сомелье не мог пить с клиентом — это основное профессиональное требование

    но необходимо только в конторах типо рурус, где «программисты» — дешевое приложение к аналитикам

    в скобках (особенно доставляет руровская защита — стопудово задумка аналитиков)

    в принципе, разделение (труда в данном случае) — это прогресс

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

    поэтому, собственно, столько и негатива от 1снегов, поскольку 1снеги ровно в той степени аналитики и архитекторы, в какой не программисты

    Reply ↓
  77. tango

    еще один курьёз типо парадокс

    рекомые сомелье просто жизненно необходимы именно франчайзи, чтобы исключить прямой контакт 1снега с клиентом

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

    Reply ↓
  78. Ish_2

    (75) Конечно , речь шла не о бабушках и не о машине СМ 1420.

    Ирина любезно помогла мне : в (78) описан функционал одного из участников проекта (не только ИТ-проекта).

    Уверяю, работники с таким функционалом требовались не только в 50-60гг., но и 19 веке —

    при внедрении новых производственных технологий.

    Так вот.

    У Вас места для описания того «откуда есть пошел» «Бизнес-аналитик»

    и чем раньше занимался — не нашлось.Он выскакивает как «черт из табакерки»,дескать, нужен в IT-проекте.

    Зато нашлось место для сурового напоминания бизнес-аналитикам:

    «Не соблюдаются правила вежливости, как при устном общении, так и в деловой переписке.»

    Наверное , в качестве «конструктива» я должен был бы добавить нечто вроде :

    «Бизнес-аналитик должен мыть руки перед едой»

    но я попытался несколько расширить рамки статьи.

    Reply ↓
  79. PAVI

    (79) tango,

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

    Но мир бесконечен в своем многообразии…

    Reply ↓
  80. PAVI

    (81) Ish_2,

    У Вас места для описания того «откуда есть пошел» «Бизнес-аналитик»

    и чем раньше занимался — не нашлось. Он выскакивает как «черт из табакерки», дескать, нужен в IT-проекте

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

    Или просто нужен повод упрекнуть автора?!

    Reply ↓
  81. tango

    (82) PAVI, про мир — не надо, я вчера побывал на прикольном переносе, и уже начал приближение к сальвадору дали.

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

    Reply ↓
  82. tango

    (82) PAVI,

    наслаждаться впечатлением, производимым на юзверей от встречи

    гы, не сообразил, что вы не в теме.

    необходимое пояснение: дело вовсе не в роскоши человеческого общения, а опять же в презренном металле

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

    Reply ↓
  83. tango

    (83) PAVI,

    повод упрекнуть автора

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

    мы обсуждаем статью

    в статье предпринята попытка наполнить содержанием роль аналитика

    содержание это добывается аналитическим рассечением роли Исполнителя — здраво и полезно

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

    и вот тут мы с Игорем слегка тормозим.

    Игорь обратил внимание на ситуативность предложенного разделения, а я — на обусловленность бизнес-схемой самого франчайзинга

    **

    еще раз.

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

    Все аргументы за то, что эта роль должна быть отдана специальному специалисту, называемому «бизнес-аналитиком», — разговоры в пользу (или во вред) валюте бюджета проекта.

    Reply ↓
  84. Ish_2

    (83) Ирина , Вы, как обычно , не придаете значения словам…

    » Как вы лодку назовёте так она и поплывет !» — помните ?

    Так вот автор будущей книги назвал свою лодку «Философия..» ,

    а собрался плыть как «Сборник рецептов..».

    Никакими клещами не могу вырвать из автора ответ на философский вопрос :

    Почему раньше такой профессии «Бизнес-аналитик» — не было, а сейчас она появилась ? (См. пред.посты)

    P,S, Ирина, может, Вы знаете ?

    Reply ↓
  85. tango

    (87) Ish_2, Философия такая:

    Там, где экономика — суть обмен эквивалентами (не важно, определен эквивалент госпланом или рынком), функциональная единица обусловлена функцией.

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

    Reply ↓
  86. chavalah

    (78)

    Спасибо, Ирина! Ваше мнение для меня очень ценно.

    Reply ↓
  87. chavalah

    (85)

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

    в скольких компаниях- 1с франчайзи Вы работали? и везде была такая проблема?

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

    Reply ↓
  88. chavalah

    (87)

    Никакими клещами не могу вырвать из автора ответ на философский вопрос :

    Почему раньше такой профессии «Бизнес-аналитик» — не было, а сейчас она появилась ? (См. пред.посты)

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

    Reply ↓
  89. tango

    (90)

    бюджет тут не на первом месте

    ну, собственно, дискуссия окончена.

    Не ничего общего в причинах, почему программистов отделяют от клиентов с некими «прямыми расчетами», как вы выражаетесь. Глупость это, подход начала 90-х. Нет давно такой проблемы.

    про моих франчайзей я вам рассказывать не буду.

    а вы обязательно вставьте этот анализ в вашу книгу.

    Тейлор наблюдал за человеком с лопатой, … После этого, между прочим, стали делать лопаты разной формы

    Это тоже в книгу, всенепременнейше.

    Reply ↓
  90. PAVI

    (47) Арчибальд,

    Просто когда система разрабатывается (или строится из модулей) архитектор необходим, а когда пиджак уже сшит — на кой нам Слава Зайцев?

    Несколько месяцев назад приходилось принимать решение: дорабатывать у клиента самописный модуль к УПП, или «идти другим путем». Есс-но тот, кто писал, уже потерялся на просторах России, даже номер телефона сменил. А писал около года. И клиент написанным почти доволен, но на итоги не выходит.

    Вот и пришлось Славу Зайцева изображать… А у «костюмчика» проблема была не только в «пуговицах».

    Reply ↓
  91. Арчибальд

    (65) Ish_2, Ты не поверишь, два года назад примерно так и было. Я пришел к РП и сказал: проект не имеет отношения к заводу по таким-то и таким-то обстоятельствам. А когда РП меня не послушал, я отказался в проекте участвовать.

    Reply ↓
  92. Арчибальд

    (74) процитирую себя:

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

    Очень подходит ко всем проектам по адаптации УПП.

    Если «с нуля» — значит, с синтеза модели бизнеса из (как правило, обрывочных) сведений, извлеченных из руководителя бизнеса.

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

    Что произойдет, если будет синтезирована неадекватная модель, либо вместо синтеза ограничиться сложением «хотелок»? Я утверждаю, что при профессиональном руководстве проект обязательно станет провальным (хотя, возможно, заказчик этого не поймет). А вот при слабо формализованном инвест-сотрудничестве заказчика с исполнителем есть шанс, что, например, программист увидит за деревьями лес, предложит модель, ТЗ будет выброшено и дальше процесс пойдет в нужном направлении.

    Reply ↓
  93. tango

    (95) Арчибальд,

    как правило, обрывочных

    + и даже прямо ложных. спроси его потом, зачем соврал? сам не знает. привычка.

    Reply ↓
  94. romansun

    Слуште, дискуссия как-то у нас куда-то ушла ))

    Давайте актуализируем потребности, та-сказать.

    1. Насущный вопрос — почему раньше не было аналитиков, а теперь они нужны?

    Моё имхо: 1С — прикладное программирование. С выходом сурьёзных конфигураций, сурьёзных проектов и сурьёзных платформенных усложнений потребность разделить таки специалиста по платформе и специалиста-консультанта ощутила даже 1С и ввела соответствующую сертификацию.

    Собственно, всё. Раньше в нашем 1С-мире особо не требовалось — сейчас часто актуально. Поэтому и выделили бизнес-аналитиков. И не требуют от них знать управляемые блокировки, управляемые формы, балансирование, прости господи, нагрузки в кластере/кластерах, оптимизацию километровых запросов и прочие классные штуки.

    Зато просят разбираться в бух-, нал-, опер- учетах. Сдавать НДФЛ и пр. Знания конфы на уровне сертификата «спец. консультант»

    2. Насущный вопрос — архитектов vs аналитик.

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

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

    Разделение труда.

    Reply ↓
  95. PAVI

    Александр, в постах к статье «Безнадежный проект. 8 уроков палкой» уже ссылаются на Вас:

    Ускорение вхождения в тему на порядок » Никогда не было основной компетенцией бизнес-аналитика. Ни у Чавалаха в его свежей публикации, ни у кого другого. Приведи ссылку.

    Я думаю, что это тоже хорошая компетенция в нашей деятельности. А как Вы?!

    Reply ↓
  96. Арчибальд

    (98) PAVI, согласен абсолютно.

    Я, собственно считаю основным качеством аналитика не умение разбирать бизнес на бизнес-процессы, а способность быстро разобраться в бизнесе. И статьи Александра (я их не только здесь читал) могут помочь развить эту способность.

    Reply ↓
  97. Ish_2

    (94)

    Ish_2, Ты не поверишь, два года назад примерно так и было. Я пришел к РП и сказал: проект не имеет отношения к заводу по таким-то и таким-то обстоятельствам. А когда РП меня не послушал, я отказался в проекте участвовать.

    Другими словами, в проекте не стало бизнес-аналитика вольнодумца. Очевидно, пригласили другого.

    Ты подтвердил мой тезис :

    «Системный и любой другой аналитик должен работать на руководителя проекта. Точка.»

    Reply ↓

Leave a Comment

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