Господин Архитектор

2021-09-18 02:30:57 Об долларовый ИТ-аутсорсинг

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

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

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

А теперь немного параллелей про валютный ИТ-аутсорсинг.

Смотрите: заграничные компании за доллары покупают "простой" и "сырой" труд разработчика здесь. Сработанный при помощи этого труда программный продукт (с высокой добавленной стоимостью и высокой ценой) спокойно и беспроблемно продается сюда обратно, многократно откачивая уже со всей страны валютную выручку, выплаченную конкретным разработчикам - продается без проблем, проще, чем масла и пластик, потому что интернет, глобализация, условные Figma и Notion можно купить, сидя в любой деревне. Описанную выше схему с нефтью это напоминает подозрительно близко, и даже стремление людей пролезть в ИТ - тоже.

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

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

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

2021-08-29 21:46:01 Об карьерный рост в ИТ

Если писать коротко - его нет. А о длинном варианте мы сейчас поговорим.

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

Типичный тимлид-"руководитель", роль которого могут предложить, будет вынужден работать больше (ответственности выше, все хотят "пишущего" руководителя), а денег при этом будет получать наравне с обычным сеньорным разработчиком. Если вас "повысили", а денег не прибавили -- вас не повысили, вас ПОНИЗИЛИ. Я здесь не беру в расчет скачки по грейдам, грейды это не рост, грейды это способ обоюдно почесать ЧСВ, при этом платить за работу меньше, чем могли бы. Удаленная работа этот тренд только закрепляет: ну, знаете, "никого не повышают по скайпу".

Жизненные истории это:
..У меня самый последний грейд, >5 раз подавался на повышение до архитектора, ни разу даже не вызвали пообщаться..
..Мне 42 года, а все, куда мне предлагают - это писать круды: "тыжпрограммист, тебе нравится педалить талоны из джиры"
.. Я отсидел свой вестинг опционов и ушёл, потому что знаю, что за 10 лет вырасти выше тимлида не получится.
Никита Проковов (tonsky) пишет, что вообще в глубоком кризисе непонимания, что надо сделать, чтобы двигаться дальше. Влад Козуля (vkozulya) в итоге прошел десятки собеседований, не нашел работу руководителем программистов и стал просто разработчиком: денег больше, ответственность четче, время на развитие тоже при нем.
В 4 компаниях, куда я приходил собеседоваться, мне не смогли буквально на пальцах показать пример, как из тимлида люди вырастали выше конкретно у них. Потому что это не случается в ИТ. Обратная сторона - нулевой кадровый резерв, когда на любое назначение зовут варяга со стороны, обычно из числа знакомых.

Дело не в вас, ребята.

Каков карьерный путь у обычного слесаря? Бригадир, мастер цеха, начальник участка, дальше в дирекцию или в руководители производства (главный механик, главный инженер), пройдя обучение за счёт компании. В дирекцию ещё и второе образование надо, финансы или экономику. А выделяет ли ИТ-работодатель бюджет на обучение обучение? На бумаге - да, а обучение чему? Обучение, нужное для вашего карьерного роста - как быть архитектором, head of engineering? Обычно нет, это просто или плюшка, как XBox в офисе, или возможность сделать вас немного опытнее, а ваш труд - дешевле. А разработчики в целом в индустрии заранее знают, что приходят без какой-либо возможности роста, но никто не парится, потому что расчитывают взять деньгами и поскакать дальше: богомол-амбассадоры работают над тем, чтобы разговоры про деньги не останавливались.

В этом смысле текущие зарплаты это ОЧЕНЬ недорого, потому что на ваш рост работодатель не тратится.

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

Полезай в корпоративного робота, Джонни, дрочи литкод, бери весло, греби круды и не выделывайся. Открыть/Комментировать

2021-08-27 00:55:19 Продакты это современный класс бюрократов
 
Когда-то в 50х, когда тейлоризм (научная эргономика и организация труда) перестал быть надеждой на светлое будущее устройства корпораций, управленческая мысль прыгнула к следущей остановке: сложно устроенными системами из людей не могут управлять простые правила, а только другие люди.

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

В наше время безудержного аджайла такой беспартийной номенклатурой-бюрократией стали продакт-менеджеры. В самом деле:

