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



Оценка задач: как делать хорошие оценки

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

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

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

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

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

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

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

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

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

Кроме того, мне понравилась мысль (ш!)кодера: «Если же задача рискованна, то она должна быть намного прибыльней - иначе зачем над ней работать, если есть такие же (по прибыльности, прим. автора), но с гораздо меньшими рисками».

Идем дальше и натыкаемся на непрекращающуюся изменчивость требований заказчика. Тут в первую очередь приходят в голову гибкие (agile) методологии разработки, которые просто стали ответом времени на эту проблему. О гибких методологиях написано довольно много, поэтому я не буду на них останавливаться. Это - один из главных трендов в мире разработки ПО не сегодняшний день, поэтому вряд ли я смогу добавить что-либо новое.

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

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

Применительно к оценке скажу, что просто нужно всегда помнить, что люди ошибаются и имеют на это право. Поэтому, не будет лишним добавлять к изначальной оценке поправку на эти возможные ошибки. Ее размер будет сильно колебаться и лишь со временем каждый придет к своему собственному. Чем опытнее разработчик, тем эта поправка, как правило, меньше. На данный момент для себя я принял ее в размере 5-10% в зависимости от сложности и размера задачи.

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

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

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

На сим все, спасибо за уделенное время и внимание. И, конечно же, удачных оценок!

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




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




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


Комментов: 0

Отправить комментарий