Организационная структура и разделение труда в ИТ - отделах
При упоминании о труде в сфере информационных технологий, в голове у многих возникает образ «помятого хакера», безвылазно сидящего за компьютером и обладающего исключительными, уникальными знаниями и навыками. Автор возьмет на себя смелось предположить, что это не совсем верно, поскольку помимо подобных единичных специалистов, занимающихся сложными проектами, которых не так много, довольно существенная часть работы рассматриваемых направлений носит рутинный характер и, следовательно, поддается формальному описанию.
В двух словах функция ИТ- службы сводится к поддержанию и развитию информационной среды компании. Она в свою очередь включает в себя помимо непосредственно информации, порождаемой внутри организации, также технические средства для хранения и обмена ею. Исходя из этого, ИТ -специалист - это не профессионал во всех сферах от сборки схем до программирования, а узкоспециализированный работник, владеющий достаточным объемом знаний в каком-то одном направлении деятельности. Условно можно разделить работников ИТ -подразделений на:
- Системных администраторов - как правило, занимаются организацией сети внутри компании, установкой и настройкой программного обеспечения, различных сервисов.
- Специалисты технической поддержки – привлекаются для установки и настройки компьютеров, телефонов, сетевых подключений, отладки серверов и принтеров. Могут организовывать закупку техники, но в крупных организациях эта функция передана отделам снабжения.
- Программисты - довольно широкий перечень специалистов, начиная от разработчиков вебсайтов и модулей учетных программ и заканчивая создателями собственных законченных продуктов.
В мелких компаниях труд первых двух категорий работников может выполнять сотрудник в одном лице, а программирование быть передано в сторонние фирмы. В средних и крупных компаниях создается полноценная ИТ служба, примерная структура которой в соответствии с описанными выше направлениями может выглядеть следующим образом.
В зависимости от рассматриваемой категории специалистов будет существенно отличаться перечень выполняемых ими работ, а соответственно и доступные для применения методы нормирования.
Выбор метода нормирования для ИТ - служб
Как для большинства профессий интеллектуального труда в области нормирования описываемой сферы можно пойти двумя путями:- Использовать прямое нормирование по трудозатратам с применением одного из методов их расчета:
- Путем проведения хронометража или фотографии рабочего времени;
- На основе подходящих типовых межотраслевых норм;
- Посредством экспертной оценки и проведения опросов специалистов, накопленных статистических данных.
- Использовать косвенный поход, сразу рассчитывая норму численности исходя из факторов, оказывающих на нее влияние.
Если в первом случае сложность заключается в выборе адекватной методики сбора данных и расчета для того или иного перечня работ. Во-втором, наибольшие проблемы будут с корректным выбором влияющих на необходимую численность факторов и накоплении требуемых для расчета статистических данных.
Попробуем определить для каких категорий специалистов, какие методы будут наиболее приемлемыми.
Первые две категории специалистов на 2/3 выполняют рутинные операции, с которыми сталкиваются ежедневно при поддержке пользователей и оборудования, периодически у них возникают нетипичные задач, например завоз нового типа серверов, который нужно настроить. Для таких случаев и пригодится экспертный метод.
Что касается программистов, то здесь вопрос довольно неоднозначный, проводить фотографию рабочего дня для них, дело неблагодарное, да и ненужное. В то же время, говоря о программистах, допустим в 1-с, нельзя сказать, что их работа совсем уж эксклюзивна. Ведь довольно часто они делают отчеты по одному и тому же шаблону, меняя только ссылки на переменные. Но даже им нередко задают нетиповые задачи, требующие новых подходов к решению и значительных затрат времени. Поэтому им все же ближе экспертный и косвенный метод определения трудозатрат. Для определения трудозатрат по эксклюзивным программным проектам есть попытки создания специфических методов расчетов.
Традиционные подходы к определению трудоемкости работ отдела ИТ
Для «рутинной» работы ИТ отделов наиболее простым способом расчета трудоемкости будет применение Постановления Министерства труда и социальной защиты Республики Беларусь от 23.03.2011 № 19 «Нормы времени на работы по обслуживанию персональных электронно-вычислительных машин, организационной техники и офисного оборудования».
Приведенный в нем перечень вполне охватывает большую часть списка производимых системными администраторами операций, связанных с подключением, настройкой и обслуживанием вычислительной техники. Но, практически не учитывает возникающую необходимость установки и настройки новых приложений. Для устранения данного пробела можно проводить дополнительные исследования затрат времени при загрузке и отладке программ. Для этого можно применять ФРД, хронометраж, либо комбинации этих методов.
Расчет трудоемкости при этом происходит по довольно простой формуле:
Тр = ∑H ×V,
Где:
H - норма времени на единицу работ;
V - количество работ указанного вида за период
При этом для не предусмотренных нормативами разовых, несистематических работ допускается дополнительное применение коэффициента 1,05.
Определенная по формуле приведенной выше трудоемкость служит базой для расчета плановой численности сотрудников ИТ-отдела по формуле:
Ч = Тр×Ккор /Фр×60 ×Kн,
где: Ф_р - фонд рабочего времени одного работника за год;
K_н - коэффициент невыходов (использования рабочего времени), рассчитанный по формуле
K_н=1+(% невыходов)/(100%)
K_кор - корректирующий коэффициент на разовые работы.
Объемы работ, которые необходимо будет выполнить в текущем году, целесообразно брать на основе статистики предыдущего года с учетом введения новых рабочих мест и возможных организационных и технических изменений.
Имея на руках плановый перечень работ и полученные статистически данные по их частоте можно прогнозировать трудовые затраты системных администраторов путем умножения количества работ на норму. Этот расчет можно оформить в формате таблицы, например, как приведено ниже.
Наименование
работ
|
Ед. изм.
|
Объем работ
на 12 мес.
|
Номер
таблицы
|
Номер нормы
|
Норма
времени на единицу работ
|
Временные
затраты всего, минут 9 (6х3)
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
Администрирование активного сетевого
оборудования с аппаратно-программной настройкой (коммутаторы)
|
устройство
|
186
|
19
|
1
|
35
|
6510
|
Сервисное сопровождение и обслуживание
программного обеспечения активного сетевого оборудования
|
устройство
|
250
|
19
|
2
|
211
|
52750
|
Сопровождение FTP-сервера
|
сервер
|
14
|
13
|
2
|
70
|
980
|
Всего
|
60240
|
На 2018 год фонд времени по календарю (максимальный) - 2016 часов, используя К_кор = 1,05, К_Н=1,10 можно посчитать необходимую численность системных администраторов на основе формулы выше и данных о трудозатратах:
60240 х 1,05/ 2016 х60 х 1,10 = 0,58 = 1 чел.
То есть для выполнения указанного объема работ достаточно иметь одного сотрудника или отдать эти функции на аутсорсинг.
А как же быть с программистами? К счастью, для них также есть Постановление Министерства труда и социальной защиты Республики Беларусь от 27.06.2007 № 91, в котором приведены необходимые нормы. В то же время в его основу положен метод функциональных точек, который потребует проведения экспертных оценок с целью выявления их количества и последующего корректного применения временных нормативов для каждой из них.
В связи с этим, определение трудоемкости, вероятнее всего, потребует от нормировщика более глубокого погружения в тонкости процесса разработки ПО. Указанный документ стандартизирует процесс программирования, разбивая его на следующие стадии:
- Техническое задание (ТЗ);
- Эскизный проект (ЭП);
- Технический проект (ТП);
- Рабочий проект (РП);
- Ввод в действие (ВН).
Помимо этого предлагается учитывать в качестве влияющих на длительность процесса следующие факторы:
- объема ПО в строках исходного кода (LOC);
- сложности разрабатываемого ПО;
- степени новизны разрабатываемого ПО;
- степени использования в разработке стандартных модулей;
- условий и средств разработки ПО.
При этом для параметра строк исходного кода предлагается таблица их количества для каждой стандартизированной функции (действия, процесса). Итоговый объем строк предлагается определять посредством суммирования количества строк по каждой функции на основе формулы:
Vо=∑Vi,
Где
V_i – объем отдельной функции программы;
n – общее число функций.
Для каждой стадии создания программы трудоемкость придется считать отдельно с учетом коэффициентов сложности, привязанных к приведенным выше влияющим факторам:
- для стадии ТЗ Тутз = Т н x Kтз x Kс x Kн x Kур;
- для стадии ЭП Туэп = Т н x Kэп x Kс x Kн x Kур;
- для стадии ТП Тутп = Т н x Kтп x Kс x Kн x Kур;
- для стадии РП Турп = Т н x Kрп x Kс x Kн x Kт x Kур;
- для стадии ВН Тувп = Т н x Kвн x Kс x Kн x Kур,
Где Kтз, Kэп, Kтп,Kрп, Kвн - доля каждого этапа разработки программного обеспечения в общей трудоемкости работ. Они представлены в формате весовых коэффициентов в таблице, в случае, если какая-либо стадия разработки не предусмотрена, то на ее неиспользуемый коэффициент увеличивается доля времени следующего этапа. Остальные коэффициенты позволяют корректировать норму трудозатрат исходя из:
- Kс - сложности работ;
- Kн - новизны работ;
- Kур - учет имеющихся средств разработки;
- Kт - применяется только на стадии рабочего проекта, учитывает использование типовых модулей при составлении кода.
Все коэффициенты также берутся из специализированных таблиц приведенных в постановлении. Итоговая трудоемкость определяется по формуле:
То=∑Tyi , ,Где T_YI-трудоемкость стадий разработки, определенных по формула, приведенным выше с учетом всех коэффициентов.
Попробуем понять, как можно пронормировать с использованием приведенного постановление создание программы для учета данных путевых листов. Итак имеется проект на языке Visual С++ для накопления информации о транспортной работе ( пройденные километры, списанные литры топлива, перевезенные тонны, время работы). На основании данных таблиц путем экспертной оценки оставляющих функций была получена следующая таблица для подсчета количества строк кода на основе приложения 1 к постановлению:
№ п/п
|
Код функции
|
Содержание функции
|
Количество
строк исходного кода Vi
|
1
|
101
|
Организация ввода информации
|
150
|
2
|
109
|
Управление вводом - выводом
|
2400
|
3
|
202
|
Формирование баз данных
|
2180
|
4
|
203
|
Обработка наборов записей баз данных
|
2670
|
5
|
206
|
Манипулирование данными
|
9550
|
6
|
207
|
Организация поиска и поиск в базе данных
|
5480
|
7
|
403
|
Формирование служебных таблиц
|
1070
|
8
|
703
|
Расчет показателей
|
460
|
9
|
706
|
Предварительная обработка и печать
файлов
|
470
|
10
|
707
|
Графический вывод результатов
|
590
|
Итого
|
25020
|
Программа в сущности является развитием уже имеющихся на рынке аналогов и создается на уже известном программном и аппаратном обеспечении, в связи с чем относится к категории новизны В, в связи с чем коэффициент новизны нВ основе приложения 5 к постановлению будет равен 0,63.
Количество стандартных модулей при написании составит 50%, поэтому на основе приложения 6 Кт = 0,65, Кур = 1. Для категории B распределение удельных весов стадий разработки следующее: Kтз - 0,08; Kэп = 0,19; Kтп =0,28; Kрп=0,34; Kвн=0,11.
Ознакомившись приложением 2 к постановлению, эксперты пришли к выводу, что для значения 25020 строк приемлемо использовать показатель строки 79 с трудоемкостью 1108 чел.-дней.
Результат расчета трудоемкости разработки программы отразим в таблице:
Наименование
коэффициента
|
Этапы
проекта
|
Всего
|
||||
ТЗ
|
ЭП
|
ТП
|
РП
|
ВН
|
||
Удельные веса этапов
|
0,08
|
0,19
|
0,28
|
0,34
|
0,11
|
1
|
Распределение трудоемкости по этапам,
человеко-дней
|
2001,6
|
4753,8
|
7005,6
|
8506,8
|
2752,2
|
25020
|
Кс
|
1,12
|
1,12
|
1,12
|
1,12
|
1,12
|
|
Кт
|
0,65
|
|||||
Кн
|
0,63
|
0,63
|
0,63
|
0,63
|
0,63
|
|
Итоговая трудоемкость
|
1412,3
|
3354,281
|
4943,151
|
3901,559
|
1941,952
|
15553,27
|
Таким образом, если задача ставиться на год, для определения необходимой плановой численности нужно будет разделить трудоемкость на количество рабочих дней в году одного работника. При этом никто не отменял метода экспертных оценок, а также применение статистики предыдущих разработок. Далее рассмотрим альтернативный вариант расчета трудоемкости для программистов.
Нетипичный способ расчета трудозатрат по написанию программ
Для разработки самостоятельных программных продуктов сформировались свои, достаточно специфические подходы к определению трудоемкости. Основная идея в их реализации сводится к тому, что создание программы - это проект. В связи с этим сделана попытка применения в сфере их создания инструментов для определения длительности проекта. Одним из наиболее распространенных стал, разработанный в начале 80-х метод COCMO, позднее усовершенствованный и получивший название COCMO II. Он предлагает рассчитывать трудоемкость исходя из показателя количества строк (тысяч строк) программного кода.
Для этого предлагается использовать следующую формулу:
PM=EAF х A х SIZE^E,
где:
Е = B +0,01 х ∑SF.
Остановимся подробнее на содержании элементов формул:
B = 0.91;
A зависит от стадии оценки проекта и принимает значение 2,45 для предварительной оценки и 2,94 для детальной.
SF - фактор масштаба, его берут из специализированной таблицы, готовой и предложенной Software Engineering Institute, США или разработанной самостоятельно на основе собранных статистических данных.
SIZE - плановый объем работ в тысячах строк кода
EAF - произведение множителей трудоемкости (ЕМ), также берущемся из стандартной готовой таблицы, либо из созданной самостоятельно на основе накопленных статистических данных.
Сначала остановимся на описании факторов масштаба, чтобы лучше понимать, что оценивается:
SFi
|
Описание
|
Уровень значимости фактора
|
|||||
Очень низкий
|
Низкий
|
Средний
|
Высокий
|
Очень высокий
|
Критический
|
||
PREC
|
Прецедентность, наличие опыта аналогичных разработок
|
опыт в продукте и платформе отсутствует
|
продукт и платформа немного знакомы
|
некоторый опыт в продукте и платформе присутствует
|
продукт и платформа в основном известны
|
продукт и платформа в большой степени знакомы
|
продукт и платформа полностью знакомы
|
FLEX
|
Гибкость процесса разработки
|
процесс строго предопределен
|
допускаются некоторые компромиссы
|
значительная жесткость процесса
|
относительная жесткость процесса
|
незначительная жесткость процесса
|
определены только общие цели
|
RESL
|
Архитектура и разрешение рисков
|
риски известны/
проанализированы на 20%
|
—″—
На 40%
|
—″—
На 60%
|
—″—
На 75%
|
—″—
На 90%
|
—″—
На 100%
|
TEAM
|
Сработанность команды
|
формальные взаимодействия
|
тяжелое взаимодействие до некоторой степени
|
чаще всего коллективная работа
|
в основном коллективная работа
|
высокая степень взаимодействия
|
полное доверие, взаимозаменяемость и взаимопомощь
|
PMAT
|
Зрелость процессов
|
СММ Уровень 1 ниже среднего
|
СММ Уровень 1 выше среднего
|
СММ Уровень 2
|
СММ Уровень 3
|
СММ Уровень 4
|
СММ Уровень 5
|
Исходя из уровня значимости указанного фактора, можно выбрать его числовое значение на основе таблицы ниже:
SFi
|
Оценка уровня фактора
|
|||||
Очень низкий
|
Низкий
|
Средний
|
Высокий
|
Очень высокий
|
Критический
|
|
PREC
|
6.20
|
4.96
|
3.72
|
2.48
|
1.24
|
0.00
|
FLEX
|
5.07
|
4.05
|
3.04
|
2.03
|
1.01
|
0.00
|
RESL
|
7.07
|
5.65
|
4.24
|
2.83
|
1.41
|
0.00
|
TEAM
|
5.48
|
4.38
|
3.29
|
2.19
|
1.10
|
0.00
|
PMAT
|
7.80
|
6.24
|
4.68
|
3.12
|
1.56
|
0.00
|
№
|
Множитель трудоемкости,
|
Описание
|
Оценка уровня множителя трудоемкости
|
||||||
Супернизкий
|
Очень низкий
|
Низкий
|
Нормальный
|
Высокий
|
Очень высокий
|
Супер высокий
|
|||
1
|
PERS
|
квалификация персонала
|
2.12
|
1.62
|
1.26
|
1.00
|
0.83
|
0.63
|
0.50
|
2
|
PREX
|
опыт персонала
|
1.59
|
1.33
|
1.22
|
1.00
|
0.87
|
0.74
|
0.62
|
3
|
RCPX
|
сложность и надежность продукта
|
0.49
|
0.60
|
0.83
|
1.00
|
1.33
|
1.91
|
2.72
|
4
|
RUSE
|
разработка для повторного использования
|
n/a
|
n/a
|
0.95
|
1.00
|
1.07
|
1.15
|
1.24
|
5
|
PDIF
|
сложность платформы разработки
|
n/a
|
n/a
|
0.87
|
1.00
|
1.29
|
1.81
|
2.61
|
6
|
FCIL
|
оборудование
|
1.43
|
1.30
|
1.10
|
1.00
|
0.87
|
0.73
|
0.62
|
7
|
CSED
|
требуемое выполнение графика работ
|
n/a
|
1.43
|
1.14
|
1.00
|
1.00
|
n/a
|
n/a
|
Предположим, что экспертным методом удалось определить, что размер программы (SIZE) будет равен 15 тыс. строк кода. Вначале рассчитаем показатель Е. Для него, в результате совещания были получены оценки вероятных значений факторов, для которых взяты соответствующие значения из таблицы.
SF
|
Оценка
|
Значение
|
PREC
|
Низкий
|
4,96
|
FLEX
|
Средний
|
3,04
|
RESL
|
Высокий
|
2,83
|
TEAM
|
Низкий
|
4,38
|
PMAT
|
Средний
|
4,68
|
Подставив их значение в формулу получим: Е = 0,91+0,01 Х (4,96+3,04+2,83+4,38+4,68) =1,1089.
Далее определяем показатель EAF, на основе приведенной таблицы трудоемкости, оценка их уровня также происходит на основе мнений специалистов. Предположим, по итогам обсуждения сложились следующие значения:
№
|
Множитель трудоемкости
|
Описание
|
Оценка экспертов
|
Значение
|
1
|
PERS
|
квалификация персонала
|
Нормальный
|
1,0
|
2
|
PREX
|
опыт персонала
|
Низкий
|
1,2
|
3
|
RCPX
|
сложность и надежность продукта
|
Высокий
|
1,3
|
4
|
RUSE
|
разработка для повторного использования
|
Низкий
|
1,0
|
5
|
PDIF
|
сложность платформы разработки
|
Нормальный
|
1,0
|
6
|
FCIL
|
оборудование
|
Очень высокий
|
0,7
|
7
|
CSED
|
требуемое выполнение графика работ
|
Высокий
|
1,0
|
Тогда EAF = 1 х 1,2 х 1,3 х 1 х 1 х 0,7 х 1=1,092.
Далее применяя основную формулу получим:
PM = 1,092 х2,94 х 15^1,1089= 64,68 человеко -месяцев.
То есть один сотрудник сможет выполнить эту работу за 64,68, почти 65 месяцев. Допустим у нас в штате 10 программистов, тогда они смогут разработать указанный продукт за 64,68 /10 = 6,468 мес., иными словами уложатся в полгода. Если типичная занятость одного программиста 12 часов в день, 5 дней в неделю, то в месяц это в среднем 5 х 12 х 4(недели) = 240 часов. Тогда в часах трудоемкость составит 64,68 х 240 = 15523,2 человеко -часа.
Данный метод является формальным и в литературных источниках советуют прибегать к нему при недостаточном опыте экспертов или при отсутствии достаточной вводной информации. Кроме того, следует понимать, что он оправдан только при наличии сложных проектов в сфере разработки программного обеспечения.
Косвенный метод нормирования численности ИТ отдела
Такой вариант нормирования численности уже рассматривался в одной из публикаций посвященной нормированию работы офисного персонала. Однако в данном случае требуется рассмотреть частный случай его применения. Первоначально определим влияющие на численность факторы для системных администраторов:
- Количество серверов на обслуживании;
- Число пользователей интернет в компании;
- Количество пользователей баз данных;
- Объем обслуживаемых файловых хранилищ (в терабайтах).
За последние несколько лет значение указанных факторов принимали следующие значения при указной фактической численности, ее и примем за оптимальную.
Годы
|
Количество
серверов на обслуживании
|
Число
пользователей интернет в компании
|
Количество
пользователей баз данных
|
Объем
обслуживаемых файловых хранилищ (в терабайтах)
|
Численность
персонала
|
2014
|
65
|
905
|
495
|
214
|
7
|
2015
|
85
|
940
|
475
|
240
|
8
|
2016
|
90
|
960
|
480
|
230
|
8
|
2017
|
104
|
990
|
510
|
260
|
9
|
С формируем дополнительную матрицу, последовательно сложив
2014 и 2015, 2015 и 2016, 2016 и 2017 годы.
Годы
|
Количество
серверов на обслуживании
|
Число
пользователей интернет в компании
|
Количество
пользователей баз данных
|
Объем
обслуживаемых файловых хранилищ (в терабайтах)
|
Численность
персонала
|
2014
|
65
|
905
|
495
|
214
|
7
|
2015
|
85
|
940
|
475
|
240
|
8
|
2016
|
90
|
960
|
480
|
230
|
8
|
2017
|
104
|
990
|
510
|
260
|
9
|
2014+2015
|
150
|
1845
|
970
|
454
|
15
|
2015+2016
|
175
|
1900
|
955
|
470
|
16
|
2016+2017
|
194
|
1950
|
990
|
490
|
17
|
Далее пользуясь средствами Excel составляем требуемое уравнение регрессии, задающее зависимость между факторами и результатом (в нашем случае численностью). Для этого формируем таблицу выше и идем в пункт меню Данные – Анализ данных, в открывшемся окне выбираем регрессия и жмем ОК.
После этого выделяем результатирующие значения Y (численность) и значения X (е ячейки с факторами).
ВЫВОД ИТОГОВ
| ||||||||
Регрессионная статистика
| ||||||||
Множественный R
|
1
| |||||||
R-квадрат
|
1
| |||||||
Нормированный R-квадрат
|
1
| |||||||
Стандартная ошибка
|
8,44552E-16
| |||||||
Наблюдения
|
7
| |||||||
Дисперсионный анализ
| ||||||||
SS
|
F
|
Значимость F
| ||||||
Регрессия
|
4
|
113,7142857
|
28,42857143
|
3,98568E+31
|
2,50898E-32
| |||
Остаток
|
2
|
1,42654E-30
|
7,13268E-31
| |||||
Итого
|
6
|
113,7142857
| ||||||
Коэффициенты
|
Стандартная ошибка
|
t-статистика
|
P-Значение
|
Нижние 95%
|
Верхние 95%
|
Нижние 95,0%
|
Верхние 95,0%
| |
Y-пересечение
|
1,77636E-15
|
9,99288E-16
|
1,77762305
|
0,217440818
|
-2,52323E-15
|
6,07594E-15
|
-2,52323E-15
|
6,08E-15
|
Переменная X 1
|
0,02976394
|
5,64761E-17
|
5,27018E+14
|
3,60038E-30
|
0,02976394
|
0,02976394
|
0,02976394
|
0,029764
|
Переменная X 2
|
0,000386902
|
1,76709E-17
|
2,18949E+13
|
2,086E-27
|
0,000386902
|
0,000386902
|
0,000386902
|
0,000387
|
Переменная X 3
|
0,002267213
|
3,01962E-17
|
7,50827E+13
|
1,77386E-28
|
0,002267213
|
0,002267213
|
0,002267213
|
0,002267
|
Переменная X 4
|
0,01678938
|
6,02486E-17
|
2,78668E+14
|
1,28773E-29
|
0,01678938
|
0,01678938
|
0,01678938
|
0,016789
|
Y =0,0000000000000017+0,0298Х+0,0004Х+0,0023Х+0,0168Х,
Как видно, значение пересечения с осью Y столь мало, что его можно смело приравнять к нулю. Теперь основываясь на полученном уравнении можно смело прогнозировать нашу будущую численность ИТ –отдела.
Предположим, что в будущем году планируются следующие параметры:
Годы
|
Количество
серверов на обслуживании
|
Число
пользователей интернет в компании
|
Количество
пользователей баз данных
|
Объем
обслуживаемых файловых хранилищ (в терабайтах)
|
2018
|
120
|
1020
|
516
|
300
|
Годы
|
Количество
серверов на обслуживании
|
Число
пользователей интернет в компании
|
Количество
пользователей баз данных
|
Объем
обслуживаемых файловых хранилищ (в терабайтах)
|
Прогноз
|
2018
|
120
|
1020
|
516
|
300
|
10
|
Коэффициенты
трудовой нагрузки
|
0,0298
|
0,0004
|
0,0023
|
0,0168
|
На этом, можно было бы остановится, поскольку искомое значение получено. Тем не менее, полученные результаты следует проанализировать на их соответствие действительному положению дел и только после этого официально утверждать численность.
P.S. Первоначально эта статья писалась для белорусского профильного издания, но к сожалению, после нескольких лет сотрудничества мне не удалось найти общего языка с редактором. Поэтому часть материала базируется на нормативных актах республики Беларусь (очень толковых, кстати). Условия работы у нас и у них я не думаю что сильно отличаются, поэтому считаю, что данный материал будет пригоден к применению и на территории РФ.
Комментариев нет:
Отправить комментарий