Как пасти котов. Наставление для программистов, руководящих другими программистами

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

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

Классический процесс следует направлять таким образом, чтобы все сотрудники компании в своей деятельности руководствовались едиными коммерческими задачами и решениями.

Определение проекта

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

При организации проекта вы должны отталкиваться от опыта работы с предыдущими проектами – вне зависимости от того, насколько они были успешными или, наоборот, провальными. Наибольший воспитательный эффект мы получаем от неудач (хотя и успехи в этом отношении очень полезны). Прежде чем подписаться на методику программной инженерии, основательно подумайте. Методика эта полностью применима к некоторой части крупных проектов, однако в том, что касается программного обеспечения, мастерство оказывается важнее инженерии. Это мое мнение. Его разделяют многие другие специалисты, но как к нему относиться – решайте сами. В конце концов, купив эту книгу, вы заплатили за мое мнение определенную цену. Выражусь иначе: если ваша группа сможет договориться со спонсорами по поводу этапов работы над проектом, то при утверждении сроков завершения работы вряд ли вам придется тыкать пальцем в небо. Дата выпуска программных продуктов часто рассматривается как движущаяся цель; чтобы справиться с неопределенностью, постарайтесь уяснить одну простую вещь – выпуск невозможен без предварительного комплексного тестирования. Очевидно, что тестирование проводится после кодирования, кодирование после проектирования и т. д. Я совершенно не хочу навязать вам какой бы то ни было процедурный шаблон с условием обязательного применения во всех проектах. Я просто пытаюсь напомнить о том, что прежде конструирования нужно тщательно определить и структурировать процессы, реализуемые в рамках проекта.