Применение программистом таблицы рисков для оценки технического задания

Как я поступаю, когда от меня хотят услышать, за какое время я подписываюсь выполнить задание?

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

1.  Как оценить не в ущерб Себе (не занижая оценку ради получения задачи, и не расплачиваться затем личным временем, и всё таки стать Исполнителем, получив задачу)
2.  Как оценить не в ущерб Заказчику (чтобы не сорвать сроки, и получить ожидаемый Заказчиком результат)

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

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

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

Сама Таблица проста в понимании: Все риски фиксированы и делятся по степени их вероятности и последствий.

Хотя какие бы ни были неопределенность и риски у задания, только таблицей сыт не будешь. Для начала нужно сделать предварительную оценку ТЗ в часах. Для этого, я читаю, вникая в текст полученного технического задания. Затем, если оно большое, то удобно оцениваю его части, затем из них складываю общую оценку. Беру документ (поступившее к оценке ТЗ) и отдельно каждый пункт/шаг/этап/часть примерно оцениваю в часах (за сколько бы сделал этот этап в среднем темпе, отмечая прямо в тексте документа, обычно *.doc), внизу документа выписываю итог, складывая части в общую оценку выполнения.

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

Вообще, зачем если уже есть оценка, еще и риски смотреть?

А всё потому, что эта оценка «первоначальная»! А я ведь не могу все знать и никогда не обладал полной информацией о будущей ситуации, в которой окажусь когда буду разрабатывать это ТЗ. И вот когда я погружусь в выполнение задания, то могут возникнуть новые дополнительные подзадачи, которые мне «хочешь-не-хочешь» придётся «разрулить». И лично мне и моему личному времени будет плохо, если я не учёл их ранее в своей оценке… За недооценкой как всегда последуют ненужные разборки с моим Руководителем и Заказчиком из-за сроков и оплаты (Мне вот этот негатив для Кармы совсем не нужен).

Чтобы этого избежать я оцениваю неопределенность и риски выполнения ТЗ исходя: во-первых - из текущего уровня доверия в отношениях с Консультантом и Заказчиком, и во-вторых из маркеров в тексте ТЗ, типа как ниже примеры и им подобное:

Рис.1 Список маркеров технического задания

1.  Недостаточная конкретность и непоследовательность шагов выполнения
2.  Конкретные значения вместо параметров или использование интервалов вместо конкретных значений
3.  Требование гарантии невозможного результата после выполнения задания программистом
4.  Отсутствие определений к терминам, использованным в тексте, отсутствие приложений, макетов, таблиц, ссылок на источники
5.  Наличие субъективных требований, типа «приемлемый, достаточный и т.п.»
6.  Неполное ТЗ
7.  Наличие утверждения, что все, что не оговорено, выполняется на усмотрение программиста
8.  Устное ТЗ
9.  Отсутствие контрольного примера для тестирования программистом версий
10.  Клиент вообще в курсе, что консультант написал в ТЗ?
11.  Кто-то уезжает в ближайшие дни в отпуск или заболевает
12.  Есть конкурирующие задания
13.  Что-то ещё.…. (сами добавляем)

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

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

Рис.2 Таблица оценки риска технического задания

ВНИМАНИЕ: Для меня на практике  важна в этой таблице была только "цветовая дифференциация штанов". Т.е. определяя «стрёмность» задания я смотрел только цветовую зону. А весовая оценка из ячеек мне не пригодилась, но я её здесь укажу в ячейках, т.к. её по делу проектники рассчитывают, определяя оценку каждого риска.

Оценка риска = Увеличение трудозатрат Х Вероятность возникновения

Вероятности возникновения события:

1.  Почти невозможно (0 – 20 % или 0.1),
2.  Маловероятно (21 – 40 % или 0.3),
3.  Вполне себе возможно (41 – 60 % или 0.5),
4.  Скорее всего, произойдёт (61 – 80 % или 0.7),
5.  Обязательно произойдёт (81 – 100 % или 0.9).

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

Увеличение трудозатрат задания:

1.  Очень слабое (0 - 10 % или 0.05, косметические изменения задания),
2.  Слабое (11 - 20 % или 0.15, небольшие изменения в содержании задания), ??
3.  Среднее (21 - 30 % или 0.25, важные изменения задания),
4.  Высокое (31 - 40 % или 0.35, изменения на грани приемлемости для заказчика),
5.  Критическое (41 - 100 % или 0.45, задание не будет принято заказчиком),

Примечание: Каждый уровень примерно объективен и фиксирован, при желании можете скорректировать больше/меньше  под сложность/мягкость своего Заказчика.

Так в итоге насколько программисту увеличить «первоначальную» оценку задания?

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

1.  Зелёная зона - задание будет реализовано тобой в срок, на раз-два-три;
2.  Жёлтая зона  - задание потребует от тебя дополнительных уточнений и доосмысления в ходе выполнения, по всей вероятности будет нескольких итераций сдачи;
3.  Красная зона  – не хотелось бы брать задание с такими рисками, оно или не будет сделано или твои усилия не оплатят по справедливости.

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

Итоговая оценка  = «Первоначальная оценка, в часах» Х (100 % + % Увеличения трудозатрат)/100 %.

Для примера. Возьмём ТЗ //infostart.ru/public/149361/ положим, что его первоначальная оценка на выполнение программистом 10 часов, маркеров риска особых нет, зеленая зона. Тогда рассчитаем

Итоговая оценка №1 = 10 часов * (100 + 10 % по шкале увеличения трудозатрат)/100 = 11 часов.

А если предположим, что это техническое задание пришло без макетов и таблиц, тогда оно уже попадёт по маркеру в желтую зону и расчет будет

Итоговая оценка №2 = 10 часов * (100 + 40 % по шкале увеличения трудозатрат)/100 = 14 часов

Если получилось так, что ТЗ у вас оказалось в красной зоне, то обязательно (одновременно с предлагаемое плохой оценкой в часах) поясните заказчику как она получилась. Расскажите о своих опасениях и предложите их проработать.

Если текущая зона задания тебя не устраивает, то можно поработать с текущими проблемами задания, чтобы из проблемной зоны постараться перевести в зону ниже (из красной в жёлтую, из жёлтой в зелёную).

Для этого составляется список своих опасений, вопросов и уточнений и прорабатывается с хозяином тех. задания. Как правило, на начальном этапе реально можно снизить вероятностью возникновения проблем,  проработав их с хозяином ТЗ (Заказчиком, Консультантом или Руководителем проекта). Таким поведением также обязательно зарабатываешь дополнительные  очки у хозяина ТЗ в свою пользу (для выбора тебя в качестве исполнителя задания и адекватного спеца, а не олуха без вопросов, который потом срок сорвёт).

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

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

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

P.S. На своём опыте знаю «как сложна и неказиста жизнь простого программиста».

Поэтому всем Коллегам программистам желаю успехов с 1С и терпения к постановщикам задач, а им к нам!