Илон Маск снова предупреждает об опасности искусственного интеллекта. В то время, как некоторые из нас воодушевлены идеями и зачарованы перспективами беспилотных такси, 100%-роботизированных фабрик, автоматических дронов доставки, большинство воспринимает такие заявления, как чистые фантазии. Где мы, а где это роботизированное будущее? Когда оно придёт? О каком ИИ речь, когда мы не знаем, как работает мозг?

Тут надо остановиться. Футуристы редко ошибаются в прогнозах, но только их будущее приходит в совершенно непредсказуемых формах, хотя и верное по сути. Время оглянуться вокруг - киборги уже давно, лет 30-50, значительно влияют на жизнь человечества.

Понимаете, о ком я? Сейчас объясню.

Если вы когда-нибудь получали банковский кредит, вы знакомы с процедурой скорринга. Каждому корреспонденту банк присваивает рейтинг надёжности на основании предоставленных данных. Кто, по вашему, рассчитывает этот рейтинг? Это уже давно делают специальные алгоритмы, встроенные в АБС (автоматизированную банковскую систему). В некоторых регионах (Китай) понятие социального рейтинга шагает уже далеко за границы финансового сектора.

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

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

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

Люди не дадут ИИ, нарушающему законность, вырасти до значительной величины. Зато эволюция позволит вырасти ИИ, отстаивающему законность общества и текущие нормы. Никто не хочет автоматических пушек с интеллектом, но общество уже сейчас не против автономных полицейских патрульных роботов.

Современная корпорация, опирающаяся на цифровую инфраструктуру, уже давно стала настоящим киборгом -- социотехнической системой, в которой часть функций выполняется людьми, а часть с успехом берут на себя машины. Корпорация Mail Ru Group отрастила себе Grishin Robotics, которая инвестирует в актюаторы (исполнительные механизмы) и сенсоры автономных машин.

Именно через структуры типа корпораций в наше бытие придёт ИИ, а мы с вами не просто его встретим -- каждый из нас будет отстаивать его status quo и право приказывать людям. Как и все остальные его права тоже. И не будет видеть в этом ничего странного.

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

С текущего момента я открыт для интересных предложений. Готов по запросу детально рассказать, чем занимался и каких результатов достиг.
Умею отвечать за результаты работы команд (50+ человек), а также внешних подрядчиков; поднимать производство ПО с нуля и обеспечивать его функционирование без ежедневного вмешательства (за несколько лет мы выросли с 12 до 130+ человек); определять и обеспечивать технологическую и методологическую поддержку производства софта, как для внешнего заказчика, так и продуктового коллектива

Ключевые слова: тимлид java .net, архитектор решений, руководитель производства/технический директор

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

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

В итоге мы вместе постараемся подготовить:
- Набор ALPHAs (Abstract-Level Progress Health Attribute) с отражением актуального состояния каждого
- Понимание, какие узкие места существуют в производстве
- Понимание, каких артефактов рабочих процессов не хватает для того, чтобы шагать далее максимально эффективно
- Каким этапам жизненного цикла стоит уделить максимальное внимание, чтобы не упустить успех проекта.

Кто заинтересован предложением, приглашаю в Телеграмм, контакты есть в описании канала.

А Р Х И Т Е К Т У Р А

Много раз я видел, как на просьбу "показать архитектуру" (что бы это ни значило), присылают картинки типа тех, что приведены в иллюстрации 1 и 2. Эти я взял из интернетов и других источников, это реальный мир.

Сможете себе ответить, что тут не так? Если вы считаете, что всё корректно, то вам будет интересно, читайте далее внимательно.

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

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

Вам понятно, что может делать система? Наверное, не очень. Но почему-то, когда на схеме изображается "БД", "сервер приложений", "модули API для связи", принято считать, что понятно. Я сейчас расскажу, где собака порылась - пропускается (вернее, держится "в голове") этап функционального анализа и синтеза. Архитектор-конструктор это всё "и так помнит": смотрит на модуль авторизации, понимает, что это функции авторизации, управления доступом и т.п.; смотрит на "сервис DbSrv", понимает, что это некоторая "функция общения с базой". Да и в целом тенденция такова, что один компонент (в терминах группы выполняемых функций) стараются реализовать при помощи одного модуля в структуре. А то и несколько функций на один модуль навешиваются.

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

Понятно, в чём проблема? Проблема НАСТОЛЬКО частая, что ее можно в учебники вносить: структура системы бежит впереди функционального разбиения.

