#коммуникации #мышление
Минутка снобизма и брюзжания. Мало, что так усложняет и замедляет рабочие коммуникации, как мессенджеры.

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

1. Нужно описать техническую/архитектурную проблему, которая влияет на ход всего проекта.
2. Проблема имеет несколько решений, у каждого свои плюсы и минусы.
3. Бизнес ничего не знает о твоей технике, поэтому нужно описать все на человеко-понятном языке.
4. Описание должно быть кратким. Длинный текст проигнорируют, либо не дочитают.
5. Если что-то будет непонятно, то тебе зададут вопрос. В ответном письме. Напоминаю, каждая итерация - один-два дня.

Прелесть в том, что 2/3 написанных писем я никогда не отправил. Потому что с такими жесткими ограничениями мысли начинают очень хорошо упорядочиваться по мере генерации текста. На эту тему есть много техник про мышление письмом и около того.

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

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

Групповые чатики - это вообще мрак. В начале удаленки они достали на столько, что я даже сделал в компании доклад “Как выбесить коллег в переписке”.

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

Пишите письма, мелким почерком.

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

https://microservice-api-patterns.org

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

Аналитикам можно смело читать все подряд, особенно разделы Structure и Quality.
Очень понравились ссылки на публичные примеры использования - можно поковырять реальные сервисы

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

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

https://podlodka.io/166

#инструменты

Подкинули ссылку на Plant UML редактор с подсветкой синтаксиса, удобненько: https://plantuml-editor.kkeisuke.com

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

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

Если кто-то не знаком: https://plantuml.com

#интеграция #API
Наглядная и веселая статейка о том, как “правильно” исспользовать http, чтобы делать “правильные” RESTful сервисы

https://habr.com/ru/company/yandex/blog/265569/

https://habr.com/ru/post/526336/

Думаю, эта статья прошла уже по всем каналам аналитиков, но проигнорировать ее я не могу - слишком сильно резонирует с моими мыслями и опытом. Я уже приводил пример, как мышление письмом помогает решать вопросы и сильно упрощает коммуникации с коллегами https://t.me/another_sa/37

Здесь же автор распространяет практику на более интересные рабочие ситуации. В главе про “письменные” встречи я вообще рыдал от восторга.

С переходом на удаленку даже самый ленивый успел провести какой-нибудь онлайн митап или где-нибудь выступить. А если не успел - то самое время. Имхо, дебютировать онлайн намного проще, чем вживую. Да, нет контакта с аудиторией, не видна ее реакция, но для первого раза это огромный плюс - ничто не отвлекает и не сбивает с мысли. Плюс, нет подсознательного страха перед ЖИВЫМИ ЛЮДЬМИ.

Эти две статьи мне нравятся за то, что относятся к выступлению и подготовке очень просто, не нагнетая. Когда-то они подтолкнули меня к первому внутреннему выступлению в компании.
https://habr.com/ru/post/289144/
https://habr.com/ru/post/289742/

А эту ссылку я уже давал, но повторюсь. Здесь автор хорошо ответил на: “Зачем я буду что-то рассказывать, что все уже знают?” Не знают. Не все. Расскажите.
https://habr.com/ru/post/501854/

#реклама #интеграция #API
Осторожно, реклама!

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

https://bit.ly/348n6we

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

Видео будет только для участников, но есть статья от автора:
https://habr.com/ru/company/accenture/blog/523414/

Что ребята сделали:
1. Собрали описания всех моделей в банке.
2. Из каждого объекта извлекли текстовые человеко-читаемые описания каждого атрибута.
3. Векторизовали все такие описания, получив набор векторов в 33-мерном пространстве. Если по-русски: посчитали количество всех букв в описаниях и получили 33-числа для каждого.
4. Дальше посчитали расстояния между векторами и получили набор кластеров.
5. На основе этих кластеров разработали “идеальные” модели для всех объектов.
6. Скорректировали ручками.

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

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

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

