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

Публикация № 179311

Методология - Управление проектом

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

 

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


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

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

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

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

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

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

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

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

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

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

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

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

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


3.      Опыт

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

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

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

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

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

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


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

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

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

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

 

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

 

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

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

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

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


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

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

 

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

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

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


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

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

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

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

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

 

 

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

 

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

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

 

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. TODD22 18 24.03.13 07:29 Сейчас в теме
Но, на практике, таких специалистов далеко не всегда вообще называют аналитиками.

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

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

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

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

А в целом статья зачётная.
KEV8383; boorenka; Uncore; SpartakM; +4 Ответить
4. chavalah 982 24.03.13 15:17 Сейчас в теме
(1) TODD22,


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


Как причем тут аналитик? Это чисто мое мнение, но я утверждаю, что 80% причин за проваленный проект лежит в области плохой аналитики. Если на проекте грамотно управляли требованиями и ожиданиями Заказчика, то некие возникшие риски, о которых Вы говорите, причиной с вряд ли станут. А если и станут, то как раз попадут в оставшиеся 20%.
Если хотите, могу проанализировать Ваш проект (если имеется провальный проект), рассказать о причинах и убедить, что это так. Если Вы сможете рассказать мне о таком проекте на конференции, то это будет абсолютно бесплатно (т.е. даром :))), поскольку люди должны помогать друг другу.
6. TODD22 18 24.03.13 15:27 Сейчас в теме
(4)И всё же мне кажется что вы путаете руководителя проекта и аналитика. Аналитик должен выполнять свою часть работы и риски проекта не его головная боль. Его задача выполнять свою работу качественно и в срок. А уже провалы и риски дело руководителей проекта. А так получается что аналитик должен ещё и за риски думать и за ожидания заказчика и тд.
Хоть я и не могу похвастаться большим опытом и кучей успешных проектов. Но мне кажется что вы смешали аналитика и руководителя проекта.
И получился "компьютерщик", который и мышь починит и бюджетирование на предприятие поставит... и про ожидания заказчика не забудет :)
EAE; bellaform; AnryMc; +3 Ответить
8. chavalah 982 24.03.13 15:42 Сейчас в теме
(6) TODD22, Думать, что делать с рисками, оценивать риски - это да, должен РП.
А получать исходную информацию ему хорошо бы от аналитика. Что такое риски ИТ-проекта? если отбросить политические игры в стане Заказчика, то все остальное - это просчеты конкретных исполнителей в команде проекта.
Я их не путаю. Просто аналитик аналитику рознь. А мне приходилось работать и тем и другим, причем несколько лет.
Если руководителю проекта необходимо проверять за аналитиком каждую мелочь, и тратить столько же времени, что и сам аналитик, то зачем он тогда нужен, такой аналитик? В своей статье я говорю о тех аналитиках, которые нужны в успешных проектах.
12. AnryMc 789 24.03.13 16:52 Сейчас в теме
(6) TODD22,

Полностью согласен:
Бизнес-аналитик и руководитель проекта имеют совершенно разные обязанности и сферы ответственности...
21. tango 492 25.03.13 15:12 Сейчас в теме
(4)
я утверждаю, что 80% причин за проваленный проект лежит в области плохой аналитики
ерунда
смотрите, здесь гораздо реальнее:
http://forum.infostart.ru/forum24/topic81601/
22. chavalah 982 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 1874 26.03.13 12:12 Сейчас в теме
(4) топикстартеру:
- В чем разница между методологом (читай бизнес-аналитиком) и террористом?
- С террористом можно вести переговоры.
:)
2. valentin2019 24.03.13 10:46 Сейчас в теме
Полезная информацию + ∞
Время оно! Статья отражает все существующие процессы, являющиеся фактами.
3. ranger 121 24.03.13 12:29 Сейчас в теме
+1
Только я бы еще посоветовал в конце указать использованные источники информации для написания статьи
5. chavalah 982 24.03.13 15:22 Сейчас в теме
(3) ranger, Статья писалась примерно так: я сел, вспомнил прошедшие проекты, и написал. Писал долго. А вообще это отрывок из неизданной пока книги, авторства моего. Ну а к самой книге список литературы будет обширный.

Если Вас интересует литература на данную тему, могу что-нибудь посоветовать.
7. TODD22 18 24.03.13 15:28 Сейчас в теме
(5)Вот литературу интересно было бы почитать. Приведите список пожалуйста.
wowik; kancerina; +2 Ответить
9. chavalah 982 24.03.13 15:43 Сейчас в теме
(7) TODD22, хорошо, подберу и напишу.
10. ranger 121 24.03.13 16:46 Сейчас в теме
(5) меня очень интересует данная тема и сама статья оказалась как нельзя кстати.Хотелось бы взглянуть как на список использованной литературы,так и на черновик книги :)
17. chavalah 982 25.03.13 08:43 Сейчас в теме
(10) ranger,
Хотелось бы взглянуть как на список использованной литературы,так и на черновик книги :)


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

