Когда комплексно внедряешь/перевнедряешь на предприятии какую-нибудь более-менее серьезную 1Ску, или более-менее серьезный участок этой 1Ски, надо посчитать, сколько это займет, примерно хотя бы, календарных дней.

Идет внедрение. Последовательная и параллельная совместная работа с разными ответственными заказчика на разных участках.

Мои текущие действия такие-то. Они мне понятны, я знаю, сколько займут, знаю сроки. Затем очередь представителя заказчика. И вот тут получается разное. Предположим, я сделал некое действие, теперь заказчику надо проверить, по результатам принять решение, наметить следующее действие. И тут заказчик может быть занят (оперативная текучка), испытывать трудности (увидел некие реальные проблемы и думает), отойти в мир иной, уволиться, заболеть, уехать в налоговую, быть уволеным, сдавать внезапную отчетность, увлечься лечебным голоданием, заболеть православием головного мозга, отдать деньги Пантелеичу и не придти на работу.

А подразумевается, что на основании действий представителя заказчика, будет понятно : 1) появились мои косяки=> правлю за свой счет (тут я опять могу оценить время) => всё повторно; 2) проявились косяки, о которых раньше не думали, новые идеи, новые результаты, не связанные с действиями программиста=> на их основании надо принять дальнейшее решение.

Вопрос, как толково подходить к календарной оценке проекта (ну там, месяц займет или год).

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

Какие еще толковые методики есть ? Может, где учат ? Может, чего такого качнуть почитать-засмотреть ?

P.S. В статьях и книгах по PM, которых прочитал достаточно, во всех пишут в стиле "Какие же все чудаки, не учитывают риски". На мисте тоже большинство комментов "Надо учитывать риски". А как считать- не пишут.

P.P.S. Полагаю, что прошу сейчас "волшебную таблетку", а на деле - никак не посчитать реально, но путь будет, например.

Какой же я умный, такой пост накатал !!!

Делать поэтапно не предлагать?

(0) иди уже внедряй. после N внедрений придёт просветление, которое называется личный опыт

*зевает

по какой методике проходит внедрение ?

(0) Друк, с такой методой ты в рабство попадешь

(5) определяюсь пока, пробую разное, сравниваю, что лучше подходит лично мне. На текущее время четкие процессы не прописаны. Вопрос как раз и поэтому.

(6) чую, что надо улучшать, проекты пошли - не задачки на час-10, надо вырабатывать позицию и методы.

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

(8) Не правь свои косяки за свой счет. Продукт с косяками - это полуфабрикат, который становится продуктом постепенно, проходя через этапы тестирования, эксплуатационного тестирования и просто жизни. Иначе ты наказываешь себя за то что ты человек. Имхо

(9) Так и делаю, от и до. Но подскажите, что тут считать этапом. Я так полагаю, уже по опыту, что часто этапы- совсем мелкие могут быть (по трудозатратам, например).Текущий этап надо было сильнее декомпозировать, да. Сам ответил :)

(1) позволю себе усомниться.
ТЗ, план работ, промежуточные формы - говорит о чем то?
По тому сценарию что описан в (0) довольно просто все решается.
Легко посчитать число людей вовлеченных в процесс. Сроки реализации известны. Срок принятия этапа можно оговорить. Важно только одно, важно заручиться поддержкой у верхних эшелонов власти и у них согласовать план работ и утвердить ТЗ.
А вообще ... покури проектное управление.

