Первые три этапа
1. Эссе о курсе «Экологичный путь менеджера»
Руководитель проектов (Digital-продюсер/PM/Project Manager) — это человек, который, во-первых, находится от начала и до конца на проекте, отвечает фактически «шкурой» за проект в целом, во-вторых, это многофункциональная роль, которая должна уметь сочетать в себе многие навыки.
Конечно, у каждой IT-компании есть свои особенности в бизнес-процессе, и понятное дело, что зоны ответственности проектного менеджера в каждой компании немного отличаются, но в целом, основные направления в работе менеджера — это технология и коммуникации.
Если говорить о направлении технологии, в курсе описан «идеальный менеджер», который проходит свой путь следующим образом. Сначала он должен поработать тестировщиком. Именно в данной должности у человека вырабатываются такие важные качества и навыки, как исполнительность, внимательность к мелочам, требовательность, навык оценки задач. А также это единственные участники в команде, которые по умолчанию заслуживают авторитет у программистов.
После того, как ты проработал тестировщиком, ты обязательно должен перейти на должность аналитика по системам. На этом этапе у тебя появляется реальное понимание всего цикла разработки, навыки бизнес-анализа, декомпозиции проектов и, что очень немаловажно для будущего менеджера, навык презентации. Стоит также отметить, что именно аналитик обладает хорошими шансами добиться авторитет у дизайнеров.
Далее можно попробовать поработать аккаунт-менеджером, перестроиться на формат внешней коммуникации с клиентом, поработать со всеми участниками команды проекта, понять что такое в целом распределение ресурсов и общая ответственность.
Ну, и через какое-то время, если все ступени пройдены достаточно качественно, то можно попробовать окунуться в одну из самых неблагодарных должностей в данном направлении — руководитель проектов. Руководителя проектов можно сравнить с многоруким «Шивой», который должен уметь все, и всегда остается крайним во всех ситуациях, связанных с проектам, как перед клиентом, так и перед руководством компании, ну и конечно перед своей командой. Можно это обобщить безобидным ««ответственность за других».
В курсе также говорится о минусах, таких как выгорание со временем, но я считаю, что это относится к любой должности внутри команды, к людям которые не работают на переменном расслабоне, а работают в напряжении всегда.
И о плюсах — быть менеджером проектов очень круто для личностного роста, потому как ты приобретаешь навыки чуть ли ни во всех направлениях разом, а они могут быть действительно полезными по жизни. Плюс горизонтальная и вертикальная карьера и возможность удаленной работы. Как говорится, выбирай, что хочешь.
2. Эссе по блоку «Релиз-менеджмент: готовим проекты к запуску»
В целом, в данном блоке говорится о тестировании, о различных вариативностях, видах тестирования. Основная мысль — перед запуском проектов обращать внимание на все мелочи!
На что важно опираться при тестировании. Конечно же это в первую очередь, уже принятые в компании определенные чек-листы, то есть некоторые критерии проверки готовности задач. Проверяем утвержденные результаты предыдущих этапов, техническое задание и соответствие ему, соответствие утвержденным прототипам, бэклоги. Несмотря на то, что должно быть очень внимательное отношение к каждой мелочи, ни в коем случае нельзя забывать о здравом смысле. Если мы используем, например, метод кальки, и накладываем дизайн на готовую верстку, надо учитывать, что возможны какие-то здравые мини-изменения на этапе верстки, и если какие-то блоки на пиксель не совпадают — не стоит доводить до инсульта разработчика. В целом, без здравого смысла никак, но он у всех разный...
Если мы хотим получить гораздо меньше трудозатрат на этапе «продакшена», то есть после передачи на приемку заказчику, то стоит начать с тестирования дизайна, правда если макетов сильно больше дюжины. Что следует проверить — нет ли лишнего, есть ли нужное и важное, и не придумал ли дизайнер ничего слишком сложного для дальнейшей разработки.
Далее должно проходить тестирование верстки. Переводим картинки в интерактивный HTML, накладываем макет на верстку (то, что ранее я назвала методом «кальки»), помним о здравом смысле, но проверяем досконально на соответствие. Обязательно должен быть общий Гайдлайн, это некоторая техничка с основными правилами верстки, отступов и т.п.
Также необходимо проверять на валидность кода. Как ведет себя анимация и видео, проверка на медленном канале, проверка адаптива. Повторная проверка после готовности всего проекта. Если проект очень крупный, имеет смысл собирать верстку в спринты и тестировать по спринтам. При этом важно на старте проекта, на этапе проектирования собрать команду, аналитика, тестировщика, верстальщика, программиста, дизайнера и совместно оценить работу, после чего разработать план со спринтами. На этом этапе тестировщик приобретает навык декомпонирования и оценки задач.
Очень хорошая мысль, которую знают все опытные руководители проектов, но, к сожалению, все равно продолжают использовать на практике: «Добавление дополнительных людей в запаздывающий проект только затягивает сдачу проекта». Думаю, что не так затягивает, как не помогает вовсе. Но мы все равно пытаемся в разовых проектах находить подобные способы решения различных внутренних проблем или недооцененности проекта в целом. А вот как раз-таки «Гайдлайн» (техничка), могут избавить от такой проблемы и позволяют включать нескольких разработчиков на параллельную разработку крупных проектов, разбивая по смысловым блокам.
Помимо ручного тестирования, очень полезны для разработки тест-кейсы к задачам. Тест-кейсы пишет скрам-мастер или тестировщик+разработчик. Да, они потратят лишние 1-2 часа, но сэкономят очень много времени и нервов в дальнейшем на этапе сдаче проекта. Также в крупных проектах рекомендуется итерационное тестирование в спринте для дальнейшей экономии времени и ресурса, потому как чем позже начнется тестирование, тем дороже выйдет проект.
Стоит упомянуть про еще один очень полезный вариант, такой как «Тестирование внешним менеджером». В данном случае можно собрать, то что не «увиделось» в ручном тестировании и получить какие-то ценные советы по оптимизации навигации.
Чем нельзя пренебрегать в крупных и сложных проектах — вариант автоматизированного тестирования. Он предполагает наличие отдельного софта, тест-скрипта и определенного тестового набора. Если программист 1 и проект совсем небольшой — этот цикл лишний, достаточно будет провести 1 ручное тестирование.
Рекомендуется использовать автотесты, когда в проекте есть длинные однообразные сценарии, которые не меняются со временем, точные математические расчеты, труднодоступные места в системе, зачастую связанные с бэкэндом (например, на интеграционных протоколах), и при миграции данных.
Подведем итог данного блока курса
При передаче работы на тестирование, будьте внимательны и придирчивы Не бойтесь указывать на ошибки. Не пропускайте мелочи. Не пренебрегайте тестированием и даже несколькими видами тестирования, потому как это займет время, но сэкономит бюджет и сохранит репутацию компании.
3. Эссе по блоку курса «Требовательность digital-продюсера»
Digital-продюсер, то есть руководитель проектов должен уметь правильно настоять на своем, и при этом, отстоять интересы компании и своих проектов. Чаще всего (почти всегда) встречается сопротивление всяческим требованиям. Поэтому, как бы не хотелось быть душкой и полюбовно решать все ситуации, в команде приходится использовать такое понятие как «Власть и эксплуатация».
Власть, установленная внутри команды в рамках digital-проектов означает преодолевать сопротивление (различные закидоны команды) и при этом оставаться в хороших отношениях. Это очень сложно, поскольку требовательность токсична.
Необходимо своевременно планировать проект с участием всей команды проекта, чтобы грамотно настроить команду, поставить правильные цели и задачи. И после передачи проекта в работу, обязательно включать мониторинг и контроль. Требовать четкой оценки задач, регулярно получать обратную связь от исполнителя. Уметь планировать, требовать, настаивать на своем, но не быть диктатором. Вслух говорить про требовательность нельзя, это также токсично. Об этом хорошо пишет Фридман в своей работе «Вы или вас».
Основные функции власти в направлении проектной работы и других направлениях:
- планируй — формирование принципов;
- делай — доведение правил;
- проверяй — обеспечение соблюдения правил;
- воздействуй — награждение и наказание.
Почему мы говорим о власти
Ни для кого не секрет, что если этот подход не использовать, можно столкнуться с популярными когнитивными искажениями у программистов и дизайнеров: критика результата воспринимается как личное оскорбление, далее получение слишком оптимистичных оценок работы, либо пессимистичные оценки работы (чтоб отстали). Появляются фразы: «Это невозможно!»; частое явление амплификация — убить муху кувалдой; генерализация частных случаев прокрастинации (затягивании); профессиональная деформация.
Что очень важно для команды в целом — это по итогам сдачи проекта получение обратной связи от всех участников проекта. То есть ретроспектива проекта. Обязательно нужно отделить хорошее и плохое, похвалить за хорошее, объяснить в чем заключалась ошибка. Закрепить выученные уроки.
И, напоследок, парадигмы Александра Фридмана
Полученное задание должно быть проанализировано перед началом работы. Полученное задание должно быть выполнено на 100%. О препятствиях к стопроцентному выполнению задания следует сообщить руководителю и всем заинтересованным лицам. «Уперся — сообщи». Предложение по решению проблемы предпочтительнее информации об ее возникновении. Факты и аргументация предпочтительнее мнения. Расширенное толкование полученного задания не допускается. Несогласие с параметрами задания или регламентами исполнения не может служить поводом для их игнорирования.
Даже самоорганизующимся командам нужен самоорганизатор.
