Peculiarities of Personnel Management in IT-Companies.pdf Введени еВ настоящее время в сфере информационных технологий распростра-нена ситуация, когда руководство компании заботится обо всех своихпроцессах: технологических процессах производства, бизнес-процессахи т.д., но не уделяет должного внимания процессам по управлению пер-соналом и кадровым проблемам.По причине особой специфики производства программных продуктовсотрудники воспринимаются руководством как некоторая система ком-пьютеров или точных информационных систем. Такое отношение к про-цессу управления персоналом приводит к неудовлетворительной реали-зации проектов компании. Организация работы сотрудников IT-компаниизаслуживает особого внимания.1. Основны е ошиб ки при организ аци работыи мотив аци персоналаПри организации работы и мотивации персонала часто допускаютсяследующие ошибки:1. Не учитывается «человеческий фактор». То есть руководство частозабывает, что подробно расписанный график работ является всего лишьпримерным и, самое главное, желаемым сценарием проведения работ. Наделе всегда возникают обстоятельства, препятствующие оптимальнойреализации проекта, а именно:а) Рутинная работа, если она не чередуется с творческой, всегда вы-полняется менее качественно. Поэтому следует чередовать виды работдаже в пределах одного проекта (например, тестирование, подготовку до-кументации и работу в команде с программистами по выяснению причиндефекта и способов его устранения).б) При распределении должностных обязанностей следует учитывать,что люди, занимающие руководящие должности, должны обладать нетолько высокой степенью профессиональной подготовки, но и определен-ными личностными качествами, такими, как умение быстро приниматьрешение и брать на себя ответственность, стрессоустойчивость, коммуни-кабельность, умение быстро разбираться в новом материале и т.д.В настоящее же время менеджерами проекта становятся просто лучшиепрограммисты. В какой-то мере это оправдано, так как человек, обладаю-щий отличными профессиональными качествами, может в определенныймомент «спасти» проект, заменив собой ведущего разработчика. Но онможет и создать проблемы при реализации проекта, не сумев правильнораспределить роли между разработчиками, не уделив должного вниманиявсем аспектам разработки (а не только программированию) и т.д.2. К каждому сотруднику нужен индивидуальный подход. То есть сле-дует знать сильные стороны каждого сотрудника, способы его мотивациик лучшей работе и использовать их при работе с персоналом.Можно условно разделить все способы мотивации персонала, приме-няемые в современных компаниях, на следующие категории:а) материальное поощрение (денежное премирование);б) повышение в должности;в) поощрение льготами (например, премирование дополнительнымотпуском);г) поощрение грамотами и благодарственными письмами различногорода.К каждому сотруднику нужен индивидуальный подход, но зачастуювыбор сводится к стандартным способам мотивации. Наиболее распро-странена практика повышения заработной платы и премий всем сотруд-никам на одинаковое количество процентов. Эффективнее было бы ввестиболее сложный коэффициент повышения денежного вознаграждения.2. Расчет повыш ени я заработн ой пл аты сотрудни каРассмотрим пример расчета денежного вознаграждения сотрудникаотдела контроля качества. Сначала введем следующие обозначения:SP (Salary Pay) - текущая заработная плата сотрудника.SPnew (Salary Pay new) - новая заработная плата сотрудника, это и естьискомая величина, которую следует высчитать для сотрудника.CS (Company Seniority) - коэффициент стажа работы в данной ком-пании. Следует учитывать тот факт, что сотрудник, давно работающий вкомпании, вызывает больше доверия и имеет право на предпочтительноеотношение за счет своих заслуг перед компанией в период своей работы.Величина CS рассчитывается по формуле(1)GS (General Seniority) - коэффициент общего стажа работы по спе-циальности. Вполне логично, что работник, имеющий больший стаж ра-боты по специальности, является в подавляющем большинстве случаевлучшим специалистом, такому сотруднику можно доверить более ответ-ственную работу. Поэтому наличие у сотрудника большого стажа работыдолжно быть отмечено со стороны руководства. Величина CS рассчиты-вается по формуле(2)VPC (Valuation Personal Coefficient) - персональный оценочный коэф-фициент. Данный коэффициент проставляется каждому сотруднику егонепосредственным руководителем и отражает субъективную оценку со-трудника. Такая оценка также необходима, так как кроме фактическихоценок (стаж и опыт работы в компании) необходима оценка непосред-ственного руководства отдела, заинтересованного в скорейшем и наилуч-шем выполнении задач, поставленных высшим руководством. Данныйкоэффициент проставляется по усмотрению руководителя и может при-нимать значения от 0 до 0,5.PC (Project Coefficient) - коэффициент проекта, в котором работаетсотрудник. Данный коэффициент отражает, насколько важен и сложенпроект, в котором работает данный сотрудник. Чем важнее и прибыль-нее проект, тем больше ответственность сотрудников, задействованных внем. Данный коэффициент высчитывается по формулеPC = FLC + PfC,где FLC (Foreign Language Coefficient) - коэффициент за работу на ино-странном языке. Данный коэффициент является логической величиной иможет принимать одно из двух значений:FLC = 0, если проект русскоязычный, так как работа на родном языкене отягощена дополнительными сложностями (как, например, в случаеработы на иностранном языке);FLC = 0,01, если проект иностранный.Коэффициенты достаточно малы (сотые доли единицы), так как, какправило, один сотрудник участвует в нескольких проектах - это распро-страненная практика. Поэтому, чтобы не раздувать стоимость проекта засчет высоких коэффициентов (и, как следствие, завышенных заработныхплат) сотрудников, коэффициенты выбраны подобным образом.PfC (Profit Coefficient) - коэффициент прибыльности. Данный коэффи-циент также является составляющей коэффициента проекта и отражаетдолю проекта в финансовом состоянии компании. Он рассчитывается какдоля проекта (или, говоря иначе, часть денег, приносимых данным про-ектом, разделенная на 100% дохода);Новая заработная плата сотрудника получается путем суммированиятекущей заработной платы и величины, полученной в результате пере-множения текущей заработной платы на сумму всех коэффициентов, сучетом формул (1) и (2), а именно:, (3)где i =1 ... n - номер проекта, в котором работает сотрудник, т.е. проис-ходит суммирование коэффициентов всех проектов, в которых участвуетсотрудник (один работник, как было сказано выше, может быть вовлеченв несколько проектов).Все коэффициенты подобраны в соответствии со степенью важностиих влияния на коммерческую стоимость проекта.Теперь рассмотрим формулу расчета повышения заработной платысотрудника отдела контроля качества на конкретном примере.Допустим, заработная плата сотрудника в настоящий момент временисоставляет 20 000 рублей, стаж работы в компании составляет 1 год, аобщий стаж работы по специальности 2 года. Данный сотрудник занятв трех проектах в компании. Два из них - иностранных заказчиков, долякаждого из них в состоянии компании составляет по 1/5 (т.е. прибылькомпании на 2/5 состоит из денежных средств, приносимых даннымипроектами). Доля русскоязычного проекта составляет 1/3 в состояниикомпании. Руководитель, несмотря на небольшой стаж сотрудника, оце-нивает его работу как отличную и ставит высокий персональный оценоч-ный коэффициент, равный 0,5. Таким образом, получается:SP = 20 000; PfC1 = 0,03;CS = 1/100 = 0,01; PfC2 = 0,02;GS = 2/100 = 0,02; PfC3 = 0,02;VPC = 0,5; PC1 = 0,03;FLC1 = 0; PC2 = 0,03;FLC2 = 0,01; PC3 = 0,03.FLC3 = 0,01;По формуле (3) имеем:SPnew = 20000 + 20000*(0,01 + (0,02 - 0,01) + 0,5 + 0,09 = 23200.Это новая заработная плата сотрудника.Процесс проверки системы и поиска ошибок представляет собойчереду творческой работы по поиску скрытых дефектов и выполнениерутинной работы по осуществлению дымового тестирования (т.е. тести-рование только основных функций программного продукта, их число,как правило, не превышает 5 основных) и проверки всех элементов GUI(Graphical User Interface - набор элементов и функций программы, види-мых для ее пользователя).3. Повыш ени е эф ективн ости путём организ ациработы персоналаВсе проблемы, возникающие в проекте только по причине недоста-точно высокого качества работы персонала, можно разделить на тригруппы:1) срыв сроков сдачи проекта;2) большое количество дефектов в полученном программном продукте;3) несоответствие полученного программного продукта требованиям,заявленным заказчиком в спецификации.Указанные проблемы обычно решаются путем увеличения штатов со-трудников. Рассмотрим данный способ решения проблем подробнее.Программные проекты чаще «разваливаются» из-за нехватки кален-дарного времени. Причина такой ситуации в современных IT-компанияхзаключается в следующем:1. Слабо развитая система оценок, т.е. оценка ликвидности проектанеадекватна и редко совпадает с реальным прогнозом, который можнобыло бы получить, проведя более подробный анализ и оценку возмож-ностей компании.2. Методы оценки ошибочно путают достигнутый прогресс с затра-ченными усилиями, т.е. если для решения задачи пришлось приложитьбольшое количество средств и усилий, то она сразу же переходит в разрядсложных и значимых, хотя на самом деле таковой не является, просто дляее решения у компании не было необходимых средств и опыта.3. Сложности в общении с заказчиком из-за того, что менеджеры про-ектов не уверены в своих оценках. Не обладая достаточными средства-ми для проведения оценочных мероприятий, менеджеру проекта труднобыть убедительным и привести серьезные доводы в защиту своего про-екта временного и финансового плана.4. Недостаточный контроль выполнения графика работ. К сожалению,данный аспект полностью попадает в разряд «человеческого фактора» ив большой степени зависит от личностных качеств менеджера проекта.Кроме того, управление группой разработчиков, занимающихся про-изводством программного обеспечения (ПО), несколько отличается отуправления другими категориями работников и имеет ряд своих особен-ностей, о которых будет сказано ниже.5. Стремление команды, работающей над проектом, к скорейшейсдачи очередного этапа проекта, не задумываясь о качестве продукта ипроцессов разработки в целом. Это выражается в том, что когда остает-ся мало времени до сдачи очередного прототипа системы, определеннаячасть функций программы на данный момент не является стабильной,поэтому все элементы программы, увеличивающие риск провала испы-таний, убираются из прототипа. Таким образом, над проектом нависаетугроза деградации, и очень часто данная угроза переходит в разряд дей-ствительности.6. Очень часто программный продукт передается заказчику, не являясьпродуктом надлежащего качества. Причина этого явления заключается вследующем: неправильное распределение проектного времени повлеклоза собой тот факт, что программный продукт был отдан на тестированиев отдел контроля качества не своевременно. Причем нежелательна какслишком поздняя передачаверсии, так и слишком ран-няя.Лучше всего сравнить раз-личные варианты выбора вре-мени начала тестирования, ис-пользуя графики зависимостивремени от найденных дефек-тов (рис. 1).Рассмотрим график 1 нарис. 1. Прототип системы былпередан на тестирование, ког-да еще не все функции про-граммы были реализованыпрограммистами в полномобъеме. Так как программи-сты вынуждены тратить боль-шую часть своего временина реализацию обязательныхфункций системы, то у нихостается очень мало временина устранение дефектов, най- Рис. 1. График зависимости количества най-денных дефектов от времениденных тестерами. Поэтому процесс устранения происходит медленны-ми темпами. Это видно из графика: сначала количество дефектов оста-ется на прежнем уровне достаточно большой период времени, а потом,когда у программистов появляется время для устранения ошибок (когдавсе основные функции программы реализованы), начинается процесс ис-правления ошибок, но, к сожалению, тогда остается уже слишком маловремени, поэтому к моменту завершения проекта, т.е. когда необходимосдавать систему заказчику, программа еще фактически не готова к экс-плуатации. Не следует отдавать прототип системы на тестирование слиш-ком рано, так как тестирование «сырой» системы только отнимает времяу тестера, поскольку данные ошибки являются скорей недоработками попричине отсутствия времени, о которых программисту и так известно.У программиста, в свою очередь, в этот момент нет времени на исправ-ление найденного тестером большего числа дефектов, так как еще не доконца реализованы основные функции.Рассмотрим график 2. Самая распространенная ситуация, когда тести-рование начинается непосредственно перед сдачей (иногда сроки особенно«экстремальны», например, тестирование начинается за 1-2 дня до сдачипроекта заказчику с расчетом на то, что программисты все сделали безошибок), но так как ошибки возникают всегда (невозможно создать иде-альную систему с первого раза), то времени на устранение дефектов оста-ется слишком мало, даже несмотря на то, что программисты полностьюсвободны во времени для исправления ошибок (так как на написание обя-зательных функций они время теперь не тратят). По сути, исполнитель насвой страх и риск отдает заказчику неоттестированную версию продукта.Рассмотрим график 3. В ситуации, когда у команды, работающей надпроектом, есть достаточно времени на разработку прототипа и фаза ак-тивного тестирования наступает вовремя - сразу после завершения работпо разработке, и тестеры, и программисты имеют достаточное количе-ство времени для совместного обнаружения и устранения дефектов.К сожалению, такая идеальная ситуация - очень большая редкостьв современных IT-компаниях. Поэтому задача руководства - правильнорассчитать сроки сдачи проекта и распределить силы таким образом, что-бы график сходимости для данного конкретного проекта был максималь-но приближен к графику 3, изображенному на рис. 1.При обнаружении отставания от графика или несоответствия получа-емой продукции заявленным требованиям общепринятой реакцией явля-ется увеличение числа сотрудников. В этом заключается основная ошиб-ка аппарата управления персоналом. Теория о том, что такие величины,как «число месяцев» и «число разработчиков», могут быть взаимозаме-няемыми, неверна для современного процесса разработки программныхпродуктов. Зачастую задачу нельзя разбить на части, выполняемые па-раллельно и независимо, и отдать на реализацию разным исполнителям,так как модули системы связаны и реализация одного модуля невозможнадо завершения реализации другого модуля. Если задачу нельзя разбитьна части, то увеличение затрат не оказывает влияния на график. Боль-шинство задач коммерческого программирования как раз носят такой ха-рактер. Даже если и существует возможность условно разбить большуюзадачу на несколько частей для реализации несколькими сотрудниками,то все равно требуется время на коммуникацию, обмен информацией исогласование действий между сотрудниками, реализующими разные мо-дули будущей системы.Таким образом, руководство само загоняет себя в тупик, так как уве-личение штата сотрудников влечет за собой увеличение временных за-трат на коммуникацию между сотрудниками и согласование действий поразработке продукта. К тому же большее количество сотрудников требуетбольших усилий по управлению как персоналом, так и процессами. Боль-шинство задач, с которыми сталкивается разработчик, могут быть раз-биты на части, но требуют обмена данными между подзадачами. Крометого, каждого нового сотрудника надо обучить технологии, целям про-екта, общей стратегии и плану работы. Это обучение нельзя разбить начасти, поэтому данная часть затрат изменяется линейно в зависимостиот числа занятых. Поскольку создание программного продукта являетсяпо сути системным проектом - практикой сложных взаимосвязей, затра-ты на обмен данными велики и быстро начинают преобладать над со-кращением сроков, достигаемым в результате разбиения задачи на болеемелкие подзадачи [1]. Таким образом, на определенном этапе количествовремени, потраченного на проект, прямо пропорционально количествуразработчиков, занятых в данном проекте.Более эффективным решением будет следующее. Необходимо создатьнебольшую специальную группу, состоящую из разработчиков, тестера ианалитика (примерно 1/5 от численности команды, работающей над про-ектом). Основная группа программистов на ранних этапах разработки за-нимается созданием нового функционала, тестировщики и инженеры покачеству из основной группы на данном этапе ведут активную работу саналитиками по разработке системы, а специальная группа в это время за-нимается тестированием и доработкой уже разработанного функционалав режиме экстремального программирования. Работники, входящие в со-став специальной группы, должны быть лучшими специалистами отдела,иметь способность быстро и эффективно решать поставленные задачи.Если специфика проекта и профессионализм персонала позволяютразделить проект на несколько автономных задач, тогда есть возможностьразбить команду на две равнозначные группы и организовать работу потакому принципу: команда А разрабатывает новый функционал, затемприступает к его тестированию и доработке. Когда команда А занима-ется тестированием и доработкой, команда В разрабатывает свой новыйфункционал, и, когда команда В приступает к тестированию и доработкесвоего функционала, команда А снова приступает к разработке новогофункционала. Схема такого взаимодействия представлена на рис. 2.По данной схеме работы требуется усиленный контроль со стороныменеджера проекта, но зато при этом исключается ситуация, когда коман-да сначала в авральном режиме разрабатывает новую программу, а потомнеоттестированный продукт передается заказчику, или разработка новогопродукта откладывается по причине того, что команде необходимо времяна стабилизацию системы.Заключ ени еПроцесс управления персоналом является столь же важным, как и тех-нологические процессы производства. К тому же это мощный инструментповышения качества производимой компанией продукции. Организацияработников - специалистов сферы IT имеет свои особенности, грамотноиспользуя которые, можно значительно повысить эффективность труда.

Скачать электронную версию публикации