gifts2017

Как управлять проектами внедрения 1С Предприятие? Обзор инструментов...

Опубликовал в раздел Управление - Управление проектом

Все знают то, что для успешного завершения проекта, нужно им управлять, но вот как это делать? Какие инструменты использовать и в каких случаях какие технологии уместны, а какие нет? Делаем работу над ошибками...

 

С1. Введение

  1. Все знают то, что для успешного завершения проекта, нужно им управлять, но вот как это делать? Какие инструменты использовать и в каких случаях какие технологии уместны, а какие нет?
  2. В одном случае инструмент может быть полезен, в другом вреден;
  3. В данной статье рассмотрим возможные варианты технологий и ситуации их применения;

С2. Понеслася!

  1. Техника «Описание проекта» или «Отчет по проекту»
    1. Это основная техника, которая нужна практически в любых проектах.
    2. Можно использовать документ Word, Google Docs, или любой другой носитель, который можно периодически обновлять. Я когда-то использовал Word+DIRECTUM, сейчас использую Мегаплан. Там есть соответствующее поле у записей проектов;
    3. Состав описания зависит от размера проекта и ситуации
      1. Обязательные части
        1. Результат (куда идем, и как выглядит ситуация в которой мы должны оказаться в конце проекта)
        2. Цель (зачем идем, можно в общих выражениях аля «чтобы мир во всем мире», хотя чем конкретней, тем лучше, например, «повышение качества услуг» или «увеличение доходов» или «снижение операционных затрат»);
      2. Дополнительные части добавляем по ситуации
        1. Участники (контакты, роли …)
        2. Заметки
        3. Ссылки на важные материалы
        4. Любые другие разделы по желанию
    4. Материалы по теме
      1. Волшебное искусство планирования (там, где описание с чего начинается план)
      2. http://ru.wikipedia.org/wiki/GTD (надо читать саму книгу конечно, там по сути тоже речь о том что план начинается с описания результата, и дана хорошая техника того, как именно надо описывать результат)
  2. Умение мыслить в стиле ВИСИ
    1. Кто не в теме, читаем описание техники «Будьте ВИСИ»
    2. Это также одна из наиважнейших техник, которая требуется на любом проекте.
    3. Но не все способны ее освоить, т.к. требуется природная предрасположенность к этому стилю мышления.
  3. GTD
    1. Это название техники и книги Д.Алиена
    2. Гибкая и универсальная техника, подходящая для управления проектами лучше, чем что либо изученное мной ранее (а изучил много чего). Не зависит от платформы, можно хоть на бумаге применять.
    3. Кроме результатов, позволяет снизить напряжение на мозг и бомбежку воображения.
    4. В общем если задач у вас стало очень много, вы начали путать маму с папой или дочку с сыном, то вам срочно нужна эта книга. А лучше не доводить до этого состояния и освоить эту технику заранее.
  4. Реестр проектов
    1. Это просто ведение списка проектов, с приоритетом, плановыми датой начала, датой окончания, описанием, фактическими датами и конечно же с указанием ответственного.
    2. Помогает в том случае, если проектов много, их нужно, во-первых, раскидать между людьми, во вторых по себе любимому видеть приоритеты (дабы не распылять силы), ну и просто эти данные иногда полезны при использовании дополнительных инструментов.
    3. Эта техника бесполезна в том случае если у вас 1-2-3 проекта, и/или вы один в поле воин.
    4. Чтобы понять смысл этой техники нужно, во-первых, изучить книгу GTD, а во-вторых, иметь соответствующий опыт.
  5. Ведение списка задач в проектах
    1. Тут нужно сразу остановиться на ключевых элементах
      1. Доступ к списку нужен всем участникам, которые могут быть в разных организациях и раскиданы по территории. Да и просто бывает, что идея догонится вас дома и надо сразу привязать ее к контексту, чтобы мозг не нагружать.
      2. Тут же нужны обсуждения.
      3. Учет времени.
      4. Контроль сроков, состояния задач, ответственных.
    2. Пару месяцев назад начал искать подходящий инструмент и остановился на 2-х:
      1. Мегаплан
        1. Продуман, прост, удобен, дизайн от Артемия Лебедева;
        2. Соответствует техникам ВИСИ (п.2) и GTD (п.3)
        3. Стоит копейки, если брать под задачи и проекты.
        4. Чисто отечественный продукт;
        5. Прочий функционал стоит уже дороже, но лично мне он нафиг не нужен, он у меня на других платформах реализован.
        6. Поддержка мобильников в планах
        7. Мой выбор из-за п.1 и 2.
      2. Тимлаб
        1. Сложноват, интерфейс далек от эргономики
        2. Соответствует технике GTD (п.3), но не поддерживает ВИСИ (п.2).
        3. Бесплатен, как следствие заметны тормоза
        4. Есть поддержка русского языка
        5. Функционал зашкаливает, тут вам и WiKi и Jabber и много чего еще
        6. Есть поддержка мобильников
        7. Простота в использовании и соответствие ВИСИ для меня слишком важны, и даже важнее халявы, потому Тимлаб оставил в сторонке, но слежу за обновлениями, и когда они реализуют поддержку ВИСИ, то может быть даже перейду на него.
    3. Конечно все это нужно лишь там где проекты ресурсоемкие и долгоиграющие. Примерно от 2-х месяцев. Там где меньше, можно использовать п.4 (просто вести реестр проектов)
  6. Отчет по проекту
    1. Тут конечно на любителя, но я не даром назвал эту технику ключевой в своей прошлой статье…  1С Предприятие. 4 ключевые проблемы проектов внедрения
    1. Если соотносить ее с вышеназванными техниками, то:
      1. она объединяет в себе все основные элементы перечисленных выше технологий;
      2. ее можно применять зная обычный Word совершенно в полевых условиях и с деревянными людьми (кому тот же Мегаплан или эл.почту не освоить за все время проекта).
      3. да и просто ее освоить легко;
    2. У нее нет ограничений по масштабу… как минимум у меня лично есть проект в 7 чел/лет, с командой из 10 спецов и создание системы на 1000 пользователей, только лишь при использовании этой техники. Проект, которому все эксперты пророчили гибель, т.к. там были нарушены все базовые принципы проектного подхода. Но проект удалось вырулить, хоть и ценой отказа от личной жизни и урезанием премии всей команде из-за минусовой рентабельности.
  7. ТЗ
    1. Самое главное это отличать ТЗ на программирование и ТЗ на внедрение.
    2. Это две совершенно разные задачи, мешанина которых приводит к провалу.
    3. В ТЗ на внедрение нужно ставить запрет на разработку и закреплять перечень процессов которые будут охвачены.
    4. А на все разработки, если без них ну ваще никак, выносить в ТЗ на разработку, где уже прописывать все требуемые алгоритмы и условия.
    5. Вообще стиль и состав ТЗ на внедрение пока что передается лишь между внедренцами. Мне его передали уважаемые люди умеющие реализовывать крупные проекты, я этот стиль передавал своим ребятам. ГОСТ есть только на ТЗ для программирования. Особенности описания ТЗ на внедрение надо как то будет сесть и попробовать выразить словами ) Хотя сам навык придет лишь с опытом в любом случае.
  8. Устав проекта
    1. Спорный документ, использование которого нужно лишь с пониманием
    2. Вообще многие вещи, которые обычно пишут в Уставе, лучше сразу прописывать в ТЗ на внедрение (не путать с ТЗ на программирование)
    3. Но бывает так, что ТЗ уже написано, и вам его дают как данность. А в команде проекта куча быдла, без таких понятий как отвага и энтузиазм. Умеющих лишь свои должностные обязанности выполнять и то спустя рукава. Тут можно прописать п. Мотивация, с бонусами и штрафами. Тогда даже из быдла можно сделать людей прямо во время проекта.
    4. Или люди начинают от ответственности уходить, вилять… тогда можно п. Ответственность добавить и там записать все.
    5. Или в ТЗ забыли результат, цели и структуру задач описать. Тоже в целях вытаскивания проекта из жопы - это можно в Устав закинуть.
    6. Если видишь, что в проект залезла куча идеологов, со своими видениями правильности решения задач, просто в устав добавляешь нужные нормы, обосновываешь верхам, согласовываешь, утверждаешь. Дальше, если видишь что та или иная идея, действие нарушают или грозят нарушить норму и увести проект в жопу, то берешь идеолога, тыкаешь его носом в норму устава, и посылаешь на три буквы.
    7. В общем, Устав - это такой документ, который нужен как антикризисный инструмент, решения ошибок которые были допущены при постановке задачи в ТЗ или обнаруженных проблемах уже в ходе проекта. Хотя если проект знакомый и в ТЗ все риски предусмотрены точной постановкой задачи, то от Устава можно отказаться.
  9. Программно-портфельные технологии из PM BOK
    1. Нужны когда вы начинаете отвечать не просто за какие то проекты, а за целые направления в крупных организациях и нужно свести все проекты в управляемую ситуацию;
    2. Основная ошибка в России это опять же усложнения. Взять тех же чиновников и ФЦП Электронная Россия или ФЦП Информационное общество.
    3. Ошибка в том что они употребляют слово Программа, но мало кто из чиновников понимает суть этого слова.
    4. Взять ту же Европу, там аналогичные программы называются просто «План действий «Е-Правительство 2011-2015″. И описаны очень простым и доходчивым языком, а как известно чем больше людей участвуют в задаче, тем проще нужно объяснять ключевые элементы деятельности.

