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

Меня зовут Константин Паламарчук, я руковожу образовательным направлением компании Programming Store. Я хочу рассказать об оценке задач – рассмотрю этот процесс с разных сторон, от теоретических аспектов и базовых принципов до конкретных ситуаций из моего личного опыта. Расскажу о том, что, на мой взгляд, важно и интересно.

В сфере 1С я работаю уже около 18 лет, прошел разные роли: от разработчика до тимлида, руководителя проектов и руководителя отдела разработки. Часть карьеры была связана с созданием тиражных программных продуктов, а часть – с внедрением ERP и других решений.

Начну с самого начала – с вопроса, зачем вообще нужна оценка задач.

Причины важности оценки задач

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

Обычно разработчик получает задачу с ограничениями: срок, бюджет и содержание. Мы передаем ему эти параметры и говорим: «Работай». При том, что программирование – это искусство. В нем всегда есть место для творчества, инсайтов и нестандартных решений. И все же нас жестко ограничивают – сроки, ресурсы, требования. Какой бы подход мы ни использовали, эти рамки остаются. Мы должны уложиться в срок и уложиться в бюджет. При этом задача редко существует сама по себе – она входит в подсистему автоматизации, которая, в свою очередь, входит в проект.

А проект – это всегда срок, бюджет и содержание. Откуда берутся эти ограничения? От бизнеса. Бизнес живет в мире, где есть клиенты, заказчики, кассовые разрывы, налоговые отчетности, дедлайны. Эти ограничения бизнес проецирует на проекты, проект – на подсистемы, а те – на каждую отдельную задачу. То есть вся цепочка – от бизнеса до мелкой задачи – пронизана этими ограничениями.

Вторая причина важности оценки – польза в текущей работе. Этот навык полезен на любом уровне. Даже junior-разработчик, умеющий оценивать задачи, может понять, адекватна ли поставленная перед ним задача. Если оценка кажется несопоставимой с трудозатратами, он может начать конструктивный диалог – с архитектором или клиентом. Не просто: «Я не успею», а: «Вот почему я считаю, что это займет больше времени». Такой диалог повышает шансы на пересмотр требований или сроков. И лучше начать его при получении задачи, чем в день дедлайна.

Кроме того, этот навык пригодится в будущем. Сейчас в 1С принято деление на junior, middle, senior, архитектора. У разных компаний – свои системы оценки, но в целом обязанности примерно одинаковы:

• Middle оценивает свои задачи (если дается такая возможность),

• Senior – свои и задачи middle,

• Архитектор – задачи всех, включая чужих разработчиков.

Чем раньше разработчик начнет тренировать этот навык, тем быстрее он сможет расти. Потому что middle, который не хочет становиться senior’ом, – это плохой middle.

Почему разработчики избегают оценки задач

Почему же не все любят оценивать задачи? У меня был случай: мне нужно было оценить задачу, и я посмотрел в хранилище, кто последний работал с этим отчетом. Нашел Мишу, написал: «Миша, есть вопрос, я тут оцениваю задачку». Он отвечает: «Окей, спрашивай, что хочешь, только не спрашивай, сколько это займет по времени».

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

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

Для небольших задач обычно все ясно. Но если задача масштабная, я рекомендую выделить время на предварительную аналитику: разработчик и аналитик вместе «копают» – не до дна, но хотя бы на пару слоев глубже.

Потом – проектирование. Оно помогает выявить вопросы, которые лучше задать заранее, чем решать по ходу реализации.

Следующее – техническая сложность. Я определяю ее, задавая себе вопросы:

• Какие объекты задействованы? Создать справочник – одно, создать регистр накопления – другое.

• Есть ли обмены? Даже небольшие – это почти всегда проблемы.

• Какие протоколы, технологии используются?

• Какая нагрузка: 100 документов в день или 100 000?

• Будут ли параллельные или фоновые процессы?

