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

02.04.13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+157 –

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.

См. также

ИИ для аналитика 1С: как читать и править код без разработчика

Компетенции и навыки Аналитик Бесплатно (free)

Разбираем, как аналитик 1С может использовать ИИ, чтобы разобраться в чужой внешней обработке без документации, шаблонов и комментариев в коде. Показываем, как восстановить логику загрузчика и структуру входных данных, подготовить Excel-шаблоны с техническими именами полей и внести минимальные правки, не разрушив работу обработки. Объясняем, где заканчиваются возможности ИИ и требуется участие разработчика. А также рассказываем, как получать укрупненные сценарии тестирования с понятными шагами и ожидаемыми результатами, которые удобно использовать при приемке.

11.11.2026 235 0 olga_kolyukova 2

Почему тормозит 1С? Большое расследование

Компетенции и навыки Бесплатно (free)

Пока технические специалисты борются со «щупальцами спрута» – плохими запросами, некачественным кодом и покупкой нового железа, – мы предлагаем найти «голову», из-за которой проблемы с производительностью 1С возникают системно. Разбираем истинные управленческие причины падения скорости, скрытые за отсутствием сильных экспертов и привычкой команды писать код без предварительной оценки бизнес-задач. Объясняем ИТ-руководителям, PM, CTO, CIO и CDTO, как распознать эти первопричины и выстроить процессы, чтобы перестать бесконечно лечить симптомы и решить проблему на корню.

06.11.2026 884 0 Velifer 14

Карта компетенций аналитика 1С

Компетенции и навыки Аналитик Россия Бесплатно (free)

Как выстроить систему грейдов для аналитиков 1С, чтобы оценка перестала быть вкусовой. Разбираем карту компетенций, которая отвечает на три вопроса: к какому грейду отнести человека, что ему подтянуть для роста и на какой проект его можно поставить. В статье описаны лестница от младшего сотрудника до архитектора и компетенции по этапам внедрения, от пресейла до поддержки. Вместо единой шкалы у каждого критерия своя рубрика, а правило монотонности не даёт старшему грейду оказаться слабее младшего. Отдельно разобраны базовые знания по видам учета и самооценка знания продуктов 1С для стаффинга, привязанная к подтверждённому проектному опыту. В конце собраны типичные ошибки при построении карты и открытые вопросы, на которые пока нет готового ответа.

29.10.2026 267 0 EKabanova 0

5 дней на оценку гибких навыков команды

Компетенции и навыки Бесплатно (free)

Оценка гибких навыков часто оказывается долгим и дорогостоящим процессом, поэтому мы рассказываем, как выстроить ее внутри компании так, чтобы она была понятной, автоматизированной и безопасной для сотрудников. Разбираем этапы проекта: от создания модели из 20 компетенций до выбора тестов, кейсов, интервью и оценки «360 градусов» с автоматизацией в «1С:Оценке персонала». Показываем, как команда из 15 человек прошла оценку за рабочую неделю, а на подведение результатов потребовалось еще пять дней. Объясняем, как полученные данные помогли улучшить подбор, сформировать кадровый резерв, точнее планировать обучение, сократить трудозатраты руководителей и снизить текучесть.

14.10.2026 308 0 user2100930 1

Сеньор за 3 года, а не за 10. Карьерный компас для 1С-разработчика: матрица компетенций + пошаговый план прокачки

Компетенции и навыки Россия Бесплатно (free)

Пять лет я был Middle и не понимал почему. Тогда разложил карьеру 1С-разработчика на шесть грейдов и описал, что и как прокачать на каждом. От Junior до Senior — три года, не десять. Делюсь системой: матрица компетенций, шаблоны IDP, чек-листы для performance review. Проведёте самооценку — увидите, каких навыков не хватает именно вам.

16.09.2026 2924 0 aidar_safin 55

Один руководитель продуктового и технологического развития: временный компромисс или новая управленческая норма?

Компетенции и навыки Продуктовый подход Бесплатно (free)

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

24.08.2026 429 0 user1982126 0

От кризиса компетенций к новой модели развития: взгляд тимлида и HR на будущее найма и обучения

Обучение и наставничество Компетенции и навыки Подбор персонала и собеседования Бесплатно (free)

Разбираем, почему привычная модель найма перестает работать и как компаниям выстраивать развитие специалистов в условиях дефицита кадров и новых ожиданий сотрудников. Показываем, как связка HR и тимлида помогает превращать новичков без проектного опыта в самостоятельных специалистов без перегрузок и потери качества. Объясняем, как сетка грейдов, ABC-классификация задач, индивидуальные планы развития и регулярная обратная связь делают рост прозрачным, помогают вовремя выявлять зоны развития и повышают мотивацию. Материал будет полезен тимлидам, HR-специалистам и руководителям IT-направлений, которые хотят сократить текучесть, сформировать кадровый резерв и не допустить кадрового голода в ближайшие годы.

17.08.2026 626 0 user2135145 3

Чем должна отличаться оценка результативности руководителя ИТ-проекта от оценки других членов команды

Компетенции и навыки Мотивация Бесплатно (free)

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

04.08.2026 767 0 user2136222 0

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. TODD22 20 24.03.13 07:29 Сейчас в теме

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

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

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

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

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

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

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

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

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

4. chavalah 1108 24.03.13 15:17 Сейчас в теме

(1) TODD22,

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

6. TODD22 20 24.03.13 15:27 Сейчас в теме

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

8. chavalah 1108 24.03.13 15:42 Сейчас в теме

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

12. AnryMc 851 24.03.13 16:52 Сейчас в теме

(6) TODD22,

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

21. tango 553 25.03.13 15:12 Сейчас в теме

(4)

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

ерунда
смотрите, здесь гораздо реальнее:
http://forum.infostart.ru/forum24/topic81601/

22. chavalah 1108 25.03.13 19:34 Сейчас в теме

(21) tango,

ерунда
смотрите, здесь гораздо реальнее:
http://forum.infostart.ru/forum24/topic81601/

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

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

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

Урок 2:

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

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

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

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

Урок 4.

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

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

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

26. Gilev.Vyacheslav 1924 26.03.13 12:12 Сейчас в теме

(4) топикстартеру:
- В чем разница между методологом (читай бизнес-аналитиком) и террористом?
- С террористом можно вести переговоры.
:)

2. valentin2019 24.03.13 10:46 Сейчас в теме

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

3. ranger 126 24.03.13 12:29 Сейчас в теме

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

5. chavalah 1108 24.03.13 15:22 Сейчас в теме

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

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

7. TODD22 20 24.03.13 15:28 Сейчас в теме

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

9. chavalah 1108 24.03.13 15:43 Сейчас в теме

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

10. ranger 126 24.03.13 16:46 Сейчас в теме

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

17. chavalah 1108 25.03.13 08:43 Сейчас в теме

(10) ranger,

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

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

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

35. chavalah 1108 27.03.13 00:15 Сейчас в теме

