Делиться "очками" и не жадничать
Раз мы гуляем по закоулкам управленческих инструментов, то надо, справедливости ради, и про что-то позитивное и хорошее. Не всё же там - сплошные темные манипуляции.
Придется зайти немного издалека. Есть такое понятие - репутация. В узком смысле - это восприятие вас другими людьми. Это призма, через которую смотрят на ваши последующие поступки.
Работает это примерно как в игре - выполняете квесты, кому-то помогаете, зарабатываете очки репутации, и открываются дополнительные опции в переговорах, новые квесты, новые персонажи для взаимодействия. Проваливаете квесты, вредите кому-то, делаете гадости или просто говорите что-то не то - она падает.
Так вот, у вас есть команда. Команда ведет какую-то деятельность и имеет достижения. Эти достижения - например, завершение важного проекта в срок, внедрение улучшений в работе и т.п. - обычно результат коллективной работы. Иногда менеджер имеет ведущую роль, иногда косвенную. Но отчетность происходит в рамках существующей иерархии.
И не знаю, является ли это для кого-то секретом, но менеджеры имеют тенденцию приписывать себе чужие достижения %) Включая достижения тех, кем они даже не руководят.
Вот у менеджера есть какие-то коммуникации с его руководителем. Скажем, в месяц есть 3-4 возможности набрать очков репутации. И вот здесь есть выбор - какую выбрать стратегию коммуникации этих ачивок? Варианты:
1. Приписать себе лично
2. Присвоить абстрактно команде (это почти аналогично п.1, просто более культурно-корректно)
3. Отнести к кому-то конкретно из своей команды
По сути выбор между собой и кем-то другим.
Так вот, в моем понимании - не надо сцать и жадничать. Во-первых, не забирать чужое. А кроме того - даже если инициатива что-то внедрить была моя и без меня этого бы 100% не было сделано, я могу, отчитываясь о ней, сделать фокус на роли в ее реализации какого-то члена команды, чтобы дать ему набрать очков, а о своей роли умолчать или перенести ее на второй план.
Почему?
Чем выше позиция, тем больше вариантов выпендриться, а выше определенного уровня наступает, как и во многом другом, diminishing effect - ситуация, при которой положительный эффект чего-либо становится всё меньше по мере того, как это используется всё больше. Грубо говоря, если у вас позиция уверенная и крепкая, нет смысла ее и дальше бесконечно укреплять.
Во-вторых, можно получить больше доверия членов своей команды, так как вы не какой-то эгоцентрист, который один на коне, когда все пешком.
В-третьих, вам могут понадобиться какие-то рычаги на переговорах о бюджете, чтобы пробивать повышения для команды. Если кто-то уже примелькался интересными ачивками в процессе работы - это сделать гораздо проще, чем если человек просто делал свое дело (такое, как ни странно, мало кому нравится).
И, наконец, не стоит недооценивать как влияет на вашу репутацию наличие ярких и известных в компании людей из вашей команды. В глазах шарящих людей это может означать, что вы хороший лидер. А если вы один блистаете, а команда в глазах остальных это безликая масса - в лучшем случае толковый администратор.
Раз мы гуляем по закоулкам управленческих инструментов, то надо, справедливости ради, и про что-то позитивное и хорошее. Не всё же там - сплошные темные манипуляции.
Придется зайти немного издалека. Есть такое понятие - репутация. В узком смысле - это восприятие вас другими людьми. Это призма, через которую смотрят на ваши последующие поступки.
Работает это примерно как в игре - выполняете квесты, кому-то помогаете, зарабатываете очки репутации, и открываются дополнительные опции в переговорах, новые квесты, новые персонажи для взаимодействия. Проваливаете квесты, вредите кому-то, делаете гадости или просто говорите что-то не то - она падает.
Так вот, у вас есть команда. Команда ведет какую-то деятельность и имеет достижения. Эти достижения - например, завершение важного проекта в срок, внедрение улучшений в работе и т.п. - обычно результат коллективной работы. Иногда менеджер имеет ведущую роль, иногда косвенную. Но отчетность происходит в рамках существующей иерархии.
И не знаю, является ли это для кого-то секретом, но менеджеры имеют тенденцию приписывать себе чужие достижения %) Включая достижения тех, кем они даже не руководят.
Вот у менеджера есть какие-то коммуникации с его руководителем. Скажем, в месяц есть 3-4 возможности набрать очков репутации. И вот здесь есть выбор - какую выбрать стратегию коммуникации этих ачивок? Варианты:
1. Приписать себе лично
2. Присвоить абстрактно команде (это почти аналогично п.1, просто более культурно-корректно)
3. Отнести к кому-то конкретно из своей команды
По сути выбор между собой и кем-то другим.
Так вот, в моем понимании - не надо сцать и жадничать. Во-первых, не забирать чужое. А кроме того - даже если инициатива что-то внедрить была моя и без меня этого бы 100% не было сделано, я могу, отчитываясь о ней, сделать фокус на роли в ее реализации какого-то члена команды, чтобы дать ему набрать очков, а о своей роли умолчать или перенести ее на второй план.
Почему?
Чем выше позиция, тем больше вариантов выпендриться, а выше определенного уровня наступает, как и во многом другом, diminishing effect - ситуация, при которой положительный эффект чего-либо становится всё меньше по мере того, как это используется всё больше. Грубо говоря, если у вас позиция уверенная и крепкая, нет смысла ее и дальше бесконечно укреплять.
Во-вторых, можно получить больше доверия членов своей команды, так как вы не какой-то эгоцентрист, который один на коне, когда все пешком.
В-третьих, вам могут понадобиться какие-то рычаги на переговорах о бюджете, чтобы пробивать повышения для команды. Если кто-то уже примелькался интересными ачивками в процессе работы - это сделать гораздо проще, чем если человек просто делал свое дело (такое, как ни странно, мало кому нравится).
И, наконец, не стоит недооценивать как влияет на вашу репутацию наличие ярких и известных в компании людей из вашей команды. В глазах шарящих людей это может означать, что вы хороший лидер. А если вы один блистаете, а команда в глазах остальных это безликая масса - в лучшем случае толковый администратор.
🔥11❤4👍2
Что мне нужно изучить, чтобы понять менеджмент в разработке?
Таким вопросом может задаться начинающий тимлид или проектный менеджер. Если мне задать такой вопрос, возможно, лаконичность ответа удивит:
1. Набор статей Селиховкина по проектному менеджменту
2. Agile манифест + пара любых приличных статей его поясняющих
3. Канбан-метод, пара видео Алексея Пименова, его поясняющих
4. Scrum-guide
Всё.
Рецепт:
1. Внимательно изучить
2. Обдумать
3. Законспектировать
Результат: у вас есть 90% самой важной информации о том, на каких основах строится организация команд разработки.
Неизбежно такой ответ вызовет сомнения, поэтому у этого поста сейчас будет вторая часть.
Таким вопросом может задаться начинающий тимлид или проектный менеджер. Если мне задать такой вопрос, возможно, лаконичность ответа удивит:
1. Набор статей Селиховкина по проектному менеджменту
2. Agile манифест + пара любых приличных статей его поясняющих
3. Канбан-метод, пара видео Алексея Пименова, его поясняющих
4. Scrum-guide
Всё.
Рецепт:
1. Внимательно изучить
2. Обдумать
3. Законспектировать
Результат: у вас есть 90% самой важной информации о том, на каких основах строится организация команд разработки.
Неизбежно такой ответ вызовет сомнения, поэтому у этого поста сейчас будет вторая часть.
🔥11❤3👍3
Как это? Почему так мало?
По сути, инфу выше можно освоить за 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, а дальше будет лотерея. Можете потренироваться, поруководив хоть где-то (клуб читателей, организация выездов на природу, команда в доте, создание стенгазеты), чтобы лучше понять природу поведения людей в коллективе.
В любом из этих случаев, вам пригодится самый краткий в мире сборник знаний по менеджменту в разработке из прошлого поста.
По сути, инфу выше можно освоить за 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, а дальше будет лотерея. Можете потренироваться, поруководив хоть где-то (клуб читателей, организация выездов на природу, команда в доте, создание стенгазеты), чтобы лучше понять природу поведения людей в коллективе.
В любом из этих случаев, вам пригодится самый краткий в мире сборник знаний по менеджменту в разработке из прошлого поста.
🔥9❤8👍3😁1🤡1
Образ будущего (эскиз)
Развивая тему из прошлого поста, я нашел для вас док, который я написал всего спустя полтора месяца работы на своей первой менеджерской позиции.
Перечитывая спустя 4,5 года, могу сказать - у меня не изменилось мнение ни по одному пункту. Всё еще база.
Вот ссылка на копию документа
Какие мысли у меня в связи с этим документом:
💭 Нужно иметь представление о том, как, в идеале, должна быть организована командная работа.
💭 Внешние обстоятельства, такие как несоответствие культуры компании или компетенций окружающих, не должны влиять на Ваше видение как "правильно". Давление обстоятельств в моменте не должно определять представления о том как надо.
💭 Достаточно понимания и осознания очень небольшого количества фундаментальных закономерностей (прошлый пост), чтобы составить компетентную картину об организации разработки.
💭 Годы опыта не меняют концепцию, если она верная. Они лишь позволяют более эффективно ее внедрять и применять.
💭 Я писал этот док, работая в компании, где почти всё было устроено не так (совпадение менее 50%). Это была чистая фантазия, опирающаяся на теорию, работу разрабом и чувство вкуса. В следующей компании, куда я пошел - было совпадение в подходе на 90%.
💭 Для меня реально удивительно, что спустя 4,5 года я бы вообще там ни слова не поменял. Не могу этого не повторить.
Можете забирать себе - это фреймворк под названием Common Sense Development )
Развивая тему из прошлого поста, я нашел для вас док, который я написал всего спустя полтора месяца работы на своей первой менеджерской позиции.
Перечитывая спустя 4,5 года, могу сказать - у меня не изменилось мнение ни по одному пункту. Всё еще база.
Вот ссылка на копию документа
Какие мысли у меня в связи с этим документом:
Можете забирать себе - это фреймворк под названием Common Sense Development )
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍6
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:
✔️кратко о себе
✔️какие ИИ инструменты используешь?
✔️несколько любимых способов использования
Сейчас я расскажу вам историю, как у меня недавно возникла идея создания закрытого клуба по использованию ИИ в разработке.
С конца 22 года я пробовал GPT. В основном просто развлекался по всякому. За последние 2,5 года пробовал разные модели и сервисы, но как-то не придавал большого значения именно практическому профессиональному использованию.
Потом в мае посмотрел видосы Антохи Гладкова про применение в продажах. Сам потыкался, кое-что потестил, пообщался с людьми. И выяснилось, что практическое применение за это время шагнуло нереально далеко вперед.
Я думаю очень многие попали в эту ловушку с мнением "клево, но до практического применения в реальной работе пока далеко".
Короче, с этого момента начался полет фантазии и мне стало гораздо интереснее.
Я провел опрос разрабов у себя в команде - кто как применяет. Выяснилось, что есть гигантское расслоение - есть кто вообще ничего не использует, а есть кто применяет на продвинутом уровне и в восторге, а есть те кому интересно, но они только начали разбираться.
Возникла мысль ускорить прогресс людей, организовать обмен опытом, внутреннюю конференцию для группы компаний. Получилось очень круто, было 60 участников, 4 спикера, классные доклады.
И по конференции еще больше стало понятно - кто-то уже обогнал других на много месяцев в своем прогрессе по знанию инструментов и способов применения.
Дальше сделал внутри команды инициативную группу по использованию ИИ в разработке - 7 человек.
Ну а потом возникла мысль, что это всё равно слишком медленно. И что можно сделать круче - такую же вещь, только не на уровне команды разработки, а на уровне всего своего нетворка.
Потому что всё очень новое и не освоенное до конца, и каждый месяц появляются новые инструменты или сценарии использования, следить за всем этим крайне сложно. Есть куча неожиданных инструментов, промтов, фишек, и не найдется ни одного человека, который может знать абсолютно всё в этой области.
А значит, общаясь с другими каждый может найти для себя что-то ценное и интересное - поделиться своими кейсами, новыми тулзами, узнать и обсудить чужие.
Ну и вот таким образом мы приходим сюда, к созданию клуба.
Что такое средняя тематическая тг-группа (если она не умерла):
➖спор ни о чем каких-то чуваков на 100+ сообщений
➖кружочки какого-нибудь полуголого мужика
➖кружочки "бля, пацаны, я сейчас бухой"
➖голосовухи с бэканьем-мэканьем
➖1-2 гиперактивных валенка (при всем уважении к валенкам) забивают весь эфир своей тупостью и мешают нормально обсуждать что-то серьезное
➖бесконечный поток мемов, стикеров, кеков
Я люблю иногда пофаниться. Но если я хочу инфы и ценности, мне нужно другое.
Уровень обсуждения неизбежно падает, интересные умные люди как правило перестают писать или читать это и уходят, уровень обсуждения падает еще ниже.
Моя идея состоит в том, чтобы создать исключительно комфортное и ценное пространство, где выше описанных проблем не существует.
Такое место, где продолжает хотеться находиться и читать что там пишут в наш век информационного овердоза.
Поэтому я выбрал формат частного клуба с закрытыми дверьми, отбором и ограниченным количеством участников.
Я хочу собрать в нем интересных и умных людей, которые умеют читать и писать. Это в наше время не тривиально )
Win-win в названии подразумевает, что каждый что-то отдает другим, но получает взамен еще больше.
Сейчас в составе 29 человек. До конца года кап, вероятно, будет 50. Это значит, что еще 20-25 человек смогут присоединиться.
Если ты разработчик/QA/менеджер и после прочтения этого текста тебе тоже стало интересно, можешь оставить заявку на участие - напиши мне (контакты в описании канала) сообщение с тэгом #win_win_AI_club:
✔️кратко о себе
✔️какие ИИ инструменты используешь?
✔️несколько любимых способов использования
🔥9👍2❤1👏1🤔1
А еще у клуба есть страничка
win-win-dev-club on Notion
Win-win Club - AI in development | Notion
Добро пожаловать в клуб. Мы располагаемся в закрытой тг-группе.
А на этой странице можно найти:
- состав участников
- последние новости
- информацию о клубе и как вступить
- ссылку на мой телеграм-канал
А на этой странице можно найти:
- состав участников
- последние новости
- информацию о клубе и как вступить
- ссылку на мой телеграм-канал
🔥5❤1👍1
Есть ли у вас план?
Я как-то упоминал здесь историю, как в одной компании тимлида забыли предупредить, что его переводят разрабом в другую команду. И в другой компании была очень похожая ситуация.
Причина - отсутствие планирования. Каким бы простым ни было организационное изменение, очень легко облажаться, если не составил план и не придерживаешься его. Люди постоянно что-то забывают, путают, упускают.
Я использую два варианта (на самом деле три, но полноценные проекты за рамками этого поста) - для простых линейных планов это нумерованный список, где я выделяю выполненные пункты плюсиком, для разветвленных планов - блок-схема.
На картинке выше - выполненная блок-схема плана по делению отдела на кросс-функциональные команды. Рисую обычно в https://app.diagrams.net/
Выполненные блоки я закрашиваю, чтобы наглядно отслеживать прогресс.
Где в этом плане можно было бы облажаться:
➖Плохо продумать состав команд
➖Не обсудить с потенциальными тимлидами их мнение по составу, которое надо учесть
➖Не обсудить индивидуально с каждым членом команды, а поставить перед фактом (особенно часто так делают)
➖Не предупредить продакта
➖Не согласовать итоговый формат команд
➖Не подготовить доску в Jira и нужные поля заранее
➖Сделать в неправильном порядке, так что придется переделывать другие пункты
И будьте уверены, большинство менеджеров облажается хоть в одном из пунктов, предпочитая делать "на глаз", и у вас есть возможность получить преимущество.
Я как-то упоминал здесь историю, как в одной компании тимлида забыли предупредить, что его переводят разрабом в другую команду. И в другой компании была очень похожая ситуация.
Причина - отсутствие планирования. Каким бы простым ни было организационное изменение, очень легко облажаться, если не составил план и не придерживаешься его. Люди постоянно что-то забывают, путают, упускают.
Я использую два варианта (на самом деле три, но полноценные проекты за рамками этого поста) - для простых линейных планов это нумерованный список, где я выделяю выполненные пункты плюсиком, для разветвленных планов - блок-схема.
На картинке выше - выполненная блок-схема плана по делению отдела на кросс-функциональные команды. Рисую обычно в https://app.diagrams.net/
Выполненные блоки я закрашиваю, чтобы наглядно отслеживать прогресс.
Где в этом плане можно было бы облажаться:
➖Плохо продумать состав команд
➖Не обсудить с потенциальными тимлидами их мнение по составу, которое надо учесть
➖Не обсудить индивидуально с каждым членом команды, а поставить перед фактом (особенно часто так делают)
➖Не предупредить продакта
➖Не согласовать итоговый формат команд
➖Не подготовить доску в Jira и нужные поля заранее
➖Сделать в неправильном порядке, так что придется переделывать другие пункты
И будьте уверены, большинство менеджеров облажается хоть в одном из пунктов, предпочитая делать "на глаз", и у вас есть возможность получить преимущество.
👍6❤4
Собрался наконец завести linkedin! Всё собирался.
И в связи с этим приглашаю единомышленников по взглядам на менеджмент и разработку - давайте задружимся ) добавьте только, пожалуйста, note с парой слов, что вы с канала, если мы не знакомы лично.
https://www.linkedin.com/in/pavel-marusich/
И в связи с этим приглашаю единомышленников по взглядам на менеджмент и разработку - давайте задружимся ) добавьте только, пожалуйста, note с парой слов, что вы с канала, если мы не знакомы лично.
https://www.linkedin.com/in/pavel-marusich/
👍6
Смелость как качество менеджера
Помните Страшилу, Железного Дровосека и Льва? Мы как-то на работе между собой проводили опрос, какой персонаж кому ближе )
Это может быть не очевидно, но смелость - очень важное качество именно для менеджера.
Для чего нужна смелость?
➖Говорить неприятную правду, особенно другим менеджерам, владельцу компании
➖Признавать свои ошибки, в том числе публично
➖Признавать, что чего-то не знаешь
➖Менять позицию, встретив более компетентное мнение
➖Защищать людей, за которых несешь ответственность
➖Выбрасывать или менять устоявшиеся процессы или практики, которые не работают
➖Увольнять неподходящих людей
➖Действовать решительно в ситуации неопределенности
➖Просто быть честным, наконец
Я видел бесконечное количество ситуаций, когда все решили промолчать, и выбрали делать неправильно.
Выступать с открытым забралом перед трудностями еще тем сложнее, чем ближе позиция к руководству компании, потому что там обычно и обитают различные интриги, борьба за власть, ресурсы и расположение руководства. Ну и, конечно, постоянно быть Дон Кихотом может быть утомительным.
Но если человек будет переступать через себя вместо того, чтобы делать то, что считает правильным - это будет медленно, но верно разрушать его собственную личность.
С другой стороны - любая компания, которая хочет быть эффективной и динамичной в изменяющихся условиях рынка, нуждается в достаточном количестве смелости в ее руководстве.
А менеджер без смелости — это администратор, который может лишь некритично передавать решения руководства и следить за их исполнением.
Помните Страшилу, Железного Дровосека и Льва? Мы как-то на работе между собой проводили опрос, какой персонаж кому ближе )
Это может быть не очевидно, но смелость - очень важное качество именно для менеджера.
Для чего нужна смелость?
➖Говорить неприятную правду, особенно другим менеджерам, владельцу компании
➖Признавать свои ошибки, в том числе публично
➖Признавать, что чего-то не знаешь
➖Менять позицию, встретив более компетентное мнение
➖Защищать людей, за которых несешь ответственность
➖Выбрасывать или менять устоявшиеся процессы или практики, которые не работают
➖Увольнять неподходящих людей
➖Действовать решительно в ситуации неопределенности
➖Просто быть честным, наконец
Я видел бесконечное количество ситуаций, когда все решили промолчать, и выбрали делать неправильно.
Выступать с открытым забралом перед трудностями еще тем сложнее, чем ближе позиция к руководству компании, потому что там обычно и обитают различные интриги, борьба за власть, ресурсы и расположение руководства. Ну и, конечно, постоянно быть Дон Кихотом может быть утомительным.
Но если человек будет переступать через себя вместо того, чтобы делать то, что считает правильным - это будет медленно, но верно разрушать его собственную личность.
С другой стороны - любая компания, которая хочет быть эффективной и динамичной в изменяющихся условиях рынка, нуждается в достаточном количестве смелости в ее руководстве.
А менеджер без смелости — это администратор, который может лишь некритично передавать решения руководства и следить за их исполнением.
❤🔥7🔥4❤3👍2
Аномалия в топ-менеджменте
Наблюдение: когда речь идет про коллег-специалистов, мы их воспринимаем так:
➖Если человек неприятный, мы подумаем - вот неприятный тип (мудак)
➖Если нормальный - обычный чел
➖Если приятный - значит, классный
Но эта шкала сдвигается на один, если речь про топ-менеджмент
➖Если человек неприятный - ну, обычный чел
➖Если просто нормальный - значит, классный
➖А если приятный - ну это что-то вообще уникальное
Не знаю, смешно вам или нет, но это реально у многих так работает )
Ну и не случайно. Давайте попробую привести несколько возможных объяснений.
Во-первых, среди различных топ-менеджеров в несколько раз больше, чем в среднем по популяции, людей с "плохими" расстройствами личности (если по простому - это те, кто вредят в основном не себе, а окружающим). Психопаты, люди с нарциссическим расстройством, социопаты и так далее - если вы зарядите глубокий поиск в ChatGPT, он вам накидает исследований, статей и статистики. У таких людей, соответственно, снижена эмпатия.
Во-вторых, это связано с тем, что на высоких позициях люди начинают вести себя более непосредственно - то есть более свободно проявлять свои истинные качества. На рядовых позициях люди чаще склонны вести себя более скрытно и сдержанно, и когда говорят, что кого-то "испортила власть" - по сути, человек просто в меньшей степени перестал скрываться.
В-третьих, если мы говорим не про предпринимателей, а про наемных топов, стоит задуматься - а какова механика, с помощью которой двигаются наверх по корпоративной иерархии? Кто-то может подумать, что это профессионализм - кто круче выполняет свои функции, того двигают наверх. Но среди топов можно выстретить как крутейших профи, так и полных долбаков, которые вообще ничего не умеют.
И может казаться реально странным с непривычки, пока не станет понятно, что профессионализм вторичен, а первично умение понравиться тому, кто принимает решение о назначении.
То есть вы можете запросто встретить полнейшего кретина, который с вашей точки зрения творит совершенную дичь (или просто ничего не делает толкового), но практически абсолютно исключено, что вы встретите человека, которого другой топ нанял вопреки личной неприязни. А вот если понравился - то наймет.
Потому что профессионализм еще надо уметь оценить, и на это часто нужно время, а вот если человек гладко стелет - это влияет сразу.
Наблюдение: когда речь идет про коллег-специалистов, мы их воспринимаем так:
➖Если человек неприятный, мы подумаем - вот неприятный тип (мудак)
➖Если нормальный - обычный чел
➖Если приятный - значит, классный
Но эта шкала сдвигается на один, если речь про топ-менеджмент
➖Если человек неприятный - ну, обычный чел
➖Если просто нормальный - значит, классный
➖А если приятный - ну это что-то вообще уникальное
Не знаю, смешно вам или нет, но это реально у многих так работает )
Ну и не случайно. Давайте попробую привести несколько возможных объяснений.
Во-первых, среди различных топ-менеджеров в несколько раз больше, чем в среднем по популяции, людей с "плохими" расстройствами личности (если по простому - это те, кто вредят в основном не себе, а окружающим). Психопаты, люди с нарциссическим расстройством, социопаты и так далее - если вы зарядите глубокий поиск в ChatGPT, он вам накидает исследований, статей и статистики. У таких людей, соответственно, снижена эмпатия.
Во-вторых, это связано с тем, что на высоких позициях люди начинают вести себя более непосредственно - то есть более свободно проявлять свои истинные качества. На рядовых позициях люди чаще склонны вести себя более скрытно и сдержанно, и когда говорят, что кого-то "испортила власть" - по сути, человек просто в меньшей степени перестал скрываться.
В-третьих, если мы говорим не про предпринимателей, а про наемных топов, стоит задуматься - а какова механика, с помощью которой двигаются наверх по корпоративной иерархии? Кто-то может подумать, что это профессионализм - кто круче выполняет свои функции, того двигают наверх. Но среди топов можно выстретить как крутейших профи, так и полных долбаков, которые вообще ничего не умеют.
И может казаться реально странным с непривычки, пока не станет понятно, что профессионализм вторичен, а первично умение понравиться тому, кто принимает решение о назначении.
То есть вы можете запросто встретить полнейшего кретина, который с вашей точки зрения творит совершенную дичь (или просто ничего не делает толкового), но практически абсолютно исключено, что вы встретите человека, которого другой топ нанял вопреки личной неприязни. А вот если понравился - то наймет.
Потому что профессионализм еще надо уметь оценить, и на это часто нужно время, а вот если человек гладко стелет - это влияет сразу.
👍12🔥5❤4
Чтобы дополнить предыдущий пост, хочу открыть рубрику #рекомендации
В основном я здесь выдаю какую-то концентрированную выжимку из своего опыта, но в пост все равно очень много не вложишь, а вот если сослаться на какой-то топового качества ресурс, из которого я сам черпал знания - тут концентрация ценности может быть намного выше.
Ну так вот, я прошлом посте я упоминал различные расстройства личности, которые часто встречаются среди руководства компаний. На самом деле, если Вы сами менеджер, то Вам точно стоит в этом хотя бы базово разбираться.
Да и по большому счету, любому человеку стоит - потому что это может касаться и выбора партнера (в смысле мужчины/женщины), и партнера по бизнесу, и окружения. А большинство людей даже не знает, что такое "психопат", хотя и употребляют это слово. Есть канал, где отлично и кратко разобраны эти темы - канал Мурада Султанова. Содержимое, формат, манера изложения - моё почтение.
Нас в первую очередь интересуют:
➖Асоциальное расстройство личности (психопаты и социопаты)
➖Нарциссическое расстройство личности
Всё это сможете найти там на ютуб-канале.
Если будете хотя бы минимально подготовлены по этим темам, у вас будет шанс избежать серьезных проблем в профессиональной и личной жизни.
https://youtu.be/smGrxDOeeK0
В основном я здесь выдаю какую-то концентрированную выжимку из своего опыта, но в пост все равно очень много не вложишь, а вот если сослаться на какой-то топового качества ресурс, из которого я сам черпал знания - тут концентрация ценности может быть намного выше.
Ну так вот, я прошлом посте я упоминал различные расстройства личности, которые часто встречаются среди руководства компаний. На самом деле, если Вы сами менеджер, то Вам точно стоит в этом хотя бы базово разбираться.
Да и по большому счету, любому человеку стоит - потому что это может касаться и выбора партнера (в смысле мужчины/женщины), и партнера по бизнесу, и окружения. А большинство людей даже не знает, что такое "психопат", хотя и употребляют это слово. Есть канал, где отлично и кратко разобраны эти темы - канал Мурада Султанова. Содержимое, формат, манера изложения - моё почтение.
Нас в первую очередь интересуют:
➖Асоциальное расстройство личности (психопаты и социопаты)
➖Нарциссическое расстройство личности
Всё это сможете найти там на ютуб-канале.
Если будете хотя бы минимально подготовлены по этим темам, у вас будет шанс избежать серьезных проблем в профессиональной и личной жизни.
https://youtu.be/smGrxDOeeK0
YouTube
ПСИХОПАТЫ и СОЦИОПАТЫ (1) чем отличаются два подтипа асоциального расстройства личности
Подписывайтесь на канал https://www.youtube.com/channel/UCE8bKtnV6h9gCqSWsTQ0h6g?sub_confirmation=1
2:27 Социопат или психопат – наглядная разница - персонажи из Место встречи изменить нельзя
3:37 Основные признаки асоциального расстройства личности
8:13…
2:27 Социопат или психопат – наглядная разница - персонажи из Место встречи изменить нельзя
3:37 Основные признаки асоциального расстройства личности
8:13…
❤6🔥3👍2
Как продакт может увеличить эффективность разработки на десятки процентов?
Часто в 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. а если вы случайно оказались продактом, который это всё делает - я хочу с Вами дружить! )
Часто в 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. а если вы случайно оказались продактом, который это всё делает - я хочу с Вами дружить! )
❤6👍4
Внедрение инноваций в команде/организации на примере
Каким бы ни было существенное изменение в работе, которое вы хотите внедрить, даже если оно будет очевидно прогрессивным и полезным, коллектив почти всегда разделится примерно на три группы по отношению к этому изменению:
1️⃣ Энтузиасты и радикалы, открытые к изменениям и улучшениям, либо прямо инициирующие их
2️⃣ Консерваторы, сопротивляющиеся изменениям (пассивно или активно - "я привык так делать и буду так делать дальше")
3️⃣ Нейтралы, которые не будут проявлять активность в ту или иную сторону, но могут присоединиться со временем к той позиции, которая доминирует
Это неискоренимо в силу природы людей, которые дифференцируются по радикализму/консерватизму, конформизму/нонконформизму, и ряду других признаков.
Это означает, что есть универсальные методы внедрения инноваций в коллективе. Хочу поделиться несколькими закономерностями из своего опыта, а потом добавить конкретный пример из последнего.
Допустим, речь об изменениях, которые требуют адаптации и больших усилий, растянутых во времени. Не то, что можно поменять 1 днем.
➖Вам никогда не нужно пытаться раскатывать изменения сразу на всех. Обратите внимание на группу энтузиастов, которые примут участие исходя из внутреннего интереса, начните с формирования из них передовой/экспериментальной группы. Это может быть одно подразделение в отделе или виртуальная группа людей из разных команд (гильдия).
➖Проводите пиар изменений, как внутри команды, так и за ее пределами (другие отделы, руководство компании). Это поднимает привлекательность изменений и репутацию команды.
➖Позаботьтесь о финансовой стороне вопроса, если речь про изменения, которые требуют существенных усилий от участников. Повышения, "плюсы" на перформанс ревью, премии, бюджет на инструменты или на то, чтобы отпраздновать успехи - в зависимости от того, что вам доступно.
➖При этом избегайте транзакционных отношений на начальном этапе ("ты мне, я тебе"). Берите на первом этапе на борт только тех, кого интересуют сами изменения как таковые. Если наберете людей, которым не интересен сам процесс - рискуете завалить всё дело.
И конкретный пример про внедрение AI инструментов в разработке:
1️⃣ Собираем инфу кто пользуется ИИ в команде, узнаем минимальные детали
(идентифицируем энтузиастов, консерваторов и нейтралов)
2️⃣ Организуем встречу по обмену опытом, где несколько спикеров делятся своим опытом использования ИИ в разработке (не обязательно быть крутым)
(продолжаем анализ кто есть кто + начинаем пиар)
3️⃣ Анализируем результаты 1 и 2, собираем группу энтузиастов использования ИИ в разработке, которые хотят быть на передовой
4️⃣ Согласуем бюджет на подписки на ИИ инструменты для этой группы
5️⃣ Ставим задачу активно использовать, делиться в группе опытом, инсайтами, собирать примеры использования
6️⃣ Ждем накопления опыта
(за это время какая-то часть нейтрально настроенных людей будет присоединяться к инициативе самостоятельно)
7️⃣ Анализируем и презентуем результат (внутри команды, в компании)
8️⃣ Распространяем успешное использование на остальную команду
Каким бы ни было существенное изменение в работе, которое вы хотите внедрить, даже если оно будет очевидно прогрессивным и полезным, коллектив почти всегда разделится примерно на три группы по отношению к этому изменению:
Это неискоренимо в силу природы людей, которые дифференцируются по радикализму/консерватизму, конформизму/нонконформизму, и ряду других признаков.
Это означает, что есть универсальные методы внедрения инноваций в коллективе. Хочу поделиться несколькими закономерностями из своего опыта, а потом добавить конкретный пример из последнего.
Допустим, речь об изменениях, которые требуют адаптации и больших усилий, растянутых во времени. Не то, что можно поменять 1 днем.
➖Вам никогда не нужно пытаться раскатывать изменения сразу на всех. Обратите внимание на группу энтузиастов, которые примут участие исходя из внутреннего интереса, начните с формирования из них передовой/экспериментальной группы. Это может быть одно подразделение в отделе или виртуальная группа людей из разных команд (гильдия).
➖Проводите пиар изменений, как внутри команды, так и за ее пределами (другие отделы, руководство компании). Это поднимает привлекательность изменений и репутацию команды.
➖Позаботьтесь о финансовой стороне вопроса, если речь про изменения, которые требуют существенных усилий от участников. Повышения, "плюсы" на перформанс ревью, премии, бюджет на инструменты или на то, чтобы отпраздновать успехи - в зависимости от того, что вам доступно.
➖При этом избегайте транзакционных отношений на начальном этапе ("ты мне, я тебе"). Берите на первом этапе на борт только тех, кого интересуют сами изменения как таковые. Если наберете людей, которым не интересен сам процесс - рискуете завалить всё дело.
И конкретный пример про внедрение AI инструментов в разработке:
(идентифицируем энтузиастов, консерваторов и нейтралов)
(продолжаем анализ кто есть кто + начинаем пиар)
(за это время какая-то часть нейтрально настроенных людей будет присоединяться к инициативе самостоятельно)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍6❤2
Что такое "хороший менеджер"?
Готовился тут писать один из следующих постов с названием "Нельзя стать хорошим менеджером, учась на своих ошибках", и логично встал вопрос пояснения термина "хороший менеджер".
Давайте расскажу, как я это понимаю, основываясь на личном опыте. И то, как лично я оцениваю себя и других.
При этом я не буду писать всякие первичные свойства, типа интеллекта, особенностей характера, харизмы и т.п., а только наблюдаемые проявления.
Без вариантов должное:
1️⃣ Умение соблюдать договоренности. Держать слово, или, в просторечии, "отвечать за базар".
2️⃣ Отсутствие гибрис-синдрома. Проще говоря, серьезных проблем с эго, связанных с наличием руководящей позиции. Жажда власти, обидчивость, высокомерие, чрезмерная щепетильность по поводу своего "авторитета" - всё сюда.
3️⃣ Win-win майндсет. Менеджер находится (мы тут говорим о наемнике) между предпринимателем или другим менеджером и своей командой. Этот пункт означает, что он действует, балансируя интересы обеих сторон, не выбирая явным образом одну в ущерб другой.
4️⃣ Отсутствие, что называется, проявлений insecurity (неуверенность, уязвимость, ощущение собственной недостаточности). Если не смелость, то по крайней мере отсутствие подавляющих страхов, чтобы отстоять то, что считаешь правильным.
(примечание: повторюсь, я пишу про наблюдаемые проявления. Внутри человек может чувствовать себя как угодно, но если он может со своими комплексами справиться и не проявлять их с коллегами - это ок)
5️⃣ Самокритичность. Способность сомневаться, выслушивать альтернативные мнения, признавать свои ошибки публично.
6️⃣ Кооперативность. Способность не вести себя как территориальное животное или герой Игры Престолов/Борджиа, а сотрудничать с другими менеджерами для достижения общих целей.
7️⃣ Здравый смысл. Наиболее сложно формализуемая характеристика, но почти все, кто имеют дело с менеджерами, часто видят, что это огромное преимущество, и это полный ахтунг, когда этого нет. Можно назвать по другому - способность принимать рациональные взвешенные решения.
8️⃣ Профессионализм. Понимание (теория, предпосылки, ситуация), применение (принятие решений и организация работы) и способность объяснить (свои решения, явления и т.п.).
Есть еще много важных свойств, без которых, тем не менее, могу представить хорошего менеджера, например получение удовольствия от своей работы, честность/открытость, справедливость и другие. Стратегическое мышление или умение воодушевлять людей, которые обычно не совмещаются в одном человеке.
Много ли людей, которые укладываются в эти критерии? На мой взгляд, не очень. Но все, кто укладывались - очень запоминающиеся личности и очень многим вокруг было очевидно, что это выдающиеся менеджеры.
Готовился тут писать один из следующих постов с названием "Нельзя стать хорошим менеджером, учась на своих ошибках", и логично встал вопрос пояснения термина "хороший менеджер".
Давайте расскажу, как я это понимаю, основываясь на личном опыте. И то, как лично я оцениваю себя и других.
При этом я не буду писать всякие первичные свойства, типа интеллекта, особенностей характера, харизмы и т.п., а только наблюдаемые проявления.
Без вариантов должное:
(примечание: повторюсь, я пишу про наблюдаемые проявления. Внутри человек может чувствовать себя как угодно, но если он может со своими комплексами справиться и не проявлять их с коллегами - это ок)
Есть еще много важных свойств, без которых, тем не менее, могу представить хорошего менеджера, например получение удовольствия от своей работы, честность/открытость, справедливость и другие. Стратегическое мышление или умение воодушевлять людей, которые обычно не совмещаются в одном человеке.
Много ли людей, которые укладываются в эти критерии? На мой взгляд, не очень. Но все, кто укладывались - очень запоминающиеся личности и очень многим вокруг было очевидно, что это выдающиеся менеджеры.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍7❤3
Закон вытеснения инициативы формализацией
Думаю, мы достаточно познакомились и размялись, чтобы иногда переходить к более глубокой и неочевидной теории)
И первая из сложных неочевидных механик - то, как формализация и правила влияют на общий результат работы.
Какое у людей обычно базовое, интуитивное представление:
➖Должны быть четко определены роли и прописаны зоны ответственности
➖Процессы должны быть понятно прописаны
➖Лучше больше ясности, чтобы понятно было кому и что делать
И в некоторых, особенно запущенных случаях:
➖Менеджеры должны описать, что нужно делать, а остальные должны делать это
Мы к этому еще сейчас вернемся, но сначала я сформулирую закон:
📖 "Для выбранной деятельности и команды существует такой минимальный набор правил, после которого добавление правила снижает полезный результат работы"
Или упрощенная версия: "делая X обязанностью, ты можешь потерять 2X от результата".
Очень простой и многим понятный пример:
➖В компании свободный график - когда хочешь приходишь, когда хочешь уходишь. При этом иногда надо сделать релиз утром или "потушить пожар" вечером/на выходных. Всем ок, люди по своей инициативе закрывают много вопросов.
➖Очередной менеджер приходит и решает вводить правила по поводу рабочего времени, например, что оно должно быть фиксированным.
➖Результат: когда кончается окно рабочего времени, все дружно отключаются и недоступны в случае каких-то проблем. В итоге все в минусе.
➖Другой пример, более сложный - с формализацией ролей и зон ответственности. Напомню ключевую механику - люди разные. У одного что-то одно хорошо получается, а другое совсем плохо. Эффективная команда строится вокруг сильных сторон составляющих ее личностей, а не вокруг погони за устранением слабостей.
➖Формализуя универсальную роль с точным перечнем навыков и выполняемых функций (например, middle backend developer), вы почти всегда получите "прокрустово ложе" - одни не будут в него вписываться, другие будут до него недотягивать.
Потом смотришь на такие описания и спрашиваешь: "это реально используется в работе?" - нет.
❗️Важно еще понимать, что наличие неработающих правил - это не ноль, это минус. Это:
1. Ухудшает отношение к нормальным правилам
2. Тратит время
3. Раздражает людей
И третий пример:
➖Есть команда, в ней 8 человек. 6 хорошо работают и имеют внутреннюю мотивацию. 1 работает нормально, но слишком часто оставшись без внимания впадает в прокрастинацию. И еще 1 работает отвратительно и ищет все возможности минимизировать продуктивность, то есть работает только, что называется, "из-под палки".
➖Есть менеджер, который делает типичный вывод, что нужен контроль, чтобы решить эту проблему. И он вводит правило - теперь каждый день делаем дейлики, где все отчитываются о том, что сделали за день и планируют делать завтра.
➖Результат: 6 человек, у которых все было норм, нагружены ненужным ритуалом. Седьмой вынужден периодически придумывать, что он "сделал", пока прокрастинировал, так как очень сложно сказать честно что не смог работать вчера. Он еще больше замыкается в себе от этой лжи. Восьмого же это совершенно не смущает и он легко выдумывает варианты типа "разбирался" или "продолжал заниматься задачей". Итог: все в минусе.
Тема на самом деле потянула бы минимум на часовую беседу, но если краткий вывод сделать, какие можно из этого выделить ориентиры:
✅ Думая о введении правила, думать не только о целях, но и минусах его введения.
✅ Периодически надо задумываться о том, чтобы отменять имеющиеся правила. Ставить под сомнение их целесообразность и эффективность.
✅ Важно разбираться в психологии того, как формируется инициатива на местах, и как обязательства ее снижают
✅ Если вы хотите от кого-то инициативы, вы должны его меньше контролировать или вообще не контролировать
✅ Не используйте правила как инструмент формирования результата. Вместо этого рассказывайте коллегам о целях и ожиданиях от результата их работы
✅ Вы не сделаете универсальную систему, в которой понравится вместе работать и людям со внутренней мотивацией, и тем, кому нужен "начальник" с палкой над душой
Думаю, мы достаточно познакомились и размялись, чтобы иногда переходить к более глубокой и неочевидной теории)
И первая из сложных неочевидных механик - то, как формализация и правила влияют на общий результат работы.
Какое у людей обычно базовое, интуитивное представление:
➖Должны быть четко определены роли и прописаны зоны ответственности
➖Процессы должны быть понятно прописаны
➖Лучше больше ясности, чтобы понятно было кому и что делать
И в некоторых, особенно запущенных случаях:
➖Менеджеры должны описать, что нужно делать, а остальные должны делать это
Мы к этому еще сейчас вернемся, но сначала я сформулирую закон:
📖 "Для выбранной деятельности и команды существует такой минимальный набор правил, после которого добавление правила снижает полезный результат работы"
Или упрощенная версия: "делая X обязанностью, ты можешь потерять 2X от результата".
Очень простой и многим понятный пример:
➖В компании свободный график - когда хочешь приходишь, когда хочешь уходишь. При этом иногда надо сделать релиз утром или "потушить пожар" вечером/на выходных. Всем ок, люди по своей инициативе закрывают много вопросов.
➖Очередной менеджер приходит и решает вводить правила по поводу рабочего времени, например, что оно должно быть фиксированным.
➖Результат: когда кончается окно рабочего времени, все дружно отключаются и недоступны в случае каких-то проблем. В итоге все в минусе.
➖Другой пример, более сложный - с формализацией ролей и зон ответственности. Напомню ключевую механику - люди разные. У одного что-то одно хорошо получается, а другое совсем плохо. Эффективная команда строится вокруг сильных сторон составляющих ее личностей, а не вокруг погони за устранением слабостей.
➖Формализуя универсальную роль с точным перечнем навыков и выполняемых функций (например, middle backend developer), вы почти всегда получите "прокрустово ложе" - одни не будут в него вписываться, другие будут до него недотягивать.
Потом смотришь на такие описания и спрашиваешь: "это реально используется в работе?" - нет.
❗️Важно еще понимать, что наличие неработающих правил - это не ноль, это минус. Это:
1. Ухудшает отношение к нормальным правилам
2. Тратит время
3. Раздражает людей
И третий пример:
➖Есть команда, в ней 8 человек. 6 хорошо работают и имеют внутреннюю мотивацию. 1 работает нормально, но слишком часто оставшись без внимания впадает в прокрастинацию. И еще 1 работает отвратительно и ищет все возможности минимизировать продуктивность, то есть работает только, что называется, "из-под палки".
➖Есть менеджер, который делает типичный вывод, что нужен контроль, чтобы решить эту проблему. И он вводит правило - теперь каждый день делаем дейлики, где все отчитываются о том, что сделали за день и планируют делать завтра.
➖Результат: 6 человек, у которых все было норм, нагружены ненужным ритуалом. Седьмой вынужден периодически придумывать, что он "сделал", пока прокрастинировал, так как очень сложно сказать честно что не смог работать вчера. Он еще больше замыкается в себе от этой лжи. Восьмого же это совершенно не смущает и он легко выдумывает варианты типа "разбирался" или "продолжал заниматься задачей". Итог: все в минусе.
Тема на самом деле потянула бы минимум на часовую беседу, но если краткий вывод сделать, какие можно из этого выделить ориентиры:
✅ Думая о введении правила, думать не только о целях, но и минусах его введения.
✅ Периодически надо задумываться о том, чтобы отменять имеющиеся правила. Ставить под сомнение их целесообразность и эффективность.
✅ Важно разбираться в психологии того, как формируется инициатива на местах, и как обязательства ее снижают
✅ Если вы хотите от кого-то инициативы, вы должны его меньше контролировать или вообще не контролировать
✅ Не используйте правила как инструмент формирования результата. Вместо этого рассказывайте коллегам о целях и ожиданиях от результата их работы
✅ Вы не сделаете универсальную систему, в которой понравится вместе работать и людям со внутренней мотивацией, и тем, кому нужен "начальник" с палкой над душой
👍9❤2
"Что такое плохо" на примере историй из жизни
Иногда можно лучше понять, что такое "хорошо", узнав, что такое "плохо".
Я расскажу несколько из запомнившихся мне историй.
Всего будет 8 историй, я их расскажу в порядке от довольно безобидных до критичных.
Ну и, наверно, стоит добавить, что по 1 ситуации (кроме самых долбанутых) не стоит делать совсем уж поспешные выводы целиком о человеке )
1️⃣ Итак, первая история - "Плюрализм споткнулся о размер столов".
Руководитель департамента разработки решил проявить плюрализм и вынести на обсуждение команды новый дизайн офиса. Сложно сказать, на что он рассчитывал, но пошел довольно серьезный и увлеченный разбор полетов с критикой, в особенности критика пришлась на слишком маленький размер столов. В итоге начался, что называется, срач.
Итог - руководитель департамента рассердился/обиделся, сказал, что больше не будет мнение команды спрашивать )
Мораль:
➖Нужно заранее думать о хороших и плохих сценариях развития событий. Если не уверен - вообще не начинай
➖Нужно уметь воспринимать критику, быть к ней готовым
➖Можно что-то почитать про фасилитацию обсуждений, как это правильно делается
➖Не надо обижаться ) это смешно и глупо
2️⃣ "Ну это, конечно, неправда".
В компанию приходит новый технический директор. Создает образ демократичного человека, который открыто общается с сотрудниками, интересуется их мнением.
И вот, обсуждается какой-то серьезный вопрос на тему как правильно организовать работу с тимлидом одной из команд разработки и разработчиком (это я).
Техдир задает вопрос, получает очень обстоятельный и глубокий ответ (разрабы с таким настроением - вот наконец-то есть кому рассказать о реальных проблемах, и с этим челом мы их устраним).
Ответ техдира - цитата - "ну, это, конечно, неправда", и как ни в чем ни бывало продолжает разговор.
Мы выпали ) Всё, с этого момента, можно сказать, что интерес к его персоне и доверие падает практически до нуля )
Мораль:
➖Надо уважительно общаться с коллегами
➖Свои комплексы надо держать при себе
➖Если даже вы кому-то не доверяете - особенно если это только начало общения и по сути знакомство - не надо "ляпать языком" всякую чушь
3️⃣ "Ты подрываешь мой авторитет"
Начинающий тимлид ведет дейлик. Отчитывается разработчик, затрагивается какая-то фича. Тимлид поясняет разрабу как она работает. Другой разработчик (это был я) высказывается, что работает по другому. Тимлид настаивает на своей версии, и получает ответ - "да нет, я вот только сегодня смотрел это". Дискуссия на этом заканчивается. Но не история )
После дейлика тимлид подходит ко мне и начинает раздраженно докапываться по какому-то другому рабочему вопросу. Раньше такого не было (да и вообще у нас дружеские отношения), поэтому сразу становится понятно, что дело не в этом вопросе. Я предлагаю сходить на обед пообщаться.
Через 10 минут посторонних разговоров тимлида прорывает, и он наконец сообщает, что я подрываю его авторитет и что я не должен оспаривать его решения. Мой ответ "это обычный рабочий вопрос, конечно нужно просто спокойно обсуждать лучшее решение и всё" - его не устраивает, разговор накаляется, доходит практически до ссоры.
Мораль:
➖Нужно внимательно следить за своим эго, своими комплексами, особенно это касается новичков, которые впервые стали руководителями
➖Не нужно путать критику идей, выборов и решений с критикой личности. Публичное обсуждение решений - норм, личности - плохо
➖Если вам что-то сильно не нравится - нужно набраться смелости, предложить встречу 1-1 и высказать это
Иногда можно лучше понять, что такое "хорошо", узнав, что такое "плохо".
Я расскажу несколько из запомнившихся мне историй.
Всего будет 8 историй, я их расскажу в порядке от довольно безобидных до критичных.
Ну и, наверно, стоит добавить, что по 1 ситуации (кроме самых долбанутых) не стоит делать совсем уж поспешные выводы целиком о человеке )
Руководитель департамента разработки решил проявить плюрализм и вынести на обсуждение команды новый дизайн офиса. Сложно сказать, на что он рассчитывал, но пошел довольно серьезный и увлеченный разбор полетов с критикой, в особенности критика пришлась на слишком маленький размер столов. В итоге начался, что называется, срач.
Итог - руководитель департамента рассердился/обиделся, сказал, что больше не будет мнение команды спрашивать )
Мораль:
➖Нужно заранее думать о хороших и плохих сценариях развития событий. Если не уверен - вообще не начинай
➖Нужно уметь воспринимать критику, быть к ней готовым
➖Можно что-то почитать про фасилитацию обсуждений, как это правильно делается
➖Не надо обижаться ) это смешно и глупо
В компанию приходит новый технический директор. Создает образ демократичного человека, который открыто общается с сотрудниками, интересуется их мнением.
И вот, обсуждается какой-то серьезный вопрос на тему как правильно организовать работу с тимлидом одной из команд разработки и разработчиком (это я).
Техдир задает вопрос, получает очень обстоятельный и глубокий ответ (разрабы с таким настроением - вот наконец-то есть кому рассказать о реальных проблемах, и с этим челом мы их устраним).
Ответ техдира - цитата - "ну, это, конечно, неправда", и как ни в чем ни бывало продолжает разговор.
Мы выпали ) Всё, с этого момента, можно сказать, что интерес к его персоне и доверие падает практически до нуля )
Мораль:
➖Надо уважительно общаться с коллегами
➖Свои комплексы надо держать при себе
➖Если даже вы кому-то не доверяете - особенно если это только начало общения и по сути знакомство - не надо "ляпать языком" всякую чушь
Начинающий тимлид ведет дейлик. Отчитывается разработчик, затрагивается какая-то фича. Тимлид поясняет разрабу как она работает. Другой разработчик (это был я) высказывается, что работает по другому. Тимлид настаивает на своей версии, и получает ответ - "да нет, я вот только сегодня смотрел это". Дискуссия на этом заканчивается. Но не история )
После дейлика тимлид подходит ко мне и начинает раздраженно докапываться по какому-то другому рабочему вопросу. Раньше такого не было (да и вообще у нас дружеские отношения), поэтому сразу становится понятно, что дело не в этом вопросе. Я предлагаю сходить на обед пообщаться.
Через 10 минут посторонних разговоров тимлида прорывает, и он наконец сообщает, что я подрываю его авторитет и что я не должен оспаривать его решения. Мой ответ "это обычный рабочий вопрос, конечно нужно просто спокойно обсуждать лучшее решение и всё" - его не устраивает, разговор накаляется, доходит практически до ссоры.
Мораль:
➖Нужно внимательно следить за своим эго, своими комплексами, особенно это касается новичков, которые впервые стали руководителями
➖Не нужно путать критику идей, выборов и решений с критикой личности. Публичное обсуждение решений - норм, личности - плохо
➖Если вам что-то сильно не нравится - нужно набраться смелости, предложить встречу 1-1 и высказать это
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥5❤3
Продолжение прошлого поста, истории про "что такое плохо"
4️⃣ "В Ставрополе за эти деньги..."
Еще давно, на первой работе я был стажером в аутсорсинговой разработке. Там классно был организован конвейер по отбору, обучению и онбордингу высококлассных стажеров. Но после окончания стажировки люди переходили на сдельную зарплату и перспективы были довольно плачевные. Все стажеры в "курилке" обсуждали свои сомнительные перспективы в компании, когда они перейдут из стажеров в специалисты. Некоторые даже специально оттягивали этот момент, хотя зарплата стажера была больше похожа на стипендию.
И вот, встреча с руководством компании, где можно открыто поговорить и задать вопросы. Я освещаю выше описанную ситуацию и предложение пересмотреть условия, на которых люди начинают работать как специалисты, гендиректор триггерится на фразу про стипендию, со словами "да в в Ставрополе люди за эти деньги" рады работать и так далее. Всё, далее уже никакие рациональные аргументы не имеют смысла. Больше я в этой компании руководству ничего не предлагал. Пара человек при мне ушли на х2 зп в другие компании. Потом и я ушел.
Это очень частая ситуация, когда человек воспринимает ситуацию, требующую менеджерского решения, не рационально, а эмоционально, причем эмоции часто основаны на воспринимаемом близко к сердцу личном (опыте или переживании).
Мораль:
➖Решая ситуацию как менеджер, нельзя полагаться на эмоции, на свою личную жизнь и опыт, прошлую карьеру. Только на объективный анализ текущей ситуации
➖"Мне/кому-то было тяжело, теперь вам должно быть тяжело" - это токсичная, неэффективная, а потому еще и глупая установка
5️⃣ "Как правильно или как лучше?"
В этой истории я уже достаточно опытный разработчик с навыками аналитика, решающий весь цикл задачи от общения с пользователем до реализации и тестирования. Наша команда занимается разработкой биллинга и различных внутренних продуктов, которыми пользуется бухгалтерия и т.п.
Возникает типовая задача - из-за рассинхрона финансовых данных между разными сервисами нужен какой-то механизм сверок. Есть несколько частей системы, за каждую отвечают разные отделы. И вот есть заказчик - главный бухгалтер, и есть менеджер, принимающий решение - директор по разработке.
У нас возникли разногласия - я предлагал сделать сверку на стороне моей команды, потому что тогда это будет сделано быстро и качественно. Директор предлагал сделать в на стороне команды, которая отвечает за данные (DWH), потому что это "правильно", и по правильному сверки должны быть на их стороне. Технически сделать можно было и так и так - в обеих системах были все возможности.
В общем мы немного поспорили, потому что я понимал, что если это отдать им - это либо вообще не будет сделано, либо будет сделано через несколько месяцев против наших 1-2 недель. Но Head of Dev твердо остался на своем.
Это типичный выбор между "как правильно" (теоретически) и "как лучше" (в реальности). И это довольно типичная ошибка людей с майндсетом разработчика.
Я на тот момент еще достаточно горячо, скажем так, воспринимал такие ситуации, поэтому на этом я не остановился, и решил слегка поинтриговать, чтобы было таки выбрано мое решение. Я отдельно встретился и обсудил ситуацию с заказчиком (главным бухгалтером) и описал просто - "либо мы делаем как хочет Стас, либо это будет нормально и быстро сделано". Она всё поняла, не знаю что там было сделано за кулисами, но через пару дней нам отдали эту задачу )
Мораль:
➖Реальные условия на земле всегда важнее "теоретически правильного" решения
➖При оценке ситуации надо учитывать качество и надежность кадров, а не только технологии и организационную структуру
➖Порой можно добиться своего решения, даже если ты разработчик, а оппонент - директор по разработке. Если уметь и хотеть. Другой вопрос - нужно ли вам это?
Еще давно, на первой работе я был стажером в аутсорсинговой разработке. Там классно был организован конвейер по отбору, обучению и онбордингу высококлассных стажеров. Но после окончания стажировки люди переходили на сдельную зарплату и перспективы были довольно плачевные. Все стажеры в "курилке" обсуждали свои сомнительные перспективы в компании, когда они перейдут из стажеров в специалисты. Некоторые даже специально оттягивали этот момент, хотя зарплата стажера была больше похожа на стипендию.
И вот, встреча с руководством компании, где можно открыто поговорить и задать вопросы. Я освещаю выше описанную ситуацию и предложение пересмотреть условия, на которых люди начинают работать как специалисты, гендиректор триггерится на фразу про стипендию, со словами "да в в Ставрополе люди за эти деньги" рады работать и так далее. Всё, далее уже никакие рациональные аргументы не имеют смысла. Больше я в этой компании руководству ничего не предлагал. Пара человек при мне ушли на х2 зп в другие компании. Потом и я ушел.
Это очень частая ситуация, когда человек воспринимает ситуацию, требующую менеджерского решения, не рационально, а эмоционально, причем эмоции часто основаны на воспринимаемом близко к сердцу личном (опыте или переживании).
Мораль:
➖Решая ситуацию как менеджер, нельзя полагаться на эмоции, на свою личную жизнь и опыт, прошлую карьеру. Только на объективный анализ текущей ситуации
➖"Мне/кому-то было тяжело, теперь вам должно быть тяжело" - это токсичная, неэффективная, а потому еще и глупая установка
В этой истории я уже достаточно опытный разработчик с навыками аналитика, решающий весь цикл задачи от общения с пользователем до реализации и тестирования. Наша команда занимается разработкой биллинга и различных внутренних продуктов, которыми пользуется бухгалтерия и т.п.
Возникает типовая задача - из-за рассинхрона финансовых данных между разными сервисами нужен какой-то механизм сверок. Есть несколько частей системы, за каждую отвечают разные отделы. И вот есть заказчик - главный бухгалтер, и есть менеджер, принимающий решение - директор по разработке.
У нас возникли разногласия - я предлагал сделать сверку на стороне моей команды, потому что тогда это будет сделано быстро и качественно. Директор предлагал сделать в на стороне команды, которая отвечает за данные (DWH), потому что это "правильно", и по правильному сверки должны быть на их стороне. Технически сделать можно было и так и так - в обеих системах были все возможности.
В общем мы немного поспорили, потому что я понимал, что если это отдать им - это либо вообще не будет сделано, либо будет сделано через несколько месяцев против наших 1-2 недель. Но Head of Dev твердо остался на своем.
Это типичный выбор между "как правильно" (теоретически) и "как лучше" (в реальности). И это довольно типичная ошибка людей с майндсетом разработчика.
Я на тот момент еще достаточно горячо, скажем так, воспринимал такие ситуации, поэтому на этом я не остановился, и решил слегка поинтриговать, чтобы было таки выбрано мое решение. Я отдельно встретился и обсудил ситуацию с заказчиком (главным бухгалтером) и описал просто - "либо мы делаем как хочет Стас, либо это будет нормально и быстро сделано". Она всё поняла, не знаю что там было сделано за кулисами, но через пару дней нам отдали эту задачу )
Мораль:
➖Реальные условия на земле всегда важнее "теоретически правильного" решения
➖При оценке ситуации надо учитывать качество и надежность кадров, а не только технологии и организационную структуру
➖Порой можно добиться своего решения, даже если ты разработчик, а оппонент - директор по разработке. Если уметь и хотеть. Другой вопрос - нужно ли вам это?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4❤2
#рекомендации
В перерывах между историями хочу поделиться рассказом Ивана Селиховкина "Черная книга скрам". Это тот чел, набором статей про проектный менеджмент которого я делился в одном из постов.
Вообще я не знаю, что он за человек и чем занимается, но он пишет очень умно и с глубоким знанием вопроса.
По сути, здесь он в форме рассказа иронически пересматривает очень распространенную не критичную точку зрения на Agile в форме карго-культа. Я бы даже сказал, что прочитать рассказ и тщательно его обдумать - это хорошее упражнение, чтобы подняться на ступеньку выше как менеджер, умеющий выбирать правильные организационные инструменты.
Ссылка: https://pmjournal.ru/articles/keysy/chernaya-kniga-skram/
В перерывах между историями хочу поделиться рассказом Ивана Селиховкина "Черная книга скрам". Это тот чел, набором статей про проектный менеджмент которого я делился в одном из постов.
Вообще я не знаю, что он за человек и чем занимается, но он пишет очень умно и с глубоким знанием вопроса.
По сути, здесь он в форме рассказа иронически пересматривает очень распространенную не критичную точку зрения на Agile в форме карго-культа. Я бы даже сказал, что прочитать рассказ и тщательно его обдумать - это хорошее упражнение, чтобы подняться на ступеньку выше как менеджер, умеющий выбирать правильные организационные инструменты.
Ссылка: https://pmjournal.ru/articles/keysy/chernaya-kniga-skram/
👍3🔥2🤔1
Продолжаем истории "что такое плохо".
6️⃣ "Удали, пожалуйста, свое сообщение"
Я тогда работал разрабом, где-то 2,5 года опыта примерно было. 50%+ моей работы это была поддержка, в основном колл-центра, оформления заказов, логистики и т.п. в приложении. Короче, много общался с пользователями и консультировал их, так как часто какие-то проблемы были из недопонимания и решались на словах. А если надо было кодить - то либо решал сам, либо передавал другим разрабам по зонам ответственности. И я был, соответственно, единой точкой входа в команду разработки по любым проблемам.
При этом у нас были трое парней на саппорте, которые по сути просто перенаправляли запросы ко мне, даже с типовыми вопросами. У меня закономерно возникла идея реорганизовать саппорт по нормальному, чтобы консультационные вопросы по работе приложения решались поддержкой, а не разрабами, типовые так точно.
Я придумал и предложил руководителю департамента улучшенную схему работы саппорта, предложил сделать внутреннюю базу знаний по решению типовых кейсов поддержкой и т.п., с обоснованием, в том числе экономическим (саппорт в несколько раз дешевле разрабов).
На это предложение отреагировали положительно, но с классической оговоркой - что организация, внедрение и обучение полностью на мне.
И вот, ближе к концу обсуждения этой идеи, идет переписка на корпоративном портале в комментах между мной, руководителем нашего департамента разработки, и техническим директором, который руководит этими чувачками на саппорте. У меня возникает резонный вопрос - а какая мотивация у этих ребят браться за это и усложнять себе работу - сейчас они с отключенным мозгом могут просто раскидывать тикеты, а в этой схеме они должны стать специалистами как минимум 2 линии. И там же спрашиваю, будет ли у них какое-то повышение зарплаты или какой у них мотив этим заниматься. В общем веду себя как нормальный человек, который конструктивно решает рабочую проблему.
Через несколько минут мне звонит техдир, их руководитель, и говорит "Удали, пожалуйста, свое сообщение". Я, помню, даже опешил от такого прикола. Говорю: "эээ, хорошо, а какая-все таки у них будет мотивация этим заниматься?". И он отвечает: "то что их не уволят" %)) В общем молодо-зелено, сообщение я удалил (сегодняшний я бы не удалил), но сразу сделал вывод, что, во-первых, техдир идиот, и во-вторых, что шансов у этого проекта примерно 0%.
При этом проект уже был повешен на меня. Я потратил какое-то время, пытаясь понять, можно ли с него съехать, и когда понял, что нельзя - просто договорился со своим руководителем, что мы попробуем, может получится, а может нет (я знал, что точно нет), и не стал особо вкладывать усилия в это, отработал чисто формально (естественно, у чуваков не было никакой мотивации), и всё это потихоньку сошло на нет за несколько месяцев и тихо было прикопано без каких-то дальнейших обсуждений.
Мораль:
➖Если вы имеете дело с каким-то среднего уровня менеджментом (а средний уровень - слабый), то скорее всего ваши предложения по улучшению работы, требующие чего-то от кого-то кроме вас - не взлетят. Бывает сложно оценить уровень менеджера, особенно по неопытности, но просто знать об этом уже неплохо.
➖Переход на принципиально более сложную и ответственную работу всегда должен сопровождаться промоушеном (повышением с изменением роли и зарплаты). Он может быть отложенным (по достижению результата), но из этого правила нет исключений. Альтернатива - почти гарантированно отсутствие мотивации этим заниматься.
➖Если на человека вешают невыполнимую или крайне неприятную задачу - отказываться и ругаться это не всегда единственная выход, который у него есть. Тихий и неприметный слив - это вторая опция. Это знает любой опытный менеджер как применительно к себе, так и к членам своей команды )
Я тогда работал разрабом, где-то 2,5 года опыта примерно было. 50%+ моей работы это была поддержка, в основном колл-центра, оформления заказов, логистики и т.п. в приложении. Короче, много общался с пользователями и консультировал их, так как часто какие-то проблемы были из недопонимания и решались на словах. А если надо было кодить - то либо решал сам, либо передавал другим разрабам по зонам ответственности. И я был, соответственно, единой точкой входа в команду разработки по любым проблемам.
При этом у нас были трое парней на саппорте, которые по сути просто перенаправляли запросы ко мне, даже с типовыми вопросами. У меня закономерно возникла идея реорганизовать саппорт по нормальному, чтобы консультационные вопросы по работе приложения решались поддержкой, а не разрабами, типовые так точно.
Я придумал и предложил руководителю департамента улучшенную схему работы саппорта, предложил сделать внутреннюю базу знаний по решению типовых кейсов поддержкой и т.п., с обоснованием, в том числе экономическим (саппорт в несколько раз дешевле разрабов).
На это предложение отреагировали положительно, но с классической оговоркой - что организация, внедрение и обучение полностью на мне.
И вот, ближе к концу обсуждения этой идеи, идет переписка на корпоративном портале в комментах между мной, руководителем нашего департамента разработки, и техническим директором, который руководит этими чувачками на саппорте. У меня возникает резонный вопрос - а какая мотивация у этих ребят браться за это и усложнять себе работу - сейчас они с отключенным мозгом могут просто раскидывать тикеты, а в этой схеме они должны стать специалистами как минимум 2 линии. И там же спрашиваю, будет ли у них какое-то повышение зарплаты или какой у них мотив этим заниматься. В общем веду себя как нормальный человек, который конструктивно решает рабочую проблему.
Через несколько минут мне звонит техдир, их руководитель, и говорит "Удали, пожалуйста, свое сообщение". Я, помню, даже опешил от такого прикола. Говорю: "эээ, хорошо, а какая-все таки у них будет мотивация этим заниматься?". И он отвечает: "то что их не уволят" %)) В общем молодо-зелено, сообщение я удалил (сегодняшний я бы не удалил), но сразу сделал вывод, что, во-первых, техдир идиот, и во-вторых, что шансов у этого проекта примерно 0%.
При этом проект уже был повешен на меня. Я потратил какое-то время, пытаясь понять, можно ли с него съехать, и когда понял, что нельзя - просто договорился со своим руководителем, что мы попробуем, может получится, а может нет (я знал, что точно нет), и не стал особо вкладывать усилия в это, отработал чисто формально (естественно, у чуваков не было никакой мотивации), и всё это потихоньку сошло на нет за несколько месяцев и тихо было прикопано без каких-то дальнейших обсуждений.
Мораль:
➖Если вы имеете дело с каким-то среднего уровня менеджментом (а средний уровень - слабый), то скорее всего ваши предложения по улучшению работы, требующие чего-то от кого-то кроме вас - не взлетят. Бывает сложно оценить уровень менеджера, особенно по неопытности, но просто знать об этом уже неплохо.
➖Переход на принципиально более сложную и ответственную работу всегда должен сопровождаться промоушеном (повышением с изменением роли и зарплаты). Он может быть отложенным (по достижению результата), но из этого правила нет исключений. Альтернатива - почти гарантированно отсутствие мотивации этим заниматься.
➖Если на человека вешают невыполнимую или крайне неприятную задачу - отказываться и ругаться это не всегда единственная выход, который у него есть. Тихий и неприметный слив - это вторая опция. Это знает любой опытный менеджер как применительно к себе, так и к членам своей команды )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤4🔥3
Предпоследняя история про плохой менеджмент.
7️⃣ "вам самим-то не надоело в говне сидеть?"
Эта история из восьми - моя любимая. Сама ситуация очень короткая, но чтобы была понятна вся ее глубина - придется рассказать предысторию.
Мы работали с другом в одной компании, оба программистами. У него были амбиции тимлида, и он нашел подходящую вакансию. Позвал меня с собой - поставил там условие, что ему нужен свой аналитик-прогер.
Это была финтех компания, в ней долгое время не могли найти руководителя в одну из команд разработки. Всё, начиная от процессов и заканчивая состоянием системы, было в относительно плачевном состоянии (было вообще в ужасном, но часть уже успели наладить при предыдущем тимлиде, который ушел за несколько месяцев до этого).
Онбординг был из серии "вот держите доступы". При трудоустройстве я общался с Head of HR и CTO, когда я через месяц пришел на работу - оба они уже уволились. По некоторым конкретным вопросам мог проконсультировать бывший тимлид (с ним был контракт на поддержку), но в целом он не сильно горел желанием сотрудничать и это было заметно.
Так что по большому счету нас просто закинули туда и предоставили самим себе. На доске в Jira - все как обычно, какие-то задачи зависшие на много месяцев в in development, непонятно что на самом деле в работе, задачи с описанием в две строки или вообще без описания и куча проблем в системе. И с командой тоже не все гладко - например, там был чувак, который вообще ничего не делал и его пришлось сразу уволить.
По сути у нас не было никакого руководителя, никто нам не ставил никакие цели, был какой-то поток бизнесовых задач, но в целом мы были просто предоставлены сами себе. Друг занялся больше технической частью и командой, я занялся процессами, ходил вместо него на часть совещаний с руководителями других отделов и заказчиками, реверс-инжинирингом проанализировал имеющийся API и описал его, ну и так далее. Я разобрался в Jira, стал ее админить, сделал новую нормальную доску, сделал рабочий процесс, внедрил его. Ну и при этом мы оба еще параллельно прогали задачи, которые влетали к нам - на разработку или какую-то аналитику собрать.
Так прошло первых несколько месяцев. Наняли нам нового руководителя - техдира. Чувак из тех, про которых сразу мелькает мысль, что физиогномика работает. Мы познакомились, он там начал какой-то свой онбординг проходить, вникать в дела.
(мы подошли к самой ситуации категории "что такое плохо") И вот, где-то пару недель наверно он работает, подходит он к нам с моим другом в опенспейсе с каким-то очередным вопросом о том, как всё устроено, и говорит: "слушайте, вам самим-то не надоело в говне сидеть?"
Вот так вот. %)
Мораль:
➖Ну, во-первых это очень смешно )
➖ Недостаток эмпатии и эгоцентричность для менеджера - это очень большая проблема, исключающая возможность наладить доверительные отношения с сотрудниками (если это не какие-то попадающие в зависимость жертвы)
➖Надо думать, что говоришь. Можно ляпнуть какую-то глупость при знакомстве с людьми, и потом исправить это впечатление будет крайне тяжело или невозможно
➖Другие люди - это не NPC, они тоже что-то делают осмысленное. Придя на новую работу - стоит начать с интервью членов команды и сбора информации о том, что происходило до тебя
➖Ситуацию в менеджменте надо всегда понимать не в статике, а в динамике - "было/стало", отдельные факты имеют малое значение. И лишь на таком уровне стоит давать какую-то оценку работе других людей.
➖И если эта оценка плохая - порой лучше промолчать и подумать еще.
Эта история из восьми - моя любимая. Сама ситуация очень короткая, но чтобы была понятна вся ее глубина - придется рассказать предысторию.
Мы работали с другом в одной компании, оба программистами. У него были амбиции тимлида, и он нашел подходящую вакансию. Позвал меня с собой - поставил там условие, что ему нужен свой аналитик-прогер.
Это была финтех компания, в ней долгое время не могли найти руководителя в одну из команд разработки. Всё, начиная от процессов и заканчивая состоянием системы, было в относительно плачевном состоянии (было вообще в ужасном, но часть уже успели наладить при предыдущем тимлиде, который ушел за несколько месяцев до этого).
Онбординг был из серии "вот держите доступы". При трудоустройстве я общался с Head of HR и CTO, когда я через месяц пришел на работу - оба они уже уволились. По некоторым конкретным вопросам мог проконсультировать бывший тимлид (с ним был контракт на поддержку), но в целом он не сильно горел желанием сотрудничать и это было заметно.
Так что по большому счету нас просто закинули туда и предоставили самим себе. На доске в Jira - все как обычно, какие-то задачи зависшие на много месяцев в in development, непонятно что на самом деле в работе, задачи с описанием в две строки или вообще без описания и куча проблем в системе. И с командой тоже не все гладко - например, там был чувак, который вообще ничего не делал и его пришлось сразу уволить.
По сути у нас не было никакого руководителя, никто нам не ставил никакие цели, был какой-то поток бизнесовых задач, но в целом мы были просто предоставлены сами себе. Друг занялся больше технической частью и командой, я занялся процессами, ходил вместо него на часть совещаний с руководителями других отделов и заказчиками, реверс-инжинирингом проанализировал имеющийся API и описал его, ну и так далее. Я разобрался в Jira, стал ее админить, сделал новую нормальную доску, сделал рабочий процесс, внедрил его. Ну и при этом мы оба еще параллельно прогали задачи, которые влетали к нам - на разработку или какую-то аналитику собрать.
Так прошло первых несколько месяцев. Наняли нам нового руководителя - техдира. Чувак из тех, про которых сразу мелькает мысль, что физиогномика работает. Мы познакомились, он там начал какой-то свой онбординг проходить, вникать в дела.
(мы подошли к самой ситуации категории "что такое плохо") И вот, где-то пару недель наверно он работает, подходит он к нам с моим другом в опенспейсе с каким-то очередным вопросом о том, как всё устроено, и говорит: "слушайте, вам самим-то не надоело в говне сидеть?"
Вот так вот. %)
Мораль:
➖Ну, во-первых это очень смешно )
➖ Недостаток эмпатии и эгоцентричность для менеджера - это очень большая проблема, исключающая возможность наладить доверительные отношения с сотрудниками (если это не какие-то попадающие в зависимость жертвы)
➖Надо думать, что говоришь. Можно ляпнуть какую-то глупость при знакомстве с людьми, и потом исправить это впечатление будет крайне тяжело или невозможно
➖Другие люди - это не NPC, они тоже что-то делают осмысленное. Придя на новую работу - стоит начать с интервью членов команды и сбора информации о том, что происходило до тебя
➖Ситуацию в менеджменте надо всегда понимать не в статике, а в динамике - "было/стало", отдельные факты имеют малое значение. И лишь на таком уровне стоит давать какую-то оценку работе других людей.
➖И если эта оценка плохая - порой лучше промолчать и подумать еще.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤5🔥4
Человек для роли или роль для человека?
Пару раз у меня стояла задача составить или применять "матрицу грейдов" для команды разработки. У думающих людей эти матрицы всегда вызывают процесс критического осмысления содержимого.
❓Действительно ли мы это используем в работе?
❓Правда ли мы именно так определяем рост на следующий грейд?
❓Действительно ли те, кого мы нанимаем и кто у нас уже работают - одинаково соответствуют описанным характеристикам?
❓Действительно ли мы именно на эти вещи смотрим, когда оцениваем сотрудников?
Ну и так далее. Обычно ответ на все или часть этих вопросов - нет.
Другой вопрос - дело ли в конкретной матрице (плохая матрица) или вообще под вопросом целесообразность ее наличия.
Хорошая сторона этой затеи - людям действительно порой не хватает ориентиров по каким критериям им можно улучшить свою работу и как двинуться дальше. Но это в принципе можно решать личным карьерным треком, сделанным на пару с менеджером.
Такие "хорошие" стороны как формализация причин отказа в повышении или принижения чьих-то заслуг я не рассматриваю как хорошие ) Стандартизацию с натяжкой можно отнести к положительным, но стандартизация не имеет самоценности и не может быть целью самой себя.
Плохих сторон, как мне видится, гораздо больше.
Они проистекают из идеи, что люди разные, и у всех разные сильные и слабые стороны. Есть такое выражение - "прокрустово ложе". Строгое и последовательное соблюдение стандартов грейдов, на мой взгляд, имеет именно этот эффект.
Во-первых, кто-то круче, а кто-то слабее. Стандарт подгонять под слабых или под сильных? Если его сделать средним - одни не будут до него дотягивать, другие будут заведомо его превышать. Придется лукавить.
Во-вторых, всегда (почти) это сводится к "на бумаге так, а на практике мы наши субъективные оценки работы человека подгоняем под шаблон". То есть, если нам чья-то работа нравится - мы склонны таким образом зафреймить его работу, чтобы она подходила под предлагаемые компетенции. А если нет - то всегда без труда можно найти в списке отсутствующие или слабые пункты.
То есть фактически это не алгоритмизируется и не автоматизируется, поэтому поверх субъективного мнения менеджера мы просто накладываем формальный слой, который добавляет издержки поверх субъективного решения. То есть решение будет ровно то же самое, просто потребуется дополнительный труд для его принятия.
Но вообще пост не про матрицу компетенций и грейды. Пост про то, вокруг чего строить команду - вокруг сильных сторон или вокруг слабостей. Это не такой очевидный вопрос, и хоть я в такой формулировке его не слышал от других менеджеров, а только в книгах, но по факту люди этот выбор совершают.
Когда мы говорим, что для определенной роли нужен такой-то минимальный набор компетенций, фактически мы легитимизируем фокусировку на слабых сторонах. То есть надо каждую свою компетенцию довести до какого-то приемлемого уровня.
В реальности мы часто имеем команду, в которой люди очень разные, причем чем команда сильнее - тем она более разнообразна и вариативна. В такой команде один будет энтузиастом, другой надежным и ему можно доверить ответственные вещи делать в соло, третий хаотичным и забывчивым, но решающим намного более сложные задачи, четвертый - очень трудоспособным, но с проблемами когда надо делать что-то сложное, а пятый - добряком, с которым всем приятно работать и из-за этого в команде отличная атмосфера.
Представьте, что для этих людей нужно сделать единый стандарт. Это я упомянул (в очень утрированном поверхностном виде) только про личные качества. А еще есть зоны ответственности, которые тоже распределены совершенно неравномерно. Кто-то только делает задачи, а кто-то еще их создает. Кто-то делает деплой. Кто-то следит за ошибками в логах, а кто-то нет.
Надо ли, чтобы все делали весь перечень работ? Сколько-то пунктов из этого списка? А что, если кто-то будет очень хорошо и стабильно делать сложные задачи, но ничего дополнительно на себя не берет?
Здесь есть над чем подумать, и, пожалуй, тема стоит еще одного поста, раскрывающего мою точку зрения на то, "как надо".
Пару раз у меня стояла задача составить или применять "матрицу грейдов" для команды разработки. У думающих людей эти матрицы всегда вызывают процесс критического осмысления содержимого.
❓Действительно ли мы это используем в работе?
❓Правда ли мы именно так определяем рост на следующий грейд?
❓Действительно ли те, кого мы нанимаем и кто у нас уже работают - одинаково соответствуют описанным характеристикам?
❓Действительно ли мы именно на эти вещи смотрим, когда оцениваем сотрудников?
Ну и так далее. Обычно ответ на все или часть этих вопросов - нет.
Другой вопрос - дело ли в конкретной матрице (плохая матрица) или вообще под вопросом целесообразность ее наличия.
Хорошая сторона этой затеи - людям действительно порой не хватает ориентиров по каким критериям им можно улучшить свою работу и как двинуться дальше. Но это в принципе можно решать личным карьерным треком, сделанным на пару с менеджером.
Такие "хорошие" стороны как формализация причин отказа в повышении или принижения чьих-то заслуг я не рассматриваю как хорошие ) Стандартизацию с натяжкой можно отнести к положительным, но стандартизация не имеет самоценности и не может быть целью самой себя.
Плохих сторон, как мне видится, гораздо больше.
Они проистекают из идеи, что люди разные, и у всех разные сильные и слабые стороны. Есть такое выражение - "прокрустово ложе". Строгое и последовательное соблюдение стандартов грейдов, на мой взгляд, имеет именно этот эффект.
Во-первых, кто-то круче, а кто-то слабее. Стандарт подгонять под слабых или под сильных? Если его сделать средним - одни не будут до него дотягивать, другие будут заведомо его превышать. Придется лукавить.
Во-вторых, всегда (почти) это сводится к "на бумаге так, а на практике мы наши субъективные оценки работы человека подгоняем под шаблон". То есть, если нам чья-то работа нравится - мы склонны таким образом зафреймить его работу, чтобы она подходила под предлагаемые компетенции. А если нет - то всегда без труда можно найти в списке отсутствующие или слабые пункты.
То есть фактически это не алгоритмизируется и не автоматизируется, поэтому поверх субъективного мнения менеджера мы просто накладываем формальный слой, который добавляет издержки поверх субъективного решения. То есть решение будет ровно то же самое, просто потребуется дополнительный труд для его принятия.
Но вообще пост не про матрицу компетенций и грейды. Пост про то, вокруг чего строить команду - вокруг сильных сторон или вокруг слабостей. Это не такой очевидный вопрос, и хоть я в такой формулировке его не слышал от других менеджеров, а только в книгах, но по факту люди этот выбор совершают.
Когда мы говорим, что для определенной роли нужен такой-то минимальный набор компетенций, фактически мы легитимизируем фокусировку на слабых сторонах. То есть надо каждую свою компетенцию довести до какого-то приемлемого уровня.
В реальности мы часто имеем команду, в которой люди очень разные, причем чем команда сильнее - тем она более разнообразна и вариативна. В такой команде один будет энтузиастом, другой надежным и ему можно доверить ответственные вещи делать в соло, третий хаотичным и забывчивым, но решающим намного более сложные задачи, четвертый - очень трудоспособным, но с проблемами когда надо делать что-то сложное, а пятый - добряком, с которым всем приятно работать и из-за этого в команде отличная атмосфера.
Представьте, что для этих людей нужно сделать единый стандарт. Это я упомянул (в очень утрированном поверхностном виде) только про личные качества. А еще есть зоны ответственности, которые тоже распределены совершенно неравномерно. Кто-то только делает задачи, а кто-то еще их создает. Кто-то делает деплой. Кто-то следит за ошибками в логах, а кто-то нет.
Надо ли, чтобы все делали весь перечень работ? Сколько-то пунктов из этого списка? А что, если кто-то будет очень хорошо и стабильно делать сложные задачи, но ничего дополнительно на себя не берет?
Здесь есть над чем подумать, и, пожалуй, тема стоит еще одного поста, раскрывающего мою точку зрения на то, "как надо".
👍8🔥5