Работа с оценкой и сроками — это стресс и ответственность, и некоторые разработчики даже придумывают идеологические отмазы против оценки. Но хотят они того или нет, в IT-мире всё вертится не вокруг качества кода, а вокруг сроков и оценок. Разрабатывая быстрее, компания получает конкурентное преимущество перед себе подобными, а адекватная оценка позволяет точно рассчитывать расходы. Заказчика в первую очередь интересуют сроки и конкретная стоимость работы, и оба этих параметра завязаны на оценке разработчика, изучавшего проект на пресейле. Конечно, менеджер заложит дополнительные риски, но это не поможет, если разработчик обсчитался в 3 раза.
Посмотрим правде в глаза — от оценки никуда не деться, и если вы не оцениваете задачи на проекте, то, скорее всего, за вас это делает кто-то другой. Между тем, разработчик, дающий адекватные оценки и в них попадающий — это бриллиант для работодателя. Такие специалисты ценны, и они растут гораздо быстрее, чем товарищи, у которых с оценками беда.
Наша команда набила немало шишек на некачественных оценках. Из-за них мы не попадали в бюджет, портили отношения с заказчиками или, как минимум, выглядели глупо. Методом проб и ошибок мы вывели свод правил, которые помогли повысить точность наших оценок. Надеемся, вам они тоже пригодятся.
Создайте условия
Начнём с того, что систематические плохие оценки и существенные просрочки могут быть не только вашей виной. Прежде всего, для хорошей оценки должен быть соблюдён ряд условий.
На оценку выделяется достаточно времени
Это ответственное и кропотливое дело, и если на оценку крупной фичи дают всего 15 минут — немудрено, что что-то важное может ускользнуть от внимания оценщика. Если у вас происходит именно так, ваш долг перед командой и её продуктивностью — донести до менеджмента, насколько высоки ставки, и что «лишний» час оценки сможет предотвратить 100 часов просрочки.
Оценка крепко вплетена в ваш воркфлоу
Вы не сможете прокачать в себе навык оценки до приличного уровня, когда вокруг бардак: задачи оцениваются от случая к случаю, вас внезапно посреди работы над задачей заставляют её оценивать, и в целом неясно, когда задачу нужно оценивать, а когда нет. Первый шаг навстречу эффективной работе с оценкой — взрастить в своей команде культуру оценки. Высокий уровень командной дисциплины — один из гарантов эффективности. Если у вас есть точный регламент, гласящий, на каком этапе задачу нужно оценивать, а в конце проекта разработчик может сделать вывод о качестве своей оценки, то разброд и шатания в итоге будут минимальными, а плотность работы с оценкой — высокой. И тогда повышение качества станет делом времени.
Задачи ставятся качественно
Каким бы огромным опытом вы ни обладали, вы не сможете заложить оценку на те части функционала, о существовании которых даже не догадываетесь. Чтобы учесть все-все детали задачи — и скрытые на начальном этапе, и те, которые появятся впоследствии — нужно обладать третьим глазом, и в реальном мире, увы, такого не бывает. Но можно минимизировать эти риски при помощи хорошего, или хотя бы сносного ТЗ.
В тех случаях, когда ТЗ не оставляет никаких надежд на точную оценку, не бойтесь задавать вопросы, даже если это займёт время.
В идеале оценка должна состоять из двух фаз:
- Вы внимательно читаете ТЗ, задаёте по нему вопросы аналитику или представителю заказчика.
- Получаете ответы и оцениваете задачу.
Но на правду больше похожа другая история:
- Вы внимательно читаете ТЗ и задаёте возникшие вопросы носителю идеи.
- Вы получаете ответы, на основе которых возникает ещё больше вопросов.
- И снова.
- И снова.
Процесс может затягиваться, но эти временные затраты обязательно окупятся. К слову, на этом этапе мы часто подключаем тестеров вместо разработчиков. Баги в постановке задачи — это дорогие баги, и чем больше людей будет участвовать в их отлове, тем стройнее и качественнее будет результат.
Работайте над собой
Теперь перейдём к правилам оценки и поговорим о том, что можете сделать лично вы для улучшения перформанса команды.
Декомпозируйте задачу и делайте это на совесть
Ешьте слона частями. Хорошая декомпозиция даёт мощный буст к укладываемости в оценку. Это стоит делать, даже если вы не планируете распараллеливать задачи между разными разработчиками. Во-первых, декомпозируя, вы смотрите на задачу чуть ближе, вертите так и сяк, планируете, как будете её выполнять, а значит — видите новые хитрости и заковыристости, на которые стоит заложить дополнительное время. Во-вторых, это дополнительная возможность самоконтроля: если вы пилите монолитную задачу на 120 часов, проще не уследить за временем и потратить 30 часов там, где стоило бы потратить 12. С декомпозицией такое не пройдёт.
Сравнивайте свои оценки и фактически затраченное время
Чтобы прокачать навык оценки, необходимо получать обратную связь о том, насколько близки к реальности оказались ваши предыдущие эстимейты. Можно сделать себе фильтр в джире, или ведите список хоть в гугл-таблице.
Учитывайте риски
Отдельно оговаривайте всё, что может существенно повлиять на оценку. К таким факторам относятся:
- незаконченная постановка задачи (неготовые макеты, незаконченное ТЗ, непонятки с API и всё-всё-всё, что «предоставят позже»);
- технология, с которой вы раньше не работали;
- «белые пятна» в описании и отсутствие ответов на ваши вопросы.
Сообщайте об этом при оценке задачи, кричите погромче о том, что изменение постановки задачи повлечёт за собой рост трудозатрат.
Будьте реалистами
Ваш менеджер или тимлид, задавая вопрос «Сколько времени это займёт?», интересуется вовсе не тем, сколько вам понадобится времени конкретно на написание кода. Тем не менее, на этом первое время сыпятся все (ну или почти все). Здесь эта цифра бесполезна, она не соотносится с реальностью. Так что возьмите время, которое вы потратите на написание кода, прибавьте к нему время на покурить, выпить кофе, не выспаться и протупить полдня в стену, спросить совета у соседа, подождать ответа от аналитика, правок макета от дизайнера, заблокироваться бэкендом, разблокироваться, десять раз упасть и одиннадцать подняться. Сколько именно закладывать на риски? Мой совет — начните с 20% для больших задач и 50% для маленьких. Затем смотрите на результат и при необходимости корректируйте эту цифру.
Не прогибайтесь
Не соглашайтесь занижать оценку, особенно если на 100% уверены, что это не сработает. Приучите своих коллег к тому, что это займёт столько времени, сколько займёт. Учитесь аргументировано защищать свои оценки, поскольку с вами всегда будут пытаться торговаться.
Не завышайте оценки (существенно)
Если с заниженными оценками всё более-менее понятно, то что не так с оценками завышенными? Разве задача, сделанная в два раза быстрее, чем ожидалось, не станет приятным сюрпризом? Возможно, где-то, для кого-то. С некоторыми оговорками:
Это снижает дисциплину. Закон Паркинсона — задача занимает столько времени, сколько на неё заложили: может больше, но почти никогда не меньше. И по нашему опыту, лишь единицы могут нормально сдаваться раньше срока. Остальным же надо во что бы то ни стало израсходовать всё время, которое дано. Поэтому, перезакладываясь «на всякий случай» без реальных рисков, можете заранее попрощаться с этим временем, т.к., с большой долей вероятности, оно просто уйдёт на течение мыслью по древу.
Это губительно для планирования и процессов в вашей команде. Во-первых, загрузка разработчика спланирована наперед на определенный срок. Если каким-то образом карточки двухнедельного спринта уйдут в 3-4 дня, остальная команда останется в недоумении, а разработчик-стахановец — без задач. И выглядит это не геройски, а даже немного глупо, к тому же заставляет серьёзно сомневаться в навыках такого разработчика. Во-вторых, процесс разработки ПО не ограничивается одним написанием кода. Есть аналитика, планирование, тестирование, код-ревью, в которых участвуют другие специалисты. И вот ваш бэклог уже пуст, а всем этим ребятам надо прям вот щас всё бросить и побежать, оставляя свои, возможно, срочные дела, чтобы грумить вам новые задачи и тестировать старые. Таким образом, эффективность планирования и взаимодействия команды плавно пикирует к нулю, плодя хаос и разрушение.
И, пожалуй, последний совет.
Расслабьтесь :)
Иногда вы будете факапить. Иногда и мы всё ещё факапим. Это не удивительно — столько всего может пойти не по плану! Но важно не опускать руки и анализировать свои успехи и неудачи, адаптировать чужие процессы и правила и изобретать свои собственные — такие, которые будут работать именно для вашей команды.
Надеемся, перечисленные советы помогут избежать частых «детских» ошибок на этом долгом и увлекательном пути.
