Как угадать время решения задачи

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

Уже сделанные. Категория, для которой вы точно знаете время решения. Она же и самая простая. Сюда входят задачи, которые вы уже решали, уже решили (в голове или на бумаге) или привычная рутина, что и не задачи вовсе.
Например, DAO. Их и без того сто, надо ещё пять. Копипастишь, меняешь названия таблиц и колонок, зеваешь, завариваешь чай. Например, вбить по документации список ошибок от API. Ну, по две минуты на строчку, 30 ошибок, час. Если челюсть не вывихну и меня в травму не увезут. Например, вы неделю в паре детальнейшим образом рисовали схемы, на схемах чуть ли не исходник. Бери и транслируй в кол. Кароч, никакой магии. Если землекоп за час землекопает кубический метр, второй кубический метр сделает тоже за час.
Подвидом задачи, что решены за вас. Как ни забавно, но вовсю встречается косяк именно в этой части. Связано с отсутствием профессиональной эрудиции и неумением гуглить. Пример из моей великолепной карьеры тому пример. Конец 90-х, интернетов нет, мануалы читаю ещё фигово, ну и вообще птенец, хоть упоротый и наглый. Пишу десктопный GUI на C под Mac OS 7..8. Дооолго пишу. Налабал даже самопальный SDK (что-то типа Bootstrap для бедных). Только потом узнал, что в природе есть (был) нормальный обычный SDK от Apple, с которым я бы эту задачу раз в пять быстрее решил. Бывает. Обычно бывает у джуниоров, впрочем, потому их прогнозы надо тщательно гугл… проверять.

Понятные. Задачи, которые вы вот прям в такой постановке не решали, но достаточно представляете метод решения, чтобы не переносить задачу в следующую категорию. Очень хочется написать, что это «просто задачи». Что-то уже делали, что-то нет (но знанием / опытом готовы), что-то ясно, что-то примерно ясно.
Скажем, словили бекендера и «нам нужен парсер нашего языка». Чувак представляет, что такое парсеры, токены, AST (всё ж чему-то учился), пусть никогда не занимался таким. Но он также помнит, что в серии статей про парсеры для чайников около 40 страниц, помнит сайт, да и под рукой исходники парсеров других языков. Короче, ничего страшного, всё решаемо. Руками не трогал, но голова может и оценка работы не будет расходиться с реальностью на порядок.

