От разработчика до руководителя

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

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

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

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

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

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

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

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