Менеджер от боженьки

Как давать негативный фидбек Одно из самых сложных в работе для – давать негативный фидбек. С позитивным все легко и просто, ведь хвалить людей всегда приятно. А критиковать как-то неуютно, таких разговоров хочется избежать. Мол, откуда вообще у меня право говорить человеку, как ему жить? Обычно фидбек дают на встречах 1-1. Чтобы сотрудник прислушался, надо доносить проблему максимально точно: ты не вложился в оценку -> поехали сроки -> заказчик недоволен. Если говорить общими фразами и полунамеками, есть большой шанс, что тебя не услышат. С другой стороны, важно не задеть чувства человека. Чтобы ему не показалось, что его отчитывают как школьника за невыполненную домашку. Есть разные техники, которые помогают справиться с этим балансом, например, бутерброд или BOFF. Мне понравились принципы, которые использует Нетфликс, потому что они короткие и простые. Всего 2 совета для тех, кто дает фидбек и 2 для принимающей стороны. Когда даешь фидбек: ▫️Стремись помочь. Критикуй с искренним желанием сделать мир лучше. ▫️Предлагай конкретные шаги. Объясняй, что именно человек сделал не так, какой был негативный эффект и как его можно было избежать. Когда получаешь фидбек: ▫️Будь благодарен за обратную связь. Когда слышишь негатив, твоя естественная реакция - начать оправдываться и защищаться. Ее надо побороть и вспомнить про пункт 1. ▫️Не всем советам обязательно следовать. Некоторые из них могу быть действительно "мимо". Только тебе решать к каким прислушаться.

Как я потерял проект, который приносил компании миллион+ баксов в год Мы работали с этим заказчиком уже несколько лет. Его бизнес растет, наша команда растет, все довольны. Потом появился он – черный экран 💀💀💀 У пользователей нашего софта рандомно вываливает черный экран во время видео стрима. Мейн флоу не работает! Идет неделя, вторая, месяц, а причина бага все не находится. Заказчика чаще вижу хмурым – бизнесу приходится платить за эти ошибки и тратить время сотрудников на устранение последствий. Чую, что долго мы так не протянем. Так и случается. За неделю до Рождества набирает главный стейк, и говорит, что вэри сорри, но режем команду. На 30% в следующем месяце и +- всю в течение года. Уау! Сейлы пытаются что-то спасти, подключают СЕО, но все тщетно, заказчик непреклонен. На все вопросы говорит, что решили растить экспертизу внутри, но все понимают, в чем дело 📺💀 Проходит пара месяцев, и в новостях пишут, что компании заказчика больше нет. Как это, нет? Произошло слияние с другой компанией, и теперь они часть большой корпы в этом сегменте. Значительная часть подрядчиков идет под нож при таких сделках. И в первую очередь режут аутсорсеров из далекой страны. В общем, рисками, конечно, нужно заниматься. Стараться снизить вероятность и влияние. Но жахнуть может откуда вообще не ждешь. ——— На картинке: реальная история из 2015, когда акула покусала подводный кабель, из-за чего во Вьетнаме несколько недель был очень медленный интернет.