Непонятные. Задачи с прогнозом «да хрен его знает». Тут несколько вариантов и опытный чувак при обнаружении хотя бы одной приметы икает и тут же накидывает запас.
Во-первых, задачи с участием других людей. Вы ни фига не можете сказать, когда вам соизволят ответить на письмо с вопросами в каком-нибудь департаменте. Не знаете, сделает ли Вася свой модуль к четвергу. Не уверены в том, правильно ли понял документацию по API смежник. И не забухает ли субподрядчик (ай, ладно, просто Петька-фрилансер). А у Игната конфликт с девушкой, Игнат каждый день сбавляет темп и пишет код всё хуже, а его задачи блокер для ваших. А вон в том отделе фронтендера заставили на ассемблере писать бекенд к ручке, которую вы дёргаете, умножайте срок на 10 и валидол закажите.
Во-вторых, research. Не то, когда надо прочитать страницу мануала, заботливо подсунутого лидом, а потом пересказать своими словами (что тоже, впрочем, не у всех получается). Но то, когда «а что под наши условия лучше, X на стеке A или Y на стеке B?» (чувака, в первую секунду крикнувшего ответ, запомните и к серьёзным задачам не подпускайте). Или вот «а как нынче делают распознавание лиц по затылку и насколько стабильны решения?». Вы не знаете объём и доступность информации. Не пробовали решения руками. Более того, нередко на старте таких задач сначала надо сузить область и клещами вытянуть из заказчика намёки на «а зачем», «а какую проблему так решаем», «а деньги есть?» (если есть, мы точно хотим упарываться, а не купить чудесный продукт XYZ Ware?), «а какой глубины ответ нужен» и т.п., что тоже тянет время.
В-третьих, проблемный софт. Вот есть продукт, которому десять лет, он обкатан, у него хорошая репутация. Вот есть продукт, который год на рынке и его написали пионер Петя с октябрёнком Олегом в гараже. Угадайте, с каким продуктом вы чаще будете на ровном месте ловить баги в зависимости от фазы Луны и оценок в дневниках авторов? Угадайте, в каком продукте у вас больше шанс неделю пилить костыль потому, что эти… ребята… забыли, видимо, о том, что у людей обычно правая и левая ноги, а не обе правых, а вы такую степень идиотии не смогли заранее предсказать и учесть в прогнозе?
В-четвёртых, задачи, в которые вы ваще ни в зуб ногой, но так получилось. Скажем, я понятия не имею, за сколько дней выучу китайский или сверстаю лендинг на React. Китайский выучу раньше, конечно, но.
В-пятых, задачи без постановки. Что-то вроде «сделай что-то». Ну… Даже не знаю… Сделать «что-то» у меня займёт «какое-то» время. Звучит, конечно, обычно не так, но в какой-то момент вы понимаете, что по сути это оно. И первой задачей будет выяснение того, что же именно сделать-то.
В-шестых, амбициозные задачи. О, чуваки, а давайте напишем компилятор C++, чтобы Windows собирался на Raspberry Pi за пять секунд! Когда мы это сделаем? Джуниор-питонист ответит «через месяц», миддл-джавист скажет «через год», сеньор-плюсист подумает «никогда» и уволится. То, на чём горит половина (с потолка) стартапов.

Чё делать-то? Главная цель — свести непонятные задачи к понятным, а понятные к уже сделанным. Со всеми задачами у вас не получится, но полезный выхлоп будет. Делается это примерно так…
Во-первых, каждую задачу дробите на подзадачи. Всех, блин, программистов этому учат на всех уровнях, но один фиг нередко откровение. Сделай бутерброд. Я не умею. Хлеб резать умеешь? Да. Колбасу резать умеешь? Да. Класть колбасу на хлеб? Нет. Вот как ладошку на ладошку. Ух ты. Ага. — вместо одной [не]понятной задачи у вас три уже сделанных.
Во-вторых, ясно локализуйте и фиксируйте всё, что превращает задачу в непонятную или сложную. После этого пытайтесь избавиться от. А давайте вместо сервера X использовать сервер Y. А давайте мы сначала получим документацию по API. А давайте хотя бы накидаем ТЗ хоть на одну страницу. А давайте research сделает Петров, он хотя бы английский язык в школе учил.
В-третьих, ясно озвучивайте (!) и объясняйте (!) то, что считаете проблемой. Самый идиотский способ попасть на карандаш: ответить «да хрен знает» и сидеть с улыбкой. Нет, ты не прикольный пацан, ты дилетант. Видишь проблему. Формулируешь. Озвучиваешь. Объясняешь. Обсуждаешь. Убеждаешь. Нет? Не удивляйся, когда окажется, что ты джуниор вместо миддла, а эту же задачу Вася спрогнозировал на пять дней, а сделал за три дня.
В-четвёртых, нюанс. Вы озвучиваете срок работы над задачей. Дата, когда эта задача будет сделана, по календарю будет сдвинута вперёд, т.к. в 8-часовой рабочий день средний программист в среднем работает 5 часов. Потому 8-часовая задача будет сделана не за вторник, но в среду. Ещё раз: календарный майлстоун и фактические трудозатраты не сходятся. Потому вы вполне можете воткнуться в тёрки с руководством, которое решило, что пора вас (раздолбая задолбавшего) подприжать к ногтю: чувак, ты сказал, что за 8 часов сделаешь, сейчас вечер вторника, где решение? Можете в лицо сказать, что вы ни фига не работаете эти 8 часов, бывает забавно.
Смотрим на задачи. Стало легче. Но всё равно доля непонятного слишком велика. А время указать НАДО. Такое тоже бывает. Потому вот немножко законных читов.