А список сделаю.
35. chavalah 982 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. Джо Мараско. ИТ-проекты фронтовые очерки.
Nelfast; Vladimir Litvinenko; Sevens; bidond; romansun; +5 Ответить
42. ranger 121 27.03.13 06:36 Сейчас в теме
(35)О!Спасибо.
Еще порекомендовал бы по собственному опыту "Приключения ИТ-лидера" http://www.ozon.ru/context/detail/id/4916263/
11. AnryMc 789 24.03.13 16:48 Сейчас в теме
К сожалению, в наших реалиях, как правило:

Бизнес-аналитик - это человек который "впихивает" процессы Заказчика в продаваемый продукт...
16. chavalah 982 25.03.13 08:40 Сейчас в теме
К сожалению, в наших реалиях, как правило:

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

Да, есть такая проблема. Но часто это и ставится задачей - максимально использовать типовой продукт. Здесь надо уметь почувствовать ту грань, когда от типового надо переходить к адаптации.
13. AnryMc 789 24.03.13 16:54 Сейчас в теме
Кстати если обратить внимание на аватары то можно точно сказать "кто есть аналитик"
14. Новиков 292 24.03.13 20:09 Сейчас в теме
Просмотрел всего Гандапаса.
Прослушал всего Архангельского.
Прошел тренинг по навыкам написания деловых e-mail.
Прошел курс по работе с возражениями.
Прочитал всего Дейла Карнеги.

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

Больше всего понравился Карнеги и Гандапас. Гандапас, вообще очень харизматечный тренер. Смотреть его тренинги - одно удовольствие!
15. chavalah 982 25.03.13 08:35 Сейчас в теме
(14) Новиков, Да, так и есть, 2,5 года это нормальный срок. Я бы даже сказал, что это небольшой срок.

А вот интересно, у кого как сложилась статистика в плане пол/возраст хороших аналитиков? Мне вот, например, толковые аналитики попадались чаще девушки 25-30 лет или мужики за 45. Хотя были и исключения из этой статистики.
18. jig 145 25.03.13 09:47 Сейчас в теме
Грамотно все написано. Спасибо за публикацию.
19. TSSV 25.03.13 10:52 Сейчас в теме
Статья супер! Все в точку! Пишите книгу! Спасибо!
23. chavalah 982 25.03.13 19:48 Сейчас в теме
(19),(18) Спасибо! Надеюсь, что к лету управлюсь.
25. Гость 26.03.13 06:43
(23) судя по этой публикации книга должна получиться очень стоящая. Хорошо бы увидеть здесь новость о выходе книги. Распространять планируете в бумажном виде?
37. chavalah 982 27.03.13 00:18 Сейчас в теме
(25) Ну вообще планирую в издательстве издать. Времени не хватает, как обычно.
У меня тут идея родилась - подарить 10 экземпляров первым интересующимся:))
20. Medvedik 25.03.13 12:57 Сейчас в теме
Спасибо, актуальная статья.
Будучи РП, очень не хватает толкового аналитика, придется растить такого в себе.
24. smaharbA 26.03.13 00:03 Сейчас в теме
нахера аналитеги вообще нужны - базары базарить и кролиководством заниматься ?
видали мы этих аналитегов еще в совдепии
36. chavalah 982 27.03.13 00:16 Сейчас в теме
27. Ish_2 1058 26.03.13 13:52 Сейчас в теме
(0) Вначале статьи поставлен вопрос :
Кто должен заниматься бизнес-анализом в IT-проектах?
Далее неспешные размышлизмы , дескать , бизнес-аналитика - дело непростое.
Затем предложения "как оно должно быть у людей".
Ничего не упустил ?

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

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

Ответы на эти вопросы сделали бы статью поживее, поинтереснее.
И читатели смогли бы судить насколько мало- или много- опытен сам автор.
38. chavalah 982 27.03.13 00:28 Сейчас в теме
(27)
Для кого статья -то ? Для внедренцев ?


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

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


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

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

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

Какой пример Вы хотите услышать? Из практики конкретного проекта?
41. Гость 27.03.13 03:52
(38)
Вообще-то статья для аналитиков. Как выясняется, инфостарт на 98% ресурс чисто программерский.

Ничего удивительного. Соотношение как и в жизни. Но это делает статьи по бизнес-анализу применительно к 1С еще ценнее. К тому же и среди 98% программистов хватает тех, кому это интересно.
50. Ish_2 1058 28.03.13 11:49 Сейчас в теме
(38),(39)
Конечно, в(27) вариант б) , т.е. выделеннеый аналитик, смотрится посолиднее.
Но мы рассмотрим более массовый случай a) - "все мы тут - аналититки".
Воздержися от оценок "хорошо"-"плохо" и ответим на вопрос "Почему так есть?".

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

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

ну, т.е. роль архитектора должна быть на любом проекте
отдельный человечек на эту роль нужен, если РП - не программер
оптимально - если один из кодеров хорошо знает конфу и без его согласования не будет добавлен ни один объект
52. Ish_2 1058 28.03.13 12:36 Сейчас в теме
(51)
роль архитектора должна быть на любом проекте