(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. Джо Мараско. ИТ-проекты фронтовые очерки.

Ответить

42. ranger 126 27.03.13 06:36 Сейчас в теме

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

11. AnryMc 851 24.03.13 16:48 Сейчас в теме

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

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

16. chavalah 1108 25.03.13 08:40 Сейчас в теме

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

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

(11) AnryMc,

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

13. AnryMc 851 24.03.13 16:54 Сейчас в теме

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

14. Новиков 292 24.03.13 20:09 Сейчас в теме

Просмотрел всего Гандапаса.
Прослушал всего Архангельского.
Прошел тренинг по навыкам написания деловых e-mail.
Прошел курс по работе с возражениями.
Прочитал всего Дейла Карнеги.

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

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

15. chavalah 1108 25.03.13 08:35 Сейчас в теме

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

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

18. jig 145 25.03.13 09:47 Сейчас в теме

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

19. TSSV 1164 25.03.13 10:52 Сейчас в теме

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

23. chavalah 1108 25.03.13 19:48 Сейчас в теме

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

25. Гость 26.03.13 06:43

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

37. chavalah 1108 27.03.13 00:18 Сейчас в теме

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

20. Medvedik 25.03.13 12:57 Сейчас в теме

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

24. smaharbA 26.03.13 00:03 Сейчас в теме

нахера аналитеги вообще нужны - базары базарить и кролиководством заниматься ?
видали мы этих аналитегов еще в совдепии

36. chavalah 1108 27.03.13 00:16 Сейчас в теме

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

27. Ish_2 1117 26.03.13 13:52 Сейчас в теме

(0) Вначале статьи поставлен вопрос :
Кто должен заниматься бизнес-анализом в IT-проектах?
Далее неспешные размышлизмы , дескать , бизнес-аналитика - дело непростое.
Затем предложения "как оно должно быть у людей".
Ничего не упустил ?

Для кого статья -то ? Для внедренцев ? .. Так чего тогда "кашу развозить" ?
Первоначальный вопрос -
как должна быть распределена роль "Бизнес-аналитика" в проекте ?
а) в каких проектах и почему эту роль можно "равномерно" распределить между участниками
("невыделенный" бизнес-аналитик или " мы все тут аналитики!" )
б) а в каких проектах необходим "выделенный" бизнес-аналитик . Почему ?
Для а) и б) привести примеры.

Следующий вопрос :
Почему случаев а) многократно больше чем б) ?
- Потому что внедренцы не чтят Аристотеля ?
- Совсем не читают А.Чавалаха ?
- Другое ?

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

38. chavalah 1108 27.03.13 00:28 Сейчас в теме

(27)

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

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

Первоначальный вопрос -
как должна быть распределена роль "Бизнес-аналитика" в проекте ?
а) в каких проектах и почему эту роль можно "равномерно" распределить между участниками
("невыделенный" бизнес-аналитик или " мы все тут аналитики!" )
б) а в каких проектах необходим "выделенный" бизнес-аналитик . Почему ?
Для а) и б) привести примеры.

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

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

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

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

41. Гость 27.03.13 03:52

(38)

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

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

50. Ish_2 1117 28.03.13 11:49 Сейчас в теме

(38),(39)
Конечно, в(27) вариант б) , т.е. выделеннеый аналитик, смотрится посолиднее.
Но мы рассмотрим более массовый случай a) - "все мы тут - аналититки".
Воздержися от оценок "хорошо"-"плохо" и ответим на вопрос "Почему так есть?".

В 90% случаев проект - это доработка типовой 1с- конфигурации.
Требования к специалистам-доработчикам сформулировал Арчибвльд :
"пиджак уже сшит - на кой нам Слава Зайцев?" .
Попросту говоря , в нашем случае требования в "бизнес-аналитику" снижаются :
достаточно иметь не систематические знания (читай - образование), а некий "набор компетенций".
Отсюда следует, что функции "бизнес-аналитика" вполне могут быть распределены среди участников проекта.
Массовость варианта а) обьясняется не всеобщей глупостью.
Вариант а) - экономичнее. Вот и всё.
P.S. На возражение "скупой платит дважлы" последует предложение
"Давайте разберемся почему люди так скупы".
Может оказаться "скупая" тактика- самая верная.

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

51. tango 553 28.03.13 12:03 Сейчас в теме

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

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

52. Ish_2 1117 28.03.13 12:36 Сейчас в теме

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

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

53. tango 553 28.03.13 12:48 Сейчас в теме

(52) Ish_2, ну да, общее место. и о чем тогда (0)?
вот еще одна такая "публикация"
http://forum.infostart.ru/forum24/topic82942/

54. Ish_2 1117 28.03.13 13:33 Сейчас в теме

(53) Я предпочитаю вопросы автору задавать явно.
Например :
Александр, в Вашей книге будут упомянуты крупнейшие проекты 50-60 гг, осуществленные в СССР ?
Какие тогда применялись технологии управления проектами ?
Как регламентировались отношения "Заказчик" - "Исполнитель"
от этапа "Ниокр" до этапа "опытной эксплуатации".
Нужны ли были тогда "Бизнес-аналитики" ?

66. romansun 213 28.03.13 18:00 Сейчас в теме

(54)

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

"Рассказы конструктора"
"Ракеты и люди"
"Воспоминания главного конструктора танков"
"Записки конструктора-оружейника"
"Оружие победы"
"Путь в ракетной технике"
"Кузницы грома"
"Цель жизни"
"Как я стал инженером"
"Война и мы"

Показать

ссылка

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

и весьма грамотный ответ на неё
О стилях внедрения крупных ERP-проектов

67. Ish_2 1117 28.03.13 19:12 Сейчас в теме

(66) За ссылки спасибо.
Понимаешь, упомянутые проекты создания совершенно новых изделий ,требующие согласованной работы сотен предприятий не могли управляться абы как . Согласен ?
Совершенно очевидно , отношения "Заказчика" и "Исполнителей" должны были как-то регламентироваться.
Должна была использоваться какая-то технология управления проектом.
Судя по результатам ( первый спутник, первый космонавт и т.д) можно предположить - технология неплохая.
Вот я и задал автору будущей книги общий вопрос :
нынешние проектные технологии это что-то новое ?
и второй более частный : нужны ли были в проектах 50-60гг. "бизнес-аналитики" ?

68. romansun 213 28.03.13 20:25 Сейчас в теме

(67)

угу, я понял

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

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

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

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

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

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

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

71. tango 553 28.03.13 22:01 Сейчас в теме

(68) romansun,

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

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

72. Ish_2 1117 28.03.13 23:58 Сейчас в теме

(68)
"Вполне вероятно, что финансовый задел в 50-60г был колоссальным на инновационные стратегические проекты."
Нет. Задела после 41-45 г. не было.

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

Э... Ты не понял. Описанная тобой метода "смены франча" возможна при внедрении 1сУПП.
Но это не проект 1с УПП.
Это проект инновационный (см. свою ссылку ) создания невиданной в мире продукции.
В котором принимали участие сотни производственных предприятий и несколько НИИ.
Здесь расстрелы и прочие ужасы мало что дадут.
Нужны технологии управления и превосходные управленцы.
По - другому ничего не получится .
Мне так кажется.

70. tango 553 28.03.13 21:44 Сейчас в теме

(67) Ish_2,

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

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

75. chavalah 1108 30.03.13 22:21 Сейчас в теме

(54)

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

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

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

81. Ish_2 1117 31.03.13 11:54 Сейчас в теме