С3. Резюме

  1. Сразу оговорюсь, что это мое ИМХО основное на эмпирическом знании. Ни один ученый сидящий в каком нибудь НИИ не является для меня авторитетом. Единственные кого я слушаю это людей с практическим опытом.
  2. Если вы точно знаете как управлять проектами, хотя не один проект в своей жизни еще не реализовали, то рекомендуется свои мысли оставить при себе, даже если вы отвечали за целый этап внутри проекта. Этап это не проект.
  3. Под проектами понимается действие, со сроком и бюджетом. Выполнено в срок и в бюджет. Тепличные условия когда кучка программистов сидят и размышляют о правильности решения без ограничения срока и бюджета… проектом как мы знаем можно назвать лишь с натяжкой. Это просто игра в проект. Хотя часть описанных технологий конечно же пригодятся и в этом случае.
  4. Основная полезность этих техник пригодится тем у кого есть задача, ресурсоемкая, сложная, с участниками от 3-х человек, где нужно не просто ковырять компьютеры и программы, а нужно еще охватывать и направлять множество людей (пользователей, сотрудников), при этом сверху на вас давит срок и бюджет,  и кровь из носу нужно сделать результат, уложившись в ограничения. Вот где вся веселуха!

(c) http://itau.ru/2011/05/19/kak-upravlyat-proektami-sozdaniya-informatsionnyih-sistem-obzor-instrumentov/

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Александр Рытов (Арчибальд) 21.03.11 08:11
Возьмеь несколько цитат
Ключевая проблема в том что внедрением занимаются программисты. Хотя это задача управленческая.
(4 ключевые проблемы проектов внедрения 1С Предприятие )
Программист может не быть руководителем проекта, если программистов на проекте несколько. Руководитель проекта не может не быть программистом.

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