Конечно. п.1-3 кто-то должен контролировать.
Правда , с тобой тут никто не спорит.
Читаем у автора :
Назовите мне хоть одну компанию 1С-франчайзи в Питере, например, где в штате есть выделенный архитектор? На практике это отдельная роль, но не отдельный человек. И в зависимости от проекта, эту роль приходится выполнять либо руководителю проекта, либо аналитику . Если квалификация последнего позволяет.Бывает, что эту роль передают опытному разработчику.
53. tango 492 28.03.13 12:48 Сейчас в теме
(52) Ish_2, ну да, общее место. и о чем тогда (0)?
вот еще одна такая "публикация"
http://forum.infostart.ru/forum24/topic82942/
54. Ish_2 1058 28.03.13 13:33 Сейчас в теме
(53) Я предпочитаю вопросы автору задавать явно.
Например :
Александр, в Вашей книге будут упомянуты крупнейшие проекты 50-60 гг, осуществленные в СССР ?
Какие тогда применялись технологии управления проектами ?
Как регламентировались отношения "Заказчик" - "Исполнитель"
от этапа "Ниокр" до этапа "опытной эксплуатации".
Нужны ли были тогда "Бизнес-аналитики" ?
66. romansun 190 28.03.13 18:00 Сейчас в теме
(54)

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


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

ссылка

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

и весьма грамотный ответ на неё
О стилях внедрения крупных ERP-проектов
67. Ish_2 1058 28.03.13 19:12 Сейчас в теме
(66) За ссылки спасибо.
Понимаешь, упомянутые проекты создания совершенно новых изделий ,требующие согласованной работы сотен предприятий не могли управляться абы как . Согласен ?
Совершенно очевидно , отношения "Заказчика" и "Исполнителей" должны были как-то регламентироваться.
Должна была использоваться какая-то технология управления проектом.
Судя по результатам ( первый спутник, первый космонавт и т.д) можно предположить - технология неплохая.
Вот я и задал автору будущей книги общий вопрос :
нынешние проектные технологии это что-то новое ?
и второй более частный : нужны ли были в проектах 50-60гг. "бизнес-аналитики" ?
68. romansun 190 28.03.13 20:25 Сейчас в теме
(67)

угу, я понял

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

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

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


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

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


Насчет сейчас - обычно софтваре-коллективы предпочитают выделять отдельно аналитиков. И это, конечно, не относится к поддержке типовых в 1С. Это относится к разработке и глубокому внедрению ПО.
71. tango 492 28.03.13 22:01 Сейчас в теме
(68) romansun,
к разработке и глубокому внедрению ПО
вот бы пример бы какой-нибудь
72. Ish_2 1058 28.03.13 23:58 Сейчас в теме
(68)
"Вполне вероятно, что финансовый задел в 50-60г был колоссальным на инновационные стратегические проекты."
Нет. Задела после 41-45 г. не было.

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

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

- Товарищ Берия, я - не виноват!
- Канещна не винават, дарагой! Бильби винават - мибитибя расстреляли!
75. chavalah 982 30.03.13 22:21 Сейчас в теме
(54)
Александр, в Вашей книге будут упомянуты крупнейшие проекты 50-60 гг, осуществленные в СССР ?
Какие тогда применялись технологии управления проектами ?


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

Кстати, у нас же хранилась проектная документация на тот софт, которые разрабатывался для этого динозавра. Если его начнет читать современный разработчик - он вообще не поймет, как так можно было работать. Весь программный код писался сначала на бумаге, чертежным шрифтом. программист не набирал код на компьютере, он лишь писал его на бумаге. Набирал код оператор. Программист потом отлаживал. Такая странная методика объяснялсь дорогим временем доступа к компьютеру - работали только по расписанию, по записи. Вот так вот работали в 70-х.
А уж как было в 50-х мне неведомо, да и не очень интересно, если честно.
81. Ish_2 1058 31.03.13 11:54 Сейчас в теме
(75) Конечно , речь шла не о бабушках и не о машине СМ 1420.
Ирина любезно помогла мне : в (78) описан функционал одного из участников проекта (не только ИТ-проекта).
Уверяю, работники с таким функционалом требовались не только в 50-60гг., но и 19 веке -
при внедрении новых производственных технологий.

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

Наверное , в качестве "конструктива" я должен был бы добавить нечто вроде :
"Бизнес-аналитик должен мыть руки перед едой"
но я попытался несколько расширить рамки статьи.
83. PAVI 1379 31.03.13 12:20 Сейчас в теме
(81) Ish_2,
У Вас места для описания того "откуда есть пошел" "Бизнес-аналитик"
и чем раньше занимался - не нашлось. Он выскакивает как "черт из табакерки", дескать, нужен в IT-проекте

Всегда считала, что историей и археологией занимаются люди с особенным призванием. И если человек хочет описывать современность, то он это делает. А потом приходит кто-то с призванием к истории и вносит свою лепту в вопрос.
Или просто нужен повод упрекнуть автора?!
86. tango 492 31.03.13 12:44 Сейчас в теме
(83) PAVI,
повод упрекнуть автора
и я, и Игорь уверены, что автор не заслужил наших упреков.
мы обсуждаем статью
в статье предпринята попытка наполнить содержанием роль аналитика
содержание это добывается аналитическим рассечением роли Исполнителя - здраво и полезно

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

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

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

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

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

