Оценка результата, часть II
(часть I здесь)
Так вот, оценивать надо не процесс, но результат, при этом держа в уме три вектора.
Первый: влиять поощрением. Кнут на творческую интеллигенцию действует фигово, она от этого хиреет. Нужны пряники.
Второй: разработчик должен сам хотеть делать хорошо. Сам. Можно кол стесать, можно голову об стену горохом, но пока этот… разработчик… мучительными раздумьями не поймёт, что ему выгодно делать хорошо, толку не будет.
Третий: максимальная ясность в причинах следствий. Множество раз сталкивался с fail’ом или сознательным обманом: ты получишь вкусняшку, если сделаешь что-то. Что? Что-то. Да что, блин? ЧТО-ТО. Так быть не должно.
Результатом разработки является сервис в production’е. Делающий то, что надо. Делающий это стабильно и прогнозируемо. Плюшки должны быть направлены на этот результат.
Назначаем членам команды базовый оклад. В ответ на возмущение заваливаем плюшками по результату.
На сервис есть чёткий Project requirements? Менеджеру +N%.
По ТЗ сделали чёткий Project plan? Менеджеру +N%, тимлиду +N%.
Разработка уложилась в план и выкатила сервис в срок? Всем +N%.
Первый месяц сервиса в production’е нет critical ошибок? Разработке и QA +N%.
Первый месяц сервиса в production’е нет major ошибок? Разработке и QA +N%.
Выкатили хорошо и от пользователей нет shit storm? Менеджеру +N%.
Код на 95%+ покрыт юнит-тестами? Разработке +N%.
Код на 95%+ покрыт документацией по установленному стандарту и не на “отвали”? Разработке +N%.
Метод понятен, думаю. Его можно продолжить.
Фишка тут в том, что ты можешь не делать хорошо. Тебя не заставляют. Не пинают для галочки, не бьют ногами, не носят на партсобрание. Но за то, что ты профессионально делаешь профессиональный продукт, ты получаешь печеньку.
Другая фишка в том, что нужны диктатура разумных и доверие тех, у кого бюджет. Чтобы построить процессы, при которых все быстро делают нужное, уходят годы. И большую часть этого времени вы потратите на возню с детским садом, слаженно пищащим “нихачу! нибуду! ниумею! хачу другую игрушку!” Нужны рычаги и полномочия, чтобы построить эту бестолковую вольницу.
Третья в том, что все оказываются повязаны понятными узелками. Менеджеру влом написать ТЗ? Не будет плана, всем не будет прибавки. Разработчик Петя адово косячит? Взрывы production’а, всем не будет прибавки. Разработчик Вася не умеет использовать фреймворк ABC? Снова проседание, снова все без прибавки. Тимлид не организовал разработчиков? Все сосут голодную лапу. Ты обгоняешь план, но твой сосед тормозит? Помоги ему, это и твои N% машут платочком.
Четвёртая в прямой мотивации профессионального роста. Чтобы написать годные тесты, надо разобраться с тестированием: методы, библиотеки, генерация данных и т.д. Чтобы написать годный план, надо разобраться как в своих разработчиках, так и в планировании: граф задач, риски, компенсация рисков, да и вообще не быть дураком. Чтобы написать ТЗ, надо разобраться с предметной областью, связать всё воедино, построить цельную систему сервиса, предусмотреть развитие. Не разобрался? 0%. Разобрался? N%.
Как итог, за пару проектов можно получить довольно ядерную команду, работающую не за страх и совесть, но за понятные результаты. А страх и совесть не работают — достаточно открыть трекеры любого проекта.
PS. Где N > 0.