Как стать автором
Обновить
10
0
Андреi @iPR

Аналитик

Отправить сообщение
Идея замены резюме портфолио замечательная. Резюме проще всего обновлять. Портфолио нужно всегда держать в тренде. Мотёрый кадровик (специалист по резюме) конечно не станет читать ваше портфолио, так как он не привык к подобному формату презентации персонала, для него будет важна сухая статистика: образование, стаж работы, сертификаты. Если на фоне общей статистики вы будете выделяться согласно его критериям, то он отметит вас. Единственным, что мне показалось, неудачным моментом — это то, что с первого раза не известен объём портфолио. Думаешь, что будет страниц 11, а на самом деле их 15. Как правило, фрилансеров нанимают те кто желает съэкономить, поэтому можно добавить пункт 6. Резюме или вообще убрать страницы с 12 по 15.
Я бы еще добавил в самом начала фразу типа: «made himself». Самое ценное я считаю во всех резюме и портфолио — это то, когда оно сделано своими руками, а не заказано в кадровом или рекламном агентстве за деньги.
В дополнение к нижнему ответу на ваш комментарий хочу уточнить, что я под клиентом понимаю «заинтересованные лица» от решения которых зависит успех вашего продукта. Ни что не мешает автоматизировать проведение опроса. Все же клиент косвенно тоже часть команды, ведь в этом случае он совершил сознательный выбор в пользу вашей программы, и нужно показать ему, что для вас очень важен этот выбор.
Для решения вашей проблемы можно организовать фокус-группу (в российской схеме — это может называться рабочей группой, где кстати могут быть и тестировщики) для которой будет демонстрироваться ваш продукт, и от её коллегиального решения будет зависеть выход изделия (продукта, релиза ПО) на рынок. В статье описана технология, а способов её применения множество. Даже если продукт инновационный, то у него все равно должны быть заинтересованные лица (клиенты). В крайнем случае, главным потребителем может быть вы сами, если продукт разрабатывается для себя. Категоризация — это не планирование, а только определение спорных моментов в рамках требований, моментов требующих проработки и возможность команде быстро показать прототип на базе типовых требований. Приведу пример, у вас существует так называемая приёмочная шкала, с её помощью вы пытаетесь расписать свои контрактные обязательства, если произвести сортировку требований по этой шкале, то может так получится, что в списке окажутся требования из категории "I" с абстрактной важностью >100. Команда потратит на них время, и даже, может быть реализует, но не сможет продемонстрировать продукт заказчику, потому, что у него в приоритете будут типовые требования и он как раз им и установит приемочную шкалу >100. Обычно типовые требования в ТЗ явно не указаны, поэтому с приоритетами так можно играть до бесконечности.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность