Postlar filtri


Разорванный день

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

Но ведь у Разработчика ситуация аналогичная. Посмотрите на эту визуализацию? (интерактивная, можно изучить каждую активность)

Это я лишь описал день разработчика. Добавил несколько событий в течение дня. И получается, что разработчик:
⁃ Работает над задачей не более 2.5 часов в день
⁃ Теряет 20-25% времени на переключение контекста между задачами

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

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

И если говорить про то, как менеджер может помочь разработчику в этой ситуации и сделать команду эффективнее:
- делайте больше приватных мест для работы (условный, homeoffice)
- покажите примеров, что нужно отключать все уведомления на телефоне и на компьютере
- Copilot все же помогает


Вайб-коддинг

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

Но, кажется, что с моим темпом выпуска статей, любая статья уже будет устаревшей, по крайней мере на тему AI 🙂

Тут вышла статья Вастрика, которая имеет ровно такое же название: Вайб-коддинг

Статью хочу оставить здесь, поскольку выводы и опыт, который описывает автор - совпадают с моим. Поделюсь основными выводами из статьи:

Но теперь вы понимаете, что с LLM надо разговаривать не как сеньор с сеньором, а как сеньор с джуном. Вы начинаете формулировать свои мысли более конкретно.
Каждый экран, каждая кнопка, каждый лаяут, размеры кнопок и иконок на каждом экране, положение меню, кнопки «назад» и даже выбор фреймворка — всё должно быть вами упомянуто и описано.

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

К теме того, что разработчики не нужны и теперь продакты могут сами сделать проекты одним промтом, то автор пишет:

Окей, всё как-то даже работает, но ощущение от нашего нового «стартапа» пока какое-то не то!
Наверное потому что он выглядит как вырвиглазное говно, как будто его айтишники писали.

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

Если в самом начале вы вносите буквально 1-2 правочки в сгенерированный код, чтобы всё заработало, то теперь уже приходится переписывать 10-20% LLM лапши каждый раз.
В какой-то момент баланс смещается с «я дофига продуктивный, LLM мне помогает кодить» в сторону «какого фига я трачу больше времени на исправление его ошибок, чем на написание кода».

Да, это то, что я тоже подтверждаю. Можно очень быстро сгенерировать решение, которое похоже на то, что вы просили. Но если нужно сделать рефакторинг – лучше это сделать самому. Потому что описывать структуру кода и проекта, которые должны быть на выходе – это очень изнурительно 🙂

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


И вопрос остается открытым, а что писать в статье, если все написано?)


AI делает нас тупыми

Заголовки, которые в среду наполнили мою ленту. Вышло исследование от Microsoft Research в коллаборации с институтом о влиянии использования инструментов GenAI (типа ChatGPT) на критическое мышление оператора (здесь краткое изложение). Но такой заголовок длинный, поэтому использовали желтый заголовок, которые многие репостнули. Такие издания как TechCrunch сделали приписку в конце все же, о чем это исследование.

Этот эффект я на себе испытал еще 1.5 года назад, когда писал об использовании AI в работе. Основные же идеи из исследования:
- Чем больше люди доверяют AI, тем меньше шансов, что они критически отнесутся к результатам
- Чем проще задача, тем менее вероятно операторы будут перепроверять результаты
- Работа смещается с "найти информацию" на "перепроверить информацию и источники"
- Чем больше оператор уверен в себе, тем выше шанс, что он критически отнесется к результатам AI
- В условиях ограниченного времени доступного на решение задачи, критическое мышление отключается
- Отсутствие знаний в доменной области, не дает возможности оператору критически отнестись к ответам AI и понять, что они могут быть неточны.
- Уверенные в своих скилах специалисты (у них есть знания, опыт) могут перепроверить результаты из их доменной области и уже критически отнестись к ответу. Но не иначе.