P,S, Ирина, может, Вы знаете ?
88. tango 492 31.03.13 13:28 Сейчас в теме
(87) Ish_2, Философия такая:
Там, где экономика - суть обмен эквивалентами (не важно, определен эквивалент госпланом или рынком), функциональная единица обусловлена функцией.
Там, где имеет место быть распределение природной ренты, внеэкономические обоснования распространяются быстрее рака.
91. chavalah 982 31.03.13 17:01 Сейчас в теме
(87)
Никакими клещами не могу вырвать из автора ответ на философский вопрос :

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



Почему не было-то? Всегда такие люди были, только назывались по-разному. А Вы знаете, откуда появились CRM-системы, ведь их раньше тоже не было? Логистика? Может и не нужны они? Мир меняется, меняются потоки информации, сложность ее обработки и много еще чего. Когда Тейлор наблюдал за человеком с лопатой, он что по Вашему делал? В какой-то степени это был тоже бизнес-анализ, за которым последовало зарождение научной орагнизации труда. Оптимизация труда, нормы труда и пр. После этого, между прочим, стали делать лопаты разной формы, в зависимости от материала, с которым этой лопатой будут работать. А после этого стали появляться первые школы менеджмента.
55. awk 725 28.03.13 14:33 Сейчас в теме
(53) tango, (54) Ish_2, Если на ролях аналитика и РП люди с мозгами, то до этапа проектирования (где появляется роль архитектора) доходит только 10% проектов. 90% либо закрываются как нерентабельные(нечего проектировать), либо покупаются коробки(архитектура предопределена).
57. tango 492 28.03.13 15:24 Сейчас в теме
(55) awk, ну да. фишка в том, что в этих 90 никто не платит за мозги рп-аналитика, поэтому начинаются внедрения-таки
вот свежий пример
http://forum.infostart.ru/forum26/topic82990/
39. chavalah 982 27.03.13 00:35 Сейчас в теме
(27)
Следующий вопрос :
Почему случаев а) многократно больше чем б) ?
- Потому что внедренцы не чтят Аристотеля ?
- Совсем не читают А.Чавалаха ?
- Другое ?


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

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

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


На эту тему полемизировать не буду. Если у Вас есть конкретный провальный проект - могу помочь спасти. А так просто что-то доказывать не стану.
28. Арчибальд 2712 26.03.13 15:06 Сейчас в теме
Надо заметить, что термин "аналитик" вообще неудачен. В буквальном переводе - расчленитель. Вот цитата из реферата по философии
...анализ – процедура мысленного (иногда и реального) расчленения изучаемого объекта на составные части, рассмотрение всех сторон и способов функционирования свойства и изучение их. Расчленение имеет целью переход от изучения целого к изучению его частей и осуществляется путем абстрагирования от связи частей друг с другом.

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

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

Теперь цитируем статью:
И тут на первый план выходят люди, именуемые бизнес-аналитиками. Их задачей является понять, что хотят заказчики, как должна выглядеть система, как должна себя вести,
Проще говоря, задача бизнес-аналитика - это синтез системы.
Далее видим
Таким образом, чтобы мыслить аналитически, надо быть немного философом. Смотреть на мир не так, как все.
На самом деле, если человек мыслит - значит, он занимается анализом и синтезом. Другого способа мышления просто не существует. Мольеровский Журден как-то сказал:
Честное слово, я и не подозревал, что вот уже более сорока лет говорю прозой.
То есть важно не только "говорить прозой", но и понимать, что это проза. Чтобы стать хорошим бизнес-аналитиком, надо помнить, что успешность проекта рождается на фазе синтеза. Это завалить проект можно уже в процессе анализа.
bellaform; yuraos; +2 Ответить
29. AnryMc 789 26.03.13 15:40 Сейчас в теме
(28) Арчибальд,

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

Это не "расчленение"?
31. Арчибальд 2712 26.03.13 15:45 Сейчас в теме
(29) AnryMc, да я ж не против расчлененки. Без нее не обойтись: разобрать, классифицировать. Но в итоге-то должна получиться система, которая не равна сумме составных частей.
30. Ish_2 1058 26.03.13 15:43 Сейчас в теме
И вроде придирка в (28) к автору чистейшей воды :
ну, называются они так - "бизнес-аналитики" ,
что не мешает им и "синтезировать" и "анализировать".

Ан , нет. Замах-то в заголовке какой : "Философия.." - а раз так то ,будь добр -соответствуй.
Дай разьяснение философическое - или неча в Философию лезть..
32. Арчибальд 2712 26.03.13 15:47 Сейчас в теме
(30) Ish_2, это не придирка, а уместное примечание для будущей книги автора.
40. chavalah 982 27.03.13 00:59 Сейчас в теме
(32)
(30) Ish_2, это не придирка, а уместное примечание для будущей книги автора.


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

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

