Руководство продуктами

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

На протяжении нескольких десятилетий существовал определенный тип программистов, представители которого предпочитали делать собственными силами все – от формулирования концепции продукта до его выпуска. В условиях современных американских корпораций такие индивиды встречаются крайне редко. К величайшему сожалению некоторых разработчиков (в основном тех, которых я отношу к породе ковбоев), программы больше не пишутся в гаражах и спальнях. То время, когда сногсшибательный программный продукт могли создать двое или даже один программист, ушло в историю. В современном мире программное обеспечение из категории занимательных новинок перешло в категорию продуктов первой необходимости.

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

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

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

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

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

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

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