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

14.10.22

Архитектура

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

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

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

  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С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1646    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1863    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    4284    0    ivanov660    10    

30

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

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2129    0    user1754524    15    

16

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    3098    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Программист Стажер Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    10070    0    1c-izhtc    37    

22

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Пользователь Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1565    0    Ingraf    0    

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

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

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

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

Была задача на реальном проекте: изменить расчет НДФЛ в документе "Разовые начисления" - не применять вычеты. Оказалась нерешаемая задача. За нее брались несколько раз, несколько человек... Как это можно было оценить на этапе ТЗ?
user811769; It-developer; ong1990; wowik; VitalyKepov; improg; Flextor74; 116hrus; +8 Ответить
5. sapervodichka 6831 28.05.20 09:40 Сейчас в теме
(4) похоже на "требование гарантии невозможного результата", уловить момент трудно, надо либо отказывать либо пробовать делать как ты пишешь, но без гарантий с твоей стороны... тут сложный у тебя пример
6. user_2010 927 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 381 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 381 29.05.20 00:55 Сейчас в теме
(42) А можно ещё проще - из готового расчёта исключать НДФЛ.
48. user_2010 927 29.05.20 09:43 Сейчас в теме
(44) задача не в том, чтобы НДФЛ исключать, а вычеты не применять при расчете НДФЛ.
54. dock 44 29.05.20 12:29 Сейчас в теме
(44) а следующий месяц у вас расчет будет неверен :)
Вычеты - это сложный расчет, с накоплением и применением пределов.
никогда не применяйте в ЗУП "быстрые" решения...
58. roman72 381 29.05.20 23:18 Сейчас в теме
(54) Если не записывать в регистры корректирующие строки, то да.
59. dock 44 29.05.20 23:38 Сейчас в теме
(58) Соглашусь,тоже вариант.
Насторожило "можно проще..." Возможно это лично моя практика, но когда кто-то упоминает слово "просто, проще ..." если нужно что-то изменить в расчетах ЗУП - это сразу настораживает. :)
47. user_2010 927 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 927 29.05.20 11:13 Сейчас в теме
55. dock 44 29.05.20 12:32 Сейчас в теме
(50) смотрите сразу 3.1.14, судя по изменениям, в 13-й будет отличаться от 14-й :)
7. user_2010 927 28.05.20 10:19 Сейчас в теме
Согласна с правилом: оценил - умнож на 2, а лучше на 3. Жизнь уже доказала это правило не раз! Да вот только конкурировать с такими сроками как?
9. sapervodichka 6831 28.05.20 11:12 Сейчас в теме
(7) никак не конкурировать. Представь, если я и ты будем конкурировать за одну задачу, ты своё обоснование напишешь (где умножила на 2, а хотела на 3), а я своё по таблице рисков, кого выберут? (важно умное обоснование подвести под свои цифры "смекаешь =)))", а умножить на 2 или на 3 - это согласись "не канает")
maxpiter; +1 Ответить
11. toypaul 63 28.05.20 11:30 Сейчас в теме
Надо просто быть честным перед самим собой и перед заказчиком. Есть четкое ТЗ, есть четкая оценка и она будет дана заказчику. Нет такого ТЗ или есть какие-то сомнения - никакой оценки, работаем по факту.

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

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

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

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

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

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


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

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

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

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

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


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

Хоть бы и есть. Оценка все равно ближе к реальной. Неоднократно клиент обжегшись на более дешевых исполнителях возвращался обратно ко мне, если конечно результат важен.
native-api; sapervodichka; +2 Ответить
32. sapervodichka 6831