turkhale

пикабушник
Искать "турханов sdu2020"
поставил 0 плюсов и 0 минусов
отредактировал 0 постов
проголосовал за 0 редактирований
6087 рейтинг 68 подписчиков 163 комментария 41 пост 2 в "горячем"
2

Большой бардак больших систем

Жан-Франсуа Женест, chief scientist Airbus содержательно раскрывает тезис про то, как государство да и любая регулятивная система, отвлеченная от физического мира и логики/рациональности, мешает людям лучше жить. Идиоты-менеджеры, вот это все. Включайте русские субтитры, перевод качественный.

-6

Господам разработчикам, которые считают, что руководители непоследовательны в своих решениях

Господам разработчикам, которые считают, что руководители непоследовательны в своих решениях, рекомендую представить, как бы они писали программы если бы:

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

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

- объекты бы наследовали поведение от других объектов, которые вам неизвестны, и взаимодействие между которыми не описано. И вдруг выяснялось бы, что два компонента не могут работать вместе потому что. А вот непонятно почему, "описание алгоритма в тетрадке у Чуня".

- неработающий компонент нельзя было бы переписать, заменить и прочее. Сиди и думай, как сделать так, чтобы все работало в обход.

- любой компонент может сам исчезнуть из программы и у вас есть 2 недели на то, чтобы придумать, как все должно работать без него.

- любой компонент исчезает из программы на 1 месяц в год. Делайте что хотите.

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

Update. Ах да, отладчика еще нет.

Господам разработчикам, которые считают, что руководители непоследовательны в своих решениях Менеджер, Разработчики
9

«747: Создание первого в мире джамбо-джета и другие приключения из жизни в авиации»

По сути, это его автобиография. Сейчас Джо Саттеру 90 лет.


Рос пятым ребенком у своего отца и восьмым – у своей матери. Родители – эмигранты из Европы – папа из Словении, мама – уже забыл, откуда. Познакомились уже в Сиэттле.


Рос в Великую Депрессию. Работал разносчиком газет с 11 лет. Под боком их поселка был (на минуточку) завод фирмы «Боинг», основанной в 1916 году. Джо разносил газеты и потом ехал на велике к забору испытательного поля «Боинга», смотреть, как испытывают новые самолеты.


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


Фирма «Боинг» была в жопе в плане коммерческой авиации и держалась за счет оборонки.


«Дуглас» и «Локхид» же были фаворитами. В пропеллерной авиации. Но «Боинг» сделал ставку на авиацию реактивную и вложился до последнего в лаборатории, аэродинамические трубы, и (важно!) взаимоотношения с авиакомпаниями. Так появился «Боинг-707», снимающийся в фильме «Аэропорт» по Хейли, например, который убрал дальних предков «Аэрбаса» («Комету») и по перформансу, и по безопасности, а пока до «Дугласа» и «Локхида» доходило, что же произошло, они безнадежно отстали навсегда.


С тех пор «Боинг» сначала проводил опросы авиакомпаний на тему какой самолет сейчас востребован (вместимость, дальность, грузоподъемность) а потом уже начинал разработку новой модели.


Джо Саттер командовал группой инженеров-аэродинамиков из 20 человек.


50-60е годы. Все съезжают с катушек на тему сверхзвуковой авиации. Британцы начинают делать свою «Супер-Каравеллу 223» или как ее там, потом у них кончается бабло, они объединяются с французами, у французов тоже кончается бабло, но они успеют в итоге получить «Конкорд».


Наши строят модельки на базе «МиГа-21», в итоге плюют и тырят чертежи «Конкорда», добавят к этому разработанные в ходе космической программы ноу-хау по титановым технологиям и получат такой же «Ту-144» (там интересно тоже было все).


Американцы же запускают проект «Боинг-2707». В два раза больше «Конкорда» и в полтора раза быстрее «Ту-144». Все, включая авиакомпании, верят, что победа за высокой оборачиваемостью пассажиров, поэтому надо летать быстро, и, как с «Боингом-707», кто первый выведет на рынок принципиально новую модель, тот и папа.


На карту поставлено все.


В программу «Боинг-2707» вброшены лучшие инженеры, лучшие менеджеры, лучшие современные офисы, немеряно средств, у всех эйфория, правительство платит, дорогие командировки, презентации, отели, красивые модели, сверхзвуковые аэродинамические трубы и у всех лиловые штаны впридачу.


И тут приходит главный невоенный клиент «Боинга» - компания «Pan Am» (исчерпывающе описан их колоритный босс Жан Трипл, умение которого брать всех за горло через яйца (или наоборот) держало в стрессе всех авиа-вендоров от западного побережья до восточного) – и говорит «Чуваки, я ОЧЕНЬ жду ваш сверхзвуковик, но у меня уже сейчас пассажиропоток – не разгребешь. СРОЧНО выдайте мне БОЛЬШОЙ и тупой самолет пока, чтоле. Чтобы отгрызть побольше рынка. А там подоспеет 2707 ваш и мы всех уделаем».


Сложно отказать Жан Триплу, даже когда гонка технологий в разгаре, да еще и Правительство США размещает заказ, от которого невозможно отказаться (на минуточку участие в изготовлении «Сатурна-5» - лунной ракеты, той самой). Потому что гонка Правительством, а стальная хватка сомкнута вы абзацем выше читали, где.


Но really, Жан, не до тебя сейчас. Как бы от тебя попроще отделаться? Это ж все равно факин-временное решение...


ВОТ ОНО: ПРОГРАММА БОИНГ-747. (Если что – здесь и далее «Программа» - это «Программа проектов»)


Берем... кто у нас из менеджеров остался, кого не особо жалко? Саттер? В подчинении 20 человек, а проектная группа – несколько тысяч? Нормально, справится! Не менеджеров же из 2707 отзывать ради такой фигни! Инженеров ему, которых мы в 2707 не взяли, лузеров всех этих, в общем... Жану Триплу надо через два года, а средний срок разработки 3-5 лет? Да хрен ли там разрабатывать, сделают гроб с двиглом, выпустим единиц 50, ну упадут 5, заплатим компенсации, все равно их потом на 2707 заменять. *торжественно* Мистер Трипл! Наши лучшие инженеры will deliver the brand-new Boeing in 2 years (на задних рядах – 2 года? Он ох%ел???) from scratch as demanded! (Только отъе%ись, пожалуйста, и не мешай больше).


Всем, кто как-то связан с проектами – ничего такая ситуация не напоминает? (Вопрос риторический)


Вся дальнейшая программа была полным адом в двух актах.


Акт первый: «Остаточный принцип».

Вся проектная группа раскидана по нескольким разным заводам «Боинга», е-мэйлов нет, Саттер и менеджеры делают по 100 миль в день, мотаясь между офисами, кульманы набиты тесно в старые полусписанные помещения например с бУхающим круглосуточно по голове прессом за стенкой, штампующим детали для 737х, работают 6-7 дней в неделю по 12 часов. Ну, обычный проект, в общем.


Трипл хочет какбэ несуществующий на тот момент А380 – чтоб двухэтажный, два ряда окон и вообще пафосно. Еще он хочет, чтобы после того, как войдет в строй 2707, все эти гробы переделали в грузовики.


