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

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

начало тут:

Алексей Павлюц Володя, можно ссылочку на общепринятость такого вот порядка? Не в плане наезда, мне ДЕЙСТВИТЕЛЬНО интересно, откуда растут у таких вещей ноги.

23 Апрель в 22:35 · Нравится

 

Владимир Капустин http://image.slidesharecdn.com/.../cobit-5-as-an-it...

 

http://image.slidesharecdn.com/.../businessdriven-ea-at...

IMAGE.SLIDESHARECDN.COM

23 Апрель в 22:54 · Нравится

 

Алексей Павлюц Эвона как! Правда я подозреваю, что наше "оперативный" и их "operational" имеют весьма разное значение.

23 Апрель в 23:00 · Нравится

 

Михаил Климарев WTOS - ЕМНИП, так говорили. Weapon, Tactic, Operational, Strategy. Но я военку прогуливал постоянно

23 Апрель в 23:36 · Не нравится · 1

 

Алексей Павлюц Миша, ты учился в вест-пойнте?

Вчера, в 0:06 · Нравится

 

Михаил Климарев Нет. Выше бери - в педагогическом

Вчера, в 6:45 · Не нравится · 1

 

Тимур Чудутов Вопрос. А чем плохи деревья? Деревья хороши. Если их проектированием занимается невьебенно разумный человек. Проблема же в том, что древовидные системы допускают слишком просто создать любому пользователю подуровень. А дальше получается вот что. Гендир...Еще

16 ч. · Не нравится · 3

 

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

16 ч. · Отредактировано · Нравится

 

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

16 ч. · Нравится

 

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

16 ч. · Нравится

 

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

16 ч. · Нравится

 

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

16 ч. · Не нравится · 1

 

Тимур Чудутов Резюме. Если в конторе нет кого-то с мощной башкой, чтобы правильно нарезать задачи - то конторе ничего не поможет. Но если такой человек есть, то в джире у него больше возможностей иметь монополию на создание сущностей. Что в краткосрочной перспективе подгружает, но в долгосрочной облегчает

16 ч. · Нравится

 

Алексей Павлюц Тим, ты не прав. Человек с башкой должен не только нарезать задачи, но и учить этому других, иначе система все равно его сожрет. Он должен своим образцом и своими требованиями к другим МЕНЯТЬ ПРАКТИКИ.

16 ч. · Нравится

 

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

16 ч. · Нравится

 

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

16 ч. · Нравится

 

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

16 ч. · Нравится

 

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

16 ч. · Нравится

 

Тимур Чудутов Что значит в "пуле будущих"?

16 ч. · Нравится

 

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

Лично я учу людей прямо противопо...Еще

16 ч. · Нравится

 

Алексей Павлюц Тимур, это все задачи, которые еще не выполнены, но уже в системе

16 ч. · Отредактировано · Нравится

 

Тимур Чудутов Активные этапы

Разобрать 264

Кому?62...Еще

16 ч. · Отредактировано · Нравится · 1

 

Тимур Чудутов Архивные этапы

16 ч. · Отредактировано · Нравится

 

Тимур Чудутов Принимайте 84

Опытная эксплуатация 1982

Сделано 1846...Еще

16 ч. · Отредактировано · Нравится · 1

 

Алексей Павлюц А на какое количество людей?

16 ч. · Нравится

 

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

Трактатъ о сущности отличий: Проекты и Процессы | Алексей Павлюц — личный сайт

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

PAVLYUTS.RU

16 ч. · Нравится

 

Михаил Климарев ниче, что я тут со своим свиным рылом? (заслушался)

16 ч. · Не нравится · 2

 

Олег Хлебников Михаил Климарев подвинься...

15 ч. · Не нравится · 1

 

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

15 ч. · Нравится · 1

 

Тимур Чудутов А вообще... не пора ли этому тредику переехать на наш любимый форумчик? Вангую что побъем рекорд прямой трансляции :-))

15 ч. · Нравится · 1

 

Владимир Капустин Так пар-то уже спущен - нет?

14 ч. · Нравится

 

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

