Как происходит работа с приоритетами

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

Сейчас расскажу.

На очень базовом уровне у людей есть представление, что приоритет отвечает за то, что будет взято в работу первее. И все. В нормально работающей команде это не так.

Я перечислю факторы, которыми, например, может оперировать команда (часто менеджер команды) на основании заданного приоритета:

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

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

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

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

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

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

1. Критичный (Critical/panic/emergency) - "все бросаем и делаем это"
2. Срочный - как можно быстрее берем в работу и делаем максимально быстро, но без ущерба другой важной работе
3. Просто высокий - плановая работа (не срочная), но подчеркнуто важная. Нужно обеспечить выполнение без задержек
4. Обычный плановый приоритет, но важные - вообще не срочные, но ценные - не торопимся, но сделать надо
5. Обычный приоритет и не особо важные - вообще не паримся. Такие можно и дропнуть в пользу важных
6. Низкий приоритет - то, что мы делаем когда нечего делать

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

Это может выглядеть несколько сложно на первый взгляд (и граница между 3 и 4, например, тонкая), но это максимально близко к тому, как на моей практике людьми понимаются и исполняются приоритеты. То есть это - отражение реальности, и скорее открытие/наблюдение, чем изобретение.

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

Корпоративная культура, но по нормальному.

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

Допустим, вы в общепите и вам рассказывают про ценности вашей компании: Вкус, Качество, Доступность, Открытость.

Или вы в технологической компании: Взаимодействие. Инновации. Благосостояние. Включенность.

Ну что это за херня? %) Унылая. Так многие подумают, но почти никто не скажет.

При этом, несмотря на подобную встречающуюся повсеместно профанацию, корпоративная культура реально существует, и я сейчас попробую объяснить, почему это имеет огромное значение, в том числе лично для тебя.

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

Примеры реальных ценностей, определяющих то, как будет выглядеть для вас работа:

➖Честность или манипуляции
➖Веселье или серьезность
➖Рациональность и аргументация или вера и вдохновение
➖Жесткая иерархия или децентрализация
➖Неформальность или корпоративная бюрократия
➖Инициативность или исполнительность
➖Плюрализм или авторитаризм
➖Увлеченность или "просто работа"
➖Токсичность или доброжелательность

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

И вот эти вещи (в отличие от красивых слов типа "для нас потребности клиента на первом месте") - действительно имеют значение.

Есть такое понятие - cultural misfit (культурное несоответствие) - это когда у человека несовпадение с какой-то культурной средой.

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

Или ты хочешь просто делать свою часть работы, а от тебя требуют инициативы.

Или приходишь к руководителю с предложениями, а он отвечает: "тебе что, нечем заняться?".

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

В лучшем случае культурное несовпадение доставляет дискомфорт и демотивирует. В худшем - делает нас действительно несчастными.

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

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

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

Среди гостей нашего канала есть разные таланты ) зацените дебютный ролик отличного парня Жени Назирова https://youtu.be/7WlwIpzzYgU

К посту про корпоративную культуру сегодня появился интересный коммент, который стоит отдельной публикации в канале.

Вообще тот факт, что Пол (Paul Griffiths), чтобы читать посты, переводит их нейросеткой на английский, а когда пишет - переводит на русский, уже сам по себе заслуживает уважения )

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

Вот:

"Ответ директора по персоналу – Технологическая компания

Спасибо за столь яркое и честное размышление о корпоративной культуре. Как человек, много лет проработавший в HR — зачастую в самом центре «бури миссий и ценностей» — я не раз кивал в знак согласия, читая ваш текст. Вы очень точно уловили то ощущение разрыва, которое испытывают многие сотрудники между заявленной культурой и реальной повседневной рабочей средой.

Вы абсолютно правы: когда корпоративная культура сводится к лозунгам — она теряет смысл. Более того, она порождает цинизм. Людям не нужна «стена с ценностями» в холле офиса — им нужны лидеры, которые действительно демонстрируют эти ценности в своих действиях: на встречах, при принятии решений, при продвижении сотрудников и в ситуациях конфликта.

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

Позвольте добавить несколько наблюдений с точки зрения HR:

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

2. Культура сверху вниз — это правда, но не вся
Вы правильно отметили, что культура, как правило, идёт сверху. Поэтому развитие лидерства для нас — один из ключевых инструментов. Но влияние коллег не менее значимо. Микрокультуры формируются вокруг тимлидов, неформальных лидеров и даже внутри отдельных Slack-каналов. Умные компании инвестируют в выявление и поддержку таких носителей культуры на всех уровнях.

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

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