Важно – широкофюзеляжных самолетов еще нет в природе. Не изобрели. И по сути у всех в голове стоит образ «Боинга-707» (3+3 кресла, один проход) только двухэтажного. Компонуют и так и эдак, получается полный шыт. И пассажиров не успеть эвакуировать, если что, и в грузовик не переделать, и салоны неудобные.


Саттер упертый. Он пробует прикинуть одноэтажный самолет. Чтобы влезли туда заявленные 400 пассажиров – нужно сделать 3+4+3 и два прохода в огромной трубе. Смешно то, что одноэтажный вариант сложнее двухэтажного – но как все складывается!


В итоге разработка одноэтажного самолета идет полным ходом. Чтобы можно было запихивать в девайс негабаритные грузы, решают поднять кабину вверх – чтобы нос откидывался. То есть – типо будет такая широкая труба, а на ней – горб «с глазами» обтекаемый. Не 2707, не красавец, ясный пень, да 50 машин всего, потерпят. Зато it meets the requirements.


Важно: Все делают 2707. Там праздник, эйфория, и реки дорогого виски усердно глушат оформляющееся предчувствие надвигающегося п%здеца. Программа 747 чета там колупается с чем-то по углам и никого не парит.


Внезапно стальной холод в районе горла прямо между ног поднимает у топ-борды волну паники – Иппать! Трипл! Время-то идет! Если мы ему не сдадим в срок этот долбанный 747, то *большой глоток, недуматьдальшеобэтом* Саттер! Срочно! Статус программы! Доложить!


Саттер докладывает, с ходом работы, прогнозами, и промежуточными результатами. Топ-борда, холодея – «А где второй этаж?... Заказчик же ясно говорил про второй этаж?» Упертый Саттер – «На хер второй этаж!» Фармацевты Сиэттла за вечер делают месячный оборот по валидолу.


Убедили Трипла в два приема.


Сначала приехал к нему на встречу мега-сэйлз Боинга. Вот вы говорите – искусство презентации, пауэрпойнт, интонации, жесты... Чувак приехал в офис Pan Am. Там Триппл с командой – уже превентивно дымится. Чувак – Триплу «извини, брателло, лажа выходит со вторым этажом. Но мы твоих 400 душ за рейс и так поднимем, на одной палубе». Трипл (фигея от такой наглости, решает, как кот, поиграть с жертвой, перед тем как придушить) «И это какой же ширины у него будет фюзеляж?» Сэйлз Боинга тут открывает портфель и достает обычную веревку. Просит одного из участников встречи взять конец веревки и встать у одной стены. Сам берет другой конец и отходит к противоположной стене. Веревка почти натягивается. А сидят они в понтовой и большой переговорной комнате. Кожа, дуб, золотые чернильницы, что у них там было в 60х.


Сэйлз: «В этой веревке – ровно 20 футов, диаметр секции прототипа. Так что, как видите, фюзеляж будет чуть больше, чем эта комната». И делает паузу, зная Трипла, и давая Триплову воображению увидеть, как золото, кожа, дуб, панели и картины вот это все, прямо вот так, как есть, летят через Атлантику, и вот так вот в ряд стока кресел по цене за каждый билет, ну, скажем... И ни у кого больше такого предложения нет!


Еще раз – не было на тот момент еще таких летающих переговорок.


Трипл чувака из Боинга не убил на месте за столь кардинальное изменение параметров, что было абсолютной удачей презентации с веревкой. С простой веревкой! Это как в криминальном чтиве – «Приходит какой-то матьего урод и грабит банк с простым телефоном!»


Окончательно все срослось, когда Трипл приехал на завод, а там ему построили в натуральную величину две секции – одноэтажную и двухэтажную. Он походил по обеим, все понял... но в бизнес-мире не все так просто. Просто так стерпеть кидалово со вторым этажом – пусть из лучших побуждений – это пацаны засмеют. А настоять на двухэтажном ужасе – пассажиры проголосуют долларом и уйдут к конкурентам, чем летать на таком... и тут Трипл видит горб с кабиной над основной конструкцией. За кабиной горб спадает более плавно – аэродинамика. Трипл (не выпуская ничьих яиц) протягивает стальную руку и указует на горб – «Это че?» Команда Боинга - «Хер знает нам просто кабину поднять нужно было ну мы думали сделать помещения, чтобы там экипаж отдыхал на длинных перелетах...» Трипл (тихо и с опасным льдом в голосе) - «Чтобы там экипаж, простите, что?» Пауза. «Бизнес-класс туда».


То есть как бы и перед пацанами за два этажа ответил, и дизайн нормальный получил.


Акт второй: «А по утру они неизбежно проснулись».

Конец 60х. Лунная программа. Война в Корее. Война во Въетнаме. Позитивный экономический допинг от Второй Мировой выветрился. А тут еще и сверхзвуковая нереальная дура только на стадии дизайна и космические счета за испорченные в отелях Вашингтона ковры. И все это – из бюджета Правительства. Короче, бабло кончается и у американцев.


Сворачиваются военные заказы, государственные программы с сомнительной перспективой (тем более что авиакомпании уже получают первые прогнозы о расходе топлива сверхзвуковиков на одного пассажира и начинают пересматривать свои стратегии в сторону подхода «медленно-но много»), одним словом, Боингу наступают финансовые кранты. Гос-средства откачаны, глубокий безнадежный минус, перерасходы на техподдержку, потому что и с текущими моделями не все OK, и все выглядит уже настолько отстойно, что ни один банк не дает кредит, а прикидывает, как он будет потрошить активы клиента после банкротства.


Единственная программа, на которую остается зафикисрованный спрос – 747.


Надежда. Спасение. Соломинка. Если удастся впарить Триплу. Он же хотел купить?


Вся топ-команда топ-генералов разворачивается на 180 градусов и в панике – САТТЕР!!!


То есть из ада «программа, которая забыта, unwanted baby» герой со своими 4500 ютящимися по углам инженерами попадает в ад «программа, про которую вспомнили на полпути, в панике, не понимая, что там происходит и не в состоянии вникать, а в состоянии только вопить быстреебля! и чтотакдорого???».


Там дальше много прекрасного.


Руководство программы ссыт докладывать наверх реальное состояние дел. Саттера вызывают на Совет Директоров и говорят – братан, твой проект жрет too much. Ты должен сократить 1000 инженеров. Упертый Саттер грустно думает «Мне ПЦ. Это Боинг, вся моя жизнь, и мой любимый проект, самолет-какого-еще-не-было, вся моя душа там, а еще трое детей, кредит за дом, а сейчас кризис и работу не найти, и понятно, что они сейчас меня сольют, чтобы прикрыть свои факапы» но все-таки говорит – «хер вам а не сократить 1000. Хотите успеть в срок – давайте еще 800».


Что характерно – совещание закончилось молчанием, и Саттер оказался в вакууме. Потом, в кулуарах, президент Боинга сказал кому-то «ладно, хорошо чувак работает, старается, не трогайте его». Но Саттеру этот фидбэк ни одна сцуко не передала и он три месяца ходил на работу с ожиданием, что сейчас его встретят приказом об увольнении. А потом просто опять втянулся и забил.


