Перейти к содержимому
Калькуляторы

проектное управление о выборе таск-менеджера, его насаждении и не только...

Кстати, о птичках.

Ринетику в этом году исполнится 20 лет. Это довольно много по меркам нашего народа.

Много ли людей осталось из тех, кто 20 лет назад начинал? Клетки организма обновляются, а сам организм - меняется.

 

Реальные проблемы начинаются когда

- у задачи большой жизненный цикл

- у задачи есть ветвления

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

 

Ну так заведи BPM и перетащи на нее все из трекера.

 

Между проектом и процессом нет фундаментальной разницы и то и другое метод агрегации тасков.

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скажем, когда Прохожий употребляет слово проект ему видится какая-то довольно эпичная картина. Приходит к Прохожему например, кто-то и говорит - надо поставить в абхазии завод по производству мандаринового сока. Сроки такие-то, бабла столько-то. Берешься? Прохожий крепко думает вспонимает все что он знает про абхазию и мандарины(вот откуда упор на уникальность) и допустим говорит берусь. Дальше у него жизнь становится резко интереснее.

Описанное тобой - не проект. Проектом становится оно тогда, когда уже есть параметры завода, площадка, бюджет, ТЭО и т.д. ;)

Тим, ты как путался в понятиях, так и путаешься, уж прости.

 

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

 

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

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

 

Тимур, я могу только констатировать, что управления процессами у тебя так же нет, как и управления проектами ;) Реально есть у тебя только таск-трекинг. А это не то и не другое, как бы похоже не было ;)

 

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

 

Откуда взялся раздел с управленческими задачами/проектами?

 

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

 

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

 

Третья причина - по ритму закрытия можно во внятной форме увидеть с какой скоростью руководитель подразделения/специалист закрывает управленческие задачи. Ремарка - управленческие задачи конечно кофликтуют за ресурс времени/внимания с текучкой. Но если человек несколько периодов подряд не _сделал_ ничего, то это естественным образом подводит нас к вопросу о расставании.

 

Четвертая причина - управленческие задачи далеко не на 100% сводятся к моим распоряжениям менеджерам - есть еще огромный пласт запросов менеджеров друг к другу. Соответственно всем удобнее когда конкретно понятно - кто чего и от кого хочет. И четко понятно кто кого и в каких вопросах стопит.

 

Ну как-то так. Уже достаточно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну так заведи BPM и перетащи на нее все из трекера.

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

Не надо так пугать. Ткни лучше в маленький и приятный вариант.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Не надо так пугать. Ткни лучше в маленький и приятный вариант.

Дык, по любой теме так будет :) Времена такие.

 

Если хочется посмотреть на чистый движок без обвеса - то посмотри на это: http://wf.runa.ru/About

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Много ли людей осталось из тех, кто 20 лет назад начинал?

 

Много.

 

Реальные проблемы начинаются когда

- у задачи большой жизненный цикл

- у задачи есть ветвления

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

 

Ну так заведи BPM и перетащи на нее все из трекера.

 

Хочу положить перста в раны. Покажи мне нормальный BPM движок в нагруженном состоянии.

 

Люди, ау!!!

У кого тут из присутствующих есть нормальный BPM движок. Покажите - как оно все у вас устроено, пожалуйста!!!

 

 

Между проектом и процессом нет фундаментальной разницы и то и другое метод агрегации тасков.

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

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

 

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

А то может мы сравниваем достоинства и недостатки реального говна с иллюзорной конфетой?

 

 

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

 

А давай в терминах информационных систем.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тим, ты как путался в понятиях, так и путаешься, уж прости.

 

Нет проблем.

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

Я остался последним человеком на форуме, который путается в понятиях?

 

 

 

С точки зрения управления строительство дачного сортира от строительства завода не так сильно отличается, как это кажется. "Вот моя цель, я должен разбить ее на этапы/блоки/крупные куски, потом разбить дальше каждый из них, потом повторять итеративно до тех пор, пока я не получу вполне обозримые куски, которые понятно как делать".

 