Не делайте так 🙂 Начинайте с функционального анализа и синтеза. Самый простой якорь - схема user stories: каждая story должна быть точно помаплена на части (даже не компоненты) системы, прицеплена к функциям системы (даже не IT-системы, а бизнеса), и иметь понятное описание, какой рабочий продукт в процессе исполнения этой story генерируется. А уже эти функции должны опереться на приложения и модули и быть поддержаны структурой. Потому что - не забывайте - в первую очередь надо сделать довольными стейкхолдеров. Они довольны, когда все их требования и ожидания находят отражение в системе.

Пост несколько не по тематике блога, но тем не менее, ему тут место.

Чего не говорят и не пишут, когда рассказывают про то, как начинались те или иные IT-стартапы? Обычно, история выглядит как 1. или 2.:
1. Появилась безумная идея которую только и ждал рынок, её начали обкатывать в реализации, под нее построили бизнес-и IT-архитектуру, которая позволила идее развиться в стремительно растущий бизнес -> концы сошлись.
2. Появилась идея, её начали тестировать, вертеть, искать тех, кому нужна она, трансформировать в поисках клиента, наконец нашли отклик, идея всем нравится -> опять концы сошлись.

Оказывается, вся картина это 1. + 2., вернее, сначала 2, потом 1. Не бывает красивой идеи, которая внезапно пришла в голову, без 2., а после не бывает хорошего продукта без (провальных) экспериментов в 1. Если почитать _разную_ литературу, тогда открываются обе половины одного целого.

О Customer Development сейчас говорят из каждого утюга. “Ваш продут должен решать боль клиента, его проблему”. Но забывают добавить кое-что ещё.
Какую проблему клиента решал iPhone? Неудобство хардварной клавиатуры? Невозможность проверить почту на ходу? Отсутствие анимированных эмодзи?

Невозможно ответить, потому что любой вариант будет натужным, придуманным уже задним умом.

Если у клиента что-то болело, поверьте, он уже как-то её попробовал решить, или согласился, что это не такая уж и боль. There is an app for it. Уже невозможно придумать что-то новое, для несуществующего ещё рынка.

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

👆 В будущем книги и образование, определенно, изменятся. Думаю, что образование будет построено по принципам Lean Startup: будет использовать образовательные платформы, создаваться по принципам agile, формироваться на основе быстрых клиентоориентированных итераций (а/б тесты, green/blue сегменты), вовсю использовать малозатратную всеобъемлющую аналитику для молниеносной корректировки процесса

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

Что, если я скажу вам, что в течение 20 лет это всё изменится? Тренды в сторону образования, новые платформы обучения, VR, онлайн-школы делают реальной ситуацию, когда в течение жизни мы сможем сменить 5-7-10 профессий, и при этом не пострадать ни в уровне оплаты, ни в авторитете. Достаточно полугодовой подготовки при помощи правильно сбалансированного портфеля курсов и даже без живого тьютора - а где их брать-то будет? - и ты готов успешно покорять новую область. Не летун, а цифровой кочевник в профессиях. И это прекрасно

Начал строить IT-отдел с нуля в одном из финтех-стартапов. Самое сложное - перебороть майндсет типа "так, всем замереть и полгода не толкать программистов под руки, они там работают". Заработал его и сам не заметил, как именно и когда

Если вы делаете продукт b2b, не забывайте что личными настройками пользователя понадобится управлять не только самому пользователю, но и группе из службы эксплуатации/администрирования. Иначе будут возникать феномены, когда десять топ-менеджеров сидят и полдня и настраивают себе условный профиль в условной JIRA самостоятельно

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

== объявление ==
Из моих читателей в Москве кто-то хочет поруководить разработкой? Интересуют больше всего разработчики и аналитики, кто хотел бы, но пока не умеет — будем учить сильному управленческому мышлению, и за это ещё з/п платить.

Меня часто спрашивают: а вот есть идея X, до неё кто-нибудь ещё додумался? Да какая к чертям разница? Не додумался, а если додумался, то не сделал, а если сделал, то бросил, а если сделал и не бросил и работает, то можно сделать лучше, а если нельзя, то и на вашу долю хватит. Как будто на рынке есть приоритет идей, и если она кому-то в голову уже пришла, то всё, баста. Нет, граждане, это так не работает.

Все хорошие решения — очевидны, что они хорошие (после того, как найдены), но все очевидные решения обычно плохи