Jump to content
Калькуляторы

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

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

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

 

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

 

 

 

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

 

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

Правда - совсем ничего драйвового.

 

А чего ты хочешь от оптимизации коммунального предприятия?

 

и проблемами не видятся,

 

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

 

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

 

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

 

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

 

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

 

Допустим, вопрос с прояснением целей. Я согласен с тем, что он имеет огромное значение. Запятая но - это уже второй класс начальной школы. А мы пока висим в первом.

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

Share this post


Link to post
Share on other sites

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

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

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

 

Беда с вами высоколобыми.

Ничерта не понимаю :-(

 

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

Давай рассмотрим реальный кейс.

 

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

А почему нельзя в данной истории рассматривать меня как клиента? Я клиент - плачу деньги, покупаю управленческие услуги. Не? Плачу премии, штрафую, могу расторгнуть контракт (что порой и происходит). Чем я не клиент?

 

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

 

Не то, чтобы я прям сильно расстроен ситуацией (скорее наоборот - считаю выбор правильным). Но тем не менее интересно чисто в дидактическом смысле.

 

Еще раз - в случае с управленческими задачами - что является продуктом и кто является клиентом?

Share this post


Link to post
Share on other sites

Тимур, ну я повторюсь да?

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

Share this post


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

переплюнет.

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

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

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

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

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

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

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

Строитель, как говориться, "старой школы".

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

Но это уже другой аспект.

 

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

 

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

Бардак можно автоматизировать бесконечно. ©Прохожий

Сэкономь своё время.

Edited by Kirya

Share this post


Link to post
Share on other sites

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

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

 

 

Так. Давайте еще раз и помедленнее.

 

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

 

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

 

Для кого-то этот таск становится проектом.

 

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

 

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

 

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

 

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

 

Вот чем меня пугают деревья.

 

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

 

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

 

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

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

 

А теги тут совершенно не при чем.

Share this post


Link to post
Share on other sites

Еще немного подробностей на про тактический слой

 

И раз уж мы заговорили о тегах. Теги штука хорошая. Полезная. Технологически реализуется просто.

 

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

 

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

 

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

 

 

 

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

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

 

Тривиальный пример - состав этапов.

Минимальный состав это бинарник - задача поставлена, задача решена (плюс возможность удалить задачу) Нас это устраивает? Очень хороший вопрос на самом деле. Увеличив количество этапов мы получаем возможность навернуть всяких сервисов, ну там... всякие скрипты для отправки почты, отличать "в работе" от "на паузе" и т.д.

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

 

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

 

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

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

 

 

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

 

Ну и так далее

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

А делать ли тег обязательным?

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

А что делать если задача ногами растет из финансового проекта, а по смыслу является аналитической - как ее метим?

Два тега вешается.

А можно ли пользователям создавать персональный набор тегов?

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

 

А можно ли создавать теги в рамках проекта?

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

 

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

Не очень понятен сценарий, который вопрос вызвал.

 

А какие штатные сервисы предоставляет система по работе с тегами? А если поковорять?

А вот если хорошо поковырять - то с разбегу впечатываемся во всякие системы создания/управления онтологиями. Страшные и мозгодробительные штуки. Ну и сразу прорекламирую: Читать вот этого человека.

Share this post


Link to post
Share on other sites

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

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

 

А что из того что ты видел тебе понравилось?

 

Бардак можно автоматизировать бесконечно. ©Прохожий Сэкономь своё время.

 

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

:-)))

 

О чем это я? А да - знаешь, чуть ли не первое, что я услышал, когда начал заниматься какой-то автоматизацией это сентенцию - "Автоматизация бардака порождает автоматизированный бардак". Мне тогда эта мысль показалась невъ#@енно глубокой.

 

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

 

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

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

 

Есть ли альтернатива? Безусловно. Например, существуют на свете управленцы, которые способны действовать крайне эффективно, они правильно нарезают задачи, правильно подбирают исполнителей, правильно контролируют и т.д. В конце концов - построили же люди как-то пирамиду хеопса без единого компьютера? Вопрос - как найти таких управленцев? На hh.ru - желаю удачи :-))

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Автоматизация это самый простой, надежный, стабильный и гарантированный способ свести бардак к терпимому уровню.

 

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

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

У всех провайдеров ЗАЯВКИ на подключения автоматизированы, те есть адрес, Ф.И.О., телефон, дата! а раньше, мы застали времена, когда это было в голове, потом в блокнотике со страницами и разлиновкой по часам, потом в сетевом Excel (который открыт на нескольких ПК) - сейчас вот в облаке :)
Edited by SergoINFOLAN

Share this post


Link to post
Share on other sites

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

 

По сабжу: запилил битрикс24 в коллективе из 12 офисных сотрудников. Решение достаточно удобное, позволило уйти от бесконечных цепочек писем в электропочте.

Регламентные задачи прописаны и сами всплывают по-расписанию. Есть клиенты под планшетники и телефоны.

В нашем случае система еще и бесплатна.

 

P.S. Технари варятся в своей тикетнице.

Share this post


Link to post
Share on other sites

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

А что делать если задача ногами растет из финансового проекта, а по смыслу является аналитической - как ее метим?

Два тега вешается.

 

Ок. Но тогда теги это механизм фильтрации. Не очень понятно как из этого можно выявить направленность на цель задачи

 

 

 

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

Не очень понятен сценарий, который вопрос вызвал.

 

Кадровая база? Ну у нас же управленческие проекты.