Пробежимся еще по этой статье. С описанием проекта - понятно, что без грамотного целеполагания (в том числе, ограничения перечня задач) тольку не будет. А вот следующий раздел - поподробнее:
2. Умение мыслить в стиле ВИСИ
1. Кто не в теме, читаем описание техники "Будьте ВИСИ"
2. Это также одна из наиважнейших техник, которая требуется на любом проекте.
3. Но не все способны ее осовоить, т.к. требуется природная предрасположенность к этому стилю мышления.
Отличная иллюстрация к моей позиции в двух предыдущих обсуждениях. Ведь "Взаимное Исключение, Совместное Исчерпание" - это именно тот стиль мышления, который в фольклоре соотносится с профессиональными программистами. Ну, как на ночь на тумбочку поставить не только полный стакан, но и пустой. Я же утверждаю, что стиль мышления ВИСИ - основное, что отличает программистов от непрограммистов (к коим и конфигурасты относятся). Третий же пункт в последней цитате говорит, что не всякому дана способность стать программистом. И руководителем проекта заодно.

2. Юрий Щербаков (ufo58) 21.03.11 08:54
Говорят: "Дурак видит дурака, умный - умного, мудрец видит и тех и других".
Отчего статья (читай автор) такая напыщенная и злая?
Тебя кто так обидел?
Пользователи? Программисты? "Местные специалисты", которые так и "не сумели понять и осознать суть статьи"?
Не мудрено.
Такое ощущение, что копаешься в помоях чужих амбиций.
Найти в этом опусе "песчинку рационального зерна" крайне сложно.
Посмотрю в ссылках. Может там больше толку.
Трактор; slaviksoft; +2 Ответить
3. Игорь Исхаков (Ish_2) 21.03.11 08:56
Есть еще одна техника. Сам ее не использовал, потому за качество не отвечаю. Суть ее в том, что нужно выкинуть руководителя проекта, а всем программистам начать бить себя в грудь и кричать "я программист!"... тем самым по заверению в статье "Руководитель проекта - это не профессия. Надо еще работать." и в комментариях к ней, проект должен завершиться успешно. Я так не пробовал, но люди утверждают что это работает, потому спорить не буду. Вероятно это какой то древний шаманский ритуал.


Явное передергивание и искажение смысла статьи bb1962 :
http://infostart.ru/public/82673/
4. Михаил Ражиков (tango) 21.03.11 09:14
- за снобизм. и эзотеричность "ответственности"
**
ну че бы сразу ни сказать, что "ответственность" имелась ввиду по Хаббарду?
смени форум, Толик, 1снегов зомбировать - дело неблагодарное
5. Игорь Исхаков (Ish_2) 21.03.11 09:29
Самое главное это отличать ТЗ на программирование и ТЗ на внедрение.
Это две совершенно разные задачи, мешанина которых приводит к провалу.
В ТЗ на внедрение нужно ставить запрет на разработку и закреплять перечень процессов которые будут охвачены.
А на все разработки, если без них ну ваще никак, выносить в ТЗ на разработку, где уже прописывать все требуемые алгоритмы и условия
.

