понедельник, 3 января 2011 г.

Разработка: оценка проделанной работы

Только сейчас допёрло, оказывается я подсознательно неверно оцениваю результаты своей работы как разработчика.

До этого момента я (подсознательно) думал что чем больше функционала я навернул, тем больше полезной работы (измеряемой в человеко-часах, или в тысячах рублей) я проделал.

А вот и нет.
Сейчас пишу один проектик, в котором по сути 2 формы ввода. На одну из форм я уже потратил около 10 часов. Функционала, казалось бы, не так уж много, соответственно, и работы должно быть мало, и пользы для юзера. Но ключевой момент в том, что этой форму юзер будет пользоваться 80% времени от всей работы с программным продуктом. Следовательно, если она будет криво написана – ему будет тяжело работать. Если она написана нормально, но нет удобных подсказок, сложность выполнения самых частых операций не будет минимизирована - ему будет тяжело работать. Соответственно, мой вклад был недостаточно большим.

Следовательно, количество работы должно оцениваться не только "в ширину" (т.е. количество фич в проекте), но одновременно и в "глубину" – проработанность одной конкретной фичи, её качество.

В связи с этим мысль:
как правило, работая над проектом, я держу перед глазами список тикетов (читай – фич), которые нужно выполнить. Возможно, вместо этого (или параллельно) стоит держать перед глазами аналогичный список use-кейсов? Так будет понятнее, какие моменты больше прорабатывать, а какие – меньше. Ещё заметил, что глядя на список подсознательно оцениваешь объём работ по количеству тикетов, а не по объёму каждого. Возможно, стоит попробовать систему списков, состоящую не просто из заголовков, а из кратких описаний тикета, где объём каждого описания визуально будет соответствовать объёму работы, которую нужно проделать. Можно организовать такое описание из множества заметок, например грубо вот так:

  1. Сделать форму AAA: значение поля XXX проверяется по внешней системе YYY, поля XXX1 - в системе YYY1, поля XXX2 - в системе YYY2, поля XXX2 и XXX1 должны быть совместимы, поля ZZZ1, ZZZ2, ZZZ3, ZZZ4 должны быть совместимы

  2. Сделать форму BBB: поле XXX должно провериться по значению AAA в базе.

  3. Вывод выборки DDD: фильтр по XXX, YYY, ZZZ. Настраиваемый фильтр по DDD, EEE. Ajax-подсказки по фильтру EEE по существующим значениям


– наглядно, что на задачу 1 нужно больше времени чем на остальные, а на 2 больше чем на 1.

Пока мысль не довёл до конца, но подумаю на досуге о целесообразности такой "системы управления проектами для визуалов/сенсориков".