Пример оценки фичи Представьте, что ведете проект а-ля мессенджер. Заказчик присылает вам такое письмо: Хочу фичу, чтобы можно было отправлять фото в чат. Сколько будет стоить? Давайте разберем, что делать. Если на проекте есть бизнес-аналитик, просим его расписать юзкейсы. Если нет – пишем сами (ну как, сами 🪄🤖), примерно так: 📌 получить доступ к галерее; 📌 выбрать фото + превью перед отправкой; 📌 загрузить фото в чат; 📌 посмотреть отправленное фото; Берем эти юзкейсы и идем утверждать их с заказчиком. Там же обговариваем другие кейсы, которые можно придумать для этой фичи – отправка видео, сжатие, история, редактирование перед отправкой и т.п. Чем больше насобираем сейчас, тем меньше шанс услышать на приемке "ой, а почему видео нельзя отправить? я думал, это подразумевается...". Чтобы не раздувать скоуп, предлагаем все необязательные кейсы сделать потом, в фазе 2. Вдруг фича вообще не пойдет? На этом этапе полезно смотреть, как аналогичные фичи работают у конкурентов 👀. Когда кейсы утверждены, идем к команде оценивать. Собираем всех в зуме и рассказываем про фичу. Мобильщики смотрят на требования и говорят, что на разработку нужно 80 часов. Бекенд просит 40. Дизайнеру понадобится 40 на отрисовку экранов. В сумме 160. Закладываем 30% на тестирование, 20% на стабилизацию, 10% на коммуникации + 10% на себя любимого. Сверху накидываем 10% рисков и получаем еще 140 часов. По рейту 40$ в час выходит $12,000. Но это еще не все. Фотографии нужно где-то хранить, для этого понадобится отдельный сервер. Заказчик говорит, что фичей будет пользоваться каждый пятый юзер, загружая где-то 100МБ фоток в месяц. Берем текущий MAU, приносим бекендеру и получаем например, $500 в месяц на сервак. Напоследок, прикинем таймлайн 📅. Бекенд может начать первым, параллельно будем рисовать дизайн. По оценке команды это неделя, но добавим 3 дня на обсуждения, утверждение макетов и риски. Мобильщики просили 2 недели, но с тестированием и стабилизацией, разработка займет все три. После первой недели обязательно сделаем демо, чтобы избежать сюрпризов перед релизом. Закладываем день на поставку и еще 2 на риски. В итоге получаем 5 недель. Оценка готова. Ставим в копию сейла и отправляем заказчику.

Project manager (m/f/d) На немецком рынке у многих вакансий после названия должности стоит загадочное (m/f/d). Причём не только в ИТ. Сперва я подумал, что может временная работа, типо с февраля по май. Окалось проще. m/f/d означает, что приветствуются кандидаты всех гендеров: female, male, diverse. Этим работодатель подчеркивает, что ему без разницы, что у менеджера между ног. Главное, чтоб работа делалась. Аббревиатуры могут разниться, например (m/w/d), (x/f/m) или просто all genders. Смысл одинаковый. А если не указано, значит, не приветствуются? Нет, но работодатель рискует. В немецком языке слово Projektmanager мужского рода, как и многие другие профессии. Если написать так, то кто-то может подумать, что нанимают только мужчин. В Германии трудовое право сильно на стороне работника, особенно в плане дискриминации. Если соискатель докажет, что была дискриминация (а название вакансии к этому располагает), можно отсудить до 3-х зп. Поэтому эйчары везде добавляют эти f/m/d от греха.

#реклама_по_любви У Стратоплана новый ивент на следующей неделе. Будем говорить о том, что делать, чтобы зимой не уволили 😅. Вот как ребята сами анонсируют ивент:

Зарплатные гонки и “розовые единороги” в IT закончились. layoff говорит, что ожидаемое кол-во увольнений в 2026-ом будет ровно в десять раз выше, нежели в 2021-ом. LinkedIn переполнен постами о поиске работы, Хабр — очередными разборами рынка, а фраза “реорганизация” звучит, скажем так, по-другому. Мы, в Стратоплане, хотели бы, чтобы руководители сегодня – не засыпали с мыслью о том, чего же ждать от завтра и не работали с тревожными мыслями на фоне “а что, если я следующий”. Потому вместе с экспертами извне, мы задумали бесплатный интенсив «ИТ-зима. Набор для выживания». Каждый день разбираем один конкретный инструмент, чтобы не просто не “замерзнуть”, но и вырасти, потому что именно зимой – освобождаются роли и решают, кому доверять больше.

Я там, кстати, тоже буду в качестве спикера на одном эфире. Ивенты бесплатные, приходите. Темы: ▫️Как показать бизнесу ценность своей команды в цифрах. ▫️Как руководителю обосновать, почему компании стоит вложить ресурсы в его инициативу. ▫️Управление вверх: как стать руководителем, которому доверяют (я тут 😇). ▫️Al-рычаг, чтобы срезать в операционке 5-10 часов в неделю. ▫️Как принимать решения, когда всё меняется и данных не хватает. ▫️Как построить команду, которая работает без надзора. ▫️ИT-бизнес в режиме выживания: как собственнику и C-level удержать управление и результат. 12–23 октября Регистрация 👉👉👉 https://stratoplan-school.com/marathon/rk

