Методика оценки задач или Как «не угореть» по срокам

Меня зовут Михаил Степанов. Я руководитель группы разработчиков компании ФТО. Наша компания занимается доработкой, внедрением и поддержкой решений в крупных организациях.

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

Наверняка у каждого были в жизни ситуации, когда мы оценивали задачу в 10 часов, а потом выполняли ее за 20 или за 30 часов. Давайте попробуем разобраться, почему так происходит, и как этого избежать.

Когда мы оцениваем задачу, наша цель – попасть в некий диапазон оценки.

• Если мы выйдем за левую границу этого диапазона, мы не успеем сделать в оцененное время. А если это будет работа с внешним заказчиком, мы еще и сработаем себе в убыток.

• Если мы выйдем за правую границу этого диапазона, то внешний заказчик скажет, что это дорого и найдет тех, кто сделает дешевле. А внутренние заказчики скажут, что через две недели уже поздно, нам нужно завтра. И тоже скажут, что лучше тогда вообще не делать.

И в первом, и во втором случае специалисты останутся без работы, что плохо.

Когда мы даем оценку задаче, мы почему-то часто попадаем очень близко к левой границе или даже выходим за ее пределы.

Давайте попробуем разобраться, почему так происходит:

Причины неверных оценок трудоемкости

Первая из причин – психологическая. Страх отказа.

Это как на дискотеке, когда есть девушка, которая тебе нравится, но ты боишься к ней подойти. Боишься, что она не захочет с тобой танцевать.

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

Следующая причина – это переоценка собственных сил.

Представьте ситуацию: вы договорились встретиться с товарищем, выезжаете и попадаете в пробку. В Москве это обычное дело. Понимаете, что к намеченному сроку приехать не получится, и как порядочный человек звоните своему другу: «Извини, я задерживаюсь, в пробку попал. Через 5 минут подъеду». Вам действительно кажется, что мы через 5 минут подъедете, потому что район знакомый, ехать буквально 3 дома осталось. Но в итоге приезжаете через 15-20 минут, а то и через полчаса.

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

Мы смело говорим 10 часов, а делаем за 20, потому что просто не учитываем какие-то факторы – мы просто про них забываем.

Следующая причина уже не совсем психологическая – это некомпетентность или просто легкое безразличие.

Есть анекдот. Сын спрашивает отца: «А что такое некомпетентность и безразличие?», а отец отвечает: «Да не знаю я, мне, честно говоря, пофиг вообще».

Так и здесь. Нам иногда просто лень погружаться в задачу. Бог с ней, сделаем часов за 10, наверное. И, конечно же, делаем за 20 или за 30.

Как с этим всем бороться? Я предлагаю выбрать методику оценки задач и ее использовать.

Что нам это даст?

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

• По поводу переоценки собственных сил: если мы изначально оценили задачу гораздо меньше, а по методике получили большее значение, значит, мы погрузились в задачу и нашли какие-то нюансы, которые при первом взгляде нам не попались. Это тоже хорошо.

• И о некомпетентности тут уже не может быть и речи. Мы действуем по методике, значит, применяем профессиональный подход.

Общепринятые методики оценки задач

Хотел рассказать про общеизвестные методики оценки задач.

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

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

  • Во-первых, сначала этот коэффициент нужно подобрать – это делается методом проб и ошибок. И ошибка для нас может быть дорога.

  • А во-вторых, разработчик тоже не дурак и чтобы не промахнуться, оценит время побольше. И если мы его на два помножим, то опять промахнемся, только в большую сторону. Потом нужно будет сделать корректировку по времени.

• Следующая методика оценки — это оценка по трём сценариям, где мы выявляем наилучший и наихудший вариант. А потом берем что-то среднее между ними. Но тут проблема – как в наихудшем сценарии учесть все возможные нюансы. Это все тоже можно не предусмотреть.

• И покерный метод оценки. Он подходит для проектных команд. Это немного игровой метод, когда команда садится за стол, и каждому члену команды раздаётся одинаковый набор карточек с оценками задач в часах, в днях, в каких-то единицах времени. Как правило есть ведущий – руководитель проекта, который по очереди озвучивает этапы проекта. И каждый член команды кладет на стол карточку, соответствующую оценке трудоёмкости этого этапа. А потом – как в покере: двое участников, которые положили карточку с наименьшим и с наибольшим значением высказывают свои аргументы к оценке. Как только команда приходит к консенсусу, мы получаем оценку этого этапа. Как правило, это ещё ограничивается по времени – либо таймером, либо песочными часами, кому как нравится. Это хороший метод, дает действительно хороший результат. Но если у вас один разработчик без команды, такую оценку, к сожалению, не применить – играть не с кем.

Как измерить что-то большое? Разделяй и властвуй

Теперь по поводу того метода, которым пользуюсь при оценке задач я сам. Сначала хочу рассказать идею на простых аналогиях.

Допустим, у нас есть большой камень-астероид, который нужно померить. А из измерительных приборов есть только маленькие штангенциркули – не дали нам ничего больше.

Что нам делать? Конечно же, нужно разделить камень по принципу «Разделяй и властвуй».

Поэтому мы будем разделять, декомпозировать задачу. Если получившиеся куски задачи еще достаточно большие, мы будем делить дальше.

Пока не получим те кусочки, которые померить нашим инструментом уже достаточно легко.

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

В этом случае мы оцениваем задачу на глаз.

И при этом у нас появляется неизвестность.

Эту неизвестность я предлагаю оценить по шкале от 0 до 8.

• 0 – это когда нам практически все понятно, практически нет никакой неизвестности,

• 8 – это когда мы точно знаем, что задачу решить можем, но как – вообще не представляем.

Формула оценки

Переходим к формуле оценки. Мы вычисляем коэффициент неизвестности:

• оцениваем степень неизвестности;

• умножаем ее на 0,1;

• и прибавляем 0,2 – это те 20%, которые стандартно закладываются на какие-то непредвиденные обстоятельства. Если мы – серьезная компания, мы, как правило, даем гарантию на свою работу. Если потом обнаружится, что что-то работает не так, как мы обещали, или всплывут какие-то ошибки, мы это, естественно, исправим бесплатно. Это и закладывается в эти 20%.

Т.е. этот коэффициент неизвестности включает в себя какие-то непредвиденные обстоятельства плюс степень неизвестности.

Итоговая формула оценки задачи выглядит так: мы умножаем нашу первоначальную оценку на коэффициент неизвестности плюс 1.

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

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

Если представить в виде схемы, то:

• на вход у нас поступает задача;

• если её целесообразно разбивать, мы её разбиваем на подзадачи, декомпозируем;

• если нет, то оцениваем трудоёмкость, определяем степень неизвестности и высчитываем итоговую оценку – складываем и получаем результат.

Если это у нас проект, мы эти этапы можем распределить между участниками проекта:

• допустим, трудоёмкость у нас оценивает разработчик;

• определяет степень неизвестности и высчитывает итоговую оценку ведущий разработчик или тимлид;

• а дальше уже руководитель проекта утверждает эту оценку и согласовывает с заказчиком.

Стандартные этапы реализации задачи

Давайте теперь перечислим, какие этапы у нас вообще при реализации задачи возникают:

• сначала мы разговариваем с заказчиком, чтобы понять, что он от нас хочет – интервьюирование проводим;

• затем делаем анализ задачи – пишем техническое задание;

• передаем в разработку – этап программирования;

• дальше тестируем на наличие ошибок;

• после того как все устранили, обновляем продуктив, рабочую базу;

• если необходимо, проводим демонстрацию;

• и пишем инструкции.

Почему я сейчас перечислил все этапы выполнения задачи? Потому что очень часто мы забываем про такие этапы, как, допустим, демонстрация или написание инструкции. И просто их не закладываем в оценку.

Пожалуйста, не забывайте. Это тоже наше время, и его тоже нужно закладывать.

Декомпозируем и определяем степень изменения (влияет на коэффициент неизвестности)

Чтобы было совсем понятно, хочу разобрать на конкретном примере.

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

Как это вообще оценить? Применяем декомпозицию. Конфигурация у нас состоит из различных объектов – в нашем случае, есть измененные модули, документы, отчеты, обработки, регистры.

• С общими модулями понятно, как их сравнивать – это просто два текста. Их можно сравнить и оценить степень изменения.

• А с документом как? Декомпозируем. Документ состоит:

  • из модуля менеджера;

  • из модуля объекта;

  • и из формы, которая в свою очередь состоит из модуля и интерфейсной части;

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

Теперь по каждой составляющей оценить степень изменения просто. Я предлагаю ввести следующие степени изменения:

• низкая;

• средняя;

• высокая;

• очень высокая;

• и у нас могут быть новые реквизиты или табличные части.

Теперь для каждой степени изменения я предлагаю ввести оценку.

• На добавление нового реквизита закладываем 20 секунд – мы просто перенесли из одного места в другое, 20 секунд должно быть достаточно. Казалось бы, что такое 20 секунд? Можно пренебречь. Но если таких реквизитов у нас 243, у нас уже получается 1,4 часа. И это значение исключать не стоит.

• Если эта степень изменения низкая, то закладываем 0,3 часа. Это когда изменения не больше, чем в 5 местах, и они достаточно простые. Можно просто их взять и перенести. Допустим, в нашем случае 8 таких объектов – 2,4 часа закладываем.

• Средняя степень изменения 0,5 часа. Это когда уже больше, чем в 5 местах изменения достаточно объемные. Допустим, у нас 6 таких объектов – 3 часа у нас получается.

• Высокая степень изменения – это когда требуется не только перенести эти изменения, но еще потом их доработать под новый релиз. Здесь под каждый объект закладываем 1 час. 3 объекта – 3 часа.

• И очень высокая степень изменения – это когда у нас очень много таких изменений и в каких-то случаях нам даже не ясно, нужно будет адаптацию производить или нет. 2 часа под каждый объект закладываем. Если в нашем случае 2 объекта – 4 часа получаем.

Оценка задачи. Трудозатраты по этапам

Теперь пройдемся по этапам и разберем этап программирования.

• На анализ задачи закладываем 2 часа.

• Добавление новых объектов получилось 1,4 часа.

• Внесение модификации получилось у нас 12,4 часа.

• Еще у нас есть объекты, которые обращаются к нашим измененным модулям. Их, возможно, потребуется дорабатывать для стыковки. Допустим, у нас 5 таких объектов. По 1 часу на каждый объект – 5 часов заложили.

• На тестирование и выявление ошибок – 4 часа.

• На обновление рабочей конфигурации – 2 часа.

Итоговая оценка получилась 25,4 часа.

Идем по методике дальше – расставляем коэффициенты неизвестности.

• Анализ задачи – это как раз фактическое время, которое уже прошло. Мы знаем, что анализ занял 2 часа, и больше у нас не выйдет.

• На новые реквизиты здесь тоже что-то закладывать сверху не имеет смысла.

• И обновление рабочей конфигурации – допустим, мы с этим процессом уже неоднократно сталкивались, понимаем, что 2 часа 100% хватит. Здесь везде по нулям.

• На объекты низкой, средней и высокой степени изменения я предлагаю заложить стандартные 0,2 (степень неизвестности везде по нулям).

• А если уже это объекты с очень высокой степенью изменения, то я предлагаю заложить степень неизвестности побольше, потому что там мы не анализировали, где потребуется адаптация, а где нет. Мы в этом моменте сэкономили по времени, но закладываем степень неизвестности – коэффициент получается 0,3.

• И объекты для стыковки – мы их вообще не смотрели, экономим время, но закладываем степень неизвестности 3. В итоге коэффициент получается 0,5.

Умножаем оценку на коэффициент, складываем, получаем 33 часа. Эти 33 часа уже можно озвучивать заказчику.

Это реальный кейс из жизни нашей компании. Мы обновляли релиз в части НДС и в итоге получили по факту 31,5 часа. Практически попали в оценку.

Как уложиться в оценку и укрепить лояльность заказчика

Давайте теперь разберем ситуацию.

Допустим, мы такие молодцы и оценили в 33 часа, а сделали за 25. Что с этим делать? Можно просто радоваться, что мы такие молодцы, поделить дополнительную выручку и жить себе дальше счастливо.

Я по этому поводу хочу рассказать одну историю. Есть такой казахстанский предприниматель Маргулан Сейсембаев. Очень умный мужчина, он в свое время был акционером Alliance Bank, входит в список Forbes 50 богатейших людей Казахстана.

Он рассказывал такую историю: его семья всю жизнь жила в съемных жилищах. И вот он принял решение построить собственный дом.

Открыл сайт по продаже недвижимости в Казахстане и на первой странице увидел объявление, что продается вилла в Улутау – есть такой небольшой поселок в Казахстане.

Он говорит: «Это же тот поселок, где я родился. Какое совпадение!» Пролистал буклет, там участок земли 1,5 гектара. Все подходит. Дома нет, есть только остов – стены и крыша.

Набирает по объявлению, берут трубку, он говорит: «Я заинтересовался домом. За сколько продаете?»

Ему говорят: «За 9 миллионов».

Он говорит: «Почему так дорого?»

Ему объясняют: «В прошлом году у нас был покупатель за 9 миллионов, но тогда не продавали».

Он говорит: «Мне неинтересна такая цена».

Его спрашивают: «А за сколько вы готовы купить?»

Он говорит: «Мне интересно за 2 миллиона».

Ему говорят: «Это не серьезно, до свидания».

Он говорит: «Возьмите контакты, если что, потом наберете».

Проходит год, ему перезванивает женщина-брокер, которая занималась продажей этого дома: «Здравствуйте, мы с вами разговаривали по дому. Там два хозяина, два брата немца, один из них собирается уезжать в Германию, оформляет документы на ПМЖ. Они снизили цену до 7 миллионов. Интересна вам еще покупка?»

Он говорит: «Конечно, интересно, но за 2 миллиона». Опять положили трубку.

Проходит где-то чуть побольше – года полтора, опять звонит женщина: «С домом такая ситуация – тот брат, который оформлял документы, уже уехал в Германию. Второй брат тоже собирается уезжать в Германию. Снижают еще цену до 5 миллионов. Интересно вам?»

Он говорит: «Интересно, но за 2 миллиона».

Кладут трубку, проходит полгода, звонят и говорят, что второй брат тоже уехал в Германию, продают дом: «За 3 миллиона готовы отдать. Интересно?»

Он говорит: «Нет, за 2 миллиона».

Проходит еще месяц, звонит женщина и говорит: «Давайте за 2,7 миллиона».

Он говорит: «Нет, за 2 миллиона».

Проходит еще неделя, перезванивает: «Ладно, давайте за 2, мы согласны».

И он тут говорит: «Подождите, мне нужно взять паузу». Проходит неделя, на том конце уже начинают думать, что он сейчас позвонит и скажет, чтобы скинули цену до 1,5. А он набирает и говорит: «Здравствуйте, я по поводу дома. Я согласен его приобрести, но при одном условии, что я покупаю не за 2, а за 2,3».

Женщина говорит: «Как так? Почему за 2,3? Мы же дали согласие за 2. Вы что, тут игры играете что ли?»

Он говорит: «Какие игры? Давайте сегодня встретимся, подпишем документы, я деньги перечислю. Все в порядке».

Встретились, подписали договор, он перечислил деньги.

Женщина-брокер спрашивает: «Так почему же за 2,3 миллиона? Что у вас за идея такая?»

Он говорит: «Понимаете, если я воспользовался нуждой продавца, и он опустился до моих условий, сделка по этим условиям ему не в радость. А тут я сделал братьям подарок 15%. Это хорошая сумма, братья ее не ожидали, у них потом будет приятное ко мне отношение».

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

Это будет очень хороший плюс к вашей карме и к дальнейшим взаимоотношениям с заказчиком.

Из той же истории – женщина говорит: «Ну конечно, 15% подарок! Сначала прожали нас до 2 миллионов, а потом подарок сделали. Какой же этот подарок?» – «А почему вы считаете, что я вас прожал? У меня был бюджет 2 миллиона, и я на этот бюджет искал себе объект. Я никого прожимать не собирался».

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

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

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

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

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