Если Вы внедряете продукт "в чистом поле" и пользователи вручную вводят начальные данные , то тогда приведенную цитату можно как-то принять.
Но в подавляющем числе случаев внедрение есть есть переход от одного продукта к другому.
И тогда в подавляющем числе случаев без ТЗ на программирование (переброска данных из одного пакета в другой) -"ваще никак". Удачность и полнота такой переброски во многом определит успешность всего проекта.
Мало того , такая переброска может потребовать создания и хранения в новом продукте дополнительных структур.
Т.е. невозможно отмахнуться от простого факта : ТЗ на программирование в подавляющем большинстве случаев есть не какое-то дополнение , а неотъемлемая часть ТЗ на внедрение.
А раз так , то искусственное разделение ТЗ на программирование и ТЗ на внедрение в общем случае - серьезная методологическая ошибка.
6. Михаил Ражиков (tango) 21.03.11 10:21
(0) Толик, брыздни позитивом: какие проекты в Увартском районе?
Прикрепленные файлы:
7. Михаил Ражиков (tango) 21.03.11 10:36
резюме
Прикрепленные файлы:
Трактор; +1 Ответить
8. Трактор Трактор (Трактор) 21.03.11 10:42
Мегаплан
1. Продуман, прост, удобен, дизайн от Артемия Лебедева;

Дизайн Лебедева это офигеть какой плюс! Как люди без него жили? Функционал при таком дизайне не так важен.

В заголовке сказано Обзор инструментов... Собственно обзор на 17 строках текста. Причём в 7 из них не более трёх слов.

У автора явно страдает логика. Нет того самого ВИСИ, призывающего структурировать мысли и отделять мух от котлет.
Минус пока не ставлю. Надеюсь на исправление.
9. A AShley (AShley) 21.03.11 10:48
(5) А мне кажется, что наоборот нужно отделять этап программирования (где идет тестирование процесса внедрения, доработка функционала и т.п.), от самого этапа внедрения, иначе мы получаем внедрение, которое не заканчивается, с кучей косяков, заплатками "лишь бы работало" и грязным кодом. Из личного опыта: внедрялась 1С:Бухгалтерия предприятия (прогибание клиента под "правильное" решение это отдельный вопрос) в строительной организации (группа компаний) с одновременным допиливанием управленческого учета, механизма распределенных баз и т.п. Проект затянулся более чем на 2 года.
10. Ярослав Тарарака (slaviksoft) 21.03.11 10:54
статья интересная, но с такими эмоциями автора читать неприятно
интересно он с клиентами тоже так обиженно себя ведет?
11. Игорь Исхаков (Ish_2) 21.03.11 10:59
(9) В (5) приведен конкретный пример когда ТЗ на программирование - неотъемлемая часть ТЗ на Внедрение (переброска начальных данных). Сказано о том , что таких случаев большинство.
Поэтому (внимание!) в общем случае неверно искусственно разделять ТЗ на внедрение и ТЗ на программирование.
С другой стороны , если это возможно, доработка функционала должна быть выделена в отдельное ТЗ на программирование.
12. Anatolii Karasev (KapasMordorov) 21.03.11 11:02
Какие клиенты?
Автор "руководитель проектов" в районной администрации в селе Уват (5000 чел. население, в районе 20 тыр).
Чиновник, 26 лет.
13. Игорь Исхаков (Ish_2) 21.03.11 11:08
(12) Не Москва. Ну и что ?
Арчибальд , скажем так , - не столичный житель. А уровень оч. высокий.
Так что поаккуратнее...
14. Anatolii Karasev (KapasMordorov) 21.03.11 11:15
(13)
Не Москва. Ничего.
Бывшие коллеги большой-большой проект в Тюмени делали.
Только есть несоответствие между статьями автора и например его же блогом.
15. Ирина Пятакова (Alraune) 21.03.11 11:25
Самое главное это отличать ТЗ на программирование и ТЗ на внедрение.
Это две совершенно разные задачи, мешанина которых приводит к провалу


