Комментарии 19
Качество кода, архитектуры, качество документации, качество планирования — без малого исчерпывающий список, отвечающий на вопрос о оптимизации расходов на разработку.
На мой взгляд, гораздо легче и важнее оценивать тех, кто строит архитектуру, тех, кто дает обещания и тех, кто контролирует процессы — т.е. тех, кого можно оценить объективно.
Люди очень разные. Компании об этом забывают еще на этапе собеседований, а с жестким подходом к необъективной оценке труда можно доиграться. Вот пишешь себе скажем REST и на тебе, "темная" — сбить показатели, а то сидит тут, с простым, объемным и планируемым кодом.
Можно конечно забыть про производительность людей в работе с однотипными задачами, раздавать их "рулеткой", но контроль ценой эффективности дискредитирует сам себя.
Тут важно с умом подходить к измерениям и к выбору метрик. Если метрика будет «точность попадания в оценку», например, то с рестом уже не будет такой ситуации. То, что люди разные, ещё Дедушка Брукс доказал и показал, когда деревья были сильно меньше. Это факт. Принимать решения только на основе цифр, которые тебе дала спец.тулза или экселька — путь в ад. Но мерять однозначно нужно и анализировать результаты тоже.
Как определить порог «мало кода»? Мы рекомендуем ставить его достаточно маленьким, чтобы любой, хоть сколько перформящий разработчик мог его легко преодолеть.
Результат не «точно плохой разработчик», а «надо бы разобраться, все ли в порядке».
Так что никакой категоричности, всё с оговорками.
Цифрами начинают заниматься тогда, когда что-то идёт не так, а оно не так идёт почти всегда. Просто кто-то не верит своим ощущениям и проверяет измерениями, а кто-то верит и в итоге загоняет проект туда, откуда цифрами и измерениями его уже не достать.
Все зависит от представления. В точных цифрах конечно не про уровень руководителя всей сотни, это не надо, но может быть полезно лиду, например. А в относительных цифрах и в виде динамики при наличие хорошего инструмента все видно замечательно и очень полезно. Гитлин по сути это и делает. Собирает кучу данных — хочешь — смотри детали, хочешь смотри динамику.
Баг багу рознь. Баг с прода меряют очень многие. Число зафейденых ревью коммитов также очень частая метрика.
Например, в моей практике был случай, когда из-за увольнения сеньора важный релиз был отложен на 3-4 недели. Это очень большой срок, и бизнес это не обрадовало.
А можно, пожалуйста, подробностей, что такого особенного может произойти за 3-4 недели, что может пагубно сказаться на бизнесе? Я в курсе, про хотфиксы, но вот про плановые релизы — не понимаю.
Пример: я «каждый» день пользуюсь браузером, я.такси/ситимобил, git-ом. Уверен, что если их очередная версия выйдет не прям сейчас, а через месяц — я абсолютно не пострадаю. И компания-производитель не пострадает, ибо клиенты как пользовались «приложенькой» (приносили деньги), так и пользуются. (Более того, клиенты даже будут рады задержке, ибо им реже придётся переучиваться (ибо дизайнеры очень любят менять интерфейс и, порой, прятать самые нужные кнопки в самый дальний угол)).
В общем, я бы с радостью послушал аргументацию автора.
(Без сарказма, действительно интересно).
1. 3-4 недели относительно месяца или года? Если месяца, то бизнес не доволен вдвое возросшей стоимостью.
2. «не обрадовало» — понятие растяжимое. Почему это должно их радовать?
3. А если это fix-price проект?
4. Этот функционал есть у конкурентов (было в моей практике).
5. Под релиз запланировано куча всего — обещания клиентам, презентации
5а. или хотя-бы внутренние связи между проектами и отделами, то есть задержка затронет всех.
например фича под какое-то событие, после которого она будет уже не нужна.
Пример — к новому году, к 23 февраля, к 8 марта или там к 1 сентября.
Задержали на месяц — упустили прибыль
Оцениваем разработчика на основе объективных данных