Про чтотакдорого было еще полно косяков типа – 747 же тяжелый. Поэтому у него сзади четыре стойки шасси. Чисто геометрически две из них должны быть поворотные, иначе самолет не сможет развернуться. Наверху сказали чтотакдорого и зарубили поворотный механизм как ненужное усложнение и удорожание конструкции.


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


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


Центральная глава книги, кстати, называется «Я ХОЧУ УВОЛИТЬСЯ».


На первом выкате самолета Саттеру не дали сказать речь. Вообще в президиум не позвали.


Топ-генералы очень хотели, чтобы 747 совершил первый вылет в годовщину первого полета братьев Райт. Символизм, все дела. Упертый Саттер даже уже говорить ни с кем не стал. Он видел, что реально полететь месяца на три позже, и шел по своему плану.


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


Саттера вызвал на ковер руководитель программы. Достал из ящика стола красивую, как игрушка, ажурную, блестящую и лакированную модель первого в истории самолета Райт. «Мне таких на заказ сделали, я думал их раздавать VIP-гостям на презентации первого полета. Но ты, сцуко, не смог обеспечить это вовремя». И с этими словами – херак самолетик об пол! Осколки брызгают во все стороны. Упертый Саттер, не повышая тона, спокойно объясняет, что именно было важно доделать на тот момент и каким нужно быть дебилом, чтобы выталкивать в воздух сырой самолет такого класса и размера, да еще и принципиально новый. «Однако беседа на этом не закончилась», пишет автор, «ему понадобилось еще полчаса, чтобы выпустить пар». Когда руководитель выпустил пар, Саттер сказал «я это, модельку заберу?» - «Валяй, собирай, если надо». Саттер собрал все осколки, и потом попросил ребят при аэродинамической трубе (тех, которые делают модели для испытаний, профи по моделькам) склеить.


«Этот склеенный самолетик до сих пор стоит у меня в кабинете.

Как память о всех выдержанных испытаниях на проекте 747».


Источник https://the-bvjdbx.livejournal.com/119317.html (Виктор Ерухимович)

Показать полностью
4

"Не люблю консультантов!" - "Ты просто не умеешь их готовить".

Командный метод не подходит для управления людьми знания, например, консультантами. Чтобы управлять ими, надо:

- Быть менее иррациональным и работать с иррациональностью других;

- Играть по роли, дисциплинированно исполнять практики;

- Играть в команде.


В конце текста приведен алгоритм работы с консультантами.


На занятиях по тактике на военной кафедре нас учил суровый майор Редькин, любитель военного романа "Черви" Флэнагана. Он любил поговорить про НАТОвскую агрессию, но военное дело знал крепко и умел понятно и без мата объяснять законы поведения в бою.

"Если вы попали на минное поле, то надо остановиться и замереть!" И потом мы отрабатывали команду: "Стой!" В самых разных условиях, в самый неожиданный момент, пока это не вошло в навык. "Если вы попали под огонь, надо бежать на противника и стрелять по нему!" "Почему?", - удивлялись мы. "Потому что, когда вы ведете огонь, он прячется, вы приближаетесь и можете лучше прицелиться". "Понятно", отвечали мы. И отрабатывали команду: "Марш бегом, огонь!"

На одном занятии Редькин был особенно загадочен. Обычно он сразу задавал вопрос по пройденному материалу и повторял при этом: "Золотая триада обучения - объяснение, повторение, закрепление". А тут он ходил вдоль парт и выбирал жертву. Мы затихли, это было не к добру. "Если ты попал на минное поле, что надо делать, Соломин?" "Остановиться". "Если по тебе ведут огонь, что надо делать?" "Бежать на противника и вести огонь". "Правильно, правильно. А если ты попал на минное поле и по тебе ведут огонь, то что надо делать?" "Подпрыгнуть!" - пошутил кто-то сзади. "Не подпрыгнуть, а встать и ответить на вопрос", - прервал его Редькин. Шутник встал и помявшись несколько секунд ответил: "Не знаю, нельзя же одновременно стоять и бежать". "Верно! Тем не менее это типовая ситуация засады. Тропа заминирована, и по вам ведут огонь из укрытия. Повторю вопрос - что делать будете, курсанты?" Ответа не знал не только шутник, его не знал никто.

Майор выдержал паузу, обвел глазами класс и сказал: "Правильный ответ - надо бежать на противника и вести огонь". "Но мы же подорвемся!" - обиженным голосом отозвался шутник. "Подорвутся не все, а только часть. Оставшиеся добегут и смогут вступить в бой. А если вы будете стоять на месте, вас всех перестреляют по одиночке как в тире".

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

Если командный метод управления не годится для организации работы людей знания, то что сработает?

"Не люблю консультантов!" - "Ты просто не умеешь их готовить". Консалтинг, Бизнес, Текст
Показать полностью 1
23

"9 женщин могут родить ребенка за 1 месяц, если одна из них на 8-м месяце беременности" и другие фразы нашего бизнес-аналитика

Машин лёрнинг и Пашин лёрнинг.


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


Цель любого моделирования - влиять на людей.


Люди спотыкаются о кочки, а не о горы, но именно горы загораживают путь.


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


Дорогая лента, объясни мне одну вещь.

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

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


Хороший лётчик умеет делать всё то же, что и плохой, но, кроме того, достоверно знает, чего нельзя делать.


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


Как хорошо скрипты писать!

К IT не надо приставать,

Не надо кодеров трясти:

«Ну напиши, ну напиши!»

Не надо умолять, браниться:

«Ну, напиши ещё страницу».

Не надо звать,

Не надо ждать,

А можно взять

И написать!


У каждой продажи есть пять основных препятствий: нет потребности, нет денег, нет спешки, нет желания, нет доверия.


"Наконец, завершил работу над изобретением. Разочарован тем, что никто не умеет читать."

Гуттенберг. Серия "Исторические твиты"


Борис был молодой судостроительный конструктор, его всего один раз увозили с совещания в больницу. Тогда ему поставили инсульт. Поэтому за руку с ним еще никто не здоровался, не дорос. В клуб избранных входили только те, кого увозили с инсультом хотя бы два раза. Но сегодняшнее совещание вполне могло стать для Бориса пропуском в мир избранных.


Всем руководителям проектов, которые жалуются на нехватку ресурсов, жесткие сроки и политические приоритеты начальства посвящается:

https://the-bvjdbx.livejournal.com/119317.html


"Чего ты читаешь эти стандарты?" - говорили они. "Эти знания прямо сейчас не нужны!" - говорили они.

Когда они понадобятся, времени не будет. Все просто.


Знакомый разработчик рассказывает. Приходит запрос: "Дорогая Ольга, настрой, пожалуйста, регулярную репликацию между базами данных А и Б. Подробное описание механизма смотри вложение". Вложение:

"9 женщин могут родить ребенка за 1 месяц, если одна из них на 8-м месяце беременности" и другие фразы нашего бизнес-аналитика Мудрость, Аналитик, Текст, Длиннопост

