Оценка стоимости разработки программного обеспечения

Зачем и когда нужна оптимизация трудозатрат?

→ Руководители подразделений просят ещё людей, и непонятно, нужны ли эти люди реально?

→ Как оценить загрузку отдела?

Методы определения стоимости программного обеспечения

→ И тем ли люди заняты, чем нужно? Достаточно ли эффективно организована работа?

→ Как установить нормативы, эталоны выработки, особенно для офисных или творческих сотрудников?

→ Как оценить изменение в процессе или функционале? Понадобятся ли ещё люди, если теперь нужно добавить операции или изменить процесс? И так ли много?

Почему традиционные хронометраж и фотография рабочего дня — это «не о том»?

Да потому, что они тренируют в персонале актёрские и/или писательские навыки, и только. Измерение должно применяться точечно и грамотно, иначе его данные будут бессмысленны.

Пример

Два сварщика. Один варит весь день, другой курит полдня. Кто работает лучше?

Хронометраж нам скажет: варит… столько %, курит… столько % времени. Это нам помогло? Нет.

А поможет что? Только выяснить, кто из них сколько сделал, и какого качества.

Возможно, курящий работает как три некурящих, а может — и наоборот.

Но и это еще не всё. Ведь возможно, они оба работают вдвое хуже, чем могли бы.

В нашей методике мы привязываемся к полученным результатам (что и сколько сделано) и выполненным процессам и процедурам (каким способом сделано). Важно: мы опираемся на стандартный, наилучший-воспроизводимый путь, как это сделать, а не на факт, как люди делают. (Сделать дольше — легко, мы выясняем и записываем, как сделать быстрее, но качественно, и назначаем это за эталон).

Методика одновременно устанавливает эталон (нельзя сделать менее эффективно, чем в нормативе) и сравнивает с ним реальную работу.

→ Вы уже видели кейс с примером оптимизации?

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

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

Так можно измерить и сделать прозрачной работу любых специалистов. (Но для сложных случаев может потребоваться участие стороннего специалиста-эксперта при назначении нормативов. )

Какие результаты вы можете получить от анализа трудозатрат?

Большинство компаний живёт в режиме «только начальник отдела знает, что делается в отделе», и это ещё в лучшем случае: часто и он неправильно представляет себе, на что уходит время, или не знает, как выполнить операции, которые делает его подчинённый.

Почти всегда при нормировании обнаруживаем (и значит — можем устранить) вот такие проблемы:

1

Подразделение делает некоторые ненужные или дублирующиеся внутренние услуги, которые можно вообще отменить (например, в одой компании обнаружили, что учёт факта по договорам ведется независимо в трёх подразделениях (трудозатраты х 3), и это не выявить, потому что каждый начальник отдела знает только свой отдел)

2

Административно-бумажная нагрузка может достигать 30% рабочего времени, в среднем 15%

3

Почти в каждом подразделении есть долгие и неудобные способы выполнения работ, привычные или оставшиеся от прошлого, которые можно заменить на более эффективные (Например, в договорном отделе работает 8 человек, а можно организовать работу так, чтобы хватало 3, и плюс к тому добавить функционала и останется еще время — просто нужно организовать работу на иных принципах).

4

Очень часто подразделения живут в режиме «ручного управления» — начальник выступает в роли диспетчера, а работник не знает, что будет делать завтра. Это вносит сумбур и снижает общую производительность.

5

Есть должности, где начальник не понимает, что делает подчинённый, там мы можем иметь значительное завышение нормативных сроков на работу (подчинённый создаёт впечатление, что это сложная и длинная операция, а она простая и быстрая)

6

Очень часто обнаруживается, что руководитель занимается не тем, чем должен.

Правки после сдачи проекта: что делать, если их прислал клиент?

Вы сдали проект.

Прошло какое-то время, и клиент прислал правки. Формально вы можете их не вносить – ведь проект принят – либо попросить доплату. Но чутье подсказывает, что оба варианта вызовут претензии у заказчика. Что делать? Давайте разберемся! Для начала взглянем на ситуацию глазами клиента и фрилансера.

