Вроде бы начиналось правильно - для проекта нудно максимально учесть все статьи. А потом как-то скатилось в мелкий прикладной пример неполного плана трудозатрат на проект.
А в части учета налогов - вообще сомнительно. Налоги платит компания, поэтому там возможна куча факторов, которые учитывать для РП вообще не нужно.
Для кого статья - не мешало бы отразить. А то получилось «смешались в кучу кони, люди..» и как для галочки - «сделано».
То есть речь просто о форматках ввода/вывода? С тем же результатом можно было настроить и в экселе.
Тут нет ничего от управления проектами (разве что упомянули диаграмму Ганта). Ни планирования задач, ни балансировки ресурсов. Молчу уж про учет отпусков.
Просто настроенная отчетность, завязанная на классифицированные формы ввода данных.
Забыл указать про одно из принципиальных различий. Проект характеризуется сроками, то есть цель достигается в поставленный срок выделяемыми ресурсами. Процесс направлен на достижение цели, но он является повторяющимся, и его могут быть регулярными на определенную дату.
Ну а так - конечно , между ними много общего. И характеризовать можно с одинаковых ракурсов. Да и ладе буквы одинаковые. Но это не одно и то же. И «управлять проектами» и «управлять процессами» - о разном. А если подменять одно другим - то не достичь цели или сорвать заданные параметры.
Процесс это действие. Проект - это определенный порядок действий, имеющий заранее определенный результат и выделенные ресурсы. Если подходить к проекту как к процессу, то результат может быть и не достигнут.
Может я и устарел в понятиях, но изначально проект и процесс - просто разные вещи.
Какая-то халтурная статья, в которой стандартный путь внедрения ит-проектов полается почему-то как путь SAP, и «в противовес» якобы путь 1С. С выводом «все пути - хороши». Зачем такое публиковать???
Интересно - зачем в заголовке «капитальное строительство»? Для дополнительного внимания? Из приведенного огромного количества буковок к капитальному строительству отсылки никакой. А всё остальное можно смело считать попыткой в значительно большем объёме описать давно используемые инструменты. В чем польза статьи???
Еще раз повторю - да, бывает ситуация, когда можно делать работу и без ТЗ. Но это, как правило, небольшой объем работ и небольшие Заказчики. Конечно, всё относительно.
При этом я рассуждаю на тему, вынесенную в заголовок. И говорю, что ТЗ порой необходимо для проекта. И против безапеляционности рассматриваемого посыла.
Какой результат можно получить, не обладая изначально определенной постановкой? Лично мне/моей Компании документация необходима. ФТТ/ТЗ. Пол них - проектная документация. И только так можно в дальнейшем поддерживать тысячи систем, созданные сотнями исполнителей.
Да на здоровье. Но крупный Заказчик не будет платить так. Ему нужен результат работы. Один-два проекта по такой схеме получится пихнуть. Дальше - всё. Оплата за результат. И тут же переход к этапности. А это - деление потребности на части. И снова - ТЗ.
Вот и получается - ориентир нужен. Это проблема из серии «какая методология проекта единственно верная - pmbook или agile” (прошу прощения, если не совсем корректно использовал данные термины, но смысл, думаю, понятен).
А кто сказал, что Заказчику нужна такая модель оплаты? В мире много чего придумано. Но нужно определиться от чего пляшем. Заказчику нужен результат, или исполнителю нужно работать?
со стороны исполнителя войти в проект без ТЗ возможно в том случае, если есть возможность соскочить с проекта. В противном случае можно войти в проект условно за 100 рублей и работать там годами, из-за того, что Заказчик будет уточнять и уточнять свое единственно требование «хочу, чтобы это работало так, как мне нужно».
То есть упоминаемый разрабатываемый продукт, рекламируемый статьёй, позиционируется и как замена для Jira, и как замена чуть ли не Oracle Primavera. Возникают сомнения - чудес не бывает!
Очень однобокий взгляд на заменяемые системы, и тем более - на аналоги. Сейчас рынок очень активно развивается и решений очень много. На мой взгляд - нужно позиционировать своё решение под конкретные задачи, а не обобщением под всё управление проектами.
Ну а к вопросам - какие характеристики по масштабируемости можете предложить? Количество задач, иерархии задач (количество уровней вложенности), количество одновременно работающих пользователей?
Вроде бы начиналось правильно - для проекта нудно максимально учесть все статьи. А потом как-то скатилось в мелкий прикладной пример неполного плана трудозатрат на проект.
А в части учета налогов - вообще сомнительно. Налоги платит компания, поэтому там возможна куча факторов, которые учитывать для РП вообще не нужно.
Для кого статья - не мешало бы отразить. А то получилось «смешались в кучу кони, люди..» и как для галочки - «сделано».
Добрый день.
То есть речь просто о форматках ввода/вывода? С тем же результатом можно было настроить и в экселе.
Тут нет ничего от управления проектами (разве что упомянули диаграмму Ганта). Ни планирования задач, ни балансировки ресурсов. Молчу уж про учет отпусков.
Просто настроенная отчетность, завязанная на классифицированные формы ввода данных.
Забыл указать про одно из принципиальных различий. Проект характеризуется сроками, то есть цель достигается в поставленный срок выделяемыми ресурсами. Процесс направлен на достижение цели, но он является повторяющимся, и его могут быть регулярными на определенную дату.
Ну а так - конечно , между ними много общего. И характеризовать можно с одинаковых ракурсов. Да и ладе буквы одинаковые. Но это не одно и то же. И «управлять проектами» и «управлять процессами» - о разном. А если подменять одно другим - то не достичь цели или сорвать заданные параметры.
Процесс это действие. Проект - это определенный порядок действий, имеющий заранее определенный результат и выделенные ресурсы. Если подходить к проекту как к процессу, то результат может быть и не достигнут.
Может я и устарел в понятиях, но изначально проект и процесс - просто разные вещи.
Какая-то халтурная статья, в которой стандартный путь внедрения ит-проектов полается почему-то как путь SAP, и «в противовес» якобы путь 1С. С выводом «все пути - хороши». Зачем такое публиковать???
Интересно - зачем в заголовке «капитальное строительство»? Для дополнительного внимания? Из приведенного огромного количества буковок к капитальному строительству отсылки никакой. А всё остальное можно смело считать попыткой в значительно большем объёме описать давно используемые инструменты. В чем польза статьи???
Еще раз повторю - да, бывает ситуация, когда можно делать работу и без ТЗ. Но это, как правило, небольшой объем работ и небольшие Заказчики. Конечно, всё относительно.
При этом я рассуждаю на тему, вынесенную в заголовок. И говорю, что ТЗ порой необходимо для проекта. И против безапеляционности рассматриваемого посыла.
Какой результат можно получить, не обладая изначально определенной постановкой? Лично мне/моей Компании документация необходима. ФТТ/ТЗ. Пол них - проектная документация. И только так можно в дальнейшем поддерживать тысячи систем, созданные сотнями исполнителей.
Повторюсь - бывает всяко. Я в первую очередь против однозначного декларирования «ТЗ не нужно». Всё определяется размером и целями проекта и Заказчика.
Я «играю» сейчас со стороны Заказчика, ооочень крупного. Был и исполнителем. И всё испытывал на себе.
Да на здоровье. Но крупный Заказчик не будет платить так. Ему нужен результат работы. Один-два проекта по такой схеме получится пихнуть. Дальше - всё. Оплата за результат. И тут же переход к этапности. А это - деление потребности на части. И снова - ТЗ.
Вот и получается - ориентир нужен. Это проблема из серии «какая методология проекта единственно верная - pmbook или agile” (прошу прощения, если не совсем корректно использовал данные термины, но смысл, думаю, понятен).
А кто сказал, что Заказчику нужна такая модель оплаты? В мире много чего придумано. Но нужно определиться от чего пляшем. Заказчику нужен результат, или исполнителю нужно работать?
со стороны исполнителя войти в проект без ТЗ возможно в том случае, если есть возможность соскочить с проекта. В противном случае можно войти в проект условно за 100 рублей и работать там годами, из-за того, что Заказчик будет уточнять и уточнять свое единственно требование «хочу, чтобы это работало так, как мне нужно».
То есть упоминаемый разрабатываемый продукт, рекламируемый статьёй, позиционируется и как замена для Jira, и как замена чуть ли не Oracle Primavera. Возникают сомнения - чудес не бывает!
Очень однобокий взгляд на заменяемые системы, и тем более - на аналоги. Сейчас рынок очень активно развивается и решений очень много. На мой взгляд - нужно позиционировать своё решение под конкретные задачи, а не обобщением под всё управление проектами.
Ну а к вопросам - какие характеристики по масштабируемости можете предложить? Количество задач, иерархии задач (количество уровней вложенности), количество одновременно работающих пользователей?