Чем мне помогает АИ – работа с таблицами Заметный буст от АИ лично для меня случился в таблицах (которые google sheets). Некоторые вещи стали сильно быстрее или проще, вот пара примеров: 1️⃣ Работа с формулами. Раньше надо было разбираться в логике и синтаксисе SUMIF, теперь просто говорю: “посчитай количество задач в колонке A, у которых статусе done в колонке B, и выведи в C12”. Забавно, что два года назад я ходил на тренинг по всем этим SUMIFам. Тогда казалось супер полезно, а теперь эти знания уже особо и не нужны, т.к. АИ полностью закрывает знание синтаксиса. 2️⃣ Работа с App script. Это такой встроенный язык скриптования внутри таблиц, гораздо более мощный, чем стандартные функции. Например, он может сходить в какую-нибудь апишку и забрать с нее данные. Для меня апп скрипт выгружает тикеты из джиры и строит по ним отчеты в таблицах. Так проще и быстрее построить что-то кастомное, чем в самой джире. 3️⃣ Еще App script умеет выполнить действия по расписанию. Например, у меня есть скрипт, который раз в неделю рассчитывает % завершенности проекта и записывает в новую строку. Это нужно, чтобы потом построить график завершенности по неделям (см. скриншот), по которому виден ход проекта, а не только текущее состояние. Через интерфейс так настроить нельзя, насколько я знаю, а через апп скрипт – легко. Раньше я знал, что апп скрипт есть, но порог входа для меня был высок, т.к. там под капотом полноценное программирование, в котором лень разбираться. А теперь и не нужно – просто объясняю клоду, что хочу, и все работет. —— Напишите в комментах, что делаете у себя апп скриптом или его аналогами.

Меня заскамил рекрутер Столкнулся с новым скамом. Пишет рекрутер, предлагает вакансию в известную компанию с жирной зарплатой. Поначалу все идет обычно, просит сбросить резюме. Потом говорит: “Слушай, твое резюме как-то не очень, боюсь не разглядят твой талант. Давай помогу сделать его лучше? У меня как раз есть Джон, который этим занимается”. Разумеется, платно. Дальше забавно. Если говоришь, что и так сойдет, пишут, что резюме прошло, но работодатель запросил еще какие-то доки, типо Candidate Validation Document и Leadership Impact Brief. Я о таких не слышал, напишите в комменты, если встречали где-то. Джон в них, разумеется, тоже разбирается и готов помочь. Как я понял, что это скамеры: 1. Спросил, “вы скамеры?”, они сказали “нет”. 2. Писали с имейл вида moritz.manpowergroup.hr@gmail.com. У агенства скорее будет имейл в своем домене, а здесь называние компании пытаются “спрятать” в сам имейл. 3. Очень подробные ответы в течение 20-30 минут – так пишут скорее боты, чем люди. Мне так написали уже по 2м разынм позициям. Будьте бдтительны.

#реклама Маркетинг – это та же валидация гипотез, только деньги горят быстрее Фичу собрали, релиз прошёл, дальше по плану «маркетинг подхватит». На практике кто-то один написал пост, залил пятьсот евро на продвижение, и через неделю никто в команде не может сказать, сработало или нет. AI эту часть упростил: разобрать аудиторию, собрать пять углов оффера, креатив под каждый, посадочную под сегмент менеджер теперь делает сам. Узкое место сместилось на то, чтобы довести тест до решения. Собрать двадцать баннеров проще, чем один раз честно посчитать, какой из них принёс деньги. 📌Marketing Sprint от AI Mindset – три недели ровно про это. 21 сентября – 10 октября, онлайн, все сессии живые. Приходят со своим продуктом и одной живой задачей. Первая неделя – продукт, посадочная и воронка. Вторая – производство контента и атрибуция вместе с SEO и GEO. Третья – go-to-market и продажи. Финал 10 октября: демо-день, каждый показывает свою маркетинг-машину и план на тридцать дней. Ведут Виталик Урбан (CEO Moonly, 10 млн+ пользователей на бутстрапе), Рома Кумар (Qmarketing Academy, продана Skyeng), Майк Прытков (CEO Simple, 15 млн+ загрузок), Сева Устинов и Кирилл Касимский (Plurio, $500 млн+ рекламных бюджетов в год), Виталий Крылов (ex-CEO Gett), Сергей Булаев (CCCrafts), Таня Савельева и со-лид спринта Тоня Жукова (CEO voir, приложение куплено Farfetch в 2022). Два честных нюанса: 1️⃣ Роста продаж за три недели никто не обещает – за такой срок не набирается объём данных. Собирается процесс, первый запущенный тест и план тридцати дней. 2️⃣ Без действующего продукта и своей задачи смотреть там нечего. Участие €890. Программа и регистрация – через бота А в ваших командах маркетинг живёт как цикл с выводами или как «запустили и посмотрим»?

