Лет 15, как системный аналитик занимаюсь оценкой трудозатрат/сроков. Честно говоря не читал специализированную литературу про это, кроме университета где учили про диаграмму Ганта. У меня получилась смесь из вышеперечисленного. Без детального исследования не берусь серьёзно оценивать, кроме как сказать маленький, большой, сложный. Вначале провожу полевые исследования, хотя бы грубые. Но мучаю заказчика, пока точно не пойму, что они хотят. Потом изучаю НПА, так как хотелки заказчика не всегда соответствуют им. Потом проговариваю с закачиком общие черты решения. И только когда у меня есть картинка, делю на части и оцениваю каждую часть трудозатрат по ролями разработчиков. В основном оцениваю сам, но иногда где есть несколько архитектурных решений, консультируюсь с сеньор разработчиками. Не сколько спрашиваю сроки, а сами архитектурные решение. Так как системы которые я разрабатываю немного спецефичны, очень часто надо делать чтобы соответствовало закону, а не логике, то оценкам программистов не доверяю. Они не знают бизнес требований, не учитывают тип и бекграунд пользователей, поэтому могут вложиться в то, что можно сделать упрощено и наоборот отмахнуться от важного. Min - max оцениваю по подзадачам в которых ещё есть элемент неопределённости. По остальным делаю одну среднию вероятную оценку. По неопределённый беру максимальную, по остальным среднию. И если хорошо знаю команду, то оставляю как есть, так как когда оцениваю, то оцениваю с учётом скорости каждого. Если пока плохо знаю кого-то в команде, то оцениваю в среднем, а потом добавляю 30÷. Конечно бывают просчеты, но в целом приемлемо укладываюсь.
Честно говоря, везде куда прихожу внедряю трекинг. И всем вначале совсем не нравится ещё одна обязанность. Но цели трекинга у меня вообще другие. Я не переношу kpi для разработчиков, слишком много факторов. И если честно предварительную оценку трудозатрат делаю с учётом конкретных людей и типов задач. Где-то задачи нудные но их много, где разработчик быстрый но не внимательный. При трекинге прошу заполнить 8 рабочих часов, перекур, игры в ps тоже входят в проекты, точность не требуется. В целом, мне нужно понять реальные трудозатраты по проектам. Когда клиент один, то конечно не заморачиваюсь, все затраты на одного и не нужно трекинга. Как бонус, понял что слишком много пустых собраний, где люди говорят одно и тоже. Теперь собрания только по необходимости. И состав тоже.
Мне показалось, что вы сами на своём примере бухгалтерский учёт изобрели. Я к тому что считать активами что пассивами для вас. Если взять ваш пример, то очень наглядно выйдет. Не всегда все бухгалтера правильно сажают проводки, а тут можно глубже понять.
Самое смешное, это когнитивное искажение, если увеличивается оборот, люди инстинктивно думают, что увеличивается доход. А на самом деле, может увеличиваются ваши обязательства. С этим часто мелкие предприниматели попадаются. Если сальдо отрицательное, то маштабирование бизнеса ведёт к большим долгам, хотя на счетах вроде больше живых денег.
Автору респект, есть над чем задуматься. Но мне кажется, что требуется вначале разработать методику бух учёта для личных расходов, а потом обучать это в школе. Все это мысли в общем, не контра против автора.
Лет 15, как системный аналитик занимаюсь оценкой трудозатрат/сроков. Честно говоря не читал специализированную литературу про это, кроме университета где учили про диаграмму Ганта. У меня получилась смесь из вышеперечисленного. Без детального исследования не берусь серьёзно оценивать, кроме как сказать маленький, большой, сложный. Вначале провожу полевые исследования, хотя бы грубые. Но мучаю заказчика, пока точно не пойму, что они хотят. Потом изучаю НПА, так как хотелки заказчика не всегда соответствуют им. Потом проговариваю с закачиком общие черты решения. И только когда у меня есть картинка, делю на части и оцениваю каждую часть трудозатрат по ролями разработчиков. В основном оцениваю сам, но иногда где есть несколько архитектурных решений, консультируюсь с сеньор разработчиками. Не сколько спрашиваю сроки, а сами архитектурные решение. Так как системы которые я разрабатываю немного спецефичны, очень часто надо делать чтобы соответствовало закону, а не логике, то оценкам программистов не доверяю. Они не знают бизнес требований, не учитывают тип и бекграунд пользователей, поэтому могут вложиться в то, что можно сделать упрощено и наоборот отмахнуться от важного. Min - max оцениваю по подзадачам в которых ещё есть элемент неопределённости. По остальным делаю одну среднию вероятную оценку. По неопределённый беру максимальную, по остальным среднию. И если хорошо знаю команду, то оставляю как есть, так как когда оцениваю, то оцениваю с учётом скорости каждого. Если пока плохо знаю кого-то в команде, то оцениваю в среднем, а потом добавляю 30÷. Конечно бывают просчеты, но в целом приемлемо укладываюсь.
Честно говоря, везде куда прихожу внедряю трекинг. И всем вначале совсем не нравится ещё одна обязанность. Но цели трекинга у меня вообще другие. Я не переношу kpi для разработчиков, слишком много факторов. И если честно предварительную оценку трудозатрат делаю с учётом конкретных людей и типов задач. Где-то задачи нудные но их много, где разработчик быстрый но не внимательный. При трекинге прошу заполнить 8 рабочих часов, перекур, игры в ps тоже входят в проекты, точность не требуется. В целом, мне нужно понять реальные трудозатраты по проектам. Когда клиент один, то конечно не заморачиваюсь, все затраты на одного и не нужно трекинга. Как бонус, понял что слишком много пустых собраний, где люди говорят одно и тоже. Теперь собрания только по необходимости. И состав тоже.
Мне показалось, что вы сами на своём примере бухгалтерский учёт изобрели. Я к тому что считать активами что пассивами для вас. Если взять ваш пример, то очень наглядно выйдет. Не всегда все бухгалтера правильно сажают проводки, а тут можно глубже понять.
Самое смешное, это когнитивное искажение, если увеличивается оборот, люди инстинктивно думают, что увеличивается доход. А на самом деле, может увеличиваются ваши обязательства. С этим часто мелкие предприниматели попадаются. Если сальдо отрицательное, то маштабирование бизнеса ведёт к большим долгам, хотя на счетах вроде больше живых денег.
Автору респект, есть над чем задуматься. Но мне кажется, что требуется вначале разработать методику бух учёта для личных расходов, а потом обучать это в школе. Все это мысли в общем, не контра против автора.