Ситуация глазами клиента

Для заказчика картина выглядит так. Он заказал работу, получил результат. Что-то не предусмотрел или упустил в ТЗ, бывает. Но ведь исполнителю не сложно внести мелкие правки, и выручить по дружбе клиента? Конечно, исполнитель может попросить доплату. Но разве он не понимает, что заказчик – тоже человек, и может немного ошибиться или что-то упустить? Пусть внесет правки по дружбе, в счет следующих заказов.

Важно учитывать, что далеко не каждый человек способен признавать свои ошибки. Многие люди обвинят в своих ошибках другого человека, а именно – исполнителя. Например, отказываясь вносить правки, вы можете услышать упреки вроде: «Но вы же, как профессионал, должны были предупредить, что здесь нужно сделать иначе?»

Иногда у клиента просто нет денег для оплаты правок, а работа нужна. Поэтому все, что остается делать – просить исполнителя поработать бесплатно.

Ситуация глазами фрилансера

Мне заказали проект, я его сделал по ТЗ. Мне заплатили, а теперь просят потратить дополнительное время (считайте – деньги) на задачу, которую никто не оплатит.

Если я внесу правки бесплатно, заказчик может снова и снова просить что-то доработать.

Естественно, без денег. А мне это надо?

Как выйти из ситуации, когда клиент прислал правки после сдачи работы?

Действия зависят от наличия технического задания на проекте и первоначальных договоренностей с клиентом:

Наличие технического задания на проекте Предупреждали о том, что правки вносятся за доплату Что делать?
Нет Не важно
  1. Попросить клиента прислать полный перечень правок, которые необходимо внести в проект.
  2. Предупредить, что последующие правки будут вноситься за доплату, поэтому список правок должен быть полным.
  3. После доработки проекта согласно полученному списку получить письменное уведомление от клиента, что проект сдан, претензий по качеству работ нет.
  4. Если клиент снова обратится с просьбой внести правки, попросить доплату, поскольку ранее вы все правки внесли, проект сдали, претензий к вам не было, про доплату вы предупреждали.
Есть Нет
  1. Если правки относятся к той части работы, которая не соответствует ТЗ – исправить ошибки бесплатно.
  2. Если работа полностью соответствует ТЗ, объяснить, что правки расширяют ранее согласованный объем работы, и попросить доплату. В случае настойчивости клиента предложить компромисс – небольшие правки внести бесплатно, остальные – за небольшую доплату. Последующие правки вносить только за доплату.
Есть Да
  1. Если правки относятся к той части работы, которая не соответствует ТЗ – исправить ошибки бесплатно.
  2. По остальным правкам объяснить, что эта работа находится за рамками согласованного ТЗ, поэтому будет вноситься за доплату. Рассчитать стоимость доплаты, озвучить ее клиенту.

Как правило, если вы предупреждали клиента о доплатах и на проекте есть ТЗ, проблем не будет. Клиент согласится доплатить за дополнительные работы.

Как избежать проблем с правками в будущем?

Чтобы клиенты не присылали просьбы бесплатно внести правки в проект после его сдачи, необходимо предпринимать следующие действия:

  1. Составлять четкое и однозначное техническое задание на проект. Иначе клиент может попросить внести правки, поскольку «результат не соответствует ТЗ». Важно понимать, что дополнительную оплату можно просить только за правки, которые выходят за рамки ТЗ. Если в проекте что-то сделано не по ТЗ, то это ошибки, а не правки. Ошибки исправляются бесплатно. Другое дело, что при нечетком ТЗ под «ошибки» можно подвести практически любые правки.
  2. До начала работы предупреждать всех клиентов, что после сдачи проекта все правки вносятся за дополнительную плату (кроме ошибок – они устраняются бесплатно). В ряде сфер можно предлагать после реализации проекта его сопровождение. Например, после сдачи сайта предложить его сопровождение за дополнительную плату. В рамках сопровождения вносить правки.
  3. Письменно фиксировать факт передачи проекта заказчику и факт отсутствия претензий к качеству выполненных работ. Запомните: устные согласования грозят тем, что заказчик в будущем откажется от своих слов.

    Критерии оценки программного обеспечения

    Или скажет, что его неверно поняли и проект на самом деле не сдан.

  4. Предлагать клиентам сопровождение проектов. Если клиенту понадобится расширить функционал продукта или что-то доработать, он сможет это сделать в рамках платного сопровождения.
  5. Индивидуально подходить к каждому случаю, ведь ситуации у клиентов бывают разные, и для каждого случая инструкцию не сделаешь.

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