• На каких технологиях ведется разработка? Хорошо ли мы с ними знакомы?

Пример: была задача – сделать отчет, объединяющий данные из двух систем. В обеих системах уже был обмен, поэтому мы решили: «Раз обмен есть – используем его». Сделали отчет, реализовали обмен. А при сдаче выяснилось: пока мы работали, клиент тихо начал разрабатывать новый вид обмена и ожидал, что мы будем использовать именно его. О нем нам никто не сказал. Обмен «работал», но не тот. Если бы мы спросили – избежали бы ошибки.

Вывод: всегда уточняйте технические детали.

Распространенные ошибки при оценке

Одна из самых частых ошибок – оптимистическое смещение. Мы оптимисты. Без этого не выживешь в разработке: беремся за сложные задачи, верим, что все получится. Но это же качество мешает объективно оценивать.

Когда беремся за проект, думаем: «Все будет хорошо». А потом что-то идет не так. И это нормально. Но если не учитывать вероятность сбоев, оценка будет завышенной.

Вторая распространенная ошибка – давление сроков. Пример: к разработчику Ивану подходит менеджер: «Оцени задачу». Иван начинает читать ТЗ, а менеджер добавляет: «Мы же к среде успеем?» Теперь Иван не оценивает – он пытается уложиться. Среда висит над ним, и он неосознанно «сжимает» оценку.

Надо забыть про срок и дать честную оценку. А потом уже с ней обсуждать, успеем ли к среде. Если нет – нужно об этом говорить. Если срок критичный – можно сократить функционал. Но для этого нужна честная оценка. Без нее мы точно не успеем.

Третья ошибка – игнорирование рисков. Это тоже часть оптимизма: «Все получится, сбоев не будет». Но у каждого разработчика свои «грабли». Лучше заранее собрать возможные риски, потратить на это немного времени – и получить более полную картину. Это защитит от неприятных сюрпризов.

Классификация разработчиков по стилю работы

Еще один фактор – разница в навыках исполнителей. Вот моя авторская классификация (не претендует на истину в последней инстанции, просто так я вижу).

1. Начинающий разработчик

Энтузиазм, энергия, но много ошибок. Проблемы с кодом, с 1С, с учетными понятиями. Сроки с ним не обсуждаются – либо рядом работает senior, либо задачу берет кто-то другой.

2. Разработчик-молния

Как говорится, молния дважды в одно место не бьет. Отлично работает в условиях неопределенности. Может выкатить бета-версию уже завтра – ее можно показать, но использовать – нельзя. Такому разработчику стоит закладывать 1–2 итерации. Умножать на ? – в хорошем смысле. Зато если нужно быстро показать прототип – это идеальный человек.

3. Разработчик-муравей

Когда берется за задачу – все будет супер. Он расскажет аналитику и архитектору, как должно быть, напишет идеальный SQL, объяснит, как должны работать таблицы. Но когда – неизвестно. Это перфекционист, который делает сильно лучше, чем нужно. Его оценки нужно контролировать, иначе он «зароется» и затянет срок.

4. Разработчик-супермен

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

Методы оценки задач: групповые подходы

1. Экспертная оценка

Эксперты оценивают время выполнения задач на основе своего опыта и знаний. Например, я ловлю Ивана: «Слушай, ты же разбираешься – оцени задачу».

• Преимущества: Быстро и просто, особенно если у экспертов есть значительный опыт в аналогичных задачах.

• Недостатки: Субъективность и возможность ошибок из-за человеческого фактора. Нужно учитывать психотип эксперта: молния он или муравей.

2. Планирование покер

Участники команды обсуждают задачи и анонимно выбирают карты с оценками времени. Затем карты раскрываются и обсуждаются до достижения консенсуса.

• Преимущества: Уменьшает влияние авторитета, увеличивает точность за счет коллективного разума.

• Недостатки: Требует времени на сессии планирования, может быть сложно организовать для больших команд.

