Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
У себя выявили одно довольно интересно требование к БА, с которым, правда, не все согласны. БА должен знать внедряемый продукт на уровне среднего внедренца (инженера или программиста). В противном случае, количество «дыр» в тех. заданиях стремится к бесконечности.
Сейчас обдумываем возможность использования БА в качестве инженеров в мелких проектов для поддержки их компетенции.
Сейчас обдумываем возможность использования БА в качестве инженеров в мелких проектов для поддержки их компетенции.
>БА должен знать внедряемый продукт на уровне среднего внедренца (инженера или программиста)
В корне не согласен. Аналитик должен знать продукт гораздо лучше любого другого участника процесса. Иначе непонятно, а какая вообще от него польза в проекте.
В корне не согласен. Аналитик должен знать продукт гораздо лучше любого другого участника процесса. Иначе непонятно, а какая вообще от него польза в проекте.
Я думаю разногласия порождены разной точкой зрения на понятия «знать продукт» и разной практикой во внедрении приложений (читай «бизнес-приложений»):
- Что значит «знать продукт»? Если имеется ввиду «технические знания в коде, архитектуре и т.п.» то в корне не соглашусь. Так как если БА знал бы это лучше всех остальных, тогда бы справедлив был бы вопрос, утрирую, «А зачем вообще нужны архитекторы, программисты, инженера и т.п.». Ведь по факту, при прочих равных, маленькая проектная команда эффективнее чем большая проектная команда (обратите внимание, при прочих равных, т.е. как минимум маленькая способна справится с таким проектом в нужный срок). Проблема взаимодействия — одна из ключевых, с ростом участников рабочей группы — эффект только усиливается. Для поговорки «Одна голова хорошо, а две лучше» метод математической индукции не действует. Где то на 4-5-ой «голове», она и каждая последующая делают коммуникации все более сложными, нивелируя эффект общей базы знаний и компетенций.
- Если «знать продукт» — имеется ввиду его фундаментальные возможности, т.е. перечень задач, которые могут быть решены — то полностью согласен. Единственная оговорка, что в этом смысле «знать продукт» в какой то степени равнозначно необходимости специализации в классе систем, например ECM, так как практически все продукты «класса ECM» в целом предназначены для решения определенного класса задач, пусть с некоторыми особенностями от продукта к продукту, но этих особенностей не «бесконечное число», особенно в терминах возможностей.
Смотрите какая интересная ситуация.
Предположим есть аналитик, который не знает продукт (его конкретные возможности и ограничения), но вполне ориентируется в классе ECM. Он идет к заказчику, в попытке выявить потребности на пресейле. Задает вопросы, записывает ответы.
При этом он не может сразу выстраивать ожидания и не может создать конкурентное преимущество, потому что не знает продукта (его возможностей и ограничений), который будет продаваться. А в случае продажи услуг разработки ситуация еще хуже, потому что аналитик не знает технические аспекты и, скорее всего, не узнает.
Теперь представим аналитика, который делает то же самое, но уже в ходе проекта, когда цель известна и нужно уточнять конкретные вопросы. Тут уже аналитик вообще ничего не сможет сделать. Потому что он продукт не знает, и если его спросят «можно ли добавить большую зеленую кнопку в правом угу» не сможет ничего ответить. И уже тем более не сможет предложить какое-либо решение.
Причем чем сложнее продукт, на базе которого создается нечто для заказчика, тем хуже ситуация для таких незнающих аналитиков.
Сколько я видел живых примеров — аналитик, не знающий продукт на уровне внедренца, практически бесполезен.
Предположим есть аналитик, который не знает продукт (его конкретные возможности и ограничения), но вполне ориентируется в классе ECM. Он идет к заказчику, в попытке выявить потребности на пресейле. Задает вопросы, записывает ответы.
При этом он не может сразу выстраивать ожидания и не может создать конкурентное преимущество, потому что не знает продукта (его возможностей и ограничений), который будет продаваться. А в случае продажи услуг разработки ситуация еще хуже, потому что аналитик не знает технические аспекты и, скорее всего, не узнает.
Теперь представим аналитика, который делает то же самое, но уже в ходе проекта, когда цель известна и нужно уточнять конкретные вопросы. Тут уже аналитик вообще ничего не сможет сделать. Потому что он продукт не знает, и если его спросят «можно ли добавить большую зеленую кнопку в правом угу» не сможет ничего ответить. И уже тем более не сможет предложить какое-либо решение.
Причем чем сложнее продукт, на базе которого создается нечто для заказчика, тем хуже ситуация для таких незнающих аналитиков.
Сколько я видел живых примеров — аналитик, не знающий продукт на уровне внедренца, практически бесполезен.
Предположим есть аналитик, который не знает продукт (его конкретные возможности и ограничения), но вполне ориентируется в классе ECM. Он идет к заказчику, в попытке выявить потребности на пресейле. Задает вопросы, записывает ответы.
При этом он не может сразу выстраивать ожидания и не может создать конкурентное преимущество, потому что не знает продукта (его возможностей и ограничений), который будет продаваться. А в случае продажи услуг разработки ситуация еще хуже, потому что аналитик не знает технические аспекты и, скорее всего, не узнает.
Я бы в ответ на Ваш пример заметил, что выявить потребность на пресейле и создать конкурентное преимущество — это две разные задачи в общем случае, мало между собой связаны: БА пытается понять границы, чтобы потом команда условно посчитала деньги, а сэйлз описывает конкурентные преимущества. Соглашусь, что совершенно не знать продукт, который внедряешь — ну такого просто и не бывает, наверное, но уровень знаний какой? Я бы рискнул утверждать, что достаточно уровня очень уверенного и «прошаренного» пользователя решений на базе этого продукта (причем не судя по одному проекту, а судя именно по набору, т.е. видел продукт в разных «состояниях»), потому что все же внедренец — это (в моем случае) знание скриптов, запросов и т.п… Хотя чем лучше БА разбирается в продукте (при прочих равных), тем меньше рисков определенного класса — с этим никто спорить не будет.
Сколько я видел живых примеров — аналитик, не знающий продукт на уровне внедренца, практически бесполезен.
Предположил бы, что такое мнение может быть следствием особенностей наблюдаемых Вами методологий внедрения и уровню взаимодействия внутри проектной команды. Это же палка о двух концах. Когда в проекте что-то идет не так, то все склонны винить обычно кого-нибудь, но только не себя. Кстати в статья я писал, что БА зачастую, наравне с ПМ-ом, самый виноватый в глазах основной команды. Почему так происходит? Рискнул бы предположить, что именно на ПМ и на БА большая большая часть ответственности, чем на других ролях.
На практике пресейл это и есть выстраивание ожиданий и создание конкурентных преимуществ.
Очень часто бывает, что заказчик говорит «хочу Х», но грамотный внедренец поймет, что можно сделать Y, с тем же результатом и меньшими затратами\рисками. А вот аналитик без знаний уровня внедренца не поймет.
А дальше получается так: аналитики все записывает приносит команде, команда нахоит 100500 таких требований, которые можно слегка поменять и снизить риски и затраты. Нужно обсуждать это с заказчиком. А как? Снова ехать, уже расширенным составом, вместе с внедренцами? А зачем аналитик тогда катался в первый раз? Вот и получается что сбор требований == выстраивание ожиданий.
И это еще хороший сценарий. А бывает так, что заказчик не знает как лучше сделать и задает вопросы, на которые аналитик ответить не может в силу незнания продукта. Это сразу бьёт по доверию к аналитику и к компании вообще. Получается что пресейл (сбор требований) == созданию конкурентных преимуществ.
Не обязательно что-то должно идти не так, чтобы было понятен вклад каждого участника в проект.
На моей практике польза аналитиков сводилась к написанию необходимых бумажек и тестированию.
Один мой знакомый сказал по этому поводу «аналитики существуют, потому что не всем тестерам можно дать бирку ПМа».
Очень часто бывает, что заказчик говорит «хочу Х», но грамотный внедренец поймет, что можно сделать Y, с тем же результатом и меньшими затратами\рисками. А вот аналитик без знаний уровня внедренца не поймет.
А дальше получается так: аналитики все записывает приносит команде, команда нахоит 100500 таких требований, которые можно слегка поменять и снизить риски и затраты. Нужно обсуждать это с заказчиком. А как? Снова ехать, уже расширенным составом, вместе с внедренцами? А зачем аналитик тогда катался в первый раз? Вот и получается что сбор требований == выстраивание ожиданий.
И это еще хороший сценарий. А бывает так, что заказчик не знает как лучше сделать и задает вопросы, на которые аналитик ответить не может в силу незнания продукта. Это сразу бьёт по доверию к аналитику и к компании вообще. Получается что пресейл (сбор требований) == созданию конкурентных преимуществ.
Когда в проекте что-то идет не так, то все склонны винить обычно кого-нибудь, но только не себя
Не обязательно что-то должно идти не так, чтобы было понятен вклад каждого участника в проект.
На моей практике польза аналитиков сводилась к написанию необходимых бумажек и тестированию.
Один мой знакомый сказал по этому поводу «аналитики существуют, потому что не всем тестерам можно дать бирку ПМа».
Очень часто бывает, что заказчик говорит «хочу Х», но грамотный внедренец поймет, что можно сделать Y, с тем же результатом и меньшими затратами\рисками. А вот аналитик без знаний уровня внедренца не поймет.
У нас явно различаются представления о понятиях «внедренец». Если бы вы сказали архитектор, то согласился бы. Оценка сложности реализации того или иного требования в зависимости от варианта реализации — компетенция архитектора, не внедренца. Аналитик может знать это исходя из опыта, а не потому что он знает продукт ровно настолько, насколько знает архитектор или внедренец.
А дальше получается так: аналитики все записывает приносит команде, команда нахоит 100500 таких требований, которые можно слегка поменять и снизить риски и затраты. Нужно обсуждать это с заказчиком. А как? Снова ехать, уже расширенным составом, вместе с внедренцами? А зачем аналитик тогда катался в первый раз? Вот и получается что сбор требований == выстраивание ожиданий.
Дальше получается на самом деле так, что в одной из итераций обсуждения принимает участие архитектор и это нормально, это на самом деле «по книжке» (по методологии) верно. Понимаю, что всем нам хочется все с оптимизировать и видеть в одном ресурсе все качества, но это больше исключение и везение, нежели практика. Причем когда Вы говорите о такой детализации (100500 требований) это уже явно не пресейл, а проект в стадии «проектирование»/«анализ» и т.п.
На практике пресейл это и есть выстраивание ожиданий и создание конкурентных преимуществ.
Странное определение пресейла. Как минимум непонятно что значит в данном контексте «создавать» к объекту «конкурентные преимущества». Конкурентные преимущества продукта или услуги не могут создаваться в рамках сделки, они могут быть в рамках сделки лишь предъявлены. С «выстраиванием ожиданий» тоже, если честно не все понятно.
На моей практике польза аналитиков сводилась к написанию необходимых бумажек и тестированию.
Не сомневаюсь. О чем это говорит? Лишь только о том, что в Вашей практике аналитики выделенные не сильно полезны, либо Вы ошибаетесь в своей оценке.
Один мой знакомый сказал по этому поводу «аналитики существуют, потому что не всем тестерам можно дать бирку ПМа».
Типичный взгляд архитектора/программиста/случайная роль/, которому чем-то не угодили аналитики. :)
Я-то с вами соглашусь, а большинство аналитиков — нет :) Аналитиков, способных полностью заменить инженера или разработчика в проекте внедрения, не так много. И ЗП у них соответствующая :)
Согласен, если бизнес-модель позволяет утилизировать БА в роли инженера внедрения, инженера-программиста, специалиста сопровождения (зачастую это по рынку менее «дорогие» роли) — эффект от плотного знакомства с продуктом (платформой) может действительно быть полезным — как минимум снижение рисков в дальнейшей разработке. Здесь правда есть обратная сторона: классическая задача БА сформулировать требования, реализация которых позволит достичь целей внедрения и по-хорошему, цели и требования должны ставится условно без оглядки на технологию и продукт (это уже потом идет «анализ покрытия№ функционалом сформированных требований и т.п.), так как клиенту по большому счету должно быть все равно, молотком конкретно какой модели строят нужный ему дом исполнители, которым он доверился (раз пошел на сделку). Заказчику нужен результат в виде польз, а не состав продуктов и их возможностей. Отсюда напрашивается вывод: если при формулировании требований БА чрезмерно опирается на возможности платформы/продукта, он по факту решает задачу вида „как же приблизить требования и цели к тому что моя команда сможет реализовать с наименьшими затратами“, а не свою классическую задачу „описание требований, позволяющих достичь целей проекта, которое (описание) позволит разработать и предложить архитектуру решения, которые покрывает эти требования полностью (что маловероятно), либо в достаточно большой степени при адекватных затратах (либо признать задачу невыполнимой и отказаться)“. Соответственно сильный уклон в первый вариант (натягивание „целей“ на базовые возможности продукта) грозит тем, что цели будут достигнуты не полностью, результат не будет соответствовать ожиданиям заказчика, т.е. проект нельзя считать полностью успешным. Хотя с точки зрения бизнеса „внедренца“, в краткосрочной перспективе „малозатратность“ реализации естественно — только в плюс, но в среднесрочной грозит отсутствием действительно хорошего подтвержденного „референса“ и портфолио, если „классическая“ составляющая не соблюдена.
Что касается „дыр в ТЗ“, а здесь имеется ввиду вероятно документ в терминах объектов платформы/продукта (т.е. не концепция, не устав, не функциональные требования), то его составление — коллективная задача БА и архитектора, задача последнего как раз минимизировать количество этих „дыр“, читай рисков реализации.
Что касается „дыр в ТЗ“, а здесь имеется ввиду вероятно документ в терминах объектов платформы/продукта (т.е. не концепция, не устав, не функциональные требования), то его составление — коллективная задача БА и архитектора, задача последнего как раз минимизировать количество этих „дыр“, читай рисков реализации.
К сожалению, зачастую компании специализируются на внедрении определенного ПО, а не программ определенного «класса». Т.е. вы не просто внедряете CRM, а вы внедряете конкретно «Microsoft Dynamics CRM». Компаний, продающих чистый консалтинг без привязки к конкретному ПО, очень мало, и рынок для таких компаний очень ограничен. Поэтому в такой ситуации аналитик должен осознавать, что требования заказчика реализуемы на данной конкретной платформе.
Ну и плюс к этому. Все современные системы более-менее похожи внутри одного класса. Т.е. если взять 3 крупных СЭД, то предоставляемый ими функционал почти идентичен. И ситуации, что заказчик требует что-то такое, что нельзя сделать на этой платформе, но можно на другой, почти не возникает.
Ну и плюс к этому. Все современные системы более-менее похожи внутри одного класса. Т.е. если взять 3 крупных СЭД, то предоставляемый ими функционал почти идентичен. И ситуации, что заказчик требует что-то такое, что нельзя сделать на этой платформе, но можно на другой, почти не возникает.
Да, верно. За консалтинг платить не привыкли, это факт. Но и мультиплатформенных интеграторов тоже достаточно. И как раз БА, РП (и возможно архитектор частично) — это те специальности, которые проще всего переключаются от проектов на одной платформе к проекту на другой. Что делает их более «утилизационноспособными»
Соглашусь с оговоркой: все современные системы похожи внутри одного класса и относительно близкого ценового сегмента и ниши.
Все современные системы более-менее похожи внутри одного класса
Соглашусь с оговоркой: все современные системы похожи внутри одного класса и относительно близкого ценового сегмента и ниши.
Коллеги, профстандарт нам в помощь.
От себя два слова. ИМХО, бизнес аналитик должен разбираться в предметной области и бизнес-процессах заказчика, а системный аналитик в информационной системе и технологиях. По мне, это две стороны одной медали, одно не может гармонично развиваться без другого.
От себя два слова. ИМХО, бизнес аналитик должен разбираться в предметной области и бизнес-процессах заказчика, а системный аналитик в информационной системе и технологиях. По мне, это две стороны одной медали, одно не может гармонично развиваться без другого.
Станислав,
за ссылочку огромное спасибо! Относительно профстандарта (октябрь 2014?, совсем недавно?) — безусловно часть вопросов снимает, остается только жалеть, что размещать в вакансиях такой перечень — бесперспективно, так как вряд ли кто то откликнется на такой серьезный перечень не запросив за это баснословную сумму :). В регионах это особенно актуально. С точки зрения систематизации требований и понимания подхода к возможному выращиванию — незаменимо. И сам ресурс школы, спасибо за то, что познакомили. Это для меня открытие, что такое в принципе существовало.
На самом деле давно был знаком с разделением понятий и ролей на бизнес-аналитика и системного аналитика. Вся проблема в том, что в существующих рыночных условия бить таким образом эти роли, формируя в команде под эти цели как минимум двух разных людей, учитывая проблемы утилизации и прочие накладны, это грозит поставить под сомнения экономическую эффективность такой модели. Если проект не имеет каких то запредельных масштабов, а особенно если из раза в раз проекты в одной и той же предметной плоскости, имхо, это должен быть всегда один человек в двух ролях. Либо часть роли системного аналитика должна ложится на архитектора.
за ссылочку огромное спасибо! Относительно профстандарта (октябрь 2014?, совсем недавно?) — безусловно часть вопросов снимает, остается только жалеть, что размещать в вакансиях такой перечень — бесперспективно, так как вряд ли кто то откликнется на такой серьезный перечень не запросив за это баснословную сумму :). В регионах это особенно актуально. С точки зрения систематизации требований и понимания подхода к возможному выращиванию — незаменимо. И сам ресурс школы, спасибо за то, что познакомили. Это для меня открытие, что такое в принципе существовало.
На самом деле давно был знаком с разделением понятий и ролей на бизнес-аналитика и системного аналитика. Вся проблема в том, что в существующих рыночных условия бить таким образом эти роли, формируя в команде под эти цели как минимум двух разных людей, учитывая проблемы утилизации и прочие накладны, это грозит поставить под сомнения экономическую эффективность такой модели. Если проект не имеет каких то запредельных масштабов, а особенно если из раза в раз проекты в одной и той же предметной плоскости, имхо, это должен быть всегда один человек в двух ролях. Либо часть роли системного аналитика должна ложится на архитектора.
В профстандарте написано, что на эту позицию должен претендовать человек со средним техническим образованием Ж8-/
Не знаю, как обстоят дела в области системной интеграции, но в случае с аутсорсингом модель «бизнес-аналитик на стороне клиента и системный аналитик на стороне исполнителя» весьма работоспособна.
Вообще чем дальше в лес, тем больше ролей и позиций (должностей), обобщенно называемых бизнес-аналитиками, мы находим.
В крупных компаниях есть и requirements engineers, и чистые business analysts, и выделенные system analysts, и даже некие business systems analysts. Еще очень близкая категория business relationship managers, и любопытные business systems consultants.
И явно я еще кого-то забыл (это те, кто у нас встречаются). К каждой из категорий в разных компаниях применяют совершенно разные требования к навыкам и ключевым компетенциям. Но с общими моментами, отмеченными в статье, я согласен.
В крупных компаниях есть и requirements engineers, и чистые business analysts, и выделенные system analysts, и даже некие business systems analysts. Еще очень близкая категория business relationship managers, и любопытные business systems consultants.
И явно я еще кого-то забыл (это те, кто у нас встречаются). К каждой из категорий в разных компаниях применяют совершенно разные требования к навыкам и ключевым компетенциям. Но с общими моментами, отмеченными в статье, я согласен.
Сложно оценивать необходимость такого разнообразия и деления в общем случае. По умолчанию, это вызывает скепсис, что естественно, с учетом конкретного опыта — все таки самый крупный мой проект был масштаба порядка 15000 человеко-часов, 1,5 года. Много это или не очень, не мне судить, но мне хватило :)
И даже в этом проекте не было очевидной необходимости разделять разные «аналитические» роли между разными людьми, одного ресурса с точки зрения экономической целесообразности было достаточно, это было по силам. Понятно, что в таком случае вынужденная замена такой роли в таком проекте — смерти подобно, но не вижу, насколько сильно бы ситуацию спасло подобное деление. Естественно риски меньше, но, имхо, не значительно, относительно гораздо больших накладных и издержек взаимодействия.
Но не спорю, что при более плотном изучении процесса в компании с потоком действительно крупных проектов, не изменил бы своего мнения.
Спасибо за комментарий.
И даже в этом проекте не было очевидной необходимости разделять разные «аналитические» роли между разными людьми, одного ресурса с точки зрения экономической целесообразности было достаточно, это было по силам. Понятно, что в таком случае вынужденная замена такой роли в таком проекте — смерти подобно, но не вижу, насколько сильно бы ситуацию спасло подобное деление. Естественно риски меньше, но, имхо, не значительно, относительно гораздо больших накладных и издержек взаимодействия.
Но не спорю, что при более плотном изучении процесса в компании с потоком действительно крупных проектов, не изменил бы своего мнения.
Спасибо за комментарий.
Так и не увидел перечня «ключевых качеств» в проверяемом виде.
Судя по тексту БА это ПМ без функций планирования и управления всей командой. На практике очень часто вижу, что аналитики это и есть недо-ПМы, которые, кстати, в ПМы растут очень быстро. Практическая ценность аналитиков в чистом виде крайне мала, те же функции спокойно распределяются между ПМом и архитектором (главным инженером проекта).
Судя по тексту БА это ПМ без функций планирования и управления всей командой. На практике очень часто вижу, что аналитики это и есть недо-ПМы, которые, кстати, в ПМы растут очень быстро. Практическая ценность аналитиков в чистом виде крайне мала, те же функции спокойно распределяются между ПМом и архитектором (главным инженером проекта).
Стас, ты прав, конечно, в своём последнем комментарии.
Но, IMHO, проблема в том, что и архитекторы встречаются в проектах крайне редко.
Вот и получается, что вместо ПМ+архитектор в реальности существуют ПМ+аналитик, а то и аналитик в роли ПМ+аналитик+архитектор (иногда и тестер до кучи).
Ну, по крайней мере, мне так почему-то часто вокруг встречается.
Но, IMHO, проблема в том, что и архитекторы встречаются в проектах крайне редко.
Вот и получается, что вместо ПМ+архитектор в реальности существуют ПМ+аналитик, а то и аналитик в роли ПМ+аналитик+архитектор (иногда и тестер до кучи).
Ну, по крайней мере, мне так почему-то часто вокруг встречается.
Коллеги, все хорошо, пока проекты относительно небольшие. А представьте себе некоего «мастадонта» на десятки тысяч человеко-часов, а то и сотни. Я не представляю себе, что будет после такого проекта со специалистом, который был в нем ПМ+аналитик+архитектор, и даже ПМ+аналитик.
У нас какие разные реальности. Без технической экспертизы любой сложный проект сделать нельзя. Простой дешевле просто аутсорсить. Так вот на сложном проекте ключевая фигура — ГИП (архитектор). По большей части именно от него зависит успех или провал. С хорошим ГИПом на небольшом проекте и ПМ не нужен, не то что архитектор.
Если ГИП слабенький, то ситуацию может вытянуть ПМ, правильно выстраивая ожидания заказчика. А вот какая польза от введения аналитика в эту историю — мне неясно.
Видел пару раз как ГИПов пытались заменить аналитиками. Аналитики, как казалось, тупо дешевле хороших программистов. Выходило кране плачевно. Качество было очень низкое, сроки постоянно просрачивались.
Если ГИП слабенький, то ситуацию может вытянуть ПМ, правильно выстраивая ожидания заказчика. А вот какая польза от введения аналитика в эту историю — мне неясно.
Видел пару раз как ГИПов пытались заменить аналитиками. Аналитики, как казалось, тупо дешевле хороших программистов. Выходило кране плачевно. Качество было очень низкое, сроки постоянно просрачивались.
Про разные реальности — в точку! Наверняка у каждого из нас деятельность со своими особенностями и это, естественно, может порождать разные мнения и оценку. Но позвольте в корне не согласится с утверждением:
Все же в этом случае ключевая фигура не одна. Ключевая все же команда и ее способность взаимодействия. Естественно, все зависит от того, как понимать в данном контексте «сложный проект». Более или менее универсальный подход к этому вопросу — размер проекта, в моем понимания это, как писал где то ранее десятки тысяч человеко-часов. Развивая мысль, если кто-то из команды слабенький, слаба сама команда. Если кто-то в состоянии вытянуть за другого что-то в проекте и приходится вообще что-то вытягивать, то это означает ровно то, что команда неэффективно (ну либо в процессе становления, все когда-то были новичками). Как минимум, того, за кого что-то вытягивают в ней не должно быть и она просто избыточна, т.е. неэффективна. Каждый реально «лишний» человек в группе — серьезная обуза, которая мешает, так как порождается ненужное взаимодействие. С чем, судя по Вашей позиции, Вы и так согласны.
Несмотря на то, что не сомневаюсь в существовании таких примеров, вынужден констатировать что бывают зеркальные примеры: проект без ярко выраженной роли аналитика (пусть даже совмещенно) — также рискует быть провальным. Это свидетельствует только о том, что и Вы и я видели разные проекты.
Так вот на сложном проекте ключевая фигура — ГИП (архитектор)
Все же в этом случае ключевая фигура не одна. Ключевая все же команда и ее способность взаимодействия. Естественно, все зависит от того, как понимать в данном контексте «сложный проект». Более или менее универсальный подход к этому вопросу — размер проекта, в моем понимания это, как писал где то ранее десятки тысяч человеко-часов. Развивая мысль, если кто-то из команды слабенький, слаба сама команда. Если кто-то в состоянии вытянуть за другого что-то в проекте и приходится вообще что-то вытягивать, то это означает ровно то, что команда неэффективно (ну либо в процессе становления, все когда-то были новичками). Как минимум, того, за кого что-то вытягивают в ней не должно быть и она просто избыточна, т.е. неэффективна. Каждый реально «лишний» человек в группе — серьезная обуза, которая мешает, так как порождается ненужное взаимодействие. С чем, судя по Вашей позиции, Вы и так согласны.
Видел пару раз как ГИПов пытались заменить аналитиками. Аналитики, как казалось, тупо дешевле хороших программистов. Выходило кране плачевно. Качество было очень низкое, сроки постоянно просрачивались.
Несмотря на то, что не сомневаюсь в существовании таких примеров, вынужден констатировать что бывают зеркальные примеры: проект без ярко выраженной роли аналитика (пусть даже совмещенно) — также рискует быть провальным. Это свидетельствует только о том, что и Вы и я видели разные проекты.
Ключевая все же команда и ее способность взаимодействия.
Эта фраза ни о чем. Команда состоит из людей, которые, внезапно, оказывают разное влияние на проект. Обычно в команде есть ключевые игроки и те, которые «на подсосе». Вторых можно безболезненно менять или убирать, если с проекта уйдет один из ключевых игроков, то это окажет сильное влияние.
Как я выше говорил — наибольшее влияние на проект оказывает ГИП (архитектор). Если он достаточно квалифицирован и клиентоориентирован, то надобности в аналитиках нет. Они становятся «реально лишним».
Получается экономически невыгодно иметь аналитика и архитектора, лучше взять одного архитектора, который понимает проблемы заказчика и умеет разговаривать.
без ярко выраженной роли аналитика (пусть даже совмещенно) — также рискует быть провальным
Это только в случае очень слабых инженеров.
В общем виде Вы не правы. Команда это главное, и весь Ваш первый абзац — вы по сути описываете качство состава и качество взаимодействия внутри, успев при этом в пылу дискуссии назвать все это «ни о чем». В конкретике — возможно. Раз уж раскрутились, скажите, о какого рода проектах Вы говорите, особенно утверждая что архитектор единственный ключевой игрок. Имеется ввиду что внедряете, какой масштаб.
Вы упорно не хотите принимать во внимание масштаб проекта. Высказывание, что выгоднее держать одного человека вместо двух, при условии что он справится, через чур очевидно.
Исходя из Вашей логики, слаб тот инженер, кто не умеет осуществлять сбор и анализ требований, оценивать «эффективность» и отдачу от реализации этих требований для бизнеса заказчика и много другое прочее. Ну это же абсурд! Это не в компетенции инженеров. И на основании отсутствия этих компетенций называть инженера слабым, все равно что называть слона ущербным, потому что он не умеет летать.
Получается экономически невыгодно иметь аналитика и архитектора, лучше взять одного архитектора, который понимает проблемы заказчика и умеет разговаривать.
Вы упорно не хотите принимать во внимание масштаб проекта. Высказывание, что выгоднее держать одного человека вместо двух, при условии что он справится, через чур очевидно.
Это только в случае очень слабых инженеров.
Исходя из Вашей логики, слаб тот инженер, кто не умеет осуществлять сбор и анализ требований, оценивать «эффективность» и отдачу от реализации этих требований для бизнеса заказчика и много другое прочее. Ну это же абсурд! Это не в компетенции инженеров. И на основании отсутствия этих компетенций называть инженера слабым, все равно что называть слона ущербным, потому что он не умеет летать.
Вы упорно не хотите принимать во внимание масштаб проекта. Высказывание, что выгоднее держать одного человека вместо двух, при условии что он справится, через чур очевидно.
Ну давайте посчитаем. Человек работает 200 дней в году или 1600 часов. На 10к часов это примерно 6 человек на год. То есть примерно 3 инженера, один тестер, один тимлид\ГИП\архитектор. и всякие ПМы\техписы и прочие прихвостни, которые на проекте работают частично. Как бы не такой крупный проект.
А что если проект крупнее? Например 30к часов. Делать три года конечно никто не будет. Поэтому имеет смысл поделить на 3 команды, каждая занимается свои направлением. В каждом направлении будет свой тимлид. Возможно будет еще один технический специалист (ГИП\архитектор), который будет разруливать технические вопросы между командами. Он же может и заниматься первичным сбором и уточнением требований, привлекая тимлида команды для конкретики.
Совсем без архитектора на таком проекте нельзя, ибо каждая команда убежит в свою сторону и появится много разных решений одних и тех же проблем. А вот без аналитика на таком проекте прожить можно, да и ничего страшного не случится.
А если проект еще больше, например 100К часов — а таки проектов в реальности не бывает. Если посчитать в деньгах, при самой низкой ставке в 1200р\час (в реальности в 2-3 раза выше), то получается бюджет проекта в 120М рублей. Даже SAP с лицензиями дешевле обходится.
Либо я потерял нить рассуждений. либо Вы куда-то не туда ушли. Смысл и назначение этого комментария — загадка. Что Вы пытались этим доказать?
Вы это сказали с самого начала, а сейчас снова повторили, и снова ни одного аргумента. Просто утверждение, без подтверждения, никакой логической цепочки которая привела бы к такому выводу.
100к часов — еще как бывает. 120М рублей даже в России, не редкость. Даже за СЭД, даже за СЭД на базе «российской платформы».
А вот без аналитика на таком проекте прожить можно, да и ничего страшного не случится.
Вы это сказали с самого начала, а сейчас снова повторили, и снова ни одного аргумента. Просто утверждение, без подтверждения, никакой логической цепочки которая привела бы к такому выводу.
100к часов — еще как бывает. 120М рублей даже в России, не редкость. Даже за СЭД, даже за СЭД на базе «российской платформы».
Вы же сами согласились, что при грамотном ГИПе аналитик не нужен на небольшом проекте. А я вам привел как эта ситуация масштабируется даже на большие проекты, и аналитики все также не нужны.
Все такие закупки будут проходить через открытые конкурсы. Киньте ссылку.
100к часов — еще как бывает. 120М рублей даже в России, не редкость. Даже за СЭД, даже за СЭД на базе «российской платформы».
Все такие закупки будут проходить через открытые конкурсы. Киньте ссылку.
Вы же сами согласились, что при грамотном ГИПе аналитик не нужен на небольшом проекте. А я вам привел как эта ситуация масштабируется даже на большие проекты, и аналитики все также не нужны.
Конечно, согласился. Только она не может так масштабироваться из-за ограничения одного ресурса. Как только одного ресурса (ГИП) будет мало, вы будете привлекать еще одного универсального ГИПА-БА, или все таки БА, который нагрузку аналитики с Вашего Гипа снимет? Я думаю второй вариант естественно выгоднее.
Все такие закупки будут проходить через открытые конкурсы. Киньте ссылку.
С чего Вы взяли что все и именно через открытые? Но не суть, площадок много, найти при желании можно. Совсем недавно только мелькало пару конкурсов для (!) областной администрации в регионе (Екатеринбург по-моему) по 40-50 млн каждый. Представьте себе, аналог в МСК, МСО, или Спб. Если интересно, можете оценить масштаб проектов в Сбере, Втб. Сумм Вы в открытом доступе не найдете, но придется поверить на слово — в текущих ценах порядок был бы за 100млн. Почитайте описание, когда речь идет о 30000-50000 одновременных пользователях, как думаете, сколько стоит такой проект?
Если одного ГИПа мало, то у него появляются подчиненные, которые работают по своим направлениям со своими командами. По сути нет никаких проблем в создании иерархии архитекторов. БА оказывается нужен когда ГИП (или архитектор) не может пообщаться с заказником и понять что он хочет. Но в этом случае проще качать гипа (архиектора), а не брать аналитика.
С того что я знаю как работает механизм закупок в крупных компаниях ;)
Я продавал проекты в сбере и ВТБ. Увы, там далеко не сотни миллионов. По сути за софт даже крупные организации не готовы платить, ибо эти затраты не капитализируются. Огромные суммы за софт есть в госах, но это в основном распил. Там конечно нужны аналитики, чтобы имитировать бурную деятельность.
Кстати в ВТБ все что дороже 3 млн идет через конкурс — www.vtb.ru/group/purchases/
Да и торги в Сбере примерно по такой же системе идут — www.sberbank.ru/moscow/ru/fpartners/purchase/notification/
Таких компаний в России просто нет. Даже Ростелеком с 150к сотрудников имеет активных пользователе на систему менее 10к одновременных. В Мегафоне (30к сотрудников) корпоративный портал имеет посещаемость около 6к пользователей в день.
Так что вы уже пошли фантазировать, большинство проектов на два порядка меньше чем вам кажется.
С чего Вы взяли что все и именно через открытые?
С того что я знаю как работает механизм закупок в крупных компаниях ;)
Я продавал проекты в сбере и ВТБ. Увы, там далеко не сотни миллионов. По сути за софт даже крупные организации не готовы платить, ибо эти затраты не капитализируются. Огромные суммы за софт есть в госах, но это в основном распил. Там конечно нужны аналитики, чтобы имитировать бурную деятельность.
Кстати в ВТБ все что дороже 3 млн идет через конкурс — www.vtb.ru/group/purchases/
Да и торги в Сбере примерно по такой же системе идут — www.sberbank.ru/moscow/ru/fpartners/purchase/notification/
Почитайте описание, когда речь идет о 30000-50000 одновременных пользователях
Таких компаний в России просто нет. Даже Ростелеком с 150к сотрудников имеет активных пользователе на систему менее 10к одновременных. В Мегафоне (30к сотрудников) корпоративный портал имеет посещаемость около 6к пользователей в день.
Так что вы уже пошли фантазировать, большинство проектов на два порядка меньше чем вам кажется.
С того что я знаю как работает механизм закупок в крупных компаниях ;)
Полюс, Норникель, МТС — это только те, приглашения об участии в закрытых конкурсах которых видел лично сам.
Я продавал проекты в сбере и ВТБ. Увы, там далеко не сотни миллионов.
Значит плохо продавали :). Вы же сами потрудились и дали ссылку. Я за две минуты нашел у сбера два относительно нестарых запроса на относительно «частные» задачи класса ECM за 50 и за 60 млн. А представьте себе относительно комплексную задачу?
Таких компаний в России просто нет. Даже Ростелеком с 150к сотрудников имеет активных пользователе на систему менее 10к одновременных. В Мегафоне (30к сотрудников) корпоративный портал имеет посещаемость около 6к пользователей в день.
Так что вы уже пошли фантазировать, большинство проектов на два порядка меньше чем вам кажется.
Прежде чем совершенно бездарно упрекать в «фантазировании», держите СЭД в Сбербанке, держите СЭД в ВТБ. А это только у DocsVision. Я уже не говорю про РЖД, Роснефть (если они наконец решат унифицироваться на одной платформе), Газпром, Росатом, Ростех, и реально огромные госы (типа МВД, ФМС, ФНС, министерства), но там конечно своя кухня. Из частников — все добытчики, там конечно поменьше, но 10-15 тыс пользователей — не так мало, не единицы. Если это проекты на Документуме — то это не одна сотня миллионов. Вы изначально говорили еще про SAP в контексте «даже Sap столько не стоит»? Одна из известных мне компаний сейчас внедряет SAP, сумма сделки свыше 100 млн. (штат 2000 человек, частный бизнес).
Если Вы чего то не знаете, это не значит, что этого нет. Если Вы утверждаете, что нет чего-то, о чем доподлинно не знаете, значит Вы просто заблуждаетесь, как и во многом другом, о чем успели, видимо, не подумав, а раз точно не знаете, даже не «погуглив», написать.
Исходя из Вашей логики, слаб тот инженер, кто не умеет осуществлять сбор и анализ требований, оценивать «эффективность» и отдачу от реализации этих требований для бизнеса заказчика и много другое прочее. Ну это же абсурд! Это не в компетенции инженеров. И на основании отсутствия этих компетенций называть инженера слабым, все равно что называть слона ущербным, потому что он не умеет летать.
Совсем не абсурд. Только инженер заранее представляет сложности реализации, поддержки и использования функционала. Без понимания стоимости ни о какой эффективности не может идти речи. Поэтому аналитики в этой проблеме бессильны.
А инженер, который дорос до архитектора (не просто получил бирку), уже достаточно понимает потребности бизнеса и видит ситуацию чуть шире, чем средний бизнес-заказчик. Если не архитектор не обладает таким навыком, то ему аналитик может помочь. Но в этом случае я бы прокачивал архитектора, а не брал еще одного человека.
А вообще каждый инженер должен понимать решаемую проблему, без этого успеха проекта не будет. Донести решаемые проблемы, измеримые параметры решения должен ПМ, ибо именно он за решения и параметры отвечает. Если инженер сопротивляется («дайте ТЗ и я буду кодить по ТЗ»), то его надо просто уволить.
Все верно.
За исключением:
В большей степени без понимания «величины» пользы не может идти речи об эффективности. И про стоимость тоже верно. Но стоимость можно и спросить, прикинуть. Важен порядок а конкретная цифра.
Т.е. уже по факту не инженер, а именно архитектор. Т.е. изначально вы хотели сказать не слабый инженер, а слабый архитектор?
Хорошее может быть решение. Но когда много проектов, они большие, загрузка высокая, то разумно же использовать архитектора как архитектора, а Ба как БА? Когда одного на всех не хватает? :)
За исключением:
Без понимания стоимости ни о какой эффективности не может идти речи
В большей степени без понимания «величины» пользы не может идти речи об эффективности. И про стоимость тоже верно. Но стоимость можно и спросить, прикинуть. Важен порядок а конкретная цифра.
А инженер, который дорос до архитектора (не просто получил бирку), уже достаточно понимает потребности бизнеса и видит ситуацию чуть шире, чем средний бизнес-заказчик.
Т.е. уже по факту не инженер, а именно архитектор. Т.е. изначально вы хотели сказать не слабый инженер, а слабый архитектор?
Но в этом случае я бы прокачивал архитектора, а не брал еще одного человека.
Хорошее может быть решение. Но когда много проектов, они большие, загрузка высокая, то разумно же использовать архитектора как архитектора, а Ба как БА? Когда одного на всех не хватает? :)
Да, соглашусь что очень часто бывает уместно вместо двух человек держать одного, закрывающего две роли. Но это, согласитесь, означает ровно то, что роль «размазана» между теми же ПМ-ом и архитектором, но не в коем случае не бесполезна, верно? Кстати, можно же ставить зеркально: почему бы тогда не размазать роль того же ПМ-а между аналитиком и архитектором? Про то, что ценность аналитиков в чистом виде мала (если согласно предыдущему утверждению имеется ввиду именно выделение отдельного ресурса под эту роль и только под нее), соглашусь, но наверняка это сильно зависит от размера проекта и их количества (проектов) в компании.
Про замечание о перечне в проверяемом виде, извините, к сожалению не понял, что Вы под этим подразумеваете.
Про замечание о перечне в проверяемом виде, извините, к сожалению не понял, что Вы под этим подразумеваете.
Когда прочитал заголовок статьи думал что в ней будет таки список этих качеств и можно взять человека и быстро проверить обладает ли он этими качествами. А не у видел вообще ничего в этом направлении. Пространные рассуждения и немного личного опыта,
Что касается ролей, то вопрос не в названии, а в функциях. Человек, который занимается общим управлением проектом (сроки, бюджет, приемка) традиционно называется ПМом, человек отвечающий за техническую реализацию называется архитектором (ГИПом). Остаются еще функции: выявление потребностей и управление коммуникациями. Так вот потребность еще одного человека для этих функций крайне мала. Потому что ГИП в любом случае будет выяснять потребности, а ПМ будет управлять коммуникациями.
Что касается ролей, то вопрос не в названии, а в функциях. Человек, который занимается общим управлением проектом (сроки, бюджет, приемка) традиционно называется ПМом, человек отвечающий за техническую реализацию называется архитектором (ГИПом). Остаются еще функции: выявление потребностей и управление коммуникациями. Так вот потребность еще одного человека для этих функций крайне мала. Потому что ГИП в любом случае будет выяснять потребности, а ПМ будет управлять коммуникациями.
Вероятно, Вы правы, что название не в полной мере дает представления о реальном содержании. Пытался смягчить «кавычками», видимо не сильно успешно. Безусловно, рассуждения не детализированы и не формализованы настолько, чтобы можно было предъявить без изменения в качестве «чего-то документального». Но и задача такая не стояла. Выше по комментариям привели новенький «профстандарт», там действительно конкретика и действительно полезна, имхо. Но, согласитесь, в качестве, статьи было бы неуместно. Поэтому «пространные рассуждения» — как минимум, это сугубо Ваша точка зрения, причем возможно (подчёркиваю, возможно) в той сфере, о который лично Вы имеете не настолько много представлений, как думаете. А судите исходя лишь сугубо из того, что с чем лично Вам приходилось иметь дело. Что, как минимум, не объективно.
Так роль и характеризуется именно набором функций, это одно из альтернативных определений.
В Вашей практике возможно, но в общем случае, найдется очень много несогласных с этой точкой зрения (например, авторы всех более менее известных методологий внедрения бизнес-приложений). Как минимум, вы не делает поправку на величину проекта. Есть не один пример проектов, в которых была целая группа аналитиков и один архитектор и один ПМ. Так что вся дискуссия основана только на том, в какой-то сфере возможно всегда не нужен выделенный БА — не сомневаюсь что такие сферы существуют даже для крупного масштаба (проекты, более инфраструктурного плана, нежели бизнесового: Exchange, SharePoint (как интранет портал), либо с очень узкой спецификой — например, для нужд ИТ-департамента). Поэтому вероятно и выходим за рамки конструктива.
Что касается ролей, то вопрос не в названии, а в функциях
Так роль и характеризуется именно набором функций, это одно из альтернативных определений.
Так вот потребность еще одного человека для этих функций крайне мала
В Вашей практике возможно, но в общем случае, найдется очень много несогласных с этой точкой зрения (например, авторы всех более менее известных методологий внедрения бизнес-приложений). Как минимум, вы не делает поправку на величину проекта. Есть не один пример проектов, в которых была целая группа аналитиков и один архитектор и один ПМ. Так что вся дискуссия основана только на том, в какой-то сфере возможно всегда не нужен выделенный БА — не сомневаюсь что такие сферы существуют даже для крупного масштаба (проекты, более инфраструктурного плана, нежели бизнесового: Exchange, SharePoint (как интранет портал), либо с очень узкой спецификой — например, для нужд ИТ-департамента). Поэтому вероятно и выходим за рамки конструктива.
Но и задача такая не стояла
А какая задача стояла? Может во вступлении опишите, чтобы не вводить людей в заблуждение.
возможно (подчёркиваю, возможно) в той сфере, о который лично Вы имеете не настолько много представлений
Для справки — СЭДами занимался с 2005 года и только пару лет как бросил, но все еще слежу за рынком.
найдется очень много несогласных с этой точкой зрения
Я понимаю, что аналитики будут против снижения важности этой роли ;)
Есть не один пример проектов, в которых была целая группа аналитиков и один архитектор и один ПМ.
А сколько было тестеров и техписателей? Уверен, что очень мало. Это значит что аналитики по факту выполняли функции этих самых тестеров и техписов.
Для анализа ситуации стоит погрузиться в историю. Лет 30 назад не было никаких аналитиков. Вообще такая роль на проектах начала зарождаться в начале 90-х, когда высокий спрос на автоматизацию породил толпы низкоквалифицированных разработчиков. Тогда появилась идея, что специально обученные люди будут писать ТЗ для разработчиков.
Но постепенно средства разработки начали усложняться, появились готовые платформы и внезапно оказалось, что нужен таки эксперт в этой самой платформе, чтобы корректно сформулировать задание. Тогда аналитики поделились на системных (которые знают технический аспект решения), и бизнес-аналитиков, которые должны разбираться с бизнес-процессами. Это началось примерно в 2000 году, до России докатилось лет через пять.
А дальше получилась очень интересная картина. Готовые платформы затачивались под вполне определенные бизнес-процессы, поэтому почти полностью отпала потребность в анализе БП в проектах автоматизации бизнеса. А при разработке продуктов роль бизнес-аналитика превратилась в product manager, который не просто задает вопросы, а собственно придумывает проблему которую решает.
Роль системного аналитика практически слилась с ролью ГИПа (архитектора) по причине того, что описать как сделать нечто на современной платформе это примерно тоже самое что сделать это.
Армия аналитиков при этом пополняется техписателями, тестерами, недо-ПМами, внедренцами и даже UX-дизайнерами. Хотя последнее время UX-более модное направление и аналитики начинают медленно переползать в категорию UX.
Понеслось :) Жаль что Вы комментируете только фразы из контекста, сложно повторятся в ответе, так как предыдущее описание было достаточно полно.
Во вступлении все описано, понимаю что интро читать не всегда интересно — там то конкретики совсем мало :)
Не только аналитики против, я как РП и управленец бизнеса в целом с Вами не согласен. Не говоря уже, повторюсь, о всех методология, которые с Вашей легкой руки предлагается отправить на свалку за ненадобностью.
Команда порядка 40 человек на один проект. Всех узких ролей было предостаточно. Просто Вы опять таки упорно игнорируете масштабы проектов, которые бывают. И 40 человек, имхо, мало на проект в структуре штатной численностью свыше 0,5 млн человек.
За экскурс в историю, спасибо. На самом деле, без сарказма. Только я убежден что качество конечных решений, качество польз от них как и качество бизнеса в целом растет. Это закон рынка, он за пределами гос.заказчиков, более или менее конкурентен и не допустил бы (рынок), чтобы новые походы в этой направлении были менее эффективные чем старые, они бы просто не прижились.
Также Ваш оценка истории развития аналогична по тону рассуждениям старшего поколения о том, что молодежь якобы нынче не та (читай «хуже»). При этом не утверждаю конечно, что старшее поколение не право, проблема в том, что до них все тоже самое говорили и их предки, дискутировать здесь бесполезно, но смысл понятен, каждый при своем мнении.
Вы опять не учитываете возможный масштаб — это раз. И как будто не понимаете иной ценности документирования, кроме как инструкций к действию по реализации. Целей у описания (документирования) — множество. Это два.
На мой взгляд, Вы смешали в одну кучу понятие платформы и понятие коробки/готового решения. Что в корне неверно.
Я согласен с целом с мнением, что на рынке много «неэффективностей» что существенно определяет фон и отношение к этой сфере. Но есть большая разница в том, что же критиковать — конкретную реальную ситуацию, пусть массовую, или критиковать подход и методологию. Методология — это общее, примеры из практике — это частное. Критикуя частное, возможно аргументированно и справедливо, Вы почему то автоматом распространяете эту критику и выводы на общее. Это не логично.
Во вступлении все описано, понимаю что интро читать не всегда интересно — там то конкретики совсем мало :)
Не только аналитики против, я как РП и управленец бизнеса в целом с Вами не согласен. Не говоря уже, повторюсь, о всех методология, которые с Вашей легкой руки предлагается отправить на свалку за ненадобностью.
А сколько было тестеров и техписателей? Уверен, что очень мало. Это значит что аналитики по факту выполняли функции этих самых тестеров и техписов..
Команда порядка 40 человек на один проект. Всех узких ролей было предостаточно. Просто Вы опять таки упорно игнорируете масштабы проектов, которые бывают. И 40 человек, имхо, мало на проект в структуре штатной численностью свыше 0,5 млн человек.
За экскурс в историю, спасибо. На самом деле, без сарказма. Только я убежден что качество конечных решений, качество польз от них как и качество бизнеса в целом растет. Это закон рынка, он за пределами гос.заказчиков, более или менее конкурентен и не допустил бы (рынок), чтобы новые походы в этой направлении были менее эффективные чем старые, они бы просто не прижились.
Также Ваш оценка истории развития аналогична по тону рассуждениям старшего поколения о том, что молодежь якобы нынче не та (читай «хуже»). При этом не утверждаю конечно, что старшее поколение не право, проблема в том, что до них все тоже самое говорили и их предки, дискутировать здесь бесполезно, но смысл понятен, каждый при своем мнении.
Роль системного аналитика практически слилась с ролью ГИПа (архитектора) по причине того, что описать как сделать нечто на современной платформе это примерно тоже самое что сделать это.
Вы опять не учитываете возможный масштаб — это раз. И как будто не понимаете иной ценности документирования, кроме как инструкций к действию по реализации. Целей у описания (документирования) — множество. Это два.
Готовые платформы затачивались под вполне определенные бизнес-процессы, поэтому почти полностью отпала потребность в анализе БП в проектах автоматизации бизнеса
На мой взгляд, Вы смешали в одну кучу понятие платформы и понятие коробки/готового решения. Что в корне неверно.
Армия аналитиков при этом пополняется техписателями, тестерами, недо-ПМами, внедренцами и даже UX-дизайнерами. Хотя последнее время UX-более модное направление и аналитики начинают медленно переползать в категорию UX.
Я согласен с целом с мнением, что на рынке много «неэффективностей» что существенно определяет фон и отношение к этой сфере. Но есть большая разница в том, что же критиковать — конкретную реальную ситуацию, пусть массовую, или критиковать подход и методологию. Методология — это общее, примеры из практике — это частное. Критикуя частное, возможно аргументированно и справедливо, Вы почему то автоматом распространяете эту критику и выводы на общее. Это не логично.
Команда порядка 40 человек на один проект. Всех узких ролей было предостаточно. Просто Вы опять таки упорно игнорируете масштабы проектов, которые бывают. И 40 человек, имхо, мало на проект в структуре штатной численностью свыше 0,5 млн человек.
Приводите конкретику. Что за проект, какая команда, чем занимались аналитики (какой выхлоп от их работы). Проект внтуренний или внешний? Кто оплачивал банкет?
Вы опять не учитываете возможный масштаб — это раз.
Про масштаб я писал выше. Проекты от 100М в России — единичные, причем работ там гораздо меньше 100М. Если у вас другое мнение, то приводите факты. Все такие закупки пойдут через открытые конкурсы.
И как будто не понимаете иной ценности документирования, кроме как инструкций к действию по реализации.
У абстрактного документирования ценности нет. Ценность есть если документация кому-то и зачем-то нужна. На практике огромная часть документации нужны не для конкретных целей, а для следования процессу. Для такой документации можно брать студентов.
На мой взгляд, Вы смешали в одну кучу понятие платформы и понятие коробки/готового решения. Что в корне неверно.
Ничего неверного нет. В бизнесе не существует «коробок». Коробка это только замануха, чтобы продать проект. Бизнес-то у всех разный, поэтому обычно бюджет состоит на треть из цены коробки, а на 2/3 из услуг внедрения (которое иногда представляет из-себя авральное переписывание кода). Я несколько лет продавал СЭДы и прекрасно знаю как это выглядит.
По сути любая коробка это «платформа». Иногда «коробка» кроме собственно платформы содержит еще и «типовое решение», то его перепиливают в 99% случаев.
Это одинаково и в CRM, и ECM, и в ERP и во всех классах бизнес-систем.
Критикуя частное, возможно аргументированно и справедливо, Вы почему то автоматом распространяете эту критику и выводы на общее. Это не логично.
У вас ровно обратная ситуация, вы какой-то узкий пример пытаетесь обобщить на всю индустрию.
Если посмотреть правде в глаза, то никакой «методологии» нет. BaBoK, CBoK и профстандарты появились только что, никакой отдельной роли аналитиков в формальных методологиях никогда и не было и только сейчас начали появляться.
А если посмотреть что было буквально 5 лет назад, то выяснится что аналитики находились в жесточайшем identity crisis, из которого вышли только путем обкладывания кучей стандартов.
Даже ваш пост и комменты к нему наглядно показывает, что есть проблема с определением кто же такой аналитик и зачем он нужен.
Приводите конкретику. Что за проект, какая команда, чем занимались аналитики (какой выхлоп от их работы). Проект внтуренний или внешний? Кто оплачивал банкет?
Крупная организация. Проект внешний. Остальное коммерческая тайна.
Вы реально думаете что можно так просто в комментах описать выхлоп от работы? Это тема отдельной большой публикации. Ваша право не верить, но сдаюсь, на такое описание меня сейчас не хватит.
У абстрактного документирования ценности нет. Ценность есть если документация кому-то и зачем-то нужна. На практике огромная часть документации нужны не для конкретных целей, а для следования процессу. Для такой документации можно брать студентов
При чем тут абстрактное документирование, кто говорил про абстрактное документирование? игра слов, методы Вашей дискуссии — постоянный отрыв от контекста либо не правильно его толкование. Цели естественные: например, саппорт, отторжение, банально, сдача работ и подтверждение защита собственного «зада». Если Вы не узкий специалист, Вы обязаны это понимать. Иначе «я что-то внедрял, продавал» — только слова. А все остальное критика узкого специалиста, который не может объективно взглянуть сверху.
Ничего неверного нет. В бизнесе не существует «коробок». Коробка это только замануха, чтобы продать проект. Бизнес-то у всех разный, поэтому обычно бюджет состоит на треть из цены коробки, а на 2/3 из услуг внедрения (которое иногда представляет из-себя авральное переписывание кода). Я несколько лет продавал СЭДы и прекрасно знаю как это выглядит.
По сути любая коробка это «платформа». Иногда «коробка» кроме собственно платформы содержит еще и «типовое решение», то его перепиливают в 99% случаев.
Зачем Вы опять сводите предметную тему, начиная рассуждать о бизнес подходах. Вернитесь к исходному тезису. Кто как себя позиционирует, не имеет значение. Сравните, например, Documentum и, не, знаю, (чтобы никого не обижать) «нечто на SharePoint», например. Первое это классическая плафторма, второе та самая коробка с замахами на «платформу». Да замануха, но Вы же специалист вроде, должны понимать и отделять зерна от плевел. И не путать «тактику продаж» некоторых индивидов и реальные технологии.
У вас ровно обратная ситуация, вы какой-то узкий пример пытаетесь обобщить на всю индустрию.
Нет, я пытаюсь убедить Вас, что Вас взгляд однобок. На свою универсальность не претендую, ровно поэтому всегда делаю оговорки, в отличии от Вашей «прямоты».
Если посмотреть правде в глаза, то никакой «методологии» нет
Возможно Вы хотели сказать что все методологии неэффективны, в таком случае это исключительно Ваше мнение. Если у Вас не получалось эффективно работать, используя методологию, даже адаптировав под Ваши реалии, это не значит что не получалось ни у кого.
Мы уже пару постов назад перешли к демагогии. Предлагаю закончить. Спасибо за дискуссию.
В статье почувствовал роли Менеджера продукта, намешанные с Пресейл инженером. Всё-таки, в интеграторе, по моему опыту, интересует скорей второй. А в производителе ИТ продукта/сервиса первый.
Но с написанными тезисами нужных качеств соглашусь.
Но с написанными тезисами нужных качеств соглашусь.
Спасибо!
К производству ИТ продукта имею опосредованное отношение, тем не менее, на мой взгляд, должно быть существенное отличие. Для продукта важны обезличенный рынок (пусть и для какой-тоузкой ниши) и соответственно в главе угла потребности «масс» заказчиков, детальное обсуждения этих потребностей со всеми, ну или с ключевой группой, процесс очевидно отличающийся от процесса обсуждения потребностей конкретного заказчика, т.е. деятельности БА в интеграторе.
К производству ИТ продукта имею опосредованное отношение, тем не менее, на мой взгляд, должно быть существенное отличие. Для продукта важны обезличенный рынок (пусть и для какой-тоузкой ниши) и соответственно в главе угла потребности «масс» заказчиков, детальное обсуждения этих потребностей со всеми, ну или с ключевой группой, процесс очевидно отличающийся от процесса обсуждения потребностей конкретного заказчика, т.е. деятельности БА в интеграторе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ключевые качества бизнес-аналитика в ИТ