https://youtu.be/HjiE3n4_6zI

#agile #scrum #процессы

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

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

А теперь посмотрим, что зачастую называют скрамом в нашей уютной it-шечке:
1. Живем двухнедельными спринтами
2. Выпускаем новые фичи для пользователей раз в 2-3-6 месяцев
3. В начале работы над крупной фичей оцениваем (а лучше сразу коммитимся на них) сроки, когда она будет готова

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

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

Почему так происходит?
1. Обычный карго-культ, когда берем внешние атрибуты методологии, не вникая в ее суть.
2. Последствия быстрого роста. Когда были маленькими, все получалось, но на фоне взрывного роста процессы как-то поломались. Даже заметить не успели.
3. Скрам в компании - это не более, чем маркетинг и следование трендам, чтобы завлекать сотрудников. Тогда вопросов нет. Только не забудьте про смузи.
4. Самый очевидный вариант, который я не увидел.

#agile #scrum #процессы

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

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

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

К чему это? Надо бы чаще рефлексировать, зачем мы внедряем те или иные подходы.

#цитаты

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

“Был год, если не ошибаюсь, 2014. Я только начал активно участвовать в продажах. И вот в конце года к нам пришел потенциальный проект. Я вел пресейл, начиная с первого звонка. Всё горело, нужно было до конца года вписаться в проект. Бюджет хороший, но все в мыле, нет времени объяснять, нужно срочно бежать. А я не понимаю куда🤯

И вот 30 декабря, последний рабочий день. Я приехал со встречи на наш корпоратив. Помню, сидя где-то в углу, написал письмо, в котором окончательно отказался от проекта. Самое интересное, что проект уходил к нашим прямым конкурентам. Кошмарный сон любого продавца🤭

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

А я опять к чему?🙃
🙋‍♂️ Задавайте вопросы, если не понимаете что-то. Да и если понимаете, тоже иногда полезно переспросить. Не бойтесь показаться глупым.
⏱ Чем меньше времени на принятие решения, тем сильнее нужно тормозить. Это про ожидания”.

#реклама #интеграция #API #REST

В феврале делаю тестовый запуск тренинга о REST API для самых маленьких.
Условия: присутствовать на всех занятиях, сделать дз и дать фидбек на выходе.
Даты: 14.02, 21.02, 28.02

UPD. Всем спасибо, группу собрали.

#интеграция #API #анонс

Описание API в Confluence
Завтра в 18:00 по мск намечается ламповая встреча с Олегом Игониным на тему документирования API в конфлюенс:

“Хочу рассказать о том, как у меня сложилась работа с описанием API методов в Confluence для постановки задачи на их реализацию разработчикам (структура страниц в confluence, структура заголовков, некоторая автоматизация, описание интерфейса метода и работы логики под капотом).

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

В общем, возьму лампу, кота и буду рассказывать. 😂

Ссылка и id конференции:
https://us04web.zoom.us/j/75989849812?pwd=Q2Mra0thdi9EL0JYUVFDVUcwU1kyUT09
Идентификатор конференции: 759 8984 9812”

#архитектура

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

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

Люто советую всем причастным к разработке и проектированию для расширения картины мира.

https://youtube.com/playlist?list=PL4_hYwCyhAvZuoK6Y0FaCh-25jEYtBvDo

#архитектура #интеграция #конференция

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

Кому были интересны архитектура и интеграция, может быть полезно.

https://podlodka.io/becrew?utm_campaign=BE-1-Early-Bird&utm_medium=social&utm_source=telegram&utm_content=BE-1-Early-Bird_PodlodkaNews

#API #REST #интеграция

Вавилонская башня REST
Заметка о том, что люди в обыденной жизни называют RESTом, и как их понять.
Пока писал, нашел статью на схожую тему: https://habr.com/ru/post/319984/