Также рекомендую прочитать другие статьи, которые помогут выстраивать конструктивные отношения с заказчиками:

Автор: Сергей Антропов(KadrofID: 5)
Добавлено: 07.08.2017 в 14:11

Рекомендуем

Как работать с трудными клиентами?

Трудные клиенты встречаются у всех. Им все не так и все не этак, они стремятся все контролировать, вмешиваются в рабочий процесс, порой нарушают …

10 опасных ошибок при расчете бюджета проекта

Ошибки при расчете бюджета приводят к тому, что вы делаете больше, чем планировали. Получаете меньше, чем хотели. Теряете мотивацию. Проект …

Существуют разнообразные модели, методы и средства оценки стоимости программного обеспечения. В частности, на практике уверенно используются алгоритмические модели и неалгоритмические методы оценки стоимости ПО. В первом случае применяются математические формулы, а во втором — определенные принципы и схемы. К не алгоритмическим относятся методы price-to-win, оценка по Паркинсону, экспертная оценка и оценка по аналогии. Модели оценки стоимости ПО более понятны, точны и прозрачны.

Методы оценки трудозатрат на разработку ПО. информационны

2.1 Метод суждения эксперта(expert judgment method)

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

Этапы оценки этого метода:

1.Координатор представляет каждого эксперта со спецификацией и формой оценки.

2.Координатор назначает встречу группы, во время которой эксперты обсуждают возможные оценки с координатором и c друг другом.

3.Эксперты заполняют формы, анонимно

4.Координатор готовит и распределяет резюме оценок.

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

6.Эксперты заполняют формы по новой, анонимно, и шаги 4, 5 и 6 повторяются несколько раз.

Преимущества:

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

2. Эксперты могут грамотно оценить различные факторы влияния на проект такие как применение новых технологий, программных архитектур и языков.

Недостатки:

Этот метод не может быть измерен

Сложно документировать факторы, используемые экспертами и экспертными группами.

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

Метод суждения эксперта обычно должен дополняться другими методами оценки такими как алгоритмические методы.

2.2 Метод оценки по аналогии (estimating by analogy)

Метод оценки по аналогии предлагает провести сравнение текущего проекта с похожим предыдущим уже завершенным проектом. Актуальная информация о завершенных проектах собирается и используется для оценки текущего проекта.

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

Этапы оценки этого метода:

Определение характеристик текущего проекта

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

Вывод оценки для текущего проекта из наиболее похожих, уже завершенных проектов, используя аналогию

Недостатки метода:

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

Оценка стоимости программного обеспечения

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

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

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

2.3 Нисходящий и восходящий методы

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

Преимущества этого метода:

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

Этот метод требует минимальную информацию о деталях проекта и он, как правило, легко и быстро реализовывается.

Недостатки этого метода:

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

Этот метод не предоставляет детальной основы о суждениях, решениях или оценках.

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

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

Преимущества:

Этот метод позволяет группе разработчиков ПО проводить оценку наиболее традиционным образом и оценивать компоненты, к которым группа имеет предпочтение.

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

Недостатки:

Этот метод не рассматривает множество затрат на системном уровне (интеграция, управление конфигурациями), связанных с разработкой ПО.

Этот метод может быть не точен, потому что необходимая информация может оказаться недоступной на ранней фазе разработки.

Метод требует значительных затрат времени