При этом, AI дает "средние" ответы. Если человек принимает без изменений ответы от Chat GPT, то он становится "средним", поскольку теряется уникальность, креативность человека (того, кто думает, придумывает, создает). Люди не придумывают аргументы, почему это сработает, а "просят AI дать аргументы для их тезиса" или "найти подтверждения их гипотез" (вместо валидации и улучшения).

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

Простота использования искусственного интеллекта может склонить даже опытных профессионалов к менее строгому контролю. И сделать их "средними", такими как многие другие. Но откуда должна прийти новая идея?

Я прикрепил один интересный эксперимент от Benedict Evans, который показывает что AI не может выйти с фактами, на которые ему даже указываешь в явном виде. Почему? Потому что GenAI и им подобные инструменты - это не инструмент, который работает одинаково из раза в раз, он выдает вероятностные ответы. Ответы, которые с наибольшой вероятностью соответствуют запросу. В результате - появляются галлюцинации.

К чему это? Как и выше писал, AI - это инструмент, который нужно научиться использовать. Нужно помнить, что это не решатель задач вместо нас, но помогает нам с этими задачами. Важно задавать вопросы, перепроверять ответы. И задавать правильные вопросы

Например, в исследовании приведен отличный пример промпта, которые не просто решает задачу, а помогает оператору понять что сделано не так и почему:

read and break down all the suggested corrections to improve my
email writing style


И ответы в целом, очень позитивные получаются (привел пример из моего опыта) (прикрепил скрин последний)


Так вот, а что с рисками использования AI разработчиком?

Кажется, что тут много чего очевидного, особенно учитывая прошлое сообщение

Это подтверждается моим опытом, в том числе:

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

2. Когда код, написанный AI отправляется на ревью разработчиком уровня Senior, то это вносит определенный диссонанс. Код вроде стройный, ну и разработчику доверяют - он же Senior, фигню не напишет. А код писал не он, а AI. Ревьюер же этого не видит и в результате может закрыть глаза на какие-то неточности, шероховатости в коде. Ведь Senior код писал!

3. Снижение планки требований. Вот вам сгенерировал класс AI. И в целом, класс во многом отличен. Не соблюдены требования, которые вы бы применили (переменные названы иначе, не как snake_case). Мелочь, может и не нужно переписать? А в результате, с каждым таким разом увеличивается когнитивная сложность кода

4. Обучения не происходит. Потому что задача написать код (решить задачу), а не обучиться. Я, правда, думаю, что обучение уже остановилось тогда, когда стали брать готовые куски кода со stackoverflow, не вчитываясь в содержимое кода.

5. Когда весь код написан AI (это как раз мой эксперимент), то когда что-то перестает ломаться - ты уже не понимаешь где и почему сломалось. Много кода написано не тобой, в голове принятые решения не задерживаются. В результате код становится хрупким. Что-то изменил в отдельной части решения, сломалось что-то еще. Это выливается в то, что нужно много времени тратить на дебаг и поиск причин, почему не работает. В целом же, это нормально для огромной кодовой базы, где одновременно пишут десятки разработчиков. Но не для кодовой базы в 1700 строк. Вся модель решения с запасом укладывается в голове.

6. А еще я попробовал зарефакторинг код... Изначально у меня был код-лапша. Далее я попросил - а сделай красиво, пожалуйста, разложи по отдельным классам, все это собери аккуратно и запусти. AI сделал. Но потерял значимые куски кода, которые потом пришлось отыскивать по истории комитов; искусственно уменьшать контекст, чтобы не было подобных потерь. И здесь уже эффективность применения AI снижается для команды разработки.

Эти риски у меня не уменьшились с момента написания статьи про использование AI в Менеджменте. Нужно правильно использовать инcтрумент. У него есть границы применимости.


Кажется, что я упустил то, как AI активно внедряется в работу. Ну или, разработчикам стыдно признаться, что они используют Copilot активно для своей работы :)

Моя основная идея, что AI может помочь менеджеру лучше, если вы дадите этот инструмент своей команде разработки (обоснуете покупку лицензий, например).

