Доброго времени суток. Спасибо за статью, интересная тема, часто по факту используем такую методику — когда рождается ее обоснование и описание — многое встает на свои места.
Правда, имхо, в статье стоит добавить контекст уместного использования методики, так как она эффективна явна не всегда. Проблема кроется в том, что зачастую верно оптимальное решение, а не идеальное (или совершенное). Где «идеальное» — сущность в общем более объективная (т.е. собеседники в решении проблемы, в которой условно одинаково компетентны, имеют в целом схожее представление об идеальности), а «оптимальность» — сущность более субъективная (чуть позже аргумент — «почему»). Соответственно на предложенное оптимальное решение (которое на практике зачастую не совершенное) — методика дает возможность критиковать (методом «на 7-чку, вот тебе 3 предложения к улучшению) и вдаваться порой в полемику. Смысл оптимальности ведь в том, что мы осознанно (или порой неосознанно, на опыте) жертвуем чем-либо (т.е. не достигаем идеала по некоторым позициям) либо когда это невозможно (например, одно преимущество противоречит другому — надо выбрать), либо когда нерационально реализовывать идеал (банально дорого). И здесь самое ключевое в том, что выбор того, чем мы жертвуем — это зачастую намеренный и осознанный „риск“. А риски как раз (в основном „жизненные“ риски) очень субъективное понятие. А если говорить строго: сложность адекватной оценки вероятности и влияния рисков зачастую многократно превосходит по сложности ту проблему, о которой спорим, поэтому оценка рисков — вероятность и влияние — на практике зачастую субъективна. В таком случае методика, например, проверки на устойчивость, превращается в спор „мировоззрений“ (в оценке рисков).
Т.е. методика становится инструментом неконструктивной манипуляции: „Ну вот смотри, в предложенной архитектуре есть вероятность того, что будут проблемы тут-то, которые нам надо будет мучатся-решать“. Вроде адекватный аргумент — но что значит в конкретике „вероятность“ и что значит „мучатся“ — это очень субъективно: какова вероятность и насколько сильно мучатся, заранее зачастую как то оценить количественно невозможно. И тогда в споре побеждает более харизматичный (главный/сильный/громкий и т.п. ).
Резюмируя, методика хороша тремя составляющими:
Проверка, что оптимальность в конкретном случае отличается от идеальности именно „позициями“ субъективной оценкой рисков, что уже неплохо
Таким методом можно оценить насколько твоя субъективная оценка совпадает с субъективноей оценкой оппонента. Это никак не продвинет в вопросе решения конкретной проблемы, но так или иначе расширит кругозор.
Отлично подойдет в ситуациях, когда локальный идеал достижим за адекватные ресурсы. Но таких случаев, к сожалению, подавляющее меньшинство.
Возможно комментарий запоздал, но тем не менее:
Когда рассказываете о встраивании в картину мира, в противовес разрушению (возможно у вас наверное просто пример не самый удачный — «мы то с вами менеджеры опытные..»), почему то возникает ощущение «лести», что тоже по сути негатив. В этом случае получается обе тактики в переговорах грозят «минусами». Вы в таком контексте не обсуждали вопрос? Возможно неправильно трактовал пример.
С того что я знаю как работает механизм закупок в крупных компаниях ;)
Полюс, Норникель, МТС — это только те, приглашения об участии в закрытых конкурсах которых видел лично сам.
Я продавал проекты в сбере и ВТБ. Увы, там далеко не сотни миллионов.
Значит плохо продавали :). Вы же сами потрудились и дали ссылку. Я за две минуты нашел у сбера два относительно нестарых запроса на относительно «частные» задачи класса ECM за 50 и за 60 млн. А представьте себе относительно комплексную задачу?
Таких компаний в России просто нет. Даже Ростелеком с 150к сотрудников имеет активных пользователе на систему менее 10к одновременных. В Мегафоне (30к сотрудников) корпоративный портал имеет посещаемость около 6к пользователей в день.
Так что вы уже пошли фантазировать, большинство проектов на два порядка меньше чем вам кажется.
Прежде чем совершенно бездарно упрекать в «фантазировании», держите СЭД в Сбербанке, держите СЭД в ВТБ. А это только у DocsVision. Я уже не говорю про РЖД, Роснефть (если они наконец решат унифицироваться на одной платформе), Газпром, Росатом, Ростех, и реально огромные госы (типа МВД, ФМС, ФНС, министерства), но там конечно своя кухня. Из частников — все добытчики, там конечно поменьше, но 10-15 тыс пользователей — не так мало, не единицы. Если это проекты на Документуме — то это не одна сотня миллионов. Вы изначально говорили еще про SAP в контексте «даже Sap столько не стоит»? Одна из известных мне компаний сейчас внедряет SAP, сумма сделки свыше 100 млн. (штат 2000 человек, частный бизнес).
Если Вы чего то не знаете, это не значит, что этого нет. Если Вы утверждаете, что нет чего-то, о чем доподлинно не знаете, значит Вы просто заблуждаетесь, как и во многом другом, о чем успели, видимо, не подумав, а раз точно не знаете, даже не «погуглив», написать.
Очевидно у Вас в некотором роде идеалистический взгляд. Что в общем то и неплохо: он открыт, это какое-никое, но подтверждение добросовестности и честности. Отсюда много вытекающих преимуществ, ключевое — у Вас наверняка очень хороший коллектив и семейная атмосфера. Комфорт во всем, в любой детали, это адекватная замена (до определенных пределов, естественно) финансовой мотивации. Комфортная атмосфера — в первую очередь. Единственный большой минус в этом — невозможность масштабироваться в таких условиях. Т.е. такая модель с ростом персонала станет нежизнеспособной. По моей оценке — предел, когда от идеалистического подхода придется отказаться — человек 25-30. Далее рост бюрократии, появления «посредственностей», как их не мотивирую и прочие проблемы роста. Вот там то наверное и начинается бизнес :)
По существу — да, 100 процентов уверенности, как то круто. Сомневаться — это нормально, риск — это естественно. К тому же с таким подходом, в реальности, Вы бы так и остались в вашей компании вдвоем/втроем (= числу изначальных соучредителей). Так что здесь бы как то смягчить условие.
Про список «ценностей с точки зрения работодателей»: это скорее список, основанный на статистике заявлений(не реальных стимулов, а именно заявлений) самих соискателей. Причина такого мнения проста: банально не перечислены те стимулы, желания, которые на самом деле у всех есть на уровне подсознания, и которые опытный психолог сразу раскусывает — это, грубо выражаясь, мотив свободы (от ...) и мотив признания (извне..)
А в целом позитивно. Спасибо!
Приводите конкретику. Что за проект, какая команда, чем занимались аналитики (какой выхлоп от их работы). Проект внтуренний или внешний? Кто оплачивал банкет?
Крупная организация. Проект внешний. Остальное коммерческая тайна.
Вы реально думаете что можно так просто в комментах описать выхлоп от работы? Это тема отдельной большой публикации. Ваша право не верить, но сдаюсь, на такое описание меня сейчас не хватит.
У абстрактного документирования ценности нет. Ценность есть если документация кому-то и зачем-то нужна. На практике огромная часть документации нужны не для конкретных целей, а для следования процессу. Для такой документации можно брать студентов
При чем тут абстрактное документирование, кто говорил про абстрактное документирование? игра слов, методы Вашей дискуссии — постоянный отрыв от контекста либо не правильно его толкование. Цели естественные: например, саппорт, отторжение, банально, сдача работ и подтверждение защита собственного «зада». Если Вы не узкий специалист, Вы обязаны это понимать. Иначе «я что-то внедрял, продавал» — только слова. А все остальное критика узкого специалиста, который не может объективно взглянуть сверху.
Ничего неверного нет. В бизнесе не существует «коробок». Коробка это только замануха, чтобы продать проект. Бизнес-то у всех разный, поэтому обычно бюджет состоит на треть из цены коробки, а на 2/3 из услуг внедрения (которое иногда представляет из-себя авральное переписывание кода). Я несколько лет продавал СЭДы и прекрасно знаю как это выглядит.
По сути любая коробка это «платформа». Иногда «коробка» кроме собственно платформы содержит еще и «типовое решение», то его перепиливают в 99% случаев.
Зачем Вы опять сводите предметную тему, начиная рассуждать о бизнес подходах. Вернитесь к исходному тезису. Кто как себя позиционирует, не имеет значение. Сравните, например, Documentum и, не, знаю, (чтобы никого не обижать) «нечто на SharePoint», например. Первое это классическая плафторма, второе та самая коробка с замахами на «платформу». Да замануха, но Вы же специалист вроде, должны понимать и отделять зерна от плевел. И не путать «тактику продаж» некоторых индивидов и реальные технологии.
У вас ровно обратная ситуация, вы какой-то узкий пример пытаетесь обобщить на всю индустрию.
Нет, я пытаюсь убедить Вас, что Вас взгляд однобок. На свою универсальность не претендую, ровно поэтому всегда делаю оговорки, в отличии от Вашей «прямоты».
Если посмотреть правде в глаза, то никакой «методологии» нет
Возможно Вы хотели сказать что все методологии неэффективны, в таком случае это исключительно Ваше мнение. Если у Вас не получалось эффективно работать, используя методологию, даже адаптировав под Ваши реалии, это не значит что не получалось ни у кого.
Мы уже пару постов назад перешли к демагогии. Предлагаю закончить. Спасибо за дискуссию.
Вы же сами согласились, что при грамотном ГИПе аналитик не нужен на небольшом проекте. А я вам привел как эта ситуация масштабируется даже на большие проекты, и аналитики все также не нужны.
Конечно, согласился. Только она не может так масштабироваться из-за ограничения одного ресурса. Как только одного ресурса (ГИП) будет мало, вы будете привлекать еще одного универсального ГИПА-БА, или все таки БА, который нагрузку аналитики с Вашего Гипа снимет? Я думаю второй вариант естественно выгоднее.
Все такие закупки будут проходить через открытые конкурсы. Киньте ссылку.
С чего Вы взяли что все и именно через открытые? Но не суть, площадок много, найти при желании можно. Совсем недавно только мелькало пару конкурсов для (!) областной администрации в регионе (Екатеринбург по-моему) по 40-50 млн каждый. Представьте себе, аналог в МСК, МСО, или Спб. Если интересно, можете оценить масштаб проектов в Сбере, Втб. Сумм Вы в открытом доступе не найдете, но придется поверить на слово — в текущих ценах порядок был бы за 100млн. Почитайте описание, когда речь идет о 30000-50000 одновременных пользователях, как думаете, сколько стоит такой проект?
Без понимания стоимости ни о какой эффективности не может идти речи
В большей степени без понимания «величины» пользы не может идти речи об эффективности. И про стоимость тоже верно. Но стоимость можно и спросить, прикинуть. Важен порядок а конкретная цифра.
А инженер, который дорос до архитектора (не просто получил бирку), уже достаточно понимает потребности бизнеса и видит ситуацию чуть шире, чем средний бизнес-заказчик.
Т.е. уже по факту не инженер, а именно архитектор. Т.е. изначально вы хотели сказать не слабый инженер, а слабый архитектор?
Но в этом случае я бы прокачивал архитектора, а не брал еще одного человека.
Хорошее может быть решение. Но когда много проектов, они большие, загрузка высокая, то разумно же использовать архитектора как архитектора, а Ба как БА? Когда одного на всех не хватает? :)
Бухгалтерия, организация труда — не очень накладно для стартапа. пару часов в неделю + аутсорс бухгалтер.
То что не всем интересно заморачиваться, да, слава Богу, что так :)
Либо я потерял нить рассуждений. либо Вы куда-то не туда ушли. Смысл и назначение этого комментария — загадка. Что Вы пытались этим доказать?
А вот без аналитика на таком проекте прожить можно, да и ничего страшного не случится.
Вы это сказали с самого начала, а сейчас снова повторили, и снова ни одного аргумента. Просто утверждение, без подтверждения, никакой логической цепочки которая привела бы к такому выводу.
100к часов — еще как бывает. 120М рублей даже в России, не редкость. Даже за СЭД, даже за СЭД на базе «российской платформы».
Понеслось :) Жаль что Вы комментируете только фразы из контекста, сложно повторятся в ответе, так как предыдущее описание было достаточно полно.
Во вступлении все описано, понимаю что интро читать не всегда интересно — там то конкретики совсем мало :)
Не только аналитики против, я как РП и управленец бизнеса в целом с Вами не согласен. Не говоря уже, повторюсь, о всех методология, которые с Вашей легкой руки предлагается отправить на свалку за ненадобностью.
А сколько было тестеров и техписателей? Уверен, что очень мало. Это значит что аналитики по факту выполняли функции этих самых тестеров и техписов.
.
Команда порядка 40 человек на один проект. Всех узких ролей было предостаточно. Просто Вы опять таки упорно игнорируете масштабы проектов, которые бывают. И 40 человек, имхо, мало на проект в структуре штатной численностью свыше 0,5 млн человек.
За экскурс в историю, спасибо. На самом деле, без сарказма. Только я убежден что качество конечных решений, качество польз от них как и качество бизнеса в целом растет. Это закон рынка, он за пределами гос.заказчиков, более или менее конкурентен и не допустил бы (рынок), чтобы новые походы в этой направлении были менее эффективные чем старые, они бы просто не прижились.
Также Ваш оценка истории развития аналогична по тону рассуждениям старшего поколения о том, что молодежь якобы нынче не та (читай «хуже»). При этом не утверждаю конечно, что старшее поколение не право, проблема в том, что до них все тоже самое говорили и их предки, дискутировать здесь бесполезно, но смысл понятен, каждый при своем мнении.
Роль системного аналитика практически слилась с ролью ГИПа (архитектора) по причине того, что описать как сделать нечто на современной платформе это примерно тоже самое что сделать это.
Вы опять не учитываете возможный масштаб — это раз. И как будто не понимаете иной ценности документирования, кроме как инструкций к действию по реализации. Целей у описания (документирования) — множество. Это два.
Готовые платформы затачивались под вполне определенные бизнес-процессы, поэтому почти полностью отпала потребность в анализе БП в проектах автоматизации бизнеса
На мой взгляд, Вы смешали в одну кучу понятие платформы и понятие коробки/готового решения. Что в корне неверно.
Армия аналитиков при этом пополняется техписателями, тестерами, недо-ПМами, внедренцами и даже UX-дизайнерами. Хотя последнее время UX-более модное направление и аналитики начинают медленно переползать в категорию UX.
Я согласен с целом с мнением, что на рынке много «неэффективностей» что существенно определяет фон и отношение к этой сфере. Но есть большая разница в том, что же критиковать — конкретную реальную ситуацию, пусть массовую, или критиковать подход и методологию. Методология — это общее, примеры из практике — это частное. Критикуя частное, возможно аргументированно и справедливо, Вы почему то автоматом распространяете эту критику и выводы на общее. Это не логично.
Спасибо!
К производству ИТ продукта имею опосредованное отношение, тем не менее, на мой взгляд, должно быть существенное отличие. Для продукта важны обезличенный рынок (пусть и для какой-тоузкой ниши) и соответственно в главе угла потребности «масс» заказчиков, детальное обсуждения этих потребностей со всеми, ну или с ключевой группой, процесс очевидно отличающийся от процесса обсуждения потребностей конкретного заказчика, т.е. деятельности БА в интеграторе.
В общем виде Вы не правы. Команда это главное, и весь Ваш первый абзац — вы по сути описываете качство состава и качество взаимодействия внутри, успев при этом в пылу дискуссии назвать все это «ни о чем». В конкретике — возможно. Раз уж раскрутились, скажите, о какого рода проектах Вы говорите, особенно утверждая что архитектор единственный ключевой игрок. Имеется ввиду что внедряете, какой масштаб.
Получается экономически невыгодно иметь аналитика и архитектора, лучше взять одного архитектора, который понимает проблемы заказчика и умеет разговаривать.
Вы упорно не хотите принимать во внимание масштаб проекта. Высказывание, что выгоднее держать одного человека вместо двух, при условии что он справится, через чур очевидно.
Это только в случае очень слабых инженеров.
Исходя из Вашей логики, слаб тот инженер, кто не умеет осуществлять сбор и анализ требований, оценивать «эффективность» и отдачу от реализации этих требований для бизнеса заказчика и много другое прочее. Ну это же абсурд! Это не в компетенции инженеров. И на основании отсутствия этих компетенций называть инженера слабым, все равно что называть слона ущербным, потому что он не умеет летать.
Очень часто бывает, что заказчик говорит «хочу Х», но грамотный внедренец поймет, что можно сделать Y, с тем же результатом и меньшими затратами\рисками. А вот аналитик без знаний уровня внедренца не поймет.
У нас явно различаются представления о понятиях «внедренец». Если бы вы сказали архитектор, то согласился бы. Оценка сложности реализации того или иного требования в зависимости от варианта реализации — компетенция архитектора, не внедренца. Аналитик может знать это исходя из опыта, а не потому что он знает продукт ровно настолько, насколько знает архитектор или внедренец.
А дальше получается так: аналитики все записывает приносит команде, команда нахоит 100500 таких требований, которые можно слегка поменять и снизить риски и затраты. Нужно обсуждать это с заказчиком. А как? Снова ехать, уже расширенным составом, вместе с внедренцами? А зачем аналитик тогда катался в первый раз? Вот и получается что сбор требований == выстраивание ожиданий.
Дальше получается на самом деле так, что в одной из итераций обсуждения принимает участие архитектор и это нормально, это на самом деле «по книжке» (по методологии) верно. Понимаю, что всем нам хочется все с оптимизировать и видеть в одном ресурсе все качества, но это больше исключение и везение, нежели практика. Причем когда Вы говорите о такой детализации (100500 требований) это уже явно не пресейл, а проект в стадии «проектирование»/«анализ» и т.п.
На практике пресейл это и есть выстраивание ожиданий и создание конкурентных преимуществ.
Странное определение пресейла. Как минимум непонятно что значит в данном контексте «создавать» к объекту «конкурентные преимущества». Конкурентные преимущества продукта или услуги не могут создаваться в рамках сделки, они могут быть в рамках сделки лишь предъявлены. С «выстраиванием ожиданий» тоже, если честно не все понятно.
На моей практике польза аналитиков сводилась к написанию необходимых бумажек и тестированию.
Не сомневаюсь. О чем это говорит? Лишь только о том, что в Вашей практике аналитики выделенные не сильно полезны, либо Вы ошибаетесь в своей оценке.
Один мой знакомый сказал по этому поводу «аналитики существуют, потому что не всем тестерам можно дать бирку ПМа».
Типичный взгляд архитектора/программиста/случайная роль/, которому чем-то не угодили аналитики. :)
Вероятно, Вы правы, что название не в полной мере дает представления о реальном содержании. Пытался смягчить «кавычками», видимо не сильно успешно. Безусловно, рассуждения не детализированы и не формализованы настолько, чтобы можно было предъявить без изменения в качестве «чего-то документального». Но и задача такая не стояла. Выше по комментариям привели новенький «профстандарт», там действительно конкретика и действительно полезна, имхо. Но, согласитесь, в качестве, статьи было бы неуместно. Поэтому «пространные рассуждения» — как минимум, это сугубо Ваша точка зрения, причем возможно (подчёркиваю, возможно) в той сфере, о который лично Вы имеете не настолько много представлений, как думаете. А судите исходя лишь сугубо из того, что с чем лично Вам приходилось иметь дело. Что, как минимум, не объективно.
Что касается ролей, то вопрос не в названии, а в функциях
Так роль и характеризуется именно набором функций, это одно из альтернативных определений.
Так вот потребность еще одного человека для этих функций крайне мала
В Вашей практике возможно, но в общем случае, найдется очень много несогласных с этой точкой зрения (например, авторы всех более менее известных методологий внедрения бизнес-приложений). Как минимум, вы не делает поправку на величину проекта. Есть не один пример проектов, в которых была целая группа аналитиков и один архитектор и один ПМ. Так что вся дискуссия основана только на том, в какой-то сфере возможно всегда не нужен выделенный БА — не сомневаюсь что такие сферы существуют даже для крупного масштаба (проекты, более инфраструктурного плана, нежели бизнесового: Exchange, SharePoint (как интранет портал), либо с очень узкой спецификой — например, для нужд ИТ-департамента). Поэтому вероятно и выходим за рамки конструктива.
Про разные реальности — в точку! Наверняка у каждого из нас деятельность со своими особенностями и это, естественно, может порождать разные мнения и оценку. Но позвольте в корне не согласится с утверждением:
Так вот на сложном проекте ключевая фигура — ГИП (архитектор)
Все же в этом случае ключевая фигура не одна. Ключевая все же команда и ее способность взаимодействия. Естественно, все зависит от того, как понимать в данном контексте «сложный проект». Более или менее универсальный подход к этому вопросу — размер проекта, в моем понимания это, как писал где то ранее десятки тысяч человеко-часов. Развивая мысль, если кто-то из команды слабенький, слаба сама команда. Если кто-то в состоянии вытянуть за другого что-то в проекте и приходится вообще что-то вытягивать, то это означает ровно то, что команда неэффективно (ну либо в процессе становления, все когда-то были новичками). Как минимум, того, за кого что-то вытягивают в ней не должно быть и она просто избыточна, т.е. неэффективна. Каждый реально «лишний» человек в группе — серьезная обуза, которая мешает, так как порождается ненужное взаимодействие. С чем, судя по Вашей позиции, Вы и так согласны.
Видел пару раз как ГИПов пытались заменить аналитиками. Аналитики, как казалось, тупо дешевле хороших программистов. Выходило кране плачевно. Качество было очень низкое, сроки постоянно просрачивались.
Несмотря на то, что не сомневаюсь в существовании таких примеров, вынужден констатировать что бывают зеркальные примеры: проект без ярко выраженной роли аналитика (пусть даже совмещенно) — также рискует быть провальным. Это свидетельствует только о том, что и Вы и я видели разные проекты.
Коллеги, все хорошо, пока проекты относительно небольшие. А представьте себе некоего «мастадонта» на десятки тысяч человеко-часов, а то и сотни. Я не представляю себе, что будет после такого проекта со специалистом, который был в нем ПМ+аналитик+архитектор, и даже ПМ+аналитик.
Да, верно. За консалтинг платить не привыкли, это факт. Но и мультиплатформенных интеграторов тоже достаточно. И как раз БА, РП (и возможно архитектор частично) — это те специальности, которые проще всего переключаются от проектов на одной платформе к проекту на другой. Что делает их более «утилизационноспособными»
Все современные системы более-менее похожи внутри одного класса
Соглашусь с оговоркой: все современные системы похожи внутри одного класса и относительно близкого ценового сегмента и ниши.
Предположим есть аналитик, который не знает продукт (его конкретные возможности и ограничения), но вполне ориентируется в классе ECM. Он идет к заказчику, в попытке выявить потребности на пресейле. Задает вопросы, записывает ответы.
При этом он не может сразу выстраивать ожидания и не может создать конкурентное преимущество, потому что не знает продукта (его возможностей и ограничений), который будет продаваться. А в случае продажи услуг разработки ситуация еще хуже, потому что аналитик не знает технические аспекты и, скорее всего, не узнает.
Я бы в ответ на Ваш пример заметил, что выявить потребность на пресейле и создать конкурентное преимущество — это две разные задачи в общем случае, мало между собой связаны: БА пытается понять границы, чтобы потом команда условно посчитала деньги, а сэйлз описывает конкурентные преимущества. Соглашусь, что совершенно не знать продукт, который внедряешь — ну такого просто и не бывает, наверное, но уровень знаний какой? Я бы рискнул утверждать, что достаточно уровня очень уверенного и «прошаренного» пользователя решений на базе этого продукта (причем не судя по одному проекту, а судя именно по набору, т.е. видел продукт в разных «состояниях»), потому что все же внедренец — это (в моем случае) знание скриптов, запросов и т.п… Хотя чем лучше БА разбирается в продукте (при прочих равных), тем меньше рисков определенного класса — с этим никто спорить не будет.
Сколько я видел живых примеров — аналитик, не знающий продукт на уровне внедренца, практически бесполезен.
Предположил бы, что такое мнение может быть следствием особенностей наблюдаемых Вами методологий внедрения и уровню взаимодействия внутри проектной команды. Это же палка о двух концах. Когда в проекте что-то идет не так, то все склонны винить обычно кого-нибудь, но только не себя. Кстати в статья я писал, что БА зачастую, наравне с ПМ-ом, самый виноватый в глазах основной команды. Почему так происходит? Рискнул бы предположить, что именно на ПМ и на БА большая большая часть ответственности, чем на других ролях.
Да, соглашусь что очень часто бывает уместно вместо двух человек держать одного, закрывающего две роли. Но это, согласитесь, означает ровно то, что роль «размазана» между теми же ПМ-ом и архитектором, но не в коем случае не бесполезна, верно? Кстати, можно же ставить зеркально: почему бы тогда не размазать роль того же ПМ-а между аналитиком и архитектором? Про то, что ценность аналитиков в чистом виде мала (если согласно предыдущему утверждению имеется ввиду именно выделение отдельного ресурса под эту роль и только под нее), соглашусь, но наверняка это сильно зависит от размера проекта и их количества (проектов) в компании.
Про замечание о перечне в проверяемом виде, извините, к сожалению не понял, что Вы под этим подразумеваете.
Правда, имхо, в статье стоит добавить контекст уместного использования методики, так как она эффективна явна не всегда. Проблема кроется в том, что зачастую верно оптимальное решение, а не идеальное (или совершенное). Где «идеальное» — сущность в общем более объективная (т.е. собеседники в решении проблемы, в которой условно одинаково компетентны, имеют в целом схожее представление об идеальности), а «оптимальность» — сущность более субъективная (чуть позже аргумент — «почему»). Соответственно на предложенное оптимальное решение (которое на практике зачастую не совершенное) — методика дает возможность критиковать (методом «на 7-чку, вот тебе 3 предложения к улучшению) и вдаваться порой в полемику. Смысл оптимальности ведь в том, что мы осознанно (или порой неосознанно, на опыте) жертвуем чем-либо (т.е. не достигаем идеала по некоторым позициям) либо когда это невозможно (например, одно преимущество противоречит другому — надо выбрать), либо когда нерационально реализовывать идеал (банально дорого). И здесь самое ключевое в том, что выбор того, чем мы жертвуем — это зачастую намеренный и осознанный „риск“. А риски как раз (в основном „жизненные“ риски) очень субъективное понятие. А если говорить строго: сложность адекватной оценки вероятности и влияния рисков зачастую многократно превосходит по сложности ту проблему, о которой спорим, поэтому оценка рисков — вероятность и влияние — на практике зачастую субъективна. В таком случае методика, например, проверки на устойчивость, превращается в спор „мировоззрений“ (в оценке рисков).
Т.е. методика становится инструментом неконструктивной манипуляции: „Ну вот смотри, в предложенной архитектуре есть вероятность того, что будут проблемы тут-то, которые нам надо будет мучатся-решать“. Вроде адекватный аргумент — но что значит в конкретике „вероятность“ и что значит „мучатся“ — это очень субъективно: какова вероятность и насколько сильно мучатся, заранее зачастую как то оценить количественно невозможно. И тогда в споре побеждает более харизматичный (главный/сильный/громкий и т.п. ).
Резюмируя, методика хороша тремя составляющими:
Когда рассказываете о встраивании в картину мира, в противовес разрушению (возможно у вас наверное просто пример не самый удачный — «мы то с вами менеджеры опытные..»), почему то возникает ощущение «лести», что тоже по сути негатив. В этом случае получается обе тактики в переговорах грозят «минусами». Вы в таком контексте не обсуждали вопрос? Возможно неправильно трактовал пример.
А в общем, спасибо за видео, очень позитивно!
Полюс, Норникель, МТС — это только те, приглашения об участии в закрытых конкурсах которых видел лично сам.
Значит плохо продавали :). Вы же сами потрудились и дали ссылку. Я за две минуты нашел у сбера два относительно нестарых запроса на относительно «частные» задачи класса ECM за 50 и за 60 млн. А представьте себе относительно комплексную задачу?
Прежде чем совершенно бездарно упрекать в «фантазировании», держите СЭД в Сбербанке, держите СЭД в ВТБ. А это только у DocsVision. Я уже не говорю про РЖД, Роснефть (если они наконец решат унифицироваться на одной платформе), Газпром, Росатом, Ростех, и реально огромные госы (типа МВД, ФМС, ФНС, министерства), но там конечно своя кухня. Из частников — все добытчики, там конечно поменьше, но 10-15 тыс пользователей — не так мало, не единицы. Если это проекты на Документуме — то это не одна сотня миллионов. Вы изначально говорили еще про SAP в контексте «даже Sap столько не стоит»? Одна из известных мне компаний сейчас внедряет SAP, сумма сделки свыше 100 млн. (штат 2000 человек, частный бизнес).
Если Вы чего то не знаете, это не значит, что этого нет. Если Вы утверждаете, что нет чего-то, о чем доподлинно не знаете, значит Вы просто заблуждаетесь, как и во многом другом, о чем успели, видимо, не подумав, а раз точно не знаете, даже не «погуглив», написать.
По существу — да, 100 процентов уверенности, как то круто. Сомневаться — это нормально, риск — это естественно. К тому же с таким подходом, в реальности, Вы бы так и остались в вашей компании вдвоем/втроем (= числу изначальных соучредителей). Так что здесь бы как то смягчить условие.
Про список «ценностей с точки зрения работодателей»: это скорее список, основанный на статистике заявлений(не реальных стимулов, а именно заявлений) самих соискателей. Причина такого мнения проста: банально не перечислены те стимулы, желания, которые на самом деле у всех есть на уровне подсознания, и которые опытный психолог сразу раскусывает — это, грубо выражаясь, мотив свободы (от ...) и мотив признания (извне..)
А в целом позитивно. Спасибо!
Крупная организация. Проект внешний. Остальное коммерческая тайна.
Вы реально думаете что можно так просто в комментах описать выхлоп от работы? Это тема отдельной большой публикации. Ваша право не верить, но сдаюсь, на такое описание меня сейчас не хватит.
При чем тут абстрактное документирование, кто говорил про абстрактное документирование? игра слов, методы Вашей дискуссии — постоянный отрыв от контекста либо не правильно его толкование. Цели естественные: например, саппорт, отторжение, банально, сдача работ и подтверждение защита собственного «зада». Если Вы не узкий специалист, Вы обязаны это понимать. Иначе «я что-то внедрял, продавал» — только слова. А все остальное критика узкого специалиста, который не может объективно взглянуть сверху.
Зачем Вы опять сводите предметную тему, начиная рассуждать о бизнес подходах. Вернитесь к исходному тезису. Кто как себя позиционирует, не имеет значение. Сравните, например, Documentum и, не, знаю, (чтобы никого не обижать) «нечто на SharePoint», например. Первое это классическая плафторма, второе та самая коробка с замахами на «платформу». Да замануха, но Вы же специалист вроде, должны понимать и отделять зерна от плевел. И не путать «тактику продаж» некоторых индивидов и реальные технологии.
Нет, я пытаюсь убедить Вас, что Вас взгляд однобок. На свою универсальность не претендую, ровно поэтому всегда делаю оговорки, в отличии от Вашей «прямоты».
Возможно Вы хотели сказать что все методологии неэффективны, в таком случае это исключительно Ваше мнение. Если у Вас не получалось эффективно работать, используя методологию, даже адаптировав под Ваши реалии, это не значит что не получалось ни у кого.
Мы уже пару постов назад перешли к демагогии. Предлагаю закончить. Спасибо за дискуссию.
Конечно, согласился. Только она не может так масштабироваться из-за ограничения одного ресурса. Как только одного ресурса (ГИП) будет мало, вы будете привлекать еще одного универсального ГИПА-БА, или все таки БА, который нагрузку аналитики с Вашего Гипа снимет? Я думаю второй вариант естественно выгоднее.
С чего Вы взяли что все и именно через открытые? Но не суть, площадок много, найти при желании можно. Совсем недавно только мелькало пару конкурсов для (!) областной администрации в регионе (Екатеринбург по-моему) по 40-50 млн каждый. Представьте себе, аналог в МСК, МСО, или Спб. Если интересно, можете оценить масштаб проектов в Сбере, Втб. Сумм Вы в открытом доступе не найдете, но придется поверить на слово — в текущих ценах порядок был бы за 100млн. Почитайте описание, когда речь идет о 30000-50000 одновременных пользователях, как думаете, сколько стоит такой проект?
За исключением:
В большей степени без понимания «величины» пользы не может идти речи об эффективности. И про стоимость тоже верно. Но стоимость можно и спросить, прикинуть. Важен порядок а конкретная цифра.
Т.е. уже по факту не инженер, а именно архитектор. Т.е. изначально вы хотели сказать не слабый инженер, а слабый архитектор?
Хорошее может быть решение. Но когда много проектов, они большие, загрузка высокая, то разумно же использовать архитектора как архитектора, а Ба как БА? Когда одного на всех не хватает? :)
То что не всем интересно заморачиваться, да, слава Богу, что так :)
Вы это сказали с самого начала, а сейчас снова повторили, и снова ни одного аргумента. Просто утверждение, без подтверждения, никакой логической цепочки которая привела бы к такому выводу.
100к часов — еще как бывает. 120М рублей даже в России, не редкость. Даже за СЭД, даже за СЭД на базе «российской платформы».
Во вступлении все описано, понимаю что интро читать не всегда интересно — там то конкретики совсем мало :)
Не только аналитики против, я как РП и управленец бизнеса в целом с Вами не согласен. Не говоря уже, повторюсь, о всех методология, которые с Вашей легкой руки предлагается отправить на свалку за ненадобностью.
.
Команда порядка 40 человек на один проект. Всех узких ролей было предостаточно. Просто Вы опять таки упорно игнорируете масштабы проектов, которые бывают. И 40 человек, имхо, мало на проект в структуре штатной численностью свыше 0,5 млн человек.
За экскурс в историю, спасибо. На самом деле, без сарказма. Только я убежден что качество конечных решений, качество польз от них как и качество бизнеса в целом растет. Это закон рынка, он за пределами гос.заказчиков, более или менее конкурентен и не допустил бы (рынок), чтобы новые походы в этой направлении были менее эффективные чем старые, они бы просто не прижились.
Также Ваш оценка истории развития аналогична по тону рассуждениям старшего поколения о том, что молодежь якобы нынче не та (читай «хуже»). При этом не утверждаю конечно, что старшее поколение не право, проблема в том, что до них все тоже самое говорили и их предки, дискутировать здесь бесполезно, но смысл понятен, каждый при своем мнении.
Вы опять не учитываете возможный масштаб — это раз. И как будто не понимаете иной ценности документирования, кроме как инструкций к действию по реализации. Целей у описания (документирования) — множество. Это два.
На мой взгляд, Вы смешали в одну кучу понятие платформы и понятие коробки/готового решения. Что в корне неверно.
Я согласен с целом с мнением, что на рынке много «неэффективностей» что существенно определяет фон и отношение к этой сфере. Но есть большая разница в том, что же критиковать — конкретную реальную ситуацию, пусть массовую, или критиковать подход и методологию. Методология — это общее, примеры из практике — это частное. Критикуя частное, возможно аргументированно и справедливо, Вы почему то автоматом распространяете эту критику и выводы на общее. Это не логично.
К производству ИТ продукта имею опосредованное отношение, тем не менее, на мой взгляд, должно быть существенное отличие. Для продукта важны обезличенный рынок (пусть и для какой-тоузкой ниши) и соответственно в главе угла потребности «масс» заказчиков, детальное обсуждения этих потребностей со всеми, ну или с ключевой группой, процесс очевидно отличающийся от процесса обсуждения потребностей конкретного заказчика, т.е. деятельности БА в интеграторе.
Вы упорно не хотите принимать во внимание масштаб проекта. Высказывание, что выгоднее держать одного человека вместо двух, при условии что он справится, через чур очевидно.
Исходя из Вашей логики, слаб тот инженер, кто не умеет осуществлять сбор и анализ требований, оценивать «эффективность» и отдачу от реализации этих требований для бизнеса заказчика и много другое прочее. Ну это же абсурд! Это не в компетенции инженеров. И на основании отсутствия этих компетенций называть инженера слабым, все равно что называть слона ущербным, потому что он не умеет летать.
У нас явно различаются представления о понятиях «внедренец». Если бы вы сказали архитектор, то согласился бы. Оценка сложности реализации того или иного требования в зависимости от варианта реализации — компетенция архитектора, не внедренца. Аналитик может знать это исходя из опыта, а не потому что он знает продукт ровно настолько, насколько знает архитектор или внедренец.
Дальше получается на самом деле так, что в одной из итераций обсуждения принимает участие архитектор и это нормально, это на самом деле «по книжке» (по методологии) верно. Понимаю, что всем нам хочется все с оптимизировать и видеть в одном ресурсе все качества, но это больше исключение и везение, нежели практика. Причем когда Вы говорите о такой детализации (100500 требований) это уже явно не пресейл, а проект в стадии «проектирование»/«анализ» и т.п.
Странное определение пресейла. Как минимум непонятно что значит в данном контексте «создавать» к объекту «конкурентные преимущества». Конкурентные преимущества продукта или услуги не могут создаваться в рамках сделки, они могут быть в рамках сделки лишь предъявлены. С «выстраиванием ожиданий» тоже, если честно не все понятно.
Не сомневаюсь. О чем это говорит? Лишь только о том, что в Вашей практике аналитики выделенные не сильно полезны, либо Вы ошибаетесь в своей оценке.
Типичный взгляд архитектора/программиста/случайная роль/, которому чем-то не угодили аналитики. :)
Так роль и характеризуется именно набором функций, это одно из альтернативных определений.
В Вашей практике возможно, но в общем случае, найдется очень много несогласных с этой точкой зрения (например, авторы всех более менее известных методологий внедрения бизнес-приложений). Как минимум, вы не делает поправку на величину проекта. Есть не один пример проектов, в которых была целая группа аналитиков и один архитектор и один ПМ. Так что вся дискуссия основана только на том, в какой-то сфере возможно всегда не нужен выделенный БА — не сомневаюсь что такие сферы существуют даже для крупного масштаба (проекты, более инфраструктурного плана, нежели бизнесового: Exchange, SharePoint (как интранет портал), либо с очень узкой спецификой — например, для нужд ИТ-департамента). Поэтому вероятно и выходим за рамки конструктива.
Все же в этом случае ключевая фигура не одна. Ключевая все же команда и ее способность взаимодействия. Естественно, все зависит от того, как понимать в данном контексте «сложный проект». Более или менее универсальный подход к этому вопросу — размер проекта, в моем понимания это, как писал где то ранее десятки тысяч человеко-часов. Развивая мысль, если кто-то из команды слабенький, слаба сама команда. Если кто-то в состоянии вытянуть за другого что-то в проекте и приходится вообще что-то вытягивать, то это означает ровно то, что команда неэффективно (ну либо в процессе становления, все когда-то были новичками). Как минимум, того, за кого что-то вытягивают в ней не должно быть и она просто избыточна, т.е. неэффективна. Каждый реально «лишний» человек в группе — серьезная обуза, которая мешает, так как порождается ненужное взаимодействие. С чем, судя по Вашей позиции, Вы и так согласны.
Несмотря на то, что не сомневаюсь в существовании таких примеров, вынужден констатировать что бывают зеркальные примеры: проект без ярко выраженной роли аналитика (пусть даже совмещенно) — также рискует быть провальным. Это свидетельствует только о том, что и Вы и я видели разные проекты.
Соглашусь с оговоркой: все современные системы похожи внутри одного класса и относительно близкого ценового сегмента и ниши.
Я бы в ответ на Ваш пример заметил, что выявить потребность на пресейле и создать конкурентное преимущество — это две разные задачи в общем случае, мало между собой связаны: БА пытается понять границы, чтобы потом команда условно посчитала деньги, а сэйлз описывает конкурентные преимущества. Соглашусь, что совершенно не знать продукт, который внедряешь — ну такого просто и не бывает, наверное, но уровень знаний какой? Я бы рискнул утверждать, что достаточно уровня очень уверенного и «прошаренного» пользователя решений на базе этого продукта (причем не судя по одному проекту, а судя именно по набору, т.е. видел продукт в разных «состояниях»), потому что все же внедренец — это (в моем случае) знание скриптов, запросов и т.п… Хотя чем лучше БА разбирается в продукте (при прочих равных), тем меньше рисков определенного класса — с этим никто спорить не будет.
Предположил бы, что такое мнение может быть следствием особенностей наблюдаемых Вами методологий внедрения и уровню взаимодействия внутри проектной команды. Это же палка о двух концах. Когда в проекте что-то идет не так, то все склонны винить обычно кого-нибудь, но только не себя. Кстати в статья я писал, что БА зачастую, наравне с ПМ-ом, самый виноватый в глазах основной команды. Почему так происходит? Рискнул бы предположить, что именно на ПМ и на БА большая большая часть ответственности, чем на других ролях.
Про замечание о перечне в проверяемом виде, извините, к сожалению не понял, что Вы под этим подразумеваете.