Могут возникнуть существенные затруднения в применении метода, если время и персонал ограничены.

2.4 Алгоритмические методы

Алгоритмический метод разработан с целью применить математические уравнения для представления оценки затрат на разработку ПО. Эти математические уравнения основаны на исследованиях и используют на входах SLOC (линии исходного кода) число представляемых функций, языки, методологию разработки, уровни навыков, оценки рисков и т.д. Алгоритмические методы хорошо изучены и многие модели основываются на них, например модели COCOMO, Путнема и модели, основанные на функциональных точках.

Преимущества:

Этот метод дает возможность создавать повторяемые оценки.

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

Этот метод эффективен и может поддерживать семейство оценок или чувствительность анализа.

Недостатки:

Этот метод не применим к исключительным условиям таким как: не включенный персонал, не включенная команда и непредвиденное соответствие между уровнем навыков и задач.

Неточная входная информация может повлечь неточность оценки.

Некоторые факторы не могут быть просто измерены.


⇐ Предыдущая11121314151617181920Следующая ⇒


Дата публикования: 2015-09-17; Прочитано: 847 | Нарушение авторского права страницы



studopedia.org — Студопедия.Орг — 2014-2018 год.(0.002 с)…

ОЦЕНКА ТРУДОЕМКОСТИ ПРОЕКТА

⇐ Предыдущая55565758596061626364Следующая ⇒

 

В качестве начального значения предлагается использовать 20 человеко-часов на одну UCP. Эта величина может уточняться с учетом опыта разработчиков. Приведем пример возможного уточнения.

Рассмотрим показатели Fl—F8 и определим, сколько показа­телей Fl—F6 имеют значение меньше 3 и сколько показателей F7—F8 имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч. на одну UCP, если 3 или 4—28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск прова­ла слишком высок.

Для системы регистрации получаем 28 чел.-ч. на одну UCP, та­ким образом, общее количество человеко-часов на весь проект равно 56,56*28 = 1583,68, что составляет 40 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из четырех человек, и добавим 3 недели на различные непредвиден­ные ситуации, тогда в итоге получим 13 недель на весь проект.

Опытные данные компании Rational. Проект среднего размера (приблизительно 10 разработчиков, более чем 6-8 месяцев) мо­жет включать приблизительно 30 вариантов использования. Это соответствует тому, что средний вариант использования содержит 12 UCP, и каждая UCP требует 20-30 ч. Это означает общую тру­доемкость 240-360 чел.-ч. на вариант использования. Таким об­разом, 30 вариантов использования потребуют приблизительно 9000 чел.-ч. (10 разработчиков в течение 6 месяцев). Однако пря­мой пропорции не существует: очень большой проект со 100 раз­работчиками и сроком 20 месяцев не начнется с 1000 вариантов использования из-за проблем размерности.

Использование описанной выше методики для простых и сложных систем хорошо согласуется с опытными данными ком­пании Rational (приблизительно 150-350 ч. на один вариант ис­пользования).

Оценка стоимости разработки программного обеспечения

Самая простая система (весовой показатель UC = 5, А = 2, UUCP = 7) дает (при 20 чел.-ч. на UCP) приблизительно 140 чел.-ч. Сложная система (весовой показатель UC = 15, А = 3, UUCP = 18) дает приблизительно 360 чел.-ч.

6.5.

МЕТОДЫ, ОСНОВАННЫЕ НА ЭКСПЕРТНЫХ

ОЦЕНКАХ

 

Подходы, основанные на экспертных оценках, применяются при отсутствии дискретных эмпирических данных. Они исполь­зуют опыт и знания экспертов-практиков в различных областях. Оценки, получаемые при этом, представляют собой синтез изве­стных результатов прошлых проектов, в которых принимал учас­тие эксперт.

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

6.5.1.

МЕТОД ДЕЛЬФИ

 

Метод Дельфи был разработан в корпорации «Рэнд» в конце 1940-х гг.

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

6.5.2.

МЕТОД ДЕКОМПОЗИЦИИ РАБОТ

 

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

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