Заказчик, который вместо того, чтобы озвучить потребности, начинает диктовать разработчику функциональную архитектуру, получит такое: "Женщина: «Господи, пошли мне кого-нибудь настойчивого и уверенного в себе, кого-нибудь, кто будет считать меня своей вкусной конфеткой, изо всех сил будет ко мне тянуться, а давать спать по ночам не будет».

- «Ну, я даже не знаю, -ответил Господь, - ну вот тебе комары "


Весы, гороскоп на год.

На старте проекта вы обсуждаете, какую стратегию выбрать - быстро спуститься с горы вон к той тёлке (mvp) или медленно спуститься и покрыть все стадо (waterfall). На практике вы будете медленно спускаться вон к той тёлке. Она будет убегать вначале, а потом окажется, что это овца. Вы назовёте это Эджайлом и сделаете доклад на конференции.


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


Разговор с рекрутером: "Вы сейчас ищете работу?" - "Да не столько ищу, сколько выбираю".


"Че-то сложно ты объясняешь. Давай на пальцах объясни". - "У меня столько пальцев нет, чтобы это объяснить".


Статус "все непросто" имеют право ставить только программисты. Остальные должны ставить статус "я тупой (но все просто)".


Подрядчики строительства АЭС Ханхикиви-1 в Пюхяйоки, которая возводится по проекту Росатома, ждали, пока проснутся болотные лягушки.

А вы говорите, для чего нужна концепция стейкхолдеров.


Начальник, помни, что 80% качества создается в последние 30% времени. Срезая срок на 20% ты ухудшаешь качество в 3 раза.


Исследование психологов из Виргинского Университета показало, что половина людей согласна получить удар электрическим током вместо 10-минутных размышлений на заданную тему.


- Средний СЕО читает 60 книг в год.

- Было бы лучше, если бы он перечитывал 10 основополагающих книг всю жизнь. Куда лучше.


Только в момент написания текста вы можете понять, насколько же небрежно вы мыслите.

Ричард Гуиндон

Показать полностью 1
9

Почему нельзя доверять единственной модели ситуации, а наблюдения должны всегда сдвигать наши оценки ситуации?

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

Но сестра решила, что проблема была с сердцем, на это ее навел сине-черный цвет кожи младенца. Она заподозрила пневмоперикард, состояние, когда воздух заполняет пространство вокруг сердца, сжимает его и оно перестает биться. Она была в ужасе потому что уже был случай, когда из-за пневмоперикарда погиб ребенок еще до постановки диагноза. Медсестра попыталась остановить подготовку к операции, она закричала: "Это сердце!" Но ей показали на монитор сердечных биений, кооторый показывал пульс 130 ударов в минуту. Но сестра не сдавалась, вырвалась из рук человека, который держал ее и приказала всем заткнуться, пока она выслушивала стетоскопом сердце младенца. Оно не билось. Медсестра начала делать непрямой массаж сердца, а когда в комнату ворвался старший неонатолог, она насильно дала ему в руку шприц и сказала: "Это пневмоперикард. Вставляйте в сердце". Вошел рентгенолог с результатами снимка и подтвердил диагноз медсестры. Старший неонатолог взял шприц и выпустил воздух из груди младенца. Его жизнь была спасена, цвет кожи медленно вернулся к нормальному розовому. Позже группа поняла, что их ввело в заблуждение. Монитор сердечных сокращений показывал электрическую активность, а не истинные биения сердца новорожденного. Нервы в сердце младенца действительно давали команды мышцам биться, но мышцы просто не могли исполнить эти команды. И только медсестра поняла, что надо проверить сердцебиение обычным способом.

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

Всякий человек смертен (бо́льшая посылка)

Сократ — человек (меньшая посылка)

------------

Сократ смертен (заключение)

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

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

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

Похороните уже стюардессу, начните думать хотя бы в парадигме 18 века, я уж не говорю про современный вариант байесовского подхода в варианте Джеймса.

5535

Как думают системные инженеры

Кардиологи и системные инженеры встретились, чтобы обсудить создание искусственного сердца. Главный кардиолог стал рассказывать про то, как работает человеческое сердце. Через пять минут его перебивает один системный инженер: "Извините, а обязательно, чтобы сердце находилось в груди? Нельзя ли его поместить в бедро, где его легче будет достать?" Кардиолог удивился, он никогда о таком не думал. Справившись с удивлением, он продолжил рассказ. Через пять минут его прервал другой системный инженер: "Извините, а зачем нужно одно большое сердце? Нельзя ли сделать несколько маленьких, распределенных по организму, которые синхронизируются между собой?" О таком тоже никто раньше не думал.


По Edward Crawley, Bruce Cameron, Daniel Selva 2016

-3

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 2/2)

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

Что такое план развития и как правильно гармонизировать. И в этом случае ситуация, которая описана на левой части диаграммы, была большой проблемой для ИТ, потому что приложения были сложными для изменения. Приложения ограничивали возможность экспериментов наверху, где бизнес как раз и хотел гибкости в части продуктовых линеек и бизнес-моделей. А приложение не могло обеспечить этой гибкости. С другой стороны, внизу приложение было крайне разнообразным, оно работало на всех видах аппаратного обеспечения и мейнфреймах, Linux, Windows, я действительно имею в виду, что там было все что угодно. Так что это был худший случай, когда внизу у вас разнообразие, которое вы оплачиваете, и эта инфраструктура ничего не дает вам в плане вариативности бизнес-модели. Вы не можете продать полис страхования, потому что поддержка бизнеса и вовлечение клиента находится на разных серверах.

Так что правильной стратегией гармонизации была гармонизация внизу. Убрать разнообразие инфраструктуры, перевести все на Linux, поместить в контейнер, автоматизировать развертывание и функционирование и резко уменьшить платформу. Джеймс Люис только что рассказал о роли платформ. Вам не нужна гармонизация, вам нужна возможность гибко экспериментировать с бизнес-моделью, не так ли?

Было бы глупо гармонизировать все сверху донизу, потому что разнообразие наверху — это ровно та штука, которая двигает бизнес. Поэтому ваше корпоративное управление ИТ должно четко понимать, где надо затянуть винты потуже, а где их ослабить и это очень важный момент в практике архитектуры предприятия. А то вы получите ситуацию, когда во всех частях организации появятся люди, которые будут гармонизировать все подряд, так как кто-то когда-то им сказал, что гармонизация — это хорошо, потому что она экономит деньги. Но гармонизация — это одновременно плохо, потому что она убивает бизнес. Если вы проведете гармонизацию там, где она не нужна, то вы сделаете ситуацию хуже. Все это кажется очень простым, но проблема в том, что ваш план может быть отличным, но реальность будет отличаться от плана. И с этим ничего нельзя поделать. Знаете, у нас есть поговорка в Германии, что если реальность не соответствует планам, то это проблема реальности, а не планов. Вы столько времени потратили на составление планов, они не могут быть плохими по определению.

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

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

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

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

Вот такая цепочка создания ценности.

И есть три вещи, которые должен делать архитектор предприятия, чтобы эта цепочка создания ценности заработала:

- Связи

- Абстракции

- Принятие решений


И чтобы объяснить суть работы архитектора предприятия, я покажу мое любимое определение этого термина.

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 2/2) Бизнес, Информационные системы, Длиннопост

Это очень простое определение и теперь, посмотрев на эти уравнения, я думаю, все понимают суть работы архитектора. Это формула Блэка-Шоулза для оценки стоимости опционов, за которую выдали Нобелевскую премию.


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


Собираюсь я переместить приложения в облако или не собираюсь этого делать? Нужен мне такой опцион или нет? Надо ли мне иметь возможность динамически масштабировать приложение или это не нужно? Я могу продать такие опционы, они называются архитектура без состояний и масштабируемая архитектура. Эти опционы стоят денег, точно также, как и опционы на финансовых рынках и эта формула вычисляет стоимость такого опциона. За этот опцион надо заплатить, потому что он позволяет отказываться от своих решений в будущем и это имеет ценность. Я не знаю точно, что мне понадобится, поэтому я покупаю опцион, он дает мне возможность пойти в будущем как налево, так и направо, что имеет для меня ценность. Можно построить деревья решений и легко посчитать стоимость таких решений и стоимость опционов. И это основная штука, которую делает практика архитектуры предприятия и ключевая дискуссия, которая происходит между архитектором предприятия и бизнесом, заключается в следующем. Вот список опционов, которые могут оказаться для вас полезными. Давайте обсудим, какие из этих опционов стоит купить и почему. И дальше надо сделать еще одну вещь, которая на самом деле показана на этой формуле. Эта вещь заключается в том, что в меняющейся среде стоимость опциона увеличивается. Это легко представить себе. Если вы знаете абсолютно точно, что произойдет, например, вы разрабатываете приложение, которыми будут пользоваться 10 человек и это всегда будут 10 человек, то опцион на то, чтобы сделать это приложение масштабируемым, ничего не стоит. А вот если вы делаете Интернет-приложение, у которого сегодня 10 пользователей, а завтра 10 миллионов пользователей, то опцион на масштабирование будет очень ценным.

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

Три вещи, которые делает архитектор.

Связи. Есть одна простая истина, которую я вам сейчас открою. Никому нет никакого дела до архитектуры.

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 2/2) Бизнес, Информационные системы, Длиннопост

Неожиданное заявление с моей стороны, не правда ли? Архитектор говорит, что никому нет никакого дела до архитектуры. От этого знания становится грустно, не так ли? Старший архитектор говорит, что никому нет никакого дела до архитектуры. Потому что заказчики не видят вашей архитектуры. Ваши заказчики видят, как ваша система себя ведет. Быстро ли она работает? Работает ли она 24/7 или она все время ломается? Способны ли вы быстро ее дорабатывать? Если вы посмотрите на левую и на правую системы, то они состоят из одинаковых кусков А, В, С, Д. В чем же между ними разница?


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


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


Архитектор должен быть хорошим поваром, а что значит быть хорошим поваром? Быть хорошим поваром означает уметь правильно использовать ингредиенты. Если вы пойдете на рынок и купите хорошие помидоры, то это еще не значит, что вы вкусно покушаете. То же самое в ИТ, приобретение хороших ингредиентов — это хорошее начало, но приготовить вкусную еду, сделать хорошую архитектуру означает правильно все связать. Хорошая архитектуры живет в правильных связях.


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


Люди считают, что так говорить не очень-то и вежливо, но я искренне так считаю. Если у вас на картинке нет связей, то эта картинка скорее всего бесполезна. Вот интересный факт про связи - они существуют в разных измерениях. Первый вид связей - это связи между слоями. Вам надо связать инфраструктуру, данные, приложения, процессы, стратегию. И с точки зрения архитектора очень важно правильно связать между собой эти слои. Инфраструктура, данные и приложения должны поддерживать процессы и стратегию. И это как раз и есть цепочка создания ценности, о которой мы столько говорили. И еще есть связи между системами. Как у вас устроена интеграция. Изолированы они или у вас микросервисы, где там облака, SaaS, PaaS и это очень сильно определяет на то, как ведут себя эти системы. И, наконец, если мы оставим на минутку мир инженерных решений и перейдем в мир организационных структур, то есть еще связи между функциями организации. И все эти вещи очень сильно влияют на архитектуру, потому что если вам надо два месяца согласовывать перенос данных на сервер, то переезд приложения в облако вам не поможет. Вы все равно будете ждать 2 месяца своего одобрения.


Связи играют основную роль и связи живут в разных измерениях - между слоями, между системами и организационные связи.


Вторая важная для архитектора вещь — это способность абстрагироваться. Помните смешную картинку, в которой связи между множеством систем переплетены между собой как спагетти? Это реальность, она бесполезна для принятия решений.


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


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

Это означает, что когда вы делаете модель архитектуры предприятия, то вам надо понять, на какой вопрос вы отвечаете, чтобы сделать хорошую модель. Или какое решение вы принимаете. Поэтому, когда кто-нибудь просит вас показать архитектуру, то совершенно закономерным уточнением с вашей стороны будет: "На какой вопрос вы ищете ответ? Какое решение вы принимаете?" Вы не должны разрабатывать диаграммы просто так, потому что такие виды диаграмм существуют. Разработка модели архитектуры должна лежать на твердом основании вопросов, на которые вы отвечаете и решений, которые вам надо принять. И можно перевернуть это в другую сторону. Если кто-то показывает вам диаграмму архитектуры, то правильно будет спросить: "Какое решение помогает принять эта диаграмма?" Если вас спросят: "В смысле?" То вы сможете ответить: "Ну как, это же модель реальности, модель нужна для того, чтобы помочь мне принять решение. Если вы показываете мне какую-то модель, то вы разрабатывали ее для поддержки принятия какого-то решения. Какое решение помогает принять эта модель?" И если он не сможет вам ничего ответить, то возможно, эта модель не так уж и полезна. Это пример архитектурной модели.

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 2/2) Бизнес, Информационные системы, Длиннопост

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


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


И есть классическая история про индийских кобр во времена колониальной Англии. Это называется эффектом кобры. В то время было много кобр, и эти кобры не были особо дружелюбными созданиями. Британцы подумали: "Как бы нам от них избавиться?" И они объявили награду за поимку кобр. Мы будем платить за каждую убитую кобру и тогда всех кобр переловят и у нас больше не будет этой проблемы. Что произошло на самом деле? Люди просто стали разводить и убивать кобр. Потому что проще разводить кобр у себя на заднем дворе, чем ловить их в джунглях. И когда индусы стали просить слишком много наград за кобр, британцы перестали за них платить. И что сделали индусы? Правильно, они отпустили ненужных им кобр на свободу. Что получили британцы? Они получили еще больше кобр, чем их было до того и потратили на это кучу денег. Такими вещами занимается теория систем, системное мышление. И создание организационных систем сталкивается с точно такими же проблемами.

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

Решения.

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

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