Если посмотреть на работу инженера (вот исследования раз и два про рабочий день разработчика), то фактически разработчик кодит до 20% рабочего времени (1.5-3.5 часа в день). А все остальное время - он занимается работой, но не кодингом (встречи, чтение документации, чинит баги, вручную сидит и делает что-то). И задача AI - пусти даже на 10% увеличить эффективность разработчика. То есть, дать инструмент, чтобы те самые 20% рабочего времени выдавали больше результатов.

Так вот, Github Copilot вокруг меня, по статистике используется 70% инженерами. Но никто не говорит об этом!

Я спросил явно, какие сценарии применения у инженеров, получились достаточно интересные:

- При работе с большой кодовой базой

Расскажи, что тестирует вот этот тест на 1000 строк? Какие функции он проверяет?

Вот эта функция, где она используется в моей кодовой базе? Как она тестируется?

Я написал вот эту функцию, она выполняет вот такую задачу. Как я могу улучшить эту функцию?


- Работа с неизвестным языком программирования (в котором инженер неопытный)

Я работал с chef 3 года назад, и часть забыл, поэтому я спрашиваю - объясни мне, что эта часть кода выполняет?

Мы много стали писать на C#, но я только переключаюсь на этот язык, поэтому я прошу Copilot написать мне ту или иную функцию на C#. Или написать тесты к этой функции, которые я проверяю и принимаю

Вместо поиска документации по множеству источников, я спрашиваю у Copilot, он мне дает ссылки на них.


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

В целом, я рад, что разработчики применяют этот инструмент. Еще идет период поиска границ применимости этого инструмента. Об этом я расскажу завтра :)


1700 строк кода

Я все еще пишу сервис, с использованием AI, о котором писал пару недель назад. Написано 1700 строк.

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

Главное, что меня волнует - мне кажется, что это какое-то читерство. Я не уделяю внимание важным вещам, а просто "прошу кого-то" выполнить за меня мою работу. Но если углубиться, в чем же разница?
Предположим, мне нужно интегрироваться с внешним сервисом. Мои действия?
1. Найти документацию внешнего сервиса
2. Изучить API или SDK, если они предоставляют его
3. Написать код интеграции.
4. Протестировать и принять решение о готовности

Особенно много времени я трачу на 1 и 2 пункты. В случае же применения AI, у меня получается:
1. Сформулировать вопрос и ограничения известные мне
2. Получить код, прочитать его. Убедиться, что код делает то, что я хочу
3. Встроить код в мое решение
4. Протестировать и принять решение о готовности

Конечный результат - одинаковый. Но в первом случае я трачу много времени на первые 2 пункта. Во втором, я получаю ответ за 5 минут.

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

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


RescueTime опубликовал отчет о потраченном мною времени за 2024 год.

В этом году у меня был выпуск по мой личной эффективности, где я ссылался в том числе на отчеты от RescueTime. Я собираю время о своей активности с 2013 года, поэтому статья получилась достаточно инитересной. На Хабре тоже поставили лайки.

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

На минуточку - это 754 часа за год! В месяце 160 рабочих часов, то есть это 4 полных месяца я провел в чате и в почте, 30% рабочего года.

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

В конце дня / месяца / года посмотреть и ответить себе на вопрос - тот результат, который вы имеете сегодня стоил ли он этих усилий или нет?

Устанавливайте себе RescueTime и начните уже собирать данные о своей активности :)

Весь мой отчет доступен по ссылке


Эффект самозванца не дремлет

Помню давно читал историю CEO Atlassian о том, что он постоянно живет с этим чувством. Что он не достоин того, что он уже заслужил и это все какая-то ошибка.

В статье 2018 года он приводит несколько примеров, которые подтверждают на его взгляд его ситуацию. Например:
- когда стартапу было 4 года и всего 70 человек, его пригласили представлять Австралию (стартап родом отсюда) на Всемирном конгрессе предпринимателей. Как он сказал, рядом с ним сидел предприниматель с 30 тыс сотрудниками и 4х-миллиардным бизнесом. А у него всего 70
- на встрече с советом директоров он сидел и не понимал все акронимы, о которых говорят эти люди в пиджаках. Поэтому он после встречи шел их гуглить, чтобы понять о чем была встреча

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

