John Doe
ахах, ты в каком году живешь ... четырки и пятнашки сгнили в том году последниеЧувак, не торопись, дождись 23-го...
Аргумент в духе «в Африке вообще дети голодают»Других не осталось...
Сотрудникам Twitter поручили распечатать копии кода
Правительство России включило 11 британских заморских территорий в список «недружественных»
что делать если он хочет оторвать все обоиБрать с крашеными стенами. Коты абсолютно равнодушны к ним.
не знаю, как он переживёт переезд, в случает чего.
возвращаться назад придётся как сбережения закончатсяЕсть неплохой шанс, что у твоей бывшей страны сбережения закончатся раньше, чем у тебя. У тебя только ты, а у кошелька страны семеро с ложкой стоят. Министры и вице-премьеры...
Российский рынок интеграции в нулевых и самом начале десятых развивался по израильской модели — лучшие ресурсы были у интеграторов (правда израильская модель продуктовая). А потом, из-за цунами халявных нефтяных денег рынок перешел на калифорнийскую модель, где лучшие ресурсы у клиента, а интеграторы подгоняют им толпы "индусов". Забавно, что массовый отъезд может вернуть назад этих crème de la crème. У крупных клиентов удаленка запрещена, а интеграторы как раз могут предоставить эту "услугу" людям.
на него редко способны те люди, которые сейчас в IT называются бизнес-аналитиками1. Вполне есть. Есть даже интеграторы, которые для людей клиента проводят за деньги аж мастер-классы на тему "как вам можно заработать больше денег". Если Вы условный (полу)-монополист в своей области, то у Ваших людей появляется кругозор. Поработав с разными клиентами они видят как что у кого устроено и где через интегратора можно наладить условный обмен опытом. Клиентам это не всегда нравится и в критичных бизнес-областях в контракты могут включать пункты, что ИТ-команды, работающие на конкурентов должны сидеть в географически отдельных офисах и людей нельзя перекидывать между проектами для конкурентов в течении года-двух после окончания работы на одного из них.
2. Но такие БА дорогие, поэтому не у всякого интегратора бизнес-модель способна сдюжить такие косты. Плюс компаниям-клиентам их конечно проще нанять, т.к. они могут тратить на них маржу из своего основного бизнеса.
получается перегруженный термин «бизнес-аналитик», который начинает обозначать две слишком разные вещи.1. Почему две разные? Это вопрос не разных ролей / функциональности в проджект-флоу, а вопрос квалификации и знания отрасли и процессов со стороны БА. Какой процент знаний и контента он может сам привнести в проект, а какой придется добавлять клиентским людям.
2. Конечно БА могут быть условными "джунами" — способны только прилежно записать слова клиента и сделать простейшие логические связки между услышанным. Но это не "настоящий" БА :)
3. Если БА не способен завоевать доверие и авторитет со стороны клиента, то он не может продать (обоснованно убедить) клиенту вижн того, что нужно сделать. Ведь что-то в задачах клиента лучше решить системными доработками, а где-то клиенту нужно изменить свои бизнес-процессы. А убедить клиента менять свои бизнес-процессы — это не хрен собачий. Но такое доверие и авторитет можно завоевать только глубокими знаниями предметной области. А если связка БА/СА или не может сформировать такое вижн ввиду недостатка отраслевых знаний или не способна продать этот вижн клиенту, то это заканчивается ровно той печалью, которую Вы описываете в статье. У интегратора / разработчки а и клиента разговор слепого с глухим.
4. Так что описываемы Вами проблемы — это не то, что клиент недостаточно "понимает ИТ", это проблема того, что на проектах нет НАСТОЯЩИХ БА — неважно клиентских или Ваших собственных. Хотя из моего опыта в клиентских я не верю :) Обычно у них настолько квалифицированные люди очень быстро перестают писать спеки и уносятся вверх по корпоративной иерархии :)
В PayPal Илон вполне сам код писал, так что в курсе
Part 2 of 2
Понятно, что финтехКонкретно проект, который я расписал в предыдущей части комменте, не в финтех :) Банки упоминал чаще, т.к. они более показательны — процессы и финансы на порядок сложнее скажем телекомов или товарного ритейла.
до системного аналитика, у него задача из разряда состыковать потоки данных, зачем ему прикладная область1. В банках все вертится вокруг плана счетов, который несравнимо сложнее "обычной бухгалтерии в других отраслях". Если Вы делаете своими ресурсами большой проект, то Вам нужно знать как отражается в учете например ипотека: деньги за рассмотрение заявки, маркетинговые плюшки клиентам, сама ипотека (и ее отражение в резервах и регуляторной отчетности), деньги за "страховку" и т.п. Если у Вас разрабы и СА, не "шарящие" в банках, то задолбаешься объяснять прописные истины. Одно дело подходишь к нему и говоришь, что в этом конкретном банке это проводят вот так и он схватывает все на лету, а другое — тратишь недели и месяцы на написание талмуда какие циферки в каких полях искать и что с ними делать.
2. Как разработчик Вы же понимаете разницу между разрабом, который знает фреймворк, который Вы используете, и тем, кто его не знает. С предметной областью та же фигня — "обучение на кошечках" отнимает силы, время и приводит к неизбежным ошибкам то тут, то здесь.
нужно учитывать большой набор степеней-свободы, часть из которых может быть известен технической команде, но не известен бизнесу1. Естественно, информация через БА/СА идет не только от клиента в сторону разрабов, но и в обратную сторону.
2. Ценность хорошего интегратора именно в том, что по факту он, а не клиент определяет, что будет на выходе проекта. И свой вижн он должен это продать клиенту, да еще так, чтобы клиент думал, что это он — клиент — принял это решение, а не какие-то "прАграммистЫ" :) "Скажите, что Вам надо и мы все закодим" на больших проектах неизбежно заканчивается факапом.
Part 1 of 2
Тут есть небольшая разница. Мы же все-таки именно делаем, а не продаем.1. В конце "пищевой цепочки" на упомянутых "маркетинговых" проектах стояли ровно такие же, как у Вас, БА, СА, разрабы, DBA и прочее. И они все мои были — ничего не аутсорсил внешним командам.
2. Если Вы хотите, чтобы проект был на 100% успешен, то Вам придется продавать:
— На входе продавать не только и не сколько, что Вы сделается проект лучше всех, но и продавать (убедительно объяснять) сколько Вам потребуется времени и ресурсов, для того, чтобы проект был успешен — все ж клиенты считают, что можно еще вчера и одной левой;
— Зайдя в клиента тут же столкнетесь с проблемами, которых Вы не видели со стороны. Придется продавать (убедительно объяснять) дескоупинг первых релизов, новые сроки, изменение бизнес-процессов клиента и вотэтовотвсе.
— Так Ваше умение "сделать" критически зависит от Вашего умения "продать".
Ну а вы по сделанным проектам выдаете просто маркетинговую информацию. Из нее в реальности невозможно понять, а что на самом деле для этого нужно было сделать.1. Вы пишете, что задача ИТ — не систему запустить, а принести бизнес вэлью. То, что Вы назвали "маркетинговой информаций", и есть то самое бизнес-вэлью ИТ проекта.
2. Это не маркетинговая информация, за этими словами стояла вполне конкретная работа меня самого и моих подчиненных. Например для сокращения срока сдачи отчетности на биржу нужно было:
— Детально понять процесс закрытия финансового периода и роли отдельных людей — кто откуда какие цифры берет, как обрабатывает (в своих Экселях, естественно), какие корректировки и когда делает, кто дает решает какие из них и как делать (это обычно самые топ-манагеры и акционеры, т.к. они катастрофически влияют на стоимость компании на бирже). И это не только финансовая отчетность — все должно совпадать с внутренней управленческой отчетностью сейлзов, маркетинга, "производства" и т.п. В компании с многомиллиардными (в долларах) продажами и стоимость на бирже в десятки миллиардов долларов это непростая задача.
— Все это сделать в параллели для GAAP (та еще бухгалтерская лапша, IAS гораздо логичнее) и РСБУ, чтобы все корректировки выдавали правильную картинку в обеих версиях отчетности.
— Решить где и что можно оптимизировать и автоматизировать, чтобы сократить сроки, как перестроить процессы. Попутно решить, как аккуратно поправить неизбежные ошибки в Экселях, которые уже много лет по незнанию репортились на биржу и так, чтобы биржа не испугалась :)
— Т.к. на биржу можно подавать только аудированную отчетность, то нужно уломать аудиторов из Биг-4 пустить Вас в свои процессы, чтобы их тоже ускорить и оптимизировать. Это весьма нетривиальная задача, т.к. есть аудиторская независимость и от этого у них могут возникнуть неиллюзорные ГЛОБАЛЬНЫЕ, а не локально российские риски (привет Энрон и Артур Андерсен). Этот процесс закончился аудитом моих внутренних процессов этой компанией из Биг-4.
— В конце этой работы конечно стоят какие-то вполне конкретные доработки / разработки, но чтобы их сделать нужно пройти через все вышеозначенные шаги.
— Плюс в том, что если Вы беретесь за ТАКУЮ работу, а не просто накодить, то можете просить много денег :)
в одном из недавних проектов проблемы были в том, что шла параллельная перестройка бизнес-процессов заказчика и перетасовывались отделыНе видел еще не одного большого ИТ проекта, который не заканчивался бы этим.
приходилось один из сервисов чуть ли не через совет директоров принуждать исправляться.Никогда не продавал проекты ниже гендира или ГД-1. И если это ГД-1, то Управляющий Комитет с его участием и участием всех релевантных ГД-1 минимум раз в 2 недели. Под решениями должны подписаться все биг боссы. В большой компании всегда дофига политики, какие-то кланы со своими интересами, на которые большие ИТ проекты обязательно повлияют. Если продавать ниже, то Вас обязательно сожрут. И денег попутно не заплатят :)
Права на произведения принадлежат всему советскому народу с момента возникновения. По крайней мере так было по закону, трудовым договорам и условиям госзаказаIP на всякую художку в СССР трекали вполне по закону не хуже "загнивающего Запада". Часто в добровольно-принудительном порядке, но все по документам. Отдельно текст произведения, сценарии на их основе, образы героев, права на экранизацию внутри СССР, права на экранизацию за рубежом, права на издание за рубежом, права на показ внутри СССР, права на показ за рубежом и т.п.
эта говноконтора не имеет никаких прав как частное предприятиеСоюзМультФильм полностью государственный.
Потом узнаем, в байопике от нетфликса (который он тоже купит)Не так, Маск купит у Маска права на экранизацию биографии Маска.
Климент назвал статью
развеиваю мифы о кольцахА я назову коммент :)
снимаем лапшу после статьи MakeRings—
кольца в нашей студии получаются более прочными по сравнению с кольцами из ювелирных мастерских и магазиновС чего это вдруг? У Вас абсолютно стандартный процесс производства, который используют примерно 100500 ювелиров. У Вас какие-то другие законы физики?
что и делает его плотным (читай: прочным)Точно другие законы физики. У свинца плотность сильно выше, чем у стали. Не иначе свинец в MakeRings прочнее нее :)
Штамповка она и есть штамповка. Получаются круглые и блестящие клоны. И часто – очень хрупкие.Штампы могут выдавать усилие гораздо выше ручного вальцевания и ручной ковки. Можете дать ссылки на исследования конкретно по золоту, что штампы какую-то не такую структуру металла оставляют? Или Вы это просто так сказали? :)
Но потом оказывается (сюрприз!), что это бриллианты самой дешевой индийской огранкиИндия с большим отрывом занимает первое местно на мировом рынке огранки и полировки. Если Вы купили какое-то дорогое "брендовое" кольцо с бриллом, то наиболее вероятно, что камень был огранен и/или отполирован в Индии :)
А что с камнями в советских золотых украшениях? С уверенностью могу сказать, что 99% таких камней искусственные. В них нет абсолютно никакой ценности. Это отходы лазерной промышленности: оксид алюминия в кристаллической форме (такую форму называют корунд).1. Даже из самого массового забыли алюмосиликаты (напр. топаз) и кварцы (напр. аметист), уж не говоря про более редкие. Эти не используются как активные среды для лазеров.
2. Сапфир и рубин — это тоже корунд :)
3. Для примера цены на синтетические рубины. Вряд ли отбирали по насыщенности цвета, но даже "без особого" цвета, но большие вполне чего-то стоят.
https://www.gemsngems.com/product-category/lab-created/hydrothermal-pulled-czochralski-gemstones/hydrothermal-ruby/round-hydrothermal-ruby/page/2/
Ответственно говорю вам, что скидки в ювелирной сфере — это всегда обманСебестоимость изделия по определению очень высокая, потому что материалы дорогиеСебестоимость изделия высокая в ультра-мелкосерийке типа Вашей, т.к. на штучное количество относительно дешевых колец приходится аллокировать аренду помещения, стоимость оборудования, з/п, промо и т.п. Поэтому в ультра-мелкосерийке действительно нет маржи делать скидки. Но в сериях хотя бы в сотни изделий с маржой все норм и есть, чем с клиентом делиться.
Почему везде один и тот же ассортимент, особенно обручальных колец?украшения, выполненные вручную. Это вам не массовое производство на заводе. Такие изделия выполняются в единственном экземпляреГлянул на линейку MakeRings — модели интересные, респект. Для примера открыл те же obruchalki, которые тоже пишут статьи на vc. Сразу попались на глаза вот это:
https://obruchalki.com/product/muzhskoe-obruchalnoe-koltso-s-originalnym-uzorom-grani-faces-foto/
https://obruchalki.com/product/29780/
Всю тучу моделей obruchalki.com не стал листать, но то, что остальное из ассортимента MakeRings тоже кто-то делает — это точно. А так... ИМХО для условно обручалки Маркинская / Эпиковская спираль выглядит относительно необычно. Но там ценник другой :(
@Климент Обаляев отличная идея рискнуть применить принцип "кулинарного курса за вечер" к ювелирке. Но зачем откровенную лапшу на уши вешать и зачем остальной ювелирный рынок овном поливать?
Pei pal?
Стартап Nothing сооснователя OnePlus Карла Пея
Сдержанно позитивные комментарии от @Евгений Зыскинд на адов трэш статьи выглядят так, что обручалки.ком решили потестить новый формат — "сделай кольцо сам" :) ИМХО пора рассказать как российские клиенты ничего не нарушая могут получать помолвку с бриллом минимально адекватного размера за 50-60% от среднероссийской цены :)
Золото куётсяПрокомментируйте, как-то прошло мимо меня, а золото вообще есть смысл ковать? Не вальцевать, а именно ковать? Для стали это контроль свойств кристаллической решетки плюс (высший пилотаж) контролируемые дендриты. В золоте действительно могут образовываться дендриты разных (контролируемых свойств? В стали это же разными способами легированные структуры Fe-C, чего в золоте же так не будет ввиду свойств металла, не? Я что-то не то говорю?
делает его плотным (читай: прочным)@Климент Обаляев а че плотность у нас теперь эквивалентна "прочности"? У свинца плотность гораздо выше, чем у стали, не иначе более прочный? :)
занимаемся сложными и уникальными проектами, где зачастую до нас уже кто-то не смогОбожал продавать в таких ситуациях. Если клиент ввиду отсутствия опыта грезит розовыми пони, а конкуренты выставляли плохой лайн-ап проектной команды, то лучше на тендере завысить ценник, чтобы как бы слиться. А потом, когда "пАбедитель" тендера основательно зафейлится и выбесит клиента, можно приходить и (почти) без тендера и с хорошей маржой продать проект спасения жоп менеджмента, подписавшегося под результатами тендера :)
эффективность наших разработчиков кратно превосходит эффективность местных разработчиков с их многолетней специализацией1. ИМХО это сравнивать яблоки с апельсинами. Ин-хаус, особенно, если сидят много лет, совсем перестают работать. Ходят и рассказывают, что "ИТ — этА так сложнАА".
2. Вероятно у нас с Вами были разные проекты. Как на духу, стандартные задачи с "как-бы" ИТ проектов:
а) Сократить 30% штата финдепа самого большого банка в той стране (столько-то тыс человек к такому-то сроку :)
б) Повысить АРПУ клиентов за счет запуска кросс- и ап-селл компаний (на Х% к такому-то сроку :)
в) Сократить срок предоставления официальной аудированной отчетности на столько то недель для компании с листингом на одной из крупнейших мировых бирж. Распишу тут поподробнее, т.к. без шуток это был очень простой прямолинейный проект:
— Быстро сформировать выверенный непротиворечивый массив цифр с достаточным уровнем детальности, которые могут согласовывать куча внутренних подразделений.
— Эффективная поддержка процесса внутреннего согласования этих цифр внутри компании. Все не спят, бегают по потолку, воспаленный мозг выдает новые варианты "корректировок"; именно для этого нужен детальный уровень информации и моментально обсчитать как "новые замечательные" идеи одного подразделения отразятся на других, чтобы когда официальная отчетность зарелизится никого не посадили (без шуток).
— Оптимизировать технологию работы аудиторов из Биг-4 с информацией клиента. В четверке те еще оптимизаторы-автоматизаторы сидят сидят, чуть ли не на счетах считают (точнее black-box скрипты в Экселе), а пока они заключение не дадут отчетность релизить нельзя.
— Все вышеописанное должно было в параллели внутренне непротиворечиво поддерживать GAAP и РСБУ, чтобы какой-нибудь дюже умный аналитик из инвестбанка, получающий без дураков лям долларов в год, не откопал бы какую-то уйню и не сделал бы себе карьеру на этом откапывании.
3. На третий простой проект с отчетностью мне дали 3 мес (но я взамен попросил мнохА денег :) Плюс был в том, что это была уже много лет как полностью аутсорсенная мне ИТ-система. Но можно было бы его сделать в ситуации, когда ключевые разрабы не просто не знают отрасль и бизнес-процессы компанию, но хотя бы на пальцах не понимают принципы финансовой отчетности?
наш опыт показывает, что многолетней специализации на предметной области им не требуетсяОчевидно у нас разный опыт. Что не говорит о том, что чей-то опыт хуже — в конце концов это все о том, какие бизнес модели работоспособны.
Если мы говорим о системном аналитике, то ему прикладная область не так уж важна. Нюансов при переходе из области в область возникает не так уж и много.Это Вы же написали статью о том, что бизнес-заказчики / клиентские БА не способны сформулировать достаточно качественные для команды разработки документы. Вы пишите статью о том, что есть проблема, а в комментах на комменты говорите о том, что проблемы нет :)
любой программист мог, находясь в любом райцентре РФ, найти работодателя из Калифорнии. С "ихней" зарплатой.1. Меня всегда удивляло повсеместно плохой уровень английского у российских разрабов. За 10% эффорта, который они потратили на изучение какой-то технологии, они могли бы легко сделать +50% к з/п.
2. П1 ИМХО был связан как раз с тем, что з/п в Сберов, ВТБ и прочие окологосы платили космические з/п. Сейчас это изменится и появится мотивации учить англ и сваливать уже не в "пожарном" порядке. Правда к концу года может быть или получай отстрочку "от окопов" в обмен на запрет выезда или езжай в "окопы", но потом может уехать (если этот вопрос не потеряет актуальности).
высокомерия было бы не меньше.ИМХО часть представления о высокомерии связано не с каким-то мифическим высокомерием разработчиков, а с банальной подсознательной завистью людей, которые с ними взаимодействуют по долгу службы. Я знаю несколько world class "чисто техарков" без всякой бизнес или менеджерской составляющей, у которых годовой доход — 300К ЮСД и выше. Живут (точнее жили) в РФ из-за того, что здесь друзья, стоимость жизни низкая, а налоги — обзавидуешься. Сам не встречал, но мне кажется высокомерие может быть:
— У тех, кто внезапно из грязи в "молодых миддлов" (и при этом без особо сияющих перспектив впереди из-за неадекватности, но они об этом пока не подозревают :)
— Externally induced впечатлением из-за активной рекламы ГикБрейнс / Скиллбокс и прочих. Их бизнес — отнять кредитные деньги у грузчика из супермаркета продавая им "мечту о быстрых миллионах в ИТ". Естественно они продают идею о том, что после на выходе их говнокурсов сразу аристократические титулы жалуют :)
Большой разницы между банком и, например, с крупным ритейлером мы не заметили1. Эммм... это как раз очень плохо, но опять таки объясняет проблемы, которые Вы описали в статье. Если даже по результатам выполненных проектов Вы не увидели разницы между такими абсолютно разными отраслями, то это значит:
— Кто-то должен писать Вашим людям ОЧЕНЬ детальные спеки — прям А и Б разжевывать.
— Как детально не пиши, но т.к. с Вашей стороны люди, которые совсем не знают предметную область, всегда будет ситуация когда один понял одно, а другой — другое. И опять таки будет недовольство с Вашей стороны, что клиентские БА недостаточно вникли в Вашу техническую сторону медали.
2. Теоретически можно выстроить такую проектную работу, но это очень дорого и проект будет двигаться очень медленно.
3. Не уверен, что вообще можно выстроить долгоиграющий бизнес, если строго придерживаться Вашего подхода. Вы не хотите знать предметную область — это автоматически означает, что Вы не можете быть "настоящим" интегратором, по большей части будете работать на субподряде у них. Продавать хорошую команду разработки под какой-то стек можно, но это ИМХО уязвимая позиция. Интеграторы (и настолько продвинутые клиенты, которые могут работать интеграторами для себя) будут постоянно "красть" Ваши лучшие ресурсы. Они смогут предлагать им более высокие з/п, т.к. они их лучше "монетизируют" за счет того, что у них остается больше маржи во всей такой value chain. ИМХО Вы постоянно будете в малоперспективной роли конвейера по обучению региональных "зеленых" джунов до средне-новеньких миддлов. Из того, что видел по миру, работоспособная модель с чисто технической специализацией — это небольшие, но охрененно дорогие команды супер-опытных техарков. Интеграторам (и клиентам) их невыгодно держать ин-хаус, т.к. они поодиночке не могут их загрузить работой на фулл-тайм. А как компания (а точнее 2-3 КАМа/HR-стаффера) Вы тоже можете дать некое value added таким специалистам. "Держать нос по ветру" где по миру запускаются большие проекты на такой технологии, и менеджить рилейшеншепы, чтобы вовремя таких супер-техарков заплейсить — это тоже большая работа.
размер проекта сложностью и объемом функционалаЭто был хороший, сложный проект :) Просто не хочу называть, т.к. это будет моментальный само-деанон :)
какой смысл БА на большом проекте общаться с технической командой? Для того чтобы что?терять возможность их быстро и внятно описать в текстовом виде, чтобы исполнитель за одно прочтение все понимал и ничего не додумывал сам, это плохая идея.
Вот мы и подошли к корню проблемы из-за которой родился Ваш текст. Ваш подход:
1. Команда разработки может позволить себе обладать нулевыми знаниями предметной области.
2. Т.к. клиент хочет ставить своих БА (а рискну предположить, что это не пропроблема не в клиентских БА, а в том, что своих БА с многолетним опытом в конкретной бизнес-области конкретной отрасли у Вас нет), то это обязанность клиентского БА — и отрасль и компанию знать досконально, и суметь до мельчайших деталей расписать функционал для "абсолютно нулевых" в отрасли разработчиков.
Таких БА у клиента в принципе не может быть, работа клиентских БА — знать процессы конкретной компании (даже не отрасли вообще), а не технологии. Они с января по июль какую-то транзакционную систему пилят, а с июля по декабрь — систему отчетности. Естественно они ни в зуб ногой общаться с Вашей командой разработки в терминах конкретной технологии этой команды разработки. Поэтому это как раз ВЫ перекладываете на них ВАШУ ответственность выставить со своей стороны таких БА или СА, которые знают предметную область. По "религиозным" причинам Вы не хотите специализировать свои ресурсы, неизбежно у Вас будут те проблемы, которые Вы здесь описываете. Вы правы, что на велосипеде с квадратными колесами ездить неудобно :)
PS Причины скорее всего вряд ли "религиозные", а они скорее в том, что:
1. Разработчики со знанием предметной области стоят весьма дорого.
2. Такие разработчики не любят переключаться между отраслями / бизнес-областями, т.е. для них нужно иметь пайплайн проектов, что непросто для маленькой компании.
3. Даже если они не свалят из-за п. 2, специалистов в предметной области содержать дорого, т.к. их сложно переключать между ними.
PPS У Вас типичные проблемы роста маленького интегратора. Поверьте мне даже те, у кого сейчас 5.5К человек тоже когда-то были в Вашей ситуации. Если Вам повезет сделать внятный и прибыльнай пайплайн в какой-то отрасли / бизнес-области и, т.о. таки прийти к специализации ресурсов, эти проблемы сами собой рассосутся. Если не повезет, то ИМХО вырасти будет довольно сложно. Слишком уж много на рынке "просто команд разработки".
Вот поработал во многих, а тренингов при входе в отрасль нигде не виделВ крупных интеграторах — несколько тыс чел — делают. Иначе:
1. Оч сложно переставлять ресурсы между отраслями и предметными областями — вне зависимости от технических скиллзов продуктивность первое время слишком низкая.
2. Коммуникации с клиентом сложно выстраивать. Или Вы такого человечка "запираете в чуланчик подальше" и есть допчеловек (а значит и допкосты), который цензурирует это общение, или у клиента складывается мнение, что на проекте работают непрофессионалы.
генеральный директор крупной федеральной компании ... был такого же мнения. Он сам в прошлом программист ... и вот счастья от того, что он руководит людьми я в его глазах не наблюдал.Это у всех так — не только у программистов. ИМХО это неизбежно. "Когда у тебя 260 000 работников, ты спишь со снотворным" (с) Галицкий. Управление собственным эмоциональным состоянием становится не менее (а скорее более) важной задачей, чем управление компанией.
Крупные заводы в регионах, напримерО да, тут я с Вами полностью согласен. Я только с очень крупными B2C компаниями работал — в РФ и не в РФ. Те партнеры, которые, например, с энергетикой в РФ работают, такое рассказывают... :)
знакома с некой высокомерностью ... отечественных IT-кадров1. (Был) жесточайший дефицит кадров.
2. В РФ з/п в ИТ (была) очень высокая з/п относительно довольно низкой стоимости жизни. Но это просто эффект моды на охулиардные гос и около-гос проекты в ИТ. Сейчас эти "костры из бюджетов" зарежут в целях экономии и з/п придет в норму.
2. Не только отечественных. Просто в РФ в принципе все коммуникации очень прямолинейные, а рабочая (и не только рабочая) культура весьма агрессивна, поэтому складывается ощущение, что только в РФ так. Нет, не только в РФ так, просто там более завуалировано.
работа с людьми удовольствия почти не доставляет1. Вы звучите так, что она ВАМ удовольствия не доставляет. А это плохо для со-основателя компании. Но эта гипотеза хорошо объясняла бы те проблемы, которые Вы описали в статье и с которыми сталкивается Ваша компания.
2. Не иметь специализации/ий в каких-то бизнес-областях и отраслях может позволить себе или джун или какой-то охрененно крутой технический архитектор. Невелика ценность миддла / сеньора, которому перед началом проекта нужно проводить многодневный тренинг, чтобы разъяснить азы предметной области.
ожидая от "программистов", что они проведут цифровизацию и автоматизацию без участия бизнеса. А оно так не работает. Работы представителей бизнеса в таких процессах не меньше, чем IT-специалистов.1. Интересно, какие такие клиенты еще "не выползли из пещер"?
2. Если они есть, то к чему Ваши "многа букафф", объясняющих, что дважды два четыре? Детей все еще учат таблице умножения, но никто не пишет статьи как это важно — знать ее.
вы сейчас ссылаетесь на проект среднего размераМне кажется наоборот. Самый большой был с командой в 180 чел (это только моих) на протяжении нескольких лет.
оставить экспертизу внутри домашней команды1. Большие проекты как раз отдают тем, кто может убедительно показать опыт и понимание бизнес-части. Просто команд разработки вокруг — хоть %опой жри (но за хорошую конечно придется заплатить премию).
2. Да, конечно. Но для этого необязательно сразу передавать критичные функции клиентским ресурсам, которые для Вашей проектной команды будут "людьми со стороны". Гораздо эффективнее это делать, когда решение уже на 80-85% работает — т.е. 2-3-4 крупных релиза уже сделали — и дальше плавно передаешь поддержку и доработку остальных 15-20%. Знания дает столько же, — даже небольшие мелкие доработки заставят разобраться в том, как работает все решение, — а проектных рисков несравнимо меньше. Но такой подход надо:
а) Убедительно продать,
б) Ваш прошлый опыт должен заставить клиента к Вам прислушаться.
3. Если клиентский БА "не тянет", а неспособность эффективно медиировать диалог между бизнесом и командой разработки — это и есть "не тянет" для БА, — то кто Вам мешает убедительно, с примерами объяснить это клиенту? Дальше или клиент платит за Вашего БА или Вы отвечаете только за разработку, а интерфейс между клиентским БА и Вашими разработчиками четко и детально прописан и Вы не несете ответственность за косяки клиентского БА. Ну или Вы отказываетесь от проекта — сплошь и рядом есть тендеры, которые лучше проиграть.
договора и акты сдачи подписывали представители технической команды. Обычно это либо C-уровень либо представители бизнесаДоговор и Акт Вам может подписать только чел с доверкой от юрлица, а таких по определению немного. Но он их обычно подписывает десятки и сотни в день. Так что до этого, надо еще собрать кучу согласований от бинес-заказчиков "внизу".
эти внутренние бизнес-аналитики специалисты весьма сильные, но говорят они на бизнес языке. Технический они понимают весьма плохо1. Если клиентский БА может выдать только БТ, но неспособен разъяснить их разработчикам, то продайте клиенту системных аналитиков. СА — это тоже вполне официально определенная проектная функция.
2. У меня ощущение, что у Вашей разработки нет специализации в какой-то бизнес-области какой-то отрасли. Если разработчик один-два раза сделал тот же кредитный конвейер в разных банках, то он без всяких БА на 80% знает как может быть устроен кредитный процесс. Но если он сегодня пилит склад для какой-нибудь строительной компании, а завтра — HR систему премирования сейлзов в банке, да и еще у него опыта работы на "кровавый энтерпрайз" — пара лет, — то для него каждый раз будет как в первый раз.
вот именно там для бизнес-аналитиков приходится переводить с технического на обычный и помогать более-менее корректно ставить задачи.Мда... Все таки не делали большие проекты. БА — это часть ВАШЕЙ проектной команды. Если Ваш бизнес — перепродажа рабочих часов Ваших разрабов, то БА Вам действительно не нужны. А если у Вас нормальный большой проект с большим заказчиком, например, Вы end-to-end отвечаете за внедрение кредитного конвейера в банке, то Вам просто не заплатят денег (а скорее и неустойку вкатают за несоблюдение дедлайнов), если Вы не предъявите спеки, подписанные бизнес-заказчиками. Не клиентскими ИТшниками, которые в космосе, а конкретными людьми, отвечающими за выполнение плана розничных продаж банка. Так что Вы наймете себе БА, который и будет переводить "с технического на бизнесовый" и проблема, описанная в Вашей стате, решится сама собой. У Вас текст... Рассуждение о возможных плюсах квадратного колеса — "пусть бизнес самообразуется в ИТ", — когда квадратное уже пробовали несколько тысяч лет назад, выкинули на помойку, и с тех пор используют круглое (нанимают БА).
Блогер выложил в Twitter советы по продуктивности от нейросетиЗапись полугодовой оценки персонала...