«Почему Я?!»
Сложно начать писать и структурировать мысли, когда за много лет работы скопилось миллион идей и наработок, как сделать оценку проекта быстро и как можно точнее.
Начнем по порядку. За время работы в ИТ ко мне, как в принципе, и к любому ИТ специалисту, приходят с просьбами оценить ту или иную задачу, функциональность или проект. Первая реакция у всех одна и та же: «Почему я?!». На такой вопрос идут типизированные ответы: «Ты же хотел чего-то нового?!», «Ты классный специалист!», «Это твое развитие!» и т. д. и т.п. Можете сами продолжить смысловой ряд, почему жребий судьбы пал именно на вас.
Все это конечно хорошо, но что делать, если тема для вас новая и оценивать не приходилось часто, а тут задача поражающая воображение: «Оцени нам, как отвезти человека на Марс!».
Агент специального назначения
Давайте представим, что вы агент разведывательных служб, и ваша главная задача — это сбор первичной информации. Помните качели, которые в воображении каждого участника процесса разработки построены по-разному. Так вот, чтобы такого не было и с оценками, начинаем собирать и структурировать информацию по требованиям. Все требования должны быть понятны, однозначны и, важно, чтобы были задокументированы и согласованы с заказчиком.
Оххх, не надо бросать в меня камень, если вообще нет никаких требований!
Вы же спецагент! Действуйте!
Назначаем рандеву со всеми действующими лицами, задаем правильные вопросы и начинаем сами записывать и структурировать, что же в итоге нужно сделать.
Собираем велосипед
Голова идет кругом от количества различных языков, технологий и фреймворков… Не надо только изобретать чего-то с нуля. Обычно есть лучшие практики по реализации проектов, есть много статей и много специалистов, которые расскажут, что и как использовать и как это делать.
Ваша задача перед тем как писать оценки, решить, что же вы будете использовать при работе над проектом. Мой совет один, чем попсовее технология или язык, тем проще найти ответы на любые вопросы.
Ведро с гвоздями
Наконец-то добрались до самой оценки поставленной задачи!
Начинаем разбивать одну большую задачу на атомарные, пока точно не сможете сказать — сколько времени нужно на нее. По-своему опыту могу сказать, что задача должна быть оценена в часах и не должна быть больше 16 (два дня работы непосредственно на то, чтобы реализовать ее).
Не стоит забывать о работах для задачи. Следует оценить также участие в митингах, написание юнит тестов, тестирование и т. п.
Точные оценки дать сложно, поэтому можно дать вилку и написать три оценки для задач: оптимистичную, реалистичную и когда все пошло по бороде.
Часть оценок лучше попросить сделать тех, кто работал с выбранными технологиями.
«Насуем в проект соломы!»
К сожалению, всего знать невозможно. К тому же, чтобы проверить, как же работает технология, не всегда хватает времени. Поэтому необходимо записать все ваши допущения. А также, если вы не уверены в реализации, написать риски.
Чем точнее и подробнее написаны риски и допущения, тем больше шансов, что проект пойдет как надо, и в итоге вам скажут спасибо!
Обрезание и корректировка
Уфффф, все оценки сделаны, и наконец-то от вас могут отстать, НО не тут-то было.
Очень часто ваши оценки слишком большие для заказчика или слишком маленькие для руководителя проекта. Начинается этап обрезания всего лишнего и корректировка оценок.
Хорошей практикой будет попросить оценить ваши задачи еще группу специалистов. Часто такой группы нет, тогда готовим рассказ, почему оценки занимают именно столько времени и ни на час больше или меньше. Необходимо уметь обосновывать заложенные цифры.
К чему же пришли?
Однозначно, не всем может понравиться заниматься оцениванием трудозатрат по проекту. Этот процесс крайне абстрактный и сложный. Каждый раз он проходит по-новому и никогда не повторяется.
Я советую посмотреть на этот процесс с другой стороны, у вас появляется уникальный шанс -посмотреть новые технологии, понять, что сейчас востребовано на рынке, получить уникальный опыт общения.
Участие в такого рода проектах обычно поднимает ваш конкурентный уровень на рыке труда и дает толчок к развитию.
В своей статье я попытался заострить внимание на базовых вещах при оценивании трудозатрат и, надеюсь, она окажется полезна как молодым, так и опытным специалистам.
Комментарии (18)
AlexTest
09.12.2018 20:36Сам такой тщательный анализ и структурирование требований — уже огромный кусок работы.
Из моего опыта, чтобы более менее достоверно оценить что-то, что займет Тх6 времени — надо потратить не меньше Т времени. Т.е. если чем-то надо будет заниматься к примеру 5 недель, то надо потратить как минимум неделю на эту оценку.
Таким образам сама толковая оценка — это как минимум шестая часть работы. Если бизнес не хочет оплачивать оценку исходя из этой пропорции — лучше с таким проектом не связываться.
lxsmkv
10.12.2018 11:19Всё это оценивание для меня всегда смахивает на определение времени прибытия по длине воздушной линии и средней скорости автомобиля
kinall
И вот тут начинается самое интересное. Исполнитель говорит: «На задачу надо потратить 10 часов». Руководитель проекта отвечает: «А я считаю, что 3». Приехали, патовая ситуация: если исполнитель соглашается, то почти наверняка срываются сроки, если не соглашается, то PM теряет лицо. Или начинается базарная торговля.
UncleBance
потому что исполнитель работает за з.п. и может быть премию, а РП работает за прибыльность проекта. Поэтому для исполнителя чем дольше идет проект, тем лучше. А для РП — наоборот. Это не патовая ситуация, это стандартная ситуация.
kinall
Не только и не столько поэтому. Исполнитель оценивает «сверху», чтобы точно успеть, РП «снизу», чтобы увеличить прибыль. Причём исполнитель почти наверняка оценивает точнее, поскольку он в данной конкретной области компетенее, чем РП, зато у РП есть власть назначить сроки.
Как бы то ни было, момент это важный, а в статье никак не освещён.
UncleBance
Знаете, я проработал в проектировании инфраструктур много лет. И технически грамотный РП там – как самородок золота в реке. А уж РП, который четко помнит, что у инженера рабочий день 8 часов и два выходны — и вовсе существо из былин.
kinall
У меня опыт меньше, но говорит о том же) Вот с чего надо начинать статьи об управлении проектами…
VolCh
Это стандартная патовая ситуация :) Исполнителю, работающему за ЗП и может быть премию, всё равно сколько идёт проект, если он за сроки никак не отвечает: закончится один проект — начнётся другой, не будет сразу проекта — оплатят простой, уволят — выплатят компенсацию за пару месяцев и т. п. Но ему (предполагаем профессионала) обычно немного не всё равно, если он не попадает (с обеих сторон) в свою же оценку, даже если никаких «оргвыводов» из этого не следует. Но чаще следуют хотя бы в виде учащающихся вопросов «когда же будет готово?», если факт выходит за оценку.
UncleBance
а из описанного вами какая мотивация исполнителю попадать в сроки, делать хорошо и т.п., если «не будет проекта — уволят»? Перспектива отличная, но только чтобы не стараться. Ибо все равно есть проект или нет от тебя не зависит, но если не будет, то уволят именно тебя. Заклинание «ты же профессионал» звучит также пошло, как и «ты же у нас программист». Получается, что ответить на «когда же будет готово?» «как только так сразу» мешает лишь страх потери рабочего места? А он отлично блокируется новым офером. Вот это да — та самая патовая ситуация. На мой взгляд.
emacsway
VolCh говорит правильно, есть такая проблема (с оценкой в частности, и с мотивацией вообще) в аутсорсе. В продуктовых компаниях с этим существенно легче.
А вообще, существует разница между оценкой (estimate) и обязательством (commitment).
Есть ряд мероприятий для повышения точности оценки в Agile, например, в XP оценки делаются двухфазно, сперва Story оценивается коллективно, затем Task оценивается индивидуально. Кроме того, постоянно ведутся метрики и отслеживается динамика ресурсов, затрачиваемых на реализацию тикетов, предсказуемость эстимитов, ресурсы, отвлеченные на багфиксы и т.п., поскольку они свидетельствуют о качестве проектирования и состоянии кодовой базы. Но автор, по всей видимости, имел ввиду, оценку для проекта целиком, т.е. Waterfall.
UncleBance
вот честно скажу, что все эти агли, скрамы, спринты и стендапы были придуманы чтобы это кому-то продать. А у нас это еще через кальку «стендап = постоять». В итоге все встали кружком, друг на друга потупили минут 10-15 и разошлись. Можно было и не стоять. Я лично с кофе приходил на такое. Если уж сидя пить не дают, а как стендап еще переводится — не знают.
VolCh
Нет и не должно быть у исполнителя мотивации попадать в произвольно назначенные менеджментом сроки, должна быть мотивация давать стабильные оценки (необязательно временные), на основе которых менеджмент построит свои планы, заложив «наценку» на риски неточности оценки и всякие форс-мажоры. А обоснованная оценка задач обычно входит в непосредственные обязанности разработчика, как и, например, документирование. Поэтому с одной стороны, да, страх потери рабочего места по несоответствию, с другой — просто желание добросовестно делать свою работу тоже не позволяет отвечать «как только так сразу»
И разумный, уверенный в себе исполнитель не боится увольнения в связи с досрочным завершением проекта и отсутствием у менеджмента новых. По факту это может быть даже дополнительной мотивацией сделать проект быстрее, получить компенсацию за два месяца и начать работу на новом проекте, не дожидаясь истечения двух месяцев.
UncleBance
что значит компенсацию за два месяца? почему не за 10?
VolCh
Кажется в кодексах это дефолтная компенсация при увольнении по сокращению штатов и т. п.
UncleBance
это не так
VolCh
Да, немного не так. Ст. 178 ТК РФ обязывает выплатить месячную компенсацию в виде выходного пособия и до двух месяцев выплачивать до трудоустройства.
UncleBance
при условии официального сокращения. А так как эти данные идут в статистику по безработице, идет ловкая подмена «сокращения» на «соглашение сторон». И тут начинается самое интересное.
VolCh
По соглашению сторон можно и больше компенсацию за фактическое сокращение выбить. Никаких ограничений ТК или иные законы на размер выходного пособия в этом случае не накладывают, насколько я знаю, как договоришься.
Тут закон на стороне работника: или оплачивать ему вынужденный простой из-за отсутствия проектов неопределённое время, или договариваться, или проводить официальное сокращение и оплачивать от месяца до двух, а иногда до трёх.