Поскольку я занимаюсь преподаванием, развитием людей, меня такое чувство посещает постоянно. Я рассказываю какие-то очевидные вещи и чувствую себя из-за этого дискомфортно. Ведь все это есть в Интернете? Зачем вы пришли меня слушать? Да, информация подается в пропорции 70-30 (теория - и мой опыт), то есть ценное - это только те 30%, которые составляют мой опыт.

Правда, понимание этого меня все равно не успокаивает. После воодушевления, что помог людям узнать что-то новое, наступает чувство самозванца, что люди зря потратили время на мою посредственность.

Не быть мне предпринимателем 🙂


Уже несколько раз садился за подготовку нового выпуска - Как AI может помочь Project Manager'у сегодня. В 2023 году выпустил две части одной большой статьи. И на нее много приходит людей по релевантным поисковым фразам :)

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

И даже сейчас, чтобы написать статью, я сделаю предварительную статью - как разработать сервис без программирования :)

И вот небольшой спойлер - в этом месяце я уже потратил 6 часов на общение с Chat GPT, чтобы он написал мне код. И примерно столько же на работу в Visual Studio Code.

Из предварительных выводов - сервис, конечно, начинает работать. Но смог бы я это все написать, не имея базовых навыков и опыта программирования? Ответ на этот вопрос я оставлю для следующего выпуска рассылки. Очень верю, что будет в Феврале


📨 Выпуск 13 рассылки уже в ваших почтовых ящиках!

Этот выпуск снова про "Заметки из корпорации" - то, что опубликовано частично в этом канале и, конечно же, порция неопубликованного.

Выпуск состоит из 7 историй, которые могут описывать работу большой организации. Такие истории ни в коем случае не описывают именно Microsoft, если посмотреть истории из подобного размера компаний – можно увидеть ровно тоже самое. Поэтому, это истории про большинство крупных копораций, независимо от сферы. Налог на корпорацию 🙂

Прошлый выпуск из цикла был опубликован еще в сентябре.

В подкрепление этого выпуска, хочу поделиться выпуском подкаста Бреслава и Ложечкина, который рассказывает о росте в корпорациях 🙂


Пойдем, а то сейчас тетя выйдет и наругает

Эту фразу я услышал от мамы тодлера, которая пыталась уговорить ребенка пойти вместе с ней. Ребенок увлекся красными коробками для подарков и санями, которые украшали вход в кафе.

И эта фраза напомнила мне о том, что менеджмент и воспитание - это одно и тоже. И в воспитании детей, и в работе с командой - используются одни и теже фразы и подходы. В одном из чатов за такое сравнение 'https://t.me/regularmanagement/1438?comment=14273https://t.me/regularmanagement/1438?comment=14273' rel='nofollow'>меня высмеяли, но отрицатение отдельных личностей не отменяет аналогичность подходов :)

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

Чтоже происходило?
Ребенок увлекся интересным то, что ему нравится, вероятно получается очень хорошо (по версии ребенка). Маме не понравилось то, что делает ребенок. Это идет в разрез ожиданий мамы (предположим, она хотела бы, чтобы ребенок сел в санки и она увезла куда-то)
Мне неизвестно, была ли у мамы реальная причина, по которой им нужно было бы уехать. Но я видел, что они минут 5-7 были у этого кафе и играли. Срочности я не видел :)

Что можно было бы сделать?
Это не ребенку нужно куда-то ехать. Это нужно маме. Или Мама не хочет заниматься с ребенком именно этим занятием. Можно ли было объяснить ребенку, что маме неинтересно этим заниматься? Что им нужно прийти к такому-то времени в здании? Что Мама замерзла? Много вариантов, которые обозначают реальное желание и причину мамы, по которой нужно идти.

