Хорошую картинку нашел у bytebytego — сразу понятно, где какие стили API обычно используются.

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

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

Часть I. Требования к ПО
* Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные).
Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой:

Инженерия требований состоит из разработки требований и управления требованиями. Разработка требований состоит из этапов выявления, анализа, спецификации и валидации.

Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно.

Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость:

В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, but you’re managing the communications closely.

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

Часть II. Разработка требований.
* Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет.
* Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют.
* Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер.
* Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
* Поиск упущенных требований — стр. 136.
* Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193.
* Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.

Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234.

* Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.

Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно.

* Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё.
* Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
* Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить.
* Прототипирование — скорее всего, его у вас нет. Пропускаете.
* Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях".
* Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
* Повторное использование требований, гл. 18. Не бывает.

ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой.

Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.

Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет.

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

Вот и всё, не благодарите.

(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)

Мы уверено преодолели отметку в 7000 подписчиков! Спасибо вам! 🙏🙏🙏Надеюсь и дальше вас радовать смешными и полезными постами.

А в комментах к этому посту предлагаю всем знакомиться, и написать — вдруг вам нужна какая-нибудь помощь? Может, вы ищете работу, или наоборот — нового коллегу, или совет, или ментора. Напишите! Нас тут много, возможно вам помогут!

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

Сколько вы знаете способов передачи данных на клиент по инициативе сервера?

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

Я насчитал 6 (добавляйте, если знаете ещё):

1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.

2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.

3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.

4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).

5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.

6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.

Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.

На самом деле, внутри GraphQL либо WebSocket, либо multipart subnoscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).

А  стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.

Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.

Пришли дети, увидели открытый draw.io, ой, а что это за стикмены? Слово за слово, нарисовали диаграмму.

Вопросы:
— содержит ли эта диаграмма элементы UML?
— это структурная или поведенческая диаграмма? (или диаграмма взаимодействия?)
— какой процесс тут, собственно, изображен?

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

И вот что интересно: все  практики и подходы, о которых мы говорили в 2010-2012 годах, которые развивали и проектировали — и тогда это был какой-то невероятный полуподпольный эксперимент — все вот они, в обычном вузовском образовании! Ну ладно, не совсем в обычном, из верхнего перцентиля, но — тут.

Например, два года назад я учился в РАНХиГС, и там мы строили CJM. А нынешнее обучение началось с трехдневной "деловой игры", которая на практике оказалось форсайтом (и именно rapid foresight, про который я несколько раз рассказывал в ИТ-сообществе, и который сейчас активно продолжает продвигать Дима Безуглый — собственно, я его с методикой и познакомил).

Методику воспроизводят неточно, где-то утерян дух, где-то — смысл, но, тем не менее, это она. Нужно отдать должное авторам — теперь, кажется, форсайты стали общим местом и стандартом для стратегических сессий (кстати, обращайтесь, если что, я их тоже провожу 🖐). А дальше обещают lego serious play и всё такое прочее.

Согласитесь, это вам не традиционные лекции и семинары! (Хотя они предусмотрены тоже, но, кажется, их не более трети от всех учебных активностей)

И это правильно — учиться нужно через деятельность, и только делая что-то своими руками/головой.

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

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

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

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

На практике же получается совсем другое: люди начинают защищать свой результат, потому что никому не нравится выглядеть дураком (об этом был прекрасный рассказ на Fail Night на последнем Flow — без записи, естественно).

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

В ситуации манипуляции человек тоже учится, но часто чему-то не тому (помните — "выученная беспомощность"? Вот, выучился!)

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

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

Хотя, на мой взгляд, лучше бы образованию заняться изменением этой культуры, а не её трансляцией.

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

А с мотивацией можно работать отдельно, если это требуется.

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

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

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

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

Ну а для тех, кто организует, выбирает или проектирует обучение, повторю ещё раз:

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

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

3⃣ Уважительное общение и поддержка желательного поведения даёт при обучении гораздо больший эффект, чем выискивание и подчеркивание ошибок.

4⃣ Без лекционной части не обойтись, но старайтесь доносить одну сильную мысль за один смысловой блок — объем внимания человека ограничен.

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


Так что спасибо этому обучению, я лучше стал понимать свои ценности и методы в обучении — на контрасте.

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

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

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

Что с этим дальше делать -- конечно же, принимать решения. Моими первыми конференциями были, кажется, IT-people и RuCamp. Это был просто другой мир, после затхлых банков (это было время, когда итшников в банках ещё считали центром расходов и неизбежными дармоедами, и относились соответственно) и примерно таких же вузов. Во многом эти события определили мою дальнейшую траекторию. И я очень жалею, что не попал в те тусовки, в которые в итоге попал благодаря этим конференциям, ещё раньше (например, прозевал расцвет рунета).

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

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

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

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

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

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

Напишите -- а вы зачем ходите на конференции, или почему не ходите, если не?

Ещё немного инсайтов про конференции. Вот про нетворкинг спикеров — это правда. Я в свое время с очень крутыми людьми познакомился и пообщался именно в спикерской или в ПК.

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