13 ч. · Нравится

 

Владимир Капустин А я уверен, что она снизу не вырастет

13 ч. · Нравится

 

Антон Зыкин растет, как ни странно

13 ч. · Нравится

 

Владимир Капустин В небольшом коллективе - поверю.

13 ч. · Нравится

 

Антон Зыкин в любом. с марке, в свое время, это начали инженеры...

13 ч. · Нравится

 

Владимир Капустин А на маркетинг и продажи кто ее натянул?

13 ч. · Нравится

 

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

13 ч. · Нравится

 

Владимир Капустин Нет уж - само это про плесень Такую штуку надо внедрять сверху. Просто ее надо не насаждать, а продавать

13 ч. · Нравится · 1

 

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

Володя, я согласен по пово...Еще

13 ч. · Нравится · 1

 

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

13 ч. · Нравится

 

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

13 ч. · Нравится

 

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

13 ч. · Нравится

 

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

12 ч. · Нравится

 

Владимир Капустин Большинство не хочет ничего менять.

12 ч. · Нравится

 

Антон Зыкин это потому что они не пробовали. или попробовали, но у них не получилось, чаще потому, что не поддержали - с этими да, сложнее. вернее - дольше

12 ч. · Нравится

 

Алексей Павлюц Антон, людей, имеющих желание и силы менять - от силы полпроцента. Остальные скорее поменяют компанию.

12 ч. · Нравится

 

Антон Зыкин ну что ж. значит - они все у меня сорри

7 ч. · Отредактировано · Нравится

 

Тимур Чудутов А я и не спорю, что я не понимаю сути проектного управления. У меня больше вопросов чем ответов

5 ч. · Нравится

 

Тимур Чудутов Надо в форумчик переползти... пара не выпущен

5 ч. · Нравится

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


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

Как интересно....

"Папа, а ты с кем счас разговаривал?":)

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

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


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

Как интересно....

"Папа, а ты с кем счас разговаривал?":)

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

 

В Ижевске живет 600 тысяч человек :-)

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


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

В теме дискуссии уже заложена ошибка: проектное управление и тасктрекеры - принципиально разные области.

 

Проект - это когда мы на старте задаем тот результат, который мы должны получить за заранее определенный отрезок времени и с учетом ресурсных ограничений. Таск-трекер же по сути позволяет упорядочить и учесть поток задач и организовать ПРОЦЕСС осмысленного распределения этого потока по наличным ресурсам и последующего выполнения.

 

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

 

Для прояснения разницы проект-процесс и понимания почему и как они рулятся - рекомендуется для начала ознакомиться вот с этим: https://pavlyuts.ru/posts/69

 

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

 

На примере операторской деятельности, например:

Каблирование нового района - проект. На старте мы знаем, чего хотим, допустим, ящик в каждом подъезде, куда можно подключать абонентов. Мы можем строить план проекта, выделять ресурсы, он конечен во времени. Результатом проекта является появление в списке доступных для подключения вполне конкретного набора адресов. При этом этот проект своими отдельными задачами запускает определенные процессы, например, закупки или config management. Для проекта ОТДЕЛЬНЫЕ ЭКЗЕМПЛЯРЫ этих процессов являются задачами проекта.

 

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

 

Кроме проектов и процессов есть еще и цели ;) Которые не то и не другое, а скорее "суперконтейнер" и плоскость анализа и для проектов и для процессов. Т.е. "цель" - в новом районе подключить 5К абонентов. В ее рамках - проект по каблированию района, проект по маркетингу, процессы подключения, бла-бла-бла. Перестройка и апгрейд своей структуры чтобы она могла вместо 100 абонентов в день подключать 500 - тоже проект. У него есть длительность, цель, ресурсы. Но ресурсы этого проекта - НЕ новые монтажники-подключалы, а те, кто их наймет, обучит, перестроит, изменит правила, дополнительный инструмент, униформа, новые линии и рабочие места колл-центра и т.д.

 

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

 