Наряду с процессом оценки МДР широко применяется для расчета себестоимости разработки ПО. Каждому элементу иерар­хий МДР можно приписать свой бюджет и уровень издержек, что позволяет персоналу составлять отчеты о количестве рабочего времени, которое было затрачено на выполнение заданной зада­чи в рамках проекта или какого-либо компонента проекта, кото­рые затем могут быть обобщены для административного контро­ля над использованием средств.

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

6.6.


⇐ Предыдущая55565758596061626364Следующая ⇒


Дата добавления: 2015-11-05; просмотров: 419 | Нарушение авторских прав


Похожая информация:


Поиск на сайте:




Обратная связь

ПОЗНАВАТЕЛЬНОЕ

Сила воли ведет к действию, а позитивные действия формируют позитивное отношение


Как определить диапазон голоса — ваш вокал


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


Целительная привычка


Как самому избавиться от обидчивости


Противоречивые взгляды на качества, присущие мужчинам


Тренинг уверенности в себе


Вкуснейший «Салат из свеклы с чесноком»


Натюрморт и его изобразительные возможности


Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д.


Как научиться брать на себя ответственность


Зачем нужны границы в отношениях с детьми?


Световозвращающие элементы на детской одежде


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


Как слышать голос Бога


Классификация ожирения по ИМТ (ВОЗ)


Глава 3. Завет мужчины с женщиной


Оси и плоскости тела человека — Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.


Отёска стен и прирубка косяков — Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.


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

Трудоемкость рассчитывается по формуле

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

Хронометраж проводится с целью получения исходных данных:

— для проектирования нормативов времени на элементы ручной и машинной – ручной работы,

— для установления норм оперативного времени на операцию,

— для установления норм времени, сопровождаемого усовершенствованием технологического процесса выполнения нормируемой работы и организации труда на рабочем месте,

— для изучения и внедрения передовых приемов и методов труда и др.

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

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

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

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

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

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

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

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

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

 

Т = Топ + Тоб + Тпт + Тот + Тиз,

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

 

4. Производительность труда, ее сущность и измерение. Факторы, влияющие на производительность труда. Эффективность ускорения темпов роста производительности труда.

 

Производительность труда – важнейший показатель эффективности труда и уровня производственно – экономической деятельности предприятия.

Чем выше производительность труда, тем меньше трудовые затраты на производство единицы продукции или работы и ниже ее себестоимость.

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

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

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

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

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

Выработку продукции за единицу времени определяют по формуле

B = Q / T,

где Q– объем произведенной продукции,T – затраты рабочего времени.

Трудоемкость рассчитывается по формуле

t = T / Q.

При определении производительности труда применяют пять методов: натуральный, условно – натуральный, индексный, трудовой и стоимостной.

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

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

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

Измерение производительности труда при трудовом методе предполагает использование показателя трудоемкости в качестве измерителя продукции. Объем продукции определяют в нормо — часах путем умножения объема продукции в натуральном выражении на норму времени на изготовление единицы продукции.

Оценка рыночной стоимости программного обеспечения

Трудовой метод требует применения научно – обоснованных норм времени.

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

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

 

Пт сети, дороги = Σ (Рl)гр / Чсп = (Σ Ргр l + К Σ Рп l ) / Чсп,

Пт отд. дороги = Σ (Рl)гр / Чсп = (Σ (Рl)п + К Σ Рп l ) / Чсп,

где Σ (Рl)гр – грузооборот, приведенные тонно – километры,

Σ Ргр l – грузооборот, тарифные тонно – километры,

Σ Рп l – пассажирообоорт, пассажиро – километры,

К– коэффициент приведения по пассажирообороту,

Чсп среднесписочная численность работников, занятых на перевозках, человек,

Σ (Рl)п– грузооборот отделения железной дороги, эксплуатационные тонно – километры.

Показатели, применяемые для измерения производительности труда работников отдельных хозяйств железных дорог, приведены в таблице 1.1.

Таблица 1.1

 


Добавить комментарий

Закрыть меню