Маринование задач

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

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

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

Зачем это делают? Причины могут быть разные, например:

➖Менеджер оценил задачу как вредную или бесполезную, но при этом не хочет идти на открытый конфликт
➖Команда перегружена и таким образом выясняется, какие задачи "действительно нужны" - те, про которые кто-то вспомнит хотя бы еще 1 раз. Аналогично если перегружен сам менеджер
➖Нет ясной и работающей системы приоритетов, и таким образом с помощью маринования "на глаз" выясняется реальный приоритет
➖В компании идут какие-то подковерные игры и у менеджера есть мотив двигать вперед задачи одних людей и тормозить задачи других людей, чтобы зарабатывать очки в этой игре
➖Задача поставлена кем-то, кто не имеет полномочий, и менеджер не хочет создавать прецедент расширения фронта своих работ (и зоны ответственности)
➖Просто лень и хочется поменьше работать

И так далее.

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

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

Какие есть варианты контригры?

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

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

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

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

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

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

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

Как выяснилось, в Казахстане еще и не работают sms-коды, чтобы зарегать канал на ютубе. Заливать просто в телегу не хочу - тут плеер неудобный. В общем, как только решу технические вопросы, так сразу )

Забавно, что на свежем канале, походу, нормально превью еще даже не работают. В общем ловите ) https://youtu.be/-tsvCDTNlYk

Время как рычаг в переговорах

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

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

Теперь ближе к нашей теме. История моя.

Расклад был такой:
1. Компания искала человека на должность delivery manager (разновидность проектного менеджера).
2. Пара кандидатов слились уже после того, как пришли на работу.
3. Я там работал прогером и проявлял повышенную организационную активность.
4. Мне решили предложить занять эту позицию.
5. Я сильно хотел перекатиться в менеджмент.

Естественно, сторонам не было все это известно на момент сделки.

В начале была динамика такая - кто-то из топов (уже не помню кто) никак не может закрыть позицию. Мяч на стороне потенциального кандидата.

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

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

И гендир применяет этот прием - он начинает просто тянуть время. Со мной никто никак не обсуждает промоушен.

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

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

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

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

Естественно, я это считаю раком, и не рекомендую эксплойтить, но знать надо в том числе и для защиты. Ведя переговоры, стоит поразмыслить:

➖над тем, что нужно каждой стороне и как сильно
➖на чей стороне сейчас мяч
➖на кого играет время
➖как может поменяться ваша репутация в ходе переговоров

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

Делиться "очками" и не жадничать

Раз мы гуляем по закоулкам управленческих инструментов, то надо, справедливости ради, и про что-то позитивное и хорошее. Не всё же там - сплошные темные манипуляции.

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

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

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

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

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

1. Приписать себе лично
2. Присвоить абстрактно команде (это почти аналогично п.1, просто более культурно-корректно)
3. Отнести к кому-то конкретно из своей команды

По сути выбор между собой и кем-то другим.

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

Почему?
Чем выше позиция, тем больше вариантов выпендриться, а выше определенного уровня наступает, как и во многом другом, diminishing effect - ситуация, при которой положительный эффект чего-либо становится всё меньше по мере того, как это используется всё больше. Грубо говоря, если у вас позиция уверенная и крепкая, нет смысла ее и дальше бесконечно укреплять.

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

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

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

Что мне нужно изучить, чтобы понять менеджмент в разработке?

Таким вопросом может задаться начинающий тимлид или проектный менеджер. Если мне задать такой вопрос, возможно, лаконичность ответа удивит:

1. Набор статей Селиховкина по проектному менеджменту
2. Agile манифест + пара любых приличных статей его поясняющих
3. Канбан-метод, пара видео Алексея Пименова, его поясняющих
4. Scrum-guide

Всё.

Рецепт:
1. Внимательно изучить
2. Обдумать
3. Законспектировать

Результат: у вас есть 90% самой важной информации о том, на каких основах строится организация команд разработки.

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

Как это? Почему так мало?

По сути, инфу выше можно освоить за 2 недели не торопясь. Дней 5 на курс Селиховкина с конспектированием, день с запасом на Agile, день на Канбан, ну и день на scrum guide. Пара дней на перечитывание и осмысление конспектов.

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

Хотите верьте, хотите нет, в общем. Но я могу попробовать пояснить, почему так происходит.

То, что ощущается как "хороший менеджер в IT", состоит из трех фундаментальных вещей:

1. Умение руководить людьми
2. Понимание принципов менеджмента в разработке
3. Общие знания о сфере деятельности