Правда, не могу представить, как читатели отреагируют. Не поймут наверное, для чего я это написал. Придется в конце большой такой смайлик нарисовать и ссылку на форум:)))
43. Арчибальд 2712 27.03.13 08:29 Сейчас в теме
(40)
Однако, не будем впадать в крайности и отвергать термин "Аналитик"
Отвергать поздно уже - термин устоялся. Но уточнить смысл никогда не вредно.
углубляется в терминологию курса философии
А это навет. Ни в какую терминологию я не углублялся. Только уточнил, что при всей важности анализа (с анализа и классификации начинается любое познание), без синтеза он бесплоден.
Ну вот хоть посмотреть на фразу из статьи
Однозначного ответа тут нет, но практика показывает, что чем лучше аналитик представляет архитектуру системы и чем глубже владеет знаниями в разработке ПО, тем эффективность команды в целом выше.
А архитектура - это что? Результат анализа или таки синтеза?
Нет, если ограничиться проектами по тюнингу типовых конфигураций, то синтез на первый и даже второй взгляд не требуется. Но тогда нужно прямо указывать, о чем идет речь. Скажем, "Роль и место бизнес-аналитика в ИТ-тюнинге".
44. tango 492 27.03.13 08:41 Сейчас в теме
+(43) Арчибальд, "неизбежность анализа при оптимизации прикладного интерфейса в семействе программ 1С:Предприятие"

Имхо, автор путает роль аналитика с ролью архитектора системы
Типо как березоцкий в свое время спутал себя с ролью презика рф
45. chavalah 982 27.03.13 09:05 Сейчас в теме
(44)
автор путает роль аналитика с ролью архитектора системы


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

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

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

А практика большинства проектов примерно такая: "аналитик" (именно в кавычках) рассказывает программисту, что хочет клиент, программист что-то делает, клиент удивляется, РП портит нервы. Нет, не знакомо? А потом еще оказывается, что принятые архитектурные решения вводит ограничения на дальнейшее развитие системы, и приходится все переделывать. Нет, не знакомо? Ну так расскажите свой опыт, чего троллить-то по форуму.
46. tango 492 27.03.13 10:08 Сейчас в теме
(45) ну вот опять. несостоятельность собственной позиции прикрывается воплями "держи тролля"
вам - в компанию ред80 и маленького злобного "учителя"
47. Арчибальд 2712 27.03.13 10:50 Сейчас в теме
(45)
В западных системах это обычно реально разные люди, но там и подход другой.
Дело не в западе/востоке. Просто когда система разрабатывается (или строится из модулей) архитектор необходим, а когда пиджак уже сшит - на кой нам Слава Зайцев?
Назовите мне хоть одну компанию 1С-франчайзи в Питере, например, где в штате есть выделенный архитектор?
Именно. Но они и не занимаются ИТ-проектами вообще. Только конкретными - тюнинг (часто нулевой) типовых конфигураций.
74. chavalah 982 30.03.13 21:51 Сейчас в теме
(47) Арчибальд,
Именно. Но они и не занимаются ИТ-проектами вообще. Только конкретными - тюнинг (часто нулевой) типовых конфигураций.


Почему Вы так решили? Существует много проектов, где разрабатывались системы практически с нуля. Даже если взять некоторые отраслевые конфигурации, то и там встречаются достаточно большие разработки. Мне, например, приходилось приходилось заниматься проектом по адаптации УПП под ювелирное производство. Весьма не тривиальная задача.
95. Арчибальд 2712 01.04.13 14:46 Сейчас в теме
(74) процитирую себя:
В подходе автора предполагается одноэсная идеология, так что третий этап становится практически незаметным, и к тому же, становится перед вторым. Вопроса из четвертого этапа не стоит - только пристроить.
Очень подходит ко всем проектам по адаптации УПП.
Если "с нуля" - значит, с синтеза модели бизнеса из (как правило, обрывочных) сведений, извлеченных из руководителя бизнеса.
И в Вашей статье, и в 78 комментарии Ирины, да, собственно, и в моих комментариях указывется на основополагающий (начальный, первичный) этап: выяснение/формулирование чего надо заказчику. То есть синтез модели будущей системы. Реально этим занимается тот же самый бизнес-аналитик - потому-то я и сказал, что название неудачное.
Что произойдет, если будет синтезирована неадекватная модель, либо вместо синтеза ограничиться сложением "хотелок"? Я утверждаю, что при профессиональном руководстве проект обязательно станет провальным (хотя, возможно, заказчик этого не поймет). А вот при слабо формализованном инвест-сотрудничестве заказчика с исполнителем есть шанс, что, например, программист увидит за деревьями лес, предложит модель, ТЗ будет выброшено и дальше процесс пойдет в нужном направлении.
96. tango 492 01.04.13 14:52 Сейчас в теме
(95) Арчибальд,
как правило, обрывочных
+ и даже прямо ложных. спроси его потом, зачем соврал? сам не знает. привычка.
93. PAVI 1379 01.04.13 07:27 Сейчас в теме
(47) Арчибальд,
Просто когда система разрабатывается (или строится из модулей) архитектор необходим, а когда пиджак уже сшит - на кой нам Слава Зайцев?

