Практически постоянно на проектах вижу такого рода постановки задач:

• [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ч.

Итого получилось:

И добавлю для дополнительного примера экспертную оценку с коэффициентом, хотя в эксперименте такая оценка не проводилась:

Точность оценки методом экспертной оценки с коэффициентом 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).

По этой причине в покере планирования важно закрытое голосование и одновременная публикация результатов голосования. Формула, по которой считается сумма слабо зависимых случайных величин (оценок членов команды, участвующих в покере планирования), определяется командой или ведущим покера планирования.

Дальше могут быть разновидности проведения покера планирования, например: комментарии людей, чьи оценки имеют наибольший выброс от общего распределения оценок, высказывания экспертов и дальнейшее переголосование, что может повлиять на оценку за счёт появления доминирующих слагаемых.

Плюсы:

• в основе приниципа работы заложен математический аппарат

• оценка привязана к производительности команды, в целом основывается на её опыте

• в оценке участвует больше одного человека (как эксперты, так могут привлекаться и не эксперты внутри команды)

• минусы экспертной оценки нивелируются за счёт того, что их оценка рассматривается как случайная величина (справедливо только при первом голосовании, при повторном голосовании это утверждение несправедливо)

Минусы:

• требуется определённое количество итераций покера планирования, чтобы получить нормальное распределение "оценка - производительность команды"

• скорость стремления к нормальному распределению зависит от постоянства состава команды. Если в команде часто ротируются люди (нет костяка, который прошёл вместе много итераций покера планирования), то это негативно влияет на точность оценки и скорости стремления к нормальному распределению

• как правило не учитывается контекст задачи, этапы решения задачи

• плюсы экспертной оценки нивелируются за счёт того, что они рассматриваются как случайные величины (справедливо только при первом голосовании, при повторном голосовании это утверждение не справедливо)

• проработка этапов решения задачи, как например, в оценке с применением составления дорожной карты, не предполагается, она должна быть выполнена либо до оценки, либо уже после

• оценка не учитывает исполнителя, который будет выполнять работу, вместо этого берётся производительность команды в целом