Поэтому всегда нужно проявлять настойчивость, высказывая предварительные оценки и говоря о возможных изменениях, даже когда вас об этом не спрашивают. Особенно это касается проектов, важных для компании или требующих большого срока для исполнения. Это означает, что вы должны проявлять настойчивость, и получая оценки от подчиненных. А как мы знаем, подготовка оценок в сфере производства программного обеспечения — очень сложный процесс. Обсуждение процесса, его временных параметров и сферы применения в конкретных проектах — часть вашей работы на уровне управления менеджерами.

Инженеры-программисты зачастую вообще не хотят давать никаких оценок за пределами agile-спринта, ограничивающегося обычно двумя неделями. Такой подход вполне обоснован, если исходить из того, что оценки должны быть достаточно точными, что требования к проекту неизвестны и могут часто меняться и что большая часть работы связана с продуктом, обычно создаваемым за один или два гибких рывка. И все же дело не всегда обстоит так. Оценки весьма полезны даже тогда, когда не очень точны, потому что помогают всей команде продемонстрировать сложность задач. Не во всяком проекте часто изменяются требования, и в принципе возможно заблаговременно провести работу по снижению количества неизвестных, затрудняющих составление оценок в разработке и производстве софта. Вы можете поспорить, утверждая, что заблаговременная тщательная проработка оценок удлиняет процесс работы над проектом больше, чем поэтапная оценка «рывков». Возможно, вы и правы. Но здесь мы говорим не только о командах, связанных с разработкой систем и программ. Мы говорим о бизнесе в целом: планирование существует, чтобы получать представление о необходимых для производства затратах и усилиях. Кроме того, мы в некотором смысле говорим о формировании целей и о том, как добиваться лучшего понимания сложности систем и софта. Мы не можем предсказывать будущее на 100%, но воспитать в командах умение вырабатывать интуитивные навыки осознания сложности работы и открывающихся новых возможностей — само по себе достойная цель.

Поэтому смиритесь, что вам всегда придется иметь дело с определенным уровнем оценок. Попробуйте разные методики и посмотрите, какая лучше подойдет для вашей компании. И сделайте такую работу привычной во всех командах.

Важный элемент гибкого процесса разработки софта — усвоение уроков прошлого. Когда наши оценки оказываются неверными, чему мы учимся? Если степень сложности проектов нам неизвестна? Что нам следует оценивать и когда? Как мы оцениваем способы донести оценки до адресатов? Какие наши ошибки вызвали у них разочарование?

Ваша работа состоит в том, чтобы максимально понятно довести до заинтересованных сторон, что означает для данного проекта «долго». Сделать это вы должны, предложив адресатам обоснованное мнение о сроках проекта и активно обновляя это мнение в случае необходимых изменений, особенно в сторону значительного замедления исполнения проекта.

Может получиться и так, что, несмотря на все ваши усилия, вам будут задавать вопрос «почему так долго» даже тогда, когда вы четко объясняли, что такое «долго»; когда ваш проект на самом деле превышает запланированные сроки или когда возникли неконтролируемые обстоятельства, задержавшие проект, о чем вы сообщали заинтересованным сторонам. Попасть в такую ситуацию всегда очень неприятно, а случается это довольно часто, потому что кто-то из руководства излишне волнуется за проект и требует завершить его быстрее, чем вы вообще когда-либо рассчитывали его сдать. Однозначного решения для таких ситуаций нет. Часто единственное, что можно сделать, это терпеливое напоминание руководителю, что проект движется вперед с положенной скоростью, по расписанию. Однако давление на подчиненного и возложение на него вины за ситуацию зачастую может быть лишено всякой рациональности. Этого трудно избежать в состоянии стресса. Поэтому даже по отношению к тому, кто на вас давит, целесообразно демонстрировать понимание и готовность приложить необходимые усилия. В перспективе такой подход может помочь трансформировать агрессию вашего оппонента в рациональное действие.

И последнее. Не бойтесь работать с менеджерами, техническими руководителями групп и бизнес-подразделениями в том, что касается возможного сокращения содержания проекта по мере приближения сроков его закрытия, чтобы не нарушить важные сроки. Как представителю старшего менеджмента вам, возможно, придется сыграть роль судьи и принять решение, какие элементы проекта можно сократить, а какие оставить как имеющие существенное значение для конечного успеха. Помогите команде найти такие элементы и проявите твердость, жертвуя чьей-то любимой идеей, если это поможет завершить большой проект. Проявите разумный подход к тому, от чего можно отказаться. Если вы уступите в вопросах качества продукта, то создадите команде сложности после выпуска. Поэтому внимательно соотносите практические свойства продукта с технологическими красотами, теоретически возможными в нем.

Сложные ситуации: нечеткие планы

Одна из самых распространенных проблем менеджеров на всех уровнях — изменение продукта и отсюда нечеткое планирование. Особенно в небольших компаниях трудно заставить работников заниматься планированием работы на год вперед. Даже в крупных компаниях изменения на рынке могут вызывать перемены в стратегии, приводящие к отказу от некоторых проектов и уже подготовленных планов.

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

Здесь появляется и еще одна проблема: как в отсутствие ясных приоритетов совместить устранение технического долга с другими проектами, ориентированными на новые технологии? В конечном счете, если вы не будете уделять время инженерным вопросам, способность команды создавать новые продукты снизится. А ведь команда продукта почти никогда не задумывается о техническом долге. Поэтому планирование не часто подразумевает время на эти цели.

Методы борьбы с неопределенностью в планировании

Вот несколько приемов по улучшению планирования, основанных на моем личном опыте.

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

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