[jab]

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

 

Канбан, скрам, эджайл, смарт, импакт - и все за 15 минут. :-)

[Sergey Gilfanov]

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

И при этом он будет совершенно стандартным. Ну, как одежда массового производства.

[SergoINFOLAN]

Если есть люди, действительно готовые вести проект, они смогут его вести на текущем инструментарии треккинга тасков

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

Не такая же ДВОИЧНАЯ логика!

[Тимур]

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

 

А если таких людей нет?

[Тимур]

И при этом он будет совершенно стандартным. Ну, как одежда массового производства.

 

Это же хорошо.

[Тимур]

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

 

Могу спорить на сок - не найдешь. :-)

 

Я люблю пари. Мне все равно - выиграть или проиграть.

Нужно четко сформулировать условия.

 

 

 

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

 

Связка-то есть. Проблема в том, что нужно веббейзед решение.

Веббейзед решение тоже есть - например связка джира - конфлюэнц

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

 

 

 

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

 

Лучшее враг хорошего, но друг идеального :-)

 

 

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

 

А вот с этим необходимо считаться.

[jab]

Я люблю пари. Мне все равно - выиграть или проиграть.

Нужно четко сформулировать условия.

 

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

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

[Тимур]

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

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

 

Нужна какая-то метрика.

 

Это же классический смарт. Конкретно, измеримо, достижимо, релевантно, ограничено по времени...?

 

Кто может сформулировать?

[Тимур]

Продолжим капать в копилку

 

Для начала посмотрим на упомянутую Кирей диаграмму сгорания задач

 

ъ

 

Что мы на ней видим?

 

Мы на ней видим визуализированную таблицу вида

 

Таск1/плановая продолжительность/фактическая продолжительность/состояние

Таск2/плановая продолжительность/фактическая продолжительность/состояние

 

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

 

Мы могли бы написать что-нибудь типа

1. Составление ТЗ/ 24часа/32 часа/готово-10 января

2. Передача ТЗ кодеру/8 часов/6часов/готово-11 января

3. Разработка прототипа/50ч/65ч/готово - 30 января

4. Анализ прототипа и формулировка доработок/12ч/?/ в работе

5. Доведение прототипа до альфы/50ч/?/планируется

7. Анализ альфы и формулировка доработок/10ч/?/планируется

8. Разработка беты/24ч/?/план

9. Прием беты/10ч/?/план

10. тестовое внедрение /30ч/?/план

12. Анализ итогов внедрения+сдача проекта/10ч/?/план

 

 

Как-то так.

 

А теперь внимание вопрос - что мне мешает пользоваться этим прекрасным методом?

[Тимур]

Да очень просто. Причины два

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

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

 

 

В моем же случае, характерная ситуация не такая. У менеджера в активе есть некий ворох тасков

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

- менеджеры занимаются задачами _урывками_ Реализация каждого пункта по времени не очень велика (от получаса до 10часов)

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

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

 

Ну и так далее. Иными словами мы никаким образом не получим такой красивой картинки.

 

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

 

Вот к примеру мой проект

фин: Сокращение затрат 1q15 (Я) [1 / 19] В работе 10 / 4 / - 1 / - / - - / - / - 3 - 1 - - - - -

Спланировать проект Я Сделано

оффлайн: Уволить ____ Я Сделано

прекращение квартальных премий Я Сделано

замораживание индексаций Я Сделано

оффлайн: разобраться с задачами ___ (Кому поручить? Я Сделано

Увольнения спецов декабрь, январь Я Сделано

сокращение зарплат АУП Я Сделано

сократить аренду помещений (переезд на завод) (30) Я Сделано

сокращение затрат на рекламу Я Сделано

поручить _____ борьбу с приписками (сумма?) Я Сделано

закрытие контракта с ______ сделано

Снизить поток через Киви в пользу альфы (сумма) kust Принимайте

закрыть оплату простоев и осмотров (30) Vit Сделано

перестать покупать подземный кабель на ______ mstryg Сделано

Перестать платить Дезам за дохлые дома (подумать над списком) rni Отменено

 

 

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

 

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

Чтобы мне дал глубокий анализ целей?

 

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

[Kirya]

Тим, это ты называешь длинными задачами ?

:(

 

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

которому приходится вести параллельно 50-100 проектов и проектиков длительностью от полугода до года

переплюнет.

 

На мой взгляд у тебя два пути: или делать жесткий time management, или всё-таки разбираться с мотивацией.

[Тимур]

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

 

Еще раз повторю то же, что писал и выше

 

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

 

Характерные особенности ситуации

 

- проекты условно небольшие (от суток до года работы)

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

- проектов много (сотни активных тасков, каждый из которых может быть интерпретирован как минипроект)

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

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

- ответственные за проекты занимаются ими урывками (99% энергии съедает текучка)

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

- массовое(даже тотальное) отсутствие у менеджеров культуры планирования (следствие процессного менталитета)

- у организации нет критичной мотивации заниматься этими проектами, потому что на приход 99% бабла в краткосрочной перспективе это не влияет (более того реализация проектов отъедает ресурсы у в целом успешной основной деятельности)

 

 

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

 

 

Бывают проекты где цели туманны

 

Вот хороший пример

Проект - Лояльность: KPI (использование средств колрега для достижения стратегических целей компании) ( kust ) [4 / 8]

зафиксировать результаты первых трех встреч по звонкам с операторами kust Отменено

Способы фиксации неправильного перевода звонков kust Отменено

Решить проблему записи звонков, проходящих через callback (Глюк, диалпланы) kust Жду реализации

Рабочее место контролёра качества услуг (КОТТП-оператора) sht Включено в план

Рабочее место и виджеты для контролера звонков в КОТТП kust Опытная эксплуатация

Коллрег менеджеров и операторов СМЕ, санация, новые кнопки kust Опытная эксплуатация

Оценить загрузку телефонной очереди СМЕ-операторов, скорректировать кол-во и график сотрудников zhuzha В работе

Анализ звонков, повторяющихся ежемесячно kust В работе

 

Я думаю, тут всем присутствующим интуитивно понятно, что это все за фигня и чем человек занимается. И даже примерно понятно зачем.

 

Однако, скажите на милость и как же мы будем выставлять цели по Лояльности?

В чем мы можем измерить лояльность?

[Тимур]

Вопрос. А можно ли вообще говорить в данном случае о проектах?

 

Сверимся с определением

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

 

- задачи скоординированы?

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

- начальными и конечными датами?

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

- предпринятых для достижения цели?

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

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

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

Другое дело, что во многих случаях овчинка не стоила выделки.

 

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

 

Раз такое дело - будем их в дальнейшем называть омега-проектами.

 

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

[Тимур]

Тим, это ты называешь длинными задачами ?

 

Конкретно эти были довольно короткими. Как ты хорошо понимаешь :-)))

