Сам себе таролог, или учимся оценивать задачи точно

Я Константин, ведущий разработчик 1С и руководитель образовательного направления в Programming Store. Недавно выступал на конференции Infostart Tech Event 2024 — рассказывал, почему важно точно оценивать задачи, и как это делать. Делюсь основными тезисами.

Содержание

Требования бизнеса

Правильно оценивать задачи — не просто галочка в чек-листе. За этим стоят требования бизнеса. Бизнес существует в мире заказчиков, клиентов, налоговых органов и жестких сроков. Ему нужно рассчитывать на четкие дедлайны, чтобы все успеть — от сдачи отчетов до решения кассовых вопросов. Поэтому бизнес проецирует свои ограничения на наши задачи.
Если вы правильно оцениваете задачи, вы управляете рисками, бюджетами и сроками. Правильно выставленные оценки помогают соблюсти баланс между творчеством и реальностью.

Полезно в текущей работе

Разработчик, который умеет оценить задачу, сразу видит, насколько она адекватна с его точки зрения. Если сроки не совпадают с реальностью или кажутся завышенными, он может обсудить это с клиентом или архитектором. Это будут не просто жалобы, вроде: «Как это можно сделать за такой срок?». Разработчик сможет объяснить, почему задача требует больше времени или, наоборот, почему он справится быстрее.

Важно начинать этот диалог в начале работы над задачей, а не когда приближается дедлайн. Своевременное обсуждение помогает избежать неприятных сюрпризов, как для разработчика, так и для клиента. Каждый грейд — мидл, сеньор, архитектор, предполагает свой объем задач для оценки.

Не все любят оценивать задачи. Есть несколько причин почему:

Различия в навыках исполнителей

Следующая преграда на пути к точной оценке — это разница в навыках исполнителей. Как разные типы исполнителей оценивают задачу и время на ее выполнение?
Предлагаю авторскую классификацию разработчиков, чтобы лучше понимать, с кем мы имеем дело.

1. Начинающий разработчик.
Это человек, полный энтузиазма и энергии, но у него много ошибок. Могут быть проблемы с кодированием, пониманием учёта в 1С и вообще с опытом работы. В таких случаях о сроках разработки говорить не приходится, и мы можем либо ставить рядом более опытного разработчика, либо просто передавать задачи другим.

2. Разработчик «Молния».
Этот тип разработчика отлично справляется с неопределенностью. Он может создать бета-версию продукта буквально за один день, но она может быть непригодна для использования. Для такого человека я бы закладывал дополнительные итерации в оценку, увеличивая время. Вероятно, процесс потребует доработки. Но если нужно быстро продемонстрировать что-то, такой разработчик — находка.

3. Разработчик «Муравей».
Когда он берется за дело, все идет как по маслу. Он отлично объясняет аналитикам и архитекторам, как должно работать решение. Хорошо подкован в предметной области и вопросах разработки. Однако, когда именно задача будет выполнена — загадка. Это перфекционист, который часто стремится делать работу намного лучше, чем нужно. Поэтому его работу стоит контролировать, чтобы он не зарывался в детали и не затягивал процесс. Качество важно, но не должно превалировать над сроками.

4. Разработчик Superman.
Это эталон в команде. Он работает быстро и качественно, всегда выполняет задачи на высоком уровне, но найти таких специалистов сложно. Когда они есть, их все знают в лицо. Такие разработчики становятся стандартом для оценки качества работы в команде.

Теперь давайте рассмотрим методы оценки задач, разделим их на групповые и личные.

Эффективная оценка задач в разработке — это больше, чем просто предсказание сроков. Это искусство, где важны нюансы, подход, и даже опыт каждого члена команды.

В этом разделе рассмотрим два подхода к оценке: групповые методы, где важен вклад коллектива, и личные методы, когда ответственность за точность оценки ложится на одного человека.

Групповые методы оценки задач

Как же подойти к выбору способа? Всё зависит от сложности задачи, уровня неопределенности и доступного времени.

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

Личные методы оценки задач

1. Историческая аналогия.

Когда сталкиваемся с новой задачей, полезно заглянуть в архивы предыдущих проектов, чтобы найти аналоги. Если в прошлом вы уже занимались чем-то похожим, можно обратиться к системе управления проектами, скажем, к 1С:СППР, и извлечь отчёт о трудозатратах.

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

2. Декомпозиция задач.

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

