#посмотреть

Обещал на прошлой неделе поделиться классными докладами, которые так или иначе касаются вопросов поведения около ИТ. Начнем с великолепного доклада Гриши Петрова - забудьте слово «ошибка». Под призмой когнитивных искажений и современной научной позиции рассматривается вопрос о том, как лучше разговаривать с разработчиками (и не только)

Тестируем новый формат - Конскружок. Покритикуйте. пожалуйста)

#посмотреть

С подачи Александра @VolAll в ленту врывается доклад Вадима Макишвили "42". Именно эту запись я буду рекомендовать в качестве преамбулы ко всему контенту на канале. Тут и про прелесть асинхронных коммуникаций, и про нейрофизиологию, и про когнитивные искажения) Рекомендую. @VolAll спасибо

А у нас новое видео в техкружке) https://www.youtube.com/watch?v=ew-ZTolmB5I

#почитать

Ого! Очень интересная подборка книг и все за бесплатно.

Кто что читал? @AnnaOxotnica добила Докинза?

#мысльвслух

В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности. Так звучит положение, именуемое как Принцип Питера.

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

Принцип, вроде как, шуточный, но грустнее от этого не становится. Мы то с вами знаем...

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

Миллионы долларов расходуются ежегодно на поиск элегантных и глубокомысленных ответов на неверно поставленные вопросы" К.Шеннон

И вот поэтому мы в команде в производство не берем задачи, в которых нет описания проблемы и возможных путей решения. При этом в 99,9% цели на входе подаются как задачи, и в 99.9% пользователи не знают чего хотят, или не знают чего можно хотеть. Задачи в производство должны попадать только после бизнес-анализа: сформулированным целеполаганием и одной или несколькими гипотезами, а еще с сформулированными критериями успеха (DoD). Идеально, если к этому еще приложить технико-экономическое обоснование, но пока для отрасли это кажется космосом. Очень хочется оказаться неправым.

#почитать

Подарок от Альпины. 12 бесплатных электронных книг. Подборка, разумеется, под стать временам.

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

#практика

Daily meeting (о том как у нас это устроено). Чуть-чуть об этом расказывал на нашем канале, получилось бегло и невнятно. Здесь подробнее.

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

Перед мероприятием каждый член команды отвечает на следующие вопросы (в telegram-боте):

🔻 Что ты Сделал вчера? Очень важно сделать акцент именно на том, что Сделал, а не делал: «Из запланированного вчера я сделал это и это»
🔻 Что ты НЕ сделал из запланированного вчера? Рассказать, что было запланировано, но по той или иной причине было не выполнено
🔻 Что ты планируешь Сделать сегодня? Рассказать, какие задачи запланировано выполнить сегодня. Акцент на Сделать, а не делать
🔻 О чем ещё ты хочешь сообщить команде? Озвучить проблемы в рабочем процессе или поделиться любой информацией, которую ты хотел бы донести до всех членов команды

Зачем это мероприятие?

Преследуем несколько целей:
🔸Синхронизация по ключевым моментам работы и по текущим задачам;
🔸Приучить мозг мыслить результатами (сделал), а не процессами, растянутыми во времени (делал);
🔸Коллегам понять, какие задачи имеют переходный характер, насколько мы близки к контрольным точкам. Руководителям − понять причины, почему предварительно намеченные планы не выполняются (высокая динамика изменения поручений, сотрудник регулярно переоценивает свои возможности, технические и внешние факторы и т.д.) и при необходимости предпринять корректирующие меры;
🔸Научиться разбивать одну большую задачу (например, написание ЧТЗ с запланированной длительностью 5 недель) на подзадачи (планировать описание конкретных разделов и подразделов);
🔸Научиться озвучивать на дейли информацию максимально полезную для всех его участников. Как только мы начинаем отвлекаться на сторонние темы или вопросы, которые можем решить внутри рабочей группы, мы утрачиваем фокус внимания непричастных к вопросу людей, тем самым создавая им дополнительное неудобство – они вынуждены переключаться, пытаться вникнуть, касается ли их этот вопрос или нет и т.д.

Где отвечаем на вопросы?

Вопросы в telegram присылает Zina (бот с бэкэндом на 1С) каждое утро в 9:00. По окончании опроса в 10:45 Zina отправляет консолидированный файл (xlsx) с ответами всех членов команды в telegram-группу.

Тайминг

Дейли-митинг начинается каждое утро ровно в 11:00 в Zoom. Для проведения мероприятия мы используем конфигурацию на Базе 1С: она сохраняет историю всех дейли, ответы на вопросы, делает замеры времени, помогает придерживаться рекомендуемой общей длительности до 15 минут.

Что еще?

А еще по многочисленным просьбам анонсирую в Q2 передачу этой кастомной конфигурации в Open Source: в ней бэкэнд для бота, отчеты по опросам, морда для проведения дэйли (скриншоты в комментариях)

#практика

Про чек-листы ☑️