Старая дата Новая дата сдачи проекта За последний год попробовал несколько разных вариаций проектных трекеров (все в гугл таблицах). Одна вещь, которая классно прижилась плюс-минус во всех – оставлять предыдущий ETA (expected time of arrival = когда будет готово), если он обновляется. Например: ETA: Март-25 Апрель-14 Май-1 Май-15 То есть изначальная дата финиша была 25 марта, потом подвинулась на апрель, затем на май, а на сегодня мы думаем, что закончим в середине мая. Уже по одной этой строчке видно: если проект переносился 3 раза -> большой шанс, что перенесется и 4-ый!

Зачем на самом деле нужны отчеты Делаем проект на несколько команд. Цель - всем вместе увеличить метрику Х, каждая команда владеет ее кусочком в рамках своих фич. Выхожу с очередной встречи, где каждый менеджер монотонно отчитывался почему его метрика в таком-то состоянии. Первые разы мне казалось, что мы теряем время, но со временем уловил смысл. Он в том, чтобы люди думали этими метриками и за пределами встречи. Отчеты нужны не для того, чтобы мой менеджер увидел, как обстоят дела (хотя это тоже) и подстраховал, когда нужно. В первую очередь, когда я пишу отчет, МНЕ нужно понять, что происходит. Почему такие цифры. Как их поменять. Какие риски за этим стоят. Ну и так далее. Формулируя слова в отчете, я уже сам вижу, что не сходится, где проблема, и задумываюсь про следующий шаг. В этом и есть ценность отчета. Сам по себе отчет (документ) – лишь побочный продукт. Главное, что я вынужден разобраться в проблеме, а там, глядишь, и решать ее начну.

Ответы стоят денег

“Сколько пользователей на версии Х столкнулись с багом?”

“Как это решение масштабируется при х10 нагрузке?”

“Что можно выбросить из роудмапа, чтобы починить эту проблему?”

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

Ответы стоят денег

“Сколько пользователей на версии Х столкнулись с багом?”

“Как это решение масштабируется при х10 нагрузке?”

“Что можно выбросить из роудмапа, чтобы починить эту проблему?”

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

Стоимость владения 10 лет назад я купил свою первую машину – бирюзовый мини купер. До этого у меня был велосипед, который много есть не просил. Новым для меня стало то, что теперь надо тратить ~100$ в месяц на мойку, заправку, масло и т.д. – на велосипеде траты были сильно меньше. С софтом похожая ситуация – тоже иногда нужно доливать масло. Особенно теперь, когда везде АИ. Благодаря АИ делать новое вроде бы быстро и дешево. Очень круто, когда можешь за пару часов сделать микро-продукт и закрыть проблему, которая мешает жить. Заметил, что многие команды бросились “писать свое”: систему локализации, поисковик битых ссылок, обвес для аналитики. Часто это действительно оправдано, надо только помнить о стоимости владения. Все эти микро-продукты нужно будет кому-то поддерживать, как тот мини купер. Чинить баги, добавлять забытые юзкейсы – это все время команды. Чем больше у тебя таких продуктов, тем больше времени ты тратишь на то, что бы они просто продолжали работать.

Фит по культуре Один мой прошлый босс матерился. Иногда он делал презентацию, рисуя на доске жопу для иллюстрации какой-то мысли (иногда архитектуры). Мне было смешно и понятно, потому что я тоже иногда говорю жопа. Но в глазах некоторых менеджеров был ужас. Кто-то из них потом из компании ушел. Не из-за жопы, конечно, но как-то не прижились, культурой не совпали. Когда нанимаешь человека на работу, важно смотреть, чтобы он подошел еще и по культуре. Иначе куча рабочего времени будет тратиться не на решение задач, а на притирку друг к другу.  Может, если бы мы тогда писали в вакансиях "у нас иногда ругаются матом", часть людей просто не отправила бы резюме. Такая честность выгодна всем: кандидатам понятно кого рода среда их ждет, а компания экономит время более точечным отсевом. Круто, когда компания транслирует наружу свои ожидания и культуру. Вот несколько таких примеров: - Культурный код Pandadoc  - Amazon leadership principles - Gitlab Handbook