И мы переходим к заключительной части моего выступления. Все те пункты, о которых я говорил, выглядят достаточно логичными. Есть 8 шагов цепочки создания ценности, у нас есть ключевые ингредиенты, вам надо учитывать связи, вам надо работать с абстракциями, вам надо принимать решения, но проблема заключается в том, что ситуация никогда не является такой простой и логичной. Потому что в реальности это огромное море неопределенности. И я думаю, что в этом море неопределенности теряется множество архитекторов предприятия, они просто теряют ориентиры. У них правильные намерения, но из-за того, что все так неопределённо, они просто не понимают, с чего начать. Поэтому принцип "разделяй и властвуй" является, пожалуй, самым важным принципом, которым вы должны руководствоваться в своей работе архитектора предприятия. Потому что именно этот принцип и позволяет им не закрываться в своей башне из слоновой кости. Но если у вас нет измеримых результатов, то вы никогда не покинете свою башню из слоновой кости. Потому что в башне из слоновой кости мир кажется прекрасным и красивым, но вы не приносите никакой пользы для бизнеса и это очень-очень плохая вещь.


Архитектура предприятия — это не какая-то черная магия. Большая часть этой практики приходит из здравого смысла. Это понимание отношений между вещами, это расстановка приоритетов, это понимание того, как объединяются бизнес и ИТ, это последовательное и дисциплинированное принятие решений, с учетом общих принципов и стратегии. Главное тут не потеряться в сложности предметной области или в сложности инструментов и методов. Вы должны помнить, что инструмент вам нужен для того, чтобы достичь какой-то цели, инструмент не является целью сам по себе. Возможно, для кого-то это будет самым важным советом за сегодня.


Если вы вспомните, о чем я сегодня говорил, вы поймете, что я рассматривал ситуация с разных точек зрения. С точки зрения основателя компании, консультанта, с точки зрения разработчика, архитектора, и хороший архитектор всегда комбинирует различные точки зрения, чтобы получить полезные модели. И я думаю, что быть хорошим архитектором означает уметь занимать различные точки зрения, понимать аспекты организации бизнеса, технические моменты, понимать бизнес. Чем больше точек зрения вы понимаете, тем лучше вы можете делать работу архитектора предприятия, тем лучше вы "склеиваете" работу разных подразделений в согласованную деятельность. И спрос на таких людей крайне высокий, потому что их просто мало. И если вы сможете делать все то, о чем я говорил, и выдавать конкретный результат, то компании будут с руками вас отрывать. Это блог и книга про роль архитектора в цифровой трансформации организации.


https://www.enterpriseintegrationpatterns.com

https://leanpub.com/37things

Показать полностью 3
1

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 1/2)

Считает Грегор Хохпе, технический директор по облачным вычислениям в Google. Грегор написал книгу "37 вещей, которые знает один архитектор о цифровой трансформации", в которой описал свои находки за время работы старшим архитектором в страховой компании Allianz с годовой выручкой 130 млрд. Евро, это в 7 раз больше, чем весь рынок страхования России, по данным KPMG https://assets.kpmg/content/dam/kpmg/ru/pdf/2018/07/ru-ru-in.... Грегор работал разработчиком в Google и закончил Стэнфорд по специальностям Computer Science и инженерный менеджмент (MSEM). Его профиль https://www.linkedin.com/in/ghohpe/


"Обычно ИТ заканчивается на офисе ИТ-директора (CIO, chief information officer). Этот человек распоряжается всем бюджетом ИТ и большинство людей в ИТ в конце концов подчиняются ИТ директору. Это довольно сложная работа. Куча людей шутят, что CIO расшифровывается как career is over, карьера закончена. Это не смешная шутка, потому что это очень сложная работа, особенно сейчас. Вам надо снижать издержки и внедрять инновации".

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 1/2) Бизнес, Информационные системы, Видео, Длиннопост

Расшифровка выступления.


Спасибо, что пришли послушать мой 45-минутный рассказ о том, что такое архитектура предприятия и какую роль она играет в крупных организациях. Как видите на слайдах, я сейчас работаю техническим директором в Google в подразделении, которое мы называем офис технического директора. Я работаю в основном с техническими и генеральными директорами крупных компаний, либо с архитекторами предприятий, и помогаю создать правильный формат использования облачных технологий. Этот формат включает в себя архитектурные и организационные изменения. Поэтому многое из того, о чем я буду сегодня говорить, вышло из таких разговоров и моего опыта работы в Allianz. До этого я работал в Google AdWords. В Allianz я был старшим архитектором, возглавлял департамент архитектуры предприятия. Когда я заступал на эту должность, я не понимал толком, что означает архитектура предприятия и чем должен заниматься архитектор предприятия.


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

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

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

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 1/2) Бизнес, Информационные системы, Видео, Длиннопост

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

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


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

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

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

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

И это одна из причин, почему в цифровых компаниях типа Google не бывает больших отделов архитекторы предприятия. Это не означает, что Google не занимается практикой архитектуры предприятия, это следствие того, что бизнес и ИТ в таких компаниях тесно переплетены. Им просто не нужны посредники. Им не нужна помощь архитекторов предприятия, они сами выполняют эту практику. И это круто, что они могут выполнять эту практику и им не нужен отдельный департамент архитектуры предприятия. Но такой департамент нужен традиционным организациям, и он у них есть. Дивизионы традиционных организаций разделены, у них общие поставщики ИТ услуг по самым разным направлениям. Поэтому бизнес и ИТ в традиционных организациях находятся дальше друг от друга, чем в цифровых компаниях. В традиционных организациях архитектура предприятия играет важнейшую роль.


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

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


Вот точно так же у практики архитектуры предприятия есть цепочка создания ценности:

1. Понять бизнес-стратегию

2. Перевести ее в ИТ-стратегию

3. Создать прозрачность

4. Описать картинку целевого состояния ИТ

5. Определить план перехода

6. Согласовывать решения и осуществлять корпоративное управление ИТ-ландшафтом

7. Собирать обратную связь и уточнять планы и цели

8. Наставлять и тренировать


И в первой части нашей беседы мы пройдемся по этой цепочке создания ценности. Я хотел бы обратить ваше внимание на то, что цепочка создания ценности получила свое название не просто так. Точно так же, как в обычной цепи, если у вас порвано одно звено, то у вас разорвана вся цепь. Вот точно также если вы пропускаете какой-то пункт из цепочки создания ценности для архитектуры предприятия, вы не можете создать ценность от этой практики.

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

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

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

Я работал в страховой компании пять лет и я точно знаю, что большинство людей считают страховой бизнес довольно скучным местом. Что-то вроде немолодого человека, который ходит в костюме и с маленьким чемоданом, стучит в вашу дверь и продает вам страховые полисы на автомобиль или квартиру, и он занимается этим 30 лет и 30 лет назад все было ровно так же. В случае с Allianz это совсем не так, это глобальная страховая компания.

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 1/2) Бизнес, Информационные системы, Видео, Длиннопост

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