(0) указываешь свой срок на твой этап, указываешь срок на этап заказчика, прописываешь, что при срыве срока заказчиком, за срыв срока начала следующего своего этапа ответственности не несешь, таким образом срок окончания твоих этапов зависит от сроков затраченных заказчиком. Твое время на этап фиксировано (абсолютное), начало и окончание этапа относительное (зависит от заказчика. При этом плановый срок выполнения заказчиком своего этапа также нужно регламентрировать.
А по хорошему нужна ответственность также и заказчика за срыв сроков его этапов.

Большую роль также играют личные качества руководителя, позволяющие ему варьировать качеством. Грубо говоря, когда выходишь из сроков, то часть работы делаешь быстро и менее качественно, объясняя что так и надо, а что не работает - это они сами виноваты

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

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

(0) Забыл написать в посте (0) "Один мой друг внедряет 1С, и у него вот такие вопросы. У друга нет компа, он попросил меня запостить".

(0) MS Project тебе в помощь ну или даже в 1С Документооборот Корп 1.2.28 есть проекты, этапы и задачи проектов, время план и факт.

Кто PM? "Представитель заказчика" входит в команду проекта?

(15) "друг внедряет 1С" и "У друга нет компа" навевают на мысли...

(0) В управлении проектом (это документ) должен быть пункт по рискам. Там ты их описываешь, и как их преодолевать.

В принципе, тут получается планирование, в ряде случаев процентов 40-60% от работ, которые планируются, но, наверное, это обязательная издержка.

(19) Погоди, он гуглит наверное ...
wiki:Управление_проектами

(0) http://consulting.1c.ru/events-view.jsp?id=90

(22) (19) Спасибо

(17) С моей стороны(исполнителя) я один, со стороны заказчика дир, назначает крайних. Сейчас, собственно, проектик не сложный, тренировочный, хочу создать и отладить у себя систему управления.

Сколько пользователей, чо за конфа?

(25) 10-15, уппшка

3 месяца не спеша, без доработок если

(27) ты даже не узнал, какие блоки ведутся в упп, какие не ведутся, какой учет, какие проблемы в учете, есть ли доработки, задачи заказчика, что он хочет. Но ты Гуру ! А я нет.

(27) Спец. По таким-то данным из (26) все определил...

(29) я сказал на стоковую программу без доработок, в чем проблема-то?

Если нужны доработки- прибавляй к этому сроку объем доработок и тестирования

получаешь время  на проект

+ написание ТЗ, если надо, это твоя предварительная оценка- кто-то пишет за 2 недели, кто-то за 2 месяца

(28) Вашу квалификацию я не оспаривал ;-)

>Если нужны доработки- прибавляй к этому сроку объем доработок и тестирования

Обычно тут пишут: "Потом умножь получившееся на 3 !!! И не забудь учесть риски !!! Вы, удаки, всегда забываете учитывать риски !!!"

(24) Система простая - есть РМ, есть команда проекта. В команду выделяются ресурсы. Если "представитель заказчика" выполняет задачи в рамках проекта, он должен официально входить в команду проекта. И часть его рабочего (или полностью) времени идет на работы по проекту. Так же, как и Ваше время. Никакой "оперативной текучки" в таком случае быть не может - обязанность "представителя" выполнить задачу по проекту есть его работа. И PM должен настучать по башке за ее невыполнение.

Естественно нужно закладывать в проект риски. Для этого нужно их оценить количественно и качественно. Для этого определяется вероятность их наступления и степень влияния на успех проекта. И рулить этим должен PM, а не ресурс проекта, которым судя по всему Вы являетесь. Методы - анализ схожих проектов, SWOT-анализ, метод Делфи, диверсионный анализ, мозговой штурм и т.п. В интернетах есть их описание. По сути они все основаны на обработке мнений экспертов.

(33)

>ТЗ, если надо, это твоя предварительная оценка- кто-то пишет за 2 недели, кто-то за 2 месяца

Тут надо чему-то привязаться !!! У меня по району висят объявы "Плазма 42 дюйма, распродажа, 20 тыщ, Эльдорадо", "Плазма 41 дюйм, распродажа, 19 тыщ, М-Видео", "Плазма 40 дюймов, распродажа, 18 тыщ, Юлмарт". Наверное, надо выбрать, какая мне нужна плазма, и пересчитать в часы на написание ТЗ.

Хотя, зачем мне плазма, напишу бесплатно.

все эти календари, описания и прочая муть написанные в ворде - это документация проекта по методу отье...сь.

последнние проекты я делаю в devprom с ипользованием бесплатного софта визуализации знаний, задач функций: FreeMind, GraphViz, VUE

гугл по этим ключевым словам вам в помощь

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

Время написания документации/календарей и прочего в традионном софте - уже абсурд.

А без визуализации с прорисовкой вороха всех бумажек в веб-приложениях - проект обречен на раппил или крах

(39) Я такую пока смотрю - MindJet MindManager, рисует майнд-мэпы и экспортирует их в требуемом виде в разное

(39) Смешались в кучу кони, люди... (с) Лермонтов

(41) Согласен, особенно мне нравится применение всех этих методов на проектах с 2-3 внешними людьми, где стоимость полноценного их применения сопоставим со стоимостью самого проекта

(40) Он еще поиск могет делать, удобненько, но платненько

(39)

вот это

