С деньгами на таких проектах в госзаказе обычно просто — есть потолок, и в этот потолок нужно влезть.
А дальше все зависит от твоих умений, навыков, и если ты крут — сделаешь в "+" себе, если нет — сделаешь в "-".
Дальше — проект (реализация госзаказа) считается успешным, если ты сможешь заявить успешный опыт реализации в других тендерах (в качестве квалификации), если же нет — будут наложены штрафные санкции и об этом узнает общественность. Пени накладываются как по качеству, так и по срокам реализации. Финансовая ответсвенность — это не только пени, так еще риск попасть в неблагонадежные поставщики согласно законодательству.
Путем нехитрых умозаключений (с помощью дедукции) можно сделать вывод что систематическая реализация крупных проектов — признак успеха. =)
Если же хочется видеть числа сравнений — то сравнений не получиться, ибо два раза один проект не сделать.
Разговоры не от бизнеса, а от эксперта в проектном управлении =) и разговоры на тему проектного управления.
Таким образом эксперт рассказывает о том, в чем он разбирается. Если пойти глубже, эксперт=наемный рабочий, и это строго экспертная статья носящая общеобразовательный характер, раскрывающий глаза тем, кто не знает какие есть подходы и практики, что существует кроме agile, scrum и pmbok =)
При этом эксперт применяет не строго данный подход, а использует микс известных практик и методик.
Ну, из того, что на слуху с эффектом «ВАУ»:
— Участие в запуске космодрома Восточный
— Автоматизация стадионов Спартак и Лужники к чемпионату мира
— Создание всероссийской системы госзакупок (http://zakupki.gov.ru/epz/main/public/home.html)
— Создание всероссийской системы жилищно-коммунального хозяйства (https://dom.gosuslugi.ru)
А личный опыт сотрудников (управленцев), и меня в том числе – не менее объемный и социально-значимый.
Если же тебе интересно узнать, как работа строилась у Торвальдса или Джобса — можно почитать не только их ;) но и их окружение, людей, которые с ними работали.
1. Где фиксируются задачи участников проекта и отслеживается их статус?
задачи фиксируется в трекере, будь то Jira, Redmine или трелло. В MM хранятся их тайтлы, и ссылки на них. Статус изменяется по ходу работы с трекерами, руками. Вся работа по задачам ведется в трекере.
Где посмотреть список всех задач с актуальными статусами по проекту? Приходится работать с одним списком задач и в трекере и в ММ?
список задач один, в трекере он может быть более широкий, в ММ фиксируются корневые задачи или групповые. Если тема небольшая, то может фиксироваться и единичная задача трекера.
2. Где ведете актуальный план проекта?
MS Project
Из статьи кажется, что задачи со сроками и часами ведете в ММ.
я просто продемонстрировал его возможности =), может кому-то будет удобней классических инструментов.
Неужели это удобнее чем project?
для меня наиболее удобный — MS Project, уже более 10 лет)
Сам использую ММ в управлении проектами:
1. WBS. MM единственный нормальный инструмент, чтобы быстро нарисовать структуру работ и внятно её кому-то показать. Использую XMind с его возможностью рисовать MM по вертикали.
А еще на базе этого WBS можно подготовить шаблон ТЗ в коммерческих проектах.
2. Описание продукта проекта или предметной области. Сам план работ и задачи в ММ не веду, но как карту требований использую, чтобы не переживать, что ничего не упустили.
я бы отметил в этом главное не только полнота требований, но и их взаимосвязь, о которой, порой, мало кто задумывается.
Про совместное использование — при наличии «просвещенных» специалистов по Майнду — вполне рабочий вариант. Но в таком случае я порекомендую интеграцию карт, в главную карту встраивать карты, подготовленные вашими обособленными командами. Иначе может рано или поздно возникнуть вопрос «я этого не делал, кто внес изменения?». Который легко решается при разграничении ответственности на проекте и в рамках отдельных карт.
Межинструментные интеграции, особенно с MSP, всегда были сомнительного качества у смежных с «офисом» продуктов. Но тут скажу, что проблем за последние пару версий поубавилось, да и MSP подрос и похорошел по сравнению с MSP10.
Я предлагаю в Майнде ставить задачам параметры, такие как срок исполнения и трудоемкость, и потом по ним уже фильтровать, или смотреть в альтернативных представлениях (например с расположением задач по календарю).
Для разделения типа задач — предлагаю использовать разную раскраску элементов (например, рабочие — розовые, а семейные — зеленые, профессиональные — синие), таким образом при наложении карты на другое представление всегда будет понятен тип задачи и сфера её применения.
Мобильными клиентами не пользуюсь только по той причине, что у меня есть ноут под рукой в ходе рабочего дня. Хотя конечно же мобильные клиенты доступны и в Apple store и Google Play.
Трелло… это любовь с первого клика =) Он показал себя очень и очень удобным инструментом, особенно для визуализации процесса разработки для Клиента
Майнд же использую для своих личных внутрипроектных целей, не публичных.
Мне кажется, нужно просто встретиться и рассказать личные истории успеха, =)
Весь мир живет в проектном управлении и оно преобразуется под нужды трудящихся, основная цель сделать то, что еще никто до тебя не делал в рамках определенных ограничений.
Вопрос оплаты — это вопрос вторичный. Приведенный вами пример — пример не из проектной деятельности. Подходы Форда верные, но они в операционке — не забывайте.
Есть замечательные специалист которые на своем опыте могут вам рассказать что такое проектный подход и как его внедрять, крайне советую. Но как минимум — ознакомьтесь с книгами, которые я порекомендовал. А потом, предлагаю обсудить =)
А дальше все зависит от твоих умений, навыков, и если ты крут — сделаешь в "+" себе, если нет — сделаешь в "-".
Дальше — проект (реализация госзаказа) считается успешным, если ты сможешь заявить успешный опыт реализации в других тендерах (в качестве квалификации), если же нет — будут наложены штрафные санкции и об этом узнает общественность. Пени накладываются как по качеству, так и по срокам реализации. Финансовая ответсвенность — это не только пени, так еще риск попасть в неблагонадежные поставщики согласно законодательству.
Путем нехитрых умозаключений (с помощью дедукции) можно сделать вывод что систематическая реализация крупных проектов — признак успеха. =)
Если же хочется видеть числа сравнений — то сравнений не получиться, ибо два раза один проект не сделать.
Мало кто рассказывает про них, рассказывают обычно проекцию их результата на успешные проекты.
Так Брендсон говорит про свой проект Student и его влияние на Virgin
Таким образом эксперт рассказывает о том, в чем он разбирается. Если пойти глубже, эксперт=наемный рабочий, и это строго экспертная статья носящая общеобразовательный характер, раскрывающий глаза тем, кто не знает какие есть подходы и практики, что существует кроме agile, scrum и pmbok =)
При этом эксперт применяет не строго данный подход, а использует микс известных практик и методик.
Как это интересно говорить о себе в третьем лице)
— Участие в запуске космодрома Восточный
— Автоматизация стадионов Спартак и Лужники к чемпионату мира
— Создание всероссийской системы госзакупок (http://zakupki.gov.ru/epz/main/public/home.html)
— Создание всероссийской системы жилищно-коммунального хозяйства (https://dom.gosuslugi.ru)
А личный опыт сотрудников (управленцев), и меня в том числе – не менее объемный и социально-значимый.
Если же тебе интересно узнать, как работа строилась у Торвальдса или Джобса — можно почитать не только их ;) но и их окружение, людей, которые с ними работали.
задачи фиксируется в трекере, будь то Jira, Redmine или трелло. В MM хранятся их тайтлы, и ссылки на них. Статус изменяется по ходу работы с трекерами, руками. Вся работа по задачам ведется в трекере.
список задач один, в трекере он может быть более широкий, в ММ фиксируются корневые задачи или групповые. Если тема небольшая, то может фиксироваться и единичная задача трекера.
MS Project
я просто продемонстрировал его возможности =), может кому-то будет удобней классических инструментов.
для меня наиболее удобный — MS Project, уже более 10 лет)
Сам использую ММ в управлении проектами:
А еще на базе этого WBS можно подготовить шаблон ТЗ в коммерческих проектах.
я бы отметил в этом главное не только полнота требований, но и их взаимосвязь, о которой, порой, мало кто задумывается.
Для разделения типа задач — предлагаю использовать разную раскраску элементов (например, рабочие — розовые, а семейные — зеленые, профессиональные — синие), таким образом при наложении карты на другое представление всегда будет понятен тип задачи и сфера её применения.
Майнд же использую для своих личных внутрипроектных целей, не публичных.
Весь мир живет в проектном управлении и оно преобразуется под нужды трудящихся, основная цель сделать то, что еще никто до тебя не делал в рамках определенных ограничений.
Вопрос оплаты — это вопрос вторичный. Приведенный вами пример — пример не из проектной деятельности. Подходы Форда верные, но они в операционке — не забывайте.
Есть замечательные специалист которые на своем опыте могут вам рассказать что такое проектный подход и как его внедрять, крайне советую. Но как минимум — ознакомьтесь с книгами, которые я порекомендовал. А потом, предлагаю обсудить =)