Мне почему-то кажется, что это обусловлено тем, что программированием и внедрением, как правило, должны заниматься в рамках проекта разные люди (если, конечно, более-менее крупный проект, сопровождающийся работой с большим количеством пользователей). Потому что из хороших программистов очень часто бывают никакие «внедренцы» (дурацкое слово, но другого в голову не приходит), и также наоборот. Программист пытается объяснить пользователю что-то в своих терминах, пользователь ничего не может понять и сидит с выпученными от ужаса глазами. Это не предположение, встречалось такое, и не раз. А пользователь не должен бояться программу, иначе внедрение нисколько не будет успешным.
16. Василий Казьмин (awk) 21.03.11 11:26
(8) Допиливать конечно, можно и нужно. Но идея показать работу РП с точки зрения РП, а не с точки зрения исполнителя - замечательная. А то многие считают, что начальство в носу ковыряется - за то и деньги получает. А что это колоссальный труд, который требует специфических знаний и качеств - мало кто понимает.
17. Михаил Ражиков (tango) 21.03.11 11:34
(16) "мало кто понимает"
ну вот блин откуда это взяли? источник только один - "все программисты тупые"
18. Василий Казьмин (awk) 21.03.11 11:44
(17) Все программисты - разные. Тупые то же есть.
19. Игорь Исхаков (Ish_2) 21.03.11 11:49
(16) Я бы тоже отметил эту замечательность статей A.Y, несмотря на перехлесты.
Оч. и оч. полезно программистам, коих здесь большинство, увидеть взгляд "извне".
20. Трактор Трактор (Трактор) 21.03.11 11:49
Перечитал статью ещё раз. Она совершенно бесполезна. Каждая из затронутых тем требует отдельной статьи.

В статье затронуты темы:
1. Спор с людьми, имеющими другое мнение по вопросу управления проектами. Этому посвящены разделы С1 и С3. Зачем это здесь - непонятно. Собачиться можно в форуме. Он для этого и предназначен.
2. Перечень необходимых по мнению автора документов по проекту. Причём автор говорит о больших проектах и при этом считает необязательным устав проекта, что весьма странно. Не описаны документы по закрытию этапов проекта без чего ИТ проект рискует быть завершённым никогда.
3. Перечисление различных техник. Без ссылок, описания и сравнения. Ненадо перечислять многое. Достаточно одного работоспособного подхода. Или надо писать отдельную статью по сравнению различных техник и описание возможностей их совместного применения.
4. Собственно инструмента приведено лишь два. Даже без ссылок, что, на мой взгляд, является очень плохим тоном написания статей.


Нумерация пунктов в статье не несёт смысла. Например в разделе С2 подпункты пункта 9 являются просто пронумерованными предложениями одного абзаца. Зачем так писать?

Думаю что автор честно заслужил минус.
suggestive; Lara.Builova; +2 Ответить 1
21. MaxDavid (MaxDavid) 21.03.11 11:52
Точка зрения руководителя:
Есть еще одна техника. Сам ее не использовал, потому за качество не отвечаю. Суть ее в том, что нужно выкинуть руководителя проекта, а всем программистам начать бить себя в грудь и кричать "я программист!"... тем самым по заверению в статье "Руководитель проекта - это не профессия. Надо еще работать." и в комментариях к ней, проект должен завершиться успешно.

Точка зрения программиста:
Есть еще одна техника. Сам ее не использовал, потому за качество не отвечаю. Суть ее в том, что руководителю нужно прочитать множество мантр типа "Getting Things Done!" "ВИСИ!", а также научиться отличать Мегаплан от Тимлаба, тем самым, по заверению статьи "Как управлять проектами внедрения 1С Предприятие? Обзор инструментов...", проект должен завершиться успешно.

Истина, как водится, где-то посередине...
22. Василий Казьмин (awk) 21.03.11 12:39
(20) Тема в статье настолько обширна, что вряд ли ее может потянуть один человек. Тут нужна коллективная работа.
23. Трактор Трактор (Трактор) 21.03.11 12:44
(22) Это не оправдывает беспочвенные наезды. А нелогичность и небрежность оформления делает статью вовсе бесполезной. В заголовке заявлен обзор инструментов. Обзор никакой. Вообще никакой.
24. Василий Казьмин (awk) 21.03.11 12:51
(23) Да, с инструментами в статье "бяда". Мне на вскидку из инструментария управления проектами приходят: MS Project, Trac, Redmine, OpenProj, Planner, eGroupWare.
25. A.Y 22.03.11 07:11
(24)
ну во-первых я же не подписывался за то что щас буду обзор всех делать )
я лишь сделал обзор тех что знаю и тех что считаю полезными.
мой опыт использования MS Project говорит о его бесполезности для проекта.
хотя у меня есть один проект где он мне помог частично, правда если бы на то время был тот же Мегаплан и я бы знал GTD, тоооо думаю результаты были бы красивше, а затраты меньше )
да и изучал я на много больше инструментов, тот же StreamWork, Manymoon ... Но тратить время на их описание не стал, т.к. Мегаплан и Тимлаб мне понравились больше и показались наиболее интересными. Кому хочется большой обзор тут или не ко мне или ко мне но за дорого )

(all) всем остальным спасибо за критику )

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

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