Во-первых, оценки есть оптимистичные, реалистичные и пессимистичные. Стандартной бочки разработчик оптимистичен. И вы тоже. Возможностей споткнуться и сломать виртуальный палец в разработке жополиард. Да чего там, у вас может зависнуть IDE именно на том файле, что редактируете. И вместо часа задачи вы будете час копаться с тем, как эту скотину заставить не виснуть (наконец, обнаружите подвальный тикет в их трекере, увидите, что билд с фиксом выпущен только сегодня, обновитесь (потеряв часть настроек), восстановите настройки). Короче, накидывайте запасик на форс-мажоры. Скажем, 10%..25%.
Во-вторых, за счёт запаса времени одних задач вы можете вырулить в срок на опаздывающих задачах. Потому ещё раз: делайте запас везде, где можно и где лид молча одобрит (если сам ещё не подкинет). Он обязательно пригодится, т.к. вы обязательно начнёте опаздывать. Чем больше у вас задач, тем лучше. В особо клёвых случаях за месяц стахановского труда можно надолбить себе подушечку на что-то непонятное категории «да хрен его знает». Уже легче.
В-третьих… поговорите с лидом / менеджером. Или не говорите, если вам уже понятно, в какую сторону этот человек читает план. Есть чуваки, склонные резать тайминги (потому делайте запас с учётом этого среза). Есть чуваки, склонные добавлять запас (потому не наглейте со своим запасом). В общем, люди разные, и если план работ вы не для себя делаете, но с внешним контролем, изучите того, кто контролирует. Подбивайте часы так, чтобы после прохода внешней тяпкой получились те числа, что вам нужны.
И всё равно будет бардак. Привыкайте.
Набирайтесь опыта. Решайте задачи, запоминая время. Смотрите на других и запоминайте их время (Вася срубил дерево за час, Петя срубил дерево за час, ага, рубка дерева занимает час). Посматривайте на то, как ведут себя на работе бойцы, попадающие в прогноз или постоянно пролетающие мимо прогноза. Прикидывайте, какие факторы на это влияют и нет ли у вас такого же. Каждую историю проектов / задач (на конфах, например) слушайте также через призму тайминга. Ага, бойцы Company X на задаче ABC встряли на год… Ага, бойцы Company Y через пару лет на задаче ABC тоже встряли на год. Хм… Оп, через год вам на совещании предлагают заняться задачей ABC и с потолка считают, что это два месяца.

Есть тонкость, которая до меня только недавно дошла. Кажется, прям вот до клеточки понял и принял только в прошлом году, да и то подбитый размышлением над книгой о планировании. Дарю: подумайте о том, а что на самом деле вы задаёте этим вот «сделаю задачу за 16 часов»? В текущей точке эволюции считаю, что это не время, которое потратите или собираетесь потратить. Это данные для функции, что проставит галочку в календаре, не позже которой вам нужно сделать задачу.
Как-то отстаивать эту оценку не буду. Достаточно того, что меня она удовлетворяет. Понаблюдайте за собою. Как часто вы решаете задачи в режиме студента перед сессией? О, 4 часа… Надо бахнуть чайку. Кек, на Youtube прикольный ролик. Осталось 3 часа. Глянули на финишную ленточку. Не, я точно часа за 2 могу сделать. Хабр сегодня отжигает, вот же тупезни в комментариях, лол. Во, 2 часа. Начинаю кодить. Остался 1 час. Сделано на 33.3%. Ойблин. Вперрррррьйооооод!!! Ррррряааааа! Я Конан! Я варвар! Я ужас, ползущий на лаптях ночи! Уф. Успел. Да, насяльника, видишь, обещал за 4 часа сделать? Обещал. Пацан сказал, пацан сделал. Ну а фигли, профессионал, не хвост конины.

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

Добавить комментарий