* Мало кто понимает, чем занимается конкретный продакт на конкретном месте;
* Тем не менее, любой продакт за пять минут вам обоснует, почему именно он тут ни за что не отвечает;
* Как правило, продакт сам должен назначить, за что себя пороть (OKR и все-все-все);
* Часть самых невезучих заранее назначаются в виноватые за все плохое, что происходит с динамикой компании, остальные тупо чиллят;
* Попытка подсветить эту ситуацию натыкается на аргумент "Быть этого не может, ты что-то путаешь: это у вотерфолла бюрократия, а тут -- гибкие методологии";
* Будучи нанятым, продакт стремится нанять себе в группировку еще продактов; вакансии на продакт-менеджеров просто ломятся, основной спрос генерирует Москва -- там уже фишку поняли;
* Непрерывно генерируют поток работы для всей остальной компании, но редко бывают ответственными за это или вообще не принимают эти работы у исполнителей.
* Управляется примерно так же отчетами, как и бюрократы прошлого века; для солидности и аджайлости называются метриками, KPI (ой, OKR, мы же не вотерфолл какой -то!)
* Пока вся "мыкаманда" сидит до утра, отлаживая релиз, продакт уже отправил отчет куда-то выше и поехал кушать порридж с соевым немясом.
 
..

А между тем, в далеком 1995-м, еще до бума доткомов, Эд Салливан ("NuMega") писал про задачи продакт-менеджера так:
* Формулировать требования рынка;
* Курировать экономические аспекты создаваемого продукта.
Это абсолютно исчерапывающе, и столь же непопулярно.

Но пока бюрократическая стратегия побеждает: 1. залить людьми 2. регулярно перетряхивать 3. ждать самоорганизации команды и результатов.

Почему это пока "выгодно" всем, я писал чуть раньше, и похоже, что удаленка тоже не поправит положение -- по крайней мере, в ближайшее время. Открыть/Комментировать

2021-08-24 22:41:40 Телеграфом об Го

Если вы когда-нибудь задумывались, почему язык GO получил такое название, и не знали, я вам принес ответ - GO это аббревиатура от Google Oberon. Совпадает с Обероном-2 (наследник Паскаля, тоже господин Вирт делал) с точностью до семантики.

А вы думали, почему в Го для выражения в if не нужны круглые скобки? Потому что их в Алголе/Паскале можно не писать.

Единственное, в Го подлит синтаксис из Си, а также идеи CSP (communicating sequential processes) Тони Хоара добавлены. А именно -- примитивы общения, известные в Го как "каналы", которыми общаются активные объекты Оберона, известные в Го как "горутины".

А вот концепция интерфейсов и полиморфизм на основе подтипов я не знаю, откуда взят, мне кажется, что из COM и GObject

В общем, пока все бежали от Паскаля, он нанес ответный удар. Открыть/Комментировать

2021-08-20 15:04:31 Психология IT-дедов

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

Например, транзакционная запись в БД. Я узнал что на go многие пишут CRUD-ы. Шут с ним что это просто полная чушь, но любому деду очевидно, что если ты раздеплоишь 100500 микросервисов на каждую сущность в БД, то при попытке сохранить что-то мало мальским сложное понадобится координатор распределённых транзакций. Ну чтобы при ошибке откатывать всю цепочку изменений автоматически. На уровне базы для этого есть встроенные механизмы (которые ещё и с репликацией дружат). Go-шники же при словах "координатор распределённых транзакций" смотрят ошалелыми холодными глазами и всем видом дают понять, что ты сказал щас что-то такое, что к их вселенной не относится.

Деды в курсе как масштабировать приложение на старых технологиях/baremetal и искренне не понимают на кой городить огород с контейнеризацией, когда достаточно грамотного билд-деплой пайплайна. А ещё диды помнят как в 2006м у них свой стартап крутился на паре бесхозных 360х "пентиумов" с винтами по 40 гигибайт. И стоило это примерно нихера и луку мешок. Счета за услуги облачных провайдеров ставят дедов в тупик. Они понимают, что им никогда не платили столько, сколько компания спускает в месяц на облака.

UI деды тоже делали. Хорошие деды даже понимают чем JS-подход к UI удобнее классики (абстракцией работы с UI-тредом), в остальном же MVC у них в крови ещё со времён Microsoft Foundation Classes. Ивент-луп и отрисовка изменений в данных. Ничего похожего на Redux дедам и в голову бы не пришло просто потому что а зачем. Максимум — MVVM (MVC с активной моделью, уведомляющей UI об изменениях). При виде современного веба, деды с тоской вспоминают RAD Studio — как тогда всё было просто, быстро, а главное — работало ведь! Никакого CSS, никакой групповухи с флексбоксами: куда кнопку поставил — там она и стоит. По меркам RAD Studio/WinForms/WPF современная веб-разработка чудовищно усложнена и до жути бестолкова (в смысле что результат неадекватен затраченным усилиям).

По поводу использования системных ресурсов деды пребывают в постоянном когнитивном диссонансе. Когда молодняк с криками "оборудование — ничто, понятность — всё" лихо разбрасывается огромными кусками оперативы, деды вспоминают, как в юношестве байтики экономил чтобы программа скачивалась два часа, а не три. Или чтобы отчёт обсчитывался за 4 часа, а не за 10 дней. Деды понимают, что весь софт сейчас работает херово и с ужасающим оверхедом. Вывозит только за счёт мощного и недорогого (относительно 80х-90х) железа. Это в их понимании означает "не работает".

