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

Публикация № 1242418 28.05.20

Управление - Анализ и проектирование ИТ-систем

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

Критическое, 41-100% или 0.45

0.045

0.135

0.225

0.315

0.405

Высокое, 31-40% или 0.35

0.035

0.105

0.175

0.245

0.315

Среднее, 21-30% или 0.25

0.025

0.075

0.125

0.175

0.225

Слабое, 11-20% или 0.15

0.015

0.045

0.075

0.105

0.135

Очень слабое,0-10% или 0.05

0.005

0.015

0.025

0.035

0.045

 

Почти невозможно,  0-20% или 0.1

Маловероятно, 21-40% или 0.3

Вполне себе возможно, 41-60% или 0.5

Скорее всего, произойдёт, 61-80% или 0.7

Обязательно произойдёт, 81-100% или 0.9

Вероятность возникновения

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

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

 

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

  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С и терпения к постановщикам задач, а им к нам!

 
 Другие публикации автора

Ссылка на компетенции по 1С:ERP - команда со знаниями, умениями и успешными проектами.

Специальные предложения

Вознаграждение за ответ
Показать полностью
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. VAAngelov 332 28.05.20 01:03 Сейчас в теме
Молодца. Неплохо. Есть, что почерпнуть и взять на вооружение. Попробую. Спасибо
2. dock 44 28.05.20 01:21 Сейчас в теме
Старая байка:
"Начинающий программист оценивает время и умножает на 2.
Продвинутый - умножает на 3,14.
Задолбавшийся - после умножения на 3,14 ... умножает ещё на и на 2."

Автор обосновывает выбор "множителя"! Однозначно - плюс.

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

Как же хорошо, когда такое задание хотя бы чуть-чуть отличается от "хотим кнопку: Сделать всё хорошо!"
It-developer; SiAl; ybatiaev; wowik; cleaner_it; Daniayr; Belomor; bulpi; user605780_L.Alexander8; suepifanov; user_2010; Светлый ум; +12 Ответить
3. ffidelite 9 28.05.20 07:00 Сейчас в теме
(2) Лет 10 назад читал метод подобного анализа,
там тоже в конце после всех расчетов ставили коэфф 2 и называли - Коэффициент факапности)
С тех пор принял на вооружение)
It-developer; milov.aleksey; +2 Ответить
8. shard 271 28.05.20 10:27 Сейчас в теме
27. Senator_I 13 28.05.20 14:07 Сейчас в теме
(2) плюс две недели )))
ybatiaev; +1 Ответить
4. user_2010 780 28.05.20 08:47 Сейчас в теме
В 1С же много задач типа "работает не так, как надо" - "надо сделать как надо". Как это оценить? - надо перелопатить код... Т.е. на этапе оценки надо фактически решить задачу?

Была задача на реальном проекте: изменить расчет НДФЛ в документе "Разовые начисления" - не применять вычеты. Оказалась нерешаемая задача. За нее брались несколько раз, несколько человек... Как это можно было оценить на этапе ТЗ?
It-developer; ong1990; wowik; VitalyKepov; improg; Flextor74; 116hrus; +7 Ответить
5. sapervodichka 6178 28.05.20 09:40 Сейчас в теме
(4) похоже на "требование гарантии невозможного результата", уловить момент трудно, надо либо отказывать либо пробовать делать как ты пишешь, но без гарантий с твоей стороны... тут сложный у тебя пример
6. user_2010 780 28.05.20 10:17 Сейчас в теме
(5) :) по большей части именно такие задачи и приходится решать.... не типовые, не типичные... вообще не знаешь во что можешь вляпаться...
С ходу-то показалось - да что там - уберем код, где вычет применяется... а нет не выходит "каменный цветок"....
10. Max777 1 28.05.20 11:25 Сейчас в теме
(4) Поддерживаю 100%
(5 тут сложный у тебя пример) - в моей практике других не было никогда, от слова совсем.

Есть еще такой момент. За 20% времени делается 80% работы, оставшиеся 20% работы делаются за оставшиеся 80% времени. Но без этих 20% работы никак нельзя.

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

На самом деле это краеугольный камень всех методик. Полное отсутствие системы осмечивания работ не только до, но и после их выполнения.
Знаю что 1С у нас неприкасаемая и сейчас в меня тапки полетят от 1СБотов, но раз проблему подняли скажу свое мнение. Такую систему можно было создать уже давно, но 1С это не делает по принципиальным соображениям. Когда все неопределенно, гораздо легче заниматься относительно честным отъемом денег у предприятий.