Информация из прошлого поста закрывает 2 пункт. 99% разработки, с которой вы столкнетесь, ведется одним из способов или их комбинацией:
1. Потоковая разработка
2. Ведение проектов
3. Итеративная разработка

Как ни странно, очень многие (на любом уровне) в этом не разбираются, и у вас будет большое конкурентное преимущество, если разбираетесь вы. Даже на 90%. Остальные 10 приобретаются с годами работы и через чтение книг, но в начале это не принципиально.

3 пункт тоже относительно простой - это такие знания, как например:

1. Какие бывают роли?
2. Как выглядит процесс разработки?
3. Какие бывают отделы в компаниях, чем они занимаются?
4. Знание профессионального сленга
5. Какое-то базовое понимание computer science
6. Что такое бизнес-ценность и откуда она берется

Очевидно, что если вы не понимаете, что такое QA, продакт, API, или что компания может хотеть от разработки, вас никак не спасут знания о менеджменте в вакууме.

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

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

Итак, еще раз посмотрим на эти три пункта:

1. Умение руководить людьми
2. Понимание принципов менеджмента в разработке
3. Общие знания о сфере деятельности

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

➖Если Вы тимлид, вам может не хватать п. 2.

➖Если Вы где-то руководили, и теперь хотите стать проджектом в айтишке - вам нужно 2 и 3.

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

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

Win-win Club - AI in development

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

С конца 22 года я пробовал GPT. В основном просто развлекался по всякому. За последние 2,5 года пробовал разные модели и сервисы, но как-то не придавал большого значения именно практическому профессиональному использованию.

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

Я думаю очень многие попали в эту ловушку с мнением "клево, но до практического применения в реальной работе пока далеко".

Короче, с этого момента начался полет фантазии и мне стало гораздо интереснее.

Я провел опрос разрабов у себя в команде - кто как применяет. Выяснилось, что есть гигантское расслоение - есть кто вообще ничего не использует, а есть кто применяет на продвинутом уровне и в восторге, а есть те кому интересно, но они только начали разбираться.

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

И по конференции еще больше стало понятно - кто-то уже обогнал других на много месяцев в своем прогрессе по знанию инструментов и способов применения.

Дальше сделал внутри команды инициативную группу по использованию ИИ в разработке - 7 человек.

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

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

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

Ну и вот таким образом мы приходим сюда, к созданию клуба.

Что такое средняя тематическая тг-группа (если она не умерла):

➖спор ни о чем каких-то чуваков на 100+ сообщений
➖кружочки какого-нибудь полуголого мужика
➖кружочки "бля, пацаны, я сейчас бухой"
➖голосовухи с бэканьем-мэканьем
➖1-2 гиперактивных валенка (при всем уважении к валенкам) забивают весь эфир своей тупостью и мешают нормально обсуждать что-то серьезное
➖бесконечный поток мемов, стикеров, кеков

Я люблю иногда пофаниться. Но если я хочу инфы и ценности, мне нужно другое.

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

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

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

Я хочу собрать в нем интересных и умных людей, которые умеют читать и писать. Это в наше время не тривиально )

Win-win в названии подразумевает, что каждый что-то отдает другим, но получает взамен еще больше.

Сейчас в составе 29 человек. До конца года кап, вероятно, будет 50. Это значит, что еще 20-25 человек смогут присоединиться.

Если ты разработчик/QA/менеджер и после прочтения этого текста тебе тоже стало интересно, можешь оставить заявку на участие - напиши мне (контакты в описании канала) сообщение с тэгом #win_win_AI_club:
✔️кратко о себе
✔️какие ИИ инструменты используешь?
✔️несколько любимых способов использования

А еще у клуба есть страничка

Есть ли у вас план?

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

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

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

На картинке выше - выполненная блок-схема плана по делению отдела на кросс-функциональные команды. Рисую обычно в https://app.diagrams.net/
Выполненные блоки я закрашиваю, чтобы наглядно отслеживать прогресс.

Где в этом плане можно было бы облажаться:

➖Плохо продумать состав команд
➖Не обсудить с потенциальными тимлидами их мнение по составу, которое надо учесть
➖Не обсудить индивидуально с каждым членом команды, а поставить перед фактом (особенно часто так делают)
➖Не предупредить продакта
➖Не согласовать итоговый формат команд
➖Не подготовить доску в Jira и нужные поля заранее
➖Сделать в неправильном порядке, так что придется переделывать другие пункты

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

Собрался наконец завести linkedin! Всё собирался.

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