В конце-то концов просто по-человечески больно осознавать, что ты писал очередь сообщений через файловую систему или базу данных. А современный школьник с улюлюканием берёт docker-образ NATS и втыкает его в свой проект. Ты бы и сам смог сделать NATS, но просто не успел. Кто-то оказался проворнее и удачливее. И сейчас вместо файн-тюнинга своего решения ты вынужден разбираться с нуля в чужом. И зачастую — донельзя говёном.

Бесит. Ну а кого б не бесило?

В любом случае помните, что деды могут делать как молодняк, просто не хотят. А вот молодняк делать как деды не умеет.

Такие дела Открыть/Комментировать

2021-08-18 20:46:01 Нужны ли современной разработке (по agile) архитекторы или нет?

Я немного расшифрую одну картинку: может, нужны, а может, и нет, скорее, второе.

Архитектора ради архитектора смысла нет нанимать - типовую архитектуру решения сейчас много ума не надо, чтобы поднять: микросервисы в облаке; внутри каждого микросервиса -- типовая для выбранного стека архитектура приложения.
Как сделать разные важные бизнесу вещи - знает доменный эксперт, а не архитектор обычно.
Предварительным планированием и предварительным проектированием тоже щас мало кто занимается.

Так что если вы не делаете какой-то высокопереиспользуемый актив (библиотеку, компилятор, коробку), не работаете на аутсорс, то архитектор вам не нужен. Максимум - эксперт по технологиям типа AWS, его можно назвать "архитектором", но это просто человек с опытом AWS.

..

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

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

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

(Хотите поспорить? Попробуйте вспомнить, что такое Perforce? DevPartner Studio? IBM RAD? Spark PRO? Когда вы в последний раз покупали что-то, кроме лицензии на Slack и условной IDEA? А вне их огромная индустрия платных инструментов.)

Все это к разработке и архитектуре как таковой стало иметь мало отношения, это просто сборка плохо слаженного говна из разных случайных кусков другого говна. Открыть/Комментировать

2021-08-08 19:31:16 Любопытно, что на Западе "взлетело" огромное количество так называемых people management systems. На самом деле огромная тема -- если только топики под ее управлением начать перечислять, тема бесконечная, от найма до payroll, от онбординга до карьерных треков, от управления документами до контроля пропусков и рабочего времени. А вот в России такие громкие решения неизвестны. Почему? Не знаю точно, но могу предположить:
- предприятия еще не превратились в commodities, нет стандартных практик
- есть прекрасная кастомизируемая 1С с конфигурациями
- банки шагнули сразу из 19 в 21 век, предоставив часть функциональности, связанной с управлением финансами
- "кадровик" это звучит совсем не престижно, пахнет нафталином, и не требует от руководства ничего, кроме толстой амбарной книги, ксерокс-аппарата -- трудовые книжки копировать, и ключа от офиса.
Или есть еще какие-то системные причины, как считаете? Открыть/Комментировать

2021-08-05 17:20:59 Об бигдату

Вообще, ваша xsolla это только начало. Вы@бывались, что работаете фуллтайм в трех местах на ремоуте - получите безумный "анализ" "активности" в рабочее время.

Когда это сделала xsolla, назовут мудачеством. Когда это сделает Apple или SAP, все последуют за ними.

Самое забавное, что когда я говорил, что перво-наперво ИТ-специалисты займутся оптимизацией работы других ИТ-специалистов, потому что лучше всего ее понимают, надо мной смеялись. А тут целая ИТ-команда дашборды вып@зживания готовит Открыть/Комментировать

2021-08-02 11:02:01 ..
хм
хм
..

Что же тогда сайт/мобильное приложение? Это не продукт, это СРЕДСТВА ПРОИЗВОДСТВА ПРОДУКТА. То есть сайт с бэкендом -- это ЗАВОД, который ВЫРАБАТЫВАЕТ продукт (страховки) прямо just in time по запросу пользователя, с околонулевой для нас себестоимостью. И как вы знаете, низкая цена масштабирования -- это ключевое преимущество ИТ. Вот она, появилась искомая себестоимость.

В такой понятийной базе все возвращается на свои места: команда с каждым релизом катит не продукт, нет, и никакие не улучшения в "business valuе". Команда катит улучшения в фабрику производства продукта, чтобы эта обновленная фабрика вырабатывала продукт с более оптимальным COGS, чем ее предыдущая версия. Как вариант - новая фабрика производит более продвинутый товар, но за ту же себестоимость, что означает удешевление стоимости производства ценности. Едва ли не единственный способ вложиться в business value со стороны ИТ - уменьшить себестоимость. В которую входит и стоимость сооружения более продвинутой фабрики, кстати.