Ну... вроде бы логично. И?

Это ты к чему?

 

Проблема начинается тогда, когда вместо такого подхода ты говоришь "ща я выпишу в столбик все таски и начну их выполнять в порядке, который придет мне в голову" :)

 

В концепции GTD это называется "естественным планированием" :-))

 

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

 

Не согласишься?

 

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

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

 

Если мы хотим как-то выживать в реальном мире нужно это учитывать.

Не?

 

 

Тимур, я могу только констатировать, что управления процессами у тебя так же нет, как и управления проектами ;) Реально есть у тебя только таск-трекинг. А это не то и не другое, как бы похоже не было ;)

 

А я пожалуй с тобой соглашусь.

 

В том смысле, что по сути в процессах мы тоже мало что контролируем. Возможно это проблема.

Чтобы понять - проблема ли это или нет нужно запустить проект по изучению ситуации. Но приоритетен ли он?

:-)))

 

 

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

 

Знаешь... как говориться, многие знания - многие печали.

 

Возможно только я и этот предшественник дозрели до понимания соответствующих вопросов :-)))

 

 

 

Тимур, когда мы говорили за Адванту я, похоже, не донес до тебя центральную мысль: это единственная известная мне система, в которой передача задач сопряжена с обязательным подтверждением исполнителем "да, берусь" и возможностью отказаться.

 

Пффф - подумаешь.

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

Даже и говорить не о чем.

 

Равно как и завершенная задача - это не когда исполнитель решил, а когда тот, кто поручил, подтвердил что он получил именно то, что хотел.

 

Опять же пффф

Есть этап "принимайте" где заказчик должен подтвердить, что задача выполнена.

 

Короче, нифига не уникально.

Поднимите руки - у кого таких функций в таск-менеджерах нет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Муа-ха-ха!!!

 

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

:-)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Принимайте в принципе, это не активный а архивный этап (заказчики тотально игнорируют прием результатов). Пытались работать по нормальному - но не смогли.

 

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

Таск это скорее напоминалка о наличии задачи, нежели ресурс в котором нужно черпать какое-то знание.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Таск это скорее напоминалка о наличии задачи, нежели ресурс в котором нужно черпать какое-то знание.
да
заказчики тотально игнорируют прием результатов
ну тогда исполнитель просто не получит ЗП. А ведь по хорошему нужно ещё и оценку поставить исполнителю, и написать ЧМСД и ЧСХ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А ведь по хорошему нужно ещё и оценку поставить исполнителю, и написать ЧМСД и ЧСХ.

 

Что значит по хорошему?

 

У Адизеса есть прекрасное наблюдение на тему различий восприятия

 

1259_pic1.jpg

 

 

6. Восприятие: есть, хочу, должно быть. В основе конфликта могут лежать и различия в восприятии реальности. Точка отсчета здесь — то, что есть; далее следует желаемое, и затем то, что должно быть. Эти области не совпадают, но пересекаются (рисунок), причем конфликты возникают именно в зонах пересечения.

 

Рассмотрим в качестве примера внутренний конфликт между тем, что «я делаю», тем, что, по моему мнению, «я должtн делать» и тем, чем «я хочу заниматься». Происходит «столкновение» и конфликт восприятия деятельности:

 

зона неосуществленных мечтаний: то, чего мы хотим, и то, что должно быть, не существует на самом деле;

«жизнь во грехе»: мы делаем то, что хотим, но этого не должно быть или требуется другое;

зона разочарований: то, что есть, и то, что должно быть, не очень нравится и не очень желательно;

«место счастья»: то, что мы уже делаем, и есть то, что мы хотим и что должно быть сделано.