(75) Конечно , речь шла не о бабушках и не о машине СМ 1420.
Ирина любезно помогла мне : в (78) описан функционал одного из участников проекта (не только ИТ-проекта).
Уверяю, работники с таким функционалом требовались не только в 50-60гг., но и 19 веке -
при внедрении новых производственных технологий.

Так вот.
У Вас места для описания того "откуда есть пошел" "Бизнес-аналитик"
и чем раньше занимался - не нашлось.Он выскакивает как "черт из табакерки",дескать, нужен в IT-проекте.
Зато нашлось место для сурового напоминания бизнес-аналитикам:
"Не соблюдаются правила вежливости, как при устном общении, так и в деловой переписке."

Наверное , в качестве "конструктива" я должен был бы добавить нечто вроде :
"Бизнес-аналитик должен мыть руки перед едой"
но я попытался несколько расширить рамки статьи.

83. PAVI 1389 31.03.13 12:20 Сейчас в теме

(81) Ish_2,

У Вас места для описания того "откуда есть пошел" "Бизнес-аналитик"
и чем раньше занимался - не нашлось. Он выскакивает как "черт из табакерки", дескать, нужен в IT-проекте

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

86. tango 553 31.03.13 12:44 Сейчас в теме

(83) PAVI,

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

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

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

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

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

87. Ish_2 1117 31.03.13 13:01 Сейчас в теме

(83) Ирина , Вы, как обычно , не придаете значения словам...
" Как вы лодку назовёте так она и поплывет !" - помните ?
Так вот автор будущей книги назвал свою лодку "Философия.." ,
а собрался плыть как "Сборник рецептов..".

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

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

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

88. tango 553 31.03.13 13:28 Сейчас в теме

(87) Ish_2, Философия такая:
Там, где экономика - суть обмен эквивалентами (не важно, определен эквивалент госпланом или рынком), функциональная единица обусловлена функцией.
Там, где имеет место быть распределение природной ренты, внеэкономические обоснования распространяются быстрее рака.

91. chavalah 1108 31.03.13 17:01 Сейчас в теме

(87)

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

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

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

55. awk 745 28.03.13 14:33 Сейчас в теме

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

57. tango 553 28.03.13 15:24 Сейчас в теме

(55) awk, ну да. фишка в том, что в этих 90 никто не платит за мозги рп-аналитика, поэтому начинаются внедрения-таки
вот свежий пример
http://forum.infostart.ru/forum26/topic82990/

39. chavalah 1108 27.03.13 00:35 Сейчас в теме

(27)

Следующий вопрос :
Почему случаев а) многократно больше чем б) ?
- Потому что внедренцы не чтят Аристотеля ?
- Совсем не читают А.Чавалаха ?
- Другое ?

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

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

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

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

28. Арчибальд 2712 26.03.13 15:06 Сейчас в теме

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

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

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

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

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

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

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

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

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

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

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

29. AnryMc 851 26.03.13 15:40 Сейчас в теме

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

А разве понять из "хотелки" заказчика: "Я хочу, чтобы всё работало..."
Что нужно конкретно:
1)..., 2)... и 3)...

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

31. Арчибальд 2712 26.03.13 15:45 Сейчас в теме

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

30. Ish_2 1117 26.03.13 15:43 Сейчас в теме

И вроде придирка в (28) к автору чистейшей воды :
ну, называются они так - "бизнес-аналитики" ,
что не мешает им и "синтезировать" и "анализировать".

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

32. Арчибальд 2712 26.03.13 15:47 Сейчас в теме

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

40. chavalah 1108 27.03.13 00:59 Сейчас в теме

(32)

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

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

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

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

43. Арчибальд 2712 27.03.13 08:29 Сейчас в теме

(40)

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

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

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

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

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

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

44. tango 553 27.03.13 08:41 Сейчас в теме

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

Имхо, автор путает роль аналитика с ролью архитектора системы
Типо как березоцкий в свое время спутал себя с ролью презика рф

45. chavalah 1108 27.03.13 09:05 Сейчас в теме

(44)

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

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

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

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

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

46. tango 553 27.03.13 10:08 Сейчас в теме

(45) ну вот опять. несостоятельность собственной позиции прикрывается воплями "держи тролля"
вам - в компанию ред80 и маленького злобного "учителя"

47. Арчибальд 2712 27.03.13 10:50 Сейчас в теме

(45)

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

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

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

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

74. chavalah 1108 30.03.13 21:51 Сейчас в теме

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

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

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

95. Арчибальд 2712 01.04.13 14:46 Сейчас в теме

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

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

Очень подходит ко всем проектам по адаптации УПП.
Если "с нуля" - значит, с синтеза модели бизнеса из (как правило, обрывочных) сведений, извлеченных из руководителя бизнеса.
И в Вашей статье, и в 78 комментарии Ирины, да, собственно, и в моих комментариях указывется на основополагающий (начальный, первичный) этап: выяснение/формулирование чего надо заказчику. То есть синтез модели будущей системы. Реально этим занимается тот же самый бизнес-аналитик - потому-то я и сказал, что название неудачное.
Что произойдет, если будет синтезирована неадекватная модель, либо вместо синтеза ограничиться сложением "хотелок"? Я утверждаю, что при профессиональном руководстве проект обязательно станет провальным (хотя, возможно, заказчик этого не поймет). А вот при слабо формализованном инвест-сотрудничестве заказчика с исполнителем есть шанс, что, например, программист увидит за деревьями лес, предложит модель, ТЗ будет выброшено и дальше процесс пойдет в нужном направлении.

96. tango 553 01.04.13 14:52 Сейчас в теме

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

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

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

93. PAVI 1389 01.04.13 07:27 Сейчас в теме

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

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

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

49. awk 745 28.03.13 00:20 Сейчас в теме

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

56. Арчибальд 2712 28.03.13 15:19 Сейчас в теме