На днях с интересом посмотрел доклад, где автор рассуждал о плюсах и минусах “REST-протокола”. В очередной раз вспомнил, что в термин REST человек может вкладывать примерно любой смысл. Усложняется история тем, что в сети полно статей и видосиков, дающих разные трактовки: одни говорят про правильные GET-POST-PUT, другие про JSON и XML, третьи вообще об архитектурных стилях рассуждают.

Вот моя версия Русско-Рестового словаря.

REST - это архитектурная концепция, которая рассказывает нам, как построить распределенную систему так, чтобы она была масштабируемой, производительной и со всех сторон успешной. Концепция включает в себя шесть принципов-ограничений, которым она должна удовлетворять. Возможно, глубокое изучение принципов никогда не понадобится аналитику, но часть из них стоит понять и осмыслить: модель client-server, stateless, кэширование – будет полезно не только при работе с REST-сервисами.

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

RESTful-сервис - сервис, удовлетворяющий принципам REST.

HTTP/1.1 - протокол передачи данных, на котором живет большая часть интернета. А вот REST протоколом не является.
Чтобы понять, как правильно использовать POST, PUT и статус коды, нужно читать спеку HTTP. Или для начала посмотреть статью на тему.

А теперь следим за руками. Несмотря на то, что в массовом сознании HTTP и REST неразлучны, REST никак не привязан к конкретному протоколу передачи данных. Можете спроектировать взаимодействия хоть поверх очередей, если ваши сервисы будут соответствовать принципам REST, то можно смело называть их RESTful-сервисами.
Но лучше об этом не говорить, т.к. собеседник может принять вас за сумасшедших. Да, для многих REST и HTTP почти синонимы.

Тогда что принято называть REST-сервисами в повседневной жизни? Здесь хочу обратиться к модели зрелости REST-сервисов Ричардсона. Он выделяет 4 уровня зрелости REST-сервисов:

Уровень 0. Мы берем в качестве протокола HTTP, но при этом игнорируем рекомендации по использованию HTTP-глаголов и именованию ресурсов aka endpoints. Часто в таких случаях используют POST с одним endpoint. Сюда можно отнести SOAP, XML-RPC, JSON-RPC и еще много чего.
Уровень 1. Начинаем правильно работать с ресурсами, но по-прежнему ограничиваемся одним HTTP-глаголом.
Уровень 2. Мы научились использовать HTTP-глаголы, статус коды и разделять endpoints так, как предусмотрено HTTP.
Уровень 3. Все то же самое, только дополнительно реализуем HATEOAS

Так вот, чаще всего REST-сервисами называют:
⁃ Сервис Уровня 0, который использует JSON. Так называемый JSON поверх HTTP, или JSON over HTTP
⁃ Сервис Уровня 2, т.е. правильное HTTP API

Кстати, многие считают, что REST-сервис - это обязательно JSON, XML использовать мы уже не можем. Хотя в концепции REST таких ограничений, конечно, нет.

#agile #scrum #процессы

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

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

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

А теперь попробуем посчитать, чего мы добились. Предположим, что на “скрам”-ритуалы уходит 10-15% времени команды. Это легко измеримая сумма S, здесь проблем нет.

Дальше можем экспериментально сравнить стоимость найма, когда мы
⁃ рассказываем кандидатам о “скраме” в командах
⁃ говорим, что используем вотерфолл, каскадную разработку и вообще не против традиционных ценностей
Посчитав разницу, получаем выигрыш на одного нанятого сотрудника dH. Если нанимаем много и часто, то экономия H может быть серьезной.

В итоге сравниваем два числа: S и H. Если H больше, то смело масштабируем “скрам” на всю компанию. Тот случай, когда подражание внешним признакам способно принести профит. А со временем кто-нибудь и о смысле задумается.
Допускаю, что “скрам” еще уменьшает текучку за счет общения внутри команды, но не понимаю, как оценить это.

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

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

https://t.me/pmdaily/780

#оффтоп

Словарь начинающего руководителя.

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