Продолжаем рассказывать о том, как замечательное слово «НЕТ» иногда помогает сохранять проект в запланированных рамках. Напоминаем, что этот вопрос мы решили обсудить с двумя коллегами: программистом и аналитиком. С точки зрения бизнес-аналитика, мы уже рассказали, почему и в каких ситуациях это слово так важно. Что же по этому поводу думает программист?
Мы будем говорить о проекте развития корпоративной информационной системы. Как быть в данном случае? Как работать с уровнем важности задач и как сделать так, чтобы команда эффективно и быстро развивала информационно-технологическую поддержку в растущей компании? На таких проектах задачи можно разделить на 2 типа: ежедневные задачи и задачи на развитие.
Ежедневные задачи можно сортировать по частоте обращений пользователей. И, если обращений поступает много, то необходимо такие задачи как можно скорее выполнить, тем самым снизив количество запросов пользователей и, следовательно, нагрузку на команду проекта. Обычно такие задачи не предполагают больших затрат на реализацию, и их можно оперативно решить.
Задачи на развитие должен передавать команде руководитель проекта или старший разработчик, или скрам-мастер, или любая другая ведущая роль в команде, а не каждый пользователь отдельно. Поэтому тут важно сразу отсечь на корню ситуации, при которых пользователи единовременно ставят задачи такого уровня проектной команде. Здесь наступает тот самый момент, когда стоит сказать нет, развернуть обращение на более старшего и опытного специалиста и получать задачу уже в корректной интерпретации, которая не нарушит целостность системы.
Но где еще важно корректно «развернуть» пользователей и других заинтересованных лиц на таких проектах? Вернемся к первому типу запросов, ежедневным задачам. Очень важно на таких проектах держать золотую середину: помогать пользователям в решении их вопросов и при этом не давать садиться тебе на шею. Звучит грубовато, но такие ситуации сплошь и рядом в IT службах крупных компаний. Если слишком часто погружаться в ежедневные вопросы пользователей, показывать максимальный уровень квалификации, причем комбинации технических и аналитических навыков, пользователь, так или иначе, расслабится и будет обращаться с любым вопросом к специалисту хелпдеска. И в этом нет вины пользователя, это будет абсолютно нормальная реакция, целью которой будет минимизация собственных ошибок. Так что, если у вас есть мануалы пользователей или вы уже несколько раз отвечали на один и тот же вопрос, поставьте таким задачам самый низкий приоритет в своем персональном бек-логе. С 95% вероятностью пользователь и сам разберется, просто чуть дольше чем с Вашей помощью. Думаете при таком подходе может ухудшиться отношение пользователя к команде или персонально к Вам? Что ж, это нормальное переживание для молодого специалиста, но помните, что никто не обязан делать работу другого сотрудника в компании. И на этот счет специалист, с которым мы проводили интервью сказал «Отвечу цитатой великого человека, сэра Алекса Фергюсона, который тренировал МЮ в течение 27 лет и выражал свою позицию к подчиненным следующий образом (в основном, к игрокам): «Мне не нужно, чтобы они меня любили. Мне нужно, чтобы они меня уважали». Пользователи, конечно, не наши подчиненные, но нам не нужно, чтобы нас любили, нам нужно, чтобы каждый профессионально делал свою работу».
Читайте далее 1 ЧАСТЬ
