Доброго вечера! Накину немного в вечер пятницы (а когда же еще)😈
Я все не оставляю своего любимого конька про Agile и самоорганизующуюся команду высокомотивированных профессионалов.
Для многих Agile в силу его насильного внедрения на уровне карго культа в организациях стал просто ругательным словом, что меня заставляет сильно грустить.
На первый взгляд кажется, что это понятный концепт, потом, что оно невозможно. Но если детально подумать, что под большинство концептов Agile можно найти логичные объяснения.

Возьмем, например, спринты. Зачем это нужно?
Все очень просто: есть закон Паркинссона: Всякая работа занимает ровно столько времени, сколько на нее отведено или больше.
Соответственно, если мы искусственно создаем ограничение в виде спринта, то сотрудники и будут целиться в пределы этого спринта.
Ведь вы знаете, что в конце спринта нужно показать результаты своей работы. Именно поэтому, кстати, Скрам настаивает на обязательном ритуале обзора результатов спринта, чтобы этот дедлайн был ощутимым.

Плюс еще одной важным плюсом работы по спринтам можно назвать привычку или, если угодно, рутину.
Для каждого человека очень важны ритуалы. Утренний кофе, душ, зарядка, медитация. Я это понял, глядя на своего ребенка, которому, чтобы спокойно пойти в кровать нужно выполнить несколько обязательных риталов. Если их не выполнить, то можно словить нехилую истерику.
То же самое и для взрослых людей. Нам важно "заземляться", рутина помогает нашей голове расслабляться и делать какие то операции на автомате, выстраивая из них последовательность, снижать уровень стресса и потребления мыслетоплива.
И в работе от этого никуда не деться: ты знаешь, что сегодня дейлик, к нему нужно подготовить ответы на вопрос, а завтра релиз, послезавтра демо результатов. Тебе не надо об этом задумываться.
В целом, все больше убеждаюсь, что гибкие методологии разработки они в первую очередь про здравый смысл.
А как вы относитесь к Agile и его производным?

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

ИИ-заменитель

Survey Monkey изучила 1000+ маркетологов стартапов. Две трети ищут данные, которые у них уже есть. Половина не понимает, почему аудитория не конвертируется. Треть не знает, чего хотят потребители. Зато 88% заморочены тем, как внедрить ИИ в свою маркетинговую стратегию. У 72% это получается хреново.

Вывод прост: ИИ заменяет кофеин и энергетики, но не мозги.

Судя по дизлайкам к предыдущему посту кому то таки ИИ и мозги заменяет? Или как это трактовать? 😁

В продолжении темы сокращения лишних людей. Считаю, что unbossing принесет миру много пользы и кучу крокодиловый слёз эффективных менеджеров. Как менеджер вам говорю 😁

В выходные хочется немного поговорить о книге, которая стала моей любимой книгой на профессиональную тематику и одновременно вошла в мой топ с литературной точки зрения.
Это бестселлер Эльяху Голдрата "Цель".
Книга написана в духе бизнес-романа, привет тебе "Атлант расправил плечи". И с точки зрения произведения захватила меня с первых страниц и не отпускала до самого конца. Впервые я испытывал жгучее желание почитать книгу из категории деловой литературы, переживал за героя и проглатывал страницы десятками.

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

Используя Теорию органичения систем и точечный менторинг ученого Ионы (несложно догадаться, кто является его прототипом), руководители совершают ряд изменений, ломающих все общепринятые способы организации производства, учета и управления запасами.
Но самое главное с чего начинается изменение майндсета - это определение цели. Это огромная проблема, когда управление и операционка выстраиваются без видения конечной цели всего предприятия. Тогда начинается оптимизация локальных оптимумов, которые далеко не всегда ведут к достижению общей цели.
Ярким примером могут служить KPI сотрудников или отделом, которые никак не работают на достижение общей цели компании, а позволяют сделать лучше только самому департаменту. И тогда все это становится исключительно элементами политической борьбы между департаментами, чтобы добиться большего влиятия и бюджетов. Думаю, многие, кто работал в компаниях от 50 человек сталкивались с таким.
По цели, кстати, в книге все просто - цель любой коммерческой компании - зарабатывать деньги. Но тут я не сильный спойлер сделал, я надеюсь😄

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

