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

Настало время рассказать, зачем я спросил про телефон. Я сдал свой божественный пиксель в ремонт (скорее по моей вине) и решил попробовать Iphone, ну просто чтобы иметь представление. После 2х недель использования, впечатление, что после тележки пересел на ватсапп (без обид, господа и дамы фанаты Эппл), и вот почему:
1. Нет разблокировки по отпечатку. Дадада, всем мне расскажут, что FaceID работает божественно, но если телефон лежит на столе, то тебе надо его поднять, чтобы разблокировать, с пальцем такой проблемы нет. В общем - экономия на спичках, учитывая, сколько стоит замена экрана на Iphone.
2. Телефон люто греется на зарядке, на беспроводной в машине - особенно, притом что на нем ничего тяжелого, игр и тд не запускается.
3. Оплата только по FaceID, даже если ты только что разблокировал телефон.
4. И вишенка на торте, ради которой я и устраивал опрос. Кнопка назад. Прекрасно работала на 4 айфоне, где ты мог дотянуться пальцем в верхний левый угол. Но дальше что то пошло не так)
И вместо исправления UX был сделан самый интересный костыль из тех, что я видел. Легкое движение внизу экрана ииии.....
Кнопка Назад съезжает в середину экрана. На этом моменте, я понял, что я все же больше люблю Андройд)

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

Немного про Холистический бизнес анализ на англиской от Stefan Bosseuwe и беларусского чаптера IIBA.
В целом Стефан очень дельно рассказал про системный подход к бизнес анализу и поиску решения. Но все же изложение системного мышления в подходе Левенчука мне заходит больше и кажется более общирным и практическим, что ли.
Но в качетсве взгляда в профиль очень даже ничего!
А вы делали подходы к системному мышлению?

Всем привет! Тестовое интервью стартует через 5 минут. Залетайте поддержать меня https://pruffme.com/landing/u4164170/tmp1716035421

Александр Горный поднял тему обучения и в целом я согласен с основной мыслью - современное высшее образование выглядит избыточным.
Оно в не состоянии успевать за текущим миром и давать актуальные специализированные навыки. Но вот что Александр на сой взгляд забыл- нетворк! Для меня ценность образования чем дальше - тем больше в контакте с интересными людьми. Я искренне жалею, что в период учебы в университете я этого искренне не понимал.
Например, в Португалии очень большой процент совместных проектов делается людьми знакомыми с университета или даже школы. Причем это может быть даже чаще 20 лет после окончания.
А вот со стороны в такой кружок вписаться очень сложно, мне коллеги такое же рассказывали про Францию. В России с нетворком проще, хотя все равно мои связи со временем университета очень крепкие.
А вы как считаете, в чем основные задачи образования?

Для офисной жизни образование должно давать четыре вещи.

— Корочку, чтобы была.
— Психологию, чтобы понимать других людей.
— Риторику, чтобы уметь объяснять другим людям.
— Математику, чтобы понимать, как мир устроен.

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

P.S.: добавляют иностранные языки. Согласен.

#простомысли

—
GPT-4o уже доступна в c.aiacademy.me

Привет! Сегодня на Аналист Дейз. Слушаю Алексея Пименова про социологию на службе аналитика.
Максим Цепков пишет ревью на доклад, почитаете потом на его канале

#AnalystDays Алексей Пименов. Социология на службе аналитика. В докладе - социологическая модель племени. Есть такое направление современной социологии - корпоративная антропология, которое говорит, что "на самом деле" современный мир не слишком далеко ушли от племенных моделей, как они это представляют, и во многих компаниях проявляются те самые конструкты племенного поведения.

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

Племена. Атрибуты племенного поведения.
* У племени есть общий враг - не надо им становиться
* Члены племени наделены внутренним сходством
* У племени свои ритуалы и обряды - объекты ценности, их не надо нарушать и подрывать, вы станете врагом. Иногда надо сносить. но аккуратно
* Племя понимает источник успеха, не дает шатать
* Племени есть свой язык.

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

Концепция V'ger - это из первого фильма star track. В любой компании есть история, связанная с технологией или чем-то ядерным - и нельзя нарушать. Microsoft - Basic, он во всех продуктах. Для компании - доменного регистратора все строится вокруг домена, хостинг и другие услуги пришли как развитие. И сейчас у них проблема с продуктами в телеграм, которые строятся без домена - как так, vger отсутствует. Узнайте, что является vger компании или команды, с которой взаимодействуете. Следующий шаг - понять дает ли это ограничение, или объединяет и что с этим делать.

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

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

Социальная сплоченность: в племени думаем одинаково. Спектр от хаоса до тоталитарной секты. Социальные инновации: способность группы выдать идею. Может ли сплоченная группа выдать идею? Хуже. Команду сначала сплачивают, а потом говорят - придумывайте. Они не могут. Со сплоченностью надо остановиться как только поняли общую цель, не идти до полного единомыслия. А если вы сотрудник, то оценив сплоченность вы можете понять, как предлагать инициативу. В одних командах - можно принести самому публично, в других - привлекать сторонников по-одному, в третьих - через руководителя. А когда принесли - можно практику сделать vger чтобы она сохранилась.