Изменения начинаются в порядке: «есть — хочу — должен», а планирование: «хочу — должен — есть». Чтобы не заниматься самообманом, избежать разочарования и разрушения доверия, нужно четко разграничить то, что есть, то, что должно быть, и то, к чему лежит душа.

 

Так мы сейчас о чем говорим?

:-)

 

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

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

 

Я кстати не говорю, что это невозможно.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Принимайте в принципе, это не активный а архивный этап (заказчики тотально игнорируют прием результатов).

 

Потому что есть великая мудрость, "Дуракам пол работы не показывают".

 

или вот эту половину примут за готовую работу, или замучают советами, или изменят всю концепцию, или отменят все совсем.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поэтому хотим уйти под власть роботов :-)))

Тим, любой Project Management всё-равно администрируется людьми.

Ибо фактически все системы управления проектами фактически есть по сути электронная бумажка для записи и встроенный мессенжер.

Дальше вкусовщина и заточенность под фичи разных методик управления под конкретные отрасли.

 

Согласен.

В деле управления проектами роботы пока не роляют.

 

У меня крутится в голове несколько другая концепция

 

Тим, и почитай про Scrum.

https://ru.wikipedia.org/wiki/Scrum

Там есть очень прикольная фишка - диаграмма сгорания задач.

Может это наглядно покажет твоим коллегам в чём состоит ценность работы над проектом ?

 

Вопрос о планировании времени я даже боюсь поднимать.

 

У нас не приживется.

 

Мы не приемлем власть людей.

Поэтому хотим уйти под власть роботов

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

 

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

 

Может, подискутировать за кружечкой пива :)?

 

Предпочитаю коньяк :-)

А заижжайте в гости. Наши двери всегда открыты

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Ну так заведи BPM и перетащи на нее все из трекера.

 

И да. Я кстати, морально готов бросить наш треккер.

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

 

Что там у нас есть на тему бизнес-процессов? OTRS?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Как я уже сказал - больше всего это похоже на управление требованиями. Оно идейно тупое как пробка но жутко много писанины и работы головой.

 

Теперь про 'требований слишком много' (а их будет много - методика такая). Соответствующий инструментарий, по идее, строит таки граф зависимостей и подсказывает узловые точки. Отсюда уже и приоритеты вытаскиваются. Ну и на каждую хотелку получается подробная документация для каких именно целей мы это захотели. Если чего-то изменилось - тот же инструментарий помогает выкидывать лишнее.

 

Ну... понятно что к чему.

А вы это в реальности где-нибудь наблюдали? Что бы кто-нибудь вот так сурово морочился (особенно во внутренних проектах)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну... понятно что к чему.

А вы это в реальности где-нибудь наблюдали? Что бы кто-нибудь вот так сурово морочился (особенно во внутренних проектах)?

Нет конечно. Я же не начальник. Только личное применение в разработке и чтение книжек по разработке систем. В личном опыте - как раз тупое расписывание и вызываемая этим лень способствует тому, что осознаешь, что чего-то ты тут перемудрил и надо начинать упрощать как происходящее так и хочушки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну... понятно что к чему.

А вы это в реальности где-нибудь наблюдали? Что бы кто-нибудь вот так сурово морочился (особенно во внутренних проектах)?

Нет конечно. Я же не начальник. Только личное применение в разработке и чтение книжек по разработке систем. В личном опыте - как раз тупое расписывание и вызываемая этим лень способствует тому, что осознаешь, что чего-то ты тут перемудрил и надо начинать упрощать как происходящее так и хочушки.

 

Понятно. Но может быть кто-нибудь видел в реальности начальников, которые регулярно практикуют нечто подобное?

Тут у нас довольно большой форум, куча народа видела много разного...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут-то мы в плотную подошли к теме топика. Потому что большая часть управленческих задач это все-таки проекты. Ну пусть проектики.

С этого места не согласен.

Управленческие задачи разные.

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

 

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

В том числе, проработкой отдельных необходимых задач.

 