продолжайте ... ))
26. A.Y 22.03.11 07:38
(1) Арчибальд! Негодяй! Ты меня поймал! )))
Без шуток ) Тот образ который ты видишь под словом программист я очень уважаю ) У меня есть 3 таких друга программиста и мы друг друга понимаем с полу слова ) Хотя и с ними бывает деремся )) но без обид и с пониманием ))
проблема называется: мы говорим одни слова на этом свете но видим разное кино ) (с) Полонский

Я же под этим словом понимаю среднестатистического специалиста, от которых в проектах одни проблемы и которых опять же большинство )

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

Потому что если рассматривать все возможные случае которые только мне встречались, без учета тех что еще повстречаются, то статья получится большой и скучной ))
27. Александр Рытов (Арчибальд) 22.03.11 07:40
28. Михаил Ражиков (tango) 22.03.11 07:55
"среднестатистического специалиста ... которых большинство"
не, блин, я как бы все понял, но не до такой же степени....
пс:
а не дох программистов в Увартовске?
29. Lara.Builova 22.03.11 12:13
"Как управлять проектами внедрения 1С Предприятие? Обзор инструментов..."
Правильнее было бы назвать статью так "управление исполнением проекта"
Приложу, пожалуй, кое-что, что действительно можно назвать управлением проекта , может быть кому-то и пригодится.
Прикрепленные файлы:
PMBOK_3_shpora.doc
Spartan; awk; Трактор; lustin; +4 Ответить 1
30. Михаил Ражиков (tango) 22.03.11 14:16
честность - здесь не очень хороший перевод интегрити
Information integrity Способность средства вычислительной техники или автоматизированной системы обеспечивать неизменность информации в условиях случайного и (или) преднамеренного искажения (разрушения)

Профессиональный кодекс РМР <> личная честность ПМ
Прикрепленные файлы:
Сравнение инструментов.xls
Spartan; lustin; +2 Ответить
31. A.Y 22.03.11 17:20
(29) Лара, в этой шпаргалке 12 основных пунктов, в среднем по 5 подпунктов в каждой. Итого около 60 норм.
Положа руку на сердце - вы видели в среде ИТ проект, соответствующий хотя бы половине из указанных норм?

А теперь давайте разбирать мысли )
1. Я тут один в курсе что PM BOK долгое время в среде ИТ не приживался да и сейчас мало кто может похвастать его знанием? Он больше ценился в тяжелых отраслях типа строительства... Конечно я могу ошибаться... т.к. изучал эти буквари уже давно )
1.1. В ИТ PM BOK меняли на Agile или тот же SureStep.
1.2. Если не ошибаюсь, его популярность в среде ИТ подросла лишь с 3-й версии, когда они сделали нормы более демократичными и гибкими.

2. В целом стандарт хороший, его можно почитать и подчерпнуть от туда полезные элементы...
2.1. Но попробуйте применить хотя бы половину того что написано пусть даже в этой шпаргалке... и посмотрите что получится с теми ИТшниками кому придется это все выполнять ) ну и с теми ИТ-проектами ))
2.2. Люди пытаются с разбегу применять эти толмуды... а потом удивляются тому что это нифига не приживается в жизни. Начинают обзываться и жаловаться на отечественный менталитет - аля "что русскому хорошо то немцу смерть".
Вообще я не против этого стандарта... я против поклонения ему и демогогий на тему "во как нада жить!"
Чтобы была польза от этого стандарта или любого другого, нужно научиться применять то что там написано.
А для этого нужно понимать что первично, а что вторично. Поклонением этим стандартам съедает все внимание человека на вторичных элементах.
Потому любители демогогий могут и дальше верить в PM BOK. А кто хочет результатов без лишней мути, попробуйте для начала освоить те пункты что описаны у меня в статье.

3. Да, и в GTD автор мягко намекнул на то что технологии типа PM BOK это сборник рецептов от теоретиков, который нифига не совпадает с жизнью.
3.1. И подход GTD как технология управления проектами мне нравится больше, она проще и легче в освоении, сосредоточена на конкретных первичных элементах.
3.2. Но рецепты PM BOK все же изучил, т.к. в них содержится мудрость поколений ) И там есть вторичные элементы которые нужно знать, особенно во внешних проектах когда есть финансовые документы и юридические обязательства. Но это все вторичные элементы. Их изучение должно идти после освоения первичных навыков, т.к. GTD или ВИСИ.