(49) awk, Я и не противоречу/не возражаю автору. И плюсиком отметился даже.
Мне просто вспомнился один мой проект двенадцатилетней давности. "Хотелка" была одна: автоматический рассчет себестоимости. В трех ипостасях: производственной себестоимости, полной себестоимости и реальной себестоимости (то, что сейчас называют управленческой себестоимостью). Так вот на начальном этапе аналитику вообще было нечего делать. Чтобы начать что-то анализировать (в данном случае, модель себестоимости), надо было это что-то получить/построить. Потом пошел анализ: какие бизнес-процессы должны порождать какие данные, и в какое время. Потом синтез будущих бизнес-оцессов в подсистему. Потом архитектурные изыскания: как встроить эту (будущую) подсистему в существующую систему (1С: Бух 7.7) без ущерба/разрушения последней. Наконец, реализация, опять-таки с этапами анализа и синтеза. В итоге получилость то, что потом стало называться РАУЗ, только (в отличие) с прозрачным движением первичных/вторичных затрат.
Этапы:
1. Рождение идеи (модели) - весьма интимное действо ( http://infostart.ru/public/82207/ )
2. Расчленение (анализ) модели на бизнес-процессы
3. Синтез (умозрительный) системы, реализующей модель
4. Привязка к местности (построить или пристроить)
5. Анализ теперь уже бизнес-процессов на предмет алгоритмизации/кодинга, интерфейсов и проч.(
6. Синтез программной системы (подсистемы)

Второй и, особенно, третий этапы - это идеология управления бизнесом. В подходе автора предполагается одноэсная идеология, так что третий этап становится практически незаметным, и к тому же, становится перед вторым. Вопроса из четвертого этапа не стоит - только пристроить. Пятый и шестой - за пределами рассмотрения автора. Вместо первого этапа предлагается слепить идею из хотелок. Это, на самом деле, нормально, но это все же действо синтетическое.
Автор концентрируется на втором этапе - и правильно делает, ибо львиная доля проектов становится провальными именно на этом этапе. При этом совершенно справедливо отмечается, что архитектурные навыки (этапы 3, 4) в значительной степени системному аналитику помогают.
Основная мысль, почему я в это обсуждение встрял, принадлежит Козьме Пруткову - специалист подобен флюсу, его полнота одностороння. Куда ни сунься - все твердят об исследовании бизнес-процессов, планировании и отслеживании этапов работ, документировании, протоколировании, ну и немалая роль отводится также впариванию и задоприкрывательству (ТЗ). Так вот, я утверждаю, что если все это прекрасно научно организовать - проект будет успешным для исполнителя и, весьма вероятно, провальным для заказчика - при этом, возможно, заказчик этого и не заметит. Если изначальная идея не выкристаллизовалась, исполнитель должен ее синтезировать из хотелок. Это будет цель проекта. Совпасть с истинной целью заказчика она может только случайно.
Должен ли это понимать читатель будущей книги автора? Вообще, циничность - это обязательный атрибут РП? Системный аналитик - он должен работать на проект или на руководителя проекта? Ведь эти цели во многом противоположны.

58. Ish_2 1117 28.03.13 16:01 Сейчас в теме

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

59. tango 553 28.03.13 16:07 Сейчас в теме

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

61. Ish_2 1117 28.03.13 16:20 Сейчас в теме

(59) Ты уловил , а я не заметил.
Когда начинаешь рассказывать про то что интересно и дорого самому - получается длинно и путанно.
Вообщем , пурга.

60. awk 745 28.03.13 16:18 Сейчас в теме

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

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

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

62. AnryMc 851 28.03.13 16:26 Сейчас в теме

(60) awk,

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

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

63. Ish_2 1117 28.03.13 16:41 Сейчас в теме

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

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

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

64. tango 553 28.03.13 16:43 Сейчас в теме

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

65. Ish_2 1117 28.03.13 17:16 Сейчас в теме

(64) Вот , представь ,Миша, - ты РП.
Подходит к тебе бизнес-аналитик (Арчибальд) и говорит :
Цели РП и Цели проекта могут не совпадать. Лично я ~~полечу прямо на солнце~~
буду работать на проект.
Так выпьем же за здоровье Арчибальда.
За крепкий клюв и широкие крылья.

69. tango 553 28.03.13 21:40 Сейчас в теме

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

94. Арчибальд 2712 01.04.13 13:38 Сейчас в теме

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

100. Ish_2 1117 01.04.13 18:08 Сейчас в теме

(94)

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

Другими словами, в проекте не стало бизнес-аналитика вольнодумца. Очевидно, пригласили другого.
Ты подтвердил мой тезис :
"Системный и любой другой аналитик должен работать на руководителя проекта. Точка."

77. chavalah 1108 30.03.13 22:32 Сейчас в теме

(60)

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

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

76. chavalah 1108 30.03.13 22:30 Сейчас в теме

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

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

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

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

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

33. tango 553 26.03.13 16:11 Сейчас в теме

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

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

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

34. AnryMc 851 26.03.13 16:56 Сейчас в теме

О "сошлись" два седобородых моряка ;-)

48. пользователь 27.03.13 16:35

Сообщение было скрыто модератором.

...

73. smaharbA 29.03.13 23:24 Сейчас в теме

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

78. PAVI 1389 31.03.13 07:34 Сейчас в теме

Александр, спасибо за четкое представление нашей специальности (?!) широкой публике.
В 2002 г. меня взяли в Рарус в качестве дешевого приложения к мужу-программисту. Через несколько месяцев зарплату подняли вдвое. А когда уезжали на малую родину, то услышала много хорошего в свой адрес. Так в моей трудовой деятельности появилась специальность "бизнес-аналитик".
Сейчас я четко понимаю, что отдавать пожелание клиента сразу в "голову" программиста вредно, ибо он начнет думать о его реализации. А любое пожелание должно пройти осмысление в следующих направлениях:
1.Клиенту нужно именно то, что он просит?
2.Можно ли реализовать пожелание клиента существующими инструментами?
3.Провести декомпозицию пожелания и снова провести анализ: что уже существует в конфигурации, а что придется дорабатывать.
4. Провести консультацию с архитектором системы или программистом по поводу возможности реализации задуманного. Выявить различия в желаниях клиента и возможностях системы.
5. Снова вернуться к клиенту и предложить ему возможную схему реализации его пожелания.
Для нас с мужем наиболее зримой аналогией такой работы является система горно-обогатительный комбинат и медеплавильный завод.

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

79. tango 553 31.03.13 11:15 Сейчас в теме

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

но необходимо только в конторах типо рурус, где "программисты" - дешевое приложение к аналитикам
в скобках (особенно доставляет руровская защита - стопудово задумка аналитиков)

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

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

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

82. PAVI 1389 31.03.13 12:15 Сейчас в теме

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

84. tango 553 31.03.13 12:25 Сейчас в теме

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

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

85. tango 553 31.03.13 12:29 Сейчас в теме

(82) PAVI,

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

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

90. chavalah 1108 31.03.13 16:47 Сейчас в теме

(85)

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

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

92. tango 553 31.03.13 20:03 Сейчас в теме

(90)

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

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

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

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

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

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

89. chavalah 1108 31.03.13 16:39 Сейчас в теме

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

80. tango 553 31.03.13 11:24 Сейчас в теме

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

97. romansun 213 01.04.13 15:43 Сейчас в теме

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

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

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

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

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

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

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

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

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

98. PAVI 1389 01.04.13 15:45 Сейчас в теме

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

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

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

99. Арчибальд 2712 01.04.13 15:59 Сейчас в теме

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

101. smaharbA 01.04.13 19:16 Сейчас в теме

покажите мне одного аналитика слепившего горшок ?

102. charushkin 110 02.04.13 07:26 Сейчас в теме

(0) Автор, статья, безусловно, заслуживает внимания. Но несмотря на то, что вы пишите

1.4. Необходимо быть достаточно грамотным

несколько раз встречается оборот

Мне ни раз приходилось ...

Ну почему же "ни", а не "не"?
Это настораживает ;)

103. chavalah 1108 02.04.13 08:46 Сейчас в теме

(102)Да, действительно, ошибка:), спасибо.

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

104. tango 553 02.04.13 10:23 Сейчас в теме

(103)

не претендую на абсолютное знание филологии

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

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

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

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

105. dachnik 27 02.04.13 10:47 Сейчас в теме

(104) tango, про лопаты именно так и воспринимается :). Часто и в технической документации сталкиваюсь с "высокохудожественным" изложением.

127. chavalah 1108 03.04.13 09:14 Сейчас в теме

(105)