Могу только повторить, что говорил чуть выше

 

Я в целом согласен.Операционные руководители в большинстве случаев не будут форматировать сами себя. Модификация бизнес-процессов должна исходить откуда-то еще (как правило сверху).

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

С другой стороны - есть и подводные камни. Тема отдельного разговора - я сейчас не хочу на него отвлекаться.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поднимите руки те, у которых системы работают именно так как задумано (поля заполняются, по этам идет продвижение в риалтайме, ведется учет старт-стопа - вот это вот все)

у нас на производстве используется redmine

жизнь задачи в нем достаточно проста. оценка трудозатрат-ресурсов. постановка в план. выполнение. проверка. приёмка.

есть возможность трэка "автоматически", есть ручной режим.

если заказчик (постановщик задачи) закрывает тикет - то значит он работу принял (тестирование и прочие вещи регламентированы).

отчётность есть на предмет того что в задачах больше двух дней тишина, если задача в состоянии "В работе"/"нужен отклик"/"решена".

пинки за просрочку имеются от руководства. но сильно редко.

 

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

это очень плохо.

концепция "ты меня знаешь-я тебя знаю-погнале" работает в конторе до 10 человек. дальше сильно плохо.

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

 

бюрократия (как и достаточная документация), к сожалению, уже необходима.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я в целом согласен.Операционные руководители в большинстве случаев не будут форматировать сами себя. Модификация бизнес-процессов должна исходить откуда-то еще (как правило сверху).

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

С другой стороны - есть и подводные камни. Тема отдельного разговора - я сейчас не хочу на него отвлекаться.

 

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

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

 

Но, в форумном формате объяснить свое понимание вопроса довольно сложно :).

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

Заодно могу расказать, какие процессные и проектные программы видел в работе, но это тоже, не вполне форумный формат.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

телега впереди лошади
а кто тут телега и кто лошадь? может они одно целое, оба же едут!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

телега впереди лошади
а кто тут телега и кто лошадь? может они одно целое, оба же едут!

Я имел в виду попытку решить инструментальными средствами административные проблемы.

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

телега впереди лошади
а кто тут телега и кто лошадь? может они одно целое, оба же едут!

Я имел в виду попытку решить инструментальными средствами административные проблемы.

 

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

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

 

Начнем с того, что проблемы не административные, а культурные.

Почувствуйте разницу.

 

А дальше... Существует такая максима - нельзя техническими методами пытаться решать культурные проблемы.

 

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

 

Техника и методы.

 

Вот примеры.

 

В средние века грамотных людей было дико мало. Обучение человека искусству читать и писать было штучным делом - особым и дорогим искусством.

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

 

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

 

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

 

Ну и так далее.

 

 

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

 

Не судите меня строго - я просто пытаюсь быть объективным :-)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

нам нужен простой дещевый, массовый, доступный любому идиоту метод управления проектами.

 

Могу спорить на сок - не найдешь. :-) У тебя уже есть прекрасные инструменты: майндмапы + трекеры ( нет только связки ссылками топиков и тасков ),

но ты же не можешь вовремя остановиться, доводишь все до абсурда и потом жалуешься всяким прохожим, что неудобно. :-)

 

Ну и очевидно, что если ты в систему управления пускаешь идиотов, то и проекты у тебя всегда будут идиотские. :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Не судите меня строго - я просто пытаюсь быть объективным :-)))

Прошу не воспринимать наши дискусии, как осуждение, ни в коей мере!

Я не знаю, как у господина Прохожего, Кири, и прочих участников темы, но мой опыт никак не позвляет мне почивать на лаврах "настоящего проектного менеджера" и быть судьей в столь тонком вопросе!

 

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

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

 

Тем не менее, мне бы хотелось указать но то, что минимум три аккорда, но знать надо. Более того, просто прочитать про три аккорда все же недостаточно :), надо еще немного потренироваться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.