Но при подготовке доклада приходится общаться с другими — и крутыми! — людьми, к которым потом можно придти и со своим вопросом или идеей. А ещё на некоторых конференциях для спикеров устраивают отдельный нетворкинг, что тоже очень круто. (А где делают несколько конференций — ещё и нетворкинг для членов ПК). В этом смысле был очень хорош ЛАФ, который и начинался как посиделки за шашлыком, и сейчас продолжает эту традицию, но почему-то не все доходят — видимо, не знают главной фишки :)

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

Продолжая тему конференций — не кажется ли вам, что популярность тем хардов и софтов на конференциях меняется циклично?

В какой-то момент, ещё лет 5 назад, чуть ли не половина докладов была про софты: как продуктивно работать, как проводить совещания, как не выгореть, как избегать конфликтов или наоборот манипулировать. Про разные там модели личности были популярны доклады, про балансы работы и жизни. Я на ЛАФе в 2022 году даже слышал доклад про то, как устроить себе саббатикал — то есть, уйти в долгий отпуск. В докладе было про 5 месяцев, но вообще саббатикал может быть и на год; в университетах его дают профессорам каждые 7 лет (или даже 5), Дональд Кнут написал TeX как раз во время такого отпуска.

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

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

Я вижу это по запросам на менторинг/консультации (а на Flow, например, была такая активность — "спроси эксперта", вот я был тем экспертом, и угадайте — про что был вопрос? Точно не про интеграции :))

Ещё примерно те же темы поднимались в опросе, который я когда-то проводил — и проблемы тоже совсем не с технологиями связаны и не с техниками анализа, а в основном с людьми.

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

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

Пишите в комментах вопросы, которые вас беспокоят, и на которые у вас нет ответа — будем разбираться!

Раз зашла речь про софт-скиллы, напомню ещё раз анекдотическую ситуацию с половиной статей про эти самые софт-скиллы: https://news.1rj.ru/str/systemswing/213

Помните! Если вы видите в какой-нибудь статье фразу "Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%." — это из книги 1918 (не опечатка!) года про обучение инженеров в США, и главный "софт-скилл" там — твердость характера!

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

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

Представим, что на дворе 1930-е годы. На выставке инструментов для лесного хозяйства фирма Андреаса Штиля только что представила бензопилу, способную сделать революцию в отрасли. Герои нашей истории работают в небольшой компании, занимаются валкой леса. Её менеджеры только что вернулись с выставки. Просто взять и начать валить деревья с большей скоростью — это прекрасно. Но ведь нельзя просто так взять и посадить первого попавшегося представителя какой-нибудь из заинтересованных сторон за стол и попросить его написать требования для закупки бензопилы. Системное мышление заставляет задуматься: как же эта новая технология будет применяться с точки зрения бизнес-операций?

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

Похожая ситуация с отделом снабжения. Его сотрудники знают своё дело — и в мельчайших подробностях! Сколько топоров ломается на метр поваленного леса (и сколько нужно закупить и доставить) известно. Но совершенно непонятно, как поддерживать работу новой бензопилой: что делать с топливом, смазкой, где всё это хранить, сколько запчастей и какие закупать, как часто. Как вообще узнать, что всё это нужно?

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

Обслуживание топоров устоялось: торговцы не просто продают инструмент, но и отвечают за его состояние. Сломалось топорище? Просто отправляем его торговцу, он заменит. Затупилось лезвие? Снова к торговцу: он заточит. А с кем и как вести дела, если закупить бензопилы? Как поддержать снабжение? Как перевозить материалы— топливо, масла — с которыми сегодня в компании никто не работает? Как и кто эту новую способность предприятия (все эти двигатели, цепи) будет поддерживать? Как поменять структуру организации? Как внедрять эту новую способность: выдать всем операторам бензопилы сразу, командам по очереди или начать скаких-то определенных регионов? Если начать валить деревья быстрее, нужно ли будет найти дополнительный транспорт для перевозки материала? Не придется ли расширять лесопилку? В конце концов, бизнес-менеджменту придется решить, стоит ли поставлять больше продукции и наводнить ею рынок, обрушив таким образом цены.

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

Знаете ли вы, что у ChatGPT можно попросить нарисовать вашу жизнь по мотивам вашего общения?

Промпт такой: "Based on what you know about me from our previous conversations, please draw a picture how in your opinion my life could look like“

Мне рисует вот такое 👆

Не знаю, откуда он взял всех этих Supplers Suppllelers Suppleton, но если считать, что я поддерживаю и обеспечиваю деятельность аналитиков — то даже похоже :)

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

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

Есть отличный текст на эту тему, он прекрасен, приведу его полностью:

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

Ты три дня тупил, и работа не будет готова к пятнице. Скажи об этом в среду сам, а не в пятницу, когда у тебя спросят результат! Дай другим возможность передвинуть планы, поискать, как тебе помочь сделать побыстрее, предупредить клиентов и так далее! Тогда ты остаешься ответственным вменяемым человеком - ты не подвел.

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

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

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

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

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

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

Если вам задают вопрос "Что происходит, когда вы набираете в браузере 'google.com'?", вспомните это видео: https://www.youtube.com/watch?v=atcqMWqB3hw

Осторожно, видео со звуком! В офисе используйте наушники. Ну или наоборот — зовите всех вокруг, особенно разработчиков — они наверняка порадуются. В комментариях отметился Даниэль Стенберг — собственно, создатель утилиты curl. Он такой подход одобряет! :)