Негосударственное образовательное учреждение
Московская международная высшая школа бизнеса
«МИРБИС» (Институт)
ПРОФЕССИОНАЛЬНАЯ ПЕРЕПОДГОТОВКА
Допустить к защите:
Проректор по программам
повышения квалификации и
профессиональной переподготовки
_____________________
«___»_______________20___г.
Группа № 000
Аттестационная (выпускная) работа по программе:
«Управление персоналом и кадровый анализ»
Слушателя: | Щербашина Леонида Алексеевича |
Тема работы:
Эффективная кадровая политика IT компаний-разработчиков коробочных программных продуктов |
Руководитель-консультант: | |
Сдана на проверку | Оценка |
("1") Москва 2012 г.
Оглавление
1.
Введение
IT компании-разработчики программных продуктов отличаются от компаний других отраслей прежде всего тем, что основным ресурсом производства в них являются люди. Персонал является главной статьей расходов, а его качество во многом определяет потенциал и возможности компании. Поэтому управление человеческими ресурсами является одним из важнейших элементов в деятельности IT компаний, а кадровая политика является объектом пристального внимания со стороны высшего руководства. Успешное функционирование IT компаний напрямую зависит их проводимой ими кадровой политики. Данная работа посвящена анализу существующих подходов к формированию кадровой политики в компаниях IT сферы и определению наиболее эффективных из них.
1.Категоризация компаний разработчиков ПО и характеристика их кадровой политики
IT компании-разработчики программных продуктов по типу своего бизнеса подразделяются на несколько категорий. Вот основные из них.
Большинство IT компаний принадлежит именно к этой категории. К этой же категории можно отнести все IT отделы, поддерживающие инфраструктуру в компаниях, бизнес которых не связан с разработкой программных продуктов.
Заказная разработка программного обеспечения учитывает индивидуальные особенности бизнес-процессов конкретного заказчика. Разработка программного обеспечения на заказ позволяет получить программный продукт, повышающий финансовую отдачу, учитывающий перспективы развития организации и современные тенденции в области информационных технологий.
Заказная разработка и внедрение программного обеспечения наиболее часто применяется при решении следующих задач:
- автоматизация уникальных бизнес-процессов (уникальное производство, или контроль специфических процессов любой природы и т. д.); интеграция существующих информационных систем: обмен данными между существующими информационными системами, создание единой системы отчетности на основе данных из различных систем и т. д.; модернизация существующих информационных систем: создание WEB интерфейсов к системам, расширение функциональности, разработка уникальных рабочих мест, адаптированных под мобильные устройства; интеграция бизнес-процессов различных предприятий: автоматизированный обмен электронными документами (заказы, счета и т. д.) между предприятиями партнерами; сбор данных из территориально распределенных подразделений: создание центральных хранилищ данных, синхронизация данных между филиалами или подразделениями, консолидированная отчетность;
В заказной разработке всегда существует заказчик, который гарантирует востребованность создаваемого продукта. Технологический процесс в таких компаниях построен таким образом, чтобы наиболее четко идентифицировать потребности конкретного заказчика, и наиболее точно реализовывать программу под них. Риски, связанные с несоответствием требований заказчика реальным потребностям бизнеса, обычно несет потребитель продукта. Он же зачастую берет на себя риски, связанные с невозможностью (чрезмерно высокой стоимостью) изменения программы, при изменении бизнеса заказчика.
Как следствие, кадровая политика в заказных разработках ориентирована на профессионалов, владеющих четко определенными инструментами разработки. На сегодняшний день существует несколько методологий, работая по которым возможно оценивать стоимость и реализовывать заказные проекты в соответствии с планом. Поэтому прежде всего компании-заказных разработчиков интересуют исполнительные и дисциплинированные люди, готовые в точности выполнять поставленные задачи. В таких компаниях, как правило, жесткий отбор по уровню владения инструментами разработки. Последствия текучести кадров достаточно серьезны, однако они могут быть в значительной степени нейтрализованы за счет технологичности производства.
2. Компании-разработчики коробочных программных продуктов
("2") Коробочный программный продукт — это программное обеспечение, предназначенное для неопределённого круга покупателей и поставляемое на условиях «как есть», со стандартными для всех покупателей функциями. Коробочными программными продуктами являются, например, операционные системы Windows, Microsoft Office, поисковые системы Яндекс и Google, антивирусные программы, компьютерные игры и т. п.
При разработке коробочных программных продуктов, как правило, заказчик не гарантирует востребованности продукта на рынке. Риски, связанные с несоответствием продукта требованиям рынка, а также убытки от доработок продукта при изменении внешних условий несет производитель.
Как следствие, кадровая политика в коробочных разработках ориентирована не только на профессионалов, владеющих инструментами разработки, но и на специалистов по предметной области, обладающих инициативностью и умением прогнозировать изменение требований рынка. В результате, если для заказной разработки достаточно просто хороших специалистов, то для создания коробочных продуктов нужны «звезды». Поскольку требования к персоналу выше, то последствия текучести кадров могут быть критическими, так как технологичность производственного процесса не может нейтрализовать уход уникального специалиста.
3. Компании, занимающиеся локализацией иностранных продуктов под особенности местного языка и менталитета
Например, к этой категории относятся офисы Microsoft в России, компании, занимающиеся локализацией компьютерных игр. Данная категория выделена отдельно, поскольку она не относится в полной мере ни к заказным разработкам, ни к коробочным. Зачастую такие компании не работают самостоятельно, а являются дочерними по отношению к крупным компаниям-разработчикам коробочных программных продуктов. По принципам кадровой политики они ближе к заказным разработкам, поскольку большинство требований для них уже введено изначальным разработчиком, и от персонала требуется главным образом квалификация и исполнительность.
В данной работе приводятся ключевые элементы кадровой политики, которые позволят добиться ее эффективности для IT компаний-разработчиков коробочных программных продуктов.
2.
Проблемы и особенности IT компаний-разработчиков коробочных программных продуктов
Поскольку главным ресурсом IT-компаний является персонал, а коробочные продукты — это всегда уникальные продукты, то люди с опытом разработки именно в данном направлении являются необходимым ресурсом. Разработка коробочных IT-продуктов сродни научным исследованиям. Т. е. чтобы развивать, например, направление лазерной физики нужны именно ученые из этой области. Заменить их физиками-ядерщиками не получится, какими бы именитыми они ни были.
В разработке коробочного программного обеспечения, требуются очень квалифицированные специалисты. Компании рассматривают очень много кандидатур, но относительно мало берут в штат. По сравнению с фирмами, занимающимися разработкой и внедрением заказного программного обеспечения, программисты коробочных продуктов – это элитные войска (спецназ) по сравнению с регулярной армией. Они более высокооплачиваемые, но и с гораздо более высокой квалификацией, каждый многое умеет. В этих компаниях практически нет так называемых "простых кодировщиков", которые занимаются программированием по кем-то подробно поставленной задаче.
Разработчиков, которые бы могли вписаться в коллектив и приносить высокую отдачу, очень трудно найти. Но компании идут именно по пути привлечения высококлассных профессионалов, и отдача от этого очень хорошая. Ведь если брать специалиста ниже классом, это означает, что придется вместо одного нанимать десять человек. Понадобится также брать начальника, который будет их координировать. Возникнет необходимость увеличивать обслуживающий персонал, разбирать конфликты между специалистами вследствие разницы в квалификации, что критически скажется на эффективности работы.
Другими словами, для создания коробочных программных продуктов требуются люди с опытом разработки программ (от архитектуры до пользовательского интерфейса) в данной сфере не менее 5 лет, хорошо ориентирующиеся в потребностях потенциальных потребителей. Люди с опытом программирования в какой-либо сфере более 5 лет сами по себе уже дефицитные специалисты. Здесь же речь идет не о простых разработчиках, но еще и о специалистах по предметной области, хорошо знающих бизнес будущих клиентов. Таким образом, подбор персонала нетривиальной задачей, а любая утечка кадров оказывает критическое влияние на успех проектов.
Еще сложнее обстоят дела с поиском руководителей разработки. Например, по технологии разработки в компании «Фирма «1С»», очень большую роль играют руководители разрабатывающих отделов. Таких отделов у них около десятка. Каждый руководитель отдела ведет проект фактически самостоятельно, он идеолог и компоновщик. К постановке задач могут привлекаться внешние специалисты, что-то запрашивается у профессиональных бухгалтеров, у аудиторов. Так, версия 7.7 “1С:Предприятия” является результатом полутора лет работы, исходный код программы содержит около 950 тыс. строк, в ее разработке принимало участие около 20 специалистов. С руководителем фирмы согласовывались только содержание, сроки разработки, необходимые ресурсы и предполагаемая цена, а «отцом» продукта, организатором разработки является руководитель подразделения.
Другими словами, руководителем разработки – это не просто специалисты с большим опытом разработки и знаниями потребностей бизнеса, но и идеологи продукта. Руководитель разработки – это носитель идеи, предприниматель, являющийся одновременно техническим специалистом с большим опытом работы (5-10 лет) в данной области. Количество таких специалистов на рынке фактически равняется количеству существующих коробочных программных продуктов, поэтому поиск и выращивание таких «звезд» внутри компании должно быть главным фокусом ее кадровой политики.
Рынок информационных технологий на сегодняшний день является бурно развивающимся, поэтому никакой руководитель компании, каким бы компетентным техническим специалистом он ни был, не сможет квалифицированно поставить задачу на разработку нового продукта. Ситуация осложняется еще и тем, что от постановки задачи до появления продукта может пройти срок до 2-х лет, а за это время рынок может измениться кардинально. Поэтому топ-менеджмент успешных IT компаний-разработчиков коробочных программных продуктов играет роль «оценщика» идей, которые рождаются как внутри компании, так и вне ее. Предложения по дальнейшему развитию продукта поступают именно от руководителей разработки, «снизу», а не «сверху» от топ-менеджмента. Конечно же, высшие руководители компании должны иметь большой опыт непосредственной разработки компьютерных программ, в идеальном варианте это должны быть бывшие руководители разработки в данной области бизнеса. Однако любой практический опыт становится бесполезным уже через 2-5 лет, и все, чем может располагать IT-директор – это способностью быстро понять суть чужой идеи и оценить ее перспективность и реализуемость.
Как можно заметить, весь основной персонал компании должен иметь большой опыт разработки программного обеспечения, а авторы (либо носители) идей должны непосредственно руководить их воплощением. Этот принцип должен обязательно соблюдаться при построении оргструктуры компании и проектных команд, и лежит в основе успеха таких компаний, как Microsoft, Google, Яндекс, 1С. Но даже у этих гигантов, несмотря на их талант в области оценки тенденций рынка и управления персоналом, случались явные неудачи.
Примером такой неудачи можно считать участие Microsoft в «войне WEB-браузеров». К моменту, когда Билл Гейтс посчитал, что рынок интернет-обозревателей является стратегически важным направлением, 80% рынка контролировалось платным приложением Netscape Navigator. Microsoft было принято решение купить не специалистов по созданию такого рода программ, а технологию (исходные тексты компьютерного кода) конкурента. Разработка Internet Explorer, браузера от Microsoft, была поручена талантливому, но не опытному разработчику Томасу Реардону. Ведущий разработчик не был идеологом продукта, поэтому Internet Explorer не более чем копировал идеи конкурента.
В результате даже когда Microsoft стала распространять свою программу бесплатно, Netscape оставался лидером рынка. Добиться ухода конкурента Билл Гейтс смог только тогда, когда Internet Explorer стал поставляться бесплатно в полном функционале вместе с операционной системой Windows. Таким образом, Microsoft пришлось навсегда пожертвовать доходами от продажи данного вида продуктов. А рынок WEB-браузеров стагнировал, поскольку с уходом конкурента не осталось идеологов, которые могли бы развивать продукт. Microsoft потеряла не только доходы от продаж, но и приобрела негативный имидж в глазах разработчиков в области WEB-технологий.
На сегодняшний день Internet Explorer стремительно теряет долю рынка, а лидерство переходит к Google Chrome. Компания Google пошла более «правильным» путем: они привлекли Ларса Барка, разработчика технологий WEB-браузеров с 20-летним опытом, а также группу бывших разработчиков Netscape Navigator. В результате ситуация на рынке выглядит так:
Рисунок 1 - Доля рынка WEB-браузеров (в %) по годам. Черная линия - Microsoft Internet Explorer, зеленая - Google Chrome
("3") Таким образом, если в компании в определенной области нет «звездных» специалистов и руководителей, то вероятность создания коммерчески успешного коробочного продукта своими силами крайне низка. Если высшее руководство компании считает перспективной какую-либо область рынка, то при отсутствии своего технически опытного идеолога в проекте надо готовиться к тому, что серьезный успех будет через 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 человек могут выполнять хорошо дифференцированные и специализированные роли в команде программистов, организованной по образцу операционной бригады.
Как это работает
("4") Созданная нами бригада может достичь желаемой цели несколькими способами. Над задачей трудятся 7 человек, но система является продуктом одного ума, по крайней мере двух, действующих uno animo (как одно целое).
Обратите особое внимание на различие между группой из двух программистов с обычной организацией и группой типа "хирург - второй пилот". Во-первых, в обычной бригаде работники делят задачу между собой, и каждый из них отвечает за замысел и воплощение некоторой части. В операционной бригаде и хирург, и второй пилот находятся в ведении всего проекта и всего программного кода. Это обеспечивает концептуальную целостность продукта.
Во-вторых, в обычной бригаде партнеры равны, и неизбежные разногласия должны разрешаться путем переговоров или компромиссов. Поскольку задача и ресурсы разделены, разногласия относятся к общей стратегии и интерфейсам, но к ним примешивается и противоположность интересов. В хирургической бригаде различий интересов нет, а разногласия единолично решаются хирургом.
Кроме того, решающее влияние на эффективность оказывает специализация функций остальных членов бригады, так как в результате осуществима значительно более простая схема контактов между сотрудниками.
Масштабирование
До сих пор все было хорошо. Проблема, однако, состоит в том, как создавать продукты, на которые сейчас уходит не 20 или 30, а 5000 человеко-лет. Бригада из 7 человек может быть эффективна вне зависимости от своей организации, если задача целиком находится в ее компетенции. Но как использовать идею операционной бригады в задачах, для выполнения которых привлекаются сотни людей?
Успех при масштабировании обусловливается коренным улучшением концептуального единства каждого участка, ведь количество проектировщиков уменьшилось в семь раз. Поэтому можно привлечь к работе над задачей 200 человек, и необходимость координации умственных усилий потребуется всего для 20 из них - хирургов.
Вся система в целом должна обладать концептуальным единством, и необходим системный архитектор, чтобы проектировать ее целиком, в нисходящем направлении. Для того чтобы этой работой можно было управлять, необходимо провести строгое разграничение архитектуры и воплощения, и системный архитектор должен добросовестно посвятить себя разработке архитектуры. Опыт показывает, что такое распределение ролей и такие методы осуществимы и оказываются весьма результативными. Системный архитектор – это в прошлом ведущий разработчик. Требования к нему те же, но его опыт разработки должен быть еще больше, а также он должен обладать навыками управления.
Такая структура проекта, когда есть одновременно и менеджер проекта и равный ему по статусу ведущий разработчик и идеолог, требует тщательного подбора менеджера (поскольку ведущие разработчики в гораздо большем дефиците). Несмотря на кажущуюся дисфункциональность структуры с двумя руководителями, примеры большинства успешных компаний показывают, что их основателями было несколько человек, как минимум – двое. Также, например, Адизес пишет о невозможности совместить все роли по управлению проектом в одном человеке, и указывает оптимальную команду управления как предприниматель+исполнитель (ведущий разработчик и администратор+интегратор команды (менеджер).
Составлять пары ведущий разработчик + менеджер проекта можно, например, с помощью соционического анализа.
В то время как ведущий разработчик сосредоточен на продукте, топ-менеджмент компании должен быть сосредоточен на получении прибыли от продаж продукта. Высшее руководство организации должно также быть выходцами из разработчиков. Для топ-менеджера IT компании-разработчика коробочных программных продуктов крайне важно обладать достаточными знаниями технической стороны вопроса, чтобы оценивать идеи, рождающиеся в головах сотрудников компании. Высшие руководители должны внимательно следить за тенденциями мира IT, поскольку он подвержен частым изменениям, а время реакции на них может составлять от 1 до 10 лет! Таким образом, топ-менеджер IT компании-разработчика коробочных программных продуктов должен быть одновременно высококвалифицированным разработчиком ПО и предпринимателем, способным оценить новые идеи и перспективы. В руководстве, как и в проектных командах, должны быть профессиональные администраторы, однако как и в проектных командах, решающее слово всегда за техническими специалистами.
2. Модель жизненного цикла организации Ицхака Адизеса
И. Адизес предположил, что динамика организационного развития, носит циклический характер. Эту идею он заложил в основу теории жизненных циклов организации. Согласно модели Адизеса, в процессе жизнедеятельности организации можно выделить десять закономерных и последовательных этапов.
Рисунок 2 - Жизненный цикл организации по И. Адизесу
Этап первый. Ухаживание. Компании еще нет, но есть идея. Основатель лишь в мечтах представляет себе свой новый проект и то, что может из него выйти. Он собирает вокруг себя людей, которые постепенно вникают в его идею, принимают ее и соглашаются рискнуть и попробовать воплотить ее в жизнь.
Этап второй. Младенчество. На данном этапе компания не обладает еще четкой структурой и системой распределения полномочий и ответственности, основатель, возможно, работает больше всех. Его изнурительный труд и нежелание или неумение делиться полномочиями, а также акцент на краткосрочных результатах, пока важнейшие факторы выживания организации. Большое внимание уделяется результатам производства и удовлетворению потребностей конечных потребителей. Денег на этом этапе сильно не хватает – и это, кстати, вполне нормально.
Этап третий. «Давай-давай» (бурный рост). На этапе Давай-давай, дела компании идут успешно, и она начинает работать все продуктивнее, преодолевая первые препятствия. Люди осознают, что идея начала работать и может быть экономически эффективной. Меняется представление сотрудников о будущем компании - видение расширяется и охватывает практически безграничные горизонты. В компании до сих пор нет четкой структуры управления и прописанных функциональных обязанностей.
Этап четвертый. Юность. Компания очень сильно меняется на этом этапе. Даже если все было благополучно на предыдущих этапах, наступает момент, когда без порядка, системы и дисциплины дальнейшее развитие невозможно. У основателя компании возникает потребность в изменении структуры компании и делегировании полномочий. Делегировать оказывается сложно, поскольку чревато ошибками подчиненных, но без этого никуда. В компании появляются профессиональные менеджеры-управленцы, которые начинают менять структуру, систему мотивации и контроля. Приходят новые работники, что неизбежно ведет к конфликту двух культур: «старого костяка» и «новых специалистов», Люди теряют силы на внутренние войны, энергия, ранее используемая на продвижение на рынке, теперь расходуется на внутренние столкновения.
Этап пятый. Расцвет. На стадии расцвета организация одновременно гибка и управляема. Она имеет относительно четкую структуру, прописанные функции, системы поощрения и наказания. Сотрудники – главный актив в компании, им приятно работать в таких условиях, они талантливы и скромны, из них получаются отличные командные игроки. Успешность деятельности организации оценивается по двум факторам, таким как удовлетворения потребностей клиентов и достижения поставленных целей. Нередко на этой стадии организация открывает несколько дочерних предприятий, которые будут проходить все стадии развития так же с самого начала.
("5") Этап шестой. Стабилизация (Поздний расцвет). На этом этапе форма начинает преобладать над содержанием. Это первая стадия старения организации, когда компания постепенно отходит от политики быстрого развития, захвата новых рынков и расширения присутствия на существующих. Компания не стремится к изменениям, уделяя большее значение межличностным отношениям в коллективе, нежели рискам, связанным с ведением бизнеса. Но если в компании есть сотрудники, которые обеспокоены будущим компании, они стараются быть услышанными коллегами и руководством. Они стремятся пробуждать в других желание создавать. Они имеют шанс предотвратить дальнейшее старение организации.
Этап седьмой. Аристократизм. Компания владеет значительными финансовыми средствами, которые расходуются на обустройство собственной деятельности и укрепление существующей системы контроля. Появляются негласные формальные правила, связанные в первую очередь со стилем одежды и прочими традициями. Компания старается быть инновационной и генерировать новые продукты и идеи, приобретая (поглощая) другие компании, находящиеся на более ранних стадиях развития.
Этап восьмой. Ранняя бюрократизация. На этом этапе функция интеграции затухает: организация постепенно погружается в ряд сложных и порой неразрешимых структурных конфликтов, которые решаются путем увольнения сотрудников, но при этом, не меняя саму структуру. Постепенно внутренняя политика все сильнее отдаляет компанию от удовлетворения потребностей конечного потребителя.
Этап девятый. Поздняя бюрократизация. Компания полностью сосредоточивается на себе и на внутренних проблемах. Все сильнее запутывается внутренняя организация процессов. Нет склонности к повышению эффективности, изменениям, нет ориентации на потребности клиента. Поддерживается громоздкая и сложная система контроля над текущей деятельностью компании, которая требует от сотрудников соблюдения набора правил и процедур, но не эффективного труда.
Этап десятый. Смерть. Смерть предприятия, ориентированного на клиента, происходит сразу же после того, как клиенты массово перестают пользоваться услугами данного предприятия. Если же этого не происходит по причине того, что организация предоставляет монопольный продукт или поддерживается государством, то ее смерть может быть отсрочена во времени. В этом случае степень бюрократизации будет увеличиваться и в итоге все равно достигнет своего апогея, что приведет организацию к неминуемой гибели.
На практике теория Адизеса и его модель жизненного цикла организации дает весьма ощутимые результаты. Модель позволяет прогнозировать развитие событий и возникновение критических ситуаций, а значит, дает возможность подготовиться к ним надлежащим образом.
Как отмечает сам Адизес, в реальных компаниях каждый отдел находится на своем этапе жизненного цикла. Говорить о стадии жизненного цикла организации можно только в обобщенной форме. Поскольку в IT компании можно говорить о том, что менеджеры проектов являются и HR-менеджерами, будет целесообразно строить кадровую политику индивидуально для каждого подразделения, отдела либо направления разработки.
Также модель жизненного цикла можно упростить, объединив этапы «Поздний расцвет» и «Аристократия», «Ранняя бюрократия» и «Поздняя бюрократия», а этап «Смерть» для IT компаний ничем не отличается от аналогичного этапа в других отраслях.
Наличие продуктов либо отделов компании на стадии бюрократии может стать тем фактором, который будет препятствовать адаптации новых команд. Т. е. люди будут уходить в стартапы, чтобы им не мешали местные атавизмы. Поэтому при появлении признаков бюрократического поведения отделы или подразделения должны срочно реформироваться (дробиться на части, сливаться с другими подразделениями, руководящее звено и весь персонал, дублироваться новой аналогичной структурой), либо ликвидироваться.
3. Структура компании
IT компании-разработчику коробочных программных продуктов выгодно быть небольшой, т. е. работать в очень ограниченном спектре направлений. Это связано с тем, что руководить компанией в часто меняющейся среде непросто, а в случае наличия нескольких разных предметных областей один человек и вовсе не в состоянии за всем уследить. Только гении вроде Стива Джобса способны контролировать несколько разных продуктов, но даже он после своего возвращения в Apple сократил количество продуктов до 4 видов. Попытка работать по нескольким направлениям приводит к сильной децентрализации управления, т. е. глава компании уже не может эффективно управлять ее функционированием. В крупных IT компаниях-разработчиках коробочных программных продуктов (1С, Google и др.) руководители разработки каждой группы продуктов практически независимы от центра и зачастую сами определяют свою стратегию развития. С руководителем организации в целом согласовываются разные вопросы руководителей направлений, он может принимать решения только о инициации принципиально новых разработок, либо о ликвидации/продаже подразделений.
2. Подбор персонала
Подбор персонала является одним из ключевых аспектов кадровой политики IT компаний. Лидеры отрасли пользуются практически всеми существующими ресурсами для поиска сотрудников: от открытия своих образовательных программ в ведущих технических ВУЗах до поиска через кадровые агентства. За подбор хорошего специалиста Яндекс готов выплатить агентству до 23% годового оклада сотрудника. Естественно, что подбирать IT специалистов очень сложно не будучи специалистом в предметной области. Частично спасают профессиональные тесты, однако вакансии в «коробочных» проектах требуют не только знаний, но и определенного уровня мышления. Поэтому к менеджеру по подбору IT специалистов предъявляются суровые требования: он должен быть как квалифицированным HR, так и быть знакомым с внутренним устройством ПО. Именно в этой отрасли чаще всего встречаются HR-менеджеры с техническим образованием: проще научить методикам рекрутмента, чем алгоритмическому мышлению.
Персонал компании можно разделить на сотрудников, занятых в разработке и сотрудников, занятых в обслуживании и администрировании деятельности компании: секретари, уборщики, повара, охрана, техническая поддержка, отдел кадров (непосредственно кадровое делопроизводство) и т. д. Разумеется, поскольку компания стремится удерживать производственный персонал, то отношение к сотрудникам этих двух категорий должно быть по возможности одинаковым. Однако в целом кадровая политика IT компаний-разработчиков коробочных программных продуктов в отношении обслуживающего персонала не имеет принципиальных отличий от кадровой политики в других типах компаний. Поэтому в данной работе я рассматриваю политику только в отношении разработчиков и менеджмента компании.
Также поскольку для компании крайне важен положительный имидж HR-бренда, продукты на стадии бюрократии необходимо по возможности ликвидировать, либо срочно реанимировать путем привлечения новых специалистов извне. Если продукт подлежит ликвидации, то важно не привлекать в него новых перспективных сотрудников и руководителей.
Профили должностей необходимо иметь в компании. Однако следует иметь в виду, что, поскольку также необходимо допускать некоторые отклонения от общей корпоративной структуры в рамках каждого проекта (вследствие уникальности личности ведущего разработчика), профили должностей могут отличаться от продукта к продукту.
При открытии вакансии в первую очередь необходимо искать людей внутри компании. На менеджерские должности особенно важно готовить своих сотрудников внутри компании. Закрытая кадровая политика является вполне типичной для IT компаний-разработчиков коробочных программных продуктов.
Таблица 1 - методы подбора в зависимости от этапа жизненного цикла, на котором находится продукт
Ухаживание (поиск руководителей) | Младенчество | Давай-давай (бурный рост) | Юность | Расцвет | Аристократия | Бюрократия | |
Рекрутинг | + | + | + | + | + | + | |
Прямой поиск | + | + | + | + | + | + | + |
Head hunting | ++ | + | + | + | ++ | ||
Preliminaring | + | ||||||
Поиск внутри компании, кадровый резерв | +++ | ++ | + | ++ | + | ++ |
("6")
Таблица 2 - Источники подбора
Ухаживание (поиск руководителей) | Младенчество | Давай-давай (бурный рост) | Юность | Расцвет | Аристократия | Бюрократия | |
работные сайты | + | + | + | + | + | + | + |
специализированные форумы | ++ | + | + | + | + | + | |
внутренние ресурсы компании – корпоративный сайт, внутренний портал, доски объявлений, сотрудники | +++ | ++ | + | ++ | + | + | ++ |
кадровые агентства | + | + | + | + | + | + | |
профильные вузы | + | ||||||
СМИ | + | ||||||
коллеги | + | + | + | + | + | + | |
собственная база соискателей | + | + | + | + | + | + | + |
ярмарки вакансий | + | + |
("7") Именно на этапе расцвета есть смысл набирать либо людей без опыта работы, либо просто новых людей. На старте карьеры очень важно показать человеку как выглядит идеально организованная система. Подсознательно будущие предприниматели и руководители должны стремиться именно к расцвету своих продуктов, не останавливаясь на достигнутом, но и не пытаясь объять необъятное.
Кроме того, в более-менее стабильных условиях, при наличии эффективных регламентов и стратегий, ошибки сотрудников стоят дешевле: система в состоянии страховать сама себя. Новых людей проще адаптировать к корпоративной культуре компании именно когда она способствует расцвету организации.
Еще одним довольно распространенным способом набора персонала является покупка стартапов в интересующей компанию области бизнеса. Это весьма эффективный путь выхода на новый рынок, однако очень важно провести адаптацию новых команд разработчиков, чтобы все ключевые сотрудники остались в новой компании.
Нередки случаи, когда первое лицо компании самолично участвует в собеседованиях с кандидатами на ключевые технические (не управленческие) позиции. Например, глава компании «Фирма «1С»» общается со всеми потенциальными сотрудниками, нанимаемыми в Московский офис компании. Однако в случаях когда штат достаточно велик, и направлений, в которых развивается компания, достаточно много, даже первое лицо уже не может обладать всеми знаниями, которые необходимы для выбора лучшего кандидата. Кроме того, в больших компаниях с несколькими разными продуктами может оказаться ситуация, при которой внутренняя культура и традиции данного проекта будут отличаться от корпоративной культуры (например, если это недавно приобретенный стартап). Поэтому в больших компаниях выбор кандидата может осуществляться менеджером проекта либо направления.
Собеседование кандидатов-финалистов следует проводить в присутствии как менеджера проекта, так и ведущего разработчика, и других членов проектной команды, которые наиболее заинтересованы в новом человеке. Конечно, такой формат означает, что разработчики будут отвлекаться от своей непосредственной работы для беседы со сторонними людьми. Кроме того, собеседование сразу с группой людей является стрессом для кандидатов. Однако очень важно, чтобы команда осознанно приняла человека. Даже если не приходит «идеальный» кандидат, люди должны представлять себе из кого был сделан выбор.
Поскольку управление человеческими ресурсами находится в обязанностях менеджера проекта, решение об окончательном выборе человека принимает именно он, однако ведущий разработчик должен обладать правом вето.
3. Адаптация персонала
Адаптация вновь нанятых сотрудников производится силами менеджеров проектов. Задача по адаптации упрощается, поскольку в собеседовании кандидатов-финалистов участвовали все заинтересованные в новом человеке лица.
Если новый специалист не имеет достаточного опыта в новой предметной области, эффективной мерой адаптации будет назначить наставника из числа опытных сотрудников проекта.
В случае если компания приобрела стартап с целью развития его продукта силами его же команды разработчиков, очень важно при оформлении трудовых договоров (или доп. соглашений) отразить условия участия ключевых сотрудников в купившей их компании. Если их договоры предусматривали долевое участие в прибыли стартапа, новые договоры также должны сохранить мотивацию в зависимости от прибыли от продаж своего продукта – но меньше чем раньше, поскольку купившая их компания берет на себя определенную долю риска. Фактически покупка стартапа для дальнейшего развития должна оформляться скорее как слияние компаний нежели поглощение.
В остальном, адаптация IT разработчиков не имеет принципиальных отличий от адаптации в других отраслях, где важно командное взаимодействие сотрудников.
4. Обучение персонала
Поскольку персонал является основным ресурсом IT компаний-разработчиков коробочных программных продуктов, обучение является эффективным способом повышения их потенциала. Если стратегические планы компании предполагают развитие бизнеса в каком-либо направлении, необходимо начинать обучать людей заранее. В зависимости от новизны предметной области, обучение может занять до 5 лет (если привлечь готовых специалистов со стороны не представляется возможным).
Компания должна планировать развитие своих сотрудников в долгосрочной перспективе. Вот, например, как рекомендует растить проектировщиков (ведущих разработчиков) Ф. Брукс:
- Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие - не всегда самые опытные. Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой. Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности. Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.
Поскольку компания делает серьезные инвестиции в обучение персонала, целесообразно заключать ученические договоры с сотрудниками. По возможности следует производить обучение с выдачей дипломов государственного образца, поскольку в этом случае шансы взыскать деньги с сотрудника при расторжении трудового договора повышаются. Также, если компания достаточно крупная, есть смысл проводить внутренние курсы и тренинги с выдачей собственных сертификатов компании. Такие сертификаты будут менее ценны для других работодателей, поскольку информацию о реальном содержании курса труднее получить.
("8") Сотрудникам должны выделяться часы для обучения, в том числе и в рабочее время. Лидеры отрасли выделяют от 5% (IBM) до 20% (Google) рабочего времени для обучения либо собственных исследований и разработок, не связанных с текущей деятельностью.
Выявлением потребности в обучении должен заниматься менеджер проекта. Кадровая служба должна только собирать информацию и планировать бюджет обучения в зависимости от перспективности направления по мнению руководства.
Обучать необходимо всех сотрудников, с которыми связаны долгосрочные ожидания. Новые знания и навыки необходимы на любой стадии жизненного цикла проекта и организации в целом.
Таблица 3 Методы выявления потребности в обучении
Метод | Пояснение |
Оценка информации о работниках | Информация имеется в кадровой службе (стаж, опыт, базовое образование, принимал ли работник ранее участие в программах обучения или повышения квалификации и др.) |
Регулярная оценка рабочих результатов (аттестация) | В ходе процедуры могут обнаружиться не только сильные, но и слабые места в работе сотрудника. К примеру, низкая оценка за профессиональные знания показывает, что имеется потребность в обучении. После этого можно определять его конкретную форму и содержание |
Анализ долгосрочных и краткосрочных планов | Анализируются планы организации и отдельных подразделений. Устанавливается необходимый уровень квалификации и профессиональной подготовки персонала, позволяющий успешно реализовать планы |
Наблюдение за работой персонала | Выявленное в результате наблюдения за работой несоответствие стандартам и требованиям должностных инструкций может выступать индикатором потребности в соответствующем обучении |
Анализ источников проблем, мешающих эффективной работе | Если в организации есть проблемы, связанные с плохой работой, неоправданно большими потерями времени, то эта информация может быть использована как при подготовке программ обучения, и для обоснования заявок на обучение персонала тех или иных категорий |
Предложения работников | Такие предложения можно получать путем опросов или анкетирования работников |
Организация работы с кадровым резервом и планирование карьеры | В процессе работы с кадровым резервом и при планировании карьеры сотрудников менеджер проекта и специалисты кадровой службы получают дополнительную информацию о потребности персонала разных категорий в обучении |
Таблица 4 Методы обучения персонала на рабочем месте
№ | Методы обучения | Характерные особенности метода |
1 | Направленное приобретение опыта | Систематическое планирование обучения на рабочем месте, основу планирования составляет индивидуальный план развития |
2 | Производственный инструктаж | Общая информация, введение в специальность, адаптация, ознакомление обучающегося с новой рабочей обстановкой |
3 | Смена рабочего места (ротация) | Получение знаний и приобретение опыта в результате систематической смены рабочего места. В результате этого за определенный промежуток времени создается представление о многогранности деятельности и производственных задач |
4 | Использование работников в качестве ассистентов, стажеров | Обучение и ознакомление работника с проблемами высшего и качественно иного порядка задач при одновременном принятии на себя некоторой доли ответственности |
5 | Наставничество | Сотрудничество наставника и обучающегося, когда наставник обеспечивает непрерывную, беспристрастную обратную связь и периодически проверяет уровень исполнения работы у наставляемых. |
6 | Подготовка в проектных группах | Сотрудничество, осуществляемое в учебных целях проектных группах, создаваемых на предприятии для разработки крупных, ограниченных сроком задач |
("9")
Таблица 5 Методы обучения персонала вне рабочего места
№ | Методы обучения | Характерные особенности метода |
1 | Чтение лекций | Пассивный метод обучения, используется для изложения теоретических и методических знаний, практического опыта |
2 | Конференции, семинары, беседы за круглым столом, дискуссии, встречи с руководством | Активный метод обучения, участие в дискуссиях развивает логическое мышление и вырабатывает способы поведения в различных ситуациях |
3 | Кейс-метод обучения руководящих кадров, основан на самостоятельном решении конкретных управленческих задач из производственной практики | Моделирование организационной проблемы, которую должны решить участники (слушатели) группы. Позволяет соединить теоретические знания и практические навыки, предусматривает обработку информации, конструктивно-критическое мышление, развития творчества в процессах принятия решений |
4 | Деловые игры | Обучение манере вести себя в различных производственных ситуациях, при ведении переговоров, причем обладатели ролей должны вырабатывать и отстаивать альтернативные точки зрения |
5 | Тренинг | Тренинг—особый метод получения знаний, который отличается от своих аналогов тем, что все его участники учатся на собственном опыте настоящего момента. Это специально созданная благоприятная среда, где каждый может с легкостью и удовольствием увидеть и осознать свои плюсы и минусы, достижения и поражения |
6 | Самостоятельное обучение | Наиболее простой вид обучения, для которого не требуется ни инструктор, ни специальное помещение, ни специально выделенное время – обучающийся учится там, тогда и так, как ему удобно, но для этого нужна сознательность и желание самого обучающегося усваивать новые знания |
7 | Кружок качества (рабочая группа) | Специалисты разрабатывают конкретные решения по проблемам управления организацией, объединившись в отдельные группы. Разработанные в рабочих группах предложения передаются руководству организации, которое рассматривает предложения, принимает по ним решения и информирует рабочую группу о принятии или отклонении ее предложения |
5. Мотивация персонала
("10") Старт новых проектов производится в случае если руководство компании считает данное направление перспективным, а в штате есть технический специалист-идеолог. При этом, ведущий разработчик должен быть сосредоточен на продукте и удовлетворению нужд рынка, но схемы получения прибыли от реализации продукта могут быть не в его компетенции. Ведущего разработчика, имеющего одновременно и технические навыки, и знаний о нуждах пользователей, и навыки продаж и маркетинга найти будет практически невозможно. Поэтому руководство должно оценивать с финансовой точки зрения перспективность предполагаемых продуктов, а в дальнейшем выставлять требования к продукту, которые необходимы для успешных продаж.
В зависимости от того насколько перспективен проект (по мнению руководства), за его исполнение может назначаться премиальный фонд. Фонд может зависеть от объема проекта, срока фактического завершения (запуска) продукта, а также от его предполагаемой ценности. Если, по мнению руководства, направление является перспективным, но среди сотрудников компании нет технического специалиста, обладающего достаточными знаниями в предметной области и видением будущего продукта, ему следует назначить премиальный фонд за лучшее предложение своих сотрудников. Для этого программистам может выделяться до 20% рабочего времени (Google) на собственные проекты и исследования. Параллельно с проведением конкурса среди своих разработчиков будет целесообразно приступить к поиску специалистов, либо команд (стартапов) вовне. Если же проект не оценен руководством как перспективный, то премиальный фонд за проект не назначается.
Новые идеи возможных продуктов должны вывешиваться на корпоративном портале. У разработчиков и сотрудников компании должна быть возможность обсуждать ценность и перспективы будущего продукта. Компания должна стимулировать образование групп сторонников продукта, которые в будущем могли бы стать командой проекта. Разумеется, этот ресурс должен быть доступен только изнутри компании, и тем более важно, чтобы внешний мир не знал об авторе идеи. В противном случае конкуренты могут перекупить такого сотрудника, если руководство недостаточно высоко оценит его перспективу.
Не забываем правило: чем ближе сотрудник к конечному результату, тем больше его переменная часть зп. Разработчики коробочных программных продуктов гораздо сильнее влияют на результат, чем разработчики других IT-проектов, поэтому премиальная часть должна быть большой.
В случае если сотрудник становится руководителем (ведущим разработчиком) нового проекта, он автоматически становится более ответственным за результат. В этом случае могут заключаться доп. соглашения к трудовому договору, если необходимо изменить соотношение оклада и премий: сотрудник получает право на участие в прибыли от реализации нового продукта, либо на получение иных определенных доплат по результатам разработки. Новое соотношение оклада и премий определяется степенью риска, с которым связана новая разработка, а также степенью согласия руководства компании на инициацию проекта. В предельном случае, если проект не нашел поддержки у руководства, но бизнес-план признан жизнеспособным, сотрудник и его сторонники могут начать разработку за 1 МРОТ в месяц (с сохранением социального пакета), но при этом в случае успеха получить значительную часть от выгоды в случае успеха. Немногие согласятся работать в таких условиях, однако они наиболее приближены к условиям стартапа.
Эффективным методом мотивации будут ежеквартальные (если компания в целом на этапе роста) или полугодовые (если компания на этапах зрелости) собрания коллектива разработчиков, на которых каждый проект, завершившийся новым запуском, в течение 3-5 минут рассказывает о своих результатах. В конце презентации участникам вручается грамота, пожимает руки первое лицо компании. Также им вручается премия, зависящая от достигнутого результата и срока выполнения задачи.
Разработчик должен быть «счастлив работать здесь»: компании важен HR-бренд, а ее персонал должен осознавать себя лучшими из лучших. Поэтому сотрудники, которые добиваются новых успехов, должны быть на виду у коллектива и быть примером для подражания. Для тех же, кто слишком долго работает над продуктом без результата, стимулом к увеличению усилий будет служить падение авторитета среди коллег. Если результатов нет слишком долго, команда проекта может быть принудительно расформирована по другим, более эффективно действующим проектам.
Таблица 6 - Способы мотивации персонала на разных стадиях жизненного цикла компании
Ухаживание (поиск руководителей) | Младенчество | Давай-давай (бурный рост) | Юность | Расцвет | Аристократия | Бюрократия | |
Участие в прибыли | + | ++ | + | + | + | ++ | |
Субъективная выплата премий | + | ++ | + | + | |||
Выплата премий на основе экономических показателей | + | ++ | ++ | ++ | ++ | ||
Коллективные премии | + | + | + | ||||
Индивидуальные премии | + | + | + | ||||
Премии ключевым специалистам | + | + | + | + | + | ||
Выплаты в зависимости от квалификации | + | + | |||||
Долгосрочные мотивационные планы | ++ | + | ++ | + | + | ||
Сокращение выплат премий и снижение зарплат | + | + | |||||
Использование фиксированных выплат | + | + | + | + | + | ||
Различные системы выплат для старых и новых сотрудников | - | + | + | + | |||
Увеличение периода выплат премий | + | + | Может регулироваться по ситуации | + | |||
Гибкий график работы | + | + | + | ||||
Нематериальная мотивация | ++ | + | + | + | + | + | + |
("11") На этапах зрелости имеет смысл использовать систему грейдов. При этом важно учитывать, что значимость для компании руководящего персонала и технических специалистов должна быть равнозначной. Т. е. максимум зарплаты ведущего разработчика ключевого проекта должен быть того же порядка, что зарплата топ-менеджера. Именно такая система уровней персонала работает в компании IBM.
Возможность учиться, отправка сотрудников на различные курсы также окажет мотивирующее влияние. Тематика обучения должна быть по направленности близкой к основной деятельности компании. Однако поскольку речь идет о знаниях в предметной области и новых технологиях разработки, может быть целесообразно предоставлять возможность лучшим (перспективным) сотрудникам самим выбирать курс обучения.
Не следует экономить на социальном пакете для IT специалистов. Отрасль характеризуется высокими зарплатами, поэтому наличие ДМС, бесплатных обедов, оплаты проезда до места работы (либо оплата топлива для автовладельцев) может сыграть решающую роль в решении о смене места работы. Фактически сегодня перечисленные льготы предоставляются всеми лидерами отрасли (Яндекс, Касперский, Google, Microsoft и др.).
Поскольку компания заинтересована в появлении внутренних стартапов, это неизбежно означает, что должна поощряться сверхурочная работа. Например, в компании «Фирма «1С»» есть негласное правило, что сотрудники должны работать более 8 часов в день. Хотя многие IT компании-разработчики коробочных программных продуктов и декларируют гибкий график работы, на практике оказывается, что для того, чтобы поспевать за лучшими программистами, «середнячкам» необходимо работать больше. А «звезды», как правило, сами по себе люди увлеченные своей работой, и также зачастую склонны задерживаться до ночи.
Эффект «обыденности переработок» наблюдается в Японии, где пожизненный найм – норма для всех компаний в стране. Это еще одна причина чтобы удерживать сотрудников в IT компаниях-разработчиках коробочных продуктов максимально долгое время.
Сверхурочная работа должна оплачиваться, если она выполняется не по инициативе сотрудника. Однако основным мотиватором к труду более 8 часов в сутки должна быть культура компании, соревновательность и стремление доказать жизнеспособность своей идеи. Также более эффективно поощрять сотрудников работать сверхурочно за счет участия в будущих прибылях, либо денежных вознаграждений при выполнении задачи в кратчайшие сроки. В этих случаях труд следует оплачивать по обычной ставке, без учета лишних часов. Соответствующий пункт (о ненормированном рабочем дне) должен быть прописан в трудовом договоре.
Поскольку сотрудники мотивируются к задержкам после работы, организация может вступить в конфликт с их семьей. Поэтому для компании важно заботиться также и о личной жизни результативных сотрудников. В Касперском, например, предоставляют ДМС для всей семьи. Для компании целесообразно будет проводить корпоративные мероприятия для сотрудников с женами и детьми. Также для некоторых работников может быть важно, чтобы специальные люди, которым они доверяют, забирали их детей из детских садов/школ, кормили и сидели с ними пока родители не вернутся с работы.
6. Корпоративная культура
Для того, чтобы быть эффективной, IT компании-разработчику коробочных программных продуктов важно привлекать и удерживать лучших из лучших специалистов. Поэтому чем сильнее ее HR-бренд, тем больше шансов она имеет на выживание и дальнейшее развитие в перспективе.
Весьма показательной для IT компаний-разработчиков коробочных программных продуктов является компания IBM. Основу ее корпоративной культуры составляют три принципа: уважение к личности, гарантированная пожизненная занятость, единый статус работников.
Первичным элементом управленческой структуры IBM являются отношения между руководителем и подчиненным. Они контролируются специально созданным институтом - системой аттестаций и собеседований (САС). Ежегодно в ходе этих собеседований каждый сотрудник официально уведомляется о той оценке, которую получила его деятельность, а так же для него формулируются цели и задачи на следующий год и выделяются приоритетные направления. Эта система подразумевает письменное согласие работника с полученными формулировками, что является одновременно системой гарантии точности и обоснованности всех оценок и нормативов. От этой оценки будет зависеть зарплата работника в течении года. Статус каждого работника определяется абстрактным “уровнем”, величина которого напрямую с занимаемой должностью не связана и формально не подлежащая оглашению.
Поскольку зарплата работников обязательно должна пересматриваться раз в год, необходимо заключать с ними срочные договора на год, и перезаключать их в конце года. Учитывая, что размеры проектных групп редко превышают 50 человек, такой подход вполне осуществим на практике при разбиении сотрудников по разным юр. лицам. Конечно, заключение трудового договора на год выглядит противоречащим провозглашаемому принципу пожизненного найма, однако, во-первых, систему мотивации должна соответствовать текущему трудовому законодательству РФ, а во-вторых, если сотрудники не показывают тех результатов, которые планировались (по согласованию с ними самими) на предстоящий год, компании следует с ними расстаться.
Ключевой принцип кадровой политики IBM - гарантированная пожизненная занятость. В результате возникает необходимость регулярной переподготовки кадров и смены ими видов деятельности, при этом отдел кадров выступает в роли опекуна и обязан сделать все необходимое, чтобы работники реализовали свой потенциал.
Неотъемлемыми правами работников компании являются также равные возможности - единый статус. Хотя в IBM занято большое число временных сотрудников, работающих по контракту, и к ним отношение компании иное.
Отдел управления персоналом непосредственно отвечает за реализацию нескольких ключевых программ, от которых во многом зависит успех общей кадровой политики. Эти программы играют роль предохранительных клапанов, гарантируя каждому сотруднику независимое право на обращение к вышестоящему руководству.
Наиболее мощным инструментом кадровой политики IBM являются опросы общественного мнения, которые проводятся раз в два года. Это анонимные и добровольные опросы, охватывающие почти всех сотрудников IBM. По результатам этих опросов каждый руководитель готовит план действий по устранению выявленных недостатков и согласовывает его со своими подчиненными.
Также эффективным инструментом получения обратной связи от сотрудников является анонимная рассылка. В такую рассылку каждый сотрудник может анонимно написать то, что боится высказать от своего имени. На рассылку подписываются только те сотрудники, которые изъявляют желание, однако практика показывает, что большинство активных людей со своим мнением соглашаются принять в ней участие.
Очень сильным удерживающим фактором для сотрудников являются традиции длительной работы персонала в компании. Т. е. если сотрудники видят, что почти никто не покидает компанию, и что в новые проекты набирают людей прежде всего изнутри компании, то они перестают воспринимать переход к другому работодателю как разумную альтернативу решения текущих проблем. Тем более просто нанимать «на всю жизнь» людей, для которых данная компания является первым местом работы.
Главные люди в IT компании-разработчике коробочных программных продуктов – программисты, а менеджмент/маркетинг/продажи – вторая каста по значимости.
("12") Для развития идей в компании очень важен обмен внутренней информацией среди сотрудников. Именно те идеи, которые находятся на стыке разных областей деятельности одной организации, являются наиболее реализуемыми на практике. Ведь в этом случае велика вероятность, что все компетентные специалисты уже есть внутри компании, а целевая аудитория уже пользуется ее продуктами. Поэтому корпоративный портал, форум, на котором могут общаться сотрудники, да и просто «курилки» должны быть объектами заботы и пристального внимания HR-отдела. Благо почти 100% персонала компании – более чем продвинутые пользователи компьютера, и электронное общение для большинства из них не вызывает затруднений.
4.
Заключение
1.Состав и структура HR отдела
Поскольку функцией администраторов (менеджеров) проектов является в том числе и управление человеческими ресурсами, и эти же администраторы должны находиться также в составе высшего руководства, HR-отдел должен иметь достаточно большую численность даже в сравнительно небольших компаниях. Требования к HR-специалистам здесь выше, чем в других отраслях из-за специфики IT. Во многих IT компаниях HR-директорами являются люди с техническим образованием.
Исходя из вышеописанных особенностей, для разработчиков коробочных программых продуктов наиболее эффективной будет следующий состав подразделения ответственного за HR:
инспектор по кадрам.
инспектор по воинскому учету. Для достаточно крупных компаний важно иметь выделенного сотрудника, поскольку многие разработчики – молодые мужчины. Проблемы с армией могут иметь весьма неприятные последствия, и компании может быть полезно иметь отдельного специалиста для консультаций, защиты сотрудников и помощи в получении необходимой отсрочки/избегания призыва. Входит в состав отдела кадров.
инспектор по охране труда и технике безопасности. Условия труда разработчиков ПО связаны с достаточно низким риском с точки зрения охраны труда, поэтому иметь отдельного специалиста на эту должность выгодно только в достаточно крупных компаниях. Тем не менее, роль такого специалиста весьма важна, поскольку многие разработчики очень требовательны к условиям труда. В таких компаниях, как Google и Яндекс, разработчикам дается возможность обустроить рабочие места полностью по своему желанию (вплоть до кабины самолета), что значительно усложняет прохождение проверок техники безопасности. Специалисты входят в состав административно-хозяйственного отдела (АХО).
менеджер по подбору. Поскольку менеджеры проектов должны обладать навыками в области HR, небольшим компаниям необязательно иметь выделенного человека на эту роль.
менеджер по компенсациям и льготам. Очень важная роль, поскольку спектр возможных льгот и социальных программ должен быть весьма широк. В небольшой компании эту роль может исполнять HR-директор + менеджеры проектов, в более крупных компаниях это должен быть специально выделенный человек. Входит в состав отдела организации труда и заработной платы.
менеджер по обучению. Эту роль должен выполнять менеджер проектов. Однако в достаточно крупных компаниях появляется необходимость в соответствующем отделе, поскольку в этом случае организация уже может себе позволить обучать персонал своими силами. Входит в состав отдела развития персонала.
менеджер по аттестации. В небольшой компании эту роль должен выполнять менеджер проектов при участии HR-директора. Однако, если компания достаточно крупная, следует иметь специальный отдел, либо, как в IBM, привлекать к аттестации всех ключевых сотрудников, взаимодействующих с оцениваемым, а также вышестоящего руководителя. Входит в состав отдела оценки и аттестации персонала.
менеджер по адаптации. Эту роль должны выполнять менеджеры проектов.
Рисунок 3 - Часть оргструктуры IT компании-разработчика коробочных программных продуктов, связанная с управлением персоналом
На Японских предприятиях, численность отдела управления персоналом составляет 2-5% от общей численности занятых. В случае IT компаний-разработчиков коробочных программных продуктов, где уместно применять принцип пожизненного найма, большое количество сотрудников в отделе управления персоналом также оправдано.
2.Критерии оценки эффективности
Итак, мы обозначили все ключевые аспекты кадровой политики IT компаний-разработчиков коробочных программных продуктов. Были перечислены возможные инструменты и методы, с помощью которых можно построить систему управления человеческими ресурсами. Однако как же добиться ее эффективности?
Оценивать работу HR-отдела компании следует по следующим показателям.
Стратегические показатели в области управления персоналом
Приверженность сотрудников ключевым ценностям корпоративной культуры ("13") Приверженность организации и удовлетворенность трудом сотрудников по данным опроса; Рост компетенций персонала; Текучесть кадров (по уровням результативности сотрудников); Понимание сотрудниками целей и задач компании; В какой мере отбор, оценка деятельности и система мотивации стимулируют развитие и обмен знаниями среди сотрудников; % сотрудников, вносящих рационализаторские предложения, идеи решения организационных проблем; % внутреннего заполнения вакансий; % сотрудников, включенных в оперативный и стратегический кадровый резерв; % сотрудников, обладающих более широким опытом работы, чем требует их нынешняя должность; % удержания высокопотенциальных и результативных сотрудников; Результативность сотрудников, работающих в компании не более 1 года; % реализованных сотрудниками целей развития; Численность кадровой службы в % к среднесписочной численности персонала; Рейтинг привлекательности компании как работодателя на рынке труда.Эффективность управления персоналом
Как много исключительных, выдающихся кандидатов мы отбираем на стратегически важные позиции? Какая часть нанимаемых сотрудников отбирается на основе надежных методов оценки? В какой мере наша компания использует профессионально, качественно разработанную модель компетенций при отборе, развитии, оценке деятельности и вознаграждении сотрудников? Какое количество часов в год обучается каждый новый сотрудник (в рамках программы адоптации, программ развития)? Какая часть сотрудников получает в течение года обратную связь через процедуру круговой оценки на 360(? ("14") Какая доля переменной части оплаты сотрудников определяется на основе оценки деятельности (отдельно по уровням управления, по подразделениям)? Какая часть сотрудников включена в программы премирования по итогам года, акционирования, участия в прибылях? Какова разница (%) в размере премиальных между высокорезультативными и низкорезультативными сотрудниками?Разумеется, в зависимости от того на каком этапе развития находится компания и ее отделы в частности, разные из этих показателей будут выходить на первый план. Соответственно и система KPI также может зависеть от стадии жизненного цикла.
Внедрение описанных в работе практик позволит IT компании, которая видит свое будущее в разработке коробочных программных продуктов, организовать действительно эффективный бизнес. Со временем, любая компания отрасли, построенная на принципах поддержки внутреннего предпринимательства, пожизненного найма и ориентации на высококлассных профессионалов может повторить успех Microsoft, Google и IBM. Кадры решают все, и это особенно верно для IT компаний-разработчиков коробочных программных продуктов!
5.
Источники
1. «Мифический человеко-месяц, или Как создаются программные системы», Ф. Брукс, издательство Символ-Плюс.
2. «Управление жизненным циклом корпорации», И. Адизес, издательство «Питер», 2008 г.
3. «Система мотивации на разных этапах жизненного цикла компании»,
Успенская Екатерина, журнал «Финансовый директор», № 9 за 2005 год
4. Курсовая работа «Мотивация – как функция управления», , Калужский Филиал Санкт – Петербургского Государственного Университета сервиса и экономики, 2007 г.
5. «Интервью с Борисом Нуралиевым», Юлиана Петрова, Сomputrewiew, #11-1999
preview_end()
