💃А может и мне пора уволиться?

Когда люди увольняются - это болезненно сказывается на всех. Сегодня хочется обратить внимание на взгляд обычного сотрудника, назовем её Василиса. Вася видит, как её коллеги из разных команд увольняются по разным причинам. Коллеги и раньше увольнялись, просто сейчас слишком многих из них Вася знает лично. Текучка близко прошла к Василисе, вильнула хвостом и оставила чемоданчик последствий. Один ушел, второй, и вот Вася уже думает.. А может и мне надо? Чего это они все уходят? Там лучше кормят? Больше зарплата? Лучше компания? Моя компания плохая? Я явно чего-то не знаю, надо открыть резюме.

Знакомо?
У меня пару тройку раз за жизнь бывало)

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

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

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

#карьера

Как ощущает себя ПМ, когда все его тимлиды и руководители разработки разбежались в отпуска или на больничные.
Один в поле войн, ввожу хештег #жиза.

Всем хороших выходных!

Если вы не знаете, чем заняться этим вечером, то можете перечитать посты в Кнопке Хорошо и зараспрастранить стикеры среди жильцов вашего ЖЭКа, как вы это любите 🖤

3 мастхэва для проектов со сложными зависимостями

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

3 фактора успеха в управлении такими задачами со сложными зависимостями.

👩‍💻 Ответственный
Если нет одного человека, который хотя бы курирует все команды, то результат будет не предсказуемым. Каждая команда по умолчанию отвечает за свой кусочек работы. Наивно предполагать, что все команды имеют видение конечного результата и бегут к нему осознанно и самостоятельно. Чтобы закрыть риск провала проекта, потому что никто не ответственный за конечный результат - нужно найти менеджера-куратора, который будет объединять команды, следить за статусом, собирать созвоны, когда видит непонимание. Например, это может быть менеджер команды, которая производит конечный результат или самый синьорный менеджер. Если у вас еще нет такого куратора и вы не можете им быть, не стесняйтесь обращаться с коллегам, заводить этот разговор, предлагать кандидатуру.

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

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

Картинки для вас в следующем посте ⬇️
#разработка

Epic Growth Conf X Кнопка Хорошо = ?

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

Если ваша профессия - не продакт менеджер, и вы думаете, что такая конференция вас не касается, вы ошибаетесь. Я не продакт, но иду, чтобы расширять кругозор, чтобы предлагать улучшалки в своих продуктовых командах, влиять на рост своей компании, нетворкиться.
Например, очень жду доклада «User engagement прямо на пейволе» из-за моей принадлежности к двум маркетинговым командам. И не смогу пройти мимо «Growth Hacking организации - как управлять ростом компании», потому что сидеть на своих проектах и не лезть в процессы компании - это не про меня.

Полную программу с докладами и воркшопами - смотрим на сайте https://egconf.ru/.

💣А теперь БОМБА-ПУШКА-НОВОСТЬ. Мы с Epic Growth среди читателей Кнопки Хорошо разыгрываем 2 билета Online Standart на эту самую конференцию. Победителям будет доступна онлайн-трансляция, записи докладов и воркшопов.

Что нужно сделать - ответить в комментариях или мне в личку на ОДИН из вопросов:

1. Что лучше: бесплатный пробный период и потом полный платный доступ к продукту ИЛИ часть продукта бесплатно, а дополнительные фичи к нему платно? Почему?
2. Если вам что-то не нравится в продукте, как понять, что это общая проблема, а не вы тормозите или придираетесь?

Присылайте ваши размышления на любой из вопросов до 7 сентября 18:00. Победителя выберу на свой субъективный вкус и цвет. Good luck 🍀

Сегодня уже пятница, конец рабочей недели, поэтому не забываем:

​​Добрейшего утра, напоминаю, что еще собираю ваши ответы для розыгрыша онлайн билетов на конференцию Epic Growth.

Ответы оставляйте в комментариях или пишите в личку до 18:00 конца дня.
Победителей выберу завтра.

​​🤼‍♀️ Разработчик →← Продакт

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

🛑Что может произойти на таком созвоне с невинной задумкой "да мне только прояснить":
1. Изменится scope. Например, решили что-то выкинуть из условий задачи или поняли, что хотим изменить описанную логику, чтобы улучшить эффект фичи.
2. Изменятся оценки. Изменение или прояснение scope не всегда, но часто влияет на трудозатраты в большую сторону.
3. Изменится бюджет. Где меняются оценки, там меняется и стоимость.

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

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

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

#заказчик #манагерство