Эффективная кадровая политика IT компаний-разработчиков коробочных программных продуктов

На сегодняшний день Internet Explorer стремительно теряет долю рынка, а лидерство переходит к Google Chrome. Компания Google пошла более «правильным» путем: они привлекли Ларса Барка, разработчика технологий WEB-браузеров с 20-летним опытом, а также группу бывших разработчиков Netscape Navigator. В результате ситуация на рынке выглядит так:

Рисунок 1 - Доля рынка WEB-браузеров (в %) по годам. Черная линия - Microsoft Internet Explorer, зеленая - Google Chrome

Таким образом, если в компании в определенной области нет «звездных» специалистов и руководителей, то вероятность создания коммерчески успешного коробочного продукта своими силами крайне низка. Если высшее руководство компании считает перспективной какую-либо область рынка, то при отсутствии своего технически опытного идеолога в проекте надо готовиться к тому, что серьезный успех будет через 5-10 лет (в зависимости от сложности программного продукта). Столь долгий срок означает также, что компания-разработчик коробочных программных продуктов должна обеспечить удержание персонала в течение десятилетий. IBM и вовсе провозглашает принцип пожизненного найма, хотя он и не отражается в кадровых документах. В противном случае получится, что специалисты обучаются в вашей компании, а потом основывают свою, либо уходят к конкурентам, где реализуют-таки успешный продукт.

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

Правда, крупные компании могут  покупать удачные стартапы не только для того, чтобы заполучить их команды, но и для того чтобы избавиться от конкурента. Однако в отличие  от других отраслей, команде такой компании будет намного проще запустить еще один стартап, либо продаться конкурентам, поскольку именно команда является основным ресурсом IT компаний.

История ведущих IT компаний-разработчиков коробочных программных продуктов изобилует примерами удачных и неудачных покупок команд. Например, автором операционной системы MS-DOS (самой первой операционной системы от Microsoft) был Тим Патерсон. Он написал операционную систему в Seattle Computer Products с 1978 по 1981. В 1981 Microsoft купила его разработку, а затем и его самого. Он работал в Microsoft с 1981 по 1982, затем основал свою компанию, которую Microsoft купила вместе с ним в 1986. Далее он работал там с 1986 по 1988, затем с 1990 по 1998. Таким образом, Билл Гейтс цеплялся за Тима Патерсона всеми возможными способами, пока тот вообще не ушел из IT.

Не менее показательна история  автора операционной системы Google Android Энди Рубина. С 1992 он разрабатывает операционные системы для мобильных устройств. Компания WebTV, в которой он работал c 1995 по 1999, была куплена Microsoft. Затем он основал еще одну компанию, которая также в конце концов была куплена Microsoft в 2008. Третью компанию, «Android», Энди Рубин основал в 2003, а в 2005 ее купила Google. Google смогла предложить этому разработчику такие условия, на которых он согласился сотрудничать, и на свет появилась новая операционная система, стремительно набирающая популярность на мобильных устройствах.

3. Направления кадровой политики

1. Состав и структура компании

1. Структура команды разработчиков

Разработка программного обеспечения – это командная  работа. Команда особенно важна на ранних стадиях жизненного цикла продукта.

Команды разработчиков, как рекомендуют Ф. Брукс и Х. Миллз (один из ведущих разработчиков компании IBM), следует организовывать наподобие бригады хирургов. Имеется в виду, что не каждый участник группы будет врезаться в задачу, но резать будет один, а остальные оказывать ему всевозможную поддержку, повышая его производительность и плодотворность.

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

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

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

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

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

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

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

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

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

Как это работает

  Созданная нами бригада может достичь желаемой цели несколькими способами. Над задачей трудятся 7 человек, но система является продуктом одного ума, по крайней мере двух, действующих uno animo (как одно целое).

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

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

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

Масштабирование

До сих пор все было хорошо. Проблема, однако, состоит в  том, как создавать продукты, на которые  сейчас уходит не 20 или 30, а 5000 человеко-лет. Бригада из 7 человек может быть эффективна вне зависимости от своей организации, если задача целиком находится в ее компетенции. Но как использовать идею операционной бригады в задачах, для выполнения которых привлекаются сотни людей?

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

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

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

Составлять пары ведущий разработчик + менеджер проекта можно, например, с помощью соционического анализа.

В то время как ведущий  разработчик сосредоточен на продукте, топ-менеджмент компании должен быть сосредоточен на получении прибыли от продаж продукта. Высшее руководство организации должно также быть выходцами из разработчиков. Для топ-менеджера IT компании-разработчика коробочных программных продуктов крайне важно обладать достаточными знаниями технической стороны вопроса, чтобы оценивать идеи, рождающиеся в головах сотрудников компании. Высшие руководители должны внимательно следить за тенденциями мира IT, поскольку он подвержен частым изменениям, а время реакции на них может составлять от 1 до 10 лет! Таким образом, топ-менеджер IT компании-разработчика коробочных программных продуктов должен быть одновременно высококвалифицированным разработчиком ПО и предпринимателем, способным оценить новые идеи и перспективы. В руководстве, как и в проектных командах, должны быть профессиональные администраторы, однако как и в проектных командах, решающее слово всегда за техническими специалистами.

2. Модель жизненного цикла организации Ицхака Адизеса

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

Рисунок 2 - Жизненный цикл организации по И. Адизесу

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

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

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