Практически постоянно на проектах вижу такого рода постановки задач:
[DEV] Разобраться с логированием при ретрае
Реализовать отчеты
NGINX. Мониторинг и логирование
Реализовать статусную модель
[ENG] Настроить мониторинг для мониторинга
Что объединяет эти формулировки?
Простота постановки
Отсутствие конкретики
Знакомы ли вам такие постановки?
К сожалению, с такими постановками я сталкиваюсь постоянно, независимо от проекта и компании, в которой работаю. И самое грустное в таких задачах - их реализация никогда не совпадают со своими оценками. А это значит, что задачи не сдают в условленный срок. Затем начинается тягучий процесс, когда менеджеры постоянно спрашивают "когда доделаете?", а инженеры виновато говорят, что ещё не готово, и начинают оправдываться: мол, появились новые вводные / подводные камни / неучтённые обстоятельства и т.п.
И так повторяется из недели в неделю, из спринта в спринт...
Я не люблю оправдываться. Это выглядит так, что ты обещал сд��лать и не сделал. Поэтому стал искать решение, как точно оценить объём работ по задаче. И мне удалось найти одно. Оно позволяет мне оценивать крупные задачи и максимально близко (90+%) попадать в оценке к реальным трудозатратам.
Крупная задача - как мечта
И начну я с одной известной фразы:
"I have a dream..." (У меня есть мечта..., - пер. с английского).
Эта фраза одного политического деятеля нашла отклик в сердцах миллионов людей по всему миру и стала крылатой.
Мечта - это слово, знакомое нам с детства, ведь начиная с детского возраста человек мечтает. Например, стать лётчиком или о покупке заветной игрушки. Вырастая, мечты не уходят, более того, появляются новые.
Но в каком бы возрасте человек ни мечтал, у всех мечт есть нечто общее: желанность и сложность в достижении. И именно сложность достижения наши желания со временем превращает в мечты. А в чём выражается сложность? - В количестве усилий и объёме работы, которую нужно сделать, чтобы исполнить мечту. Поэтому мечта похожа на крупную задачу:
у всех мечт, как правило, простые и лаконичные названия (постановки)
у всех мечт в названиях мало конкретики
И все, кто когда-либо пытался осуществить свою мечту, знают: мечтается - легко, а воплощать мечты в жизнь - трудно.
Чтобы разобраться, почему так, предлагаю посмотреть на мечту как на крупную задачу в task-трекере. Тогда слово "мечтать" станет постановкой крупной задачи. Например, стать лётчиком. А воплощать мечты в жизнь - это уже шаги реализации задачи. Например, действия, которые нужно выполнить, чтобы выучиться на лётчика и найти работу по этой специальности.
В сфере разработки программного обеспечения за постановку задачи отвечает менеджер, а за решение задачи - инженер.
Менеджер не погружается в детали реализации задачи и смотрит на неё словно издалека, видя только общие очертания, - отсюда как раз и возникает та простота постановки задачи. А инженер, в свою очередь, смотрит на задачу с более близкого расстояния, поэтому он видит больше деталей - конкретные шаги, которые нужно сделать, чтобы решить задачу.
И именно поэтому мечтать и претворять мечту в жизнь - разные вещи, т.к. требуют разных компетенций. Но на этом разница не заканчивается, и я продемонстрирую её на примере решения такой крупной задачи, как строительство дома.
Экспертная оценка
Как видят объём работ одной и той же задачи менеджер и инженер?
Менеджер обычно не владеет компетенциями инженера, поэтому в лучшем случае, он знает примерный порядок действий, которые нужно выполнить. И с позиции менеджера создаётся видение объёма работ как при строительстве небольшого одноэтажного домика.
Инженер же, как исполнитель, смотрит на задачу через призму конкретных шагов, которые нужно выполнить, и поэтому объём работ совершенно другой, как при строительстве многоэтажного дома.
В итоге разные специалисты расходятся в понимании объёма работ одной и той же задачи. Поэтому и оценки будут отличаться, и у инженера она будет точнее, т.к. он видит больший объём работ. И именно поэтому менеджеры всегда идут за оценкой к инженеру.
Его оценка называется экспертной.
Но, к сожалению, оценка крупной задачи, сделанная инженером, частенько оказывается меньше, чем реальное время её выполнения.
Почему же так получается?
Экспертная оценка с коэффициентом
Чтобы разобраться, почему экспертная оценка имеет низкую точность, нужно посмотреть на её алгоритм. И здесь мы сталкиваемся с одним из недостатков экспертной оценки - каждый эксперт по-разному высчитывает оценку. Я пробовал разные методы экспертной оценки и самый лучший результат получал, используя следующий алгоритм: представляю последовательность действий, которые нужно сделать, и точку (финишную ленточку), когда задача будет считаться решённой. Зная начало и предполагаемый конец задачи, можно получить представление об объёме работы над задачей, и уже после этого дать оценку.
Такой алгоритм оценки понятен и интуитивно кажется правильным, но на практике он очень часто даёт ошибку, оценка получается сильно ниже, чем реальные трудозатраты. И основная проблема такого алгоритма кроется в том, что предполагаемый при оценке конец задачи на самом деле мираж, подобный тому, что изображён на картинке:
Стоит отметить, что мираж не иллюзия, а оптический эффект. Это значит, что мираж всегда показывает реальный объект, только не в том месте, где он реально находится. И эффект миража возникает из-за специфики работы нашего мозга - мы воспринимаем видимые объекты, словно они лежат на прямой, тогда как свет движется по кривой.
Из наблюдений, при экспертной оценке оценщик всегда представляет успешный и кротчайший путь решения крупной задачи, а такой путь всегда является прямой. Но неизменно при реализации крупной задачи всегда всплывают неучтённые требования, обстоятельства и прочие подводные камни. А значит, решение задачи - это извилистая кривая. И именно поэтому представляемая экспертом точка завершения задачи является миражом.
Это утверждение подтверждается моим опытом: реальные трудозатраты по крупной задаче почти никогда не попадают в оценку выполненную экспертом. И многие опытные менеджеры знают об этом, поэтому они умножают экспертную оценку на определённый коэффициент.
Такой вид оценки так и называется: экспертная оценка с коэффициентом.
Сложность этого вида оценки заключается в выборе подходящего коэффициента. Можно найти много различных методик его расчёта: от простого "Pi * оценка / 2" до сложных математических формул. Такой вид оценки даёт более лучший результат, чем обычная экспертная оценка, но всё равно частенько промахивается как в меньшую, так и в большую сторону. Поэтому эта оценка также не даёт уверенности в её точности.
Так как же сделать оценку точнее?
Парадокс точной оценки задачи
Для поиска ответа я сделал следующее:
Взял схематичное изображение экспертной оценки с коэффициентом, взял график параболы, который очень похож на кривую из оценки с коэффициентом, и наложил их друг на друга.
Важно понимать, что парабола на графике - это очень упрощённая модель кривой оценки трудозатрат по задаче, с которой просто удобно работать человеку. В реальном проекте у каждой задачи своя уникальная кривая. И уравнение такой кривой неизвестно, а выводить его классическими математическими способами необоснованно трудозатратно, если вообще возможно, т.к. количество входящих параметров невероятно велико.
Но парабола была выбрана в качестве модели не только для простоты. На собственном опыте я убедился, что ошибка в экспертной оценке резко возрастает с размером задачи, т.е. чем крупнее задача, тем сильнее ошибка в оценке. И в данном примере график параболы очень хорошо демонстрирует эту нелинейную зависимость.
Поэтому найти подходящий коэффициент - это одна из самых больших сложностей экспертной оценки с коэффициентом, т.к. простое умножение на одно число - это линейная зависимость, а ошибка оценки зависит нелинейно от размера задачи.
Подведу итог вводных в решаемую мною задачу:
полное уравнение кривой (путь решения задачи) неизвестно на старте задачи
у каждой задачи своё уникальное уравнение кривой
вычислить уравнение кривой необоснованно трудозатратно, если вообще возможно
размер ошибки оценки нелинейно зависит от размера задачи
По сложившимся условиям я сразу понял: искать формулу, применимую ко всем решаемым задачам в мире, - абсолютно бесполезное занятие. Мир слишком разнообразен, постоянно меняется и каждая задача уникальна со своим контекстом и набором переменных. Поэтому нужен какой-то инструмент, который не зависел бы от контекста решаемой задачи. И подсказку я нашёл в своём же графике: из школьного курса алгебры мне вспомнился инструмент, который умеет определять скорость изменения функции, - это производная.
Как уже было сказано, полное уравнение кривой (путь решения задачи) неизвестно на старте задачи, поэтому нет возможности взять производную. Но я вспомнил, что у производной есть геометрический смысл, и отобразил его на графике. Перпендикуляр, выходящий из реального конца задачи на пересечении с касательной, образует точку, тот самый видимый конец задачи - мираж, который видит в оценке инженер.
При оценке эксперт видит успешный путь решения задачи. А это - прямая. Эксперту кажется, что он видит весь объём работы, а значит, видимый им конец задачи - реальный. Но это заблуждение, мысленный оптический обман, на самом деле он видит мираж реального завершения задачи.
Это заключение согласуется с теми знаниями, которые известны из школьного курса алгебры:
касательная делит перпендикуляр на два отрезка
линейное приращение аргумента
нелинейное приращение аргумента (иногда его называют ошибкой)
Линейное приращение (отрезок с цифрой 1 на графике) - это тот объём, который видит эксперт при оценке. А все неучтённые требования, обстоятельства и прочие подводные камни скрываются в нелинейном приращении (отрезок с цифрой 2 на графике). Именно нелинейное приращение олицетворяет собой ошибку в экспертной оценке.
Обратите внимание, насколько нелинейное прир��щение больше линейного, если мы находимся на старте решения крупной задачи. Но из своего опыта я знаю, что стоит начать решать задачу, как сразу начинают проявляться детали решения (те самые подводные камни и неучтённые нюансы), которые были не видны с самого начала.
И если попытаться переоценить задачу после того как над ней немного поработал исполнитель, то ошибка в оценке уменьшается, а видимый конец задачи начинает приближаться к реальному:
И чем больше исполнитель работает над задачей, тем яснее становится оставшийся объём работы, а значит, уменьшается ошибка в оценке:
В какой-то момент видимый и реальный концы задачи совпадут друг с другом. Как правило, это получается уже перед самой финишной ленточкой.
И теперь на основе графика экспертной оценки я могу дать ответ на поставленный вопрос: как же сделать оценку точнее?
Чтобы понять реальный объём работы, мне нужно реально пройти все шаги реализации задачи.
Получился парадокс: чтобы точно оценить задачу, нужно её выполнить.
Искусство оценки задачи
Как разрешить парадокс?
Известно: если возникает парадокс, это значит, что как минимум одно из условий ложно. Я перепроверил условия задачи, ход своих рассуждений, формулировки парадокса и, к сожалению, не смог обнаружить ложное условие.
Помощь в решении парадокса пришла от людей, которые зачастую с ИТ имеют мало общего. Удивительно, но оказалось, что поставленную мной задачу оценки довольно давно и весьма успешно решают в другой области - в области ориентирования на местности. Во время походов туристы постоянно ставят перед собой задачу оценки времени пути из пункта А в пункт Б. Иногда такие маршруты неизведаны человеком, но чаще всего это уже кем-то ранее пройденные маршруты. Но тем не менее каждый такой поход представляет собой абсолютно уникальный набор параметров: погодные условия, участники маршрута, их опыт, снаряжение и т.п. А это всё очень похоже на решение задачи в любом ИТ-проекте.
Как же оценивается время прохождения маршрута? Ведь я точно знаю, что оценщик реально не проходит весь маршрут перед тем, как определить места ночёвки, сколько провизии взять и сколько дней займёт весь подход. Прохождение маршрута выполняется мысленно по карте местности, основываясь на предыдущем опыте и своих возможностях.
И здесь я осознал ложное условие в парадоксе: нужно реально пройти все шаги реализации. Слово "реально" наталкивало меня на то, что нужно уже решить задачу. А это ложное утверждение. Чтобы дать точную оценку, необязательно реально решить задачу, можно это сделать мысленно, составив дорожную карту решения.
Составляя дорожную карту решения, мы описываем маршрут решения задачи: контрольные точки решения, направление движения и финишную точку. И такой маршрут представляет собой модель решения задачи. Поэтому процесс оценки задачи - это моделирование её решения.
Сам процесс моделирования представляет собой получение приближённой копии оригинала, но не сам оригинал. Поэтому погрешность при моделировании будет присутствовать всегда, а значит, ошибка в оценке, к сожалению, тоже будет неизбежна. Но ошибку можно минимизировать, прнедставив более точную модель будущего решения. Другими словами, чем выше точность модели будущего решения, тем ниже ошибка в оценке, но в этом случае вырастают трудозатраты на составление такой точной модели.
Таким образом, я определил:
искусство оценки задачи - это составление модели решения, где ошибка оценки должна стремиться к нулю, но никогда не будет равняться нулю.
Трудозатраты на оценку без ошибки уходят в бесконечность, в этом случае дешевле и проще сделать задачу и залогировать реальное время выполнения. Поэтому важно найти баланс между трудозатратами на составление модели и точностью оценки, которые нужно получить.
Проверка экспериментом
Когда я готовил материал, то решил провести целенаправленный эксперимент, чтобы ещё раз проверить точность оценки по методу дорожной карты.
На своём текущем проекте я выбрал такую задачу:
Перевести микросервис ABC со Spring Framework на Jakarta EE и Libercat
Функции микросервиса:
вычитать сообщение из очереди и отправить его в ES
сохранить в БД информацию о выполненном действии
Экспертная оценка по этой задаче составила: 24ч.
Затем была составлена дорожная карта будущего решения задачи. Другими словами: выполнено моделирование будущего решения.
Вот дорожная карта:
Заменить Spring Data ES на Jakarta EE реализацию
Перевести текущую Spring Camel на Jakarta EE реализацию
Заменить Oracle JDBC драйвер на Postgresql драйвер
Заменить Spring Data JPA на Jakarta EE JPA
Заменить Spring Web на Jax-RS
Заменить Spring Core на Jakarta EE и Libercat
Настроить запуск приложения в docker контейнере
Затем была выполнена экспертная оценка каждого шага в отдельности, а полученные оценки просуммированы. Таким образом, была получена оценка по методу дорожной карты: 77 ч.
Далее список подзадач, полученный во время оценки методом дорожной карты, был передан исполнителю, который не участвовал в оценке, не знал о проводящем эксперименте и не знал оценок задач. Исполнителю не ставились никакие ограничения по времени (deadline'ы) решения задач. Всё что ему требовалось сделать:
брать подзадачи по списку
решить задачу, как исполнитель считает нужным
залогировать время работы над задачей
После реализации всех подзадач, было просуммировано время залогированное на решение каждой из них. Реальное время решения задачи составило: 80ч.
Итого получилось:
Экспертная оценка | Оценка по методу | Реальные трудозатраты |
24ч. | 77ч. | 82ч. |
Точность оценки | ||
24 / 82 = 0,2926 * 100% = | 77 / 82 = 0,9390 * 100% = | |
И добавлю для дополнительного примера экспертную оценку с коэффициентом, хотя в эксперименте такая оценка не проводилась:
Точность оценки методом экспертной оценки с коэффициентом Pi*оценка/2:
(3,14* 24 / 2) / 82 = 37,68 / 82 = 0,4595 *100% = 45,95%
в 3,2 раза оценка по методу дорожной карты оказалась точнее экспертной оценки задачи в целом
в 2,04 раза оценка по методу дорожной карты оказалась точнее экспертной оценки задачи в целом с коэффициентом
Оценка по методу дорожной карты в этом эксперименте оказалась не просто самой высокой, она получилась очень близкой к реальным трудозатратам. И аналогичные результаты я получал во всех проектах, где пользовался оценкой по методу дорожной карты.
Но хочу обратить внимание, что ошибка в оценке всё-равно присутствует. Т.к. искусство оценки задачи - это моделирование её будущего решения, и чем точнее нужна модель, тем больше трудозатрат нужно на её составление.
Заключение
Читая статью, кто-то может подумать, что я просто рассказал про декомпозицию задачи и оценке её маленьких частей. И отчасти будет прав. Но слово "декомпозиция" довольно абстрактное и обобщённое. И интуитивно не очень понятно, как делить задачу, откуда начинать.
Возможно, кто-то ещё вспомнит аналогию про слона, которую используют для объяснения декомпозиции. И снова этот человек отчасти будет прав. Но метафора "разрезания слона", как и "декомпозиция", интуитивно не подсказывает, как делить задачу и откуда начинать: где у слона находиться начало, а где конец? Более того, разрезание живого существа, пусть и фигурально, лично у меня не вызывает симпатии и отбивает желание пользоваться этой аналогией.
А вот составление дорожной карты - это составление маршрута. У любого маршрута есть начальная и конечная точки, как и у любой задачи. У маршрута есть траектория движения, а из школьного курса математики известно, что любую кривую можно разбить на отрезки. Таким образом, получить ключевые точки маршрута, но чаще всего используют слово milestones или вехи. И эти понятия они все взяты из нашей реальной жизни и более интуитивно понятны для человека.
И самое интересное, составляя дорожную карту, ты неявно делаешь декомпозицию задачи. Другими словами, декомпозиция задачи - это не цель дорожной карты, а следствие, т.е. дополнительный результат полученный после составления дорожной карты. Цель любой дорожной карты - это построение маршрута, чтобы понять, как из начальной точки попасть в конечную.
После построения маршрута на дорожной карте появляются ключевые точки. Если переложить терминологию дорожной карты в плоскость решения задачи, то ключевые точки маршрута превращаются в этапы решения задачи - шаги, которые нужно сделать, чтобы завершить задачу. Шаги решения дают более чёткое понимание объёма задачи, это делает процесс оценки и работы над задачей более прозрачным. И когда менеджер видит большое количество шагов в задаче и большую оценку, то он интуитивно охотнее в неё верит, чем если бы эксперт просто назвал большую оценку.
Поэтому искусство оценки задачи - это составление модели её решения. Модель решения задачи представляет собой этапы решения задачи. И чем точнее будет ваша модель, тем более точную оценку вы сможете дать по задаче.
Бонус: плюсы и минусы оценок
В качестве дополнения распишу плюсы и минусы оценок, перечисленных в статье, а также допишу те виды оценки, которые не были озвучены в статье, но сейчас популярны.
Экспертная оценка
Оценка задачи экспертом в области её решения.
Плюсы:
эксперт в проф. области задачи ближе всего стоит к решению задачи, поэтому зачастую видит больший объём работ, чем другие участники проекта
Минусы:
метод оценки для окружающих - чёрный ящик, непонятно каким способом вычислена оценка
чем крупнее задача, тем больше ошибка в оценке
нет гарантии, что учтены все детали решения, т.к. нет способа верифицировать, что эксперт полностью вник в задачу и контекст вокруг неё
точность оценки сильно зависит от опыта эксперта и знания проекта
обычно эксперт не учитывает риски, например, связанные с человеческими ресурсами
все эксперты оценивают по-разному: кто-то берёт оценку из опыта решения похожей задачи, кто-то в голове прикидывает "что нужно сделать по задаче", кто-то просто рисует цифру по принципу "непонятно, что там делать, но в этот срок точно должны успеть" и т.п.
оценка обычно не учитывает исполнителя, который будет выполнять работу
Экспертная оценка с коэффициентом
Оценка задачи экспертом в области её решения, умноженная на коэффициент. Коэффициент к оценке обычно добавляет менеджер.
Плюсы:
все плюсы экспертной оценки
величина коэффициента может учитывать риски по задаче (например, непредвиденные ситуации, болезнь сотрудника и т.п.)
Минусы:
все минусы экспертной оценки, кроме рисков.
сложность в вычислении подходящего коэффициента для каждой задачи
чаще всего (из виденного мной на проектах) менеджеры применяют один и тот же коэффициент ко всем задачам, не вычисляя коэффициент под конкретную задачу
Составление дорожной карты задачи и оценка каждого этапа
Составление дорожной карты решения задачи, оценка каждого этапа задачи и суммирование оценок.
Плюсы:
можно получить оценку очень близкую к реальным трудозатратам
по ключевым точкам решения можно верифицировать какие детали решения учтены, а какие - нет
точность оценки мало зависит от опыта эксперта и знания проекта, т.к. дорожная карта - это артефакт, который может быть дополнен, скорректирован другими участниками проекта
составление дорожной карты можно делегировать другому участнику команды, а оценку, например, провести более опытному эксперту на проекте
декомпозиция задачи как побочный продукт составления дорожной карты
шаги решения дают чёткое понимание объёма задачи, это делает процесс оценки и работы над задачей более прозрачным
Минусы:
чем крупнее задача и / или чем точнее нужно получить оценку, тем больше требуется трудозатрат на составление дорожной карты
оценка обычно не учитывает исполнителя, который будет выполнять работу
если руководствоваться принципом единственной ответственности, то, строго говоря, составление дорожной карты и декомпозиция задачи не входит в понятие "оценка"
Оценка путём сравнения с ранее решённой задачей
Сравнить насколько ранее решённая задача по объёму работ меньше\больше оцениваемой задачи.
Плюсы:
(не выявлены)
Минусы:
сложный выбор задачи для сравнения
часто оценщик плохо представляет объём работ ранее решённой задачи, т.к. обычно не является её исполнителем
сложность определения объёма задачи по оцениваемой задачи
сложность сравнения двух абстрактных объёмов работ
включает все минусы экспертной оценки
Покер планирования (Planning poker, Scrum poker)
Возможно, не стоило сюда включать этот вид оценки, т.к. он чаще всего используется для оценки сложности задачи, а не объёма работы в часах. Но он сейчас довольно популярен и, на мой взгляд, можно использовать его и для оценки количества часов, т.к. концептуально методу всё-равно в каких единицах измерения проводится оценка.
Опишу принцип работы, т.к. из него будут вытекать плюсы и минусы такого метода оценки.
Принцип работы (авторское видение):
В основе работы покера планирования лежит Центральные предельные теоремы (ЦПТ) из теории вероятности. Вкратце:
Сумма достаточно большого количества слабо зависимых случайных величин, имеющих примерно одинаковые масштабы (ни одно из слагаемых не доминирует, не вносит в сумму определяющего вклада), имеет распределение, близкое к нормальному (цит. - wikipedia).
По этой причине в покере планирования важно закрытое голосование и одновременная публикация результатов голосования. Формула, по которой считается сумма слабо зависимых случайных величин (оценок членов команды, участвующих в покере планирования), определяется командой или ведущим покера планирования.
Дальше могут быть разновидности проведения покера планирования, например: комментарии людей, чьи оценки имеют наибольший выброс от общего распределения оценок, высказывания экспертов и дальнейшее переголосование, что может повлиять на оценку за счёт появления доминирующих слагаемых.
Плюсы:
в основе приниципа работы заложен математический аппарат
оценка привязана к производительности команды, в целом основывается на её опыте
в оценке участвует больше одного человека (как эксперты, так могут привлекаться и не эксперты внутри команды)
минусы экспертной оценки нивелируются за счёт того, что их оценка рассматривается как случайная величина (справедливо только при первом голосовании, при повторном голосовании это утверждение несправедливо)
Минусы:
требуется определённое количество итераций покера планирования, чтобы получить нормальное распределение "оценка - производительность команды"
скорость стремления к нормальному распределению зависит от постоянства состава команды. Если в команде часто ротируются люди (нет костяка, который прошёл вместе много итераций покера планирования), то это негативно влияет на точность оценки и скорости стремления к нормальному распределению
как правило не учитывается контекст задачи, этапы решения задачи
плюсы экспертной оценки нивелируются за счёт того, что они рассматриваются как случайные величины (справедливо только при первом голосовании, при повторном голосовании это утверждение не справедливо)
проработка этапов решения задачи, как например, в оценке с применением составления дорожной карты, не предполагается, она должна быть выполнена либо до оценки, либо уже после
оценка не учитывает исполнителя, который будет выполнять работу, вместо этого берётся производительность команды в целом
