От джуна до сеньора: Как стать востребованным разработчиком

Оценка задач

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

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

Требования. Первое, что вам нужно сделать при оценке любой задачи, – досконально разобраться в требованиях к ней. Любая мелкая деталь может кардинально изменить сроки выполнения. Задайте максимум вопросов по задаче, проведите анализ кода, который будет изменен, поговорите со старшими разработчиками.

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

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

Тестирование. Всегда закладывайте дополнительное время на написание тестов для реализуемой задачи и ее проверки. Компании часто не считают тестирование важным пунктом задачи (ровно до момента, пока все не упадет). Я не могу изменить политику вашей компании, но могу сказать вам: отстаивайте свое право проверять код, который написали. Время, выделенное на тесты для вашей задачи, – это огромный плюс для вас, продукта и компании.

Взаимодействие. Не самый очевидный, но от этого не менее важный пункт. Любая компания и любой проект обладают внутренним распорядком, будь то совместные обеды, ежедневные митинги или трехчасовые лекции директора о том, почему ваша компания лучшая на рынке. Проще говоря, любой коллектив требует, чтобы часть вашего рабочего времени уходила на действия, никак не связанные с написанием кода. Если при анализе задачи вы понимаете, что как минимум два часа будет «съедено» митингом, час уйдет на шуточки продакт-менеджера, которые вам придется слушать, потому что уйти будет неловко, и еще час – на растаскивание в разные стороны коллег, сцепившихся, чтобы выяснить раз и навсегда, можно ли писать на Lisp в продакшн, то учитывайте и это время. Разумеется, вы не сможете указать его как официальное, так как никакой менеджер не признается в том, что потратил час на шутки, отвлекая коллег, а разработчики сделают вид, что холивары о Lisp – это ваши фантазии.

Коэффициенты. Финальное действие – это применение коэффициентов. Строго говоря, коэффициенты могут понадобиться вам лишь в ряде случаев, но для начинающего разработчика они весьма желательны, так как дают запас времени, даже если изначальная оценка была проведена некорректно (пока вы только набираетесь опыта, так и будет, можете мне поверить). После того как вы оценили задачу, руководствуясь предыдущими пунктами, необходимо выбрать коэффициент и умножить на него полученную оценку. Это дополнительное время – ваша страховка на случай непредвиденных обстоятельств. Выбор коэффициента будет зависеть от того, насколько такая практика принята в вашей компании, готов ли заказчик платить за скрытые риски, а также от того, как вы оцениваете свой опыт в задаче. Если попытаться свести величины к числам, коэффициент будет варьироваться от 1 (вы считаете оценку точной и не предвидите никаких рисков, начальное время оценки после умножения на 1 остается тем же) до 1,5 (вы предполагаете, что задача таит в себе большое количество скрытых рисков и дополнительной работы). Допустим, вы оценили задачу на 10 часов, но догадываетесь, что даже с тестированием и заложенными рисками можете потратить дополнительное время на обсуждение и доработку от дизайнеров, и выбираете коэффициент 1,2. Таким образом, ваша конечная оценка будет 12 часов (10 × 1,2), где дополнительные 2 часа – ваша страховка.

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

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

Тезисы

■ Перед оценкой выясните все требования к задаче.

■ Дробите большие задачи на более мелкие.

■ Учитывайте потенциальные риски; запоминайте, когда вы ошибались в оценке.

■ Добавляйте время на тестирование.

■ ОБЯЗАТЕЛЬНО добавляйте время на тестирование!

■ Учитывайте время на «потрындеть», оно такое же реальное.

■ Добавляйте коэффициенты оценки, не пренебрегайте своей безопасностью.

■ Низкие оценки никого не впечатлят, а вам придется ночевать на работе.

Задание

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

История из жизни

Всех историй о том, как я недооценил задачу, не перечислить и в трех книгах, но одна запомнилась особенно хорошо – правда, по иным причинам. Я уже не вспомню, что конкретно надо было сделать, но задача выглядела солидно, предполагала время на анализ, на дополнительные тесты. Суммарно выходило порядка 20 часов. Задача была оценена, я отложил ее на поздний срок и вернулся к ней через несколько недель. Работа моя продлилась 2 часа, после чего еще полчаса ушло на то, чтобы понять, как я ухитрился нафантазировать себе оценку в 20 часов.