Эта статья посвящена интересному, на мой взгляд, аспекту – оценке. Оценка может быть не гаданием на кофейной гуще, а очень крутым инструментом. Я покажу, как собирать статистику, как попробовать с ней поработать. Будут формулы, будет немного философии, будет даже матан.
Зачем нужна оценка и сбор требований
На каждом проекте, на каждом этапе есть необходимость что-то оценить. Это может быть пресейл, какое-то крутое ТЗ, просто словесная постановка от РП или от продавца, что нужно что-то прикинуть, дать индикатив.
Как только вы получаете такую задачу, необходимо получить как можно больше дополнительной информации. Сколько у нас есть времени? Какая должна быть оценка – точная, неточная, индикативная? Возможно, она нужна для того, чтобы спланировать спринт.
Все эти вещи влияют и на точность, и на саму оценку. Всегда следует держать в голове практический смысл оценки. Для разработчиков он заключается в том, что мы резервируем для себя квант времени.
Мы оценили задачу в условные 40 часов – значит, эти 40 часов можем сконцентрироваться на этой задаче и работать над ней. Если некорректно оценить задачу в условные 20 часов, этот гэп в 20 часов нужно будет как-то догонять.
У того, кто запрашивает оценку – РП, ТА или ФА, без разницы, кто к вам пришел, – уточните, насколько она должна быть детальной, укрупненной и так далее. Тем самым мы помогаем этим людям работать с ожиданиями того, кто пришел к ним.
К нам приходят за компетенцией. Возможно, человек, который к вам пришел, обладает этой компетенцией, но не обладает другим ресурсом – временем. Ему нужно помочь. Сделайте это квалифицированно.
Процесс оценки, риски и прозрачность
Если мы используем метод «три П» – всем известный «пол, палец, потолок», – получим соответствующий результат.
Не стоит идти на поводу и давать первую пришедшую на ум оценку. Нужно постараться снизить степень неопределенности и дать более реалистичную оценку.
Если проигнорировать этот момент, будет сложно обосновать перед заказчиком, а тем более ответить на вопрос: почему так дорого.
Если оценка завышена – это один разговор. Если оценка занижена – тогда придется отчитываться перед РП, к которому мы придем с просьбой добавить часов на разработку.
Еще один важный момент. Если задача приходит уже с оценкой и вы видите, что не умещаетесь, сразу сигнализируйте об этом. Тот, кто пришел с этой оценкой, должен понимать, что есть риск: возможно, здесь нужно будет дозаложиться, здесь может возникнуть проблема.
Будьте прозрачнее, идите на контакт, выстраивайте взаимоотношения. Это тоже важно.
В процессе оценки важно фиксировать, какие риски для этой задачи вы видите. Вы работаете над ней и понимаете, что что-то может пойти не так – сообщайте об этом. Не храните это у себя в голове.
К вам пришли за компетенцией. Расскажите человеку, который пришел за этой компетенцией, что может пойти не так. Это его первое поле для битвы.
Мы не работаем в вакууме. Процесс оценки задач – это запрос от конкретного человека, и он очень сильно замотивирован в том, чтобы эта оценка сыграла как надо, а задача была решена.
Философия ошибок и неопределенности
Ошибаться – это нормально. Кроме орфографических ошибок. Но хуже всего ошибки, конечно, в коде.
Тем не менее ошибаться – более чем нормально. А вот не делать выводов из своих ошибок – уже в корне неправильно.
Я понимаю разработчиков. Я сам был разработчиком. Разработчики работают в потоке: одна задачка, вторая, третья. Времени на рефлексию часто не хватает – его либо не выделили, либо просто не успели. Но за вас это никто не сделает. Пока вы сами не начнете анализировать себя, к сожалению, никто в этом не будет заинтересован больше, чем вы.
Оценка, на мой взгляд, – это всегда компромисс между неопределенностью и вашими навыками. Чем выше навыки, тем сильнее вы можете сократить неопределенность. И наоборот. Если задача абсолютно неясна, такой и будет оценка. Не хватает компетенций – так бывает.
История и принципы метода PERT
Что же такое PERT? Как и многое в этом мире, он был изобретен военными.
Это инженерный метод оценки трудоемкости – Program Evaluation and Review Technique. Он был разработан в 1958 году, когда внезапно NASA понадобилось изобрести ракету, которая показана на изображении. Это ракета Polaris.
Что им нужно было сделать? Была амбициозная задача – объединить между собой очень много подрядчиков. В разных источниках приводятся разные цифры: от 50 до 150 организаций. Возможно, точные данные до сих пор засекречены. Представьте: очень много организаций нужно было между собой связать так, чтобы ракета была создана.
Ребята серьезные, поэтому считаю, что им можно доверять.
В основе методики лежат несколько принципов: выявление задач, или декомпозиция, и трехточечный метод оценки. Каждый из них рассмотрим отдельно.
Декомпозиция и взаимодействие с заказчиком
Основой методики является декомпозиция – процесс разбивки сложной задачи на более мелкие управляемые задачи. Основная цель – снижение и локализация неопределенности.
Каждая задача должна быть атомарной и сформулирована так, чтобы вы сами для себя ее понимали. Не просто «разработать документ», а разработать конкретный документ. У вас должно сразу возникнуть понимание, что именно здесь написано. И если вы внезапно вернетесь к этому через месяц или через полгода, прочитав формулировку, вы сразу поймете, о чем идет речь.
Скорее всего, то, что я сейчас скажу, звучит банально и заезженно, но это стоит проговорить. Не все это понимают.
Залог успеха в разбивке задач – предварительный анализ. Если вам что-то неясно, если вы что-то недопонимаете, задавайте вопросы. Чем больше ответов вы получите, тем точнее получится оценка. Все просто.
Помогите своим коллегам найти точки неопределенности. Подсветите эту неопределенность и предложите заложить больше времени. Возможен вариант, когда РП скажет: «Я беру риски на себя». Окей. Мы это зафиксировали, все понимают ситуацию.
Оценка может и должна вызывать обсуждение на стороне заказчика. Всегда возникает история переговоров, когда заказчик говорит: «Почему так много? У меня кто-то – подрядчик, внутренняя команда или еще кто-то – оценил иначе».
Но на нашей стороне будет анализ. Тот, кто ведет переговоры, сможет отстоять свою точку зрения, потому что у него есть информация. Мы провели анализ и сможем толково объяснить людям, почему получили именно такую оценку. Либо получим от них обратную связь.
Иногда могут сказать: «У нас есть эксперт, можете его опросить. Он архитектор системы». Отлично. Это как раз то, что нужно.
Всего знать невозможно. Если у вас не хватает компетенции для оценки, запрашивайте помощь: чат, ИИ, ТА и так далее. Локализуйте эту проблему и как можно быстрее ее закройте.
Если же компетенций ни у кого нет и даже в сети нет информации – такое тоже бывает – расскажите об этом РП или тому, кто запросил у вас оценку. Скажите прямо: «Ребята, мы зашли на terra incognita. Здесь возможен только индикатив и исследование».
Если всех это устраивает – идем дальше. Если не устраивает – хорошо, что не взялись за эту задачу. Скорее всего, ничего хорошего из этого не получилось бы.
Оценка задач – это навык, который, как и прочие навыки, можно и нужно прокачивать и развивать.
Перед отправкой задачи посмотрите на то, что у вас получилось. Проверьте, правильно ли вы понимаете каждую из задач. Возможно, стоит еще сильнее разбить их на части. Не спешите. Это игра, в которую нужно играть не спеша.
Трехточечный метод оценки
Я обещал, что будет матан – вот он. На изображении представлена формула. В ней используются три оценки: оптимистичная, реальная и пессимистичная.
-
Оптимистичная оценка – это принцип: быстрее мы уже точно не сделаем. Все прошло идеально, все пошло по маслу.
-
Реальная оценка – компромисс между оптимистичной и пессимистичной. Предполагается, что какие-то риски все же сработают, и задача будет выполнена в условиях обычной рабочей реальности.
-
Пессимистичная оценка – ситуация, когда все пошло не так. Практически все, что могло пойти не так в этой задаче, действительно пошло не так.
Эта формула уже заложена в шаблон, поэтому рекомендую пользоваться ею.
В формуле используется коэффициент 4. Возникает вопрос: почему умножение на четыре помогает сделать оценку более корректной?
Здесь применяется средневзвешенная оценка. Чтобы снизить влияние крайних значений – оптимистичной и пессимистичной оценки – результат смещается в сторону реалистичного значения. Это делается с использованием закона нормального распределения.
Иначе говоря, попасть в область четырех средних сигм гораздо проще, чем в значения, находящиеся на самых краях распределения. Это подтверждает известная величина 68,2%. Оценка – это вероятностная характеристика, и предполагается, что она подчиняется нормальному закону распределения. Чуть позже этот момент будет еще раз подсвечен.
В шаблоне используется не только эта формула. Еще одна формула рассчитывает среднеквадратичное отклонение. В ней используются пессимистичная и оптимистичная оценки.
Среднеквадратичное отклонение показывает разброс возможных значений времени выполнения задачи вокруг ожидаемого времени. Чем больше это значение, тем выше неопределенность. За этим коэффициентом нужно следить. Если он больше двух, оценку стоит пересмотреть.
Есть еще один коэффициент, который я ввел при подготовке этой статьи. Это отношение предыдущего коэффициента к самой оценке. В общем случае, если этот показатель больше 20%, стоит задуматься. Либо мы ушли в излишний оптимизм, либо слишком сильно в пессимизм. В любом случае с этой оценкой что-то не так, и на это нужно обратить внимание.
И, наконец, основная формула – более серьезная. Самое интересное в ней – коэффициент 2. Если ее разобрать, это сумма всех средневзвешенных оценок по задачам плюс сумма произведений заградительного коэффициента на среднеквадратичное отклонение.
Почему именно 2? Здесь снова используется нормализация распределения. Но если раньше речь шла о шести сигмах, то здесь используется диапазон трех сигм. Чтобы дать реалистичную оценку с вероятностью около 95%, необходим такой буфер. Чистая статистика.
Пока я готовил эту статью, для меня это было определенной магией. Я получил удовольствие от того, что все эти формулы действительно работают и их можно складывать в свою базу знаний и использовать в работе.
Математики, которые все это придумали, – гении. Если бы я пытался изобрести подобное с нуля, получилось бы довольно убого. А здесь все продумано и работает очень красиво.
И грех не использовать то, что было настолько грамотно и толково придумано до нас.
Оптимальный шаг и паттерны оценки
Размер шага, само собой, зависит от объема задачи. Если задача маленькая – условно час-два-три – то погрешность в 50–100% вполне нормальна.
В процессе подготовки этой статьи у нас возникла дискуссия с ТА внутри компании. Я больше работаю в поддержке, и у нас очень много небольших задач – условно от 8 до 40 часов, это примерно 80% всех задач.
Для меня как для руководителя важно понимать, что разработчик все понял правильно. Поэтому 8 часов для меня – потолок. Я просто заставляю декомпозировать сильнее. Цена ошибки слишком высока.
При этом люди, которые внедряют крупные проекты, говорят: «Слушай, Илья, и 24 часа нормально».
Со временем у вас должны появиться собственные паттерны, подтвержденные статистикой. Например, если вы знаете, что разработка документа занимает 40 часов под ключ – со всеми рюшечками, интерфейсом, проводками, движениями и всем остальным – пользуйтесь этим. Это ваш пруф того, что вы в это укладываетесь. Или ваша команда укладывается. Что бы ни произошло, в 40 часов эту работу можно сделать.
Учет рисков и ответственность
В любой задаче будет доля неопределенности и рисков. Эти риски как раз отражаются в пессимистичной оценке. Важно делать это не наугад. Пессимистичная оценка должна быть основана на анализе, а риски должны быть зафиксированы в файле заполнения оценки. Фиксируйте эту историю – она очень быстро забывается.
Например, не получается провести декомпозицию большой задачи. Или консультанты не могут получить достаточное количество информации. Бывают ситуации, когда у нас есть вопросы, но на них просто некому ответить.
Такие риски часто закладываются в пессимистичную оценку. В результате получается определенная цифра. Но когда начинается работа, вскрывается множество новых обстоятельств.
Все должны понимать, какая неопределенность заложена в оценке. Под «всеми» я подразумеваю всю команду, которая работает над оценкой, а не только вас.
Нужно понимать, что, давая оценку, мы берем на себя ответственность в нее уложиться. Мы подсветили риски, все зафиксировали – значит, за это придется отвечать.
Алгоритм оценки и микротесты
В общем случае алгоритм составления корректной оценки состоит из трех этапов:
-
Получение информации по задаче.
-
Проектирование решения.
-
Расчет трудозатрат.
Есть еще одна полезная практика – микротесты.
Иногда кажется, что задачу можно реализовать, но это «кажется» не дает покоя. Бывает даже, что из-за такой оценки трудно спокойно спать.
В этом случае можно провести микротест. Возьмите 20–30 минут и попробуйте реализовать сложный фрагмент. Например, что-то в СКД или в другой сложной части решения.
У нас был интересный кейс. Нужно было реализовать интеграцию с продуктом «Мой офис». Для него практически нет готовых паттернов. Если бы это был Excel, то можно было бы найти огромное количество материалов о том, как это делать. С «Моим офисом» такого нет – только API.
Чтобы понять глубину задачи, мы провели анализ. На микротест выделили около 10 часов. Общая оценка задачи составляла примерно 500 часов, поэтому такие затраты на проверку были оправданы. Мы сделали микротест и получили результат.
Но важно помнить, что микротесты должны оставаться микротестами. Не нужно делать всю задачу. Многие разработчики сначала реализуют решение, а потом приходят с оценкой: «Вот такая оценка, все готово». А заказчик может сказать: «Мне это не нужно». В этом случае усилия были потрачены зря. Нужно приучить себя давать оценку до момента реализации. Это гораздо правильнее и дает сильный буст.
Чем выше развивается разработчик – сначала middle, потом ведущий разработчик, ТА и так далее – тем с большей неопределенностью ему приходится работать.
Если разработчик привык держать неопределенность в голове по принципу «я сначала что-то разработаю», это начинает ломать процесс. Окей, у тебя внедрение ERP: нужно оценить доработку себестоимости. И что – уйти на несколько недель, реализовать, а потом прийти и сказать, сколько времени это заняло? На мой взгляд, это не совсем верно.
Прозрачность и коммуникация при задержках
Старайтесь делать свою работу максимально прозрачной. Если вы понимаете, что оценка может затянуться, так и скажите: «У меня нет уверенности, что я смогу реализовать эту задачу корректным образом. Мне нужно дополнительное время на оценку».
Сообщите об этом тому, кто запросил у вас оценку.
Если заказчик скажет: «Все, мне уже не надо, вы просрочили», – окей. Завершили работу, взяли следующую задачу. Зато мы избежали негатива: всех предупредили, все прозрачно, все хорошо.
Если вам сказали: «Да», – согласовываем и идем дальше. Значит, вы снова все сделали правильно.
Скрытые трудозатраты и тестирование
Мы подекомпозировали, уточнили, разобрались, посмотрели формулы. Все ли мы сделали, чтобы отдать оценку тому, кто ее запросил? Конечно же, нет.
На самом деле мы сделали крайне недостаточно для того, чтобы отдать оценку тому, кто ее запросил.
Есть трудозатраты, которые я для себя называю скрытыми. Они влияют на саму оценку. На этом изображении приведены трудозатраты для технических специалистов. Для функциональщиков – чуть ниже.
В оценку необходимо включать время, затраченное на оценку. Это очевидно, но в большинстве случаев от разработчика получают только «сколько времени нужно на реализацию», а все допы не учитываются.
А у нас может быть code review. Может быть первичное тестирование – внезапно, откуда оно появилось. Может быть оценка самой задачи. И я рекомендую добавлять такую вещь, как доработка по замечаниям.
Если у тебя жирная задача на 70 часов – для меня это жирная – заложи немножко времени. В любом случае ты сделаешь, покажешь заказчику, он скажет: «Да, это то, что я хотел». Но потом добавит: «Вот здесь кнопочки надо местами поменять». А это снова деплой, снова все подвинуть. И эти крохи по времени нужно будет снова согласовывать. Это бывает очень больно.
Я заказчикам так и рассказываю: «Мы дозаложились вот здесь на случай того, что у вас появятся небольшие хотелки, какие-то рюшечки».
Все это будет в файле, расчетные поля шаблона. Коэффициенты, которые здесь указаны, исторически выверены. У вас они могут быть свои. И у вас они должны появиться свои. Не доверяйте этому слепо – проверяйте все на прочность.
Дальше – скрытые трудозатраты для функциональщиков. У них все немного сложнее. На каждом проекте очень специфичная история: какие трудозатраты включать в общую таблицу, какие – в допы, какие коэффициенты использовать и так далее. Это самый общий список, который я смог вывести для своей команды сопровождения.
Отдельно хочу остановиться на тестировании. Очень важен алгоритм тестирования. Если в начале, когда вы дали оценку, вы не выяснили, какими критериями будете измерять результат, чтобы понять, что задача сделана, – скорее всего, при сдаче будут проблемы. Вы можете все реализовать, но реализовать не то.
Требуйте, чтобы это было отражено: в документах, в чатах или другим способом. Мы у себя применяем ЗНР. В ЗНР должен быть отдельный пункт про тестирование, где аналитик расписывает, как он будет проверять, что вы все сделали правильно. И вам стоит пойти по тому же пути.
И еще важный момент, который приходит только через боль. Когда задача занесена в трекер, должно быть разделение. Есть время на разработку и есть допы. Допы должны идти отдельными задачами. Иначе в общем вале будет сложно разобраться, что пошло не так, у кого и почему.
Проблемы методики и типичные ошибки
Недостаточное количество информации, требуемой для проведения оценки. Возможно, был пропущен или некачественно проведен этап обследования. В этом случае стоит быть более настойчивым и инициировать дополнительное общение до тех пор, пока понимание не появится и у вас, и у заказчика. Заказчиком для вас может быть тот человек, который запросил у вас оценку.
Чрезмерно оптимистичная или чрезмерно пессимистичная оценка. В пессимистичную оценку не стоит закладывать риски «на всякий случай». Все риски должны быть осязаемыми, ясными, понятными и зафиксированными. Вы сами должны понимать, что именно может пойти не так.
Оптимистичная оценка, в свою очередь, должна коррелировать с вашим личным опытом.
Также не стоит оценивать задачу впритык. Если у вас есть небольшая задача, условно на 8 часов, заложите дополнительно один–полтора часа на то, чтобы еще раз все проверить и убедиться, что вы реализовали все необходимое.
Еще один важный момент – рефлексия. Это краеугольный камень. Бывает, что вы все сделали правильно: разнесли задачи в шаблоне, настроили трекер, создали все необходимые задачи, но все равно не уложились в оценку. Это поле для анализа, для ретроспективы, это повод для того, чтобы самому себе придумать ИПР.
Если в компании нет людей, которые могут сформировать для вас ИПР, вы тот человек, который может сделать это для себя. Если вы понимаете, что сложные динамические списки – не ваша сильная сторона, закурситесь. Проблемы с управляемыми формами – закурситесь. СКД вызывает сложности – закурситесь. И так далее.
Еще одна типичная ошибка – слишком детальная декомпозиция. Можно начать разбивать задачу настолько подробно, что получится десятки или даже сотни подзадач. Но это уже не проблема методики, а проблема ее применения.
Со временем приходит понимание, какой уровень атомарности задач является достаточным для вас и вашей команды. И эта проблема постепенно исчезает.
Итоговые рекомендации
Вдумчиво анализируйте задачу. Старайтесь взглянуть на конфигурацию до того, как даете оценку. Это звучит банально, но в мире 1С все постоянно меняется, и знания двухгодичной давности могут уже не соответствовать реальности.
Например, однажды я внезапно узнал в чате, что в «Управлении холдингом» есть характеристики. В той версии, которая построена на Бухгалтерии. Зачем они там – мне пока никто не ответил. Никаких алгоритмов на них не завязано, нигде не используются, но в табличных формах они есть.
Не спешите с оценкой. Задавайте вопросы, уточняйте нюансы, прорабатывайте риски.
Делайте качественную декомпозицию. Разбивайте задачу на подзадачи – так оценка станет точнее.
Используйте микротесты для уточнения сложных мест задачи. Но не забывайте, что микротесты должны оставаться микротестами. Если нужна серия микротестов – проведите ее и дайте обратную связь техническому руководителю: где именно находятся риски.
Работайте со своей командой и давайте ей обратную связь.
И вернемся к началу: ошибаться не страшно, страшно не делать выводов. Посмотрите на свою оценку и попробуйте понять, что было не так и что вы не учли.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.