3. Метод делфи

Когда собрать экспертов вместе невозможно берем одного – обсуждаем задачу, риски, возможности. Записываем. Идем ко второму: «Вот какие риски мы видим – что ты думаешь?» Он добавляет свои. Идем к третьему. Итерационно собираем полную картину.

• Преимущества: Уменьшает влияние предвзятости, увеличивает точность оценок.

• Недостатки: Затратно по времени, требует нескольких раундов опросов.

4. Трехточечное оценивание

Для каждой задачи делаются три оценки – оптимистичная (О), пессимистичная (P) и наиболее вероятная (М). Итоговая оценка рассчитывается по формуле: (O + 4?M + P) / 6.

• Преимущества: Учитывает неопределенность и риски, дает более сбалансированную оценку.

• Недостатки: Требует больше времени и усилий для расчетов.

Методы оценки задач: личные подходы

А что делать, если экспертов нет?

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

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

• Преимущества: Объективность и точность при наличии детализированных исторических данных.

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

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

Разбиваем задачи на подзадачи и оцениваем каждую из них отдельно, затем суммируем оценки.

• Преимущества: Увеличивает точность оценок, так как мелкие задачи легче оценить.

• Недостатки: Требует времени на разбиение задач и может быть сложно управлять большим количеством подзадач.

Пример практической оценки задачи (декомпозиция)

Задача:

- Добавить колонку в табличную часть,

- Заполнить ее,

- Добавить кнопку «На основании»,

- Реализовать загрузку из Excel.

Я составляю таблицу: этап, действие, оценка времени.

Итого: 32 часа. Из них разработка – 26 часов (76%), все остальное – 8 часов (24%). Кажется, немного. Но если таких задач 10 – 80 часов просто на «остальное». Это уже две недели одного человека.

Вывод: мелочи накапливаются. Их нужно учитывать.

Анализ ошибок на реальных примерах (компромат-плезир)

Теперь «компромат-плезир». Расскажу о своих ошибках.

Ситуация 1: отчет по договорам

На проекте был отчет – сводка по одному договору. Анализировал СКД, 15 пакетов, виртуальные таблицы. Аналитик звонит: «Выдели данные из 10-го запроса в отдельный отчет. И сделай не по одному договору, а по списку». Я думаю: «Поменять на В(…) – 3 минуты. Вытащить запросы – пара часов. Легко». Но начинаю и вижу: отчет берет данные из других информационных баз, где данные по одному договору. А мне нужно по списку. Надо понять, из каких баз брать, как передать список договоров, как интегрировать.

Ошибки:

- Недостаточная аналитика,

- Игнорирование технической сложности,

- Оптимистическое смещение: «Да это же просто!»

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

Нужно было перенести доработки сервиса на несколько конфигураций.

Сделали, протестировали, все работает. Начинаем сдачу – а оказывается:

- Должно работать во фреше (никто не сказал),

- Заказчик ожидал, что мы заполним справочники и документы (не в задаче),

- Сам релиз, который дали – не работал во фреше (быстро починили, но на момент сдачи – барьер).

Ошибки:

- Не уточнили контекст использования,

- Не выяснили полный объем ожиданий,

- Не проверили совместимость среды,

- Попали на пересекающиеся задачи.

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

Рекомендации по улучшению навыка оценки

1. Замеряйте свое время

Даже если срок не задан – попробуйте оценить задачу заранее. Запишите: «Я сделаю это за X часов». Потом сравните с реальным временем. Никому не показывайте – это ваш личный тренировочный процесс. Со временем вы станете точнее.

2. Работайте в паре

Если есть доверенный коллега – оценивайте его задачи, он – ваши. Обсудите риски. После выполнения – сравните результаты.

3. Шаблоны для начинающих

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

4. Главное – смелость

Не бойтесь давать честную оценку. Да, вы будете ошибаться. Но только так можно учиться и становиться лучше.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.