Третий важный инсайт - про загрузку. Внезапно загрузка 100% - неэффективна, привет вам проджекты 😃. В книге описывается это с точки зрения отсутствия резерва по ресурсам с одной стороны и перепроизводства с другой стороны.
То есть когда вам нужно более приоритетный заказ прогнать - у вас не получится, все ресурсы заняты. При этом заняты они могут быть какой то низкоприоритетной задачей, просто лишь бы не сидели без дела. И вроде бы это относится к станкам, которые надо перенастраивать, перед которыми лежат ящики с деталями и тд. Но вспомните себя. Сидите вы делаете задачу, половину сделали, а тут прибегает эффективный менеджер и срочно кидает на аврал. Вы точно так же будете переключать контекст, откладывать результаты предыдущей задачи (складировать) и тд.

Ну а про главный инсайт напишу в следующем посте.

Всем привет! Напомню, что в воскресенье в 11 утра по Мск проведу мастер класс по работе с документами.
В рамках мастер класса разберем несколько подходов к подготовке документов:
1. ТЗ
2. Use case
3. User Story
4. Функциональные требования.
5. Другие (да, есть и другие)

Еще подсветим с вами тему, как эти документы можно использовать в дальнейшем при организации базы знаний.

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

Запись буду делать только для себя, публиковать запись НЕ БУДУ.
Условия участия:
1. Зарегистрироваться
2. Обязательно дать развернутую обратную связь и разрешить ее публиковать.
3. Участие бесплатное!

Очень крутой пост. Я в найме руководствуюсь ровно тем же, общаюсь с человеком, вместе рассуждаем, ищем решения, главное это реально ведь ход мыслей для аналитика. А все БПМНы со сваггерами приложатся, если голова работает

Как нанять кого угодно

Если нужен разработчик – смотри как он пишет код и сдает работу.

Нужен маркетолог? Пиши с ним объявления и вместе настраивай рекламу.

Редактор? Пишем тексты в прямом эфире.

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

Выгул собак? Идем и гуляем вместе.

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

Но проще всего сделать упор на практике.

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

Прочитал коротенькую статью от аналитика из Касперского про бизнес требования. В целом толково описаны семантические моменты отражения требований, хотя и выглядит это все оторванным от контекста, как например, Use case или что то подобное.
Но главная проблема в том, что так речь не особо про бизнес требования. Там скорее про те требования, которые нужно согласовать с бизнесом, реакция системы на действия пользователя или другой системы. Все же к бизнес требованиям это имеет достаточно опосредованное отношение.

Готовился к уроку по технике Event Storming, смотрел и читал много интересных и полезных материалов. Из них хочу выделить для вас три:
Выступление Дениса Бескова на конференции Flow c общим обзором техники и рассказом о ее применении. https://www.youtube.com/watch?v=-gG7snMlUDk
Выступление Сергея Баранова про многоликий ДДД, где автор рассказывает не только про саму технику Event Storming, но и про то огромное количество артефактов, которые можно из нее получить. И структуру команд и сервисов, и User story, и словарь доменов, и объекты предментной области, и тесты в стиле BDD https://www.youtube.com/watch?v=2WHarUW0PjI
И третье выступление, тоже Сергея, где он рассказывает о практических кейсах применения ES. https://www.youtube.com/watch?v=kJjuTuviZ-E

Очень интересный пост. И я, к сожалению, с ним согласен на все 100%, именно KPI, направленные на локальную оптимизацию количества нанятых в итоге стреляют компании в ногу.
Людей не прогоняют на совместимость с командой, причем ладно бы только психологическую совместимость, так зачастую даже по стеку. Типа вот фронт - 10 лет опыта. Но опыт на Ангуляре, а у вас Реакт, но рекрутера это не волнует, у него же KPI (реальный случай из практики моей).
Как считаете, проблема реально системная или преувеливаем?

Интересы тимлида и рекрутера не совпадают

На Хабре выложили аналитику по зарплатам рекрутеров. И все бы ничего, но есть там несколько интересных моментов:

👉Зарплаты линейных рекрутеров почти всегда зависят от KPI, которым выступает количество закрытых вакансий
👉24% опрошенных считают, что для повышения зарплаты им надо закрывать больше вакансий. Только 12% – что нужно улучшать сорсинг кандидатов.

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

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