Автору респект. Хорошо что хоть кто-то об этой проблеме думает.
wowik; user_2010; sapervodichka; +3 Ответить
43. roman72 323 29.05.20 00:54 Сейчас в теме
(10) Относительно честным отъёмом денег у предприятий занимается не 1С, а сами предприятия у себя. Гигантская доля затрат предприятий на автоматизацию вызывается не отсутствием "методик 1с", а отсутствием систематичного и технологичного подхода к автоматизации у самих предприятий = отсутствие политики автоматизации в ИТ в отношении конфигурируемого и разрабатываемого ПО. "Купим пучок франчей и консультантов за мешок копеек - они нам усё сделают".
It-developer; madonov; isaev2016; wowik; Student1C; Manoshkin; +6 Ответить
52. dock 44 29.05.20 12:21 Сейчас в теме
(43) Нельзя вот так сразу всю правду русскими буквами писать!
Предприятия не виноваты! На самом то деле: "Франчи-кровососы: нихрена ничего не умеют, а денег требуют! А мы вот просто не можем без этой вот фичи..."
53. dock 44 29.05.20 12:25 Сейчас в теме
(10)
Такую систему можно было создать уже давно, но 1С это не делает по принципиальным соображениям.

А вот тут вы не правы... не только в мире 1С "бардак" - это проблема всей области.
Фирма 1С на текущий момент тоже двигается в сторону "порядка" - продукт СППР неплохо развивается, АПК тоже есть...
Да, свой "подход" к наведению порядка, да, не слишком "быстрый"... но есть!
42. ogoneksergei 3 28.05.20 22:32 Сейчас в теме
(4)Задача решается в несколько строк кода модуля расчета НДФЛ. У нас была решена и в ЗКБУ 1.0 и сейчас решена с ЗиКЗУ 3.1. Пришлось конечно разобрать весь модуль расчета НДФЛ. Но итог положительный. Странно что несколько человек не смогли решить.
44. roman72 323 29.05.20 00:55 Сейчас в теме
(42) А можно ещё проще - из готового расчёта исключать НДФЛ.
48. user_2010 780 29.05.20 09:43 Сейчас в теме
(44) задача не в том, чтобы НДФЛ исключать, а вычеты не применять при расчете НДФЛ.
54. dock 44 29.05.20 12:29 Сейчас в теме
(44) а следующий месяц у вас расчет будет неверен :)
Вычеты - это сложный расчет, с накоплением и применением пределов.
никогда не применяйте в ЗУП "быстрые" решения...
58. roman72 323 29.05.20 23:18 Сейчас в теме
(54) Если не записывать в регистры корректирующие строки, то да.
59. dock 44 29.05.20 23:38 Сейчас в теме
(58) Соглашусь,тоже вариант.
Насторожило "можно проще..." Возможно это лично моя практика, но когда кто-то упоминает слово "просто, проще ..." если нужно что-то изменить в расчетах ЗУП - это сразу настораживает. :)
47. user_2010 780 29.05.20 09:41 Сейчас в теме
(42) молодцы! конечно, тоже весь модуль разобрали... дело было на 3.1.3. НДФЛ же постоянно перелопачивают - может быть сейчас по-другому реализовано. Как раз в 3.1.4 - был уже совсем другой алгоритм. Вы в какой версии 3.1 реализовали?
50. ogoneksergei 3 29.05.20 10:58 Сейчас в теме
(47) мы начали с 3.1.5. Сейчас уже 3.1.10.443. Все работает штатно. Пришлось конечно поковыряться с имущественными вычетами. Но тоже решили. Правда пока в старом варианте расчета. 1С Недавно внедрили новый модуль. Оптимизированный. Вот его еще не разбирали. Собираемся переход на 3.1.13(14) делать. И переход на новый модуль расчета.
51. user_2010 780 29.05.20 11:13 Сейчас в теме
55. dock 44 29.05.20 12:32 Сейчас в теме
(50) смотрите сразу 3.1.14, судя по изменениям, в 13-й будет отличаться от 14-й :)
7. user_2010 780 28.05.20 10:19 Сейчас в теме
Согласна с правилом: оценил - умнож на 2, а лучше на 3. Жизнь уже доказала это правило не раз! Да вот только конкурировать с такими сроками как?
9. sapervodichka 6178 28.05.20 11:12 Сейчас в теме
(7) никак не конкурировать. Представь, если я и ты будем конкурировать за одну задачу, ты своё обоснование напишешь (где умножила на 2, а хотела на 3), а я своё по таблице рисков, кого выберут? (важно умное обоснование подвести под свои цифры "смекаешь =)))", а умножить на 2 или на 3 - это согласись "не канает")
maxpiter; +1 Ответить
11. toypaul 63 28.05.20 11:30 Сейчас в теме
Надо просто быть честным перед самим собой и перед заказчиком. Есть четкое ТЗ, есть четкая оценка и она будет дана заказчику. Нет такого ТЗ или есть какие-то сомнения - никакой оценки, работаем по факту.