>нужно закладывать в проект риски. Для этого нужно их оценить количественно и качественно. Для этого определяется вероятность их наступления и степень влияния на успех проекта. И рулить этим должен PM, а не ресурс проекта, которым судя по всему Вы являетесь. Методы - анализ схожих проектов, SWOT-анализ, метод Делфи, диверсионный анализ, мозговой штурм и т.п. В интернетах есть их описание. По сути они все основаны на обработке мнений экспертов.

интересно. Но это общие слова, как мне видится. Про "анализ схожих проектов" я написал, так и делаю, остальное с интересом погуглю.

(44) В вашем случае перечень рисков дсотаточно ограничен:

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

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

с вашей стороны:
1. недостаточная квалификация по некоторым блокам
2. Болезнь.
3. Более денежный проект
4. Не выплата аванса
5. Затягивание заказчиком сроков
6. Не приемка ответсвенными блоков описанных ( они описаны или нет)
7. Доделки по проекту

(46) Мы ща предприятие за 4 месяца запустили на УПП, 160 пользователей 10 человек запускающая команда, без базы знаний и прочего

(45) Ну да, но всегда надо предполагать развитие либо помирать, перечитываю свои вопросы на мисте годовой давности- море толковых и правильных (уже по факту) ответов, и тогда, год назад, я бы не понял этих ответов. Наверное, еще кому-то поможет :) Много умных мистян на мисте.

(44) А что Вы хотите конкретного? Чтобы вам написали "Вероятность ухода в декрет ГБ ООО "Рога и Копыта Марьи Ивановны во премя выполнения работ по проекту 50%" или "Вероятность того, что ресурс проекта менеджер ООО "Рога и копыта" Вася Пупкин уйдет в запой равна 34,5678%"?

Каждый проект уникальный по определению. Какую конкретику Вы хотите услышать?

(48) сколько там видов деятельности 1-2 или более 40, есть ли сношения с неризедентами, насколько сложно производство.

Запустить можно и за неделю, если контора просто барыжит или щьет лапти)

тоска

(51) 3 различных видов производства, 5 переделов, работа с оснасткой, планирование производства, давальцы, экспорт,все сети (50),

планирование транспорта своего, чужого, ну там блоки казначейства вообще не беру,

1500 тысячи человек народу ;-)

* 1500 человек

(53-56) 22 см. Не меньше. Но к сабжу это каким боком?

(57) Это к вопросу о том что применение методово планирования не всегда дает результат, и можно обойтись без них с малым количеством сотров вовлеченных в процесс

обычно на малом количестве людей используют свот, использовать другие методы можно, но дорого

Вопрос-то один, а обосновано ли использование методов планирования на малом количестве людей, где за результат отвечает ограниченное количество сотрудников, и для коммуникаций не тратится большое количество усилий

(58) Таки Вы утверждаете, что не планировали работы? Просто так пришли вдесятером, чего-то там поковырялись и вдруг все взлетело?

(61) планировали конечно же ;-), но не  работы, а блоки, и в процессе выполнения проекта решали до что недозапланировали ;-).

Состав проекта был такой после 3-х дневного обследования
1. Обучение
2. подготовка запуска производства -
3. Подготовка запуска продаж
4. Поехали ;-)

Тока к концу января появился осмысленный план ввода новых разработок, ща уже проект закончился ;-)

Так конечно нельзя делать, и рисков там было куча, и Ит директор начал в январе съезжать с договоренностей

(62) Уровень детализации плана не суть важен. Хоть блоком, хоть по секундам расписывайте. Но планирование оказывается все таки было.

Но даже тут у меня сомнения. Для примера "Обучение" - Вы не определяли кто будет учить, когда, по какой программе, какой состав учебных групп, не определяли график обучения? Вот так вдруг все взяли, и обучились? Блоком?

(65) Будете смеятся ;-) но доходило до абсурдного, мы просто заходили к начальнику подразделения, обговаривали список группы и сразу шли в бой

были известны только блоки которые надо запустить, ну и полностью описание бизнес процессов, на сколько их можно было собрать за 3 дня

Но бесспорно укрупненное планирование по блокам конечно же было

(66) Все вдесятером одновременно? Или каждый приходил с интервалом в один день и давай предлагать всех учить?

(69) Ну давайте уж до маразма не доводить, были ответсвенные по блокам

Хотя бывали случаи что мы пересекались

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

А то "да оно само все срослось без всякого плана" :))