https://www.linkedin.com/in/pavel-marusich/

Смелость как качество менеджера

Помните Страшилу, Железного Дровосека и Льва? Мы как-то на работе между собой проводили опрос, какой персонаж кому ближе )

Это может быть не очевидно, но смелость - очень важное качество именно для менеджера.

Для чего нужна смелость?

➖Говорить неприятную правду, особенно другим менеджерам, владельцу компании
➖Признавать свои ошибки, в том числе публично
➖Признавать, что чего-то не знаешь
➖Менять позицию, встретив более компетентное мнение
➖Защищать людей, за которых несешь ответственность
➖Выбрасывать или менять устоявшиеся процессы или практики, которые не работают
➖Увольнять неподходящих людей
➖Действовать решительно в ситуации неопределенности
➖Просто быть честным, наконец

Я видел бесконечное количество ситуаций, когда все решили промолчать, и выбрали делать неправильно.

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

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

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

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

Аномалия в топ-менеджменте

Наблюдение: когда речь идет про коллег-специалистов, мы их воспринимаем так:
➖Если человек неприятный, мы подумаем - вот неприятный тип (мудак)
➖Если нормальный - обычный чел
➖Если приятный - значит, классный

Но эта шкала сдвигается на один, если речь про топ-менеджмент
➖Если человек неприятный - ну, обычный чел
➖Если просто нормальный - значит, классный
➖А если приятный - ну это что-то вообще уникальное

Не знаю, смешно вам или нет, но это реально у многих так работает )

Ну и не случайно. Давайте попробую привести несколько возможных объяснений.

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

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

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

И может казаться реально странным с непривычки, пока не станет понятно, что профессионализм вторичен, а первично умение понравиться тому, кто принимает решение о назначении.

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

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

Чтобы дополнить предыдущий пост, хочу открыть рубрику #рекомендации

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

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

Да и по большому счету, любому человеку стоит - потому что это может касаться и выбора партнера (в смысле мужчины/женщины), и партнера по бизнесу, и окружения. А большинство людей даже не знает, что такое "психопат", хотя и употребляют это слово. Есть канал, где отлично и кратко разобраны эти темы - канал Мурада Султанова. Содержимое, формат, манера изложения - моё почтение.

Нас в первую очередь интересуют:
➖Асоциальное расстройство личности (психопаты и социопаты)
➖Нарциссическое расстройство личности

Всё это сможете найти там на ютуб-канале.

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

https://youtu.be/smGrxDOeeK0

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

Часто в B2B SaaS компаниях команда разработки - основная статья расходов. Это подразумевает, что эффективное ее применение напрямую влияет на успешность бизнеса или его крах.

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

Что нужно команде разработки от продакта, чтобы увеличить эффективность работы если не кратно, то на десятки процентов? Не так уж много на самом деле:

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

Каждый пункт отвечает на свой критично важный для работы вопрос:
1. Что делаем?
2. Зачем и для каких целей?
3. В каком порядке и с какой интенсивностью?
4. Не устарела ли информация из п.1-3?
5. Что получилось в результате?

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

В среднем это выглядит так:
1. Что делаем - доносится частично, не четко, часто на словах и без критериев приемки. Результат эффективность утекает из-за потери информации от "испорченного телефона" и "имелось в виду другое", что вызывает переделки на поздних этапах разработки. Растет lead time, разработка становится дороже.
2. Почему мы это делаем - чаще всего никак не объясняется. Результат:
- не знаешь зачем нужна твоя работа - падает вовлеченность и мотивация
- не знаешь цель - не можешь выбрать лучшее решение из своих знаний о системе. Делаешь как сказано
В итоге падает производительность и реже выбираются оптимальные решения
3. Типовые ситуации с приоритетами - они либо вообще не используются по назначению, либо "всё срочно", что делает такую коммуникацию бесполезным шумом. Итог - путаница, стресс команды, неправильное распределение усилий для поставки ценности.
4. Груминг просто не делается. В итоге бэклог перестает соответствовать потребностям продукта и бизнеса, и усилия команды утекают на выполнение того, что уже потеряло ценность.
5. Задача после попадания в релиз улетает куда-то в небытие. Не происходит ни приемки, ни фидбека, ни освещения результатов. В итоге - падение интереса к работе, продукту, как следствие - снижение вовлеченности и мотивации что-то делать.

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

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

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

А для читателя остается загадка - то ли всё, что я написал выше - полная чепуха, то ли... почему же так происходит?

P.S. а если вы случайно оказались продактом, который это всё делает - я хочу с Вами дружить! )