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

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

Я в заключении хочу отметить, что методы корпоративной антропологии. с одной стороны, дают рабочую модель, но, с другой - искажают восприятие. В основе лежит убеждение, что человек живет в придуманной парадигме первобытного племени, живущего в 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 готов помогать нам все больше и больше

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

Всем доброго вечера! К сожалению, в эти выходные провести мастер-класс не получится , потому что из России я помимо положительных впечатлений и кучи мерча привез еще и какой то гадкий вирус.
Эту неделю я с ним доблестно борюсь, так что сил на МК не хватает. Пока план - сдвинуть на две недели, так что stay tuned!
Всем здоровья!

Ребята из Flow сегодня опубликовали мой доклад с мартовской конференции.
Смотрите и наслаждайтесь!
А если захотите сделать так же (я и про требования и про выступление), то приходите ко мне на сессии менторинга

#видеозаписи

Начинаем постепенно публиковать записи весенней Flow!

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

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

Уже давненько прочитал книжку "50 бизнес моделей новой экономики" от троих известных российских авторов и предпринимателей Михаила Иванова (МИФ), Александрв Горного (инвестор, стартапер), Алексей Черняк (инвестор, основатель Groupon).
Книга построена в формате справочника и описывает 50 крутых стартапов ставших единорогами (более $1 млрд капитализации), сопровождаемых комментариями авторов, сводной аналитикой и описанием собственно бизнес модели, как одной из составляющих успеха.
Если смотрите в сторону своего стартапа (а я внезапно смотрю в эту сторону) или идете в продуктовый менеджмент, то настоятельно рекомендую почитать. Читается быстро и легко.

Сегодня пост тщеславия. Выкладываю несколько фоток со своего доклада на Аналист дейз и презентацию выступления "Почему из аналитиков плохие продакты".