2 сентября 2010 г.



Оценка исследовательских задач


Все знают, что оценивать исследовательские задачи очень трудно. Как по времени («будет сделано к следующему понедельнику.... или через неделю... или...»), так и по фактическим трудозатратам («на эту задачу у меня уйдет... скажем, 24 часа и примерно 35 минут»).


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


Чтобы расставить все точки над i, приведу примеры задач из мира разработки ПО, которые я отношу к исследовательским:
  • разработка с обязательным использованием новых, еще не изученных, технологий («недавно прочитал о название_супер_новой_и_универсальной_технологии - нам в проекте обязательно нужно ее использовать!»)
  • разработка для малознакомой предметной области («что вы знаете о бизнесе китайских торговцев лапшой?»)
  • разработка функциональности на основании грубых набросков, без детальных спецификаций требований («вот здесь вот нужна вот такая кнопка, вот тут сделаем несколько картинок, а когда я нажму, нужно чтобы все получилось как мне нравится»)
  • проектирование пользовательского интерфейса с учетом, и это важно, юзабилити («мне кажется, здесь нужно использовать текстовое поле с выпадающим списком со стрелочкой вправо» - А мне кажется, что стрелочка должна быть вниз, а не вправо и вместо выпадающего списка должно показываться пять разноцветных всплывающих окошек!»)
  • устранение «фантомных» ошибок («хм... а в прошлый раз оно работало и было зеленым...»)
  • оптимизация производительности и использования памяти («программа работает очень медленно, сколько минут тебе нужно чтобы это исправить?»)
Глядя на этот список, можно сказать, что такие задачи на самом деле занимают очень значительный кусок рабочего времени программиста. Поэтому правильно их оценить крайне важно для успешного выполнения своей работы и плана по проекту. Да и начальник наверняка требует оценку, да побыстрее!

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

Первым делом нужно постараться максимально определить границы задачи. Твердо решить что относится к задаче, а что нет. Понятно, что когда мало знаешь, есть риск определить границы не совсем верно. Поэтому мне кажется, что исследование задачи нужно начинать именно с тех ее областей, которые помогут определиться с границами. В книге «Балдеющие от адреналина и зомбированные шаблонами» за авторством Тома ДеМарко, Тима Листера и других описан шаблон под названием «Трубка и акваланг» Ниже его суть в двух словах.

Когда плаваешь с трубкой возле поверхности воды, можно увидеть очень много всего вокруг: стайки рыб, очертания затонувших кораблей, подводные скалы и прочее. Однако все это видно сквозь толщу воды, практически как сквозь туман. Может оказаться, что очертания корабля - это на самом деле причудливая скала; а то что вы сначала посчитали скалой - секретная подводная лаборатория ЦРУ. Чтобы узнать это, нужен акваланг для более глубокого погружения и исследования выбранного объекта в деталях. Однако, полная картина конечно же при этом теряется.

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

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

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

Если же ни один из компонентов вам не знаком, можно попробовать следующее. Выбрать, на свой взгляд, наиболее простой из них и попробовать исследовать его и, возможно, решить эту часть задачи. После этого, выбрать наиболее сложный на свой взгляд и добавить к нему приблизительную оценку рисков - они станут более-менее ясны при работе с более простым компонентом, все же они из одной предметной области. Теперь мы можем найти среднюю оценку между самым простым и самым сложным. Умножив эту среднюю оценку на общее количество компонент получаем результирующую оценку. Не лишним будет добавить, что чем больше будет компонентов (читай, чем мельче они будут по отношению к общей задаче), тем точнее получится такая оценка.

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

На этом все, удачных оценок!


Полезные ссылки:




Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


2 комментария:

  1. Я вот что хотел сказать - точные оценки для таких задач давать сложно.

    Если нас просят дать оценки, то мы либо берем время на дополнительное исследование (для точной оценки нам нужно 3 дня), если заказчик не согласен, то мы можем дать оценку либо зафиксировав некоторые условия, то есть сформулировать assumptions (убрать неопределенность), либо дать приблизительную оценку, указав уровень точности оценки (к примеру, Low) и перечислив вопросы, которые требуется решить для повышения точности (план на те самые 3 дня дополнительного исследования).

    Однако всегда есть риск неправильной оценки. Так вот идея в том, что профит от сложной задачи должен превышать риск во много раз (10ки, 100ни). В этом случае можно тратить меньше времени на оценки (ведь даже если мы ошибемся, то все равно останемся в выйгрыше), потратив больше на эффективную работу.

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

    ОтветитьУдалить
  2. Да, в идеале нужно обязательно пытаться брать время на дополнительные исследования, чтобы некоторое время "поплавать с трубкой у поверхности воды". Слава богу, большинство заказчиков к этому относятся с пониманием. Может быть не сразу, но рано или поздно это так и будет.

    Что касается assumptions и попытка убрать неопределенность через фиксирование некоторых условий, лично мне не очень нравится такой подход. Кажется, что есть большой риск получить в конце не то что лучше всего соответствует интересам заказчика. Т.е. в этом случае получается что заказчик принимает часть рисков за возможное неудачное решение на себя (тем, что требует оценку немедленно и согласен что-либо зафиксировать). И не факт, что осознает это. В результате виноватой окажется компания-разработчик. Хотя, конечно, в каждом конкретном случае все зависит от сложившихся взаимоотношений между заказчиком и исполнителем.

    Приблизительная оценка, безусловно, выход. Только я стараюсь давать степень точности количественно (например, 50%). И еще тут обязательно надо удостовериться, что заказчик это действительно услышал и понял. Потому что можно сказать, что "приблизительная оценка на разработку такого-то модуля составляет 20 человеко-дней с точностью в 50%", это будет означать что в результате на реализацию модуля может уйти до 30 человеко-дней. Но в подавляющем большинстве случаев заказчики будут склонны услышать только цифру 20 и ожидать именно такие результирующие затраты.

    А идея насчет намного большей прибыльности рискованных задач мне нравится! В таких условиях заказчики сами могут начать помогать нам снижать степень неопределенности (рискованности) задач.

    ОтветитьУдалить