Ну нам надо оценить обычно говорят (посредники). Ну надо - так пусть другие на это тратят свое время
12. nomad_irk 63 28.05.20 11:39 Сейчас в теме
(11)В работе по факту может быть 2 варианта:
1. Задача не завершится никогда(условно), либо ее решение будет очень долгим и дорогим для заказчика.
2. За решение задачи вы получите несоизмеримо низкую оплату, т.к. заказчик выделил определенный бюджет.

Как правило, события развиваются по второму сценарию.
user989550; +1 Ответить
13. toypaul 63 28.05.20 12:06 Сейчас в теме
(12)
1. это не мои проблемы. нанимайте консультантов, пускай они вам пишут ТЗ. если заказчик не потрудился поставить задачу, я не вижу смысла работать по другому. это вообще золотое правильно везде - если ты сам предварительно не потрудился и не вник в то, что тебе нужно, то дальше будет все долго и дорого. если ты этого не понимаешь, я не вижу смысла браться за такую работу.

2. работа по факту, это оплата по этапам. странно это не понимать. причем оплата по согласованному тарифу.

можно конечно пустить пыль в глаза - и заложить космические часы на решение задачи. многие так и делают. те кому лишь бы за задачу схватиться. это не мой способ. я такого не понимаю.
14. Vlad1917 47 28.05.20 12:07 Сейчас в теме
- У нас отчёт не показывает... ну пусть будет какие-нить Основные Средства. Почему?
- Ну ты ж бухгалтер, я-то почём знаю? Дайте время, разберусь.

Через несколько часов
- Поставьте тут и тут галочки, всё будет. Итого с вас 2 часа.
- 2 часа??? За 2 галочки??? Да тут времени на это 2 минуты надо!

А то, что ты три часа в коде копался, чтоб разобраться, потом проверял, что нашёл, потом ещё всякие скрины делал и ответ писал, в общем, убил на эти галочки пол-дня, и 2 обозначенные часа это и так заметно меньше потраченного времени - мало волнующий фактор. Ну да. Тыжпрограммист, и должен знать назубок все эти бухгалтерские (ЗУПовские, УТшные и прочие) галочки.
Fril; zima_a; wowik; maxos1978; bulpi; pm74; CheBurator; rmarkovych; shard; sapervodichka; +10 Ответить
15. toypaul 63 28.05.20 12:09 Сейчас в теме
(14)
Да тут времени на это 2 минуты надо!


знание того где нужно нажать стоит в 30 (60) раз дороже :)
17. Vlad1917 47 28.05.20 12:19 Сейчас в теме
(15)Хорошо бы. Но когда сразу знаешь ответ и его озвучиваешь, это выходит совсем бесплатно. Дружеская помощь франча клиенту. :)
18. sapervodichka 6178 28.05.20 12:23 Сейчас в теме
(17) тут звено пропущено "менеджер по работе с клиентами". Ты свою работу сделал, разбираться с оплатой "менеджер из твоего франча" должен, а не ты. Или за что они там деньги у вас получают? (ведь не просто за то что нас программистов/консультантов в бассейн с говном бросают, а дальше мы сами должны и сделать и оплату выбивать)
16. sapervodichka 6178 28.05.20 12:15 Сейчас в теме
(14) Тебе попался "такой" пользователь, он наверное дифференциальные уравнения по щелчку решает =))) Честно вот "таких" не больше, чем "тех", которые нормально тебя выслушают и скажут "Спасибо" (вот не перереживай за него, главное, что ты сам разобрался, и за это тебе + к карме 1Сника)
19. Vlad1917 47 28.05.20 12:25 Сейчас в теме
(16)
У меня статистика совсем другая.
Походу, 80% "таких" достались мне, а 80% "тех" - тебе. :D
Да и ладно, можно было бы порадоваться, мол "скилл растёт". Но увы,когда через пол-года, после сотни других аналогичных галочек, снова спросят про тот же отчёт и ту же проблему, совсем не факт, что я вспомню и не буду заново сидеть и вникать.
pm74; improg; nomad_irk; sapervodichka; +4 Ответить
20. sapervodichka 6178 28.05.20 12:33 Сейчас в теме
(19) хреново, тебе! Я например раньше думал, что успокоительные для девчонок, но стал старше и мне прописали.... постоянная нервотрепка, она имеет накопительный эффект и не выводится полностью из организма. Бухать не начал, но стараюсь помедитировать, когда подбешивают уменки "типа ответсвенные", которые задачи делегируют на тебя, а сами нормально спят по ночам как будто нет у них ответсвенности.
21. dsdred 2301 28.05.20 12:45 Сейчас в теме
Неполное ТЗ