Несколько месяцев назад приходилось принимать решение: дорабатывать у клиента самописный модуль к УПП, или "идти другим путем". Есс-но тот, кто писал, уже потерялся на просторах России, даже номер телефона сменил. А писал около года. И клиент написанным почти доволен, но на итоги не выходит.
Вот и пришлось Славу Зайцева изображать... А у "костюмчика" проблема была не только в "пуговицах".
49. awk 725 28.03.13 00:20 Сейчас в теме
(45) (47) Арчибальд, Как сказал Ходжа Насреддин "И ты прав... И ты прав..." Аналитик - это ключевая роль начальных этапов. Вот только зачастую у нас их игнорируют и начинают проектировать. Потом ничего не получается и приходим к... Ну тут каждый к своему...
Арчибальд; +1 Ответить
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) в значительной степени системному аналитику помогают.
Основная мысль, почему я в это обсуждение встрял, принадлежит Козьме Пруткову - специалист подобен флюсу, его полнота одностороння. Куда ни сунься - все твердят об исследовании бизнес-процессов, планировании и отслеживании этапов работ, документировании, протоколировании, ну и немалая роль отводится также впариванию и задоприкрывательству (ТЗ). Так вот, я утверждаю, что если все это прекрасно научно организовать - проект будет успешным для исполнителя и, весьма вероятно, провальным для заказчика - при этом, возможно, заказчик этого и не заметит. Если изначальная идея не выкристаллизовалась, исполнитель должен ее синтезировать из хотелок. Это будет цель проекта. Совпасть с истинной целью заказчика она может только случайно.
Должен ли это понимать читатель будущей книги автора? Вообще, циничность - это обязательный атрибут РП? Системный аналитик - он должен работать на проект или на руководителя проекта? Ведь эти цели во многом противоположны.
awk; ula1c; +2 Ответить
58. Ish_2 1058 28.03.13 16:01 Сейчас в теме
Вероятно в (56) , ты хотел сказать много чего разного и много чего интересного.
Хм.. А получилась пурга какая-то.
cool.vlad4; +1 Ответить
59. tango 492 28.03.13 16:07 Сейчас в теме
(58) Ish_2, да нормально сказал: там, где awk зарубил 90% проектов, Арчи сохранил светлое интим-ностальжи
**
заметь, дирректрисса ему до сих пор платит "большую" зарплату
61. Ish_2 1058 28.03.13 16:20 Сейчас в теме
(59) Ты уловил , а я не заметил.
Когда начинаешь рассказывать про то что интересно и дорого самому - получается длинно и путанно.
Вообщем , пурга.
60. awk 725 28.03.13 16:18 Сейчас в теме
(58) Ish_2, Мысль, в том, что подход правильный - стоит БООЛЬШИХ денег.
Системный аналитик - он должен работать на проект или на руководителя проекта? Ведь эти цели во многом противоположны.

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


Очень знакомо...
63. Ish_2 1058 28.03.13 16:41 Сейчас в теме
(60)
"Системный аналитик - он должен работать на проект или на руководителя проекта? Ведь эти цели во многом противоположны."

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

Интересно другое :
Арчибальд до сих пор упорно задает этот вопрос.
64. tango 492 28.03.13 16:43 Сейчас в теме
(63) Ish_2, он не определился :)
65. Ish_2 1058 28.03.13 17:16 Сейчас в теме
(64) Вот , представь ,Миша, - ты РП.
Подходит к тебе бизнес-аналитик (Арчибальд) и говорит :
Цели РП и Цели проекта могут не совпадать. Лично я полечу прямо на солнце
буду работать на проект.
Так выпьем же за здоровье Арчибальда.
За крепкий клюв и широкие крылья.
69. tango 492 28.03.13 21:40 Сейчас в теме
(65) Ish_2, невозможно, чтобы Арчи ушел от нее. я бы трижды подумал
94. Арчибальд 2712 01.04.13 13:38 Сейчас в теме
(65) Ish_2, Ты не поверишь, два года назад примерно так и было. Я пришел к РП и сказал: проект не имеет отношения к заводу по таким-то и таким-то обстоятельствам. А когда РП меня не послушал, я отказался в проекте участвовать.
100. Ish_2 1058 01.04.13 18:08 Сейчас в теме
(94)
Ish_2, Ты не поверишь, два года назад примерно так и было. Я пришел к РП и сказал: проект не имеет отношения к заводу по таким-то и таким-то обстоятельствам. А когда РП меня не послушал, я отказался в проекте участвовать.


Другими словами, в проекте не стало бизнес-аналитика вольнодумца. Очевидно, пригласили другого.
Ты подтвердил мой тезис :
"Системный и любой другой аналитик должен работать на руководителя проекта. Точка."
77. chavalah 982 30.03.13 22:32 Сейчас в теме
(60)
"У нас все готово, но находится в голове РП".
- отличная фраза, надо запомнить:)
76. chavalah 982 30.03.13 22:30 Сейчас в теме
(56) Спасибо за развернутое мненние. Вообще-то, в статье не идет речь об этапах проекта и вообще о проектом управлении. В ней ведь говорится лишь о том, каких аналитиков хочется видеть на проектах.

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

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