Но бывают и длинные.

 

 

 

 

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

переплюнет.

 

А в какой среде он кстати это делает.

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

Делается такой значит файлик. В строках названия задач, в колонках временные периоды, ячейки красятся в разные цвета.

Нормально все получается :-)

 

На мой взгляд у тебя два пути: или делать жесткий time management, или всё-таки разбираться с мотивацией.

 

До мотивации и тайм менеджмента я еще конечно доберусь. Ту би континьют

[Тимур]

Продолжим... что я на эту тему думаю.

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

 

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

 

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

 

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

 

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

 

 

 

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

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

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

 

Продолжим после паузы

[Тимур]

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

Какие таски относятся к тактическому уровню

- это задача имеющая определенный бизнес-смысл

- законченные куски работы

- куски работы имеющие воспринимаемую протяженность (до двух недель)

- задачи, где разделены заказчик и исполнитель

 

Критически важно научиться учитывать такие задачи.

 

Чуть конкретизирую.

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

 

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

 

 

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

 

Смена ответственного.

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

 

 

Если мы добьемся состояния, что все задачи тактического уровня

 

- у нас зарегистрированы в системе

- что все задачи ставятся в системе, а не где попало (почта, телефон, бумажки)

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

 

то мы уже на полпути к Луне.

 

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

 

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

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

 

 

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

 

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

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

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

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

- люди не отмечают своевременно закрытие

 

Ну и так далее. Проблем много, решить их необходимо иначе невозможно сдвинуться дальше.

 

Как решать? Ну тут уж зависит от традиций организации, административные меры, надзор, премирование, убеждение, тренинги - что угодно.

[Тимур]

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

Можно спокойно отписываться, не отвлекаясь на комменты :-)))

 

 

О чем я? А ну да. Тактический слой. Чтобы было понятно что я имею в виду.

 

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

 

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

 

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

 

 

Ну так вот. Тактический слой.

 

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

[Тимур]

Ну так вот. Я тут выше сказал, что автоматизационной проблемы тут нет. Это половина правды.

 

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

 

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

 

Какая должна быть структура проектов?

 

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

 

Технологически пофиг. А методические последствия очень существенные.

 

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

 

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

 

Проблемы я вижу две.

 

1) Если система допускает неконтролируемое создание подзадач пользователями, то по моему скромному мнению, пользователи именно этим и будут заниматься. Делать это будут адово нелогичным способом, от чего в какой-то момент вся иерархия поплывет. На одном уровне восприятия будут таски уровня "повысить выручку в сегменте ТСЖ на 20%" и "постирать униформу монтажников". Довольно скоро в этом фарще разобраться будет в принципе невозможно, после чего все участники потяряют к системе интерес, предварительно сурово фрустрировав друг друга.

 

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

 

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

 

 

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

 

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

[Тимур]

Альтернативой является плоская организация. Как в Джире.

 

В джире у проекта нельзя создать подпроект.

 

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

Как же тогда люди живут в джире? Плохо живут :-) - им приходится руками создавать связи между задачами, использовать местную систему тегов (версии, компоненты).

Короче, чтобы культурно эксплуатировать джиру пользователю нужно понимать чем он занимается. Это осложняет обучение. Нужно потратить время и поврубаться в то, как устроены правильные практики.

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

 

 

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

 

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

 

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

[leiden]

Прикольно. Битва за формирование process-based vs project-base в ситуации, когда все смыслы уже давно в product-base.

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

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

 

Ибо смыслы все - в потребителе и потребляемом им продукте.

[Sergey Gilfanov]

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

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

[jab]

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

 

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

[Тимур]

Прикольно. Битва за формирование process-based vs project-base в ситуации, когда все смыслы уже давно в product-base.

 

Ну... ты же нам на кроссе про это расскажешь?

 

Ибо смыслы все - в потребителе и потребляемом им продукте.

 

Да.

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

;-)

[SergeiK]

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

Можно спокойно отписываться, не отвлекаясь на комменты :-)))

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

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

 

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

Это как раз и есть следствие расхождения понятийного базиса.

[leiden]

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

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

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