Поэтому, когда вы видите по новостям о каких-то катастрофах и чрезвычайных происшествиях, вы должны понимать, что убытки по этим событиям покрывает какая-то крупная страховая компания типа Allianz. Это все реальные примеры страховых случаев, которые покрывала Allianz, начиная с крушения дирижабля Гинденбург. Allianz довольно старая компания. Чтобы обработать такие страховые случаи, вам нужно объединить работу кучи специалистов, а не только тех, кто выплачивает страховое покрытие. Вам нужны те, кто будет заниматься управлением кризисными ситуациям, людям, которые будут заниматься защитой бренда, которые будут спасать людей, будут возобновлять нормальную деятельность. Так что работа в страховой компании намного интереснее, чем это кажется снаружи.

Ребята в ИТ общем-то достаточно самонадеянно считают, что их работа намного интереснее, потому что есть клевые Kubernetes контейнеры и квантовые вычисления, а бизнес продает скучные страховые полисы. Такая самонадеянность очень опасна, потому что когда вы вглядитесь в бизнес повнимательнее, там тоже есть куча интересных вещей. Так что, в общем-то это вопрос того, чтобы их увидеть, эти интересные штуки. И, конечно, следующая очень важная вещь - это понять, где бизнес делает деньги. И делать деньги означает получать выручку, но у вас может быть выручка, но маржа может быть нулевой или отрицательной. Так что надо понимать, где у бизнеса находятся зоны роста, где он собирается расти. Собирается ли бизнес продавать какие-то подразделения или наоборот, покупать другие организации. Вы можете подумать: "Да мне-то какое дело до этого, я работаю в ИТ, а покупка и продажа других бизнесов - это забота генерального директора. Почему мне надо об этом думать?" Но если вы немного подумаете, вы поймете, что такие решения сильно влияют на ИТ. Если вы будете приобретать бизнесы, это означает кучу задач по интеграции, это неизбежно. Поэтому я, например, поездил по Азии и изучил, что же происходит там в реальности. Филиппины, например, в основном живут продажами страховок жизни. В Малайзии самые большие продажи страхования имущества.

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

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

Чтобы понять, как организационно структурирован бизнес, чтобы работать на выбранных рынках, архитекторы обычно делают реверс инжиниринг.

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

Обычно ИТ заканчивается на офисе ИТ-директора (CIO, chief information officer). Этот человек распоряжается всем бюджетом ИТ и большинство людей в ИТ в конце концов подчиняются ИТ директору. Это довольно сложная работа. Куча людей шутят, что CIO расшифровывается как career is over, карьера закончена. Это не смешная шутка, потому что это очень сложная работа, особенно сейчас. Вам надо снижать издержки и внедрять инновации.

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

Фишка в том, что ИТ-подразделения очень нацелены на снижение затрат, все ИТ нацелено на снижение издержек. Помните, мы говорили про реверс инжиниринг организации? Чтобы понять, считает ли ваша организация главной функцией ИТ снижение издержек, надо просто проверить, кому подчиняется отдел ИТ. Если ИТ-директор подчиняется финансовому директору, то его целью будет снижение затрат, потому что финансовый директор — это человек, который оплачивает счета. Поэтому если ваша отчетность подчинена деньгам, то именно этим ваша ИТ-организация и будет заниматься, она будет экономить. И это очень важная мысль, потому что представьте себе вы пришли с классной идеей гибридных облаков, например Docker Kubernetes.

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

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

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

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 1/2) Бизнес, Информационные системы, Видео, Длиннопост

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


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

И это, в свою очередь, объясняет, почему компакт-диски так быстро уступили место стриминговым сервисам. Потому что стриминговые сервисы лучше закрывали потребность в немедленном доступе к нужному треку. И в этом месте все становится интересным, потому что из этих разных моделей вытекают разные логические выводы. Если ИТ нацелено на снижение издержек, то вам надо аутсорсить его в то место, где эти услуги стоят дешевле. Многим из нас это не понравится, но это логичный шаг.


А если вы ищете способ раскрыть пользу для бизнеса, то вам, наоборот, надо отвязаться от якоря снижения издержек, и нацелиться на гибкость. Никаких сотрудников в Бангалоре. Гибкость — это способность правильно маневрировать. Гибкость — это правильный курс действий.


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

Еще вы можете обнаружить, что ИТ-директор переходит в подчинение к CDO, chief digital officer. Эти люди поняли, что мир цифровизации подчиняется другим правилам, и ИТ-директор должен подчиняться напрямую генеральному директору и ИТ-директор также важен, как и остальные функции типа финансов или операций, маркетинга и продаж. Они должны быть одинаково важны, это действительно так, ИТ — это хороший бизнес.

Этого разделение между ИТ и бизнесом уже не существует. Я называю это экономикой скорости, в противоположность экономике масштаба. Люди осознали, что в цифровом мире не так важно, насколько ты крупный, важно, насколько ты быстрый. Поэтому надо преобразовывать бизнес-стратегию в ИТ-стратегию.


И тут я бы хотел напомнить, что стратегия — это не реальность. Это направление, в котором вы двигаетесь.


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

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

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

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

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

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 1/2) Бизнес, Информационные системы, Видео, Длиннопост

Самой первой книгой про архитектуру предприятия была книга про стратегию архитектуры предприятия. И как это часто бывает с первыми книгами, это, конечно, важная книга, но не самая лучшая книга, потому что она отражает самые начальные представления о предмете. Так что я скажу, что в этой книге есть самая важная диаграмма, в виде матрицы 2 на 2. Хорошая новость заключается в том, что руководство привыкло к матрицам 2 на 2, к ним они привыкли, потому что такие матрицы любят McKinsey and Co.

Поэтому руководители хорошо понимают идеи, которые изложены в матрице 2 на 2. И если вы хотите, чтобы руководство поняло вашу мысль, используйте этот инструмент. Но эта диаграмма все-таки потребует пояснений. Одна ось показывает уровень стандартизации процессов, другая уровень интеграции. Внизу слева у вас будет интересный бизнес, в котором отсутствует стандартизация и интеграция. Это, например, Siemens или GE или любая другая компания, которая делает все подряд от локомотивов до атомных электростанций и от поездов до холодильников.

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

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

Это хорошо подходит для репликации, потому что новый Макдональдс очень похож на любой существующий Макдональдс. В этом сила франшизы. Но с другой стороны каждый ресторан Макдональдс действует абсолютно независимо от других. Единственная вещь, которая консолидируется в такой системе - это финансовые показатели. Поэтому для вас важна стандартизация общего набора приложений, но почти неважна интеграция. И это полная противоположность бизнесам, которые территориально распределены, но требуют стандартизации процессов. Тогда для вас становятся важными хранилища данных, озера данных. И это примеры того, как операционная модель влияет на ИТ-стратегию.

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

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

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

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору (Часть 1/2) Бизнес, Информационные системы, Видео, Длиннопост

Видите базу данных слева внизу? Она ни к чему не подключена, вот в чем секрет масштабируемости, по-моему, это очевидно. Она должна быть на 100% избавлена от состояний. Но, шутки в сторону. Создать прозрачность в крупной организации - огромная задача.

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

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

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

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

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

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

Показать полностью 5
0

Парадокс полезной глупости (часть 4)

Предыдущие части https://pikabu.ru/story/paradoks_poleznoy_gluposti_chast_3_6...

Часть 2. Пять видов полезной глупости


