Чувак, не торопись, дождись 23-го...
Других не осталось...
Брать с крашеными стенами. Коты абсолютно равнодушны к ним.
Есть неплохой шанс, что у твоей бывшей страны сбережения закончатся раньше, чем у тебя. У тебя только ты, а у кошелька страны семеро с ложкой стоят. Министры и вице-премьеры...
Российский рынок интеграции в нулевых и самом начале десятых развивался по израильской модели — лучшие ресурсы были у интеграторов (правда израильская модель продуктовая). А потом, из-за цунами халявных нефтяных денег рынок перешел на калифорнийскую модель, где лучшие ресурсы у клиента, а интеграторы подгоняют им толпы "индусов". Забавно, что массовый отъезд может вернуть назад этих crème de la crème. У крупных клиентов удаленка запрещена, а интеграторы как раз могут предоставить эту "услугу" людям.
1. Вполне есть. Есть даже интеграторы, которые для людей клиента проводят за деньги аж мастер-классы на тему "как вам можно заработать больше денег". Если Вы условный (полу)-монополист в своей области, то у Ваших людей появляется кругозор. Поработав с разными клиентами они видят как что у кого устроено и где через интегратора можно наладить условный обмен опытом. Клиентам это не всегда нравится и в критичных бизнес-областях в контракты могут включать пункты, что ИТ-команды, работающие на конкурентов должны сидеть в географически отдельных офисах и людей нельзя перекидывать между проектами для конкурентов в течении года-двух после окончания работы на одного из них.
2. Но такие БА дорогие, поэтому не у всякого интегратора бизнес-модель способна сдюжить такие косты. Плюс компаниям-клиентам их конечно проще нанять, т.к. они могут тратить на них маржу из своего основного бизнеса.
1. Почему две разные? Это вопрос не разных ролей / функциональности в проджект-флоу, а вопрос квалификации и знания отрасли и процессов со стороны БА. Какой процент знаний и контента он может сам привнести в проект, а какой придется добавлять клиентским людям.
2. Конечно БА могут быть условными "джунами" — способны только прилежно записать слова клиента и сделать простейшие логические связки между услышанным. Но это не "настоящий" БА :)
3. Если БА не способен завоевать доверие и авторитет со стороны клиента, то он не может продать (обоснованно убедить) клиенту вижн того, что нужно сделать. Ведь что-то в задачах клиента лучше решить системными доработками, а где-то клиенту нужно изменить свои бизнес-процессы. А убедить клиента менять свои бизнес-процессы — это не хрен собачий. Но такое доверие и авторитет можно завоевать только глубокими знаниями предметной области. А если связка БА/СА или не может сформировать такое вижн ввиду недостатка отраслевых знаний или не способна продать этот вижн клиенту, то это заканчивается ровно той печалью, которую Вы описываете в статье. У интегратора / разработчки а и клиента разговор слепого с глухим.
4. Так что описываемы Вами проблемы — это не то, что клиент недостаточно "понимает ИТ", это проблема того, что на проектах нет НАСТОЯЩИХ БА — неважно клиентских или Ваших собственных. Хотя из моего опыта в клиентских я не верю :) Обычно у них настолько квалифицированные люди очень быстро перестают писать спеки и уносятся вверх по корпоративной иерархии :)
В PayPal Илон вполне сам код писал, так что в курсе
Part 2 of 2
Понятно, что финтех
Конкретно проект, который я расписал в предыдущей части комменте, не в финтех :) Банки упоминал чаще, т.к. они более показательны — процессы и финансы на порядок сложнее скажем телекомов или товарного ритейла.
1. В банках все вертится вокруг плана счетов, который несравнимо сложнее "обычной бухгалтерии в других отраслях". Если Вы делаете своими ресурсами большой проект, то Вам нужно знать как отражается в учете например ипотека: деньги за рассмотрение заявки, маркетинговые плюшки клиентам, сама ипотека (и ее отражение в резервах и регуляторной отчетности), деньги за "страховку" и т.п. Если у Вас разрабы и СА, не "шарящие" в банках, то задолбаешься объяснять прописные истины. Одно дело подходишь к нему и говоришь, что в этом конкретном банке это проводят вот так и он схватывает все на лету, а другое — тратишь недели и месяцы на написание талмуда какие циферки в каких полях искать и что с ними делать.
2. Как разработчик Вы же понимаете разницу между разрабом, который знает фреймворк, который Вы используете, и тем, кто его не знает. С предметной областью та же фигня — "обучение на кошечках" отнимает силы, время и приводит к неизбежным ошибкам то тут, то здесь.
1. Естественно, информация через БА/СА идет не только от клиента в сторону разрабов, но и в обратную сторону.
2. Ценность хорошего интегратора именно в том, что по факту он, а не клиент определяет, что будет на выходе проекта. И свой вижн он должен это продать клиенту, да еще так, чтобы клиент думал, что это он — клиент — принял это решение, а не какие-то "прАграммистЫ" :) "Скажите, что Вам надо и мы все закодим" на больших проектах неизбежно заканчивается факапом.
John Doe
Запись полугодовой оценки персонала...