Почему функциональные точки труднее подделать по сравнению с

затраченными часами или строками кода?

Это связано с тем, сколько лиц нужно вовлечь в процесс.

1) Проще всего подделать часы, т.к. чтобы их подделать не нужно ни с кем
договариваться. Пример: сотрудник потратил на задачу 4 часа, еще 4 часа
занимался своими делами, в итоге списал 8 часов. Как понять, что потрачено
было не 8 часов, а в 2 раза меньше? В офисе это решается проще - у
сотрудника включен монитор и проходя мимо можно хотя бы заметить, что
открыт не его рабочий проект, а что-то другое.
2) Сложнее подделать строки кода. Сотрудник может размножить какую-либо
функцию по коду несколько раз: например, каждый раз “с нуля” писать типовую
задачу вместо того, чтобы сделать базовый класс с несколькими настройками
или вставлять в код лишние переводы строк (например, при перечислении
параметров вызываемой функции каждый писать с новой строки). Может
создать новые классы там, где они не нужны - прикрываясь пользой паттернов
проектирования создать излишние конструкции, например, к каждому классу
можно при желании создать абстрактный интерфейс, абстрактную фабрику и
абстрактный сериализатор-десериализатор - просто на всякий случай. Если в
команде есть практики ревью кода, есть автоматизированный инструментарий
ревью кода и инструменты проверки стиля написания кода, то на ревью
подобные кейсы можно выловить. Очевидно, что затраты на подделку строк
кода выше.
3) Самое сложное - подделать функциональные компоненты. Чтобы это сделать
сотрудник должен договориться с бизнесом, аналитиком и архитектором о том,
что в системе нужны новые формы ввода, новые отчеты, новые данные
сохраняемые в системе, новые API и новые форматы обмена данными между
его системой и смежными системами. Сложность такого обмана на несколько
порядков выше, чем подделка строк кода. Иногда появляются хитрецы, которые
указывают функциональные компоненты, которые они не модифицировали.
Этот обман легко вскрыть.

Сколько стоит быстрая функциональная точка?

Если взять мешок задач в 10 тысяч быстрых функциональных точек, то для МКБ
средние полные ИТ-затраты за вычетом затрат на тестирование составят 3.8 часа.
Средние полные ИТ-затраты за вычетом затрат на тестированию включают работу
управленцев, аналитиков, разработчиков.

На горизонте года ИТ МКБ производит 100 тысяч функциональных точек.

На мешке задач до 250 функциональных точек о среднем лучше не упоминать

вообще.

Для снижения стоимости функциональной точки рекомендуется изучить места

возникновения затрат. Например, ими являются:
 1) Простои членов команд (например, несогласованность между планированием и
реализацией)
2) Излишний ручной труд по типовым задачам (например, ручное выкладывание
билдов на стенды)
3) Большое количество ошибок (например, в следствие отсутствия коротких
циклов “постановка” - “проектирование” - “реализация” - “демонстрация” -
“фидбек”)
4) Неподходящий инструментарий/библиотеки (например, сайт на ассемблере и
все виды изобретения велосипедов)

Почему в KPI стоимости функциональной точки 2020 не включены ИТ-затраты на

тестирование?

В МКБ в 2019 тратил недостаточно ресурсов на тестирование и было принято

решение в 2020 эту практику развивать. Если бы в KPI стоимость функциональной
точки включили тестирование, то на тестировании экономили бы, что привело бы к
невыполнению цели по развитию тестирования.

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

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

Проблема в том, что в каждой системе Входы, Выходы, Таблицы, Сообщения и

Интерфейсы названы по-своему

Например, в SharePoint:
- Формы - это Входы
- Представления - это Выходы
- Списки - это Таблицы
- Конечные точки - это Сообщения
- Элементы - это Интерфейсы

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

точки могут называться Точками интеграции и тд.

Лучше всего попросить самого активного сотрудника написать короткую табличку, в

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

Почему в 2020 не потребовали заполнять функциональные точки до начала

реализации задач?
Оценивать нужно задачи внедренные в 2020. Некоторые из них начали реализовывать
в 2019 еще до того как методику функциональных точек начали внедрять.

Заполнять функциональные точки до начала разработки - отличная идея, поскольку

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

Есть ли норматив для систем 3.8 часа на функциональную точку и нужно ли его
выполнять каждой системе?

Такого норматива нет. Есть среднее по ИТ. Преуспевающим и неуспевающим

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