Допустим, возникла задача перевести конфигурацию на новую редакцию. В нашем случае это был перевод 19 подсистем и 134 объектов. Выглядит пугающе, особенно если сроки поджимают. Решением стало собрать команду, подключить 1С:СППР и три дня в переговорной посвятить анализу каждого подсистемного модуля. В итоге мы пришли к выводу, что на всю работу потребуется около 2852 часов — довольно точный ориентир, если говорить о масштабах задачи.

3. Числовая оценка задач

Если хотите использовать числовую оценку для различных сценариев, можно применить формулы для вычисления. Например, вы можете учитывать оптимистичные и пессимистичные оценки, используя такую формулу, как трехточечное оценивание.

Эта формула помогает сбалансировать различные точки зрения и получить более реалистичную оценку времени и усилий, необходимых для выполнения задачи.

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

Попробую её расписать.

1. Обновление из хранилища — первое, что я делаю. Подключаюсь к хранилищу, чтобы всё было актуально, занимает около 15 минут.

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

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

4. Добавление загрузки данных из Excel — для этого этапа уже нужно разрабатывать отдельную обработку, которая загрузит данные и синхронизирует их с полями нашей таблицы. Здесь приходится повозиться, так как часто возникает несоответствие данных, требуется доработка. На этот этап я обычно закладываю около 16 часов, так как возможны правки по ходу работы.

5. Добавление нового ввода на основании. Следующая доработка — это настройка нового ввода на основании, для чего потребуется внести правки в модуль менеджера, добавить кнопку и несколько общих модулей. Обычно это отнимает порядка 8 часов, так как зависит от сложности алгоритма.

6. Тестирование — теперь проверяю, как работает доработка в целом. На тестирование закладываю 4 часа.

7. Код ревью и описание в 1С:СППР — описываю изменения в системе проектного управления, прохожу ревью, ещё 2 часа.

8. Перемещение в чистовое хранилище — завершаю всё переносом доработки в чистовое хранилище, занимает около 2-х часов.

9. Собираю все эти этапы вместе, получается 34 часа на доработку.

Теперь посчитаем, сколько времени уходит на разработку, а сколько на другие этапы:

Разберем конкретные ситуации, где я ошибся в оценке задач, — это будет ваш шанс найти мои промахи и выделить нюансы, которые я упустил. Но не ограничивайтесь лишь фразами вроде «не провел анализ». Мы уже говорили о сложностях разработки, и здесь важно связать их с конкретными ошибками.

Ситуация первая: отчет.

Команда работала над проектом, где требовалось создать сводный отчет с информацией по договору. Этот отчет использовал сложную структуру на базе системы компоновки данных (СКД). Она состояла из пакета примерно из 15 запросов, связанных между собой. Задача была в том, чтобы модифицировать отчет по просьбе аналитика: выделить данные из 10-го запроса и изменить его так, чтобы отчет формировался не по одному договору, а по списку договоров.

Во время выполнения задачи выяснилось, что данные для отчета поступали из других информационных баз. Это добавило сложности, потребовалось выяснить, какие именно базы используются и как изменить запросы для вывода данных по списку договоров. Задача, которая казалась простой, потребовала значительно больше времени и усилий из-за того, что были не учтены зависимости от внешних источников данных.

Основная ошибка: недостаточный анализ требований перед началом работы. Разработчик не учел, что отчет забирает данные из нескольких баз, что существенно повлияло на сложность задачи.

Вывод: перед началом разработки сложных отчетов или модификаций важно уточнять структуру данных и зависимости, особенно если отчет использует внешние источники.

Ситуация вторая: локализация сервиса.

На другом проекте клиент попросил доработать сервис для других конфигураций, и мы, сделав это, передали результат на проверку. Но оказалось, что заказчик ожидал работы сервиса в облачном формате (1С:Fresh), а также думал, что мы автоматически заполним справочники и классификаторы.

Вопрос: Какие сюрпризы и недочеты вы видите в этой ситуации? Как бы вы действовали, чтобы избежать таких ошибок?

Ошибка: Недостаточное уточнение требований перед началом проекта. Не было уточнено, что система будет работать в облаке, и какие дополнительные задачи ожидает клиент. Ошибка произошла из-за нехватки информации о конечном использовании системы.

Совет: прежде чем приступить к задаче, важно обсуждать с клиентом детали использования решения, задавать вопросы, чтобы не упустить важных требований, и точно знать, какие задачи клиент считает приоритетными.