Про общего врага. Это не должен быть человек или другая команда, не играйте в игру против команды PVP, играйте PVE - против внешней среды, против рынка и так далее.

Ритуалы. Как искать общее в новой команде? Первое - отношения с каждым. Выявляем соуиальные группы - ВУЗ, хобби, проживание. Дальше - разматываем, создаем личный контакт. Когда с каждым личный выстроен - объединяем. Если общее. И против проблемы. И сам: можем побороться - поддержите. С удаленщиками искать общее на порядок сложнее. Возможно, игры, стриминг, телеграм-чатики.

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

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

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

Максим Цепков написал рецензию и на мой доклад (отдельное ему спасибо за это).

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

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

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

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

Катя Лысенко написала крутые 10 советов про REST API для финтеха, но как мне кажется, они супер универсальные

🚀 10 Капитанских правил для REST-API в Финтехе 🚀

Привет всем!

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

1️⃣ Понятность названий параметров: Каждый параметр должен однозначно объяснять своё предназначение и формат. Пример: параметр "visibility_flag", кажется должен быть булевым (true/false). Однако часто такие параметры могут быть представлены как int со значениями 0, 1, 2, 3... Это создаёт путаницу и уменьшает читаемость API.

2️⃣ Использование префикса для булевых переменных: Для булевых переменных используйте префикс 'is', например, 'is_visible'. Это сразу делает понятным, что переменная имеет два состояния: истина (и true = видимо) или ложь, и упрощает работу с кодом.

3️⃣ Ясное описание происходящего: Если можно объяснить ситуацию словами — делайте это. Вместо того чтобы заставлять пользователя дешифровать числовые значения в 'invisibility_reason', лучше сразу указывать причину: 'blocked', 'fraud', 'no money'. Это делает API более дружелюбным и понятным.

4️⃣ Прозрачность ошибок: Не заставляйте пользователей разбираться в сложных таблицах для понимания ошибок. Ошибки должны быть понятны и просты для интерпретации, чтобы пользователи могли быстро находить и исправлять проблемы. Самый странный протокол в моей жизни содержал 57 печатных страниц с расшифровкой кодов ошибок.

5️⃣ Полная информация об ошибках: Если в процессе выполнения запроса обнаружено несколько ошибок, сообщайте о всех одновременно. Это позволяет пользователям быстрее и эффективнее устранять проблемы. Пример: отправлены данные пользователя. Но одно из обязательных полей пропущено, а в паспорте нехватает цифры. Если обе проверки выполняются на API (а скорее всего - да, так как это валидация данных) - отдайте сразу обе ошибки и о нехватке данных, и об ошибке в номере паспорта.

6️⃣ Отсутствие дублирующих параметров: Избегайте создания параметров с похожими названиями и разной логикой. Пример: 'is_visible' и 'visible_flag'. Если хотите в поле 'visible_flag' поместить причину - назовите 'visibility_reason', если "буль" передающий информацию о ручной установки видимости из админки 'is_visible_manual'.

7️⃣ Один метод — одна функция: Избегайте создания универсальных методов, которые меняют своё поведение в зависимости от передаваемых параметров. Это усложняет поддержку и отладку. Иногда встречается попытка создать единый метод для старта однофазного и двухфазного платежа, внутри которого флагом отмечается какой это платеж. Вместо того чтобы явно прописать, что за метод вызывает. К сожалению, это путь к проблемному дебагу и сложному мониторингу.

8️⃣ Продуманность структуры данных: Лучше заранее подумать о данных, которые могут понадобиться в будущем (в части сущностей, где вы не main система), чем впоследствии их добавлять. Например, клиент-создается на стороне Мерчанта, вы только обогащаете его параметрами. Но клиент может иметь «галочку», которая вам если и понадобится, то не раньше чем через год. При большой пользовательской базе и части процессов идущих напрямую через вас, добавление параметра через год, может стоить дорого.

9️⃣ Изолированность данных в методах: Убедитесь, что каждый метод работает с данными только одной сущности. Это облегчает понимание и поддержку API. Не стоит в клиентские методы прокидывать параметры счета и наоборот. Если признак тестовости у клиента, а счет не имеет признака тестовости, то методы аккаунтов не должны содержаить параметь 'is_test'.

🔟 Подробные описания кодов: Если ваш API использует специфичные числовые коды, обязательно предоставьте рядом текстовое описание. Это поможет другим разработчикам и поддержке быстрее разобраться в работе системы.

Надеюсь, эти правила помогут сделать наш API не просто функциональным, но и удобным и приятным в использовании!

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

Помогаю Дмитрию Кучме из Коруса провести для аналитиков игру с построением БПМН процессов из настоящих деревянных элементов. Никаких вам Визио и Камунд!