Поверьте, заказчику, тому кто платит деньги за проект... важен результат... ему начихать на то умеете вы проектные документы стряпать красиво или нет. Если будет отличный результат, сам заказчик вам сам оформит все бумажки, лижбы вам было тепло и уютно, а любые ошибки во вторичных элементах будут не то чтобы прощены, они вообще будут не замечены. А вот если вы начнете валить проект, то не важно красиво вы оформите документы или нет. Будете вы знать красивые слова из PM BOK или нет. Заказчик будет нервничать и эти нервы дорого обойдутся. Тогда держитесь... придирки будут по всем мелочам. Тогда конечно же пригодятся не только знания PM BOK, а еще желательно обзавестись юридическими знаниями ГК РФ, т.к. спор будет жарким )
32. Александр Рытов (Арчибальд) 22.03.11 17:30
Вообще говоря, большинство западных технологий имеют перекос в сторону "хорошо выглядеть" по объективным причинам - исходя из источников финансирования (необходимости привлечения инвесторов). У нас же решения о финансировании в основном принимаются путем лоббирования, а не оценки.
33. Lara.Builova 22.03.11 18:21
(31)
Чтобы была польза от этого стандарта или любого другого, нужно научиться применять то что там написано

Конечно.
Потому любители демогогий могут и дальше верить в PM BOK. А кто хочет результатов без лишней мути, попробуйте для начала освоить те пункты что описаны у меня в статье

С помощью PM BOK я сделалала несколько проектов, один из них совсем маленький и смешной для вас - проект открытия фирмы. Это "масштабируемый" инструмент, его можно применять для различного объема, хоть для расчета ремонта своей кухни, хоть для расчета внедрения УПП на заводе по производсву колбасы или еще чего- нибудь, просто нужно уметь, а сначала понять.
Вы рассказали о своем опыте - это замечательно и спасибо вам! Вы описали небольшую часть инструментов.
Хотя с точки зрения PMBOK под инструментами понимается несколько другое.

Меня больше интересует опыт управления проектами с нуля, от начала и до завершения или хотя бы опыт расчета бюждета и сроков, рисков и пр. Глядя на название статьи я подумала, что речь об этом, но тут совсем о другом.
Уж не обессудьте, но в полемику я вступать не буду, просто отмечу для себя - "не то".
И да, я, наверное, теоретик - не руковожу людьми и не провожу собрания, но внедряю проекты в одиночку.
От этого они не перестают быть проектами, но это из другой оперы
P.S. Расчет рисков и стекхолдеров (движущих сил влияющих на проект как положительно, таки отрицательно) позволил мне не сунуть голову в сие предприятие, через год оно приказало долго жить, несмотря на инвестиции.
lustin; tango; Арчибальд; +3 Ответить 2
34. A.Y 22.03.11 18:53
(33)
Lara.Builova пишет:
С помощью PM BOK я сделалала несколько проектов, один из них совсем маленький и смешной для вас - проект открытия фирмы.

Нееет ) я когда первый раз фирму открывал, тоже к этому делу ответственно подходил. Потому ничего смешного в этом не вижу )
Наоборот, чую родную душу ))
Lara.Builova пишет:
Это "масштабируемый" инструмент, его можно применять для различного объема, хоть для расчета ремонта своей кухни, хоть для расчета внедрения УПП на заводе по производсву колбасы или еще чего- нибудь, просто нужно уметь, а сначала понять.

солидарен ) только в этом мире все относительно и все познается в сравнении... я пробовал PM BOK и пробовал GTD. Остановился на втором.
Кто то ездит на джипах, кто то на седанах, а кому то в кайф купе. Но чтобы понять что твое, а что нет, нужно попробовать...
Если выбор осознан это правильный выбор. А если защита идет из принципа Синдром утенка... тогда беда.
Lara.Builova пишет:
Меня больше интересует опыт управления проектами с нуля, от начала и до завершения или хотя бы опыт расчета бюждета и сроков, рисков и пр. Глядя на название статьи я подумала, что речь об этом, но тут совсем о другом.

Тут вот какое дело... бюджеты, сроки и риски зависят от темы проекта. если говорить об универсальности то тут только методика ВИСИ.
А далее вступает уже специфика... схема расчета затрат у проекта на базе ДИРЕКТУМ или 1С будет своя. У 1С схема расчета затрат на БП или УПП тоже своя.
Причем если есть программирование то там еще больше специфики. И вся это особенность должна ложиться на какие то более глубокие базовые нормы.
Хотя да, полезность такой методики, пусть даже в узком, конкретном плане, в сообществе 1С была бы полезна. Подобные вещи мне встречались в сообществе ДИРЕКТУМ. Правда когда я их нашел, было уже поздно, лоб разбит, опыт наработан, и было чуть чуть обидно что не нашел эту методику ранее. И в качестве обучения молодых РП применял ее постоянно.
Может быть как нибудь соберусь и напишу аналогичную методику для 1С. Не все сразу )
Lara.Builova пишет:
Уж не обессудьте, но в полемику я вступать не буду, просто отмечу для себя - "не то".
И да, я, наверное, теоретик - не руковожу людьми и не провожу собрания, но внедряю проекты в одиночку.
От этого они не перестают быть проектами, но это из другой оперы