про лопаты именно так и воспринимается :). Часто и в технической документации сталкиваюсь с "высокохудожественным" изложением.

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

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

Джеффри Креймс, Думай как Друкер, Минск, «Попурри», 2009 г., с. 127-128.

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

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

129. tango 553 03.04.13 10:29 Сейчас в теме

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

132. Ish_2 1117 03.04.13 17:26 Сейчас в теме

(127) Давайте уж разберемся "без гнева и пристрастия" с лопатами.
Свое суждение о правильности поста (104) я сделал после поверхностного прочтения цитаты из Тейлора:
"Существует лишь один правильный способ погружать лопату в вещество определенного рода - и множество неправильных. Итак, чтобы правильно набрать лопатой трудно поддающееся вещество, надо сильно прижать верхнюю часть руки к верхней части правой ноги чуть ниже бедра, взять конец лопаты в правую руку и, когда вы будете втыкать лопату в насыпанную кучу, вместо того, чтобы использовать мускульное движение рук, что утомительно, перекиньте вес вашего тела на лопату; тогда лопата вонзится в насыпанную кучу без всякого напряжения и без всякой усталости для рук"

Здесь и речи нет об изготовлении лопат. Отсюда я сделал вывод , что Tango прав :
Тейлор не являлся изобретателем новых форм лопат. Он лишь указывал "как, когда,с какой лопатой" правильно работать.

Но из цитаты :
«До Тейлора никому даже в голову не приходило систематизировать конструкцию лопат. Их форма и размер были произвольными. Тейлор установил, что идеальное количество земли для переброски с помощью лопаты составляет 9,75 килограмма, и сконструировал лопату именно такой емкости, в результате чего производительность труда землекопов значительно возросла. "
Джеффри Креймс, Думай как Друкер, Минск, «Попурри», 2009 г., с. 127-128.

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

Александр , мои извинения.

133. AlexO 136 03.04.13 17:36 Сейчас в теме

(132) Ish_2,
ну, т.е. с чужих слов про Тейлора - намного понятнее, чем сам Тейлор, особенно, если приведены прямо противоположное мнение?

Тейлор установил, что идеальное количество земли для переброски с помощью лопаты составляет 9,75 килограмма

Это для кого идеально? И где тут "изобретение" лопат? Это для всех 9,75 кг - худой, тонкий, молодой, старый?!
И, по большому счету

перекиньте вес вашего тела на лопату;

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

138. tango 553 05.04.13 16:24 Сейчас в теме

(132) Ish_2, Голосуй, а то проиграешь :)

(136) AlexO, а еще у меня есть золотая подвеска :)

106. chavalah 1108 02.04.13 10:59 Сейчас в теме

(104) когда это вам посчастливилось участвовать в моем проекте?

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

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

107. tango 553 02.04.13 11:40 Сейчас в теме

(106) Бог миловал - мне не довелось работать под вашим руководством.
Программисты вполне могли быть и довольны - известен опыт с крысой, умирающей от голода рядом с едой, но счастливой, поскольку нажимала кнопку стимулятора.

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

Напечатайте и повесьте в рамочке над копутером.

108. dachnik 27 02.04.13 14:02 Сейчас в теме

(106) не серчайте.
Люди искренне ждут появления вашей весьма полезной книги, я и tango в том числе.
Потому мы и пытаемся указать на явные недочеты в подаче материала и просим не упустить из виду многие важные моменты. Воспринимайте как полезную критику.

125. Ish_2 1117 02.04.13 20:31 Сейчас в теме

Лучший в теме пост - № (104) .
Уверен , что Tango должен получить вознаграждение от Александра .
(Ирина , можете присоединиться..)

В посте № 104 мы видим "естество и плоть" работы аналитика :
выявление и исправление смысловой ошибки в сообщении (91).

Ура ! Среди нас есть ,по крайней мере , один аналитик.

126. tango 553 02.04.13 21:46 Сейчас в теме

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

109. romansun 213 02.04.13 16:36 Сейчас в теме

Товарищи, статья "в целом". Основные, на взгляд автора, истины собраны в один материал.

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

Мне, в свою очередь, было бы как раз интересно больше углубленной инфы :)

110. tango 553 02.04.13 16:42 Сейчас в теме

(109) romansun, вот, с ходу:

бизнес-требования (или пользовательские требования)

блин - и комментировать-то не получается :)
**
ага, нашел
вот хороший камент к данному конкретному эпизоду авторского потока:

Microsoft Dynamics NAV meets your business needs. You want to focus on your business—not on your business software.

Прикрепленные файлы:

111. romansun 213 02.04.13 17:43 Сейчас в теме

(110)
ну так и чо? не понял..

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

112. tango 553 02.04.13 17:59 Сейчас в теме

(111) romansun, садитесь два
в приведенном выше каменте NAV подчеркивает как свою цель - реализация бизнес-требований, а не хотелок пользователей. автор (и вы с ним) эти понятия у себя в голове даже не разделяете. у автора - это просто синонимы,
вы - "тож считаете", что бизнес-требования - это "мысленный поток заказчика"

отнюдь.

хотелки - это по большей части просто интерфейс, по меньшей - автоматизация as is

пользовательские требования - это требования пользователей программы: операторов 1с и окончателей MBA

business needs - это даже не поток владельца. это поток бизнеса

Прикрепленные файлы:

113. romansun 213 02.04.13 18:02 Сейчас в теме

(112)

это детали и возможные проблемы терминологии, не более чем

upd. даже еще проще - это абсолютно общая фраза, ~~которая всем понятна... цепляться к ней смысла не имеет, если только это и не есть смысл~~

upd. вычеркнуто, как вызывающее подозрение :)

114. tango 553 02.04.13 18:17 Сейчас в теме

(113) romansun, ага, ага, очень мягкий намек на троллинг.
похоже на тренд - если встретилась непонятка, виноват тот, кто непонятку засветил
возможно - в этом и есть причина отставания 1с от SAPа и т.п., а вовсе не технологическая

116. romansun 213 02.04.13 18:24 Сейчас в теме

(114)

это не намек :)

ок, сейчас вычеркну фразу..

общая идея - та же:
как мне кажется - это детали и на данном уровне абстракции, так сказать, обсуждать их нет смысла

115. tango 553 02.04.13 18:22 Сейчас в теме

попробую еще раз

требование бизнеса - информационная система (информационное основное средство), способствующая выполнению миссии (ну или хотя бы повышению рентабельности)

требование пользователей - "чтобы я на этом месте быстрее и легче выполнял то, что выполняю"

так разница видней?

117. romansun 213 02.04.13 18:26 Сейчас в теме

(115)

разница понятна и ясна - но на данном уровне углубления в тему несущественна, имхо

118. tango 553 02.04.13 18:29 Сейчас в теме

(117) romansun, соглашусь в следующей формулировке: уровень статьи не способствует углублению в нее
**
читателям же рекомендую обратить внимание на авторскую ремарку в (90):

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

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

121. tango 553 02.04.13 18:43 Сейчас в теме

(117) romansun, ага, вот ответ керзону:

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

123. chavalah 1108 02.04.13 18:49 Сейчас в теме

(117) Да чего ему объяснять, это бесполезно. Спамер он и в Африке спамер.
Не хотел уже больше комментировать танго-спамера, у меня времени на это нет, работать надо, а не на форумах спамить.