Глупость, порожденная лидерами

Забавный случай Бенджамина Букера

Обольщение лидером

Большие лидеры?

Маленькие последователи?

Лидерство как источник глупости

Преданность лидеру

Лидеры как менеджеры по глупости

СуперЛидер нас всех спасет?

Злая, плохая реальность!

От хорошего к великому, от посредственного к тупому

Самоотупляющие лидеры

Неоднозначное благословение бездумных лидеров


Заключение


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


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


И хотя лидерская прокачка коллектива может привести к тому, что все отупеют, чаще все происходит по-другому. Лидерские идеи не всегда так сильны и могущественны, как мы полагаем. Чаще всего “лидерство” означает просто высокопарный монолог, который работники воспринимают с юмором, пренебрежением и скукой.


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


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


Глупость, порожденная структурами


Рутинное отсутствие размышлений

Умные люди на тупой работе

Профессиональные дураки

Вера в систему

Как структура создает беспорядок

Общество поверхностного тщательного изучения


Заключение


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


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


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


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


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


Глупость, порожденная имитацией других


Следуй за толпой

Когда имидж - это все

Следуй за победителем

Выгляди организованным

Корпоративное приукрашивание

Обещание достать Луну с неба


Заключение


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


Все более важным становится создание хорошего имиджа для компании. И это часто становится причиной возникновения проблем. Различие между прекрасным образом компании, который она пытается создать снаружи, и жесткой реальностью ведет к разочарованиям, низкой вовлеченности и цинизму. И это может быть плохо для бизнеса. Многие организации пытаются убедить себя и остальных в том выглядеть хорошо это и есть быть хорошим. И если сейчас мы не так хороши, то, может, мы станем такими потом, в будущем. Желание выдать существующие оргструктуры за реальные ценности компании так велико, что люди в конце концов верят в это и отказываются признавать, что все эти декоративные структуры лишь вывеска для тех, кто ничего не знает про то, что происходит внутри организации. Главное в этой ситуации - это избегать критического осмысления того, что происходит вокруг. Если вы принимаете все за чистую монету, то ваша самооценка растет, вы отождествляете себя с компанией, и в организации создается боевой рабочий настрой. И пойти по этому пути в обществе, где внешнее ценится больше, чем внутреннее, не так уж и сложно.


И увлечение современного общества брендами очень в этом помогает. И в следующей главе мы исследуем эту золотую шахту полезной глупости.


Глупость, порожденная брендами


Чертовски хороший омлет?

Танцующий бренд

“Абсолют”-ная херня

Священная зубная паста

Скажи так, будто ты это и впрямь сделаешь

Изготовление потребителей


Заключение


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


Каждый год ученые пишут миллионы статей, из них меньше половины прочитает кто-то за исключением редактора и рецензентов. Чтобы впаривать все те ненужные штуки, которые мы производим, мы придумали экономику убеждения. Размер втюхивания настолько велик, что люди, казалось бы, должны начать спрашивать: “Какого черта мы всем этим занимаемся?”, но большинство понимает, что задавать этот вопрос слишком часто опасно для благосостояния и психологического самочувствия.


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


Брендинг предлагает ее решение. Брендинг помогает представить вместо тупой и нудной работы что-то значимое и интересное. Вы не создаете упаковку зубной пасты, вы “работаете с брендом”. Что важнее - чистые зубы или глубокий смысл и любовь покупателей к продукту? Вы не продаете водку втридорога, вы “создаете чистоту, прозрачность и совершенство”. Вы не учите класс скучающих студентов и не пишете бессмысленные исследовательские статьи, вы “ученый мирового класса, перед которым лежат безграничные возможности”.


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


Глупость, порожденная культурой


Расскажи нам что-нибудь радостное!

Плясать под одну дудку без размышлений

Компас или тюрьма?

Культура оптимизма

Культура изменений

Культура “сейчас”

Культура уникальности

Культура плоской организации и сообщества


Заключение


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


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


Но с другой стороны, оптимизм означает то, что плохие новости будут замалчиваться. Постоянные изменения будут означать, что ни одно изменение не укоренится в организации и не даст плодов. Ориентированность на текущий момент означает, что уроки прошлого будут проигнорированы, а долгосрочные последствия не будут рассматриваться серьезно. Вера в собственную исключительность приведет к тому, что организаци зациклится на себе. Забвение иерархии приведет к тому, что будет потерян авторитет начальства.


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


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


Часть 3. Управление глупостью и как противостоять глупости.


Почему нам надо быть тупыми

Управление глупостью - секреты мастерства

Управление глупостью в ССС

Борьба с глупостью

Вредные советы

Как развеять глупость:

- процедуры рефлексии

- адвокаты дьявола

- пост-мортемы

- пре-мортемы

- новички

- взгляд со стороны

- работайте с критиками

- конкуренция и игры

- анти-слоганы

- отдел по борьбе с глупостью

- систематические меры по борьбе с глупостью

Боритесь с глупостью с чувством, толком и расстановкой

Борьба с глупостью в больнице

Почему финансы важны?


Заключение


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


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


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


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


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


Но полезная глупость - это обоюдоострое лезвие. У отдельных работников она создает постоянно растущее недовольство и разочарование. Различие между провозглашенными ценностями и реальностью приводит к проблемам и тревожности. В некоторых случаях эти различия ведут к цинизму и отчуждению. Люди в конце концов могут полностью самоустраниться от работы.


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

Показать полностью

Мы ищем frontend-разработчика

Мы ищем frontend-разработчика

Привет!)


Мы открываем новую вакансию на позицию frontend-разработчика!

Как и в прошлые разы для backend-разработчиков (раз, два), мы предлагаем небольшую игру, где вам необходимо при помощи знаний JS, CSS и HTML пройти ряд испытаний!


Зачем всё это?

Каждый день на Пикабу заходит 2,5 млн человек, появляется около 2500 постов и 95 000 комментариев. Наша цель – делать самое уютное и удобное сообщество. Мы хотим регулярно радовать пользователей новыми функциями, не задерживать обещанные обновления и вовремя отлавливать баги.


Что надо делать?

Например, реализовывать новые фичи (как эти) и улучшать инструменты для работы внутри Пикабу. Не бояться рутины и командной работы (по чатам!).


Вам необходимо знать современные JS, CSS и HTML, уметь писать быстрый и безопасный код ;) Хотя бы немножко знать о Less, Sass, webpack, gulp, npm, Web APIs, jsDoc, git и др.


Какие у вас условия?

Рыночное вознаграждение по результатам тестового и собеседования, официальное оформление, полный рабочий день, но гибкий график. Если вас не пугает удаленная работа и ваш часовой пояс отличается от московского не больше, чем на 3 часа, тогда вы тоже можете присоединиться к нам!


Ну как, интересно? Тогда пробуйте ваши силы по ссылке :)

Если вы успешно пройдете испытание и оставите достаточно информации о себе (ссылку на резюме, примеры кода, описание ваших знаний), и если наша вакансия ещё не будет закрыта, то мы с вами обязательно свяжемся по email.

Удачи вам! ;)

Показать полностью
Отличная работа, все прочитано!