Менеджерам в области информационных технологий иметь с этим дело трудно. Особенно болезненно изменения стратегии сказываются на промежуточных этапах управления проектами. У вас может быть очень мало возможностей отступить назад в связи с переменами в стратегии компании, исходящими сверху. Иногда из-за неожиданных изменений вы должны брать назад обещания относительно новых проектов, данные команде. Это вызывает недовольство, и члены команды начинают вам жаловаться. Однако, поскольку почти ничего поделать вы не можете, у вас возникает ощущение бессилия, а работники перестают чувствовать себя людьми, превращаясь в маленькие винтики корпоративной машины.
Здесь появляется и еще одна проблема: как в отсутствие ясных приоритетов совместить устранение технического долга с другими проектами, ориентированными на новые технологии? В конечном счете, если вы не будете уделять время инженерным вопросам, способность команды создавать новые продукты снизится. А ведь команда продукта почти никогда не задумывается о техническом долге. Поэтому планирование не часто подразумевает время на эти цели.
Методы борьбы с неопределенностью в планировании
Вот несколько приемов по улучшению планирования, основанных на моем личном опыте.
Всегда реалистично смотрите на возможность изменений в планах с учетом размеров и уровня развития компании. Если ваше частное предприятие традиционно корректирует свои планы летом, учитывая при этом свои бизнес-результаты за первую половину года, будьте готовы к таким изменениям именно летом и не давайте своей команде долгосрочных обещаний.
Подумайте над тем, чтобы разбить большой проект на несколько отчетных этапов, чтобы увидеть реально достигнутые на отдельных этапах результаты. При этом необязательно окончательно определять всю большую картину проекта. Разбивка инженерной работы на несколько частей потребует тесного взаимодействия с бизнес-менеджерами и менеджерами по новой продукции при расстановке приоритетов в проекте. При этом все должны помнить, что в проекте могут происходить быстрые изменения, поэтому его состояние придется часто контролировать, выделяя самые важные на данный момент элементы.
Не давайте завышенных обещаний по проектам,связанным с программированием. Не обещайте своей команде интересных проектов по ПО «позже», поскольку планы по продукции на «позже» еще не написаны. Ваши обещания породят у людей надежды, а потом они сменятся разочарованием. Если проект важный, то составьте его расписание на данный конкретный момент или максимально близко к нему. Если проект несрочный, можете отложить его на потом. Но помните, что когда «потом» наступит, к тому времени у вас будет много других приоритетов в отношении других продуктов. Если сейчас вы не уделите время тому, чтобы четко сформулировать ценность данной работы, она будет отодвинута в сторону в пользу проектов с более явной ценностью.
Уделяйте 20% рабочего времени команды поддержанию необходимого технологического уровня. Выделите достаточно времени на рефакторинг (перепроектирование или переработку кода), устранение серьезных ошибок, улучшение процесса программирования, осуществление чистки программ и оказание текущей поддержки пользователям. Учитывайте это при каждом планировании. К сожалению, 20% может быть недостаточно для больших проектов, поэтому иногда по ходу исполнения может потребоваться больше времени для переписывания элементов кода или программ либо других улучшений в ПО. Но без этих 20% времени вы можете не достигнуть запланированных результатов и столкнуться с неприятной работой по чистке программного обеспечения.
Добейтесь для себя ясного понимания, насколько важен в действительности тот или иной программный проект. Проекты, связанные с разработкой новых продуктов или бизнес-проектов, как правило, бывают оправданы тем, что от них ожидается создание для компании новой ценности. Однако с чисто инженерными проектами большие ожидания обычно не связаны. Когда к вам приходит программист, желающий заняться конкретным инженерным проектом, при оценке воспользуйтесь следующими критериями.
Насколько объемен данный проект?
Насколько он важен?
Сможете ли вы ясно объяснить ценность этого проекта любому спрашивающему человеку?
Что даст команде успешное исполнение данного проекта?