Роль руководителя проекта

Несмотря на существование проектных офисов и на то, что  в мире медленно растет понимание ценности и необходимости этой профессии – все равно иногда происходит интересный сбой матрицы, и со стороны заказчика тебе выдают так называемого “руководителя проекта со стороны заказчика”. Это правильно и логично при работе на внешних проектах, на внутренних же вызывает недоумение, так как в 99% случаев РМ от бизнеса оказывается просто представителем заказчика и выполняет только эту функцию.

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

Это долго, противно и отнимает кучу времени, и в большинстве случаев на выходе ни к чему не приводит, так как выясняется, что поруководить-то представитель заказчика хотел, а вот нести за все это ответственность – не очень.

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

Trello – два маленьких лайфхака

Тут  с удивлением узнала, что не все используют две хорошие функции в Trello, сильно облегчающие жизнь. Если вы Trello не пользуетесь – дальше можно не читать, но очень советую погуглить, крайне полезная и удобная вещь.

Как организовать эффективное тестирование силами пользователей?

Сегодня у нас немного ИТ, но, думаю, интересно будет всем. Любой проект разработки ПО предполагает, что в нем есть 3 стадии тестирования (упрощенно) – сначала сам разработчик проверяет правильность работы, потом это делают специально обученные профессиональные тестировщики, и последними приходят пользователи и осуществляют приемочное тестирование. Это как должно быть, но по факту может случиться так, что основными тестировщиками в проекте выступаю пользователи (или аналитики, в этом контексте не важно), если у Компании почему-то нет ресурсов на профессиональное тестирование, проект имеет низкий приоритет, некогда или по любой другой причине. И пользователи часто делают это “для галочки”, а потом уже в процессе опытной эксплуатации начинает сыпаться ошибка за ошибкой. Их сложно за это винить, чаще всего у них нет для тестирования ни специальных знаний, ни рабочего времени. Как же можно исправить эту ситуацию?

По следам SQA Days – 20 – маленький лайфхак

Подсмотрела тут у пары человек на конференции SQA Days -20 маленький, но очень удачный лайфхак. Часто на конференциях или строятся километровые очереди за кофе, или в самый неудачный момент заканчиваются стаканчики или на них просто нет крышек, и ты дефилируешь в толпе, каждую секунду выбирая, что лучше – залить соседа кофе или свои раздаточные материалы (а в особо удачные моменты – спикера или оборудование). А ведь решается легко и просто!

“Где сделаем обезьянку?” или как не делать лишней работы

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