У него только бюджет в голове как причина всех проблем в проектах.
И даже в голову не приходит, что софт бывает не только коммерческий.
Какие бизнес-требования преследует некоммерческий софт (именно некоммерческий в чистом виде)?
Если он будет неудобен, никто им пользоваться не станет. Вот, например, установил я недавно в телефон программу "шахматы" - легальную и бесплатную. Интерфейс удобен, играет хорошо. Пользуюсь. Какие бизнес-цели преследовали разработчики? Конечно же пользовательские требования, проводили тесты на фокус-группах и пр.

И не одним 1с-ом жив человек. В прошлом году на конференции по юзабилити 1С приводили как один из неудачных примеров пользовательских интерфесов. И 1С знает это прекрасно, и работает над этим.

124. dachnik 27 02.04.13 19:11 Сейчас в теме

(123) вообще-то танго не зря цепляется и в его словах здравое зерно.
Каким бы ни был проект, краеугольных камней всегда 3: заказчик (фактический инициатор процесса, конкретное лицо), бюджет, сроки. ИМХО

119. tango 553 02.04.13 18:39 Сейчас в теме

вот, пожалуй:

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

120. tango 553 02.04.13 18:40 Сейчас в теме

- Анализ предприятия – деятельность по идентификации потребностей бизнеса (business need) через призму целей и задач бизнеса, нацеленная на поиск решения (Solution), которое бы удовлетворило потребности бизнеса. Это и есть классический бизнес-анализ, работающий с требованиями на самых ранних стадиях их жизненного цикла.

- Сбор и выявление требований – деятельность, направленная на работу с ключевыми специалистами предприятия и предметными экспертами по выработке бизнес- и системных/функциональных требований к решению (solution), включая сбор данных по нефункциональным требованиям, ограничениям и допущениям. Используемые техники работы: мозговые штурмы, фокус-группы, прототипирование, интервью, workshops.

- Анализ требований – деятельность, направленная на анализ требований и четкое описание/специфицирование будущего решения (Solution). В сущности здесь происходит окончательная выработка системных и функциональных требований, определение объема будущих работ, приоритезация, классификация, моделирование и валидация требований.

122. tango 553 02.04.13 18:45 Сейчас в теме

все, ушел
всем успехов!

128. tango 553 03.04.13 10:19 Сейчас в теме

Рекурсия это:
Если я укажу на нарушение автором правила Самовольное модерирование. Т.е. когда некий участник форума, не являющийся модератором данного форума, делает замечания другим участникам.,
будет ли это нарушением того же правила мной?

Автору: вам бы следовало вообще грохнуть эту "публикацию", а то клиентов потеряете.

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

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

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

130. rus128 2 03.04.13 15:42 Сейчас в теме

Отличная статья!
Отдельная благодарность за рекомендации конкретных авторов для изучения дополнительной информации.
Правда, я заметил 3 небольшие опечатки, несколько снижающих ее восприятие:
1) "Договаривайтесь О встрече всегда заранее";
2) где-то видел опечатку (заметил ее по ходу чтения статьи, но теперь не могу найти это место, а полностью перечитывать ее сейчас нет возможности) - возможно, проверка орфографии в Word поможет найти ее;
3) "после пары успешных проектов У человека преждевременно загорается".
Ну и с пунктуацией я в некоторых местах не согласен (поставил бы несколько запятых в сложных предложениях).

131. AlexO 136 03.04.13 16:04 Сейчас в теме

(0) Автор, а почему у вас на сайте КИТ-проект на семинар "Семинар «Разработка требований для автоматизированных систем (Технических заданий)" идет регистрация на период 16.02.2013-18.02.2013?
А то мы все о высоком, о философии, аналитике, ответственности :)

Прикрепленные файлы:

134. PAVI 1389 03.04.13 20:30 Сейчас в теме

Контрагенты и номенклатура - это как бы наш пушкин.

Это цитата из одной статьи tango.
Вывод: легче найти соринку в чужом глазу... (далее про бревно).
Безапеляционность, всезнайство и почти бесплатно раздаваемые советы

Автору: вам бы следовало вообще грохнуть эту "публикацию",

И это мешает воспринимать те замечания, которые можно было бы принять.
Но бизнес-аналитику не привыкать "перемалывать" горы словесной шелухи в поисках реальных бизнес-требований.
Полагаю,tango искренне хочет улучшить такой бизнес-проект, как форум Инфостарт.

135. chavalah 1108 03.04.13 22:01 Сейчас в теме

(134) а его уже забанили на неделю. Я уж и не обращаю внимания.
Человек сидит на работе, ни хрена не делает, и по форумам спамит.
Я даже могу нарисовать его психологический портрет:

Возраст примерно 45-48, когда-то давно работал во 1С франчайзи. Ничего не получилось. Разочаровался.
Живет скорее всего, в большом городе, возможно в Москве. Нашел себе работу, где можно сидеть, получать вероятно хорошую зарплату (иначе бы он работал, а не на форумах сидел). Считает, что ему очень повезло с работой и он очень умный. Хотя в душе понимает, что ничего ценного пока не создал, что его расстраивает.Кем работает сложно сказать, скорее всего программистом, возможно начальником небольшого отдела (ну это странно тогда при таком неадеквате начальником его делать:)). Еще пора задуматься, что работу можно и потерять, а на другой работать придется. Проектов, которые он смог самостоятельно реализовать нет. Вот и бесится.

136. AlexO 136 04.04.13 10:42 Сейчас в теме

(135)

Возраст примерно 45-48

- он, вообще-то, почти в два раза (в полтора точно) вас старше :)

что ничего ценного пока не создал

ну да, мелочи всякие - например, книгу там по 7.7...
Но интересует меня другой вопрос.
В отличие от tango, не стесняюсь спросить, если чего-то не понимаю :)
Объясните, как разные лопаты под разные работы, обнаруженные Тейлором в ходе проекта, смогли (вдруг!) быть изготовлены в результате именно этого проекта?"

137. alpopo 05.04.13 09:51 Сейчас в теме

Добавил оформление

Прикрепленные файлы:

Философия бизнес-анализа.pdf

139. tango 553 05.04.13 16:29 Сейчас в теме

(137) alpopo, это что, еще один аккаунт автора? круто

140. devel0per 1 05.04.13 17:22 Сейчас в теме

Как должна выглядеть работа бизнес-аналитика, за которую не жалко отстегнуть 10-15% гонорара с IT проекта?
Бизнес-аналитик должен описать проблемной область "как есть" и как "должно стать".
на выходе:
1. Диаграммы бизнес сущностей
2. Диаграммы или текстовые нотации бизнес-юскейсов
В принципе, это все что требуется от бизнес-аналитика, которого нанимают в IT проект.
Почему такая работа востребована?
Программисты в состоянии самостоятельно нарисовать UML-диаграммы, расписать варианты использования,
однако, не зная и глубоко не вникая в проблемную область, не имея её достаточного описания
они могут перепутать сущности "Order", "Payment" и "Account", могут обозвать поле "Oplata",
могут завести поля Korr1, Korr2, Korr3 строкового типа для корресподнирующий счетов.
Для того чтобы таких казусов не возникало и нужны бизнес-аналитики в IT.
Психология, представительный внешний вид, переговоры - это в отдел продаж, а не IT.

141. tango 553 05.04.13 17:35 Сейчас в теме

(140) devel0per, спасибо за перевод базара в деловое русло.

1. Диаграммы - вы какую нотацию предпочитаете? А почему?
нет смысла в диаграммах при внедрении 1с, кроме одного случая - у клиента работают крутые перцы, которые тоже любят погнуть пальцы.
Но! если у местных в это время года в моде другая нотация - вы в пролете

2.

они могут перепутать сущности "Order", "Payment" и "Account", могут обозвать поле "Oplata",
могут завести поля Korr1, Korr2, Korr3 строкового типа для корреспондирующих (я правильно поправил?) счетов

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

3.

Психология, представительный внешний вид, переговоры - это в отдел продаж, а не IT.

а в описаниях бизнес-аналитика как раз и подчеркивается, что он - не ИТ
и это - так
так что - грамотная письменная и устная речь, психологическая устойчивость (хранить лицо, держать удар) и понимание основ теории бизнес-анализа (разница между между Business needs и User needs)
ну и немножко таки шарить в программировании - ровно настолько, насколько и в бизнесе - интерфейс это ведь в обе стороны, верно?

ПС: интересно было бы глянуть на образцы кода ТС

143. devel0per 1 05.04.13 18:49 Сейчас в теме

(141)
1. Мне намного удобнее работать с текстовыми нотациями, по двум причинам:
а) всегда можно сгененрировать диаграмму
б) их удобно завести в систему контроля версий и сравнивать что у нас поменялось
2. Не вижу ничего необычного или плохого в том, что программист интуитивно не понимает в чем отличие между счетом на оплату, платежкой, счетом в плане счетов, счет-фактурой и т.д. и т.п.
При грамотной документации, (которую он обязан уметь читать) в этом нет проблемы. Он должен по предоставленой ему документации - создать указанные объекты и реализовать такие-то свойства и методы.
Бизнес-аналитик должен задокументировать проблемную область и передать эстафету далее дизайнеру системы.
3. Статья, которую мы комментируем называется: "Философия бизнес-анализа в IT-проектах, или кто такие бизнес-аналитики" - просто сузил тему до своего уровня понимания.

145. AlexO 136 05.04.13 22:13 Сейчас в теме

(143) devel0per,

2. Не вижу ничего необычного или плохого в том, что программист интуитивно не понимает в чем отличие между счетом на оплату, платежкой, счетом в плане счетов, счет-фактурой и т.д. и т.п.

сами-то знаете? Или вы программист? :)

147. devel0per 1 06.04.13 00:11 Сейчас в теме

(145) AlexO, допустим знаю и что дальше? Легче вам от этого?

150. tango 553 07.04.13 12:43 Сейчас в теме

(143) devel0per,

б-р-р... мы, наверное, о каких-то разных программистах говорим.
"1снег - не программист" - знаете о таком логане среди "настоящих" программистов? а знаете - почему?
потому, что 1снег имеет дело не с ООП, а как раз со "счетом на оплату, платежкой, счетом в плане счетов, счет-фактурой и т.д. и т.п."
Если он это "интуитивно не понимает", то он ни разу не открыл конфигуратор, но почему тогда вы его назвали 1снегом?

158. devel0per 1 09.04.13 00:57 Сейчас в теме

(150) tango,

"мы, наверное, о каких-то разных программистах говорим"

О разных, конечно.

"потому, что 1снег имеет дело не с ООП, а как раз со ..."

Разве программист на C (не C++) имеет дело с ООП?
Разве кто-нибудь сомневается, что тот кто программирует на C является программистом?
От выбранной парадигмы программирования принадлежность к классу ( не по К. Марксу!) программистов совершенно не зависит.

"знаете о таком логане среди "настоящих" программистов?"

Нет, но знаю что:
Издательство 1С выпустило книжку Радченко М.Г. Е.Ю. Хрусталёва - "Практическое пособие разработчика",
в которой на стр. 14 дается разъяснение по этому вопросу:

"Программирование или разработка?
...Если ваша цель - научиться «программировать на 1 С»,
то эта цель не совсем верная. В системе 1С Предприятие 8
есть встроенный язык, но он занимает далеко не главное
место в процессе разработки."

Это позиция самой 1С, а не "логан"(?) среди "настоящих" программистов.
Идем далее, в официальном 2-ух томном издании "Руководства разработчика"
на стр. 1-29 :

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

"...почему тогда вы его назвали 1снегом?"

Где такое вы у меня прочитали? Когда я пишу про настройку конфигурации 1С, то стараюсь всегда
придерживаться рекомендованой 1С терминологии. Например: "Разработчик 1С", "Разработчик-прикладник 1С", "настройщик конфигурации", но не "1С программист" и тем более не "1снегом".

"дизайнер - это таки больше интерфейс, а тут нас 1с-платформа ставит в рамки."

Тут я виноват, надо было написать - проектировщик системы или что-то на подобие.
Дело в том, что в английском языке design - означает проектировать.
Да, не православно получилось, каюсь. В своё оправдание приведу только две ссылки:
Engineering design process
и
Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements
System designer я написал как "дизайнер системы", а надо было писать - архитектор, проектировщик, чтобы вы меня поняли.
Идем далее:

"1с-конфа, эмулирующая не-1с-базу"

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

Если СистемаНе1С.Доступность() Тогда
	РасшифроватьЧерезWEB(Объект);
Иначе
	НарисоватьСписокНакладныхПоДоговору();
КонецЕсли;

Таким образом, мы можем иметь многоуровневые
расшифровки и отсутствие лишних данных в базе 1С!

159. tango 553 09.04.13 18:10 Сейчас в теме

(158) devel0per, спасибо - серьезно - за ответ, потрачено времени много

итак, на разных языках говорили о разных прогов, ок

если мы здесь говорим о проектах-1с, то и прогов имеем ввиду 1с

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

у меня же отношения с работодателями. работодатели прекрасно понимают термино !1с-программист", и этого достаточно, как на проектах, так и на job-сайтах
на ИС 1снег - понятный всем термин.
получается (не в упрек) вы залезли со своей терминологией в чужой форум

дольше по существу ответить пока нечего, сорри

160. tango 553 10.04.13 13:58 Сейчас в теме

(158) devel0per,

аппаратная (не софтовая часть) с которой 1С не дружит даже через внешние компоненты

проблема, имхо, таки во внешних компонентах (и/или их писателях), а не в 1С

нужно в "Системе не 1С" запросить данные из нескольких таблиц, обработать

нормальная рабочая задача (даже для чистого 1снега)

передать через вебсервис в 1С

ну, можно и через веб-сервис

в 1С существует отличный финансовый блок

в 1с есть разные такие блоки и разные мнения по каждому из них

актуализируемая по подписке на ИТС отчетность большой плюс

это да

и в чем был трабл?

Как бизнес-аналитика может пригодиться в прикладной разработке 1С? Это другой вопрос.
Приведу пример:

программисты, которые будут писать WEB-сервис, должны получить надлежащую документацию и в соответствии с ней кодировать, а "разработчики 1С" в свою очередь, - написать демонстрационнную конфигурацию.И те и другие должны иметь полную и согласованную документацию.

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

