Оценка
Врожденное стремление к оперативной информации - это «фича» человека , сколько разных СМИ , телеграмм каналов , которые рассказывают новости. Так же и «бизнесу» интересно протестировать разные гипотезы и получить обратную связь , как можно раньше. Бизнес естественно ожидает результат, но то, что своевременность важнее качества - это иллюзия.
Быстрое получение обратной связи для бизнеса - это путь к получению прибыли / сокращению издержек / расширение рынков - оно же получение желаемого результата, как можно скорее. Быстрый результат тоже свойство нас всех: просмотрите на популярность курсов про успешный успех)))
Конечно представителям бизнеса, как и любому другому человеку результат нужен как можно скорее , но то что бизнесу не нужно качество - это надуманная история. Разработчики регулярно , когда думают про качество представляют себе создание космического корабля , который долетит до края вселенной и обратно. Стоит понять , кто твой бизнес и только ли бизнес является заинтересованной стороной, а дальше понять какого качества будет достаточно.
Качество решения напрямую связано с оценкой.
38 попугаев и 1 попугайское крылышко?
PM/PL/бизнес регулярно спрашивают Тимлида, когда команда завершит работу над функциональностью/проектом. Тимлид в таком случае даёт сроки завершения сам или делает оценку вместе с командой. Оценка для заказчика даётся несколькими агрегированными значениями, например дата завершения и стоимость ( или в количестве часов) . Тимлид или команда регулярно дают оценку так же одним числом ( например, 100 часов, 10 попугаев , или через неделю).
Сама по себе оценка одним значением возможна, например команда годы работает над одной предметной областью и кодовой базой. За годы работы мозг сам научился «что» и «сколько» времени займет, т.е. навык оценки в данном конкретном проекте формировался неосознанно . Но что, если природа проекта препятствует естественным образом сформировать такой опыт? Так же при смене проекта сотрудник будет довольна таки продолжительное время учиться оценивать свои работы в новом проекте.
Неосознанная оценка будет работать, когда
- требования к проекту совпадают с личным опытом к сотрудника
- и/или когда всё вокруг замерло и меняется очень редко
Если продукт меняется , в команду приходят новые сотрудники , оценка «одним значением» , как бы, подменяет состав работ. Подмена состоит в том, что оценка делается , в основном, изходя из прошлого опыта, а не реальной ситуации. Можно вообще не оценивать и дать возможность команде сделать, как она умеет.
При оценки «одним числом» ( или датой) упускается из вида когнитивная сложность продукта , стандартов команды/компании и целей.
Основной причиной таких оценок «одним числом» отсутствие структуры оценки.
Нервируют и не дают рефакторить
Как следствие выше описанного возникает разрыв в ожиданиях между разными участниками производства.
Тимлид регулярно сталкивается с тем, что бизнес недоволен сроками завершения работ над задачами. Сам Тимлид регулярно сталкивается с тем, что участники команды срывают собственные сроки сдачи работ.
Аналитики, разработчики и тестировщики сами страдают от того, что их нервируют с вопросом, когда они уже наконец закончат.
Тимлид и команда сталкиваются также с тем, что бизнес не даёт рефакторить и складывается ощущение, что бизнесу не нужно «качество».
Структура оценки
Вместо оценки «одним числом» можно разделить её на компоненты. Например , как самый простой вариант разделить на оценку по разным компетенциям в команде:
Итоговое значение оценки будет суммой компонентов.
Если есть стандарты , которые каждая компетенция должна выполнять, их можно также указать. Например, аналитика может содержать
И так далее по остальным компетенциям. Суммарная оценка будет суммой оценок по всем компетенциям, а каждая оценка по компетенции будет сумма входящих в неё работ.
Можно также добавить верхнеуровый состав работ (5-7 пунктов), который планируется сделать в рамках разработки фичи.
Такую структуру можно обсуждать с разными участниками производственного процесса ( бизнес , PO/PL/PO, архитектор) для согласования того самого качества и выравнивания ожиданий.
Саму структуру оценки можно сделать в виде шаблона и каждый раз использовать его для оценки работ, сделав оценку артефактом.
Если Тимлид осознанно подходит к управлению команды и у него описана модель команды (структура, цели и процессы ) и технология производства , то структуру оценки можно привязать к процессам и ожиданиям компании по достижению целей .
Утаптывание
После данной оценки регулярно происходит своеобразный торг ( утаптывание оценки). Торг связан с попыткой другой стороны понять, чем обоснована такая оценка .
Имея структуру оценки можно объяснить , что именно туда включено. При необходимости уменьшить стоимость, ускорить поставку , можно явно указать от чего отказываемся . При реализации будет понятно, что команда делает, а что нет и в каком объёме.
Оценка - это формирование ожидания о качестве и сроке, которое мы можем воплотить в жизнь.
Наличие оценки , как артефакта , дает Тимлиду понятный механизм по контролю за ходом работ по разработки функциональности.