Тут дурацкий вопрос. К примеру джира платная. То есть покупать аккаунты на всех сотрудников глупо (потому что в управленческих проектах задействовано процентов 20 от штата.) Можно купить лицензию на 50 пользователей, но нужен какой-то механизм как загружать ники остальных сотрудников.

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

 

 

Ну и сразу прорекламирую: Читать вот этого человека.

 

Подписался. Наш старый абонент, кстати :-)

Не ругал?

 

ОФФТОП - жалко, что компьютерры больше нет.

Share this post


Link to post
Share on other sites
По сабжу: запилил битрикс24 в коллективе из 12 офисных сотрудников. Решение достаточно удобное, позволило уйти от бесконечных цепочек писем в электропочте.

я его смотрел пару лет назад. кривая тормозная неповоротливая поделка с вырвиглазным молодежным дизайном. даже teamwox дешевле и лучше.

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

Share this post


Link to post
Share on other sites

Подписался. Наш старый абонент, кстати :-)

Не ругал?

Кстати, может, его сюда пригласить? Пусть порезвится и примеров для своих лекций пособирает. С Прохожим еще можно стравить. Будет очень поучительно для всех читающих.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
По сабжу: запилил битрикс24 в коллективе из 12 офисных сотрудников. Решение достаточно удобное, позволило уйти от бесконечных цепочек писем в электропочте.

я его смотрел пару лет назад. кривая тормозная неповоротливая поделка с вырвиглазным молодежным дизайном. даже teamwox дешевле и лучше.

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

Врядли. Я даже не заморачивался над его дизайном. Так мы бы никогда систему не внедрили)

Впрочем до этого пытался вести проекты в тимере и мегаплане. Там как-то все еще печальнее показалось.

 

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

:-D

Меня все устраивает пока. Только приложение по ipad в свежем апдейте сломали и не починили обратно.

Share this post


Link to post
Share on other sites

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

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

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

Ну, например, то, что ты описал как альфа проекты проектами не являются :). И омега - тоже.

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

 

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

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

Правда - совсем ничего драйвового.

 

А чего ты хочешь от оптимизации коммунального предприятия?

Я? Ничего :). А ты, что хочешь ты?

 

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

Это верно, я не руковожу таким предприятием.

 

Допустим, вопрос с прояснением целей. Я согласен с тем, что он имеет огромное значение. Запятая но - это уже второй класс начальной школы. А мы пока висим в первом.

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

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

Share this post


Link to post
Share on other sites

Беда с вами высоколобыми.

Ничерта не понимаю :-(

 

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

Давай рассмотрим реальный кейс.

 

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

А почему нельзя в данной истории рассматривать меня как клиента? Я клиент - плачу деньги, покупаю управленческие услуги. Не? Плачу премии, штрафую, могу расторгнуть контракт (что порой и происходит). Чем я не клиент?

 

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

 

Не то, чтобы я прям сильно расстроен ситуацией (скорее наоборот - считаю выбор правильным). Но тем не менее интересно чисто в дидактическом смысле.

 

Еще раз - в случае с управленческими задачами - что является продуктом и кто является клиентом?

Давайте рассмотрим реальный кейс.

Но я не настоящий сварщик, поэтому нарисую картину, как вижу, прошу не судить слишком строго.

 

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

1. Задачи у группы довольно типичные.

2. Бизнес-процесс группы не формализован, регламенты не прописаны, сотрудники группы познают порядок работы в общении с коллегами и по наитию.

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

4. Так же она решает некоторые типичные задачи для руководителя, типа каких-то сводных отчетов.

5. Задач руководителя, постоянных и регулярных, не так много, а нетипичные ситуации случаются спонтанно и объем их непредсказуемый.

 

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

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

2. Её личная заинтересованность в результате работы невелика. Конечно, уверен, её бы хотелось, чтоб после её ухода проблем не было. Но это никак не приоритет номер 1.

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

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

 

Как бы, я полагаю, надо поступить?

1. Взять в группе толкового сотрудника и поставит прямым заместителем. Нагрузку с девушки надо снимать, ибо не угадаешь, в такой ситуации, как будут развиваться события, и адекватная замена должна уже быть.

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

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

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

5. Заместитель заранее знает о своих перспективах и об оценке результатов его работы за месяц.

 

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

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

Share this post


Link to post
Share on other sites
Врядли. Я даже не заморачивался над его дизайном. Так мы бы никогда систему не внедрили)

я имел возможность сравнить в живых организациях несколько систем совместной работы CRM. дизайн имеет решающее значение.

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

Share this post


Link to post
Share on other sites

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

 

Люди вон, даже к интерфейсу 1с как-то привыкают.:-)

Share this post


Link to post
Share on other sites

Сергей.

Я таки уехал на шашлыки, пишу с телефона.

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

2Сергей

вы писали: Íó, íàïðèìåð, òî, ÷òî òû îïèñàë êàê àëüôà ïðîåêòû ïðîåêòàìè íå ÿâëÿþòñÿ :). È îìåãà -òîæå. Òû íå äåëàåøü ðàçíèöû ìåæäó ïðîöåññàìè, ïðîåêòàìè è ïðîñòî îòäåëüíûìè ðÿäîâûìè çàäà÷àìè.

 

Два момента.

 

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

 

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

Share this post


Link to post
Share on other sites

Öèòàòà

 

еùå ìàëåíüêèì, íî óæå áîëüøèì

 

ýòî êàê ?!

 

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

 

 

:)

 

многие годы мы болтаемся в интрвале от 290 до 330

:)))

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this