162. devel0per 1 10.04.13 16:22 Сейчас в теме

(160) tango, сами курите что хотите.
То решение про которое я вам рассказал давно уже реализовано. Если вы ничего не поняли то это ваши проблемы. Все.

163. tango 553 10.04.13 16:30 Сейчас в теме

(162) devel0per, все так все, чё за обидки-то?!
реализовано много чего, вон хоть бы и на заборах

164. devel0per 1 10.04.13 16:48 Сейчас в теме

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

165. tango 553 10.04.13 16:52 Сейчас в теме

(164) devel0per, да, деньгами было бы лучше во всех отношениях. учтите, пожалуйста

161. tango 553 10.04.13 14:03 Сейчас в теме

(158) devel0per,

Таким образом, мы можем иметь многоуровневые
расшифровки и отсутствие лишних данных в базе 1С!

таким образом гарантированно получим расшифровку строки "1 рубль" типо
- 1,5 рубля - туда-то
- 3,6 рубля - туда-то
- 10 рублей - туда-то
= итого 15,1 рубля
при этом в 1с итого - это 1 рубль...

151. tango 553 07.04.13 12:47 Сейчас в теме

(143) devel0per,

передать эстафету далее дизайнеру системы

передать "архитектору", ок? дизайнер - это таки больше интерфейс, а тут нас 1с-платформа ставит в рамки. Ну, т.е. испортить интерфейс таки можно, но роль дизайнера в 1с-проектах все-таки перебор.

152. tango 553 07.04.13 12:49 Сейчас в теме

(143) devel0per,

Статья, которую мы комментируем называется: "Философия бизнес-анализа в IT-проектах, или кто такие бизнес-аналитики" - просто сузил тему до своего уровня понимания.

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

144. AlexO 136 05.04.13 22:11 Сейчас в теме

(140) devel0per,

Для того чтобы таких казусов не возникало и нужны бизнес-аналитики в IT.

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

146. devel0per 1 06.04.13 00:09 Сейчас в теме

(144) AlexO, немного не так.
Бизнес-аналитик документирует предметную область, а уже проектировщик (он же дизайнер системы) рисует подробные диаграммы системы и через менеджера проекта доводит до программистов - кодеров какие объекты нужно реализовать, т.е. в нормальном коллективе прямой связи между бизнес-аналитиком и кодером нет.
"Разбирать счета и их смысл" это уже больше похоже на работу "разработчика 1С" и разницу между понятиями программист и "разработчик 1С" можно уловить из книги Радченко М.Г. - "Практическое пособие разработчика"
почти цитата:
"...в 1С Предприятии есть встроенный язык, но он
занимает далеко не главное место в процессе разработки.
Разработка прикладных решений на основе платформы 1С Предприятие -
процесс, в котором "программирование" безусловно присутствует,
но лишь как один из инструментов разработки." (по М.Г. Радченко)

Как бизнес-аналитика может пригодиться в прикладной разработке 1С? Это другой вопрос.
Приведу пример:
Допустим, у вас есть Система (не 1С) к которой нужно сделать вебсервис, а также разработать конфигурацию на 1С, демонстрирующую возможности обмена с Системой. Желательно, чтобы объекты были максимально совместимы. В таких случаях, программисты, которые будут писать WEB-сервис, должны получить надлежащую документацию и в соответствии с ней кодировать, а "разработчики 1С" в свою очередь, - написать демонстрационнную конфигурацию. И те и другие должны иметь полную и согласованную документацию. Без нее может получиться путаница, для исправления которой потом потребуется рефакторинг, который стоит дорого.

153. tango 553 07.04.13 13:37 Сейчас в теме

(146) devel0per,

Система (не 1С) к которой нужно сделать вебсервис, а также разработать конфигурацию на 1С, демонстрирующую возможности обмена с Системой.

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

142. Программист 1С 161 05.04.13 18:14 Сейчас в теме

Ох уж эти аналитики! Тяжко без них Васильевой и Сердюкову... А где успешные проекты-то? Всё срисовываем с кризисного Запада? И хотим такого же успеха? - Я работал несколько лет в Coca-Cola: в зубах навязли эти скаутские речитативы и тренинги, смысл которых: мы несём людям счастье через наши напитки! Больше продаж, больше прибыли и... заплывшие жиром люди, плохо понимающие реальность, в которой они живут.

149. tango 553 07.04.13 12:38 Сейчас в теме

(142) Программист 1С, настоящий сюр :) мультик какой-то напомнило, с лягушками

148. ZLENKO 398 07.04.13 12:22 Сейчас в теме

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

154. tango 553 07.04.13 13:40 Сейчас в теме

(148) ZLENKO.PRO, бизнес-аналитик как таковой применяется вне 1с, и даже вне не-1с-систем
во вне-1с-системах появляется б-а как интерфейс между кодерами и бизнесом, в 1с-ситемах б-а появляется как модная маркетинговая фишка в подражание не-1с-системам
мы тут пытаемся найти какой-то смысл с наличии б-а в 1с-системах

155. ZLENKO 398 07.04.13 13:58 Сейчас в теме

(154) Тут скорее дело не в 1С или не-1С, а в том что бюджеты 1С проектов обычно не предполагают наличие БА.

156. tango 553 07.04.13 14:11 Сейчас в теме

(155) ZLENKO.PRO,

бюджеты 1С проектов обычно не предполагают наличие БА

Да, и это - ключевой вопрос (не зависимо от согласия или несогласия с этим тезисом автора обсуждаемого материала).

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

157. tango 553 07.04.13 14:13 Сейчас в теме

(156) tango, Во-вторых, при сравнении SAP c 1C всегда на первое место выходит разница именно в бюджетах.

166. EAE 12.10.14 02:29 Сейчас в теме

Соглашусь TODD22, руководитель проекта и аналитик - это разные участники проекта, каждый из которых имеет свои обязанности. Более того, в команду проекта, зачастую, включают несколько аналитиков. Главным лицом, ответственным за успех является РП.
Да, бывают проекты где РП и аналитик - один человек. Но это либо от нехватки ресурсов, что конечно же неправильно, либо небольшой проект, где можно допустить такое скрещивание.

167. пользователь 12.06.15 13:07

Сообщение было скрыто модератором.

...

168. пользователь 24.08.16 05:53

Сообщение было скрыто модератором.

...

169. ulen 56 17.08.24 12:50 Сейчас в теме

Отличная статья, хотелось бы увидеть ее в новом свете 10 лет спустя, с поправкой на современные технологии и тенденции.

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

Записи сейчас легко транскрибировать, а GPT в момент структурирует по заданному промту. И т.д.

Для отправки сообщения требуется регистрация/авторизация

Автор:

Александр Чавалах (chavalah)

Рейтинг: 1108

Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.

Публикация:

№ 179311

Создание 24.03.13 01:29

Обновление 02.04.13 08:47

Статистика:

Просмотры 48675

Загрузки 0

Рейтинг 157

Комментарии 166

Характеристики:

Код открыт Да

Рубрики Компетенции и навыки

Кому Для всех

Тип файла Нет файла

Платформа Не имеет значения

Конфигурация Универсальные

Операционная система Не имеет значения

Страна Россия

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)

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