И аналитик, и Руководитель проекта, должны работать на Заказчика! - я правда так считаю. В этом кроется секрет его удовлетворенности. На первый взгяд банально, но Вы попробуйте!
33. tango 492 26.03.13 16:11 Сейчас в теме
(28) Арчибальд,
задача бизнес-аналитика - это синтез системы.
построение модели. задача программиста
34. AnryMc 789 26.03.13 16:56 Сейчас в теме
О "сошлись" два седобородых моряка ;-)
73. smaharbA 29.03.13 23:24 Сейчас в теме
дейбилы -3 добавили - на то оне и дейбилф
78. PAVI 1379 31.03.13 07:34 Сейчас в теме
Александр, спасибо за четкое представление нашей специальности (?!) широкой публике.
В 2002 г. меня взяли в Рарус в качестве дешевого приложения к мужу-программисту. Через несколько месяцев зарплату подняли вдвое. А когда уезжали на малую родину, то услышала много хорошего в свой адрес. Так в моей трудовой деятельности появилась специальность "бизнес-аналитик".
Сейчас я четко понимаю, что отдавать пожелание клиента сразу в "голову" программиста вредно, ибо он начнет думать о его реализации. А любое пожелание должно пройти осмысление в следующих направлениях:
1.Клиенту нужно именно то, что он просит?
2.Можно ли реализовать пожелание клиента существующими инструментами?
3.Провести декомпозицию пожелания и снова провести анализ: что уже существует в конфигурации, а что придется дорабатывать.
4. Провести консультацию с архитектором системы или программистом по поводу возможности реализации задуманного. Выявить различия в желаниях клиента и возможностях системы.
5. Снова вернуться к клиенту и предложить ему возможную схему реализации его пожелания.
Для нас с мужем наиболее зримой аналогией такой работы является система горно-обогатительный комбинат и медеплавильный завод.

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

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

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

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

поэтому, собственно, столько и негатива от 1снегов, поскольку 1снеги ровно в той степени аналитики и архитекторы, в какой не программисты
82. PAVI 1379 31.03.13 12:15 Сейчас в теме
(79) tango,
Как я поняла, профессия "сомелье" Вам так же неприятна, как и "бизнес-аналитики". Первые мешают пить, вторые - наслаждаться впечатлением, производимым на юзверей от встречи с титанами мысли и программирования.
Но мир бесконечен в своем многообразии...
84. tango 492 31.03.13 12:25 Сейчас в теме
(82) PAVI, про мир - не надо, я вчера побывал на прикольном переносе, и уже начал приближение к сальвадору дали.

корень проблемы - бюджет проекта. если клиент способен проникнуться до саповских масштабов, появление в команде аналитика, нет не так - Бизнес-Аналитика! - может только приветствоваться, если, конечно, доля малая простым лягушкам будет увеличена пропорционально
85. tango 492 31.03.13 12:29 Сейчас в теме
(82) PAVI,
наслаждаться впечатлением, производимым на юзверей от встречи

гы, не сообразил, что вы не в теме.
необходимое пояснение: дело вовсе не в роскоши человеческого общения, а опять же в презренном металле
франчайзи изолируют прогов от клиента с целью предотвращения прямых расчетов
90. chavalah 982 31.03.13 16:47 Сейчас в теме
(85)
необходимое пояснение: дело вовсе не в роскоши человеческого общения, а опять же в презренном металле франчайзи изолируют прогов от клиента с целью предотвращения прямых расчетов


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

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

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

Тейлор наблюдал за человеком с лопатой, ... После этого, между прочим, стали делать лопаты разной формы
Это тоже в книгу, всенепременнейше.
89. chavalah 982 31.03.13 16:39 Сейчас в теме
(78)
Спасибо, Ирина! Ваше мнение для меня очень ценно.
80. tango 492 31.03.13 11:24 Сейчас в теме
еще один курьёз типо парадокс
рекомые сомелье просто жизненно необходимы именно франчайзи, чтобы исключить прямой контакт 1снега с клиентом
с другой стороны эта необходимость находится в непримиримом противоречии с лозунгом "доступно и" "наливай и пей", увеличивая бюджет любого проекта до саповских размеров, что может только приветствоваться всеми участнегами
97. romansun 190 01.04.13 15:43 Сейчас в теме
Слуште, дискуссия как-то у нас куда-то ушла ))
Давайте актуализируем потребности, та-сказать.

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

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

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

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


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

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


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

Разделение труда.
cleaner_it; +1 Ответить
98. PAVI 1379 01.04.13 15:45 Сейчас в теме
Александр, в постах к статье "Безнадежный проект. 8 уроков палкой" уже ссылаются на Вас:
Ускорение вхождения в тему на порядок " Никогда не было основной компетенцией бизнес-аналитика. Ни у Чавалаха в его свежей публикации, ни у кого другого. Приведи ссылку.

Я думаю, что это тоже хорошая компетенция в нашей деятельности. А как Вы?!
99. Арчибальд 2712 01.04.13 15:59 Сейчас в теме
(98) PAVI, согласен абсолютно.
Я, собственно считаю основным качеством аналитика не умение разбирать бизнес на бизнес-процессы, а способность быстро разобраться в бизнесе. И статьи Александра (я их не только здесь читал) могут помочь развить эту способность.
cleaner_it; +1 Ответить
Оставьте свое сообщение

См. также

Стратегия выживания в корпоративных войнах Промо

Управление проектом Бесплатно (free)

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

16.09.2019    10512    GSoft    16    

9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

Управление проектом Бесплатно (free)

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

16.02.2021    2573    MariaTemchina    39    

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

Управление проектом Управление командой Бесплатно (free)

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

10.02.2021    3364    andironenko    12    

Статья Компетенции РП по версии PMI и здравому смыслу. Часть 2-ая

Управление проектом Бесплатно (free)

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

09.12.2020    1530    MariaTemchina    3    

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

Управление проектом Бесплатно (free)

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    10176    user809424    11    

Что почитать про Agile для чайников?

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    3052    MariaTemchina    9    

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

Управление проектом Бесплатно (free)

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    2938    MariaTemchina    8    

Как стать исполнителем в проекте от Инфостарта

Управление командой Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    3095    alexandr.blinov    17    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    35244    1СERP    79    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    3355    MariaTemchina    23    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

Управление услугами и сервисом Управление бизнес-процессами (BPM) Управление прочее Управление проектом Бесплатно (free)

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    3133    MariaTemchina    4    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    4630    1c-intelligence    17    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    31589    1СERP    175    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

Из-за отсутствия грамотных правил разработки на этапе внедрения сильно усложняется работа по поддержке и развитию типовых доработанных конфигураций. О некоторых правилах и подходах в разработке, которые помогут специалистам сопровождать внедренное решение, на конференции Infostart Event 2019 Inception рассказал разработчик компании «Инвестиционная группа Абсолют» Алексей Степаненко.

08.06.2020    5315    stepan96    12    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    5808    sapervodichka    1    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    11549    MariaTemchina    33    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    32599    1СERP    189    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

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

23.03.2020    6289    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    6856    VLikhobabin    44    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Waterflow Бесплатно (free)

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

23.01.2020    20561    MariaTemchina    8    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

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

10.04.2017    32657    1СERP    107    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    8655    roman72    0    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6914    1c-intelligence    33    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Бесплатно (free)

Очередной темой серии статей “20 мыслей об ИТ-проектах” будут требования к системе. По результатам голосования был вариант про карьеру проектных ИТ-специалистов, но ее я коснулся в докладе на Воронежском митапе, немного изменив и сделав акцент в сторону аналитиков. В ближайшем выпуске сделаю небольшую выдержку по теме.

14.10.2019    6079    chavalah    16    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    43786    1СERP    231    

Незакрытый проект на 1000 часов

Управление проектом Россия Бесплатно (free)

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

19.09.2019    12894    ogroup    164    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    13787    SergeyN    10    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

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

20.08.2019    9360    Arsen1986    7    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Многие руководители предприятий не обладают полной картиной происходящего в собственных производственных подразделениях. Они знакомы с организационной структурой, направлениями деятельности, общими экономическими показателями. Если по результату получилась прибыль, то наступает уверенность успеха. Но есть ли на рынке предприятия, которые длительное время удерживаются в "слепом" режиме управления?

23.02.2017    27996    Gavrik    10    

Управление проектами по автоматизации бюджетирования

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    8609    SergeyN    1    

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

Управление проектом Бесплатно (free)

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    6992    sbase    9    

Цифровая трансформация. Будущее учетных систем

Управление проектом Россия Бесплатно (free)

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

19.06.2019    10563    FB_10160810658600104    62    

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

Управление проектом Бесплатно (free)

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

17.06.2016    40587    raiml    37    

Риск - благородное дело!.. Часть первая

Управление проектом Бесплатно (free)

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    7927    MariaTemchina    8    

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

Управление проектом Бесплатно (free)

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

31.05.2019    10274    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    11532    1c-intelligence    121    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

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

26.12.2014    45190    CheBurator    64    

Устав писать Устав

Управление проектом Бесплатно (free)

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    8077    MariaTemchina    8    

Как сжать время?

Управление проектом Личная эффективность 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    9127    1c-intelligence    39    

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

Управление проектом Бесплатно (free)

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    12474    MariaTemchina    15    

Практика пуска склада продуктов питания Промо

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    36542    axxell    15    

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Управление проектом Бесплатно (free)

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

13.02.2019    8395    chavalah    22    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    10682    MariaTemchina    20    

Бизнес, не горюй

Управление проектом Бесплатно (free)

Про цели автоматизации.

04.02.2019    10362    1c-intelligence    64    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

06.04.2015    38045    raiml    14    

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения

Управление проектом Бесплатно (free)

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

31.01.2019    8466    MariaTemchina    0    

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

Управление проектом Бесплатно (free)

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

14.01.2019    10497    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

Управление проектом Бесплатно (free)

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    13237    chavalah    123    

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

Управление проектом Бесплатно (free)

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

16.11.2014    28943    raiml    46    

Где мы взяли флакон?

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

История появления и развития методики

26.12.2018    10180    1c-intelligence    7    

Озарение после прочтения макулатуры по проектному управлению

Управление проектом Бесплатно (free)

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    10190    MariaTemchina    24