ТЗ?
Нет я слышал это слово и сам когда то писал во время учебы, но в жизни такой зверь не встречался.
izidakg; improg; +2 Ответить
22. sapervodichka 6178 28.05.20 12:49 Сейчас в теме
(21) ТЗ = "Точка Зрения" (сегодня одна, завтра другая)
izidakg; rmarkovych; dsdred; +3 Ответить
25. dsdred 2301 28.05.20 13:28 Сейчас в теме
(22)Вот это мне знакомо))

Хуже когда точка зрения появляется к моменту завершения проекта у молчавшего до этого на совещаниях сотрудника...
23. mixsture 28.05.20 12:57 Сейчас в теме
В этих таблицах есть лишь одна проблема. Они сильно затягивают процесс оценки, а в большинстве случаев этот процесс не оплачивается. Поэтому и используют просто некий средний коэффицент 2 или как вариант используют интервальные оценки. Это позволяет не тратить время бесплатно.
Да, в варианте среднего коэффициента одни клиенты (с хорошим ТЗ) платят за других клиентов (с отсутствием ТЗ). А в варианте интервальной оценки присутствует неопределенность (между левой и правой границей легко может быть разница в 2 раза).

Думаю, там, где необходимы эти таблицы - стадия предпроектного проектирования уже занимает порядочно времени и поэтому должна оплачиваться отдельно (или проще: раз заказчик не написал ТЗ - мы напишем вместе с ним, но это отдельная работа и отдельная оплата. И уже после нее будет понятен объем работ и оценка проекта). Для сильно неопределенных ТЗ - разбиение на маленькие шаги и приемка/оплата каждого из них.
roman72; improg; +2 Ответить
24. sapervodichka 6178 28.05.20 12:59 Сейчас в теме
(23) кому как удобно обосновывать свою оценку.
26. sapervodichka 6178 28.05.20 13:50 Сейчас в теме
(24) таблица и маркеры составляются единожды, т.е. 1 раз, чтобы потом пользоваться на всех задачах. У меня она лично понимание в какой цветовой зоне ТЗ, находится в голове, и коэффициент риска я добавляю на лету к оценке. А если потребуют обоснования (что не всегда требуется Заказчику), то показываю таблицу и маркеры. Поэтому утверждение про затягивание времени при использовании таблицы тут не уместно, даже не понятно (Нормальный 1Сник использует инструменты так как нужно, а как не нужно - делать не нужно, как говорил уважаемый, Винни Пух.).
Irwin; user605780_L.Alexander8; user1408452; marylin; Aleksandr_Ch; duke-81; dmryzhkov; +7 Ответить
28. СергейКа 668 28.05.20 14:12 Сейчас в теме
Как я понял, много крутится вокруг обоснования оценки в часах )
По сути, тут есть пара способов обойти: как написано выше - работать по факту или выставлять сразу стоимость.
Конечно для расчета стоимости для себя составляешь примерную оценку в часах с рисками, но клиенту это знать не обязательно. Много раз уже поднимали тему что "работа программиста схожа с работой древнейшей профессии - все оценивается в часах". Но если не работаешь во франчайзи с почасовой ставкой, то можно и нужно от этого уходить.
По существу же вопроса, если схожая задача выполнялась ранее, то так же можно на ее основе составлять таблицу рисков. И обязательно во время задачи нужно добавлять время на предварительную оценку.
29. sapervodichka 6178 28.05.20 14:19 Сейчас в теме
(28) ещё раз напишу: "таблица не составляется на каждую задачу, таблица фиксированная, составляется 1 раз, и используется в дальнейшем при оценке задач" (конечно цифры там у каждого свои, под свою специфику и контекст).
30. sapervodichka 6178 28.05.20 14:24 Сейчас в теме
(29) и по таблице определяется лишь что добавить сверх своей предварительной оценки (что каждый включает в свою предварительную оценку, дело индивидуальное: включать ли время на чтение и обджумывание - да включать, показывать ли время завышенное для клиента или реальное в предварительной оценке это сугубо вопрос конкуренции с другим программистом, претендующим на эту же задачу. Если нет конкуренции, то не заморачивайтесь так сильно, оно вам не надо)
31. СергейКа 668 28.05.20 14:38 Сейчас в теме
(29)
ещё раз напишу: "таблица не составляется на каждую задачу, таблица фиксированная, составляется 1 раз, и используется в дальнейшем при оценке задач" (конечно цифры там у каждого свои, под свою специфику и контекст).

Трам-пам-пам ) Ни разу не спорил с этим утверждением.


(30)
Если нет конкуренции, то не заморачивайтесь так сильно, оно вам не надо)

Хоть бы и есть. Оценка все равно ближе к реальной. Неоднократно клиент обжегшись на более дешевых исполнителях возвращался обратно ко мне, если конечно результат важен.
sapervodichka; +1 Ответить
32. sapervodichka 6178 28.05.20 14:40 Сейчас в теме
(31) потому что ты аргументируешь свою позицию и правильно работаешь с претензиями и возражениями =))))
33. СергейКа 668 28.05.20 14:43 Сейчас в теме
(32) Не факт )) Все от клиента зависит, иногда что-то доказывать и аргументировать просто бесполезно. В таком случае лучше работает что то типа ультиматума: моя цена такая за задачу, не хотите - пожалуйста, рынок большой. Есть 2 крупных (и вредных) клиента которые уходили ~ на полгода и вернулись обратно поработав с несколькими другими.
34. sapervodichka 6178 28.05.20 14:52 Сейчас в теме
(33) разные случаи бывают, такие тоже были. Но вот есть контр пример, если кушать хочется и ты например на 1сlancer или fl пытаешься задачу выиграть у других прогеров...там ультимативный подход будет жёсток и не прокатит. Нужно показать себя надёжным, и если просто цифру с оценкой бросить, то тебя проигнорируют. Приходится демонстрировать подход к оценке задачи
35. СергейКа 668 28.05.20 14:59 Сейчас в теме
(34)
на 1сlancer или fl

Если на эту тему зашел вопрос, то мое мнение что эти сервисы дно. Несколько лет с них как ушёл.
Но и там подход вполне реален. Если задача и оплата меня не устраивает то браться за нее не буду. Не вижу смысла конкурировать за ставку 300-500 р. в час. Если клиента мало интересует результат а больше стоимость, то это показатель на мой взгляд, своего рода маркер что работать с ним не стоит.
zima_a; bulpi; shard; user_2010; +4 Ответить
36. sapervodichka 6178 28.05.20 15:16 Сейчас в теме
(35) да, вообще, у нас не кремниевая долина... и Дудь интервью у нас не возьмёт... хотя если его Доджи на митап Инфостарта пригласят, может и возьмёт =)
71. SiAl 75 21.12.20 09:49 Сейчас в теме
(36) кого-то может интересовать мнение шута и лжеца Вдудя?
"О, времена, о, нравы..."
72. sapervodichka 6178 21.12.20 11:29 Сейчас в теме
(71) это науке неизвестно, но интересен его канал как инструмент маркетинга и популяризации.
73. SiAl 75 21.12.20 11:44 Сейчас в теме
(32) Науке это как раз известно. Нечистоплотность и лживость Вдудя уже известны многим. Например, есть разборы его видео на ютуб-канале "Плохой сигнал". Если он интересен как пример маркетинга, то тогда - да, маркетинг и правда очень редко ходят по одной стороне дороги.
37. mixsture 28.05.20 17:16 Сейчас в теме
(33) Присоединюсь, что доказывать и аргументировать почти всегда бесполезно. Потому что для спора с обоих сторон должны быть знания. А со стороны заказчика в большинстве случаев имеем просто жадность (хочу дешевле) в соединении с некомпетентностью ("у нас тут сисадмин говорит, что на форумах где-то видел, как это за 15 минут сделать").
Я для заказчиков говорю так: вот моя оценка задачи (она основана на том, что известно в момент времени Х), либо вы доверяете моему опыту, либо нет. Все что становится известно после момента Х - увеличит и стоимость по фактически потраченному времени. Для снижения рисков мы можем разделить на маленькие этапы, чтобы вы могли попробовать качество на малых суммах. Если вы хотите спорить - то предоплачиваете любое число часов и мы на них спорим сколько угодно.

После этого желание спорить пропадает, потому что основная цель спора - выторговать скидку - не соотносится с затратами денег на сам спор.
evkuznetcova; zima_a; wowik; user_2010; pavlov_dv; СергейКа; +6 Ответить
38. Serg O. 204 28.05.20 17:30 Сейчас в теме +1 $m
в целом ... хорошая статья как "заострение вопроса" , ставлю +
---------------------------------------------------------
но таблица...не кажется Вам - немного странной?

Конкретные коэффициенты видимо каждый - свои может подставлять...
многие тут пишут... x 2 множитель... это "обычный" менеджерский приём...
тут его нет... а это странно ...

более того - "удивляет" несимметричность таблицы... почему по строкам шаг от 5% + 10 % а по столбцам 10% + 20% (в 2 раза больше... )

---------------------------------------------------------------------------
симметричная картина - будет "в целых" процентах... и в максимуме +81% от первоначального срока... т.е. почти в 2 раза...
-------------------------------------------------------------------------
ту же табличку если считать по Максимальным значениям симметричных интервалов - как раз получится + 100% в крайнем верхнем углу... и "более симметричная верхняя и нижние части" - см. 2 картинку
---------------------------------------------------------------------

Ещё интересный вопрос был бы "уменьшение" срока... если сразу "сдвинуть" груницу "нормального" на середину... тогда "Зелёные" % будет отрицательным!
т.е. мы должны закончить РАНЬШЕ срока! Желтый - примерно в срок.... а Красные - точно не успеем....

и шкала % не обязательно должна быть "линейная"...
ошибки обычно носят 2х характер... т.е. шкала будет логарифмическая.... и взяв за "основу в 2 раза быстрее ... в 2 раза медленнее... получаем 4 картинку... "белые ячейки" - это 1 - нормальное время... -

3-я картинка - даёт и + и - значения ...
Прикрепленные файлы:
izidakg; sapervodichka; +2 Ответить
40. sapervodichka 6178 28.05.20 19:14 Сейчас в теме
(38) мне очень нравится ваш подход и раскраска!!!
39. Serg O. 204 28.05.20 18:11 Сейчас в теме
Если "Техническое задание" - это длительное выполнение... множества задач... то их надо разбивать на кучу мелких "задач"... и для них "приблизительно можно оценить график "выгорания"... и тут оценка может быть более точной

см. видео и Excel-файлик от Максима Дорофеева (автора книг "Джедайские техники" и "Путь джедая")

- Оценка и прогнозирование проектов (Часть 0: Введение)
https://www.youtube.com/watch?v=40NRDkgcksI

- Оценка проектов часть 1: Простая диаграмма выгорания работ
https://www.youtube.com/watch?v=PpNFgPCI-XM

- Оценка проектов часть 2: Велосити и добавлясити (расширенная диаграмма выгорания работ)
https://www.youtube.com/watch?v=gTn3ErjIQbY

Всем советую начинать с 0 части...
56. dock 44 29.05.20 12:36 Сейчас в теме
41. Serg O. 204 28.05.20 21:18 Сейчас в теме
Реальную "скорость" посмотрел... по 3м людям ... за 3 месяца

Отклонение от "нормы" от -80% до + 80% бывает ... но редко

"тренды" в Excel - конечно приблизительные... но "характеры" людей легко видны...
Прикрепленные файлы:
wowik; sapervodichka; +2 Ответить
45. roman72 323 29.05.20 01:03 Сейчас в теме
Сослался бы на эту статью
https://infostart.ru/public/1176530/
Метод COCOMO всё же более "технологичен" в расчёте потенциальных затрат проекта на основе предыдущего опыта разработки и проектирования.
46. sapervodichka 6178 29.05.20 02:08 Сейчас в теме
(45) я тут не за проект писал, а за задание программисту. Прочитал указанную статью, но там не указано как с помощью COCOMO программист может задание более "технологично" оценить. Если будет время, пожалуйста, продемонстируйте метод COCOMO для оценки вот этого ТЗ //infostart.ru/public/149361/.
57. roman72 323 29.05.20 23:16 Сейчас в теме
(46)
//infostart.ru/public/149361/

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

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

"Технологичность" COCOMO в том, что он опирается на накопленные ранее и формализованные данные и детализированные до необходимого уровня операции.
В этом отличие от методов "экспертной оценки", к которым относится ваша таблица рисков ТЗ.
49. starik-2005 2797 29.05.20 09:52 Сейчас в теме
Хорошо спланированный проект занимает в ДВА раза больше времени (телескоп Уэбб, например), плохо спланированный - в ТРИ - почти все проекты Роскосмоса. Выбивается тут СпэйсИкс, но у них Аджайл, так что они играют не честно )))
63. Painted 48 02.06.20 19:01 Сейчас в теме
(49)
Выбивается тут СпэйсИкс
Обещал пилотируемый полет в 2017 году, сделал в 2020. Наверное, все-таки не Agile.
64. starik-2005 2797 02.06.20 22:28 Сейчас в теме
(63) Да, РосКосмос федерацию или как ее теперь там сто раз переименовывал начал делать в 2010-м, на 15-й были назначены испытания. Сейчас 20-й, корабля нет вообще.В 2020-м году:
28 января 2020 года из презентации первого замглавы «Роскосмоса» Юрия Урличича, представленной на XLIV Академических чтениях по космонавтике памяти С. П. Королёва, стало известно, что беспилотный облёт Луны кораблём «Орёл» планируется на 2028 год,

13 февраля 2020 в материалах разработчика аппарата — Ракетно-космической корпорации «Энергия», появилась информация о том, что космический корабль «Орёл» впервые отправится к Международной космической станции (МКС) в пилотируемом режиме в сентябре 2025 года, в беспилотном режиме - в сентябре 2024 года.


У Маска юыло иначе: в 2006-м получили бабки на Фалкон и Драгон в огромном размере! - жалкие по меркам РосКосмоса 400кк бачей (даже меньше). В 2010-м капсула Драгона с вертолета была скинута в море для проверки парашютной системы, т.е. прототип уже был. Ну а дальше:
25 мая 2012 года, в 16:02 UTC, корабль Dragon был пристыкован к модулю Гармония, в рамках демонстрационной миссии SpaceX COTS Demo Flight 2/3[12]. Dragon стал первым частным космическим кораблём, пристыкованным к Международной космической станции.


Ну и 6 лет до первого полета без космонавтов пилотируемого прототипа, ну и еще два на полную доводку корабля. Заметьте, многоразового, а не как Союз и Прогресс - одноразовых болванок.
65. Painted 48 03.06.20 08:41 Сейчас в теме
(64)
РосКосмос... начал делать в 2010-м

в 2006-м получили бабки

Все-таки Маск начал на 4 года раньше. Подождем. ))
Плюс он же частник, у частника время-деньги. А Роскосмос на окладе - солдат спит, зарплата идет.
(64)
жалкие по меркам РосКосмоса 400кк бачей (даже меньше)

Бюджет госкорпорации "Роскосмос" в открытой части на 2020 год составляет 176 млрд руб.
Действующий бюджет NASA составляет около $22,6 млрд.
Американская администрация запрашивает у Конгресса $25,2 млрд на деятельность NASA в 2021 финансовом году.
То есть, бюджеты различаются на порядок.
67. starik-2005 2797 03.06.20 14:35 Сейчас в теме
(65) так НАСА не только Маска финансирует, но и Боинг, который второй корабль пилит, а еще SLS пилят и кучу всего. У них три робота работали на Марсе, один у Юпитера, Новые Горизонты, ... А РосКосмосы фобос-грунт так и не запустили - распилили и страховочку получили. Только радио-телескоп запустили орбитальный - хоть что-то.

В общем РосКосмос не стоит сравнивать с НАСА - не те масштабы, а вот с Маском - легко. У Маска куда меньше бюджет, куда больше результатов. Надо РосКосмос расформировать и отдать бабки частникам - тогда, может быть, будет результат.
user989550; +1 Ответить
60. iov 407 30.05.20 00:40 Сейчас в теме
Это отлично. Но как всегда натянуто на личный опыт.
Потому как простая задача обмена с некой конторой простыми документами через простой веб сервис растянулась на месяцы. Оказывается договор номер 34058723-6729-8672-56-287450-9258605625/245624562 /24562456245 - это не выдумка а реальная ситуация - и как это натянуть в простой обмен простым решением? А вот этот элемент выясняется не в процессе тестирования (тестирование производится на синтетических данных предоставленных заказчиком ). И вот таких моментов кучи. Где коэффициент на то что ТЗ написано без учета реальных данных и без учета ИЗМЕНЕНИЯ реальных данных.
Но это не автору камень это просто так сижу на горе камней и раскидываю кругом.
61. sapervodichka 6178 30.05.20 15:19 Сейчас в теме
(60) скорее теория, натянутая на практику
62. kudlach 11 02.06.20 09:24 Сейчас в теме
Дмитрий молодец. Поднял интересную тему.
Она важна, но не всем. Только для тех кому никуда без плановой отчетности и отчетности план-факт проекта с описанием причин отклонений.
Это руководители проектов в больших компаниях, фрилансеры, которые работают по проектной технологии, где "оговоренная функциональность за оговоренные деньги в оговоренные сроки".
Оценкой, действительно, как сказали выше лучше заниматься не программистам.

Но есть другие модели взаимодействия. Например, решение поставленной задачи по графику с оплатой по факту затрат.
В перечень задач может входить формирование контрольного примера, согласование изменений и их исполнение. При получении доп. информации График меняется. И да, здесь могут быть применены РИСКИ для оценки сроков, но не конечных денег. При наличии рисков Заказчик предупреждается о возможном повышении стоимости как следствии, тогда и он заинтересован в самостоятельных действиях для уменьшения рисков.
Обоснование такой модели элементарное - всем руководителям хорошо известный треугольник "Качество-Время-Деньги".
Другим аргументом служит предложение рассказать как бы эту задачу решали и оплачивали если бы ее выполняли наемные сотрудники Заказчика, предложение рассматривать Исполнителей, как временных работников Заказчика. (Что у исполнителей есть варианты другой работы говорить не надо, разумный Заказчик это понимает сам).
Если на вариант СОТРУДНИЧЕСТВА Заказчик не идет, то это не Ваш Заказчик.
sapervodichka; +1 Ответить
66. timeforlive 15 03.06.20 09:11 Сейчас в теме
После прочтения следующей цитаты я сразу поставил жирный ПЛЮС:
Как я поступаю, когда от меня хотят услышать, за какое время я подписываюсь выполнить задание?


В частных компаниях, например, производство продовольственных продуктов питания, никогда не будет точной оценки работы в часах, потому что задачи ставятся:
А. устно, либо письменно, но под диктовку;
Б. заказчик в лице сотрудника компании одного из отделов не стремится нести ответственность за предоставленную информацию, а понимание бизнес-процессов и функционал 1С лежит непосредственно на плечах программиста 1С.
В. скорость всегда приоритетнее качества, что порождает костыли в процессе изменения задания (устно) программисту.
sapervodichka; +1 Ответить
68. d.zhukov 1274 04.06.20 13:04 Сейчас в теме
В чем смысл оценки работ со всеми этими диаграммами, когда и без того понятно, что считая стоимость разработки нужно прибавлять как минимум столько же на полноценное человеческое тестирование (спасибо V.A., но нет). И когда ты приходишь к итоговой стоимости. то понимаешь, что ее озвучивать заказчику нет никакого смысла если хочешь остаться исполнителем))
69. sapervodichka 6178 04.06.20 14:50 Сейчас в теме
70. Serg O. 204 05.08.20 21:54 Сейчас в теме
Добавление к предыдущему комментарию:

последняя 3-я часть от Максима Дорофеева - для оценки сроков проекта с учетом "добавляемых" задач... и плана...
https://www.youtube.com/watch?v=BxSznIv0dgY

а так же очень классный стрим
Управление разработкой ПО (Технический долг, Agile и все такое)
https://www.youtube.com/watch?v=xYNQLUBtuIM

книга, упоминаемая в стриме книга Макконелла "Сколько стоит программный проект"
-djvu файл. http://en.bookfi.net/book/1214041

и в этой книге - на с.154 - табл.12.14 интересная таблица "Важность-ТрудоЗатраты"
"улучшенная" таблица Важно-Срочно но уже 4 х 4

т.е. чем больше - тем первее надо делать...
Прикрепленные файлы:
74. AnryMc 840 10.03.21 13:13 Сейчас в теме
Разговор: Менеджер (М) и Заказчик (З)

З - Скажите пожалуйста сколько будет стоить ТАКАЯ доработка
М - Сложно сказать так сразу нужно посмотреть, уточнить...
З - Ну хотя бы приблизительно...
М - Ну я думаю где то 70 - 90 тысяч.
З - А можно точнее.
М - 20 тысяч.
З - Но вы толь ко что сказали 70-90?
М - Вы не поняли. "Сказать точнее" стоит 20 тысяч

(Вольный пересказ реального разговора)
fatman78; investec; Fril; +3 Ответить
75. sapervodichka 6178 10.03.21 13:17 Сейчас в теме
(74) т.е. по итогу всегда 90 =))
Оставьте свое сообщение