Смотрите, чего Jet Brains сделали. Целую IDE для техписов и тех, кто работает с документами! Кто то уже пробовал?

Writerside – IDE для технической документации

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

👉Построена на принципах Docs-as-a-code: встроена работа с гитом, системами сборки и автотестами.
👉Умеет работать одновременно с XML и Markdown. Поддерживает встраивание Mermaid диаграмм и LaTeX.
👉Встроена куча инспекций, которые проверяют качество документации.
👉Live preview для доков, которое обновляется на лету.
👉Доки собираются в артефакты, которые легко опубликовать в вебе.

Пока Writerside в раннем доступе и распространяется бесплатно, так что можно пробовать.

Минутка токсичности. Многие знают, что уже больше 2,5 лет я успешно веду курс для СА с опытом. Естественно, чтобы быть в курсе рынка, мониторю другие курсы, смотрю, кто и что подает. Если есть возможность, хожу на открытые уроки, челенджу преподавателей. Послежний раз ходил к цифровым привычкам, которве стянули у меня 2\3 программы, даже опечатки не поправив)
Но речь не о них. Увидел тут, что Иннотех (раньше ИТ дочка ВТБ, теперь кусок монструозного Т1) сделал курс для аналитиков с опытом, чтобы вы поучились, а самых талантливых возьмут на работу. Идея классная, и пиар и сотрудников найти и под себя научить, и кадровый резерв на всякий случай, одни плюсы.
А теперь про реальность. Описание самого курса нигде нет, есть ссылка на тест. Тест на 92 вопроса (это ж насколько надо хотеть работать в Иннотехе, чтобы всерьез их заполнять?). Посмотрел я на те вопросы и не понял таки, кто там нужен и чему будут учить, но явно не аналитик, даже не системный.
Разбит тест на 4 блока: общие, SQL, BPMN и UML. Про требования один или два вопроса. Зато тупое задротство (извините, но под другому я это назвать не могу), в стиле как расшифровывается UML, BPMN, SQL и IDEF (они реально его еще используют что ли?). Причем про IDEF правильного ответа в тесте нет)
Есть нескольво вопросов про АПИ. Например, в каком элементе REST! запроса передаются данные на сервер: в теле, в пути, в заголовках или параметрах запроса. Правильный вариант всего один.
Вопрос про БП понравился - в каких нотациях удобнее рисовать БП: (BPMN И UML) ИЛИ (EPC И Idef) - правильный только один вариант. И судя по следующему вопросу: В какой нотации вы будете описывать бизнес процесс И диаграмму последовательности. Правильный ответ таки (BPMN И UML).
Есть вопросы по SQL, как создавать БД, добавлять и дропать таблицы, давать пермишены и тд.
Вопросов про потребности, способы выявления требований, управлние ими, проектирование архитектуры или интеграции особо нет.

Отсюда вопрос, чем, блин занимаются СА в Иннотехе? Судя по тесту, рисуют БП в БПМН, и в UML cо слов заказчика (интересно, какая все же диаграмма используется?), потом делают сразу диаграмму классов и последовательности и там же, не приходя в сознание РУКАМИ! создают БД и таблицы, обязательно в транзакциях (про COMMIT и ROLLBACK тоже спрашивают) и все. Но что радует, документацию, похоже писать не требуют😆.
А, да, забыл! Еще в активити диаграммах обязательно описывают последовательность операций внутри метода класса!!
Ну цирк с конями, блин. Чего хотят от аналитиков и чему собираются учить - не понятно, но после этого теста, я даже близко к Иннотеху подходить не буду, уж извините.
P.S. а вот картина с завершения теста на фирменном канцелярите.

После моей токсичности вот вам пилюля (да, но нет) в виде статьи от Кати Лысенко про ее вижн, каким должен быть аналитик. Я, конечно, могу докопаться до деталей, но с сутью согласен на 100%.
В последнее время я очень часто слышу от аналитиков просьбы дать фреймфорк, как делать хорошо и не делать плохо. Но проблема в том, что такой пилюли нет. Анализ он как раз про то, что нужно очень много слушать, очень много думать, очень много пропускать через себя, очень много знать и потом все это синтезировать в идеи.
https://www.linkedin.com/pulse/%25D0%25B0%25D0%25BD%25D0%25B0%25D0%25BB%25D0%25B8%25D1%2582%25D0%25B8%25D0%25BA%25D0%25B8-%25D0%25B2%25D0%25BE%25D0%25B7%25D0%25B2%25D1%2580%25D0%25B0%25D1%2589%25D0%25B5%25D0%25BD%25D0%25B8%25D0%25B5-%25D0%25BA-%25D0%25BA%25D0%25BE%25D1%2580%25D0%25BD%25D1%258F%25D0%25BC-%25D0%25B2-c%25D0%25BF%25D0%25B8%25D1%2580%25D0%25B0%25D0%25BB%25D1%258C%25D0%25BD%25D0%25BE%25D0%25BC-%25D1%2580%25D0%25B0%25D0%25B7%25D0%25B2%25D0%25B8%25D1%2582%25D0%25B8%25D0%25B8-lysenko-7egwe/

