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

2024-02-20 18:00:04 Границы системы

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

Сложно управлять тем, чего не понимаешь. Например, клиент говорит, “давайте в выгрузке в CRM-ку прокидывать еще страну покупателя”, а ты думаешь “о, а мы еще какую-то выгрузку делаем?”

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

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

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

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

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

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

А какие у вас лайфхаки?

----------

UPD: хорошие варианты из комментов:
- поговорить с командой и предыдущим менеджером;
- поработать в поддержке; Открыть/Комментировать

2024-02-13 12:00:04 ​Критический путь

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

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

Объясню на примере.
Допустим, мы планируем фичу “пригласи друга, получи скидку”. Чтобы ее сделать, нужно отрисовать дизайн (1 неделя), запрогать приложение (2 недели), запрогать бекенд (1 неделя) и написать пресс-релиз (2 дня).

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

Самое минимальное время, за которое можно сделать такую фичу (ее критический путь) это: дизайн (1 неделя) + приложение (2 недели) = 3 недели.

Зачем нужен критический путь.
Во-первых, построить расписание. Чтобы это сделать, мы максимально распараллеливаем все задачи, пока это не вредит качеству и минимизируем простои между ними.

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

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

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

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

2024-01-31 18:00:03 ​Метод освоенного объема (EVA)

Метод освоенного объема (Earned Value Analysis) - техника из PMBoK, которую используют для отслеживания прогресса. С ее помощью ты ответишь на 2 главных вопроса проджект менеджмента, которые задают на любом проекте:
успеваем ли мы в срок и
вкладываемся ли в бюджет.

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

Проще всего понять, как работает EVA на примере.

Допустим, у нас проект из 8 задач, которые надо сделать за 4 дня. Мы прикинули, что будем делать по 2 задачи в день. На третий день по факту сделано 4 задачи, на которые ушло 28 часов, при первоначальной оценке 32 (см. колонки Planned value и Actual Cost).

Что можно сказать о проекте? Для этого посчитаем 2 показателя:

CPI - индекс успеваемости по бюджету (cost performance index). Здесь он равен 1,14, значит, в бюджет мы вкладываемся. И наоборот - если CPI < 1, значит, в изначальный бюджет мы не попадаем.

SPI - индекс успеваемости по расписанию (schedule performance index). В примере он 0,44, значит, в расписание мы не попадаем, причем сильно. Аналогично, если SPI > 1, значит, мы идем с опережением графика.

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

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

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

На проектах с относительными оценками EVA не особенно применим*, потому что у каждой задачи есть только planned значение - оценка в стори поинтах. Мы не считаем, сколько реально стори поинтов она заняла, поэтому не можем вычислить затраты (actual cost).
Если вам удалось прикрутить EVA к относительным оценкам, поделитесь в комментах, как это работает. В первом комменте расскажу одну реализацию, которую видел сам.

Раньше метод EVA мне казался чем-то громоздким и сложным, наверное, из-за того, что в нем много формул и определений. На деле, многие можно скипнуть и использовать только SPI и CPI, чтобы следить за попаданием в бюджет и срок. Открыть/Комментировать

2024-01-24 18:02:09 Открыть/Комментировать

2023-06-02 14:00:25 #реклама

Не устраивает работа подрядчика — что делать?

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

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

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

4. Обсудите возможность замены сотрудника
Замена потребует времени на онбординг нового человека. Это крайняя мера, но иногда она помогает получить свежий взгляд на проект.

Этим алгоритмом поделились арт-директора из студии продуктового дизайна «Луч». Ребята работают с Яндексом, Авито и ВКонтакте и копят лучшие практики.

Об остальных методах решения трудных ситуаций на проектах читайте в статье Луча

— Как выбрать подрядчика, с которым будет комфортно?
— Что делать, если подрядчик предлагает слишком комплексное и дорогое решение?
— На что клиенту заложить время, чтобы сроки проекта не сместились?
— Как запустить сотрудничество со студией без ТЗ? Открыть/Комментировать

2023-06-01 18:00:03 ​Прогулочные встречи

У нас в компании продвигают прогулочные встречи. Это когда вместо переговорки идешь митинговать на улицу.

HRы нарисовали карту района вокруг офиса, обозначив маршруты на 15, 30 и 45 минут. Удобно, что не надо думать, куда идти и сколько времени закладывать, чтобы вовремя успеть обратно.

Я так сходил на несколько встреч, мне понравилось. Вроде бы и поработал, и очков здоровья немного собрал, размялся. Для 1-1 это отличный формат.

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

Еще один минус лично для меня, это сниженная концентрация. Постоянно надо смотреть, куда шагаешь, чтобы не попасть под велосипед или самокат. Думать одновременно с этим сложнее.

Напишите в комментах, как вам формат, если попробуете. Открыть/Комментировать

2023-05-25 18:00:03 ​Этикет видеозвонков

Несколько советов, которые сделают из вас английского лорда (или леди) в сфере видеозвонков.

Нормально:
Пить кофе или воду.
Сидеть без камеры, когда у всех тоже выключена камера.
Заходить на звонок с выключенным микрофоном.
Raise hand, когда хочешь что-то сказать.
Написать в чат “sorry I’m late”, если опоздал и дискуссия уже началась.

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

Неприлично:
Оставлять включенным микрофон, когда не говоришь, и все слышат это шуршание.
Перебивать.
Курить сигареты (вейпы, электронки, айкосы, шмайкосы).
“Ваня, что ты думаешь по этому поводу?”, а в ответ - тишина. Ваня куда-то отошел, но все еще висит на звонке.

См. также: Календарный этикет Открыть/Комментировать

2023-05-19 17:00:03 ​Статусы проектов и план спасения

У нас в компании на этот год запланировано 600 OKR-ов. Чтобы СТО не потратил целый день, просматривая их все, а понимал большую картину по поставке, за которую он отвечает, сделали статусы. Всем OKR (считай, проектам) ставят статус, а затем строят разную статистику на этой основе. Такие есть в любой организации, где работает 300+ человек.

Бывает 3 статуса:

Зеленый: Проект on track, все риски понятны и есть митигейшн план.

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

Красный: У проекта есть блокеры или неопределенность, из-за которых он пропустит дедлайн, а также нету согласованного плана спасения.

Последний как раз и представляет наибольший интерес.

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

Залог хорошего плана спасения - понятные шаги, благодаря которым блокеры растворятся. Например:

1. Что делаем: анализируем, что из неучтенного куска влияет на OKR и составляем technical proposal вместе с командой Х.

2. Кто именно отвечает за действие: тимлид Ваня.

3. В какие даты: 24-30 мая.

4. Какие критерии того, что проект снова будет зеленым: команда Х подтвердила доп. работы и успевает их выполнить к дедлайну по OKR.

5. Что делать, если проект остается желтым или красным: пересмотреть другие фичи из OKR, чтобы вместить неучтенный кусок.

Не всегда проект получает нужное внимание и ресурсы со стороны стейкхолдеров. Если команда Х тупит и вторую неделю не может посмотреть technical proposal, нужно это где-то зафиксировать. В этом случае статус и план спасения создают хороший предлог, чтобы поговорить. ПМу легко вовлечь своего руководителя, а ему - продать проблему еще наверх, если потребуется.

В маленькой компании эта бюрократия чаще не нужна. Хотя методы работают те же: Открыть/Комментировать

2023-05-11 19:10:03 ​Приглашение на интервью

Приглашение на интервью в СНГ:

- Приходите на интервью.
- Хорошо.

Приглашение в Европе: Открыть/Комментировать

2023-05-10 19:00:03 ​Как делать предсказуемые сроки поставки

Приходит к вам новый проект. Свеженький, красивый. Беклог в джире еще умещается на один экран.

Вопрос, который будет постоянно волновать вашего клиента \ босса \ инвестора - когда будет готово?

Вот что нужно сделать, чтобы на него ответить:

Выяснить скоуп.
Определить Definition of Done.
Оценить скоуп с командой и построить расписание.
Зафиксировать предыдущие три пункта в джире \ контракте \ митинг ноутсах.

Прокол на любом шаге ставит проект под удар.

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

Все н̶е̶м̶н̶о̶г̶о̶ ̶о̶х̶е̶р̶е̶л̶и̶ высказали озабоченность. Я говорю - а какой у нас DoD? Технари отвечают - разработка новых модулей архитектуры. Продакты говорят, да, все правильно. И еще миграция и удаление старого кода (+ полгода работы). Так ведь?

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

Задача менеджера здесь - найти эту подвижность и показать всем (это еще называют visibility).

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

Настройте трекинг.
Отправляйте отчеты по срокам раз в неделю.

С такой системой ваши сроки будут предсказуемыми.

————————————
#реклама_по_любви

Чтобы сроки ехали реже, нужен сильный тимлид. Это главный друг ПМа. Он и команду замотивирует, и скоуп нарежет ровно и риски увидит рано.

Классные тимлиды, многих из которых я давно читаю сам, сделали вот эту папку с каналами:
https://t.me/addlist/mDWR2gD6UEhlOWRi

Добавляйте, читайте, попадайте в сроки Открыть/Комментировать