#реклама Как не потерять контроль в ИИ-проектах Наверное, каждый уважающий себя менеджер хотя бы раз испытывал это чувство, будто его разжаловали обратно в стажёра. Это происходит, когда на очередном стендапе вся команда обсуждает внедрение новой модели, а он лишь кивает с умным видом и судорожно гуглит каждое второе слово в соседней вкладке. Такой опыт не редкость. Например, менеджер фиксирует сроки релиза, а потом выясняется, что это была лишь первая итерация. Команда просит ещё времени, а возразить нечего, потому что непонятно, действительно ли это обосновано или просто удобная отговорка. Разобраться как-нибудь по ходу тут не прокатит. Лучше один раз пройти системное обучение вроде курса “Управление ИИ-проектами” от Академии Эдюсон и перестать уже падать в грязь лицом. Вам на реальных кейсах разложат весь жизненный цикл, объяснят, как ставить задачи команде, оценивать сроки и результаты внедрения. Если что непонятно – целый год на связи будет личный куратор. Вы добавите 8 работ в портфолио и разработаете ИИ-решения для бизнеса в качестве итогового проекта. В конце получите удостоверение о повышении квалификации. Оставьте заявку с промокодом МЕНЕДЖЕР – будет скидка 65% + второй курс на выбор в подарок. Реклама. ООО "Эдюсон", ИНН 7729779476, erid: 2W5zFGhZkPT

Маленький трюк, чтобы усилить договоренности Когда люди делают что-то своими руками, они больше это ценят. Вот два классных примера, которые иллюстрируют этот эффект. 1️⃣ Эффект IKEA:

В исследовании IKEA люди собирали мебель, оригами или фигурки из Lego. После этого они оценивали созданные своими руками объекты существенно выше, чем аналогичные объекты, созданные другими людьми. Когда человек сделал что-то своими руками, вложил силы и время, у него появилась микро-связь с этим чем-то. Благодаря связи, ценность растет в разы (часто непропорционально сильно).

2️⃣ Кейс про конверсию в длинной форме vs короткой

Интуитивно кажется, что чем больше в форме полей, тем больше “трение” и ниже конверсия. Но вот одни ребята

протестировали

несколько вариантов формы на сайте и обнаружили неожиданное: длинная форма с понятными вопросами сработала так же хорошо, как короткая — обе дали ~100% прирост лидов по сравнению с оригиналом. Ключевым оказалось не количество полей, а то, объясняет ли форма пользователю, зачем она задаёт каждый вопрос. Когда человек формулировал свои задачи и цели прямо в форме, он психологически вкладывался в процесс и с большей вероятностью доходил до конца. Усилие, потраченное на заполнение осмысленных полей, сработала не как трение, а как инвестиция в собственное решение.

Как это использовать в управлении проектами? Просите стейкхолдеров подтвердить ваши договоренности. Их собественными руками. Например, обновить дату поставки фичи в трекере. Или, поставить чекбокс в плане проекта напротив “я отдам бекендера на 1 неделю на ваш проект”. Мелочь, а работает. Когда человек сам пишет такой комментарий, это уже гораздо больше его решение, его слова, чем когда написал кто-то другой. Так договоренности прочнее.

Сначала сделай просто У всех ПМов есть такой чемоданчик сохраненок: шаблоны оценок, документы со старых работ, просто полезные статьи и видео. Мне пришла идея сделать такой общий мега-чемодан в сообществе ПМ совет, чтобы каждый мог скинуть что-то полезное в общий котел. Тогда мы собрались группой инициативных ребят и стали придумывать, как это реализовать. Сразу всплыла проблема с копирайтом: вдруг будут добавлять пиратский контент или корпоративные доки. После пары итераций (кажется, прошло несколько месяцев) мы придумали убойный процесс модерации. А еще апвоуты, теги и разделение материалов по группам. Когда мы все это зарелизили, то материалы добавили примерно 2,5 человека, и все эти свистелки оказались никому не нужны. Я допустил совершенно джуновскую ошибку, с головой увлекшись реализацией фичи вместо того, чтобы сначала поисследовать, кому она нужна. Этот пример подтвердил для меня простую продуктовую истину: когда валидируешь гипотезу, сначала сделай просто.