Как следствие - сама постановка вопроса: "использовать таск-трекер, BPMN или ИСУП?" - ложна. Использовать надо И процессный движок И систему управления проектами. Как их связывать в единую картину - это уже другой вопрос ;)

 

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

 

Вот как-то так.

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


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

Как интересно....

"Папа, а ты с кем счас разговаривал?":)

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

 

В Ижевске живет 600 тысяч человек :-)

 

Вау! Когда меня в очередной раз спросят про бизнес в Черногории я буду советовать двигать в Ижевск! Людей больше, на острие прогресса опять же!

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


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

Вау! Когда меня в очередной раз спросят про бизнес в Черногории я буду советовать двигать в Ижевск! Людей больше, на острие прогресса опять же!

А еще тут как-то много условно-профильных учебных заведений. Помогает ли это или нет - это надо AntZ спрашивать.

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


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

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

Еще жизненный цикл систем забыл добавить. Что делать, когда в этом районе все построенное снимать и переделывать нужно будет. А об этом надо бы задумываться. Скажем, желание властей 'убрать весящие кабеля' - это, кажется, во многом из за того, что их действительно много и они глаза мазолят/падают куда не надо/мешают ремонты крыш делать из за неправильного подвеса. А какая часть того что мешается и чего много - это уже неиспользуемые и 'бесхозные' линии?

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


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

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

 

Вопрос.

А почему ты вообще стал говорить о процессах?

В фейсбучике шло обсуждение систем ведение проектов - почему же ты перешел к смысловым отличиям между процессами и проектами? И какое это имеет отношение к софту для ведения проектов?

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


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

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

 

И я не понимаю словосочетание "ведение проектов" ;)

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


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

Тим, ты вообще послушай Прохожего.

Он дельные вещи говорит.

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


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

Спасибо, дорогой!

 

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

 

1. Что такое проект в твоей организации. Не вообще, а конкретно! Какие они бывают у тебя?

2. Сколько у тебя сейчас проектов каждого типа на марше? Реестр проектов хотя бы в виде списка есть?

3. Когда и чем каждый из них ДОЛЖЕН кончится по твоему мнению? Это записано где-то, формулировку все понимают одинаково?

4. Кто отвечает за каждый из них? Чья голова будет усечена, если результата не будет?

5. Использут ли сотрудники при разговоре что-то типа "проблемы по проекту ХХХХ?"

 

Вот с ответов на эти вопросы надо начать.

 

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

 

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

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


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

3. Когда и чем каждый из них ДОЛЖЕН кончится по твоему мнению? Это записано где-то, формулировку все понимают одинаково?

тут момент скользкий.

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

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

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


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

3. Когда и чем каждый из них ДОЛЖЕН кончится по твоему мнению? Это записано где-то, формулировку все понимают одинаково?

тут момент скользкий.

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

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

Значит это исследовательский проект, и задачи надо формулировать соответственно: "Хочу, чтоб 90% неподготовленных пользователей смогли разобраться с телефоном без инструкции через полчаса знакомства с ним!"

Ну, или вообще не проект, а так, развлечение :).

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

Если у вас ПО на коленке, то стройте без проекта, но если вы пишите серьезный продукт, у вас есть бюджет, у вас есть задачи, у вас есть ресурсы на это, и от вас те, кто дает бюджет, ждет конкретный результат.

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


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

 

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

Товарищ, о чем вы говорите?!

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

В процедурах компании написано, что риски, вероятность которого меньше 20% считается очень низким (в компании, где я работал до этого, очень низким риск считался, если не встречался в индустрии!). Да в этом документе даже ссылка на "PMbok" с ошибкой :).

 

В большинстве компании в России нет нормальной практики управления проектами, и никого это не волнует, увы. И это идет с высоты топов, даже понимающие PM вынуждены встраиваться в такую систему!

 

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

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


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

Значит это исследовательский проект

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

ПО, а особенно веб - тут с целепологанием беда.

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


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

Значит это исследовательский проект

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

ПО, а особенно веб - тут с целепологанием беда.

Почему же беда? ПО для веб вообще бесцельно?

Или беда с формулированием задачи? Может быть тогда беда с постановщиками задач? :)

