Edtech с2с в России текущем виде это маркетплейсы "клиент"-"преподаватель", которые:
- инвестиционными деньгами заливают маркетинговые каналы, чтобы авторскому курсу на рынке было делать нечего, только идти на площадку - попробуйте загуглить курсы и с интересом поизучайте поисковую выдачу;
- за счет этого прессует авторов и преподавателей, забирая 90%+ выручки себе (поинтересуйтесь ставкой преподавателя SkyEng, кстати: рублей эдак 100-200 за час).
Почему люди несут туда деньги? Ну, это совокупность факторов, как и у любого явления:
- хейт "официального" образования (кстати, как вам победы на последних физ и мат олимпиадах, плохое образование?)
- мантра "лучшие инвестиции это инвестиции в себя! не дай себя обмануть в другом месте!"; ну и в самом деле, при относительной бедности другие формы инвестиций не особо доступны;
- последовавшее за глобализацией вайтишничество;
- подкрепление компаниями деньгами и пиар-активностями обсуждений повестки про деньги и зарплаты -- иногда кажется, что в любом ИТ сообществе только и разговоров, что о зарплатах;
- эксплуатация комплекса ученика: надо хорошо учиться, и тогда придет успех; если успеха нет, надо еще поучиться.
Оценить ёмкость рынка я не могу, с интересом наблюдаю.
Про Edtech b2b я еще напишу, не переключайтесь.
- инвестиционными деньгами заливают маркетинговые каналы, чтобы авторскому курсу на рынке было делать нечего, только идти на площадку - попробуйте загуглить курсы и с интересом поизучайте поисковую выдачу;
- за счет этого прессует авторов и преподавателей, забирая 90%+ выручки себе (поинтересуйтесь ставкой преподавателя SkyEng, кстати: рублей эдак 100-200 за час).
Почему люди несут туда деньги? Ну, это совокупность факторов, как и у любого явления:
- хейт "официального" образования (кстати, как вам победы на последних физ и мат олимпиадах, плохое образование?)
- мантра "лучшие инвестиции это инвестиции в себя! не дай себя обмануть в другом месте!"; ну и в самом деле, при относительной бедности другие формы инвестиций не особо доступны;
- последовавшее за глобализацией вайтишничество;
- подкрепление компаниями деньгами и пиар-активностями обсуждений повестки про деньги и зарплаты -- иногда кажется, что в любом ИТ сообществе только и разговоров, что о зарплатах;
- эксплуатация комплекса ученика: надо хорошо учиться, и тогда придет успех; если успеха нет, надо еще поучиться.
Оценить ёмкость рынка я не могу, с интересом наблюдаю.
Про Edtech b2b я еще напишу, не переключайтесь.
(Утащил из Интернета и подрихтовал для понятности)
Подавляющее большинство гипотез - х%йня, и работать так не будет.
Но фаундерам не нужен тот, кто скажет им, что это х%йня и работать не будет. Им нужны те, кто скажет: "ребята, вы ох%енные, лучше всех, и это обязательно будет работать, только надо сделать вот так вот и так и еще вот так".
Парадокс в том, что это все равно получится нерабочая х%йня - потому что фаундер уже все равно придумал это вот именно так, как вам описал, и не собирается отступать от своей идеи, в которую уже влюбился. Чтобы сделать "вот так вот и еще вот так" вам самому нужно сесть и начать это делать - и не в статусе наёмника или консультанта, а кофаундера - потому что иначе все равно проект сделают по-своему, а вы только огребете негатива.
За "х%йня и так работать не будет" вы тоже огребете негатива - после того, как за вами закроют дверь.
Потом это действительно оказывается х%йней и так не работает, но если об этом напомнить, огребете негатива еще раз, потому что "х%ли вы такой умный тут, попробовали бы сделать это сами".
Подавляющее большинство гипотез - х%йня, и работать так не будет.
Но фаундерам не нужен тот, кто скажет им, что это х%йня и работать не будет. Им нужны те, кто скажет: "ребята, вы ох%енные, лучше всех, и это обязательно будет работать, только надо сделать вот так вот и так и еще вот так".
Парадокс в том, что это все равно получится нерабочая х%йня - потому что фаундер уже все равно придумал это вот именно так, как вам описал, и не собирается отступать от своей идеи, в которую уже влюбился. Чтобы сделать "вот так вот и еще вот так" вам самому нужно сесть и начать это делать - и не в статусе наёмника или консультанта, а кофаундера - потому что иначе все равно проект сделают по-своему, а вы только огребете негатива.
За "х%йня и так работать не будет" вы тоже огребете негатива - после того, как за вами закроют дверь.
Потом это действительно оказывается х%йней и так не работает, но если об этом напомнить, огребете негатива еще раз, потому что "х%ли вы такой умный тут, попробовали бы сделать это сами".
Об внедрение Скрама
Работать некому, в стране одни коучи. Вчера я видел вакансию OKR коуча. То есть буквально - человек, который никак не отвечает за результат, будет помогать командам понять, чего они хотят в эту итерацию. Очень красиво, правда?
Подводя к вопросу, расскажу, что я попытался применить принципы системной инженерии к Скраму, и результаты очень любопытные. Заодно стало понятно, за что именно отвечает скрам-тренер, и каким таким единым чиселком KPI следует измерять работу целого ИТ-департамента. Но об этом я напишу позже, а сейчас я расскажу внешнюю точку зрения. Вопрос в том, почему внедрения аджайла, Скрама и так далее находятся в состоянии "начали, но не закончилось".
Если вы посмотрите в конкретную ситуацию, которые я видел не раз, вы обнаружите одну или несколько причин из списка:
1. Это не выгодно скрам-тренеру. Ну, потому что его очень быстро попросят на выход, то есть -- прямо закрутят финансовый поток в обмен на "кейс" какой-то степени успешности. Несколько успешных кейсов, разумеется, нужны для презентации, а дальше они становятся бесполезны.
2. Это не выгодно менеджменту. Потому что задача Скрама - устранить препятствия на пути работы команды. И очень быстро становится понятно, что главным препятствием на пути работы команды становится непонимание среднего менеджмента, как вести компанию дальше - видение есть, стратегия, может быть, есть, но средний менеджмент в недоумении, как это превратить в планы. Выражаясь другими словами, внедренный Скрам быстро перемещает бутылочное горлышко на сторону бизнеса. Если раньше можно было ссылаться на священную, но очень упрямую корову ИТ, то теперь уже нельзя, ИТ готов к работе и предсказуем (почитайте: https://habr.com/ru/post/567416/). Еще по этому вопросу можно почитать саркастическую "Черную книгу скрам" (https://iselihovkin.com/bookonline)
3. Это не выгодно самим командам. Самоуправляемые команды, как идеальный газ, случаются не часто, на пути их формирования -- системный кризис, который может вылиться в масштабные увольнения не готовых к "бирюзе".
4. Скрам это дорого - я уже выше писал несколько раз, почему.
5. Банально, сейчас на скрамизацию благополучно списываются бюджеты обучения подразделений, и это всех устраивает.
Часто ситуацию поясняют философским "easy to start, hard to master", особенно тренеры, но тут очень простой ответ: потому что это не выгодно никому.
Работать некому, в стране одни коучи. Вчера я видел вакансию OKR коуча. То есть буквально - человек, который никак не отвечает за результат, будет помогать командам понять, чего они хотят в эту итерацию. Очень красиво, правда?
Подводя к вопросу, расскажу, что я попытался применить принципы системной инженерии к Скраму, и результаты очень любопытные. Заодно стало понятно, за что именно отвечает скрам-тренер, и каким таким единым чиселком KPI следует измерять работу целого ИТ-департамента. Но об этом я напишу позже, а сейчас я расскажу внешнюю точку зрения. Вопрос в том, почему внедрения аджайла, Скрама и так далее находятся в состоянии "начали, но не закончилось".
Если вы посмотрите в конкретную ситуацию, которые я видел не раз, вы обнаружите одну или несколько причин из списка:
1. Это не выгодно скрам-тренеру. Ну, потому что его очень быстро попросят на выход, то есть -- прямо закрутят финансовый поток в обмен на "кейс" какой-то степени успешности. Несколько успешных кейсов, разумеется, нужны для презентации, а дальше они становятся бесполезны.
2. Это не выгодно менеджменту. Потому что задача Скрама - устранить препятствия на пути работы команды. И очень быстро становится понятно, что главным препятствием на пути работы команды становится непонимание среднего менеджмента, как вести компанию дальше - видение есть, стратегия, может быть, есть, но средний менеджмент в недоумении, как это превратить в планы. Выражаясь другими словами, внедренный Скрам быстро перемещает бутылочное горлышко на сторону бизнеса. Если раньше можно было ссылаться на священную, но очень упрямую корову ИТ, то теперь уже нельзя, ИТ готов к работе и предсказуем (почитайте: https://habr.com/ru/post/567416/). Еще по этому вопросу можно почитать саркастическую "Черную книгу скрам" (https://iselihovkin.com/bookonline)
3. Это не выгодно самим командам. Самоуправляемые команды, как идеальный газ, случаются не часто, на пути их формирования -- системный кризис, который может вылиться в масштабные увольнения не готовых к "бирюзе".
4. Скрам это дорого - я уже выше писал несколько раз, почему.
5. Банально, сейчас на скрамизацию благополучно списываются бюджеты обучения подразделений, и это всех устраивает.
Часто ситуацию поясняют философским "easy to start, hard to master", особенно тренеры, но тут очень простой ответ: потому что это не выгодно никому.
Хабр
Гонка итераций
Выдался у меня как-то на работе хороший год. Я сделал пару серьёзных проектов, за что получил существенную прибавку к окладу. Естественно, я захотел этот опыт повторить. Пришёл к директору и говорю –...
Об продукт в ИТ-команде
Это будет серьезный пост, который может показать разработку с той стороны, с которой на нее никогда не смотрели. Аутсорсинга не касается, так что в этом случае можно пропустить. Для остальных - затравка:
- если вы согласны, что ИТ-команда разрабатывает и релизит продукт (сайт, приложение)
- если вы согласны, что компания зарабатывает, продавая доступ к этому сайту/приложению
- если вы согласны, что product owner владеет, собственно, разработкой
- то вам точно стоит это прочитать: вы ошибаетесь. Заодно вы узнаете, каким KPI можно измерять вклад ИТ-отдела в бизнес компании.
[15 min+]
Я постараюсь донести свою мысль в аналогии, сравнением двух вымышленных компаний. О них ниже.
Пусть компания "А(грегатор)" - ИТ-"стартап", который делает сайт-агрегатор по страховым полисам. Компания "Б(исиклеты)" - собирает из комплектух и продает велосипеды. Обе эти компании очень похожи - это b2c бизнес, в котором есть реклама, продажи, производство. Только в "А" это производство - ИТ-ное, а в "Б" - железячное в пространстве и времени.
Забудем на время про "А", сосредоточимся на реальных велосипедах. На какой бизнес-показатель реально может повлиять производство, над оптимизацией которого оно должно думать, если поставленный план производства в штуках товара выполняется?
Есть такой показатель, COGS(cost of goods sold), или, по-русски - себестоимость проданных юнитов. Чем ниже себестоимость, тем больше прибыль на каждой сделке при прочих равных. Для этого оптимизируется склад, непрерывно отбираются и меняются поставщики, ускоряется сборка, чтобы производство тратило как можно меньше денег на каждый велосипед. Тут есть нюансы, но в общем и целом нет вопросов, выглядит здраво, да? Ну, потому что так это устроено везде.
Теперь вернёмся к нашим компьютерам, в компанию "А". Там есть ИТ-команды, как и много где. Давно ли вы видели задачи у ИТ-команд "сократить себестоимость"? Нет, такая задача иногда встречается, но будем честными - вряд ли они поднимаются в бэклоге по приоритету куда-то в область важных, если только вы не разоряете свою компанию чеками на AWS. Да и вообще не очень понятно, каким образом ИТ-команда, проедая зарплату и добавляя все новые фичи в продукт, работает над СНИЖЕНИЕМ себестоимости? И себестоимости чего? Учитывая, что себестоимость для ИТ это операционные расходы на поддержание сервиса, тестирование фич (а их все больше), и т.п.. Фантастика какая-то, нереально.
Получается удивительная картина: есть два "производства", оба делают продукты, но цели работы совершенно разные. Значит, и принципы управления одного не применимы в другом? А зачем мы тогда называем наше ИТ "производством", ведь тут вообще другая наука и теория нужны?
ИЛИ НЕТ?
Когда я попадаю в такую ситуацию, мне начинаю считать, что сам что-то не понял. И я нашел это место: понимание действительно сломано. Когда речь идет о физичных вещах, легко назвать их своими именами, но когда мы касаемся информационных объектов, несложно допустить ошибку. Давайте покажу, как я исправился, чтобы все заработало. Вся беда выше - от того, что мы неправильно определили наш ПРОДУКТ.
Продукт это что-то, что реализует ценность для пользователя, и за что он нам платит деньги. И если идти нашим примером, то правильная онтология будет такой.
Компания "А" продает страховки. Основное ценностное предложение в данном случае (value) - СОСТОЯНИЕ ЗАСТРАХОВАННОСТИ, вот что принесет пользователю сделка на сайте.
Составляющие ценности, повышающие удовлетворенность клиента - это ЭКОНОМИЯ (агрегатор предложений) и СВОЕВРЕМЕННОСТЬ (выбрал и купил прямо на сайте).
А продукт - это не сайт и не мобильное приложение. Продукт это СОВОКУПНОСТЬ ВСЕХ СТРАХОВОК, КОТОРЫЕ МЫ ПРОДАЕМ/ПРОДАЛИ.
Это будет серьезный пост, который может показать разработку с той стороны, с которой на нее никогда не смотрели. Аутсорсинга не касается, так что в этом случае можно пропустить. Для остальных - затравка:
- если вы согласны, что ИТ-команда разрабатывает и релизит продукт (сайт, приложение)
- если вы согласны, что компания зарабатывает, продавая доступ к этому сайту/приложению
- если вы согласны, что product owner владеет, собственно, разработкой
- то вам точно стоит это прочитать: вы ошибаетесь. Заодно вы узнаете, каким KPI можно измерять вклад ИТ-отдела в бизнес компании.
[15 min+]
Я постараюсь донести свою мысль в аналогии, сравнением двух вымышленных компаний. О них ниже.
Пусть компания "А(грегатор)" - ИТ-"стартап", который делает сайт-агрегатор по страховым полисам. Компания "Б(исиклеты)" - собирает из комплектух и продает велосипеды. Обе эти компании очень похожи - это b2c бизнес, в котором есть реклама, продажи, производство. Только в "А" это производство - ИТ-ное, а в "Б" - железячное в пространстве и времени.
Забудем на время про "А", сосредоточимся на реальных велосипедах. На какой бизнес-показатель реально может повлиять производство, над оптимизацией которого оно должно думать, если поставленный план производства в штуках товара выполняется?
Есть такой показатель, COGS(cost of goods sold), или, по-русски - себестоимость проданных юнитов. Чем ниже себестоимость, тем больше прибыль на каждой сделке при прочих равных. Для этого оптимизируется склад, непрерывно отбираются и меняются поставщики, ускоряется сборка, чтобы производство тратило как можно меньше денег на каждый велосипед. Тут есть нюансы, но в общем и целом нет вопросов, выглядит здраво, да? Ну, потому что так это устроено везде.
Теперь вернёмся к нашим компьютерам, в компанию "А". Там есть ИТ-команды, как и много где. Давно ли вы видели задачи у ИТ-команд "сократить себестоимость"? Нет, такая задача иногда встречается, но будем честными - вряд ли они поднимаются в бэклоге по приоритету куда-то в область важных, если только вы не разоряете свою компанию чеками на AWS. Да и вообще не очень понятно, каким образом ИТ-команда, проедая зарплату и добавляя все новые фичи в продукт, работает над СНИЖЕНИЕМ себестоимости? И себестоимости чего? Учитывая, что себестоимость для ИТ это операционные расходы на поддержание сервиса, тестирование фич (а их все больше), и т.п.. Фантастика какая-то, нереально.
Получается удивительная картина: есть два "производства", оба делают продукты, но цели работы совершенно разные. Значит, и принципы управления одного не применимы в другом? А зачем мы тогда называем наше ИТ "производством", ведь тут вообще другая наука и теория нужны?
ИЛИ НЕТ?
Когда я попадаю в такую ситуацию, мне начинаю считать, что сам что-то не понял. И я нашел это место: понимание действительно сломано. Когда речь идет о физичных вещах, легко назвать их своими именами, но когда мы касаемся информационных объектов, несложно допустить ошибку. Давайте покажу, как я исправился, чтобы все заработало. Вся беда выше - от того, что мы неправильно определили наш ПРОДУКТ.
Продукт это что-то, что реализует ценность для пользователя, и за что он нам платит деньги. И если идти нашим примером, то правильная онтология будет такой.
Компания "А" продает страховки. Основное ценностное предложение в данном случае (value) - СОСТОЯНИЕ ЗАСТРАХОВАННОСТИ, вот что принесет пользователю сделка на сайте.
Составляющие ценности, повышающие удовлетворенность клиента - это ЭКОНОМИЯ (агрегатор предложений) и СВОЕВРЕМЕННОСТЬ (выбрал и купил прямо на сайте).
А продукт - это не сайт и не мобильное приложение. Продукт это СОВОКУПНОСТЬ ВСЕХ СТРАХОВОК, КОТОРЫЕ МЫ ПРОДАЕМ/ПРОДАЛИ.
..
хм
хм
..
Что же тогда сайт/мобильное приложение? Это не продукт, это СРЕДСТВА ПРОИЗВОДСТВА ПРОДУКТА. То есть сайт с бэкендом -- это ЗАВОД, который ВЫРАБАТЫВАЕТ продукт (страховки) прямо 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
хм
хм
..
Что же тогда сайт/мобильное приложение? Это не продукт, это СРЕДСТВА ПРОИЗВОДСТВА ПРОДУКТА. То есть сайт с бэкендом -- это ЗАВОД, который ВЫРАБАТЫВАЕТ продукт (страховки) прямо 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
Wikipedia
Cost of goods sold
carrying value of goods sold during a particular period
Об бигдату
Вообще, ваша xsolla это только начало. Вы@бывались, что работаете фуллтайм в трех местах на ремоуте - получите безумный "анализ" "активности" в рабочее время.
Когда это сделала xsolla, назовут мудачеством. Когда это сделает Apple или SAP, все последуют за ними.
Самое забавное, что когда я говорил, что перво-наперво ИТ-специалисты займутся оптимизацией работы других ИТ-специалистов, потому что лучше всего ее понимают, надо мной смеялись. А тут целая ИТ-команда дашборды вып@зживания готовит
Вообще, ваша xsolla это только начало. Вы@бывались, что работаете фуллтайм в трех местах на ремоуте - получите безумный "анализ" "активности" в рабочее время.
Когда это сделала xsolla, назовут мудачеством. Когда это сделает Apple или SAP, все последуют за ними.
Самое забавное, что когда я говорил, что перво-наперво ИТ-специалисты займутся оптимизацией работы других ИТ-специалистов, потому что лучше всего ее понимают, надо мной смеялись. А тут целая ИТ-команда дашборды вып@зживания готовит
Любопытно, что на Западе "взлетело" огромное количество так называемых people management systems. На самом деле огромная тема -- если только топики под ее управлением начать перечислять, тема бесконечная, от найма до payroll, от онбординга до карьерных треков, от управления документами до контроля пропусков и рабочего времени. А вот в России такие громкие решения неизвестны. Почему? Не знаю точно, но могу предположить:
- предприятия еще не превратились в commodities, нет стандартных практик
- есть прекрасная кастомизируемая 1С с конфигурациями
- банки шагнули сразу из 19 в 21 век, предоставив часть функциональности, связанной с управлением финансами
- "кадровик" это звучит совсем не престижно, пахнет нафталином, и не требует от руководства ничего, кроме толстой амбарной книги, ксерокс-аппарата -- трудовые книжки копировать, и ключа от офиса.
Или есть еще какие-то системные причины, как считаете?
- предприятия еще не превратились в commodities, нет стандартных практик
- есть прекрасная кастомизируемая 1С с конфигурациями
- банки шагнули сразу из 19 в 21 век, предоставив часть функциональности, связанной с управлением финансами
- "кадровик" это звучит совсем не престижно, пахнет нафталином, и не требует от руководства ничего, кроме толстой амбарной книги, ксерокс-аппарата -- трудовые книжки копировать, и ключа от офиса.
Или есть еще какие-то системные причины, как считаете?
Нужны ли современной разработке (по agile) архитекторы или нет?
Я немного расшифрую одну картинку: может, нужны, а может, и нет, скорее, второе.
Архитектора ради архитектора смысла нет нанимать - типовую архитектуру решения сейчас много ума не надо, чтобы поднять: микросервисы в облаке; внутри каждого микросервиса -- типовая для выбранного стека архитектура приложения.
Как сделать разные важные бизнесу вещи - знает доменный эксперт, а не архитектор обычно.
Предварительным планированием и предварительным проектированием тоже щас мало кто занимается.
Так что если вы не делаете какой-то высокопереиспользуемый актив (библиотеку, компилятор, коробку), не работаете на аутсорс, то архитектор вам не нужен. Максимум - эксперт по технологиям типа AWS, его можно назвать "архитектором", но это просто человек с опытом AWS.
..
И вообще, следует помнить, что изначально разработка и не была особо доступна мелким конторам. Это была вотчина военных, государства, корпораций, именно там были ресерч и инженерия.
Потом появились разного рода автоматизаторы и стартаперы, которые из технологической отрыжки, выпущенной в опенсорс по разным причинам крупными конторами, стали собирать "продукты" с целью "срубить здесь и сейчас". У них обычно даже на платный компилятор денег не запланировано.
Отсюда, кстати, появилось и недовольство, почему разработка ПО это не инженерия. Потому что туда надо звать квалифицированных инженеров-проектировщиков с фундаментальным образованием в разработке и организации разработки.
(Хотите поспорить? Попробуйте вспомнить, что такое Perforce? DevPartner Studio? IBM RAD? Spark PRO? Когда вы в последний раз покупали что-то, кроме лицензии на Slack и условной IDEA? А вне их огромная индустрия платных инструментов.)
Все это к разработке и архитектуре как таковой стало иметь мало отношения, это просто сборка плохо слаженного говна из разных случайных кусков другого говна.
Я немного расшифрую одну картинку: может, нужны, а может, и нет, скорее, второе.
Архитектора ради архитектора смысла нет нанимать - типовую архитектуру решения сейчас много ума не надо, чтобы поднять: микросервисы в облаке; внутри каждого микросервиса -- типовая для выбранного стека архитектура приложения.
Как сделать разные важные бизнесу вещи - знает доменный эксперт, а не архитектор обычно.
Предварительным планированием и предварительным проектированием тоже щас мало кто занимается.
Так что если вы не делаете какой-то высокопереиспользуемый актив (библиотеку, компилятор, коробку), не работаете на аутсорс, то архитектор вам не нужен. Максимум - эксперт по технологиям типа AWS, его можно назвать "архитектором", но это просто человек с опытом AWS.
..
И вообще, следует помнить, что изначально разработка и не была особо доступна мелким конторам. Это была вотчина военных, государства, корпораций, именно там были ресерч и инженерия.
Потом появились разного рода автоматизаторы и стартаперы, которые из технологической отрыжки, выпущенной в опенсорс по разным причинам крупными конторами, стали собирать "продукты" с целью "срубить здесь и сейчас". У них обычно даже на платный компилятор денег не запланировано.
Отсюда, кстати, появилось и недовольство, почему разработка ПО это не инженерия. Потому что туда надо звать квалифицированных инженеров-проектировщиков с фундаментальным образованием в разработке и организации разработки.
(Хотите поспорить? Попробуйте вспомнить, что такое Perforce? DevPartner Studio? IBM RAD? Spark PRO? Когда вы в последний раз покупали что-то, кроме лицензии на Slack и условной IDEA? А вне их огромная индустрия платных инструментов.)
Все это к разработке и архитектуре как таковой стало иметь мало отношения, это просто сборка плохо слаженного говна из разных случайных кусков другого говна.
Forwarded from Novikov on Soapbox
Психология 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, но просто не успел. Кто-то оказался проворнее и удачливее. И сейчас вместо файн-тюнинга своего решения ты вынужден разбираться с нуля в чужом. И зачастую — донельзя говёном.
Бесит. Ну а кого б не бесило?
В любом случае помните, что деды могут делать как молодняк, просто не хотят. А вот молодняк делать как деды не умеет.
Такие дела
Дедами в 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, но просто не успел. Кто-то оказался проворнее и удачливее. И сейчас вместо файн-тюнинга своего решения ты вынужден разбираться с нуля в чужом. И зачастую — донельзя говёном.
Бесит. Ну а кого б не бесило?
В любом случае помните, что деды могут делать как молодняк, просто не хотят. А вот молодняк делать как деды не умеет.
Такие дела
Телеграфом об Го
Если вы когда-нибудь задумывались, почему язык GO получил такое название, и не знали, я вам принес ответ - GO это аббревиатура от Google Oberon. Совпадает с Обероном-2 (наследник Паскаля, тоже господин Вирт делал) с точностью до семантики.
А вы думали, почему в Го для выражения в if не нужны круглые скобки? Потому что их в Алголе/Паскале можно не писать.
Единственное, в Го подлит синтаксис из Си, а также идеи CSP (communicating sequential processes) Тони Хоара добавлены. А именно -- примитивы общения, известные в Го как "каналы", которыми общаются активные объекты Оберона, известные в Го как "горутины".
А вот концепция интерфейсов и полиморфизм на основе подтипов я не знаю, откуда взят, мне кажется, что из COM и GObject 🙂
В общем, пока все бежали от Паскаля, он нанес ответный удар.
Если вы когда-нибудь задумывались, почему язык GO получил такое название, и не знали, я вам принес ответ - GO это аббревиатура от Google Oberon. Совпадает с Обероном-2 (наследник Паскаля, тоже господин Вирт делал) с точностью до семантики.
А вы думали, почему в Го для выражения в if не нужны круглые скобки? Потому что их в Алголе/Паскале можно не писать.
Единственное, в Го подлит синтаксис из Си, а также идеи CSP (communicating sequential processes) Тони Хоара добавлены. А именно -- примитивы общения, известные в Го как "каналы", которыми общаются активные объекты Оберона, известные в Го как "горутины".
А вот концепция интерфейсов и полиморфизм на основе подтипов я не знаю, откуда взят, мне кажется, что из COM и GObject 🙂
В общем, пока все бежали от Паскаля, он нанес ответный удар.
Продакты это современный класс бюрократов
Когда-то в 50х, когда тейлоризм (научная эргономика и организация труда) перестал быть надеждой на светлое будущее устройства корпораций, управленческая мысль прыгнула к следущей остановке: сложно устроенными системами из людей не могут управлять простые правила, а только другие люди.
Так бюрократия, впервые опробованная в госуправлении еще в 18 веке, поселилась и внутри коммерческих компаний, постепенно выйдя из под всякого контроля. Ситуация бюрократической волокиты высмеяна даже у Паркинсона в его "законах" (чиновник стремится множить подчинённых, а не соперников; чиновники создают друг другу работу и далее столь же точно).
В наше время безудержного аджайла такой беспартийной номенклатурой-бюрократией стали продакт-менеджеры. В самом деле:
* Мало кто понимает, чем занимается конкретный продакт на конкретном месте;
* Тем не менее, любой продакт за пять минут вам обоснует, почему именно он тут ни за что не отвечает;
* Как правило, продакт сам должен назначить, за что себя пороть (OKR и все-все-все);
* Часть самых невезучих заранее назначаются в виноватые за все плохое, что происходит с динамикой компании, остальные тупо чиллят;
* Попытка подсветить эту ситуацию натыкается на аргумент "Быть этого не может, ты что-то путаешь: это у вотерфолла бюрократия, а тут -- гибкие методологии";
* Будучи нанятым, продакт стремится нанять себе в группировку еще продактов; вакансии на продакт-менеджеров просто ломятся, основной спрос генерирует Москва -- там уже фишку поняли;
* Непрерывно генерируют поток работы для всей остальной компании, но редко бывают ответственными за это или вообще не принимают эти работы у исполнителей.
* Управляется примерно так же отчетами, как и бюрократы прошлого века; для солидности и аджайлости называются метриками, KPI (ой, OKR, мы же не вотерфолл какой -то!)
* Пока вся "мыкаманда" сидит до утра, отлаживая релиз, продакт уже отправил отчет куда-то выше и поехал кушать порридж с соевым немясом.
..
А между тем, в далеком 1995-м, еще до бума доткомов, Эд Салливан ("NuMega") писал про задачи продакт-менеджера так:
* Формулировать требования рынка;
* Курировать экономические аспекты создаваемого продукта.
Это абсолютно исчерапывающе, и столь же непопулярно.
Но пока бюрократическая стратегия побеждает: 1. залить людьми 2. регулярно перетряхивать 3. ждать самоорганизации команды и результатов.
Почему это пока "выгодно" всем, я писал чуть раньше, и похоже, что удаленка тоже не поправит положение -- по крайней мере, в ближайшее время.
Когда-то в 50х, когда тейлоризм (научная эргономика и организация труда) перестал быть надеждой на светлое будущее устройства корпораций, управленческая мысль прыгнула к следущей остановке: сложно устроенными системами из людей не могут управлять простые правила, а только другие люди.
Так бюрократия, впервые опробованная в госуправлении еще в 18 веке, поселилась и внутри коммерческих компаний, постепенно выйдя из под всякого контроля. Ситуация бюрократической волокиты высмеяна даже у Паркинсона в его "законах" (чиновник стремится множить подчинённых, а не соперников; чиновники создают друг другу работу и далее столь же точно).
В наше время безудержного аджайла такой беспартийной номенклатурой-бюрократией стали продакт-менеджеры. В самом деле:
* Мало кто понимает, чем занимается конкретный продакт на конкретном месте;
* Тем не менее, любой продакт за пять минут вам обоснует, почему именно он тут ни за что не отвечает;
* Как правило, продакт сам должен назначить, за что себя пороть (OKR и все-все-все);
* Часть самых невезучих заранее назначаются в виноватые за все плохое, что происходит с динамикой компании, остальные тупо чиллят;
* Попытка подсветить эту ситуацию натыкается на аргумент "Быть этого не может, ты что-то путаешь: это у вотерфолла бюрократия, а тут -- гибкие методологии";
* Будучи нанятым, продакт стремится нанять себе в группировку еще продактов; вакансии на продакт-менеджеров просто ломятся, основной спрос генерирует Москва -- там уже фишку поняли;
* Непрерывно генерируют поток работы для всей остальной компании, но редко бывают ответственными за это или вообще не принимают эти работы у исполнителей.
* Управляется примерно так же отчетами, как и бюрократы прошлого века; для солидности и аджайлости называются метриками, KPI (ой, OKR, мы же не вотерфолл какой -то!)
* Пока вся "мыкаманда" сидит до утра, отлаживая релиз, продакт уже отправил отчет куда-то выше и поехал кушать порридж с соевым немясом.
..
А между тем, в далеком 1995-м, еще до бума доткомов, Эд Салливан ("NuMega") писал про задачи продакт-менеджера так:
* Формулировать требования рынка;
* Курировать экономические аспекты создаваемого продукта.
Это абсолютно исчерапывающе, и столь же непопулярно.
Но пока бюрократическая стратегия побеждает: 1. залить людьми 2. регулярно перетряхивать 3. ждать самоорганизации команды и результатов.
Почему это пока "выгодно" всем, я писал чуть раньше, и похоже, что удаленка тоже не поправит положение -- по крайней мере, в ближайшее время.
Об карьерный рост в ИТ
Если писать коротко - его нет. А о длинном варианте мы сейчас поговорим.
Говорят, что в индустрии сейчас гораздо проще уйти куда-то вбок на +20% к зарплате, чем добиться повышения. Секрет очень прост: перейти в другую команду с повышением проще в любом случае, потому что вырасти в текущей компании не просто сложно, а вовсе невозможно. То есть в типичной ИТ компании буквально некуда расти, практически некуда, это никому не нужно, не поощряется, и компания этого не хочет. И это самоподдерживающийся процесс. Вторая половина петли обратной связи в том, что современные разработчики уже настолько настроены "поработаю год и дальше пойду", что никто этот механизм в компании и не воспринимает как недостаток.
Типичный тимлид-"руководитель", роль которого могут предложить, будет вынужден работать больше (ответственности выше, все хотят "пишущего" руководителя), а денег при этом будет получать наравне с обычным сеньорным разработчиком. Если вас "повысили", а денег не прибавили -- вас не повысили, вас ПОНИЗИЛИ. Я здесь не беру в расчет скачки по грейдам, грейды это не рост, грейды это способ обоюдно почесать ЧСВ, при этом платить за работу меньше, чем могли бы. Удаленная работа этот тренд только закрепляет: ну, знаете, "никого не повышают по скайпу".
Жизненные истории это:
..У меня самый последний грейд, >5 раз подавался на повышение до архитектора, ни разу даже не вызвали пообщаться..
..Мне 42 года, а все, куда мне предлагают - это писать круды: "тыжпрограммист, тебе нравится педалить талоны из джиры"
.. Я отсидел свой вестинг опционов и ушёл, потому что знаю, что за 10 лет вырасти выше тимлида не получится.
Никита Проковов (tonsky) пишет, что вообще в глубоком кризисе непонимания, что надо сделать, чтобы двигаться дальше. Влад Козуля (vkozulya) в итоге прошел десятки собеседований, не нашел работу руководителем программистов и стал просто разработчиком: денег больше, ответственность четче, время на развитие тоже при нем.
В 4 компаниях, куда я приходил собеседоваться, мне не смогли буквально на пальцах показать пример, как из тимлида люди вырастали выше конкретно у них. Потому что это не случается в ИТ. Обратная сторона - нулевой кадровый резерв, когда на любое назначение зовут варяга со стороны, обычно из числа знакомых.
Дело не в вас, ребята.
Каков карьерный путь у обычного слесаря? Бригадир, мастер цеха, начальник участка, дальше в дирекцию или в руководители производства (главный механик, главный инженер), пройдя обучение за счёт компании. В дирекцию ещё и второе образование надо, финансы или экономику. А выделяет ли ИТ-работодатель бюджет на обучение обучение? На бумаге - да, а обучение чему? Обучение, нужное для вашего карьерного роста - как быть архитектором, head of engineering? Обычно нет, это просто или плюшка, как XBox в офисе, или возможность сделать вас немного опытнее, а ваш труд - дешевле. А разработчики в целом в индустрии заранее знают, что приходят без какой-либо возможности роста, но никто не парится, потому что расчитывают взять деньгами и поскакать дальше: богомол-амбассадоры работают над тем, чтобы разговоры про деньги не останавливались.
В этом смысле текущие зарплаты это ОЧЕНЬ недорого, потому что на ваш рост работодатель не тратится.
Но нужен ли ваш рост и опыт работодателю? Нет, не нужен -- спасибо, мистер аджайл: опыт руководства людьми не нужен, мы же agile, заряженная команда, нам нужны скрам-коучи, а не руководители. Опыт найма и онбординга? Не нужен, у нас это все сделает HRD, вдобавок еще и систему грейдов и бонусов принесет. Опыт бюджетирования и закупок? Не нужен, у нас за это отвечает ИТ-директор. Опыт открытия филиалов и ресурсных центров? А на это место у нас племянник СЕО есть.
Полезай в корпоративного робота, Джонни, дрочи литкод, бери весло, греби круды и не выделывайся.
Если писать коротко - его нет. А о длинном варианте мы сейчас поговорим.
Говорят, что в индустрии сейчас гораздо проще уйти куда-то вбок на +20% к зарплате, чем добиться повышения. Секрет очень прост: перейти в другую команду с повышением проще в любом случае, потому что вырасти в текущей компании не просто сложно, а вовсе невозможно. То есть в типичной ИТ компании буквально некуда расти, практически некуда, это никому не нужно, не поощряется, и компания этого не хочет. И это самоподдерживающийся процесс. Вторая половина петли обратной связи в том, что современные разработчики уже настолько настроены "поработаю год и дальше пойду", что никто этот механизм в компании и не воспринимает как недостаток.
Типичный тимлид-"руководитель", роль которого могут предложить, будет вынужден работать больше (ответственности выше, все хотят "пишущего" руководителя), а денег при этом будет получать наравне с обычным сеньорным разработчиком. Если вас "повысили", а денег не прибавили -- вас не повысили, вас ПОНИЗИЛИ. Я здесь не беру в расчет скачки по грейдам, грейды это не рост, грейды это способ обоюдно почесать ЧСВ, при этом платить за работу меньше, чем могли бы. Удаленная работа этот тренд только закрепляет: ну, знаете, "никого не повышают по скайпу".
Жизненные истории это:
..У меня самый последний грейд, >5 раз подавался на повышение до архитектора, ни разу даже не вызвали пообщаться..
..Мне 42 года, а все, куда мне предлагают - это писать круды: "тыжпрограммист, тебе нравится педалить талоны из джиры"
.. Я отсидел свой вестинг опционов и ушёл, потому что знаю, что за 10 лет вырасти выше тимлида не получится.
Никита Проковов (tonsky) пишет, что вообще в глубоком кризисе непонимания, что надо сделать, чтобы двигаться дальше. Влад Козуля (vkozulya) в итоге прошел десятки собеседований, не нашел работу руководителем программистов и стал просто разработчиком: денег больше, ответственность четче, время на развитие тоже при нем.
В 4 компаниях, куда я приходил собеседоваться, мне не смогли буквально на пальцах показать пример, как из тимлида люди вырастали выше конкретно у них. Потому что это не случается в ИТ. Обратная сторона - нулевой кадровый резерв, когда на любое назначение зовут варяга со стороны, обычно из числа знакомых.
Дело не в вас, ребята.
Каков карьерный путь у обычного слесаря? Бригадир, мастер цеха, начальник участка, дальше в дирекцию или в руководители производства (главный механик, главный инженер), пройдя обучение за счёт компании. В дирекцию ещё и второе образование надо, финансы или экономику. А выделяет ли ИТ-работодатель бюджет на обучение обучение? На бумаге - да, а обучение чему? Обучение, нужное для вашего карьерного роста - как быть архитектором, head of engineering? Обычно нет, это просто или плюшка, как XBox в офисе, или возможность сделать вас немного опытнее, а ваш труд - дешевле. А разработчики в целом в индустрии заранее знают, что приходят без какой-либо возможности роста, но никто не парится, потому что расчитывают взять деньгами и поскакать дальше: богомол-амбассадоры работают над тем, чтобы разговоры про деньги не останавливались.
В этом смысле текущие зарплаты это ОЧЕНЬ недорого, потому что на ваш рост работодатель не тратится.
Но нужен ли ваш рост и опыт работодателю? Нет, не нужен -- спасибо, мистер аджайл: опыт руководства людьми не нужен, мы же agile, заряженная команда, нам нужны скрам-коучи, а не руководители. Опыт найма и онбординга? Не нужен, у нас это все сделает HRD, вдобавок еще и систему грейдов и бонусов принесет. Опыт бюджетирования и закупок? Не нужен, у нас за это отвечает ИТ-директор. Опыт открытия филиалов и ресурсных центров? А на это место у нас племянник СЕО есть.
Полезай в корпоративного робота, Джонни, дрочи литкод, бери весло, греби круды и не выделывайся.
Об долларовый ИТ-аутсорсинг
Весь конец 90х и все нулевые я и вы слушали и слышали, какие "плохие" у нас нефтяники. Они продают за доллары ресурсы, которые принадлежат "всем нам", и на эти деньги "жируют". И даже государство "не может найти на них управу", хоть и отбирает большую часть долларовой выручки т.н. бюджетным правилом. И одновременно, нефтегазовая отрасль - желанное место для работы людей: как раз потому что выручка - долларовая, стабильная, а контракты - многолетние.
Что происходило с нефтью и газом дальше? Если говорить грубо, дальше эта нефть поступала на заводы по переработке, которые превращали ее в пластик, индустриальные масла и другие высокоорганизованные субстанции с высокой добавленной стоимостью, которые за гораздо бОльшие доллары продавались обратно в Россию, откачивая таким образом гораздо больше денег, чем принося. Ведь сырая нефть стоит гораздо дешевле продуктов из нее. То есть по факту нефтяной экспорт работал как механизм ограбления населения в пользу нефтяников - деньги собираются со всей страны за заграничный импорт, а их малая часть отщепляется тем, кто продает нефтяной ресурс.
Сейчас ситуация изменилась, потому что появились собственные заводы органического синтеза. Кроме этого, было организовано системно взимание пошлин, сопровождающих такой импорт, так что он в массе и объеме стал куда меньше, незакрытыми остаются позиции материалы особо высокого качества.
А теперь немного параллелей про валютный ИТ-аутсорсинг.
Смотрите: заграничные компании за доллары покупают "простой" и "сырой" труд разработчика здесь. Сработанный при помощи этого труда программный продукт (с высокой добавленной стоимостью и высокой ценой) спокойно и беспроблемно продается сюда обратно, многократно откачивая уже со всей страны валютную выручку, выплаченную конкретным разработчикам - продается без проблем, проще, чем масла и пластик, потому что интернет, глобализация, условные Figma и Notion можно купить, сидя в любой деревне. Описанную выше схему с нефтью это напоминает подозрительно близко, и даже стремление людей пролезть в ИТ - тоже.
И по правде говоря, ИТ-аутсорсинг даже хуже, чем торговля сырой нефтью.
Потому что труба с нефтью требует непрерывного контроля, снабжения и поставки, из одного барреля нефти можно сделать конкретное количество пластика, и за каждый баррель надо заплатить. А с ИТ все ещё проще -- однажды сделанный трудом разработчика продукт, который вообще никак не принадлежит ему ни на какую долю, с почти нулевыми затратами может продаваться какое угодно число раз.
Но нефтяники, конечно, это плохие грабители страны, а валютный ИТ-аутсорсинг - "не трожь мой честно заработанный уровень жизни, падло".
Весь конец 90х и все нулевые я и вы слушали и слышали, какие "плохие" у нас нефтяники. Они продают за доллары ресурсы, которые принадлежат "всем нам", и на эти деньги "жируют". И даже государство "не может найти на них управу", хоть и отбирает большую часть долларовой выручки т.н. бюджетным правилом. И одновременно, нефтегазовая отрасль - желанное место для работы людей: как раз потому что выручка - долларовая, стабильная, а контракты - многолетние.
Что происходило с нефтью и газом дальше? Если говорить грубо, дальше эта нефть поступала на заводы по переработке, которые превращали ее в пластик, индустриальные масла и другие высокоорганизованные субстанции с высокой добавленной стоимостью, которые за гораздо бОльшие доллары продавались обратно в Россию, откачивая таким образом гораздо больше денег, чем принося. Ведь сырая нефть стоит гораздо дешевле продуктов из нее. То есть по факту нефтяной экспорт работал как механизм ограбления населения в пользу нефтяников - деньги собираются со всей страны за заграничный импорт, а их малая часть отщепляется тем, кто продает нефтяной ресурс.
Сейчас ситуация изменилась, потому что появились собственные заводы органического синтеза. Кроме этого, было организовано системно взимание пошлин, сопровождающих такой импорт, так что он в массе и объеме стал куда меньше, незакрытыми остаются позиции материалы особо высокого качества.
А теперь немного параллелей про валютный ИТ-аутсорсинг.
Смотрите: заграничные компании за доллары покупают "простой" и "сырой" труд разработчика здесь. Сработанный при помощи этого труда программный продукт (с высокой добавленной стоимостью и высокой ценой) спокойно и беспроблемно продается сюда обратно, многократно откачивая уже со всей страны валютную выручку, выплаченную конкретным разработчикам - продается без проблем, проще, чем масла и пластик, потому что интернет, глобализация, условные Figma и Notion можно купить, сидя в любой деревне. Описанную выше схему с нефтью это напоминает подозрительно близко, и даже стремление людей пролезть в ИТ - тоже.
И по правде говоря, ИТ-аутсорсинг даже хуже, чем торговля сырой нефтью.
Потому что труба с нефтью требует непрерывного контроля, снабжения и поставки, из одного барреля нефти можно сделать конкретное количество пластика, и за каждый баррель надо заплатить. А с ИТ все ещё проще -- однажды сделанный трудом разработчика продукт, который вообще никак не принадлежит ему ни на какую долю, с почти нулевыми затратами может продаваться какое угодно число раз.
Но нефтяники, конечно, это плохие грабители страны, а валютный ИТ-аутсорсинг - "не трожь мой честно заработанный уровень жизни, падло".
Об дефицит разработчиков
Пока не готов ответ на вопросы к предыдущему посту, я вынесу из комментариев и отформатирую вот такой недлинный и слегка хулиганский пост на другую тему - куда полетели зарплаты разработчиков, и кто причина дефицита? Причин несколько, одна очевидная, другие не очень.
1. COVID. Эпидемия затворничества внезапно поспособствовала развитию удаленки, а это значит, что стало всё равно, где нанимать. Поэтому глобальный рынок ИТ нормализовался вокруг какой-то цифры, к какой и поехали зарплаты. Стало все равно, где нанимать разработчика, потому что платить ему предстоит одинаково, иначе он с завтрашнего дня начнет, не вставая с кресла, работать уже на другого работодателя. Вот такой баланс. И даже те, кто не может работать на Запад - на их запросы так же оказывает давление этой средней зарплаты сеньора, они тоже подтянулись. Кто там будет разбирать, пойдет конкретный разработчик работать за границу или нет?
2. COVID, но НЕСТАНДАРТНО. Дело в том, что мы все с вами говорим о низкой производительности труда в РФ. Это касается и разработки, а как вы думали - только шахтёр в России медленно кайлом машет? Нет, программисты тоже печатают неспешнее, чем их европейские коллеги /это шутка, если кто не понял/. Суть в том, что в большинстве банков - видел своими глазами - в доковидные времена конвейер разработки установился в 6-9 месяцев. То есть - ты ставишь задачу сейчас, а через 6-9 месяцев за нее только примутся. А куда было торопиться? У нас же самый прогрессивный финтех в мире! /нет/.
И тут вдруг Ковид показал - некоторые компании за эти 6-9 месяцев могут запустить 2 версии доставки продуктов до дома. А банк все еще даже не начал работу. "Эгегегегей!" - подумали в топ-менеджменте, нас же щас уделают - WB купил банк, Яндекс купил банк и т.п. - что будет с нами? И решили ЦИФРОВИЗИРОВАТЬСЯ: топ-10 банков, не считая бюджетов, нанимают людей, чтобы этот постыдный time-to-market (TTM) превратить во что-то приличное.
Будет ли эта разработка эффективной? Не уверен. Тут торгуют TTM в обмен на эффективность. Лучше неэффективно, но сейчас, чем эффективно тогда, когда остальные уже опередили. Цель одна -- катить быстрее. Печальная дихотомия, но другой не завезли.
(Для справки: одно только iOS приложение Сбера, по слухам, пишет около 550 человек. Вот такая "производительность" в обмен на TTM)
3. Agile. Как ни странно, да. Посмотрите на предыдущий пункт: TTM поставили во главу угла. Это значит: надо быстро, надо уже сейчас, если что -- переделаем. А где линейный и регулярный менеджмент? А его нет, за "жирные" годы его смыло, остались одни продакт менеджеры, задача которых - уж точно не воспитывать из слабой команды команду посильнее. А у некоторых C*O, по из словам, вообще задача - "мотивировать замов" (С).
Смогут ли недообученные, слабо адаптированные начинающие разработчики в команде в режиме Agile-разработки делать поставку? Не думаю. Поэтому дефицит, о котором мы говорим, носит ОЧЕНЬ специфический характер.
А) Все отрывают с руками синьористых разработчиков, и зарплаты растут именно у них;
Б) Но не слишком сеньористых: в режиме пар из задницы и постоянных авралов более старшие их товарищи работать не станут, нужны такие, чтобы глаза горели, как будто _специй_ принял, и вопросов лишних не задавал (то есть 4-8 лет опыта). А над ними поставят тимлида, как я уже писал. С этих людей сняли все компанейские обязанности, которые они в силу недостаточной своей зрелости способны выполнять - найм, бонусы, оценки адаптация - и отдали в специальные структуры. Отдельный вопрос - куда расти такому тимлиду? На него ответить я не могу.
В) На рынке мешками валяются резюме менее продвинутых разработчиков; HR-ы пишут, что на каждую вакансию просматривают тысячи (кроме шуток) резюме.
Разработчиков так-то полно, не хватает тех, кто сам и без менеджмента сможет делать суперкороткий TTM.
Всем интересно, что дальше будет? Мне тоже. Позже напишу, как и собирался, во что верю.
Пока не готов ответ на вопросы к предыдущему посту, я вынесу из комментариев и отформатирую вот такой недлинный и слегка хулиганский пост на другую тему - куда полетели зарплаты разработчиков, и кто причина дефицита? Причин несколько, одна очевидная, другие не очень.
1. COVID. Эпидемия затворничества внезапно поспособствовала развитию удаленки, а это значит, что стало всё равно, где нанимать. Поэтому глобальный рынок ИТ нормализовался вокруг какой-то цифры, к какой и поехали зарплаты. Стало все равно, где нанимать разработчика, потому что платить ему предстоит одинаково, иначе он с завтрашнего дня начнет, не вставая с кресла, работать уже на другого работодателя. Вот такой баланс. И даже те, кто не может работать на Запад - на их запросы так же оказывает давление этой средней зарплаты сеньора, они тоже подтянулись. Кто там будет разбирать, пойдет конкретный разработчик работать за границу или нет?
2. COVID, но НЕСТАНДАРТНО. Дело в том, что мы все с вами говорим о низкой производительности труда в РФ. Это касается и разработки, а как вы думали - только шахтёр в России медленно кайлом машет? Нет, программисты тоже печатают неспешнее, чем их европейские коллеги /это шутка, если кто не понял/. Суть в том, что в большинстве банков - видел своими глазами - в доковидные времена конвейер разработки установился в 6-9 месяцев. То есть - ты ставишь задачу сейчас, а через 6-9 месяцев за нее только примутся. А куда было торопиться? У нас же самый прогрессивный финтех в мире! /нет/.
И тут вдруг Ковид показал - некоторые компании за эти 6-9 месяцев могут запустить 2 версии доставки продуктов до дома. А банк все еще даже не начал работу. "Эгегегегей!" - подумали в топ-менеджменте, нас же щас уделают - WB купил банк, Яндекс купил банк и т.п. - что будет с нами? И решили ЦИФРОВИЗИРОВАТЬСЯ: топ-10 банков, не считая бюджетов, нанимают людей, чтобы этот постыдный time-to-market (TTM) превратить во что-то приличное.
Будет ли эта разработка эффективной? Не уверен. Тут торгуют TTM в обмен на эффективность. Лучше неэффективно, но сейчас, чем эффективно тогда, когда остальные уже опередили. Цель одна -- катить быстрее. Печальная дихотомия, но другой не завезли.
(Для справки: одно только iOS приложение Сбера, по слухам, пишет около 550 человек. Вот такая "производительность" в обмен на TTM)
3. Agile. Как ни странно, да. Посмотрите на предыдущий пункт: TTM поставили во главу угла. Это значит: надо быстро, надо уже сейчас, если что -- переделаем. А где линейный и регулярный менеджмент? А его нет, за "жирные" годы его смыло, остались одни продакт менеджеры, задача которых - уж точно не воспитывать из слабой команды команду посильнее. А у некоторых C*O, по из словам, вообще задача - "мотивировать замов" (С).
Смогут ли недообученные, слабо адаптированные начинающие разработчики в команде в режиме Agile-разработки делать поставку? Не думаю. Поэтому дефицит, о котором мы говорим, носит ОЧЕНЬ специфический характер.
А) Все отрывают с руками синьористых разработчиков, и зарплаты растут именно у них;
Б) Но не слишком сеньористых: в режиме пар из задницы и постоянных авралов более старшие их товарищи работать не станут, нужны такие, чтобы глаза горели, как будто _специй_ принял, и вопросов лишних не задавал (то есть 4-8 лет опыта). А над ними поставят тимлида, как я уже писал. С этих людей сняли все компанейские обязанности, которые они в силу недостаточной своей зрелости способны выполнять - найм, бонусы, оценки адаптация - и отдали в специальные структуры. Отдельный вопрос - куда расти такому тимлиду? На него ответить я не могу.
В) На рынке мешками валяются резюме менее продвинутых разработчиков; HR-ы пишут, что на каждую вакансию просматривают тысячи (кроме шуток) резюме.
Разработчиков так-то полно, не хватает тех, кто сам и без менеджмента сможет делать суперкороткий TTM.
Всем интересно, что дальше будет? Мне тоже. Позже напишу, как и собирался, во что верю.
/забыл добавить: Agile и скрам сам по себе не то чтобы эффективный. Он гибкий, в смысле -- можно быстро развернуться, это правда, но - гибкость дается не бесплатно, в недельной итерации Scrum около 30% времени уходит на обязательные встречи (не спорьте, у меня цифры на руках - лучше посмотрите Селиховкина). С дистанционной работой это соотношение стало еще хуже. То есть мы работаем _медленнее_, поэтому надо больше, БОЛЬШЕ разработчиков, да не абы каких, а тех, кто умеет работать без менеджмента/
Об работу на два фронта
Недавно посмотрел эпатажный доклад какого-то iOS разработчика, где докладчик предлагал (не скажу "агитировал") искать работу на 2 компании в одно и то же рабочее время, поясняя на примерах плюсы, минусы, первые шаги и другое обоснование,:
- как работать так мало, чтобы только не выгнали
- какие задачи брать, чтобы выглядеть занятым и подольше не "спалиться";
- куда стоит идти, а где заметят, что ты работаешь не только на них.
При этом призывает не работать больше 8 часов, то есть речь не о совместительстве.
Параллельно докладчик упомянул, что тема в ИТ-сообществе не особо обсуждаемая, зато после выступлений за кулисами к нему подходят несколько человек с просьбами пособить обустроиться именно так. Почему пишу "эпатажный" - после выступления какой-то из комитетов отказался выставлять запись на публику, руководствуясь, видимо, какими-то соображениями о добре и зле 🙂
У меня по этому поводу возникло много мыслей, в том числе и желание покидать камнями в сторону работодателей -- это по их воле устроиться в два места и работать на "отцепись", чуть выше минимума выгоднее, чем тащить, расти и стремиться на своём основном месте.
Но в том, что касается основной темы доклада, я -- не одобряю, и вот почему.
--
Основной пойнт, вокруг которого все крутится: разработка - вещь ненормируемая. Это следствие и того, что задачи нередко друг от друга отличаются в десятки раз, и производительности двух разработчиков тоже могут заметно отличаться, и вообще двух похожих задач не бывает, сплошное RnD. В общем, каждая отдельная задача в разработке, если по-честному брать -- это маленький проект, и если ими управлять как проектом, то накладные расходы превысят любой профит.
Поэтому работодатель в этом месте договаривается о некотором негласном контракте -- он отказывается от нормирования задач об разработчиков, и разработчиков между собой -- в обмен на то, что разработчик со своей стороны сам обязуется прилагать максимальные усилия к работе в потоке задач. Работодатель не требует точить 100 сторипойнтов в час (и оценивать, отмерять, вводить план по сторипойнтам), а разработчик обещает, что он будет точить так много, как только сам сможет, и сам ориентироваться на свои способности. Ну а там -- посмотрим, пределы толерантности широкие, потому что это выгодно всем.
И вот в этом месте негласный контракт нарушается -- разработчик решает не прикладывать усилия к максимизации, как ранее условились, а напротив, эксплуатирует знание о том, что сторона работодателя отказалась оценивать его по какой-то общей для индустрии, этой компании, этого проекта шкале, а согласились на индивидуальную оценку способностей.
И под такое нарушение подводится база: работодатель плохой и наживается на разработчике -- надо нажиться в ответ; бизнес бесчеловечный, поэтому надо кинуть его раньше, чем он тебя кинет; главный критерий успеха это количество заработанных денег, поэтому данный способ -- верный, а остальное -- корпоративный булшит.
На то, что это нарушает мораль, намекают и проблемы у таких "стахановцев", которые докладчик описывает: полный улет кукухи на Кассиопею, безосновательно включившийся "режим IDDQD" у таких разработчиков и прочая коррупция ценностных устоев.
На мой взгляд, некрасиво, поэтому не поддерживаю.
Недавно посмотрел эпатажный доклад какого-то iOS разработчика, где докладчик предлагал (не скажу "агитировал") искать работу на 2 компании в одно и то же рабочее время, поясняя на примерах плюсы, минусы, первые шаги и другое обоснование,:
- как работать так мало, чтобы только не выгнали
- какие задачи брать, чтобы выглядеть занятым и подольше не "спалиться";
- куда стоит идти, а где заметят, что ты работаешь не только на них.
При этом призывает не работать больше 8 часов, то есть речь не о совместительстве.
Параллельно докладчик упомянул, что тема в ИТ-сообществе не особо обсуждаемая, зато после выступлений за кулисами к нему подходят несколько человек с просьбами пособить обустроиться именно так. Почему пишу "эпатажный" - после выступления какой-то из комитетов отказался выставлять запись на публику, руководствуясь, видимо, какими-то соображениями о добре и зле 🙂
У меня по этому поводу возникло много мыслей, в том числе и желание покидать камнями в сторону работодателей -- это по их воле устроиться в два места и работать на "отцепись", чуть выше минимума выгоднее, чем тащить, расти и стремиться на своём основном месте.
Но в том, что касается основной темы доклада, я -- не одобряю, и вот почему.
--
Основной пойнт, вокруг которого все крутится: разработка - вещь ненормируемая. Это следствие и того, что задачи нередко друг от друга отличаются в десятки раз, и производительности двух разработчиков тоже могут заметно отличаться, и вообще двух похожих задач не бывает, сплошное RnD. В общем, каждая отдельная задача в разработке, если по-честному брать -- это маленький проект, и если ими управлять как проектом, то накладные расходы превысят любой профит.
Поэтому работодатель в этом месте договаривается о некотором негласном контракте -- он отказывается от нормирования задач об разработчиков, и разработчиков между собой -- в обмен на то, что разработчик со своей стороны сам обязуется прилагать максимальные усилия к работе в потоке задач. Работодатель не требует точить 100 сторипойнтов в час (и оценивать, отмерять, вводить план по сторипойнтам), а разработчик обещает, что он будет точить так много, как только сам сможет, и сам ориентироваться на свои способности. Ну а там -- посмотрим, пределы толерантности широкие, потому что это выгодно всем.
И вот в этом месте негласный контракт нарушается -- разработчик решает не прикладывать усилия к максимизации, как ранее условились, а напротив, эксплуатирует знание о том, что сторона работодателя отказалась оценивать его по какой-то общей для индустрии, этой компании, этого проекта шкале, а согласились на индивидуальную оценку способностей.
И под такое нарушение подводится база: работодатель плохой и наживается на разработчике -- надо нажиться в ответ; бизнес бесчеловечный, поэтому надо кинуть его раньше, чем он тебя кинет; главный критерий успеха это количество заработанных денег, поэтому данный способ -- верный, а остальное -- корпоративный булшит.
На то, что это нарушает мораль, намекают и проблемы у таких "стахановцев", которые докладчик описывает: полный улет кукухи на Кассиопею, безосновательно включившийся "режим IDDQD" у таких разработчиков и прочая коррупция ценностных устоев.
На мой взгляд, некрасиво, поэтому не поддерживаю.
Рекрутер в ИТ это то препятствие, которое стоит между компанией, отчаянно нуждающейся в персонале, и высококлассными инженерами на рынке
Тут пятничный разговор зашёл, так что..
А похвастайтесь в комментариях самыми сложными и чудовищными тестовыми заданиями, которые вас просили сделать?
А похвастайтесь в комментариях самыми сложными и чудовищными тестовыми заданиями, которые вас просили сделать?
Щас будет странный вопрос, не переключайтесь.
А нет ли среди моих читателей теплых выходов на проверенные и крупные (20+ человек) аутсорсные ИТ-команды строго из Румынии и Молдавии? Есть долгоиграющий и перспективный заказ на разработку - с территориальными, к сожалению, ограничениями.
Если срастётся через рекомендацию — с меня хорошее вознаграждение: например, макбук.
Шутки про цыган и лошадей слать не надо
А нет ли среди моих читателей теплых выходов на проверенные и крупные (20+ человек) аутсорсные ИТ-команды строго из Румынии и Молдавии? Есть долгоиграющий и перспективный заказ на разработку - с территориальными, к сожалению, ограничениями.
Если срастётся через рекомендацию — с меня хорошее вознаграждение: например, макбук.
Никогда не знаешь, где найдешь, где потеряешь
На сайте издания "Военное обозрение" авторы учинили серию статей про рождение советской ПРО. Которая сразу, со второй статьи, превратилась в серию о советской микроэлектронной и компьюерной программе, с фактами от 20 годов и до начала 90-х. Крайне любопытный, обширный материал, с отсылками к фамилиям, названиям и другим историческим артефактам.
Я собрал статьи, которые нашел, в подборку ниже по дате выхода. Надеюсь, вам будет так же интересно, как и мне.
Лебедев и МЭСМ
https://topwar.ru/182766-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-ii-lebedev-i-bruk.html
Брук и М-1
https://topwar.ru/182774-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-iii-bruk-i-m-1.html
"БЭСМ против Стрелы"
https://topwar.ru/182787-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-iv-bjesm-protiv-strely.html
Варшавский договор
https://topwar.ru/183309-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chehija-vstupaet-v-igru.html
Проект ЭПОС
https://topwar.ru/183401-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-vi-proekt-jepos.html
Назад в СССР
https://topwar.ru/183599-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-vozvraschaemsja-v-sssr.html
"Юдицкий строит суперкомпьютер"
https://topwar.ru/183763-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-judickij-stroit-superkompjuter.html
Кристадины, диоды и транзисторы
https://topwar.ru/184029-rozhdenie-sovetskoj-pro-kristadiny-triody-i-tranzistory.html
Транзисторные машины СССР
https://topwar.ru/184319-rozhdenie-sovetskoj-pro-tranzistornye-mashiny-sssr.html
"Долгий путь к ИС"
https://topwar.ru/184420-rozhdenie-sovetskoj-pro-dolgij-put-k-integralnym-shemam.html
"Осокин против Килби"
https://topwar.ru/184823-rozhdenie-sovetskoj-pro-osokin-protiv-kilbi-kto-na-samom-dele-izobrel-mikroshemu.html
"Зеленоград и Ленинград"
https://topwar.ru/184867-rozhdenie-sovetskoj-pro-zelenograd-i-leningrad.html
"Атака клонов"
https://topwar.ru/184877-rozhdenie-sovetskoj-pro-ataka-klonov.html
Модулярный компьютер
https://topwar.ru/185254-rozhdenie-sovetskoj-pro-velichajshij-moduljarnyj-kompjuter.html
Убийство 5Э53
https://topwar.ru/185282-rozhdenie-sovetskoj-pro-istorija-ubijstva-5je53.html
"Конец модулярных машин"
https://topwar.ru/186510-rozhdenie-sovetskoj-pro-konec-moduljarnyh-mashin.html
"Звездные войны"
https://topwar.ru/186782-rozhdenie-sovetskoj-pro-karcev-i-chelomej-strojat-zvezdnye-vojny.html
"Конец Юдицкого"
https://topwar.ru/186572-rozhdenie-sovetskoj-pro-konec-judickogo.html
"Кибернетика"
https://topwar.ru/187039-rozhdenie-sovetskoj-pro-ot-bitvy-za-britaniju-do-kibernetiki.html
"Механические мозги"
https://topwar.ru/187407-rozhdenie-sovetskoj-pro-mehanicheskie-mozgi.html
"Винер. Человек и миф"
https://topwar.ru/187844-rozhdenie-sovetskoj-pro-viner-chelovek-i-mif.html
"На пути к Киберкоммунизму"
https://topwar.ru/188128-rozhdenie-sovetskoj-pro-na-puti-k-kiberkommunizmu.html
"Конец Карцева"
https://topwar.ru/188689-rozhdenie-sovetskoj-pro-konec-karceva.html
Бэсм. Сага
https://topwar.ru/189578-rozhdenie-sovetskoj-pro-bjesm-saga-chast-i.html
"Величайший советский компьютер"
https://topwar.ru/189956-rozhdenie-sovetskoj-pro-bjesm-saga-chast-ii.html
За и против БЭСМ-6
https://topwar.ru/189960-rozhdenie-sovetskoj-pro-bjesm-saga-chast-iii.html
"БЭСМ-6. Итоги"
https://topwar.ru/189962-rozhdenie-sovetskoj-pro-bjesm-saga-chast-iv.html
"На пути к Единой Системе"
https://topwar.ru/190327-rozhdenie-sovetskoj-pro-na-puti-k-edinoj-sisteme.html
Конец советской компьютерной программы
https://topwar.ru/190377-rozhdenie-sovetskoj-pro-konec-sovetskoj-kompjuternoj-programmy.html
"Приключения С-300"
https://topwar.ru/190481-rozhdenie-sovetskoj-pro-prikljuchenija-s-300.html
Долгое восхождение на "Эльбрус"
https://topwar.ru/190990-rozhdenie-sovetskoj-pro-dolgoe-voshozhdenie-na-jelbrus.html
"При Сталине такого не было"
https://topwar.ru/190999-rozhdenie-sovetskoj-pro-pri-staline-takogo-ne-bylo.html
"Эль-Берроуз"
https://topwar.ru/191202-rozhdenie-sovetskoj-pro-jel-berrouz.html
На сайте издания "Военное обозрение" авторы учинили серию статей про рождение советской ПРО. Которая сразу, со второй статьи, превратилась в серию о советской микроэлектронной и компьюерной программе, с фактами от 20 годов и до начала 90-х. Крайне любопытный, обширный материал, с отсылками к фамилиям, названиям и другим историческим артефактам.
Я собрал статьи, которые нашел, в подборку ниже по дате выхода. Надеюсь, вам будет так же интересно, как и мне.
Лебедев и МЭСМ
https://topwar.ru/182766-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-ii-lebedev-i-bruk.html
Брук и М-1
https://topwar.ru/182774-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-iii-bruk-i-m-1.html
"БЭСМ против Стрелы"
https://topwar.ru/182787-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-iv-bjesm-protiv-strely.html
Варшавский договор
https://topwar.ru/183309-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chehija-vstupaet-v-igru.html
Проект ЭПОС
https://topwar.ru/183401-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-chast-vi-proekt-jepos.html
Назад в СССР
https://topwar.ru/183599-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-vozvraschaemsja-v-sssr.html
"Юдицкий строит суперкомпьютер"
https://topwar.ru/183763-unikalnaja-i-zabytaja-rozhdenie-sovetskoj-pro-judickij-stroit-superkompjuter.html
Кристадины, диоды и транзисторы
https://topwar.ru/184029-rozhdenie-sovetskoj-pro-kristadiny-triody-i-tranzistory.html
Транзисторные машины СССР
https://topwar.ru/184319-rozhdenie-sovetskoj-pro-tranzistornye-mashiny-sssr.html
"Долгий путь к ИС"
https://topwar.ru/184420-rozhdenie-sovetskoj-pro-dolgij-put-k-integralnym-shemam.html
"Осокин против Килби"
https://topwar.ru/184823-rozhdenie-sovetskoj-pro-osokin-protiv-kilbi-kto-na-samom-dele-izobrel-mikroshemu.html
"Зеленоград и Ленинград"
https://topwar.ru/184867-rozhdenie-sovetskoj-pro-zelenograd-i-leningrad.html
"Атака клонов"
https://topwar.ru/184877-rozhdenie-sovetskoj-pro-ataka-klonov.html
Модулярный компьютер
https://topwar.ru/185254-rozhdenie-sovetskoj-pro-velichajshij-moduljarnyj-kompjuter.html
Убийство 5Э53
https://topwar.ru/185282-rozhdenie-sovetskoj-pro-istorija-ubijstva-5je53.html
"Конец модулярных машин"
https://topwar.ru/186510-rozhdenie-sovetskoj-pro-konec-moduljarnyh-mashin.html
"Звездные войны"
https://topwar.ru/186782-rozhdenie-sovetskoj-pro-karcev-i-chelomej-strojat-zvezdnye-vojny.html
"Конец Юдицкого"
https://topwar.ru/186572-rozhdenie-sovetskoj-pro-konec-judickogo.html
"Кибернетика"
https://topwar.ru/187039-rozhdenie-sovetskoj-pro-ot-bitvy-za-britaniju-do-kibernetiki.html
"Механические мозги"
https://topwar.ru/187407-rozhdenie-sovetskoj-pro-mehanicheskie-mozgi.html
"Винер. Человек и миф"
https://topwar.ru/187844-rozhdenie-sovetskoj-pro-viner-chelovek-i-mif.html
"На пути к Киберкоммунизму"
https://topwar.ru/188128-rozhdenie-sovetskoj-pro-na-puti-k-kiberkommunizmu.html
"Конец Карцева"
https://topwar.ru/188689-rozhdenie-sovetskoj-pro-konec-karceva.html
Бэсм. Сага
https://topwar.ru/189578-rozhdenie-sovetskoj-pro-bjesm-saga-chast-i.html
"Величайший советский компьютер"
https://topwar.ru/189956-rozhdenie-sovetskoj-pro-bjesm-saga-chast-ii.html
За и против БЭСМ-6
https://topwar.ru/189960-rozhdenie-sovetskoj-pro-bjesm-saga-chast-iii.html
"БЭСМ-6. Итоги"
https://topwar.ru/189962-rozhdenie-sovetskoj-pro-bjesm-saga-chast-iv.html
"На пути к Единой Системе"
https://topwar.ru/190327-rozhdenie-sovetskoj-pro-na-puti-k-edinoj-sisteme.html
Конец советской компьютерной программы
https://topwar.ru/190377-rozhdenie-sovetskoj-pro-konec-sovetskoj-kompjuternoj-programmy.html
"Приключения С-300"
https://topwar.ru/190481-rozhdenie-sovetskoj-pro-prikljuchenija-s-300.html
Долгое восхождение на "Эльбрус"
https://topwar.ru/190990-rozhdenie-sovetskoj-pro-dolgoe-voshozhdenie-na-jelbrus.html
"При Сталине такого не было"
https://topwar.ru/190999-rozhdenie-sovetskoj-pro-pri-staline-takogo-ne-bylo.html
"Эль-Берроуз"
https://topwar.ru/191202-rozhdenie-sovetskoj-pro-jel-berrouz.html
Военное обозрение
Уникальная и забытая: рождение советской ПРО. Лебедев и МЭСМ
Мы остановились на том, что к концу 1950-х в СССР не имелось ни одного компьютера, способного эффективно решить задачу наведения для противоракеты. Но, постойте, мы же были одними из пионеров компьютерной техники? Или нет? На самом деле история советских…