Вместо этого, Мама использовался отссылку к авторитету и запугивание.

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

Ровно аналогичная ситуация. Только вместо мамы - руководитель. Вместо ребенка - подчиненный.

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

Вот цитата из похожей статьи (но про ребенка), к чему ведут такие запреты:
В итоге у ребенка формируется только внешняя совесть, только одно правило: можно все, пока не видит тот, кто может наказать. А внутренняя совесть — та, за чье формирование отвечает мама – отсутствует. И у ребенка в результате нет внутренней системы запретов: это можно, а это нельзя, потому что плохо для окружающих.


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


Тем не менее, поделюсь немного инсайтами с опроса. В опросе есть вопрос - "какой совет вы дадите начинающему менеджеру проектов?" Мне кажется, что часть ответов стоит опубликовать для вас, чтобы в следующем году вы могли сделать что-то иначе 🙂

За простыми словами в этих фразах, заложен опыт и, вероятно, недавние ошибки и разрешенные проблемы респондента.


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

💡Делать проекты, ошибаться, получать обратную связь и снова делать

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

💡Не тяни резину: позвони, напиши, хоть что-то сделай сразу. СРАЗУ! Не оттягивай! Сделай маленькое действие прямо сейчас! Дальше будет легче

💡- Найти хорошего наставника, который готов объяснять, делиться знаниями и опытом - а самому быть готовым использовать в своей работе все рекомендации, даже если что-то кажется рутинным или есть сомнения в пользе выполняемого действия. Пока не попробуешь - не сможешь сделать правильные выводы, да еще и рискуешь наделать кучу ошибок, которые можно было предупредить и избежать.
- Честно и откровенно общаться с Заказчиком и с командой. - Знай "триггеры" и старайся не ввязываться в заведомо провальные проекты (сил и времени на них потратишь много, а результатом всё равно вряд ли сможешь гордиться):
-- где Заказчик не способен слышать/идти на диалог;
-- ожидания Заказчика не совпадают с реальными возможностями продукта и команды Исполнителя;
-- сроки указаны "как надо Заказчику", а не рассчитаны исходя из трудоемкости работ.
- Помни, что "плохой", "сложный" Заказчик - обычно исключение из правил. Любому Заказчику нужен успешно завершенный проект также, как и тебе! Если на каждом твоем проекте "плохой" Заказчик - то либо в компании, где ты работаешь, что-то не так с продажами, обещаниями, расчетами на пресейле; либо ты на старте проекта и в ходе него не договариваешься с Заказчиком о реалистичных ожиданиях и возможностях.

💡Браться за любые задачи, проводить работу над ошибками и завести дневник выводов. Фиксировать все задачи, проблемы, сложности, что удалось решить, а что нет, по какой причине? В дальнейшем этот извлеченный опыт превратит тебя в сильного РП


Ничего не пишу, а канал подрос. 20% собрано

Тем не менее, прошу прощения за то, что нет обновления 2 месяца уже. Много сил потрачено на опрос

Вот что получилось из проведения этапа сбора данных по опросу
- Мы собрали 20% (400 ответов) по русско-говорящему сегменту. Это промежуточная цель, которую мы перед собой ставили. Остальные 80% предполагали собрать в Европе
- Сделали попытку выйти на Европейский рынок и она оказалась неудачной. Непонятно, где и как искать респондентов. Поэтому весь опрос разделили на 2 части. Русско-говорящий и Остальной мир. Остальной мир будем опрашивать в следующем году, сейчас вырабатываем с командой варианты выхода на этот рынок
- Вероятно, на Европейском рынке нам нужно действовать через ассоциации профессиональные (PMI, IPMA, PRINCE2) и инфлюенсеров (Nader Rad, как пример или профессиональные новостные рассылки и порталы)
- В русско-говорящем сегменте нам не удалось дотянуться до чиновников, строителей и металлургии. Эти люди редко появляются в профессиональных комьюнити (в телеграмме и в фейсбуке). Еще не оставляем надежд
- Практически все владельцы крупных каналов шли навстречу нам, чтобы опубликовать наш опрос! Посмотрите на этот список, более 40 каналов! (на любой из них можно подписаться)
- Есть и те, кто нам отказали в поддержке. Часто причина - мы не участвуем во всем этом, Вторая причина - размещение рекламы платное. Из приятного мне - те сообщества, участником которых я являюсь давно - ни один не отказал!
- Я познакомился с большим количеством авторов каналов. Это позитивных исход лично для меня - расширил круг профессиональных знакомств :)