Всем привет, несколько видео посмотерел в последние дни.
Первое про метрики в Канбане и Скраме. Очень ценные примеры по совместному использованию скрама и канбана, спикеры разбируют, как совместить и померить производительность и эффективность. https://www.youtube.com/watch?v=IEI-IAIvQFc

Думаю, многие слышали, что в понедельник не стало Сергея Мартыненко.
Всю неделю хотел что то написать и не мог.
Это очень странно, я видел Сергея вживую всего два раза. Но даже их хватило, чтобы понять, что это человек потрясающего ума и он был прекрасно осведомлен об этом!
Порой, слушая Сергея, казалось, господи, что он несет. А потом через 5 минут, через час, на следующий день до тебя доходило.
А еще Сергей мне запомнился двумя почти бессонными ночами, проведенными за игрой в Бенг на костях на ЛАФ 2021, там его переиграть было так же непросто!
Чего хочется сказать напоследок. Дружище, желаю тебе попасть в лучшую из твоих сказок и найти там достойных оппонентов.

Я всегда подозревал, что с российскими банками что то не так. Но что они пользуются услугами тарологов, это прямо открытие.
P.S. Искренне надеюсь, что это фейк или шутка

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

Бизнес-мракобесие

Тут полезняшки с Analyst Days. Кто не в чатике, забирайте

Очередной привет от Кати Лысенко. Очень жесткая статья, аккуратно, может сломаться картина мира https://www.linkedin.com/pulse/%D0%BB%D1%8E%D0%B1%D0%B8%D0%BC%D1%8B%D0%B9-%D1%85%D0%BE%D0%BB%D0%B8%D0%B2%D0%B0%D1%80-%D0%BD%D1%83%D0%B6%D0%B5%D0%BD-%D0%BB%D0%B8-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5-ekaterina-lysenko-ozxfe/

Немного интересного с Вебсаммита. Всякой крипты и VR навалом, а вот тут интересная штука, с помощью AI позволяет оцифровать и оптимизировать сетевую инфраструктуру)

ARIS уже не тот

Сегодня мне стукнуло 38 (у меня еще 26 ноября в Лиссабоне, так что все ок)
Обычно итоги подводят по календарному году, а я решил подвести итоги году жизни. А он был что надо, насыщеным и интересным:
- Я сменил страну. Опять. Теперь я обитаю в Португалии и мне тут нравится.
- Я отдохнул 3 месяца в саббатикале.
- Я сменил машину. Всегда мечтал о BMW и наконец то смог себе купить.
- Я сменил работу. Да, опять. И не просто работу, я окончательно сместился из чистого ИТ в продуктовый менеджмент, чем несказанно доволен.
- И я (естестенно не один) сделал в Лиссабоне крутую конференцию EpicHey, которая будет уже в эту среду.
И то ли еще будет!
С днем рождения меня!

Мы это сделали! Сегодня первый день нашей конференции EpicHey!, которую мы собрали в Лиссабоне за предыдущие полгода.
200 человек, больше 40 спикеров. Ваш покорный слуга открывал конференцию в качестве программного директора. новый, волнующий опыт, но у нас получилось!)

Наша конфа начинает собирать отзывы, народу понравилось. В течение перы дней наберусь сил и напишу подробнее о своих впечатлениях!

Новая реальность IT конференций

Заглянул вчера на англоязычную конференцию EpicHey, которую организовала русскоязычная команда в Лиссабоне. Для первого раза получилось очень бодро! Ребята хорошо подошли к выбору спикеров — получилась отличная смесь из докладов про разработку, управление продуктами и тестирование. Все выступления были на английском, хотя для большинства спикеров и участников это не основной язык. Так что в кулуарах часто переходили на русский 🙂

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

#portugal

Решил тут почитать статей аналитических, а то пока к конференции готовились совсем времени не было. И сразу наткнулся на вот этот опус https://habr.com/ru/companies/X5Tech/articles/777196/. В целом, чтобы понять про что статья можно обратиться к первой фразе заключения: Что же делать, если артефакт нужен, а задача под него не подходит? Не отчаиваться!
В целом, наверное, отчаиваться и правда не стоит, но и карго культ делать не надо, если артефакт не подходит - надо взять другой.
Возьмем первый пример по CJM (Customer Journey Map). Зачем он нужен, когда мы описываем внутренний бизнес процесс? Посмотреть на эмоциональную реакцию логиста, когда привезли топливо не на ту заправку? Я и так ее знаю 😂. CJM нужен только в продуктовой разработке, когда делается продукт для широкого рынка, для внутрянки или заказной разработки проще делать описанные БП.
USM вообще то логической продолдение CJM, на котором вы раскладываете те самые эмоции и мотивацию по историям, чтобы понять, как вам разложить реальный путь пользователя на систему, продукт или ручные задачи. В этом, кстати, самое главное отличие US от UC. Стори можно закрыть ручным трудом и ничего не разрабатывать.
Очень важно, кстати, перед CJM и USM определиться с категориями пользователей, сегментировать, выделить персоны, без этого работать будет плохо. А еще между ними можно сделать ServiceBlueprint, как логичное развитие CJM, которое описывает, как тот самый путь пользователя ложится на наш сервис в общем виде, то есть без учета того, что автоматизировано, а что нет и где есть точки контакта. Это помогает дальше строить карту пользовательских историй. И, соответственно под конкретный шаг пути пользователя добавить не только его истории, но и истории и задачи развития сервиса.
Ну и финальный аккорд это Impact Map. Суть ее вообще потеряна и удалена от книжки Аджича. То есть в целом ок использовать такую ментальную карту, но называть ее Impact Map не стоит. Кстати, Александр Бындю усовершенствовал Impact Map, назвав свой метод Карта гипотез, очень рекомендую к изучению. https://xn--80aajikek0bigwf.xn--p1ai/
Вывод простой - дорабатывать инструменты надо под свои нужды, но как минимум соблюдая принцип Сю Ха Ри, и не выдавать свои идеи на их базе за сами методы.

Итак, конфа прошла, и у меня появилось свободное время. А шило сами знаете где говорит, что его быть не должно)
Поэтому я готов взять на половинку декабря и январь трех человек на несколь менторских сессий.
Условия:
1. Все бесплатно
2. Общаемся по договоренности, сессия не больше часа и не чаще раза в неделю
3. Запросы присылайте вот сюда: https://forms.gle/ingi1o3Jqcm3ybLW9
4. Выберу три интересных мне запроса до 13 декабря
5. Если вы не приходите на назначенную сессию с вас штраф, небольшой, но обидный.
6. Почему и кого выбрал объясню после того, как закончим сессии. Или не объясню)

Давно в списке to read лежала статья СберМаркета про проджектов в продуктовом подходе. https://habr.com/ru/companies/sbermarket/articles/772390/
Что я могу сказать, в той системе, в которой работает СберМаркет оно, кажется, действительно, надо. Является ли это продуктовым подходом? Большой вопрос. Есть ли гибкость? Тоже не понятно. Если у вас выстроена вся разработка так, что даже небольшие доработку требуют учёта и проработки большего количества зависимостей, а это следует из упоминания про удвоение количества проджектов меньше чем за год, то проблема похожа на неэффективность всего процесса доставки ценности.
Я с таким сталкивался в МТС, когда у меня был весь день забит митами с различными проджектами различных проектов, а про интересантов, бизнес заказчиков проекта особо ничего не было известно и их было даже не видно. У вас есть куча документов, ТЗ и тому подобного.
Проблема появления проджектов в том, что они не решают системные процессные проблемы, а лишь закрывают дыры в этих процессах собой. таких проджектов на моем пути встречалось 99%. Зачастую они кроме всего прочего не мыслят категориями ценности для бизнеса, а только категориями закрытия проекта в срок любой ценой, т.к. их КПИ на это намертво завязан.
Наличие в статье упоминания Деливери менеджера меня очень порадовало, т.к. именно деливери это основная функция проджектов, а подпускать их к целеполаганию мне кажется излишним. Правда ребята деливери менеджером называют скорее человека, выстраивающего процессы в целом, но и это очень хорошо, хотя если мы говорим про процесс гибкой разработки ПО (а судя по двухнедельным спринтам это он), то логичнее все же использовать Agile coach, правда хорошие стоят очень дорого.
Главное преимущество тут будет в том, что, как я говорил проджект закрывает собой функцию, а Коуч учит команду и компанию обходиться без проджектов за счёт коллаборации и ответственности.
В целом, я ничего не имею против хорошего проджекта, но проблема, что для многих строгое управления проектом в железном треугольнике становится гораздо важнее доставки реальной ценности. Как только это поменяется, я сам буду топить за проджектов. Кстати, у нас на конфе Надер Рад, один из создателей методологии p3express рассказывал об особенностях ее применения, когда получится, выложу презу и ссылку на запись вступления, проджектам точно пригодится