Как повысить организованность в масштабах всей компании

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

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

Таблица 4.2. Мотивы, определившие необходимость выделения вашего отдела в автономное структурное подразделение компании

Мотив: Производить гениальные продукты и тем самым зарабатывать для компании деньги.

Воздействие: Путем продуктивного и эффективного использования компетентных специалистов и прочих ресурсов свести непроизводительные издержки к минимуму.

Мотив: Забавляться с технологией.

Воздействие: Оптом скупать свежие программные средства и бесцельно генерировать забавные программы.

Мотив: Пройти очередной этап к реализации ваших непомерных амбиций.

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

Лишь первый мотив из трех вышеперечисленных можно признать допустимым. Остальные либо вторичны, либо в корне неверны. О существе третьего мотива я расскажу в главе 7, посвященной обратной стороне лидерства. Вы должны четко уяснить, что амбиции вполне допустимы, но лишь в том случае, если на первое место вы ставите планы компании и лишь на второе – свои планы. Второй мотив, приведенный в табл. 4.2 (забавы), при удачном стечении обстоятельств становится побочным продуктом первого.

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

Мою книгу трудно отнести в одну категорию с формализованными учебниками по руководству проектами. Но факт остается фактом – для того чтобы преуспеть в области лидерства, вы должны стать хорошим руководителем проекта. В литературе, имеющейся на рынке, эта область описана очень комплексно, и ряд рекомендуемых работ по данной теме есть в разделе «Библиография». Шаг за шагом вам предстоит овладевать все новыми и новыми навыками руководства проектами и в особенности – специальными методиками управления проектами по разработке программного обеспечения. По словам автора одной из моих самых любимых книг на эту тему: «основная причина неудач в процессе разработки программных продуктов заключается в неадекватном руководстве проектами»[50]. Обратите внимание на ключевое слово – «адекватность». Действительно, наличие организационных навыков, ориентированных на управление проектами, есть основной залог успешной реализации последних. На первый взгляд приведенная цитата кажется чрезмерно упрощенной. В то же время, если вы ознакомитесь с рекомендуемыми мною литературой и предложениями по руководству проектами, многочисленные причины, по которым это высказывание представляется справедливым, станут для вас очевидными.

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

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

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

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

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

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

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

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

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

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

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

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

Как известно, изменения в нашей жизни есть единственное постоянное явление. Этот принцип вы слышали не раз, не так ли? Даже в курсе по основам физики утверждается, что в замкнутых системах следует ожидать повышения энтропии. Так почему же тогда мы пишем книги, читаем код, занимаемся другими структурированными видами деятельности? Надо полагать, что-то (или кто-то) способствует упорядочению, которое противостоит естественной, присущей всей Вселенной тенденции к дезорганизации. «Что это он такое мелет? – спросите вы. – Уж не хочет ли он сказать, что мне предстоит стать "Богом управления процессами"?» Да, именно это я и имею в виду. Хотите более замысловатый титул – можете называть себя «владыкой изменений». Главное, как вы понимаете, – не наименование, а действие. В рамках общей, единой для вашей компании стратегии вы должны руководить процессом определения продуктов и проекта.

Изменения делятся на два основных типа: намеренные и случайные. Изменения, относящиеся к первому типу, обычно планируются; вторые же, как правило, непредсказуемы. Если вы ориентированы на успех, старайтесь тщательно управляться с намеренными изменениями – тогда вы сможете получить определенный контроль над случайными изменениями. Подумайте, какое воздействие модификация продукта окажет на сетевую инфраструктуру? А как насчет изменения механизма взаимодействия с пользователем во второй версии продукта? Учитываете ли вы все эти моменты? Кодирование не есть изолированный процесс. По словам Томаса Мертона (Thomas Merton), «нас согревает огонь, а не дым; через океан мы плаваем на кораблях, а не на волнах, которые они оставляют за собой»[51]. К сожалению, слишком часто программные продукты создаются без достаточного анализа воздействия технических решений на окружающую среду – «дым» и «волна» наших усилий в таких случаях приводят к дестабилизации деятельности компании.

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

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

• Каким представляется воздействие изменения на архитектуру системы и процесс сопровождения?

• Как предполагаемое изменение воздействует на сетевую инфраструктуру, в которой оно будет проводиться?

• Как предполагаемое изменение повлияет на способность пользователя эффективно и продуктивно взаимодействовать с данным программным продуктом?

• Какое влияние предполагаемое изменение окажет на действия сотрудников отделов, которым его придется испытать на собственной шкуре?

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

Тестирование

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

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

Руководство инфраструктурой

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