Возможно ли выйти за пределы 400 респондентов? Я думаю, что да. До 500-600 реально догнать, но уже в следующем году.

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

Что будем в следующем году?
- Мы выпустим отчет по русско-говорящему сегменту
- До Апреля будем собирать данные по международному рынку
- Летом выпустим международный отчет (как соберем данные)
- Попутно соберем еще немного из русско-говорящего сегмента
- У меня есть заготовки уже 3 новостных рассылок! Буду надеяться, что у меня получится поделиться с вами ими
- Следующий выпуск выйдет в 10х числах января

Не там много сил потрачу на опрос

С Наступающим Новым годом!

🌲


10% собрано!

За 3 недели исследования, мы собрали более 200 ответов, при нашей цели в 2000. Это 10%, что означает, что нам еще несколько месяцев собирать данные такими темпами :)
Это как проект, каждый день, с каждой анкетой, прогресс увеличивается на доли процента.

Чем я могу уже поделиться за этот период?

Ниже часть статистики. Она отфильтрована по странам СНГ. Когда будем готовить большой отчет, то сделаем в разрезе стран. Но пока - отдельные факты:

- Самые распространненые методологии - Scrum и Kanban (распределение ответов - одинаковое, поэтому можно считать это одним и тем же), стандарты по PMBoK
- Jira, Miro, Excel - самые распространенные инструменты для оперативного планирования
- На просторах СНГ - Telegram, самый распространенный инструмент коммуникации как с Заказчиком, так и с командой
- Большинство респондентов используют инструменты AI в своей работе! И это Chat GPT в его бесплатной версии :)
- 80% из тех, кто используют инструменты AI - используют его каждую неделю или чаще
- Примерно равное распределение респондентов по работе из офиса / гибридному / полностью удаленному формату

Эти данные еще могут измениться, и вы можете на это повлиять. Отчет полный подготовим в следующем году, а пока ждем ваших ответов и репостов :)

https://surveys.meet-deadlines.kz/


Социальный конформизм используется в политике, в маркетинге. Он влияет на вас прямо сейчас, когда вы читаете этот пост (поставьте лайк :))

И для того, кто лидирует команду важно понимать, как его можно применять.

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

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

Этот и другой эффект описал в статье (в пост не влезает, к сожалению, только в серию постов)


Выпуск 12 рассылки уже в ваших почтовых ящиках 🙂

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

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

Для понимания в чем суть эффекта - предлагаю посмотреть оригинальный эксперимент, который проводился более 70 лет назад 🙂


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

Основные характеристики социального конформизма:

- Групповое давление. Индивид меняет своё мнение или поведение в ответ на влияние группы, даже если это противоречит его личным убеждениям.
- Желание принадлежать. Стремление быть частью группы может заставить человека приспосабливаться к её нормам и правилам.
- Страх отвержения. Люди боятся быть исключёнными из социальной группы или осуждёнными, поэтому они подстраиваются под её ожидания.
- В дополнение, эти характеристики могут усилится атрибутами власти (Должность, Форма, Признаки состоятельности), то есть всем что увеличивает социальны статус индивида в конкретно взятом сообществе.

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

Как этот эффект влияет на общество и на вашу команду в частности?

Отличный пример показан применения этого эффекта на примере одной взятой компании - разговор на TED



18 ta oxirgi post ko‘rsatilgan.