Карта клиента
С некоторыми клиентами работать одно удовольствием. А бывает, попадаются трудные личности.
У меня, например, был один чел, который заплатил приличную сумму за проект и пропал. Дело было в Мексике, проект был для правительства, и что с челом случилось на самом деле никто не знает. Приемку мы проводили уже с другим.
В карточках выше я описал типажи клиентов и их особенности, которые доставляют нам, менеджерам, больше всего проблем. Ставь лайк, если узнал своего.
Иллюстрации: Анастасия Вишневская.
С некоторыми клиентами работать одно удовольствием. А бывает, попадаются трудные личности.
У меня, например, был один чел, который заплатил приличную сумму за проект и пропал. Дело было в Мексике, проект был для правительства, и что с челом случилось на самом деле никто не знает. Приемку мы проводили уже с другим.
В карточках выше я описал типажи клиентов и их особенности, которые доставляют нам, менеджерам, больше всего проблем. Ставь лайк, если узнал своего.
Иллюстрации: Анастасия Вишневская.
Метод освоенного объема (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, чтобы следить за попаданием в бюджет и срок.
Метод освоенного объема (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, чтобы следить за попаданием в бюджет и срок.
Критический путь
Метод критического пути - самый популярный способ оценки сроков проектов и фич. Им пользуются менеджеры в аутсорсе, продукте, геймдеве и даже на стройке. Бывает, что даже неосознанно - настолько метод легкий и интуитивный.
Суть его в том, чтобы расставить задачи в плане так, чтобы срок проекта был минимальным. Иными словами, критический путь - это самая длительная последовательность задач, которая приведет к завершению проекта.
Объясню на примере.
Допустим, мы планируем фичу “пригласи друга, получи скидку”. Чтобы ее сделать, нужно отрисовать дизайн (1 неделя), запрогать приложение (2 недели), запрогать бекенд (1 неделя) и написать пресс-релиз (2 дня).
Предположим, что все дизайны согласовывает лично СЕО, поэтому приложение мы не начинаем, пока дизайн не завершен. Пресс-релиз можно писать в любое время.
Самое минимальное время, за которое можно сделать такую фичу (ее критический путь) это: дизайн (1 неделя) + приложение (2 недели) = 3 недели.
Зачем нужен критический путь.
Во-первых, построить расписание. Чтобы это сделать, мы максимально распараллеливаем все задачи, пока это не вредит качеству и минимизируем простои между ними.
В примере выше распараллелить можно две задачи: разработку бекенда (его можно начинать одновременно с дизайном) и пресс-релиз (можно написать в любое время). Само приложение можно начинать после согласования дизайна, распараллелить эти две задачи нельзя. Значит, они обе находятся на критическом пути и их суммарная длительность, это и есть длительность всей фичи.
Во-вторых, понять какие задачи влияют на дату завершения фичи. В нашем примере это снова дизайн и приложение. Если любая из них задерживается, то задерживается и вся фича. Задержек мы не хотим, значит, за этими задачами будем следить пристальнее остальных и делать все, чтобы они закончились вовремя. Например, если в команде есть мидл фуллстек и сениор фуллстек, то приложение логичнее отдать сениору, чтобы снизить вероятность задержки.
Задержки с бекендом и пресс-релизом для нас не так важны - они не на критическом пути. Даже если они задержатся, это не повлияет на дату завершения фичи.
При работе с критическим путем главная задача менеджера не позволять ему расти, чтобы не ехало расписание.
Метод критического пути - самый популярный способ оценки сроков проектов и фич. Им пользуются менеджеры в аутсорсе, продукте, геймдеве и даже на стройке. Бывает, что даже неосознанно - настолько метод легкий и интуитивный.
Суть его в том, чтобы расставить задачи в плане так, чтобы срок проекта был минимальным. Иными словами, критический путь - это самая длительная последовательность задач, которая приведет к завершению проекта.
Объясню на примере.
Допустим, мы планируем фичу “пригласи друга, получи скидку”. Чтобы ее сделать, нужно отрисовать дизайн (1 неделя), запрогать приложение (2 недели), запрогать бекенд (1 неделя) и написать пресс-релиз (2 дня).
Предположим, что все дизайны согласовывает лично СЕО, поэтому приложение мы не начинаем, пока дизайн не завершен. Пресс-релиз можно писать в любое время.
Самое минимальное время, за которое можно сделать такую фичу (ее критический путь) это: дизайн (1 неделя) + приложение (2 недели) = 3 недели.
Зачем нужен критический путь.
Во-первых, построить расписание. Чтобы это сделать, мы максимально распараллеливаем все задачи, пока это не вредит качеству и минимизируем простои между ними.
В примере выше распараллелить можно две задачи: разработку бекенда (его можно начинать одновременно с дизайном) и пресс-релиз (можно написать в любое время). Само приложение можно начинать после согласования дизайна, распараллелить эти две задачи нельзя. Значит, они обе находятся на критическом пути и их суммарная длительность, это и есть длительность всей фичи.
Во-вторых, понять какие задачи влияют на дату завершения фичи. В нашем примере это снова дизайн и приложение. Если любая из них задерживается, то задерживается и вся фича. Задержек мы не хотим, значит, за этими задачами будем следить пристальнее остальных и делать все, чтобы они закончились вовремя. Например, если в команде есть мидл фуллстек и сениор фуллстек, то приложение логичнее отдать сениору, чтобы снизить вероятность задержки.
Задержки с бекендом и пресс-релизом для нас не так важны - они не на критическом пути. Даже если они задержатся, это не повлияет на дату завершения фичи.
При работе с критическим путем главная задача менеджера не позволять ему расти, чтобы не ехало расписание.
Границы системы
Когда приходишь в новый проект это всегда стресс. Заметил, что часть этого стресса у меня вызывает то, что я не вижу границы системы. То есть из чего состоит приложение, где оно заканчивается и где граница моей ответственности.
Сложно управлять тем, чего не понимаешь. Например, клиент говорит, “давайте в выгрузке в CRM-ку прокидывать еще страну покупателя”, а ты думаешь “о, а мы еще какую-то выгрузку делаем?”
Как понять границы системы быстрее?
Посмотреть на систему с точки зрения пользователей, фич, кода и интеграции. Подробнее про каждый пункт:
1️⃣ Начать рекомендую с типов пользователей. Их обычно не очень много и, поняв их цели, можно уже прикинуть систему. Плюс, даже если у вас простое приложение для обработки фоточек, здесь часто обнаруживаются скрытые системы, вроде админки.
2️⃣ Пройтись по всем экранам приложения. Дизайнеры часто делают карту всех экранов со стрелочками-переходами, тоже полезная вещь.
3️⃣ Выписать список сервисов и SDK, которыми пользуется прила. Здесь снова невидимые штуки вроде хостинга медиа файлов. Особенно важно найти платные, т.к. за счета от них ПМа тоже будут спрашивать.
4️⃣ Найти точки интеграции с другими командами. Бывает, что вашим сервисом для обрезки фоток пользуется соседняя команда, которая пилит свой продукт на вашей технологии. Если этот сервис упадет, то пострадают не только ваши пользователи, но и соседний продукт - к этому лучше быть готовым.
Когда понимаешь границы системы, появляется больше уверенности в собственных действиях и стресса становится в разы меньше.
А какие у вас лайфхаки?
----------
UPD: хорошие варианты из комментов:
- поговорить с командой и предыдущим менеджером;
- поработать в поддержке;
Когда приходишь в новый проект это всегда стресс. Заметил, что часть этого стресса у меня вызывает то, что я не вижу границы системы. То есть из чего состоит приложение, где оно заканчивается и где граница моей ответственности.
Сложно управлять тем, чего не понимаешь. Например, клиент говорит, “давайте в выгрузке в CRM-ку прокидывать еще страну покупателя”, а ты думаешь “о, а мы еще какую-то выгрузку делаем?”
Как понять границы системы быстрее?
Посмотреть на систему с точки зрения пользователей, фич, кода и интеграции. Подробнее про каждый пункт:
1️⃣ Начать рекомендую с типов пользователей. Их обычно не очень много и, поняв их цели, можно уже прикинуть систему. Плюс, даже если у вас простое приложение для обработки фоточек, здесь часто обнаруживаются скрытые системы, вроде админки.
2️⃣ Пройтись по всем экранам приложения. Дизайнеры часто делают карту всех экранов со стрелочками-переходами, тоже полезная вещь.
3️⃣ Выписать список сервисов и SDK, которыми пользуется прила. Здесь снова невидимые штуки вроде хостинга медиа файлов. Особенно важно найти платные, т.к. за счета от них ПМа тоже будут спрашивать.
4️⃣ Найти точки интеграции с другими командами. Бывает, что вашим сервисом для обрезки фоток пользуется соседняя команда, которая пилит свой продукт на вашей технологии. Если этот сервис упадет, то пострадают не только ваши пользователи, но и соседний продукт - к этому лучше быть готовым.
Когда понимаешь границы системы, появляется больше уверенности в собственных действиях и стресса становится в разы меньше.
А какие у вас лайфхаки?
----------
UPD: хорошие варианты из комментов:
- поговорить с командой и предыдущим менеджером;
- поработать в поддержке;
Как выбрать, что рефакторить - ч.1 оцениваем пользу
TL;DR
На техдолг нужно смотреть, как на обычные фичи - с точки зрения ценности и метрик. Альтернативный вариант, если это невозможно - посмотреть “что болит” в коде. Самым полезным для рефакторинга будет код, удовлетворяющий двум условиям: 1) высокая complexity 2) часто меняется.
————————
Спроси любого программиста, он всегда насобирает техдолга на год работы. Тут древний фреймворк, который ни разу не обновлялся, там легаси, которое уже никто в команде не понимает.
Как понять, какой рефакторинг стоит брать в работу, а что можно отложить на потом?
Как и любую задачу в беклоге, рефакторинг нужно рассматривать с точки зрения ценности.
Например, перепишем модуль рендеринга, чтобы фотки грузились быстрее. Благодаря этому, меньше пользователей будут отваливаться на долгом шаге загрузки фоток, и общая конверсия в покупку вырастет.
Ценность такой задачи легко посчитать в деньгах, она понятна бизнесу и имеет все шансы попасть в спринт. Продакт тоже доволен - задачи по рефакторингу можно сравнивать с обычными фичами и применять к ним те же процессы.
Проблема в том, что далеко не все технические задачи можно так запросто перевести в метрики и деньги...
TL;DR
На техдолг нужно смотреть, как на обычные фичи - с точки зрения ценности и метрик. Альтернативный вариант, если это невозможно - посмотреть “что болит” в коде. Самым полезным для рефакторинга будет код, удовлетворяющий двум условиям: 1) высокая complexity 2) часто меняется.
————————
Спроси любого программиста, он всегда насобирает техдолга на год работы. Тут древний фреймворк, который ни разу не обновлялся, там легаси, которое уже никто в команде не понимает.
Как понять, какой рефакторинг стоит брать в работу, а что можно отложить на потом?
Как и любую задачу в беклоге, рефакторинг нужно рассматривать с точки зрения ценности.
Например, перепишем модуль рендеринга, чтобы фотки грузились быстрее. Благодаря этому, меньше пользователей будут отваливаться на долгом шаге загрузки фоток, и общая конверсия в покупку вырастет.
Ценность такой задачи легко посчитать в деньгах, она понятна бизнесу и имеет все шансы попасть в спринт. Продакт тоже доволен - задачи по рефакторингу можно сравнивать с обычными фичами и применять к ним те же процессы.
Проблема в том, что далеко не все технические задачи можно так запросто перевести в метрики и деньги...
Как выбрать, что рефакторить - ч.2 анализируем код
Представьте, что ваш стартап пережил фазу бурного роста и СТО решил, что пора побить монолит на сервисы поменьше. Сделал классную презу, заручился поддержкой СПО и тимлидов и получил зеленый свет. С чего начать такой проект? Какой сервис взять в работу первым? Где наибольшая ценность от рефакторинга?
Один из вариантов - посмотреть на техдог с точки зрения файлов. Все наше приложение состоит из файлов, в которых хранятся экраны, API, интеграции и конфигурации. Чем больше фич, тем больше кода и тем больше файлов. В небольшом приложении по занятию йогой может быть, скажем, 300 файлов.
Чтобы определить скоуп рефакторинга, посмотрим на два параметра: сложность и частоту изменения файлов.
Сложность - это объем логики принятия решений в функциях исходного кода. Ее можно узнать, подключив сервисы вроде CodeScense или SonarQube. И хотя существуют различные способы, как ее подсчитать, самый популярный из них - цикломатическую сложность - придумали еще в 70-х и используют до сих пор.
Когда программисты пишут новую фичу и задействуют в ней файлы с низкой сложностью, это не вызывает у них раздражения. Короткие файлы легко читать и изменять, в них не запутаешься. Но когда в файле уже больше 300 строк, добавить 5 новых и ничего не сломать уже проблематично. Раздражать программистов мы не хотим, поэтому нас интересуют файлы с высокой сложностью.
Окей, допустим, таких файлов 100 из 300. Но мы же не будем с ходу переписывать 30% проекта. Какие из них прям самые невыносимые?
Здесь мы смотрим на второй параметр - изменяемость. Она показывает, как часто программисты вносят изменения в файлы, когда пишут новые фичи или исправляют баги.
Функционал вроде Настроек, Логаута, Смены пароль, меняются редко. Даже если в нем высокая сложность, его обслуживание стоит недорого. А раз так, то и снижать эту стоимость нет смысла. Про такой код говорят “Работает - не трогай”.
И наоборот, в фиче Урок Йоги продакт постоянно ставит новые эксперименты. Если в ней высокая complexity, то с каждым юзкейсом программистам все труднее и труднее писать новый код и менять растущие в объеме файлы. Это выливается в растущие оценки и долгий поиск багов.
Такие фичи стоит приоритезировать для рефакторинга в первую очередь.
————————
Недавно на работе мы думали, как определить самую важную часть скоупа для технического проекта длиной в несколько лет. Попробовали описанную технику (нашли ее здесь) и результат нас удовлетворил. Оказалось, что найденные файлы совпали с тем, что программисты субъективно назвали самой важной частью проекта. А это хороший знак.
Представьте, что ваш стартап пережил фазу бурного роста и СТО решил, что пора побить монолит на сервисы поменьше. Сделал классную презу, заручился поддержкой СПО и тимлидов и получил зеленый свет. С чего начать такой проект? Какой сервис взять в работу первым? Где наибольшая ценность от рефакторинга?
Один из вариантов - посмотреть на техдог с точки зрения файлов. Все наше приложение состоит из файлов, в которых хранятся экраны, API, интеграции и конфигурации. Чем больше фич, тем больше кода и тем больше файлов. В небольшом приложении по занятию йогой может быть, скажем, 300 файлов.
Чтобы определить скоуп рефакторинга, посмотрим на два параметра: сложность и частоту изменения файлов.
Сложность - это объем логики принятия решений в функциях исходного кода. Ее можно узнать, подключив сервисы вроде CodeScense или SonarQube. И хотя существуют различные способы, как ее подсчитать, самый популярный из них - цикломатическую сложность - придумали еще в 70-х и используют до сих пор.
Когда программисты пишут новую фичу и задействуют в ней файлы с низкой сложностью, это не вызывает у них раздражения. Короткие файлы легко читать и изменять, в них не запутаешься. Но когда в файле уже больше 300 строк, добавить 5 новых и ничего не сломать уже проблематично. Раздражать программистов мы не хотим, поэтому нас интересуют файлы с высокой сложностью.
Окей, допустим, таких файлов 100 из 300. Но мы же не будем с ходу переписывать 30% проекта. Какие из них прям самые невыносимые?
Здесь мы смотрим на второй параметр - изменяемость. Она показывает, как часто программисты вносят изменения в файлы, когда пишут новые фичи или исправляют баги.
Функционал вроде Настроек, Логаута, Смены пароль, меняются редко. Даже если в нем высокая сложность, его обслуживание стоит недорого. А раз так, то и снижать эту стоимость нет смысла. Про такой код говорят “Работает - не трогай”.
И наоборот, в фиче Урок Йоги продакт постоянно ставит новые эксперименты. Если в ней высокая complexity, то с каждым юзкейсом программистам все труднее и труднее писать новый код и менять растущие в объеме файлы. Это выливается в растущие оценки и долгий поиск багов.
Такие фичи стоит приоритезировать для рефакторинга в первую очередь.
————————
Недавно на работе мы думали, как определить самую важную часть скоупа для технического проекта длиной в несколько лет. Попробовали описанную технику (нашли ее здесь) и результат нас удовлетворил. Оказалось, что найденные файлы совпали с тем, что программисты субъективно назвали самой важной частью проекта. А это хороший знак.
Быстрое ревью документов: как в Амазоне
Кто хоть раз просил CPO поревьювать документ с новой инициативой, знает, что напомнить о просьбе придется минимум пару раз. Если компания большая, и стейкхолдеров у инициативы много, на простое ревью легко уходит 2-3 календарные недели. Потому что у каждого сейка таких просьб по нескольку в неделю.
Увидел новую технику, как получить фидбек на документ быстро:
➡ собираешь всех на мит
➡ 5 минут рассказываешь про инициативу
➡ все садятся читать и комментировать док, выключают камеру
➡ когда прочитали, включают камеру обратно
➡ оставшееся время проходитесь по комментариям, спорите, определяете следующие шаги.
В таком варианте ты как бы бронируешь время человека под ревью, добавляя инвайт в его календарь. В итоге результат у тебя на руках всего за час, а времени потрачено плюс-минус столько же. Обсуждение тоже идет хорошо, потому что народ загрузил инициативу себе в оперативную память.
Вариант эффективный, но лишняя энергия все равно уходит. Пока спросишь всех, как прошли выходные и какие планы на отпуск уже устанешь улыбаться.
Поэтому мне больше нравится гибридный вариант - каждый обязуется прочитать док перед встречей, а собираетесь вы только чтобы принять решение.
Кто хоть раз просил CPO поревьювать документ с новой инициативой, знает, что напомнить о просьбе придется минимум пару раз. Если компания большая, и стейкхолдеров у инициативы много, на простое ревью легко уходит 2-3 календарные недели. Потому что у каждого сейка таких просьб по нескольку в неделю.
Увидел новую технику, как получить фидбек на документ быстро:
➡ собираешь всех на мит
➡ 5 минут рассказываешь про инициативу
➡ все садятся читать и комментировать док, выключают камеру
➡ когда прочитали, включают камеру обратно
➡ оставшееся время проходитесь по комментариям, спорите, определяете следующие шаги.
В таком варианте ты как бы бронируешь время человека под ревью, добавляя инвайт в его календарь. В итоге результат у тебя на руках всего за час, а времени потрачено плюс-минус столько же. Обсуждение тоже идет хорошо, потому что народ загрузил инициативу себе в оперативную память.
Вариант эффективный, но лишняя энергия все равно уходит. Пока спросишь всех, как прошли выходные и какие планы на отпуск уже устанешь улыбаться.
Поэтому мне больше нравится гибридный вариант - каждый обязуется прочитать док перед встречей, а собираетесь вы только чтобы принять решение.
Как оценки увеличиваются х3 на пустом месте (пример)
Недавно оценивал большой проект. Чтобы его сделать, надо обновить десятки сервисов, принадлежащие 12 командам.
При этом проект типовой, в компании такой уже делали несколько раз (представьте поставку б2б коробки клиенту по чеклисту). Тогда одна спецназ-команда сама делала апдейты во всех сервисах. Но на этот раз решили их не привлекать и отдать работу владельцам сервисов. Они-то свой домен хорошо знают, должно даже быстрее получиться.
Ну-ну. В итоге суммарная оценка 12 команд - 50 инженереных недель. А оценка спецназа - 18!
Работа одна и та же, а разница в 3 раза, откуда такая разбежка? Причины, на мой взгляд, такие:
1\ Повторить проект, который ты делал вчера с той же командой, проще за счет проектных знаний и набитых шишек, чем сделать новый. Здесь ты выигрываешь даже у команды, которая по факту владеет сервисом, потому что ты его менял только что, а они когда-то там.
2\ Чем меньше людей в проекте, тем меньше времени уходит на коммуникацию и тем быстрее идет работа;
3\ То же и с синхронизацией. Опытные менеджеры всегда закладывают доп риски, если предстоит работать с другими командами: пока запланируешь, договоришься о формате API, потестируешь общий флоу. Тут оценки значительно толстеют.
Недавно оценивал большой проект. Чтобы его сделать, надо обновить десятки сервисов, принадлежащие 12 командам.
При этом проект типовой, в компании такой уже делали несколько раз (представьте поставку б2б коробки клиенту по чеклисту). Тогда одна спецназ-команда сама делала апдейты во всех сервисах. Но на этот раз решили их не привлекать и отдать работу владельцам сервисов. Они-то свой домен хорошо знают, должно даже быстрее получиться.
Ну-ну. В итоге суммарная оценка 12 команд - 50 инженереных недель. А оценка спецназа - 18!
Работа одна и та же, а разница в 3 раза, откуда такая разбежка? Причины, на мой взгляд, такие:
1\ Повторить проект, который ты делал вчера с той же командой, проще за счет проектных знаний и набитых шишек, чем сделать новый. Здесь ты выигрываешь даже у команды, которая по факту владеет сервисом, потому что ты его менял только что, а они когда-то там.
2\ Чем меньше людей в проекте, тем меньше времени уходит на коммуникацию и тем быстрее идет работа;
3\ То же и с синхронизацией. Опытные менеджеры всегда закладывают доп риски, если предстоит работать с другими командами: пока запланируешь, договоришься о формате API, потестируешь общий флоу. Тут оценки значительно толстеют.
Абстрактные задачи -> сениорность
Наблюдая за работой топ менеджеров (директоры, випи), восхищаюсь их умением работать с неопределенностью и абстрактными задачами.
Например, силевел говорит: "есть идея запустить проект Х, посчитай, что для этого нужно".
Я бы на этом месте начал мучить всех вопросами: а на каком рынке, а какой командой, а какие критерии успешного запуска. Но прикол в том, что у силевела нет времени вникать в эти вопросы и разжевывать ответы. Они ожидают, что ты уже взрослый-сениорный, сам разберешься в каком бизнесе мы работаем и сделаешь нужные выводы. А к нам приходи только с результатом. Поэтому топы просто делают кучу допущений исходя их своего прошлого опыта и здравого смысла и берут ответстственность на себя 😱
Если тебя ставят на проект с проработанным беклогом, устоявшейся командой, где мало рисков и нужно заделиверить 200 понятных СП за полгода, то для перехода на следующий менеджерский левел этого может не хватить.
Чем более абстрактные задачи ты можешь выполнять с хорошим качеством, чем больше неопределенности выдерживаешь, тем более сениорным спецом считаешься.
Наблюдая за работой топ менеджеров (директоры, випи), восхищаюсь их умением работать с неопределенностью и абстрактными задачами.
Например, силевел говорит: "есть идея запустить проект Х, посчитай, что для этого нужно".
Я бы на этом месте начал мучить всех вопросами: а на каком рынке, а какой командой, а какие критерии успешного запуска. Но прикол в том, что у силевела нет времени вникать в эти вопросы и разжевывать ответы. Они ожидают, что ты уже взрослый-сениорный, сам разберешься в каком бизнесе мы работаем и сделаешь нужные выводы. А к нам приходи только с результатом. Поэтому топы просто делают кучу допущений исходя их своего прошлого опыта и здравого смысла и берут ответстственность на себя 😱
Если тебя ставят на проект с проработанным беклогом, устоявшейся командой, где мало рисков и нужно заделиверить 200 понятных СП за полгода, то для перехода на следующий менеджерский левел этого может не хватить.
Чем более абстрактные задачи ты можешь выполнять с хорошим качеством, чем больше неопределенности выдерживаешь, тем более сениорным спецом считаешься.
#реклама_по_любви
Три года назад я проходил курс Замесина по кастдеву (друзья подарили на др). После каждого урока нужно было что-то делать на реальной работе, например, поделить своих клиентов на сегменты или узнать, как они решали свою проблему раньше.
На мой взгляд, это лучший формат обучения, когда ты А. оттачиваешь один конкретный навык и Б. сразу пробуешь его в работе. Сегодня я с удовольствием рекламирую курс Вани, который за это время, уверен, стал еще лучше.
------
Чему учит Ваня
→ Даёт фундаментальное понимание как делать продукт, из которого вытекает решения абсолютно всех продуктовых задач, JTBD — то самое решение.
→ Методология Вани помогает учиться: выходить из конкуренции, растить средний чек, конверсию и возвращаемость, выводить продукт на рынок, находить сегменты и гипотезы ценности.
→ Ваня нашёл ответ про то, как находить и пробуждать спящие работы, что такое базовое качество.
→ На тренинге живые воркшопы и практики, а также есть дополнительные материалы, квизы, гайды JTBD-интервью. Всё собрано в личном кабинете. На вопросы отвечает Ваня, а также исследователи и кураторы проекта.
→ Приятная новость для тех, кто когда-либо проходил тренинг или будет проходить в будущем — все материалы останутся у вас навсегда, а ещё будут обновляться до самых актуальных. Все подробности всегда есть в ТГ: @zamesin
Тренинг — большой проект Вани, он непрерывно работает над его развитием. На сегодня тренинг прошли больше 8 500 человек, а средняя оценка ценности 9,2.
🔗 Узнать подробнее о тренинге можно по ссылке
Три года назад я проходил курс Замесина по кастдеву (друзья подарили на др). После каждого урока нужно было что-то делать на реальной работе, например, поделить своих клиентов на сегменты или узнать, как они решали свою проблему раньше.
На мой взгляд, это лучший формат обучения, когда ты А. оттачиваешь один конкретный навык и Б. сразу пробуешь его в работе. Сегодня я с удовольствием рекламирую курс Вани, который за это время, уверен, стал еще лучше.
------
Чему учит Ваня
→ Даёт фундаментальное понимание как делать продукт, из которого вытекает решения абсолютно всех продуктовых задач, JTBD — то самое решение.
→ Методология Вани помогает учиться: выходить из конкуренции, растить средний чек, конверсию и возвращаемость, выводить продукт на рынок, находить сегменты и гипотезы ценности.
→ Ваня нашёл ответ про то, как находить и пробуждать спящие работы, что такое базовое качество.
→ На тренинге живые воркшопы и практики, а также есть дополнительные материалы, квизы, гайды JTBD-интервью. Всё собрано в личном кабинете. На вопросы отвечает Ваня, а также исследователи и кураторы проекта.
→ Приятная новость для тех, кто когда-либо проходил тренинг или будет проходить в будущем — все материалы останутся у вас навсегда, а ещё будут обновляться до самых актуальных. Все подробности всегда есть в ТГ: @zamesin
Тренинг — большой проект Вани, он непрерывно работает над его развитием. На сегодня тренинг прошли больше 8 500 человек, а средняя оценка ценности 9,2.
🔗 Узнать подробнее о тренинге можно по ссылке
Тренинг Вани Замесина по Advanced JTBD
Как делать продукт: тренинг Вани Замесина по Advanced JTBD
Получи ключевые навыки создания продуктов, отстройся от конкурентов уникальной ценностью и упакуй продукт в маркетинге
Нужны ли тестировщики?
Большие компании часто работают без тестировщиков. За качество отвечают сами программисты. У такого подхода есть много плюсов: ответственность за качество не размывается, легче планировать проекты, меньше cycle time.
Есть, конечно, и минусы, главный из которых - дорого. Как раз на этом фоне выгодно выделяются мануальщики. Они хороши на старте продукта, когда ручное тестирование дешевле автоматизации.
Пока продукт ищет маркет фит, фичи в нем постоянно меняются. Завтра вы можете пивотнуться и выкинуть половину кода, а послезавтра закрыться. С такой неопределенностью не всегда есть смысл с первого дня вкладываться в высокое качество. Зрелые инженерные решения тянут много времени и в такой среде порой не окупаются.
На первом этапе важнее быстро запускать эксперименты и валидировать гипотезы методом “из желудей и спичек”. И пока в продукте 3 фичи и 50 пользователей, дешевле нанять тестировщика, который будет их прокликивать вручную.
Когда маркет фит найден, ситуация меняется. С ростом продукта растут и требования к качеству.
То, на что раньше даже тикет не заводили, теперь может быть high priority. На большом скейле даже 0.5% конверсии стоит кучу денег. Компания начинает вкладывать в качество и думать, как находить такие баги раньше, а не просто чинить их последствия.
Подход просто нанять больше ручных тестеров плохо масштабируется. Когда фич уже 30, только чтобы выпустить новый релиз, нужно потратить неделю на регрессию всего приложения. Бизнес от этого не в восторге, и это отличный момент, чтобы продать автоматизацию.
———
Узнать о том, как большие компании работают с качеством можно в выпуске ПМ совета с Principal Quality Engineer из Атлассиан (нужна подписка).
Большие компании часто работают без тестировщиков. За качество отвечают сами программисты. У такого подхода есть много плюсов: ответственность за качество не размывается, легче планировать проекты, меньше cycle time.
Есть, конечно, и минусы, главный из которых - дорого. Как раз на этом фоне выгодно выделяются мануальщики. Они хороши на старте продукта, когда ручное тестирование дешевле автоматизации.
Пока продукт ищет маркет фит, фичи в нем постоянно меняются. Завтра вы можете пивотнуться и выкинуть половину кода, а послезавтра закрыться. С такой неопределенностью не всегда есть смысл с первого дня вкладываться в высокое качество. Зрелые инженерные решения тянут много времени и в такой среде порой не окупаются.
На первом этапе важнее быстро запускать эксперименты и валидировать гипотезы методом “из желудей и спичек”. И пока в продукте 3 фичи и 50 пользователей, дешевле нанять тестировщика, который будет их прокликивать вручную.
Когда маркет фит найден, ситуация меняется. С ростом продукта растут и требования к качеству.
То, на что раньше даже тикет не заводили, теперь может быть high priority. На большом скейле даже 0.5% конверсии стоит кучу денег. Компания начинает вкладывать в качество и думать, как находить такие баги раньше, а не просто чинить их последствия.
Подход просто нанять больше ручных тестеров плохо масштабируется. Когда фич уже 30, только чтобы выпустить новый релиз, нужно потратить неделю на регрессию всего приложения. Бизнес от этого не в восторге, и это отличный момент, чтобы продать автоматизацию.
———
Узнать о том, как большие компании работают с качеством можно в выпуске ПМ совета с Principal Quality Engineer из Атлассиан (нужна подписка).
PMP экзамен (1/6) - требования, стоимость, можно ли сдать из РБ и РФ
Project Management Professional (PMP) - это сертификация по управлению проектами. Ее выдает американский Project Management Institute (PMI), основанный еще в 1969. Это, пожалуй, самый узнаваемый сертификат для проджектов в мире.
Чтобы получить PMP, нужно пройти тест. Он состоит из 180 вопросов, на которые нужно ответить за 230 минут. Официального порога сдачи нет, но говорят, что он около 70%.
Для сравнения, в сертификации на скрам мастера порог сдачи 85%. Несмотря на то что проходной выше, PSM показался мне значительно легче, чем PMP, но об этом в другом посте.
Чтобы допуститься до экзамена, нужно иметь:
⁃ 3 года опыта в ПМ, если есть высшее образование;
⁃ 5 лет опыта в ПМ, если его нет.
Опыт и образование подтверждается, когда регистрируешься на экзамен. В анкете подробно описываешь каждую работу, что ты делал как ПМ и т.д.
После подачи анкету могут отправить на аудит, так случилось с моей. PMI написал моему текущему и прошлому менеджерам и попросил подтвердить данные в анкете. Контракт и трудовую не спрашивали, всего лишь нужно было поставить птичку “Рома не врет, я отвечаю” и на этом аудит закончился.
Кроме опыта работы, для допуска к экзамену нужно набрать 35 часов обучения от одобренных тренеров. На рынке их немало, формально эти часы закроет любой курс на udemi с пометкой PDU contract hours.
Сдать экзамен стоит 550$ + минимум 100 потянет udemi, поэтому минимальная сумма - 650$. Если не сдашь с первого раза, то каждая следующая попытка стоит еще 275$. У меня так незаметно набежало аж 1,5К, благо в Германии затраты на обучение по работе можно вернуть в налоги в конце года.
В Беларуси PMP есть у43 проджектов, в Украине - у 931 , в России - у 650 . В нескольких статьях я встречал цифры в 2-3 раза выше. Думаю, это связано с тем, что с началом войны PMP приостановил выдачу новых и продление старых сертификатов (его дают на 3 года). Официально, пройти тест, проживая в РБ и РФ, сейчас нельзя.
Некоторых это не останавливает, и люди сдают через VPN. Другие, специально выезжают в соседние страны, чтобы пройти экзамен. PMI проверяет именно локацию (иногда просят доказать), поэтому сам по себе бел. или рф паспорт не является запретом для сдачи.
В следующем посте расскажу, как и по каким материалам готовился.
Project Management Professional (PMP) - это сертификация по управлению проектами. Ее выдает американский Project Management Institute (PMI), основанный еще в 1969. Это, пожалуй, самый узнаваемый сертификат для проджектов в мире.
Чтобы получить PMP, нужно пройти тест. Он состоит из 180 вопросов, на которые нужно ответить за 230 минут. Официального порога сдачи нет, но говорят, что он около 70%.
Для сравнения, в сертификации на скрам мастера порог сдачи 85%. Несмотря на то что проходной выше, PSM показался мне значительно легче, чем PMP, но об этом в другом посте.
Чтобы допуститься до экзамена, нужно иметь:
⁃ 3 года опыта в ПМ, если есть высшее образование;
⁃ 5 лет опыта в ПМ, если его нет.
Опыт и образование подтверждается, когда регистрируешься на экзамен. В анкете подробно описываешь каждую работу, что ты делал как ПМ и т.д.
После подачи анкету могут отправить на аудит, так случилось с моей. PMI написал моему текущему и прошлому менеджерам и попросил подтвердить данные в анкете. Контракт и трудовую не спрашивали, всего лишь нужно было поставить птичку “Рома не врет, я отвечаю” и на этом аудит закончился.
Кроме опыта работы, для допуска к экзамену нужно набрать 35 часов обучения от одобренных тренеров. На рынке их немало, формально эти часы закроет любой курс на udemi с пометкой PDU contract hours.
Сдать экзамен стоит 550$ + минимум 100 потянет udemi, поэтому минимальная сумма - 650$. Если не сдашь с первого раза, то каждая следующая попытка стоит еще 275$. У меня так незаметно набежало аж 1,5К, благо в Германии затраты на обучение по работе можно вернуть в налоги в конце года.
В Беларуси PMP есть у
Некоторых это не останавливает, и люди сдают через VPN. Другие, специально выезжают в соседние страны, чтобы пройти экзамен. PMI проверяет именно локацию (иногда просят доказать), поэтому сам по себе бел. или рф паспорт не является запретом для сдачи.
В следующем посте расскажу, как и по каким материалам готовился.
PMP экзамен (2/6) - Материалы для подготовки
Моя подготовка выглядела так:
🏋️♀️Прошел курс Ивана Селиховкина - 1 месяц
🏋️♀️Прошел 6 полных тестов и с десяток мелких - 1,5 месяца
😵Первая попытка - не сдал
🏋️♀️Прошел еще 5 полных тестов и с десяток мелких - 1,5 месяца
🏋️♀️Параллельно прочитал книгу PMP Exam Prep - 1,5 месяца
🥇Вторая попытка - сдал
По будням я изучал теорию и делал короткие тесты на 20 или 30 вопросов. По выходным делал полный тест - 180 вопросов за 4 часа. В субботу сдавал, а в воскресенье разбирал ответы. В сумме уходило около 12 часов в неделю.
Расскажу подробнее про каждый пункт.
Курс Ивана Селиховкина я взял для изучения теории, и потому, что для допуска к экзамену нужны часы от аккредитованного тренера.
Как материалы для подготовки к PMP, он закрыл ~90% необходимых знаний лично для меня. Я думал, что будет 100%, и удивился, когда увидел новые определения, гоняя тесты. Справедливости ради покрыть все 100%, наверное, сложно, т.к. экзамен постоянно обновляется. Например, в реальном тесте я впервые увидел термин Dropped Baton (тот самый вопрос). Ни о каких батонах ни один другой источник раньше не упоминал.
Без привязки к PMP курс хорошо зайдет как база джунам и ранним мидлам, кому не хватает структурных знаний в управлении проектами. Здесь тонны полезного контента для начинающего менеджера: критический путь, метод освоенного объема, типы контрактов - это маст хэв база. Если вы работаете менеджером пару лет где-нибудь в студии, без налаженных процессов и наставника, этот курс вас точно бустанет.
Да, качество видеозаписи здесь ниже того, к чему мы привыкли на ютубе. Местами есть описки в слайдах. С другой стороны, за весьма скромные деньги (на момент выхода поста курс стоит $290) вы покупаете 20-летний опыт эксперта в индустрии. Это не чувак, который 3 года назад пришел в ИТ и продает переписанный контент из интернета за 999$ через красивый лендинг.
Кроме теории в курсе есть 2 полных теста по 180 вопросов. Это единственный материал на русском в моем списке, все остальные будут на английском.
Моя подготовка выглядела так:
🏋️♀️Прошел курс Ивана Селиховкина - 1 месяц
🏋️♀️Прошел 6 полных тестов и с десяток мелких - 1,5 месяца
😵Первая попытка - не сдал
🏋️♀️Прошел еще 5 полных тестов и с десяток мелких - 1,5 месяца
🏋️♀️Параллельно прочитал книгу PMP Exam Prep - 1,5 месяца
🥇Вторая попытка - сдал
По будням я изучал теорию и делал короткие тесты на 20 или 30 вопросов. По выходным делал полный тест - 180 вопросов за 4 часа. В субботу сдавал, а в воскресенье разбирал ответы. В сумме уходило около 12 часов в неделю.
Расскажу подробнее про каждый пункт.
Курс Ивана Селиховкина я взял для изучения теории, и потому, что для допуска к экзамену нужны часы от аккредитованного тренера.
Как материалы для подготовки к PMP, он закрыл ~90% необходимых знаний лично для меня. Я думал, что будет 100%, и удивился, когда увидел новые определения, гоняя тесты. Справедливости ради покрыть все 100%, наверное, сложно, т.к. экзамен постоянно обновляется. Например, в реальном тесте я впервые увидел термин Dropped Baton (тот самый вопрос). Ни о каких батонах ни один другой источник раньше не упоминал.
Без привязки к PMP курс хорошо зайдет как база джунам и ранним мидлам, кому не хватает структурных знаний в управлении проектами. Здесь тонны полезного контента для начинающего менеджера: критический путь, метод освоенного объема, типы контрактов - это маст хэв база. Если вы работаете менеджером пару лет где-нибудь в студии, без налаженных процессов и наставника, этот курс вас точно бустанет.
Да, качество видеозаписи здесь ниже того, к чему мы привыкли на ютубе. Местами есть описки в слайдах. С другой стороны, за весьма скромные деньги (на момент выхода поста курс стоит $290) вы покупаете 20-летний опыт эксперта в индустрии. Это не чувак, который 3 года назад пришел в ИТ и продает переписанный контент из интернета за 999$ через красивый лендинг.
Кроме теории в курсе есть 2 полных теста по 180 вопросов. Это единственный материал на русском в моем списке, все остальные будут на английском.
Prepcast - классный тренажер, чтобы погонять тесты после изучения теории. За 150 баксов дают 4 полных теста и с десяток тестов поменьше. Из всех тестов, которые я проходил, здесь были максимально подробные объяснения. Это очень помогает натренировать ум на логику экзамена. Более того, если не согласен с ответом или остались вопросы, можно прямо в тесте написать фидбек и получить ответ от эксперта - пушка!
Из минусов показалось, что в реальном тесте больше сложных вопросов. В препкасте они тоже есть, но здесь их, скажем 20%, а в реальном тесте 40%. Английский здесь тоже более человеческий - в реальном тесте формулировки местами менее понятные.
После тестов препкаста я пошел сдавать экзамен и не сдал, но не спешите с выводами, здесь еще будет свой плот твист.
Книга PMP Exam Prep. После проваленной попытки я решил подкачать теорию. Многие советовали книгу Риты. Из нее особо ничего нового я не узнал, все то же самое было в курсе Ивана. Единственный плюс - лучше запомнил термины на английском.
Если будете покупать книгу, обратите внимание на издание, последнее на сегодня 11ое.
PMI Study Hall - это тренажер от самого PMI, которые принимают экзамен. Всего за 70$ дают 5 полных тестов и 20 маленьких.
Объяснения ответов здесь тоже есть, но большая их часть абсолютно бестолковые. Например, могут сказать так: “Ответ Б - это не лучший вариант”. Или: “Объяснение читайте в статье Х или книге У”. Ну спасибо хоть не надо к вам в офис ехать за объяснением. От таких вопросов мало толку, потому что без объяснения ты ничему не учишься, проходя тест.
Обратная связь тоже есть, но на десяток вопросов, в отличае от prepcast, мне ни разу никто не ответил, хоть я и старался не душнить.
Тем не менее у Study Hall есть один жирный плюс: его вопросы настолько жедебильные сложные, как и реальный тест. Язык и формулировки тоже схожие. Это гораздо точнее отражает то, что вы увидите на экзамене. Поэтому рекомендую его, пусть через боль и страдание.
В следующем посте расскажу про сам тест и вопросы.
——————
На гифке показана фича “Chill out and take a break” в PMI Study Hall. Интересно узнать, как продакт питчил эту фичу руководству и влияет ли она на какую-то метрику.
Из минусов показалось, что в реальном тесте больше сложных вопросов. В препкасте они тоже есть, но здесь их, скажем 20%, а в реальном тесте 40%. Английский здесь тоже более человеческий - в реальном тесте формулировки местами менее понятные.
После тестов препкаста я пошел сдавать экзамен и не сдал, но не спешите с выводами, здесь еще будет свой плот твист.
Книга PMP Exam Prep. После проваленной попытки я решил подкачать теорию. Многие советовали книгу Риты. Из нее особо ничего нового я не узнал, все то же самое было в курсе Ивана. Единственный плюс - лучше запомнил термины на английском.
Если будете покупать книгу, обратите внимание на издание, последнее на сегодня 11ое.
PMI Study Hall - это тренажер от самого PMI, которые принимают экзамен. Всего за 70$ дают 5 полных тестов и 20 маленьких.
Объяснения ответов здесь тоже есть, но большая их часть абсолютно бестолковые. Например, могут сказать так: “Ответ Б - это не лучший вариант”. Или: “Объяснение читайте в статье Х или книге У”. Ну спасибо хоть не надо к вам в офис ехать за объяснением. От таких вопросов мало толку, потому что без объяснения ты ничему не учишься, проходя тест.
Обратная связь тоже есть, но на десяток вопросов, в отличае от prepcast, мне ни разу никто не ответил, хоть я и старался не душнить.
Тем не менее у Study Hall есть один жирный плюс: его вопросы настолько же
В следующем посте расскажу про сам тест и вопросы.
——————
На гифке показана фича “Chill out and take a break” в PMI Study Hall. Интересно узнать, как продакт питчил эту фичу руководству и влияет ли она на какую-то метрику.
PMP экзамен (3/6) - Как проходит тест
Тест длится 3 часа 50 минут, за это время надо ответить на 180 вопросов. Есть 2 перерыва по 10 минут. Высидеть 4 часа сложно, поэтому советую хотя бы раз попробовать сдать полный тренировочный тест.
Получается около 1 минуты 15 секунд на вопрос. На деле этого мало, и даже на второй попытке последние 3-4 вопроса я ответил наугад, т.к. время заканчивалось.
90% теста - это вопросы с одним правильным ответом из 4 вариантов. Еще в 10% нужно выбрать 2 или 3 варианта из 5-6. Если выбрал хотя бы один неправильный, то не засчитывается весь ответ. Несколько вопросов предлагали соединить 5 определений с 5 формулировками, вот так.
Я немного переживал, что проходил курс по PMBOK 6, а в 7-ой версии они перелопатили всю структуру процессов. Оказалось, что на тест это никак не влияет. И тренировочные, и реальный тестs не спрашивали специфики 7-ого PMBOK.
Тест можно сдавать в специальном центре, вот тут человек хорошо описал оффлайн опыт. Оба раза я сдавал дома.
Во время теста у тебя включена камера, микрофон и шаринг экрана. За всем этим наблюдает специальный человек - проктор - который смотрит, чтобы ты не списывал. Проктор - не сотрудник PMI, это стороняя фирма, которую нанимают университеты, чтобы обеспечивать честную сдачу экзамена.
Во время экзамена нельзя шуметь, разговаривать и даже бурчать под нос! Все время нужно быть в поле зрения камеры, чтобы проктор тебя видел. Еще нельзя сдавать в наушниках, и второй раз я сдавал в берушах, потому что без шумодава не могу долго фокусироваться. А беруши не видно, поэтому даже не стал спрашивать, можно ли.
Пустой лист бумаги и ручку для заметок тоже не разрешают брать. В тесте есть рисовалка, в которой можно делать пометки или писать формулы, но я этим не пользовался. Единственная реально полезная фича - зачеркнуть ответ, который считаешь неправильным.
В первый раз я забыл подключить зарядку, и мой ноут сел. Потеряв 5 минут, я переподключился и, на удивление все восстановилось бесшовно. Второй раз, сам тест подвис на две минуты, но потом все также вернулось само собой.
В следующем посте расскажу про вопросы и темы из теста.
Тест длится 3 часа 50 минут, за это время надо ответить на 180 вопросов. Есть 2 перерыва по 10 минут. Высидеть 4 часа сложно, поэтому советую хотя бы раз попробовать сдать полный тренировочный тест.
Получается около 1 минуты 15 секунд на вопрос. На деле этого мало, и даже на второй попытке последние 3-4 вопроса я ответил наугад, т.к. время заканчивалось.
90% теста - это вопросы с одним правильным ответом из 4 вариантов. Еще в 10% нужно выбрать 2 или 3 варианта из 5-6. Если выбрал хотя бы один неправильный, то не засчитывается весь ответ. Несколько вопросов предлагали соединить 5 определений с 5 формулировками, вот так.
Я немного переживал, что проходил курс по PMBOK 6, а в 7-ой версии они перелопатили всю структуру процессов. Оказалось, что на тест это никак не влияет. И тренировочные, и реальный тестs не спрашивали специфики 7-ого PMBOK.
Тест можно сдавать в специальном центре, вот тут человек хорошо описал оффлайн опыт. Оба раза я сдавал дома.
Во время теста у тебя включена камера, микрофон и шаринг экрана. За всем этим наблюдает специальный человек - проктор - который смотрит, чтобы ты не списывал. Проктор - не сотрудник PMI, это стороняя фирма, которую нанимают университеты, чтобы обеспечивать честную сдачу экзамена.
Во время экзамена нельзя шуметь, разговаривать и даже бурчать под нос! Все время нужно быть в поле зрения камеры, чтобы проктор тебя видел. Еще нельзя сдавать в наушниках, и второй раз я сдавал в берушах, потому что без шумодава не могу долго фокусироваться. А беруши не видно, поэтому даже не стал спрашивать, можно ли.
Пустой лист бумаги и ручку для заметок тоже не разрешают брать. В тесте есть рисовалка, в которой можно делать пометки или писать формулы, но я этим не пользовался. Единственная реально полезная фича - зачеркнуть ответ, который считаешь неправильным.
В первый раз я забыл подключить зарядку, и мой ноут сел. Потеряв 5 минут, я переподключился и, на удивление все восстановилось бесшовно. Второй раз, сам тест подвис на две минуты, но потом все также вернулось само собой.
В следующем посте расскажу про вопросы и темы из теста.