С последним соглашусь совершенно!

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


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

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

 

И я не понимаю словосочетание "ведение проектов" ;)

 

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

 

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

 

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

 

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

понимании). Но что это тогда?

 

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

 

Давай начнем с того, что все эта деятельность делится на два больших класса -

- поддержка типизированной деятельности

- поддержка деятельности с большой долей неопределенности

 

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

- единством контрагента

- наличием очерченной рабочей группы

- оговоренными намерениями по

- заданию

- срокам

- стоимостью

- пространством рабочих материалов

 

Но проект ли это? А почему не процесс?

 

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

 

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

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

 

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

 

Имхо это и есть проект. Но замечу что у него нет четких сроков, ясного конца, однозначного бюджета и т.д.

 

И кстати. Обратимся к твоей основополагающей работе

Трактатъ о сущности отличий: Проекты и Процессы

 

Прое́кт (от лат. projectus — брошенный вперед, выступающий, выдающийся вперёд) — согласно новому стандарту ISO 21500 — уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определённым заранее требованиям, в том числе ограничения на получения результатов, таких как время, деньги и ресурсы. (с) Википедия

 

Минимальный квант работы проекта будем для простоты называть ЗАДАЧЕЙ.

 

Процесс — совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы» или в английском варианте «Process — set of interrelated and interacting activities which transforms inputs into outputs». (с) ИСО 9001:2000

 

Минимальный квант работы процесса назовем ШАГ.

 

Вопрос. А нет ли тут терминологической подтасовочки?

 

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

 

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

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

 

Чем это собственно говоря не задача?

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


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

Но что это тогда?

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

 

И я считаю свое определение чертовски точным.

 

Давай начнем с того, что все эта деятельность делится на два больших класса -

- поддержка типизированной деятельности

- поддержка деятельности с большой долей неопределенности

Здесь у тебя серьезная методологическая ошибка. Дело в том, что неопределенность есть везде, она вообще является базовым свойством бытия. Разделять по мере неопределенности глупо, потому что эта метрика, которая не меняет НИЧЕГО во всей остальной методологии.

 

Имхо это и есть проект. Но замечу что у него нет четких сроков, ясного конца, однозначного бюджета и т.д.

Значит это не проект ;)

 

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

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

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

 

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

 

Ведь не просто так в определении проекта сказано "набор взаимно увязанных процессов" ;)

 

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

 

Вопрос. А нет ли тут терминологической подтасовочки?

 

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

 

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

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

 

Чем это собственно говоря не задача?

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

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


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

Но что это тогда?

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

 

И я считаю свое определение чертовски точным.

 

Вопрос ведь, сам понимаешь, в точности представлений.

 

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

 

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

 

По сути что тут происходит? Происходит здесь довольно плавный переход от состояния "ничерта не понятно", в состояние "кое что получается", а от туда в состояние "мы умеем решать такие-то задачи, решили их уже много, и готовы сделать примерно то же для вас за вот такие деньги".

 

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

А что есть? Есть итеративное развитие процесса. Эволюция.

 

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

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


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

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

А что есть? Есть итеративное развитие процесса. Эволюция.

Ага. Сайтовладение - это непрерывный R&D.

 

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

А некоторые (смотрим на Гугл) на разработке инструментов к этом R&D и предоставлении доступа к ним кучу денег заработали. Правда, немного косвенно.

 

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

:-) Нету, по крайней мере в начале, никакого понимания. Есть 'нам кажется, что есть вот такая потребность и люди, которого этого хотят'.

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


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

Но что это тогда?

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

 

И я считаю свое определение чертовски точным.

 

Вопрос ведь, сам понимаешь, в точности представлений.

 

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

 

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

 

По сути что тут происходит? Происходит здесь довольно плавный переход от состояния "ничерта не понятно", в состояние "кое что получается", а от туда в состояние "мы умеем решать такие-то задачи, решили их уже много, и готовы сделать примерно то же для вас за вот такие деньги".

 

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

А что есть? Есть итеративное развитие процесса. Эволюция.

 

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