По результатам одной из ретроспектив пришли к выводу - нам нужны чек-листы) Может быть - это начало конца, но тем не менее. Некоторые вопросы таким образом получится закрыть малой кровью. Мы определяем DoR (Definition of Ready, критерии готовности, чек-листы) к началу очередного этапа. К примеру, до начала UAT сделать заявку на актуализацию UAT контура; или написать (установить) мораторий на изменение данных в продуктивном контуре. DoR можно определить для каждого этапа , мы для себя пока фиксируем только чек-листы для старта спринта и UAT. Сами чек-листы - это задачи (task, issues) в трекере, их команда вносит перед началом спринта по шаблонам (template).

Пример шаблона так-же прилагаю. Для gitlab его нужно положить в репо: .gitlab\issue_templates\

В комментариях - как все это выглядит и пример шаблона для gitlab ↘️

#мысливслух

Фото с выставки «Искусство будущего» в МАММ

Писал про эффект ИКЕИ и о том, как можно «читерить», привлекая Заказчика к разработке.

С другой стороны, из текста на фото родилась мысль о том, чтобы Заказчик хвастался результатом своего труда с создателями (разработчиками). Эффект ИКЕА в этом случае будет действовать и на разработку. Как тимлид я, конечно, вижу все это на референсах, но еще круче, чтобы бизнес рассказывал разработчикам о том, каких реальных успехов / неуспехов они добились благодаря реализованным фичам. Почти уверен, что в каком-нибудь agile-фреймворке такая практика есть. Покопаем и попробуем…

🔥Мы сделали 1С: Батл 2.0. На этот раз вся концепция собрана благодаря опенсорс технологиям и комьюнити.

Это пост благодарности 🙏:
1. OneScript (https://news.1rj.ru/str/onoscript_library)
2. Универсальные инструменты (https://news.1rj.ru/str/tools_ui_1c)
3. Репозиторий hexlet codebattle (https://github.com/hexlet-codebattle/battle_asserts/tree/master/src/battle_asserts/issues)
4. Юрий Пермитин и его статья на Infostart - Вы запускаете приложения, но делаете это без уважения
5. Jitsi (видео-конференции) - https://jitsi.org/

Разобрали задачи с 1С: Битва. На выходных упакую все в репозиторий и передам комьюнити на растерзание.

Вам отличной пятницы)

Забирайте, терзайте, развивайте.

Отличных выходных 😺

❗️❗️❗️ Написал наиподробнейшее руководство контрибьютора для полных чайников (типа меня). Подойдет, разумеется, не только для проекта Let's code. Буду очень рад, если это хоть как-то снизит порог вхождения в разработку на 1С:EDT

И еще чуть изменений по Let's code:

🔸 Рефакторинг: исключил ненужное, привел в соответствие стандартам, исправил замечания Sonar
🔸 Подключил проект https://sonar.openbsl.ru/, за quality gate можно наблюдать с главной странички. Спасибо @nixel2007
🔸 Внес issues по обратной связи от коллег. Исправлены ошибки.

Про менторство

Рад тому, что вопросы менторства в 1С отрасли, как и во всей айтиишечке, стали подниматься чаще.
Вот и вчера @AnnaOxotnica на стриме упоминала про такой формат взаимодействия.

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

Где искать менторов?
1. Напишите запрос о менторстве напрямую человеку в telegram, github, etc. . Если у вас будет сформулированный запрос (пусть и не четко) или список вопросов, то шанс того, что вам ответят резко возрастает
2. Профильные порталы:
2.1. Бесплатно: getmentor.dev
2.2. Платно: solveri.io

🔥Люблю выполнять свои обещания

Готовимся к настоящему интервью в режиме онлайн⚡️
Спасибо за смелость @TA_Vladimir – выступит нашим «кандидатом» в роли Team Lead. Поможет мне оценить hard skills @plastinin

👨🏻‍💻Предлагаю всем присоединиться к Zoom 10 мая в 11.30
Тайминг: 2ч точно нам пригодится, чтобы оценить навыки и вместе проанализировать вопросы/ответы. Взглянем на процесс интервью с другой стороны🌟

Переходим по ссылочке: https://us02web.zoom.us/j/87484032423?pwd=YlV0M1VKbmxvSDU4N3Y1UUhVanRLQT09
Идентификатор конференции: 874 8403 2423
Код доступа: 917044

🔥 А вот и ссылка на Zoom-интервью на позициюTeam Lead
https://youtu.be/-3Ld4an84ns

🌟Спасибо нашему герою @TA_Vladimir за смелость и стойкость, 3 часа общения не каждый выдержит😉
🤩Спасибо @plastinin за поддержку, за крутые вопросы и просто так!

Спасибо всем, кто к нам присоединился и поддержал наш эксперимент♥️
Я рада буду вашей обратной связи,вопросам, критике и идеям!

По ссылке генератор шаблонов для баг-репортов (ну очееееееень простой)

А вы используйте шаблоны для регистрации багов 🪲?

#векжививекучись

К своему стыду узнал о существовании платформенного механизма Сравнить файлы только сегодня ;)
Не знаю применяют его на практике или нет, но уверен, что некоторым пользователям понравится.

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

Теория разбитых окон или почему важно проводить Code Review

Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна.

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

Причем здесь разработка и code-review, я думаю вы поняли, а если не поняли, welcome в комментарии 😜