История про удовлетворённость клиентов
В истории маркетинга есть очень известная байка про компанию Rolls Royce. Я её периодически вспоминаю, но уже применительно к IT.
Однажды в компанию Rolls Royce пришла жалоба от клиента, которая звучала примерно так: “Вы называете свои автомобили лучшими, но их качество разочаровывает. В недавно купленном автомобиле полно явных инженерных просчётов. Наиболее раздражающий – это часы. Их тиканье настолько громкое, что я его отчётливо слышу, даже на скорости в 60 миль в час! Это просто позор!”
Байка не говорит, что ответили на эту претензию. Наверное, как-то помогли клиенту сделать часы тише. Всё-таки ценовой уровень обязывает.
Но зато известно, что именно из этой претензии родился известный слоган компании Rolls Royce: “На скорости 60 миль в час самый громкий шум в салоне – это тиканье часов”. Этот слоган наполняет гордостью работников и привлекает новых клиентов. Этот слоган показывает качество.
Я вспоминаю эту историю каждый раз, когда премию менеджера привязывают к числу жалоб клиентов. Это простой и, вроде бы, объективный показатель, который нужно и полезно отслеживать.
Но каждый раз я задумываюсь, что именно в тех жалобах: возмущение по поводу заваленного проекта или “тикание часов”?
Оценки задач
Я написал несколько глав про оценки: про PERT, про то, как проверять оценки, про оценку рисков. Но меня не оставляло ощущение, что эти главы малополезны и я их убрал из окончательного варианта книги, оставив только пару неочевидных моментов.
На практике я редко вижу проблему именно в оценках. Да, когда проект заваливают, то часто говорят, что промазали с оценкой и надо было заложить побольше буферов. Но обычно так прикрывают неспособность контролировать изменение требований и управлять проектом.
В моей практике был забавный случай, когда я пришёл на новый проект, где вроде бы были проблемы с оценками, и поэтому случился кризис. Когда я стал разбираться, то выяснилось, что изначальные оценки были сильно уменьшены, так как заказчику они показались большими. И параллельно объём требований увеличился в десять (!) раз. После такого адекватность самих изначальных оценок можно было и не проверять. Там могли бы быть случайные числа, на “успех” проекта это не повлияло бы.
В общем, все эти, показавшиеся мне очевидными, рассуждения об оценках я убрал. Но, возможно, я был неправ. Если вам не хватает информации об оценивании задач и проектов, напишите мне, пожалуйста, о том, что именно вам хотелось бы знать: borisovke@gmail.com.
Оценка субъективна
Но один момент в оценивании необходимо упомянуть, так как я часто вижу, что его игнорируют и попадают в беду. Важно понимать, что оценка – это субъективная величина. Про это легко забыть, когда смотришь на результат оценки в долларах. Кажется, что если проект оценён в $1’000’000, то это объективно. Ведь величина бюджета – это объективная величина! Как будто у нас есть некий мешок работы и мы его взвесили. Всё точно!
Но тут надо учесть, что если этот проект будет делать другая компания, то бюджет будет другой. Даже со сравнимым качеством за сравнимое время другая компания потратит другое количество денег. На этом строится весь аутсорс. Одна компания умеет находить и удерживать дешёвых разработчиков, умеет использовать лёгкие и гибкие процессы и легко масштабируется. Другая компания использует очень дорогих, хотя и не очень умелых разработчиков, погрязла в бюрократии и делает даже простые вещи очень долго. Оценка и реальный бюджет проектов в двух этих компаниях будут разными.
Кажется, что это не так важно, когда мы уже получили проект. Ведь мы знаем, как наша компания работает. С новым проектом мы будем работать, как обычно. И оценка сделана из этого предположения. То есть в рамках одной компании можно оценку считать объективной?
Совсем нет. Например, если вы спросите оценщика, на какую команду он рассчитывал оценку, то он скажет либо конкретные фамилии, либо уровень. Разумно в оценку сразу закладывать определённую структуру команды: один тимлид, три senior-разработчика, 5 middle-разработчиков. Но нужно понимать, что здесь тоже заложена субъективность.
Даже одинаковые по структуре команды могут сильно отличаться по производительности, просто за счёт того, что отдельные люди не могут сработаться. А отдельные могут так сработаться, что пожениться и сбежать из компании в отпуск на Багамы.Опытный менеджер может это выровнять, а может и не выровнять. Я уж не говорю о том, что вместо планируемых middle-разработчиков обязательно в команду вкинут junior-ов. Реальный бюджет при этом изменится и не в меньшую сторону.