А product owner (PO), управляющий продуктом, должен управлять не сайтом и не приложением. PO управляет продуктом, сценарием, который обменивает деньги клиента на продукт (=страховку), а ИТ-средства производства развивает его команда.

Давайте пройдем на примере Gmail. Ценность - "быть на связи социально приемлемым способом". Усиление ценности - "это бесплатно", "можно выбрать публичное имя", "антиспам", "поиск" и прочее. Продукт - а здесь продукт это комплексная услуга: предоставление доступа к своей почте через установленные каналы обслуживания. Вроде бы сходится.

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

Что же по этому поводу думает товарищ Скрам? А Скрам в этом месте молодец, он подтверждает наши мысли так: Your product is a vehicle to deliver your value proposition - it shouldn’t drive your value proposition. В Скрам это все заложено изначально, сюрприз - однако Скрам далеко не просто постичь самому.

https://en.wikipedia.org/wiki/Cost_of_goods_sold Открыть/Комментировать

2021-08-02 11:02:01 Об продукт в ИТ-команде

Это будет серьезный пост, который может показать разработку с той стороны, с которой на нее никогда не смотрели. Аутсорсинга не касается, так что в этом случае можно пропустить. Для остальных - затравка:
- если вы согласны, что ИТ-команда разрабатывает и релизит продукт (сайт, приложение)
- если вы согласны, что компания зарабатывает, продавая доступ к этому сайту/приложению
- если вы согласны, что product owner владеет, собственно, разработкой
- то вам точно стоит это прочитать: вы ошибаетесь. Заодно вы узнаете, каким KPI можно измерять вклад ИТ-отдела в бизнес компании.

[15 min+]

Я постараюсь донести свою мысль в аналогии, сравнением двух вымышленных компаний. О них ниже.

Пусть компания "А(грегатор)" - ИТ-"стартап", который делает сайт-агрегатор по страховым полисам. Компания "Б(исиклеты)" - собирает из комплектух и продает велосипеды. Обе эти компании очень похожи - это b2c бизнес, в котором есть реклама, продажи, производство. Только в "А" это производство - ИТ-ное, а в "Б" - железячное в пространстве и времени.

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

Есть такой показатель, COGS(cost of goods sold), или, по-русски - себестоимость проданных юнитов. Чем ниже себестоимость, тем больше прибыль на каждой сделке при прочих равных. Для этого оптимизируется склад, непрерывно отбираются и меняются поставщики, ускоряется сборка, чтобы производство тратило как можно меньше денег на каждый велосипед. Тут есть нюансы, но в общем и целом нет вопросов, выглядит здраво, да? Ну, потому что так это устроено везде.

Теперь вернёмся к нашим компьютерам, в компанию "А". Там есть ИТ-команды, как и много где. Давно ли вы видели задачи у ИТ-команд "сократить себестоимость"? Нет, такая задача иногда встречается, но будем честными - вряд ли они поднимаются в бэклоге по приоритету куда-то в область важных, если только вы не разоряете свою компанию чеками на AWS. Да и вообще не очень понятно, каким образом ИТ-команда, проедая зарплату и добавляя все новые фичи в продукт, работает над СНИЖЕНИЕМ себестоимости? И себестоимости чего? Учитывая, что себестоимость для ИТ это операционные расходы на поддержание сервиса, тестирование фич (а их все больше), и т.п.. Фантастика какая-то, нереально.

Получается удивительная картина: есть два "производства", оба делают продукты, но цели работы совершенно разные. Значит, и принципы управления одного не применимы в другом? А зачем мы тогда называем наше ИТ "производством", ведь тут вообще другая наука и теория нужны?

ИЛИ НЕТ?

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

Продукт это что-то, что реализует ценность для пользователя, и за что он нам платит деньги. И если идти нашим примером, то правильная онтология будет такой.

Компания "А" продает страховки. Основное ценностное предложение в данном случае (value) - СОСТОЯНИЕ ЗАСТРАХОВАННОСТИ, вот что принесет пользователю сделка на сайте.
Составляющие ценности, повышающие удовлетворенность клиента - это ЭКОНОМИЯ (агрегатор предложений) и СВОЕВРЕМЕННОСТЬ (выбрал и купил прямо на сайте).
А продукт - это не сайт и не мобильное приложение. Продукт это СОВОКУПНОСТЬ ВСЕХ СТРАХОВОК, КОТОРЫЕ МЫ ПРОДАЕМ/ПРОДАЛИ. Открыть/Комментировать