Тимур, я конечно, не Прохожий, но тем не менее :).

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

 

Я тут уже писал выше, в ответ karpa13a, как раз про Веб-проекты, что вопрос в постановщике задачи.

 

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

Допустим!

 

Цели людей какие? Развлечься, и, может быть сделать что-то путное? Или же заработать денег на проекте? Или решить какие-то свои личные задачи? Зачем у людей этот проект? От ответа на этот вопрос очень сильно зависит подход к проекту!

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

Если заработать денег - то должно быть понимание, для кого проект, где доходы, где расходы, и прочее, прочее. И цель проекта - сделать удобный для пользователя сервис, который привлечет не менее, чем K (нет, К - мало, пусть будет M!) пользователей, которые готовы отдавать за сервис не менее чем X рублей в течении года, техническое решение должно быть таким, чтоб обслуживание сервиса стоило не более чем Y рублей на пользователя.

 

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

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

 

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

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

 

То есть, если какой-то "шаг" процесса требует решения уникальной задачи - этот шаг реализуется отдельным проектом!

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

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


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

 

Вопрос ведь, сам понимаешь, в точности представлений.

 

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

 

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

 

По сути что тут происходит? Происходит здесь довольно плавный переход от состояния "ничерта не понятно", в состояние "кое что получается", а от туда в состояние "мы умеем решать такие-то задачи, решили их уже много, и готовы сделать примерно то же для вас за вот такие деньги".

 

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

А что есть? Есть итеративное развитие процесса. Эволюция.

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

Дорогой друг, ты великолепен :)

 

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

 

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

1. Создание прототипа/стартовой версии сервиса. Исходя из СЕГОДНЯШНЕГО представление о будущем продукте, оперативных возможностей и ограничений. Вот тебе появляется вполне конкретная область, где ты уже можешь строить планы. Внутри ты можешь использовать скрам, агиль, да что угодно, важно не это, а то, что ты имеешь представление о результате, который действительно собираешься получить (прототип с вполне конкретным фичер-сетом), ресурсах, которыми располагаешь и временных рамках, в пределах которых ты хотел бы этот результат получить.

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

3. Маркетинг/раскрутка/SEO - тоже вполне себе проект.

4. Фанд-райзинг. Тоже вполне себе конкретный проект.

 

Вот видишь, эта муть уже разложена на 4 проекта с вполне себе конкретным пониманием результата. Они НЕ обязаны быть выполнены четко по плану, я тебе по секрету скажу что так и не бывает. Оно будет корректироваться, плыть и жить, ты на полпути можешь переосмыслить набор фич или ВНЕЗАПНО найти хорошего программера, который сильно ускорит разработку. Но у тебя уже есть цели НЕ стратегического уровня, у тебя уже есть возможность делегировать блоки, у тебя уже есть план. Который, есс-но, не на всю жизнь ;)

 

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

 

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

 

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

 

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

В мире миллионы людей не имеют доступа к достаточному количеству пресной воды. И че? Мыться перестаем? А еще в мире ежесекундно происходят сюициды и изнасилования. И?

 

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

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


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

Кстати, положу офигенную ссылочку про то, как устроен инжинириг и девелопмент в букинг-ком. Автор, видимо, охренел от своей популярности, устыдился и закрыл документ на переписывание, но, во первых, я думаю, что из кэша можно вытянуть ;) https://docs.google.com/document/d/1poDLkuksi3HzLt6q0E6M6r-PcmJiPrvakfn0gy1ehvc

 

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

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


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

Вопрос. А нет ли тут терминологической подтасовочки?

 

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

 

Чем это собственно говоря не задача?

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

 

У меня ощущение, что ты споришь тут из принципа.

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

 

Короче говоря, шаг в проекте это такая же задача как и задача в процессе.

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


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

У меня ощущение, что ты споришь тут из принципа.

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

Cваи, говоришь, забить не проблема ?

:)))

http://www.youtube.com/watch?v=Yex_uRO15yI

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


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

Join the conversation

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

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

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

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

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

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

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