1. ну не то так не то )
2. проекты не внедряют. внедряют программы ... не удержался от замечания, прошу прощения ))
3. проект вообще универсальное понятие. и проектный подход можно применять при разных масштабах задачи. это бесспорно. я лишь отметил что описанные мной методики начинают приносить в пользу в относительно сложных проектах, там где есть люди, сроки, бюджеты и соответствующий класс проблем.

успехов на проектном фронте! )

иии почему то стих вспомнил )

Прощай.
Позабудь.
И не обессудь.
А письма сожги...
Как мост.
Да будет мужествен твой путь
И будет он прям
И прост.
Да будет во мгле
Для тебя гореть
Звездная мишура,
Да будет надежда ладони греть
У твоего костра.
Да будут метели,
Снега, дожди,
И бешенный рев огня...
Да будет удач у тебя впереди
Больше,чем у меня.
Да будет могуч и прекрасен
Бой,
Гремящий в твоей груди.
Я счастлив за тех,
Кому с тобой,
Может быть,
По пути.

(с) Бродский
35. Михаил Ражиков (tango) 22.03.11 20:45
"У 1С схема расчета затрат на БП или УПП тоже своя"

пеши, как говорится, еще
36. Михаил Ражиков (tango) 22.03.11 22:50
(33) давненько не читывал постов с таким удовольствием
37. desty (lustin) 25.03.11 23:17
Коллеги.

У меня назрели два маленьких вопроса:

"Как данная статья, где в комментариях больше смысла чем в ней самой, попала вдруг в выбор экспертов ?"
"Не могли бы Вы рассказать, кто эти эксперты, чей выбор пал на данную статью ?"

С Уважением и Недоумением....
38. Ирина Пятакова (Alraune) 25.03.11 23:53
(37)
чей выбор пал на данную статью

В числе тех, кто поставил данной статье плюсы, то есть рекомендовал ее к прочтению, - Администрация Инфостарта и руководитель Экспертизы публикаций. Так что недоумение непонятно.
39. desty (lustin) 26.03.11 01:31
Alraune пишет:

(37)


я спрошу еще раз, для закрепления:

"Совет экспертов считает эту статью полезной ? достойной выбора экспертов ?"
40. Ирина Пятакова (Alraune) 26.03.11 01:37
desty пишет:
я спрошу еще раз, для закрепления:

Не знаю, что здесь еще закреплять. Не могу отвечать за экспертов. Но статья интересна хотя бы тем, что дает повод для размышления. Поэтому вполне может быть отмечена.
41. desty (lustin) 26.03.11 01:57
Alraune пишет:

Alraune пишет:



еще раз

.....

два простых вопроса
"Как данная статья, где в комментариях больше смысла чем в ней самой, попала вдруг в выбор экспертов ?"
"Не могли бы Вы рассказать, кто эти эксперты, чей выбор пал на данную статью ?
42. Михаил Ражиков (tango) 26.03.11 11:02
(41) да ладно, пусть цветут все цветы
43. Ирина Пятакова (Alraune) 26.03.11 11:35
(41) Недоумение продолжается? Ладно, объясняю.
Выбирает, какие публикации попадают на главную, только один человек - владелец данного ресурса.
В группе Экспертиза публикаций (насколько помню, она открыта для всех) любой может предложить свои варианты, все они рассматриваются и учитываются.
Только желающих пересматривать все публикации за период и отбирать из них наиболее интересные ТАМ особо нет.
А зато умников, которые начинают ЗДЕСЬ спрашивать, "как и почему", хватает.
Как-то так.
44. A.Y 26.03.11 15:00
(37)
тут вот какая проблема )
если ты не видишь смысла в статье... то есть вероятность что проблема не в статье )
но не всем это дано понять )
45. desty (lustin) 26.03.11 20:17
Alraune пишет:

(41) Недоумение продолжается? Ладно, объясняю.

Выбирает, какие публикации попадают на главную, только один человек - владелец данного ресурса.

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

Только желающих пересматривать все публикации за период и отбирать из них наиболее интересные ТАМ особо нет.

А зато умников, которые начинают ЗДЕСЬ спрашивать, "как и почему", хватает.

Как-то так.


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

P.S. (37) Троллей не кормлю, вопросы были не Вам.
46. evgen1977 (musatov1c.ru) 11.11.11 17:19
Вроде общее направление понятно. Не понятно, почему ТимЛаб не поддерживает пресловутое ВИСИ. ТимЛаб посмотрел. Хороший открытый облачный сервис. МегаПлан посмотрю попозже. Как можно программой ограничить логическую целостность? Ну да ладно. Обзор автора его видения работы с проектами все равно интересен. Хотя меня не три, а всего одын :)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа