Всім привіт.
Як ви (у вас на проекті) вимірюють якість проекту. Цікавить саме формула (формули) — значення яке можна підтвердити різними показчиками (цифрами) з проекту. Цікавить саме в загальному якість проекту, а не окремо якість коду\девів\куа....
Ну і взагалі, які метрики-показчики ви використовуєте для репортів проекту, крім стандартних KPI-ів.
Дякую :)
По продажам. Если продажи библиотеки растут, то команде повышают заплату и увеличивают штат. Если продажи вообще в ноль, но могут разогнать всю команду.
Пользуйтесь «формулой любви» — если клиент полюбил Вас настолько, что снова пришел к Вам со своим баблом за следующим проектом, или порекомендовал Вас кому-то — значит качество проекта удовлетворило клиента. Если впадло столько ждать, попросите ласково у клиента отзыв о команде и о людях, с которыми он общается.
А KPI или выбросьте нах, или держите его глубоко в тайне от всех, особенно от подопытных кроликов (что не есть кошерно). Я еще ни одного KPI-я не видел, который нельзя было бы подогнать при хреновейшем качестве кода\девов\куа.
загальная якисть — это скорость роста капитализации )))) мерять в папугаях )
Кількість матів на годину роботи команди. Більше матів — менша якість
Навпаки. Якщо мати заборонити, воно взагалі не працюватиме.
Цікавий процес заборони мата
зняти двері в коридор і посадити навпроти бухгалтерію
по бінарній шкалі
завалився/ не завалився
Поскольку качество это мера соответствия требованиям то соответственно в зависимости от требований можно оценить и качество. Требования могут быть как явные «кнопка становится зеленой по нажатию» так и не явные «кнопка становится зеленой по нажатию быстро». В неявной части требований еще и присутствует не измеримое понятие «быстро» потому как то что быстро для одного может быть не допустимо долго для другого не говоря уже о том, что на разных машинах кнопка может менять свой цвет по разному да и зеленый будет не одинаковый, а его оттенков дофига и больше.
Требования же могут быть довольно разнообразны да и в зависимости кто их составляет список может быть разным. К примеру сейлзам и сапорту нужны разные вещи, а стало быть и в требованиях они разойдутся.
К примеру вот не плохой чек лист www.joelonsoftware.com/...-12-steps-to-better-code
«Defect Density» — можно считать как по всем имеющимся, для учета качества в целом, так и только по новым, для учета качества девелопмента.
Потом садятся тестировщик и программист за пивом, и договариваются мелкие баги не заводить, чтобы зарплату повысили обоим.
Если вам нужно оценить качество проекта, оцените его по отдельным критериям —
Accessibility
Adaptability
Auditability and control
Availability (see service level agreement)
Backup
Capacity, current and forecast
Certification
Compliance
Configuration management
Cost, initial and Life-cycle cost
Data integrity
Data retention
Dependency on other parties
Deployment
и остальные 100500 критериев здесь en.wikipedia.org/...on-functional_requirement
та є таке...
менеджери просять неменеджерів і ті мають паритися :|
хай ті пропонують випадкові алгоритми — все одно гірше вже не буде
або знайдуть більш серйозну контору
Return on investment (ROI) uk.wikipedia.org/wiki/ROI
никак не меряем качество проекта в целом, это все равно что контролировать цвет покрышек вместо того что бы контролировать давление в шинах. В проектах все должно быть сосредоточенно на бюджете, сроках и качестве deliverables. То что вы пытаетесь изобрести велосипед говорит мне о нехватке знаний. )))
ну так если б знал что темы б не создавал, правда?)
По размеру годового бонуса менеджера, конечно.
И чем больше, тем длиннее срок оттягивания сдачи проекта заказчику. Экспириенс
Кількість учасників команди, кількість розподілених задач, кількість доданих задач, кількість доробок, кількість та час обговорень, підсумкова швидкість виконання, швидкість надходження зворотнього зв’язку від замовника після здачі чергового етапу проекту, загальний час на обробку вимог до проекту. Це щодо ключових метрик, тобто, кількісних показників. Якість — це певні взаємозвязки. Наприклад, вплив факторів латентних (тобто, прихованих, не озвучених замовником та не усвідомлених командою) очікувань замовника на якість виконання проекту в цілому та по задачах. Апріорі, латентність не є правом замовника виставляти претензії щодо «неналежної якості» або «невиправданих очікувань» — як то кажуть, мало там хто що подумав собі. Озвученість, обговореність та узгодженість вимог візаві визначає готовність розподіляти відповідальність за результати, і ніяк інакше.
Ніяк.
Взагалі — можна оцінити за відгуками користувачів та оцінками, котрі вони ставлять після звернення до служби підтримки.
Alexandr Gavriluk
Євген Лесько
Дмитро Дем'яненко
Maxim Deyneka
anonymous
Олексій Пєніє
Maxim Deyneka
Denys Poltorak
Леголас Трандуилович
Nikita Podgorbunskyi
Java Bee
Some Developer
anonymous
Alex Furman
NoName
TechnoBarbarian
Mary Zarzhytska
Mary Zarzhytska
Denys Poltorak
Andrey Rogovsky
27 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів